如何檢查 VPN 是否生效，不能只看客戶端是否顯示「已連線」。這個狀態通常只代表交握完成或通道已建立，並不表示瀏覽器、命令列工具和其他應用程式的流量都經過指定線路。可靠的判斷應同時核對出口 IP、DNS 查詢路徑和實際應用程式結果。
一次完整檢查可分成三個層次：先確認客戶端與節點之間的協定連線，再確認作業系統是否將指定流量交給通道，最後確認目標網站看到的出口與預期一致。若只檢查其中一層，很容易把「協定已連線但路由未接管」誤判為連線正常，也可能把瀏覽器自身的代理伺服器或 DNS 設定誤認為系統層級 VPN 已生效。
先區分「連線成功」與「流量經過線路」
客戶端發起連線時，會先與遠端伺服器建立傳輸通道。Shadowsocks、VMess、Trojan、VLESS、Hysteria2 和 TUIC 都可負責這個階段，但協定交握成功後，流量如何進入通道，仍取決於客戶端模式、系統權限和分流規則。
例如，客戶端處於系統代理模式時，通常只有遵循系統代理設定的應用程式會進入代理。瀏覽器可能正常切換出口，但部分遊戲、命令列程式或自行實作網路堆疊的桌面軟體可能繼續直接連線。客戶端處於虛擬網卡或通道模式時，可以接管更廣泛的系統流量，但仍可能受到路由優先順序、排除規則、其他網路工具和系統權限影響。
因此，「已連線」至少可能對應以下幾種不同結果：
- 協定交握完成，瀏覽器和其他應用程式都依規則經過線路。
- 協定交握完成，只有使用系統代理的應用程式經過線路。
- 協定交握完成，但分流規則將目前目標判定為直接連線。
- 通道已建立，但系統路由未正確寫入，或被其他設定覆寫。
- 主要網頁流量經過線路，但 DNS 查詢或部分協定族群仍從本地網路送出。
- 瀏覽器擴充功能或應用程式內建代理改變了結果，使其與系統出口不一致。
排查時不要反覆切換節點後只觀察狀態燈。更有效的方法是固定一條目標線路，記錄連線前後的網路結果，再逐層縮小問題範圍。如此可判斷故障發生在協定、路由、DNS、分流規則，還是特定應用程式。
用出口 IP 確認實際存取路徑
出口 IP 是目標網站看到的來源位址，也是判斷網頁流量是否經過遠端節點最直接的依據。檢查前應先中斷客戶端連線，造訪可信賴的 IP 查詢頁面並記錄本地出口；接著連線至指定線路，再次查詢並比較結果。若位址和地理歸屬隨節點改變，表示目前的查詢請求已從遠端出口送出。
測試時應盡量維持網路環境不變。不要在連線前後切換無線網路、有線網路或其他上網方式，否則本地出口本身也會改變，比較結果便失去意義。瀏覽器頁面也可能快取舊結果，必要時可強制重新整理，或在新的隱私視窗中重新查詢。
出口沒有變化時該檢查什麼
出口 IP 未變化，不一定表示節點無法使用。常見原因包括目前瀏覽器沒有讀取系統代理、客戶端只啟動了本地代理連接埠、虛擬網卡沒有取得必要權限，或分流規則將 IP 查詢網站列為直接連線。此時應先確認客戶端目前使用的是系統代理、規則模式、全域模式還是通道模式。
如果全域模式下出口會改變，而規則模式下不變，問題通常不在協定連線，而在規則比對。可以查看連線記錄，確認查詢網站的網域最後命中代理規則還是直接連線規則。記錄中的「連線成功」只能證明客戶端能夠連到遠端；真正具診斷意義的是該請求被分配到哪個出站。
不同應用程式顯示不同出口
瀏覽器、終端機和桌面應用程式顯示不同出口，通常表示它們沒有共用同一套代理入口。瀏覽器可能啟用了獨立代理擴充功能，終端機程式可能忽略系統代理，部分應用程式還會優先使用自行設定的網路通道。此時應分別關閉應用程式內的代理，或明確將應用程式設定為使用客戶端提供的本地代理入口，再重新測試。
| 觀察結果 | 可能原因 | 下一步 |
|---|---|---|
| 連線後出口發生變化 | 目前查詢流量已進入目標線路 | 繼續核對 DNS 與實際應用程式 |
| 出口始終不變 | 代理未接管、規則直接連線或路由未寫入 | 切換測試模式並檢查連線記錄 |
| 瀏覽器出口改變，其他應用程式不變 | 只有瀏覽器使用了代理 | 檢查系統代理、通道模式與應用程式設定 |
| 不同查詢頁面的結果互相衝突 | 快取、協定族群差異或頁面識別資料不同 | 重新整理結果，並從多個網路入口複核 |
檢查 DNS 查詢是否繞過通道
存取網域時，系統需要先將網域解析為可連線的位址。若網頁流量經過 VPN，而 DNS 查詢仍交由本地網路提供的解析器處理，通常仍可完成存取，但網域查詢路徑與網頁出口並不一致。這類情況常稱為 DNS 洩漏；更精確地說，是解析請求沒有依預期進入受控通道。
檢測時應分別在中斷連線和連線狀態下查看 DNS 解析器的歸屬。連線至線路後，若查詢仍持續由原本的本地網路解析器處理，就需要檢查客戶端的 DNS 接管、虛擬網卡設定和系統快取。若顯示的是客戶端設定的遠端解析器或通道內解析入口，則表示解析路徑較符合預期。
不過，DNS 檢測結果不能脫離設定來判斷。瀏覽器可能啟用加密 DNS，繞過作業系統的解析設定；客戶端也可能依網域類別選擇不同解析器。某個解析器與出口地區不同，不一定代表洩漏，關鍵在於這條路徑是否符合客戶端的設計與使用者設定。
瀏覽器加密 DNS 造成的差異
現代瀏覽器可以自行傳送加密 DNS 請求，因此瀏覽器的解析結果可能與系統命令、其他應用程式和客戶端記錄不同。如果瀏覽器的加密 DNS 請求仍透過通道送出，未必構成繞行；但若分流規則允許該請求直接連線，就會形成獨立於系統 DNS 的路徑。
排查時可以暫時讓瀏覽器遵循系統解析設定，然後重新執行檢測。如果結果因此統一，差異來自瀏覽器自身設定；如果仍不一致，則繼續檢查客戶端的 DNS 規則、虛擬網卡接管範圍和系統網路服務順序。
系統快取與舊解析結果
作業系統和瀏覽器都可能快取解析記錄。切換線路後，既有連線也可能繼續重複使用，導致新出口已生效，但頁面看起來仍使用舊路徑。測試前可以關閉相關頁面、清除系統 DNS 快取，再重新開啟瀏覽器。日常使用不必頻繁清除，只有在診斷路徑變化時才有必要。
Windows:
ipconfig /all
macOS:
scutil --dns
Linux:
resolvectl status這些命令用於查看系統目前識別的解析設定，不代表每個應用程式一定遵循該設定。命令結果需要搭配客戶端記錄、瀏覽器設定和實際 DNS 查詢結果一併判斷。
個別應用程式驗證：瀏覽器正常不代表全部正常
完成出口和 DNS 檢查後，應選擇實際要使用的應用程式逐一驗證。測試對象可以包括瀏覽器、終端機下載工具、桌面客戶端、影片應用程式，以及需要 UDP 的即時通訊程式。重點不是讓所有應用程式顯示完全相同的介面，而是確認每個應用程式的連線是否命中預期出站。
最簡單的方法是先在客戶端記錄中觀察新連線。啟動目標應用程式並執行一次明確的網路操作，接著查看相應網域或位址被分配至代理、直接連線還是封鎖。若記錄中完全沒有該應用程式的請求，可能是它不在客戶端接管範圍內，或使用了客戶端目前未處理的網路協定。
系統代理與通道模式的差異
系統代理適合遵循代理設定的網頁與桌面軟體，設定相對直接，但無法保證涵蓋所有程序。通道模式透過虛擬網路介面接收系統流量，通常更適合需要統一接管的情境。啟用通道模式時，應注意系統權限、預設路由、DNS 接管方式和區域網路存取規則。
如果系統代理測試正常而通道模式異常，應檢查虛擬網卡是否建立成功、路由是否被其他 VPN 或安全軟體改寫，以及客戶端是否排除了目前的網路介面。反過來，如果通道模式正常而系統代理無效，則應查看作業系統代理開關是否成功寫入，以及應用程式是否支援相應代理類型。
分流規則如何影響驗證結果
規則模式會依據網域、位址範圍、程序名稱或規則集合選擇出站。規則判斷錯誤時，客戶端仍會顯示連線正常，但目標請求可能直接送出。尤其在網域經過重新導向、應用程式連線至內容分發網域，或規則只涵蓋主網域時，存取鏈路可能與預期不同。
診斷規則問題時，可以暫時切換至全域代理進行對照。如果目標應用程式在全域模式下恢復，而規則模式下失敗，就應檢查規則順序、網域比對和最終備援策略。排查完成後再恢復所需的分流設定，不必長期依賴全域模式。
UDP 與基於 QUIC 的連線
部分網頁、即時通訊和遊戲會使用 UDP。若客戶端只接管 TCP，或目前網路限制 UDP，應用程式可能退回其他傳輸方式，也可能直接失敗。Hysteria2 與 TUIC 本身基於 QUIC 和 UDP，節點交握、底層網路可達性以及客戶端的 UDP 轉送能力都會影響結果。
Trojan、VMess、VLESS 與 Shadowsocks 的具體表現也取決於客戶端實作、傳輸層設定和路由方式，不能只憑協定名稱判斷是否涵蓋系統流量。協定決定客戶端與伺服器如何傳輸資料，系統代理、虛擬網卡和分流規則才決定哪些應用程式資料會進入這條通道。
| 測試對象 | 需要觀察 | 異常線索 |
|---|---|---|
| 瀏覽器 | 出口、DNS、瀏覽器獨立代理 | 擴充功能或加密 DNS 繞過系統設定 |
| 命令列工具 | 是否讀取環境代理或進入通道 | 終端機出口與瀏覽器不一致 |
| 桌面應用程式 | 程序規則與應用程式內網路設定 | 記錄中沒有相應連線 |
| 即時通訊應用程式 | UDP 接管與連線回退 | 網頁正常但即時連線異常 |
協定、訂閱與節點類型如何影響結果
訂閱連結通常包含節點名稱、伺服器參數、協定類型和傳輸設定。將訂閱匯入客戶端後，客戶端會把這些資訊轉換成本地設定。匯入成功只表示客戶端能夠讀取訂閱內容，不代表所選節點已連線，也不代表路由規則會自動適合目前平台。
如果更新訂閱後突然無法使用，應先確認目前節點是否仍存在、協定欄位是否受客戶端支援，以及訂閱更新是否覆蓋了本地分流設定。部分客戶端會分開管理節點、策略群組、DNS 和路由規則；選擇新節點卻仍使用舊策略群組，也是常見的結果不一致原因。
不同協定的檢查重點
- Shadowsocks：重點確認客戶端是只開放本地代理，還是同時啟用了系統代理或虛擬網卡。僅啟動本地監聽不會自動接管所有應用程式。
- VMess 與 VLESS：除了節點連線外，還要檢查傳輸設定、出站策略與路由規則。VLESS 的安全性取決於採用的傳輸與安全設定，不能脫離完整設定單獨判斷。
- Trojan：需要確認傳輸安全參數與目標伺服器相符。交握失敗屬於協定層問題；交握成功但出口不變，則應回到路由層排查。
- Hysteria2 與 TUIC：重點檢查目前網路對 UDP 的可達性，以及客戶端是否正確處理 UDP 流量。網路環境改變時，它們與基於 TCP 的方案可能呈現不同結果。
直接連線、中轉與 IEPL 專線
直接連線線路通常由使用者網路直接連接遠端節點，路徑更依賴公網路由變化。中轉線路會先連接中轉入口，再由中轉鏈路送往出口節點，可以減少部分不可控的公網路徑，但實際效果仍取決於入口、承載網路和出口設定。
IEPL 專線通常指由跨境企業專線承載的一類鏈路。需要注意的是，線路標示為 IEPL，不代表使用者裝置到入口、入口到出口、出口到目標網站的每一段都脫離公網。驗證時仍應以實際出口、DNS 路徑、連線記錄和目標應用程式結果為準，而不是只依據節點名稱。
切換直接連線、中轉或專線節點後，建議重新執行相同的檢查流程。線路類型改變可能改變出口和傳輸路徑，卻不會自動修復應用程式未被接管、DNS 設定錯誤或分流規則衝突。
各平台常見差異與排查順序
Windows 客戶端通常同時提供系統代理與虛擬網卡模式。系統代理是否成功寫入、虛擬網卡驅動程式是否正常、網路介面優先順序是否被其他工具修改，都會影響結果。可以先查看系統代理狀態，再檢查路由與 DNS 設定，最後用不同應用程式進行對照。
macOS 對網路擴充功能和系統代理設有明確的權限控制。首次啟用通道時，如果網路擴充功能未獲准，客戶端可能儲存節點設定卻無法接管流量。還要注意瀏覽器、終端機和系統網路服務可能讀取不同的代理環境。
iOS 上的客戶端通常透過系統 VPN 設定接管流量，但隨選連線、應用程式規則和系統隱私功能可能改變測試結果。切換節點後，應重新發起請求，不要只觀察仍在重複使用的舊連線。若某個應用程式異常而瀏覽器正常，可先完全關閉該應用程式再重新開啟。
Android 的實作會受到系統 VPN 權限、省電策略、按應用程式代理和一律開啟設定影響。若客戶端在背景遭系統暫停，介面可能保留先前狀態，但新請求無法繼續透過通道。排查時應確認系統狀態列中的 VPN 狀態、客戶端執行狀態和按應用程式清單是否一致。
Linux 更依賴具體桌面環境、路由工具和權限設定。僅設定桌面代理不會自動影響所有 shell 命令和背景服務；虛擬網卡模式則需要正確建立介面並寫入路由。使用容器或獨立網路命名空間時，容器流量也不一定會繼承主機的路徑。
客戶端顯示已連線但無法存取的完整排查流程
遇到「已連線但打不開」時，依固定順序檢查比隨機更換協定更有效。每一步都應記錄結果，以便區分節點故障、網路限制和本地設定問題。
- 記錄連線前基準。中斷客戶端連線，確認本地網路本身可用，並記錄出口 IP 與 DNS 解析路徑。
- 連線至固定節點。不要連續切換多個節點。等待客戶端給出明確的交握或連線回應，並查看是否存在驗證、逾時或傳輸錯誤。
- 重新檢查出口 IP。如果出口未變化，檢查代理模式、虛擬網卡權限、路由規則，以及查詢網站是否命中直接連線。
- 重新檢查 DNS。確認系統與瀏覽器是否使用預期的解析路徑，並排除快取和瀏覽器獨立加密 DNS 的干擾。
- 對照全域與規則模式。若全域模式可用而規則模式異常，重點檢查規則命中和備援出站。
- 逐一測試應用程式。觀察客戶端記錄是否出現相應請求，以及請求最後進入代理、直接連線還是遭到封鎖。
- 檢查協定與網路相容性。若基於 UDP 的協定無法交握，可在相同網路下對照其他可用傳輸方式，判斷是否屬於底層網路限制。
- 排除設定衝突。暫時關閉其他代理、VPN、瀏覽器擴充功能，或會改寫路由的網路工具，再重新建立連線。
- 重新匯入或更新訂閱。確認客戶端支援訂閱中的協定與欄位，並檢查更新是否改變策略群組、DNS 或本地規則。
若某一步恢復正常，應在繼續修改前儲存目前設定。一次變更多個選項會讓故障原因難以確認。排查目標不是讓狀態燈變綠，而是建立一條可重複驗證的路徑：協定能交握、路由能接管、DNS 符合設定、目標應用程式取得預期出口。
最可靠的驗證不是單一測試頁面，而是確認連線記錄、出口結果、DNS 路徑和實際應用程式表現一致。任何一項衝突，都表示仍有部分流量未依預期運作。
如何判斷問題已經解決
修復完成後，應重新從基準開始驗證，而不是只重試剛才失敗的頁面。連線至目標線路後，出口 IP 應與中斷連線時不同，並與所選出口相符；DNS 查詢應符合客戶端設定；瀏覽器、終端機和主要應用程式應依分流規則進入相應出站。
如果啟用了規則模式，本地網站維持直接連線，而指定目標經過線路，兩者並不矛盾，這正是分流預期的結果。判斷是否生效時，要比較規則意圖與實際路徑，而不是要求所有請求都顯示相同出口。對於明確排除的區域網路資源，也應確認它們仍能透過本地網路存取。
最後可以中斷連線並重新連線一次，檢查結果能否穩定重現。如果只有首次測試成功，重連後設定遺失，應繼續檢查系統權限、啟動項目、訂閱策略群組和網路介面設定。可重複的操作結果比單次頁面成功更具診斷價值。