判斷 VPN 是否正常運作，不能只看用戶端顯示的「已連線」。這個狀態通常只代表用戶端已與遠端線路建立連線或完成握手，並不能直接證明瀏覽器、下載工具與其他應用程式的流量都經過該線路。最穩妥的檢查方式，是先記錄連線前的網路狀態，再依序確認出口 IP、DNS 解析路徑與實際使用的應用程式，最後檢查分流規則、系統代理與路由模式。
排查時要分開確認「線路是否建立」、「系統是否接管流量」以及「目標應用程式是否遵循接管方式」。前者正常、後兩者異常時，用戶端仍可能顯示連線成功。反過來，出口 IP 已經變更，也不代表所有請求都採用相同路徑；DNS、IPv6 流量、區域網路請求或被規則排除的應用程式，仍可能經由原本的網路。
先分清「已連線」與實際接管流量
代理或 VPN 用戶端通常需要完成幾個獨立環節：讀取節點設定、與伺服器建立工作階段、設定系統代理或虛擬網路介面、寫入路由規則，再依照分流策略處理請求。介面上的連線開關，多半只能概括前面幾個環節。若系統設定被其他軟體改寫、虛擬介面未取得路由，或應用程式忽略系統代理，就可能出現開關已開啟但存取路徑沒有改變的情況。
不同協定不會改變這套判斷邏輯。Shadowsocks、VMess、Trojan 與 VLESS 通常由代理用戶端搭配系統代理或虛擬網卡模式使用；Hysteria2、TUIC 等協定同樣需要用戶端將應用程式流量交給對應連線。協定握手成功只能證明用戶端能夠連到節點，是否涵蓋整台裝置，仍取決於用戶端模式、作業系統路由與分流規則。
| 觀察到的現象 | 可以說明什麼 | 仍不能說明什麼 |
|---|---|---|
| 用戶端顯示已連線 | 節點工作階段大概已建立 | 不能證明所有應用程式都經過線路 |
| 瀏覽器出口 IP 改變 | 該瀏覽器的檢測請求經過了新的出口 | 不能直接代表其他應用程式與 DNS 路徑 |
| 目標網站可以開啟 | 目前請求存在可用的存取路徑 | 不能僅憑可存取狀態判斷採用哪條路徑 |
| DNS 檢測出現陌生的解析器 | 解析請求可能已由線路端或自訂服務處理 | 不能只憑名稱判斷所有流量的出口 |
還要區分「系統代理」與「虛擬網卡」這兩種常見的接管方式。系統代理仰賴應用程式主動讀取作業系統的代理設定，瀏覽器通常支援較完善，但部分遊戲、命令列工具與獨立更新程式可能會忽略。虛擬網卡模式會在網路層接管更多流量，涵蓋範圍通常更廣，但仍會受到路由排除項目、分流規則與本機網路設定影響。
用出口 IP進行第一輪確認
出口 IP 是最直觀的檢查項目。先中斷用戶端連線，開啟本站的 IP 檢測 頁面，記下目前的位址與大致地區。接著關閉該頁面，連線至目標線路，再重新開啟檢測頁面。不要只重新整理一個長時間未關閉的分頁，因為瀏覽器快取、頁面腳本狀態或舊連線重用都可能干擾判斷。
- 中斷線路，確認用戶端已恢復未連線狀態。
- 開啟 IP 檢測頁面，記錄原本網路的出口。
- 關閉檢測分頁，再連線至準備使用的線路。
- 重新開啟檢測頁面，比較位址與地區是否符合所選線路。
- 改用其他瀏覽器或無痕視窗複查，排除擴充功能與快取的影響。
如果位址沒有變化，先檢查用戶端目前的模式。規則模式可能將 IP 檢測站判定為直連，因此檢測到的仍是原本的出口。排查階段可以暫時切換至全域或虛擬網卡模式進行比對，但確認原因後，應恢復適合日常使用的分流設定。不要長期保留臨時排查規則，否則本機網站、區域網路裝置或辦公資源可能經由不必要的遠端路徑。
如果位址發生變化，但地區與所選節點明顯不符，先排除資料庫標示差異。IP 地理資訊來自不同資料庫，城市層級的結果可能不一致，不能把單一頁面的城市名稱當作線路故障證據。更有價值的是確認位址是否從原本的網路出口變成另一個位址，以及多個檢測來源是否大致指向目標國家或地區。
如果瀏覽器檢測正常，但其他軟體仍使用原本的網路，問題通常已從「線路是否連線」縮小至「應用程式是否受到接管」。此時不必反覆更換節點，應繼續檢查用戶端模式與特定應用程式的行為。
檢查DNS 解析是否繞回原本的網路
存取網域時，裝置通常會先進行 DNS 解析，將網域轉換成可連線的位址。網頁內容經過遠端線路，並不代表 DNS 請求也一定採用相同路徑。如果系統仍將解析請求傳送給原本網路提供的解析器，就會出現常說的 DNS 洩漏。這不一定會導致網頁無法開啟，但會讓解析路徑與存取路徑不一致，也可能造成地區判定錯誤、網域解析異常或分流結果偏差。
檢查時應在中斷與連線狀態下分別執行 DNS 檢測，比較解析器的歸屬。連線後仍只出現原本網路的解析器，表示用戶端的 DNS 接管可能未生效；若同時出現原本網路與線路端解析器，則可能存在並行解析、瀏覽器內建加密 DNS、系統快取或多個網路介面同時運作的情況。
- ✅ 分別在連線前後進行檢測，並保留兩次結果以便比較。
- ✅ 檢查瀏覽器是否啟用了獨立的安全 DNS 設定。
- ✅ 檢查用戶端是否提供遠端 DNS、代理 DNS 或防洩漏選項。
- ✅ 修改設定後關閉舊分頁，再重新執行檢測。
- ❌ 不要因為出現陌生解析器，就直接判定線路異常。
- ❌ 不要只清除瀏覽器記錄，卻忽略作業系統的 DNS 快取。
瀏覽器內建的加密 DNS 容易讓結果變得複雜。它可能繞過系統 DNS 設定，直接連線至瀏覽器指定的解析服務；也可能依據系統策略自動降級。排查時可以暫時讓瀏覽器跟隨系統設定，再觀察用戶端能否接管解析。確認路徑後，再決定使用瀏覽器獨立解析或由用戶端統一解析，避免兩套策略互相覆蓋。
分流用戶端也可能依據網域規則決定流向。如果 DNS 解析在規則比對前後採用不同策略，某些網域可能取得適合原本網路的位址，之後卻被送往遠端線路；也可能取得線路端位址，卻被判定為直連。這類問題常表現為部分網站正常、部分網站逾時，而出口 IP 檢測看起來沒有異常。
IPv6 也需要單獨留意。原本的網路支援 IPv6，但線路只接管 IPv4 時，支援雙堆疊的應用程式可能優先選擇未受接管的 IPv6 路徑。如果檢查頁面同時顯示兩類位址，應確認它們是否都符合預期。用戶端未接管 IPv6 時，可以在用戶端啟用相應支援、調整路由策略，或在排查階段暫時停用該路徑進行比對。不要在沒有記錄原始設定的情況下直接修改系統網路參數。
按應用程式逐一驗證，不要只測試瀏覽器
瀏覽器通過檢測不代表整台裝置都已被接管。不同應用程式使用網路的方式並不相同：瀏覽器通常遵循系統代理；部分桌面軟體使用自己的代理設定；命令列程式可能讀取環境變數；遊戲與即時通訊工具可能直接傳送 UDP；商店應用程式與系統服務還可能受到作業系統沙盒或背景策略限制。
驗證時應選擇實際要使用的應用程式，而不是一次開啟許多軟體。先關閉應用程式，連線至線路，再重新啟動應用程式，並使用能明確反映地區或網路出口的功能。已經執行中的應用程式可能保留舊連線，即使系統路由發生變化，舊工作階段也不一定會立即重建。
瀏覽器
先檢查擴充功能。代理擴充功能可能覆蓋系統代理，也可能只代理目前的瀏覽器。如果用戶端與擴充功能同時啟用，實際路徑可能出現重複代理或規則衝突。排查時保留一種接管方式即可。無痕視窗通常會停用部分擴充功能，適合用來比對，但仍需確認瀏覽器是否允許擴充功能在無痕模式中執行。
桌面軟體與命令列工具
如果桌面軟體提供「跟隨系統」、「不使用代理」或「自訂代理」等選項，應先確認目前選取的是哪一項。命令列工具則可能讀取 HTTP_PROXY、HTTPS_PROXY 或 ALL_PROXY 等環境變數。舊的終端機視窗不一定會自動取得之後寫入的變數，修改後應重新開啟終端機再測試。
檢查順序
中斷線路 → 記錄原本的出口
連線至線路 → 開啟新的瀏覽器檢測頁面
重新啟動目標應用程式 → 執行實際存取
對照用戶端連線記錄 → 確認是否符合規則
切換接管模式 → 再次進行比對即時通訊與使用 UDP 的應用程式
部分應用程式的登入請求會走 TCP，但語音、視訊或即時資料會走 UDP，因此可能出現「可以登入但通話異常」。需要確認節點協定、用戶端與目前網路都能處理應用程式所需的 UDP 流量。系統代理模式對這類流量的涵蓋通常不如虛擬網卡模式完整，排查時可以使用虛擬網卡模式進行交叉驗證。
如果只有一個應用程式異常，而其他應用程式的出口與 DNS 都正常，應優先檢查該應用程式本身的設定、防火牆許可、舊連線與分流命中狀況。此時繼續更換線路通常無法定位問題。若用戶端提供連線記錄，可查看目標網域或位址最後被標記為代理、直連或拒絕；記錄應用來判斷規則，不應只看流量總量。
常見的假連線現象與對應處理方式
「看起來連上了但沒有經過線路」通常不是單一故障。以下現象可以協助縮小範圍。處理時一次只修改一項設定，並在每次修改後重複相同的檢測；同時更換節點、協定、DNS 與模式，會讓結果無法判斷原因。
| 現象 | 可能原因 | 優先檢查項目 |
|---|---|---|
| 所有應用程式的出口都沒有變化 | 系統代理未寫入、虛擬介面未接管或路由衝突 | 接管模式、系統代理狀態、虛擬介面權限 |
| 瀏覽器正常，其他軟體異常 | 其他軟體忽略系統代理或使用獨立代理 | 應用程式網路設定、虛擬網卡模式、分應用程式規則 |
| 出口已變更，DNS 仍是原本的網路 | DNS 未被接管或瀏覽器使用獨立解析 | 用戶端 DNS 選項、瀏覽器安全 DNS、系統快取 |
| 部分網站直連，部分網站經過線路 | 規則模式正常分流，或規則存在誤判 | 目標網域命中的規則與規則順序 |
| 切換線路後仍顯示舊地區 | 舊連線重用、快取或地理資料庫差異 | 關閉應用程式後重新開啟，並更換檢測來源複查 |
| 應用程式可以登入，但即時功能異常 | UDP 未被接管、網路限制或分流不一致 | 協定能力、用戶端模式與應用程式流量類型 |
訂閱連結與用戶端設定也可能造成誤判。更新訂閱後，用戶端內仍可能選取舊節點；名稱相同的節點不一定對應相同設定。遇到長期異常時，可以先重新整理訂閱，確認更新時間與目前選取的節點，再重新連線。不要將訂閱連結直接貼到網頁檢測工具或傳給他人，其中通常包含與帳戶相關的資訊。
同時執行多個用戶端也是常見的衝突來源。一個用戶端寫入系統代理，另一個建立虛擬介面，關閉其中一個時又恢復舊設定，最終狀態會很難判斷。排查階段應完全退出其他代理或 VPN 用戶端，只保留目前測試的軟體。只關閉視窗不一定等於退出，還需檢查背景執行狀態。
從 Wi-Fi 切換至有線網路、熱點，或從休眠狀態恢復後，原有的虛擬介面與預設路由可能失效。用戶端仍顯示連線，是因為工作階段尚未及時更新。此時先中斷再重新連線；如果仍無效，再退出用戶端並重新啟動。企業網路、飯店網路與公共網路也可能限制特定連線方式，更換協定可以作為比對，但應先確認基本的網頁存取本身正常。
依固定順序完成最終複查
完成修改後，應從頭執行一次完整複查，不要將前面不同設定下得到的結果拼湊在一起。最終結果應來自同一次連線、同一套規則與同一個網路環境。以下清單適合在更換用戶端、匯入新訂閱或調整分流規則後使用。
- ✅ 在中斷連線狀態下記錄了原本的出口與 DNS 基準。
- ✅ 連線後出口位址出現預期變化，地區與所選線路大致一致。
- ✅ DNS 檢測沒有意外只顯示原本網路的解析路徑。
- ✅ IPv4 與 IPv6 的處理方式符合目前的用戶端設定。
- ✅ 瀏覽器擴充功能沒有覆蓋或重複使用用戶端代理。
- ✅ 實際使用的桌面應用程式已關閉並重新開啟，且完成單獨驗證。
- ✅ 分流記錄顯示目標請求符合預期規則。
- ✅ 臨時使用的全域模式或測試設定已經恢復。
- ❌ 不要把單一網站能否開啟當作唯一判斷依據。
- ❌ 不要在一次排查中同時修改所有網路選項。
如果出口 IP、DNS 與多個應用程式都符合預期，可以認為目前連線已正常接管需要處理的流量。如果只有個別應用程式失敗，繼續檢查應用程式設定與分流；如果所有應用程式都失敗，回頭檢查系統代理、虛擬介面與路由層；如果出口正常但解析異常，則集中處理 DNS 與瀏覽器獨立解析設定。按層次定位比反覆切換節點更穩定，也更容易重現。