確認 VPN 是否真的生效，不能只看客戶端顯示的「已連線」。這個狀態通常只能代表客戶端已與遠端線路完成交握，無法證明瀏覽器、桌面軟體、命令列工具和 DNS 查詢都經過預期路徑。可靠的判斷方式，是依序檢查出口 IP、DNS 解析、路由模式與具體應用程式，並比較連線前後的結果。
如果出口位址已經改變，但某個應用程式仍顯示原本的網路位置，問題通常不在線路交握，而是出在系統代理、TUN 模式、分流規則、快取連線或應用程式本身的網路實作。反過來說，即使頁面可以正常開啟，也不能直接推斷所有請求都經過線路：規則模式可能只轉送特定網域，其他流量仍會透過本地網路直連。
先了解「生效」包含哪些部分
VPN 是否生效並不是單一開關。完整連線至少涉及線路交握、系統路由、名稱解析與應用程式流量。任何一層未按預期運作，都可能出現介面顯示正常、實際路徑卻異常的情況。
| 檢查對象 | 應確認的結果 | 常見異常 |
|---|---|---|
| 客戶端狀態 | 設定已載入、線路交握完成，且沒有持續重新連線 | 訂閱已過期、節點無法連線、系統時間異常或協定參數不相容 |
| 出口 IP | 連線後的公開出口與連線前不同，且符合所選地區 | 應用程式繞過代理、規則命中直連、舊連線未釋放 |
| DNS 解析 | 解析請求符合客戶端設定的本地、遠端或加密 DNS 策略 | 系統快取、瀏覽器獨立解析、區域網路解析器持續接管 |
| 具體應用程式 | 需要經過線路的應用程式實際使用對應出口 | 應用程式不讀取系統代理、只有部分協定被接管、分應用規則設定錯誤 |
| 協定與位址族 | TCP、UDP、IPv4 與 IPv6 依目前設定處理 | 只接管其中一類流量，另一類仍從本地網路送出 |
不同客戶端對這些層的控制能力並不相同。桌面端常見的「系統代理」主要修改作業系統的代理設定，只有主動讀取這些設定的應用程式才會跟隨。TUN 模式則會建立虛擬網路介面，透過路由表接管更廣泛的網路流量，較適合不支援代理設定的軟體，但通常需要相應的系統權限。
行動端客戶端一般會使用系統提供的 VPN 介面統一接管流量，但仍可能受到分應用排除、隨選連線、私人 DNS 或應用程式內建加密 DNS 的影響。因此，同一份 Shadowsocks、VMess、Trojan、VLESS、Hysteria2 或 TUIC 設定，在不同平台上的「已連線」不代表接管範圍完全一致。
出口 IP 檢查的正確順序
出口 IP 是最直觀的驗證入口，但必須先記錄未連線狀態，才能進行可靠比較。只在連線後開啟查詢頁面，看見一個陌生位址，並不足以證明結果屬於目前線路；企業網路、共享網路和上游代理本身，也可能讓公開位址與裝置區域網路位址不同。
- 中斷客戶端連線。完全結束現有連線，關閉可能自動重新連線的隨選規則。
- 記錄基準。查看目前的公開出口、網路提供者與大致地區，不要把完整位址發布在公開截圖中。
- 重新連線。選擇容易辨認的地區線路，等待客戶端狀態穩定。
- 建立新工作階段。使用新的瀏覽器隱私視窗，避免舊頁面、快取與長連線干擾判斷。
- 再次查詢。比較出口位址、地區與網路歸屬是否隨線路改變。
- 切換線路複查。切換到另一個線路群組後重新載入，確認結果不是查詢頁面的快取。
- ✅ 連線前後的出口位址不同，地區與所選線路一致，可以繼續檢查 DNS 與應用程式流量。
- ✅ 瀏覽器和系統網路工具取得相同出口，表示接管範圍較為一致。
- ❌ 位址完全沒有變化，需要檢查目前規則是否將查詢網域設定為直連。
- ❌ 只有瀏覽器位址改變，其他軟體沒有變化，通常表示目前使用的是系統代理，而不是完整流量接管。
- ❌ 切換線路後仍顯示舊地區，可能是頁面快取、連線重用或舊程序尚未關閉。
還要分別觀察 IPv4 與 IPv6。部分本地網路同時提供兩種位址，而客戶端可能只接管 IPv4。此時一般查詢看似已切換出口，但支援 IPv6 的應用程式仍可能優先走本地路徑。處理方式不是簡單關閉所有網路功能，而是先確認客戶端是否支援 IPv6 接管；如果不支援，再依客戶端文件決定停用、阻擋或交由規則處理。
DNS 解析是否依預期處理
瀏覽器存取網域前，通常需要先將網域解析為 IP 位址。DNS 洩漏通常是指原本應交由線路內解析器或指定加密解析器處理的請求，卻仍持續傳送給本地網路提供的解析服務。這不一定會導致網頁無法開啟，但可能暴露查詢過的網域範圍，也可能造成解析結果與線路地區不一致。
判斷 DNS 是否異常，不能只看檢測頁面列出的解析器名稱。現代客戶端可能使用公共 DNS、DoH、DoT、遠端解析或依網域分流；瀏覽器也可能啟用自己的安全 DNS。這些結果未必與出口線路屬於同一家網路。真正需要確認的是：檢測結果是否符合目前設定，而不是解析器名稱是否與出口 IP 完全相同。
建立可解釋的 DNS 結果
先開啟客戶端的 DNS 設定，確認目前策略屬於哪一種：由系統解析、透過遠端線路解析、使用指定的加密 DNS，或依網域規則分別處理。接著清除舊快取，再次發起查詢。不同桌面系統可使用相應的快取重新整理指令：
Windows:
ipconfig /flushdns
macOS:
sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder
Linux with systemd-resolved:
resolvectl flush-caches重新整理系統快取後，還應關閉並重新開啟瀏覽器，因為瀏覽器可能維護獨立快取與連線池。如果瀏覽器啟用了自己的加密 DNS，系統指令不會清除其全部狀態，需要在瀏覽器網路設定中確認解析策略。
- ✅ 解析器與客戶端設定一致，查詢結果會隨設定切換而變化。
- ✅ 本地域名依本地規則解析，國際網域依遠端規則解析，結果與分流設計一致。
- ❌ 客戶端設定為遠端解析，但檢測結果始終只有本地網路解析器。
- ❌ 瀏覽器與命令列的解析結果長期不同，需要檢查瀏覽器的獨立 DNS 設定。
- ❌ 切換線路後網域仍回傳明顯過期的位址，需要清理系統、瀏覽器和應用程式快取。
分流 DNS 比單一解析路徑更複雜。例如，本地域名可以由本地解析器處理並直接存取，其他網域則由遠端解析後經過線路。在這種情況下，檢測頁面同時顯示不同來源的解析請求，不一定代表發生洩漏。判斷重點應放在規則是否符合預期，以及需要遠端解析的網域是否被錯誤送往本地。
逐一驗證應用程式的流量路徑
出口 IP 和 DNS 都正常後，下一步是逐一驗證實際使用的軟體。瀏覽器能經過線路，不代表遊戲、下載器、終端機、同步工具和桌面客戶端也會讀取相同的代理設定。尤其在系統代理模式下，部分應用程式會直接建立連線，完全忽略作業系統代理。
瀏覽器
瀏覽器通常最容易驗證，但也最容易受到擴充功能、獨立代理設定、安全 DNS 和連線重用影響。排查時先停用會修改網路路徑的擴充功能，再使用新的隱私視窗測試。如果一個瀏覽器結果正常、另一個異常，應比較兩者的代理與 DNS 設定，而不是立刻更換節點。
命令列與開發工具
命令列工具是否使用代理，取決於工具本身、環境變數和系統實作。有些工具會讀取代理環境變數，有些需要明確指定代理，還有些只有在 TUN 模式下才會被透明接管。測試時應同時查看客戶端連線記錄，確認請求是否命中代理規則、直連規則或拒絕規則。
桌面軟體與行動應用程式
桌面軟體可能使用內建網路堆疊，行動應用程式也可能建立獨立的 QUIC 或其他 UDP 工作階段。如果目前節點協定或客戶端模式只接管 TCP，相關請求可能繼續直連或直接失敗。Hysteria2 與 TUIC 以 UDP 作為傳輸基礎，不代表啟用這類協定後所有應用程式的 UDP 都必然被接管；應用程式流量是否進入通道，仍由客戶端路由與 TUN 設定決定。
分應用與繞過規則
部分客戶端允許指定哪些應用程式經過線路，哪些維持直連。排查時要同時查看「包含」與「排除」清單，並注意應用程式更新後，可執行檔路徑或套件識別碼可能改變。如果規則仍引用舊路徑，新版本程式可能不再命中原有策略。
| 現象 | 優先檢查 | 處理方向 |
|---|---|---|
| 瀏覽器正常，終端機直連 | 系統代理、代理環境變數、TUN 模式 | 為工具設定代理，或改用能接管該流量的模式 |
| 網頁正常，應用程式內請求失敗 | UDP、QUIC、憑證驗證、分應用規則 | 檢查協定支援與應用程式是否被排除 |
| 部分網站經過線路，部分直連 | 規則模式、網域分類、程序規則 | 查看規則命中記錄，確認是否屬於預期分流 |
| 切換節點後應用程式仍顯示舊出口 | 長連線、背景程序、連線池 | 完全結束應用程式後重新開啟，必要時中斷並重新連線網路 |
| IPv4 正常，IPv6 維持本地出口 | 客戶端位址族支援、系統路由 | 啟用相應的接管能力，或依設定阻擋未受保護的路徑 |
顯示已連線但流量沒有經過線路的原因
最常見的原因是客戶端只建立了通往節點的連線，卻沒有成功修改系統代理或路由。權限不足、虛擬網卡初始化失敗、其他網路工具覆寫設定，都可能造成控制層在線、資料層卻未接管。此時應先查看客戶端記錄，而不是反覆點擊連線按鈕。
系統代理與 TUN 模式選錯
只需要瀏覽器和支援代理的軟體時，系統代理通常較簡單。需要接管不讀取代理設定的應用程式時，TUN 模式更合適。兩者不是速度等級，而是不同的流量入口。啟用 TUN 後，仍應確認虛擬介面已建立、預設路由或策略路由已寫入。
分流規則命中直連
規則模式會依據網域、IP、程序或規則集決定路徑。查詢出口的網站如果被歸類為直連，檢測結果自然不會變化。排查時切換到全域代理，只適合作為短暫對照：如果全域模式正常，表示線路本身大概率可用，問題集中在規則；驗證完成後應恢復符合需求的分流模式。
舊連線沒有釋放
瀏覽器、聊天軟體和同步工具會維持長連線。切換線路不一定會強制這些連線立即重建，因此應用程式可能暫時沿用舊路徑。完全結束應用程式後重新開啟，比只重新整理頁面更可靠。對於背景常駐程序，還要確認程序確實已結束。
多個網路工具爭用設定
同時執行企業 VPN、除錯代理、網路過濾軟體或另一個線路客戶端時，後寫入的路由和代理設定可能覆蓋先前配置。排查階段應保留必要工具，暫停其他會修改網路路徑的程式，再逐項恢復，以找出衝突來源。
訂閱設定沒有更新
訂閱連結負責向客戶端提供節點與規則資訊。伺服器端設定調整後，本地客戶端仍可能保留舊副本。應在客戶端內執行訂閱更新，確認更新成功後再重新選擇線路。訂閱連結屬於存取憑證，不應貼到公開檢測網站或問題截圖中。
線路類型如何影響排查結論
直連、中轉和 IEPL 專線描述的是通往線路入口及出口之間的網路路徑，不等同於客戶端的接管方式。直連線路由裝置直接連接遠端節點，路徑簡單，但更依賴本地網路到目標地區的公網品質。中轉線路會先連接較近的入口，再由中間網路送往出口，可能改善部分網路環境下的路由穩定性。
IEPL 專線通常是指入口與出口之間使用專用承載或受控鏈路，重點在跨區域傳輸路徑。無論使用哪一種線路，裝置端仍需正確完成系統代理、TUN、DNS 與分流設定。專線不會自動修正應用程式繞過代理的問題，也不能取代出口 IP 與 DNS 驗證。
協定同樣不能單獨決定是否生效。Shadowsocks、VMess、Trojan 與 VLESS 提供不同的傳輸和驗證方式，Hysteria2 與 TUIC 著重以 UDP 為基礎的傳輸機制；真正決定應用程式請求是否進入線路的，仍是客戶端如何建立本地入口並套用路由規則。節點交握成功但應用程式直連時，通常應先檢查本地接管層，而不是直接判定遠端節點故障。
一套可重複的完整驗證流程
暫時開啟一個查詢頁面只能取得瞬間結果。更穩妥的做法是建立固定檢查流程，每次更換客戶端、匯入訂閱、調整 DNS 或修改分流規則後，都依相同順序執行。這樣可以快速判斷變化發生在哪一層。
- 更新設定。在可信任的客戶端內更新訂閱，確認線路與規則已成功載入。
- 記錄未連線基準。保存出口地區、位址族與目前 DNS 策略，不公開完整網路識別資訊。
- 建立連線。觀察記錄是否完成交握，以及是否出現持續重試或虛擬介面錯誤。
- 檢查出口。使用新工作階段比較連線前後的 IP，並分別留意 IPv4 與 IPv6。
- 檢查 DNS。確認解析器與客戶端策略一致，排除系統和瀏覽器快取。
- 檢查規則命中。查看測試網域與應用程式被判定為代理還是直連。
- 逐一驗證應用程式。涵蓋瀏覽器、終端機、桌面軟體和需要使用的行動應用程式。
- 切換線路複查。確認應用程式會建立新連線，且出口結果能隨線路變化。
- 恢復日常模式。如果為了排查而暫時使用全域代理，完成後恢復所需的分流設定。
- ✅ 客戶端交握穩定，記錄中沒有反覆重新連線。
- ✅ 出口結果與所選線路一致，位址族沒有意外繞過。
- ✅ DNS 查詢符合本地、遠端或加密解析策略。
- ✅ 需要經過線路的應用程式都命中代理規則。
- ✅ 應維持直連的本地服務仍依規則存取。
- ❌ 只看連線圖示，沒有核對實際出口與規則記錄。
如果完整流程中只有某個應用程式失敗，應優先收集該應用程式名稱、作業系統、客戶端模式、節點協定、規則命中結果和錯誤記錄。如果所有應用程式都無法切換出口，則優先檢查系統代理、TUN 介面、路由衝突與訂閱設定。將問題限定在具體層級後，排查效率會明顯高於反覆更換節點。