VPN 連線卻沒生效，不能只看用戶端顯示的「已連線」。這個狀態通常只代表用戶端已與遠端節點完成交握，或本機代理埠已啟動，並不能直接證明瀏覽器、命令列工具與其他應用程式的流量都經過目標線路。可靠的判斷方式是依序檢查出口 IP、DNS 解析、IPv6 路徑與分應用規則。
排查時不要頻繁切換節點、協定與系統設定。一次只修改一個變數，再重複相同測試，才能分辨是節點、路由，還是某個應用程式繞過代理。以下方法適用於常見的系統 VPN、系統代理、TUN 模式，以及使用 Shadowsocks、VMess、Trojan、VLESS、Hysteria2 或 TUIC 設定的用戶端。
為什麼「已連線」仍可能沒生效
用戶端建立連線後，還需要將流量送進對應的通道或本機代理埠。這個過程涉及系統代理、路由表、虛擬網卡、DNS 設定與應用程式本身的網路實作。任何一環未成功接管，都可能出現「用戶端顯示正常，但存取結果沒有改變」。
不同連線模式的涵蓋範圍並不相同。系統代理主要影響會讀取系統代理設定的應用程式，瀏覽器通常會讀取，但部分命令列程式、遊戲、下載工具或自行實作網路堆疊的軟體可能忽略它。TUN 模式透過虛擬網卡處理更廣泛的 IP 流量，但仍會受到路由排除項目、區域網路繞過、分流規則與系統權限影響。
| 表面現象 | 實際可能發生的情況 | 優先檢查項目 |
|---|---|---|
| 用戶端顯示已連線 | 只完成節點交握，應用程式未使用本機代理或通道路由 | 出口 IP、系統代理、TUN 狀態 |
| 瀏覽器生效，其他應用程式未生效 | 瀏覽器讀取了系統代理，其他應用程式直接連線 | 分應用規則、應用程式代理設定、TUN 模式 |
| 網頁出口改變，但解析異常 | 網頁流量經過節點，DNS 仍由本地網路處理或使用快取 | DNS 模式、快取、用戶端記錄 |
| 部分網站路徑異常 | 網域規則、IP 規則或 IPv6 路徑與預期不同 | 規則命中記錄、IPv6、路由策略 |
| 切換節點後結果不變 | 檢測頁面被快取，或目前應用程式未進入代理路徑 | 重新載入、換用應用程式複測、檢查路由 |
協定名稱本身也不能證明涵蓋範圍。Shadowsocks、VMess、Trojan、VLESS、Hysteria2 與 TUIC 描述的是用戶端與節點之間傳輸資料的方式。應用程式流量是否進入這條連線，仍由本機監聽埠、系統代理、TUN 與路由規則決定。協定成功交握與全域流量接管是兩回事。
先記錄未連線時的網路基準
要判斷是否發生變化，必須先知道未連線時的狀態。關閉用戶端連線，確認系統代理與 TUN 已恢復，接著記錄目前的出口 IP、網路業者資訊、IP 類型與大致地區。可以開啟本站的 IP 檢測頁面完成這一步。
基準測試應使用之後要驗證的同一個應用程式。如果要檢查瀏覽器，就在該瀏覽器中記錄；若問題出在命令列工具，也需要從命令列單獨測試。瀏覽器結果不能取代其他應用程式，因為兩者可能使用不同的代理設定。
- ✅ 中斷目前連線，並確認用戶端不再佔用系統代理或虛擬網卡。
- ✅ 在目標應用程式中開啟 IP 檢測頁面，記錄出口 IP、IP 類型與地區。
- ✅ 關閉可能改變網路路徑的其他代理擴充功能或並行用戶端。
- ✅ 維持目前的連線網路不變，避免在測試過程中切換有線、無線或其他網路。
- ✅ 重新連線至目標節點後，使用相同應用程式與相同檢測頁面再次測試。
如果中斷連線後仍顯示節點出口，表示系統代理、瀏覽器擴充功能、虛擬網卡或背景程序可能尚未恢復。此時繼續進行連線測試沒有意義，因為基準已被舊設定污染。應先退出相關用戶端，檢查系統網路設定，再重新建立基準。
檢查出口 IP：確認網頁流量走向
完成基準後連線至目標節點，再次開啟 IP 檢測頁面。為減少快取干擾，可以重新載入頁面，或使用新的瀏覽器分頁。若出口 IP 從本地網路位址變為節點出口，且網路歸屬與所選線路相符，即可確認這個瀏覽器分頁的網頁請求已經經過代理路徑。
出口 IP 變化是最直接的證據，但只能證明目前這次檢測請求的路徑。瀏覽器擴充功能可能只代理瀏覽器；系統代理可能只被部分程式讀取；分流規則也可能讓檢測網站經過節點，而其他網域維持直接連線。因此還要繼續檢查實際發生問題的應用程式與目標網域。
出口 IP 沒有變化時如何排查
- 查看用戶端是否只啟動了本機代理埠，卻沒有自動寫入系統代理設定。
- 確認瀏覽器沒有設定獨立代理。獨立設定可能覆蓋系統設定，也可能指向已失效的舊埠。
- 檢查用戶端目前的模式。規則模式可能將檢測網域判定為直接連線，可暫時使用涵蓋範圍更明確的模式進行診斷。
- 如果使用 TUN，請檢查虛擬網卡是否成功建立，以及用戶端是否取得修改路由所需的系統權限。
- 查看執行記錄，確認請求是否命中代理規則、直接連線規則或拒絕規則。
用戶端從訂閱連結匯入設定後，通常會取得節點參數與分組規則，但匯入成功不等於系統代理已啟用。有些用戶端會將「更新訂閱」、「選擇節點」、「啟動本機服務」與「設為系統代理」分成獨立操作。排查時應確認這些狀態，而不是反覆重新匯入訂閱。
出口 IP 變化後仍無法開啟目標服務
這時問題已從「是否經過代理」縮小為「這條路徑是否適合目標請求」。可能原因包括 DNS 回應異常、目標服務限制特定出口網路、分流導致相關子網域走不同路徑，或瀏覽器保留了舊連線。先不要繼續切換協定，應檢查 DNS、規則命中與應用程式記錄。
檢查 DNS：判斷網域解析經過哪條路徑
存取網站前，系統通常需要先將網域解析為 IP 位址。網頁連線經過節點，不代表 DNS 查詢一定沿著相同路徑傳送。如果 DNS 仍交由本地網路處理，可能出現解析結果與節點地區不符、部分網域回應異常，或網域請求暴露給本地解析服務的情況。
DNS 排查不能只看系統介面填寫了哪台伺服器。許多系統會使用本地存根解析器，用戶端也可能接管查詢、回傳虛擬位址，或將查詢封裝進通道。介面中出現本地位址不必然代表洩漏；關鍵在於用戶端記錄中的處理方式，以及最後由哪一方完成遞迴解析。
瀏覽器與系統 DNS 可能不同
現代瀏覽器可以啟用自己的加密 DNS。啟用後，瀏覽器的解析路徑可能與作業系統不同。因此可能出現命令列查詢正常、瀏覽器仍異常，或瀏覽器正常、其他應用程式仍使用本地網路解析器的情況。排查時需要分別測試，不要用單一結果代表整個系統。
可以在終端機查詢一個尚未快取的目標網域，並同時觀察用戶端記錄。Windows 常用 nslookup，macOS 與 Linux 可使用 dig 或 nslookup。命令輸出負責顯示解析結果，用戶端記錄則說明請求是否被接管、轉送或依規則直接連線。
nslookup example.com
dig example.com
nslookup example.com 指定的解析服務最後一行中的「指定的解析服務」應替換為實際準備測試的伺服器位址。不要把公共解析服務本身當成代理。DNS 只負責解析網域，不會自動改變網頁連線的出口。
避免 DNS 快取造成誤判
系統、瀏覽器與用戶端都可能快取解析結果。切換節點後立即查詢相同網域，看到的可能仍是舊回應。較穩妥的做法是關閉相關分頁、清除應用程式內的 DNS 快取，重新連線後再查詢。若不熟悉系統清除快取的命令，可以重新啟動目標應用程式；不要隨意刪除未知的網路設定。
- ✅ 出口 IP 已變化，再開始檢查 DNS，避免兩個問題同時干擾。
- ✅ 分別測試瀏覽器與系統命令列，確認是否只有單一應用程式異常。
- ✅ 查看用戶端記錄，確認 DNS 請求命中了代理解析還是直接解析。
- ✅ 檢查瀏覽器是否啟用了獨立的加密 DNS 設定。
- ❌ 不要僅因系統介面顯示本地存根位址，就直接判定發生 DNS 洩漏。
- ❌ 不要把網域能夠解析，等同於網頁流量已進入通道。
檢查 IPv6 與分應用路由
部分網路同時提供 IPv4 與 IPv6。用戶端可能只接管其中一種，也可能依系統能力選擇不同路徑。如果 IPv4 經由節點，而 IPv6 維持本地直接連線，支援 IPv6 的網站可能優先使用未被接管的路徑，造成同一瀏覽器中不同網站的結果不一致。
檢查時應在 IP 檢測頁觀察目前暴露的是 IPv4、IPv6，還是兩者同時存在。如果只接管部分協定堆疊，應在用戶端啟用相應支援，或依用戶端文件調整 IPv6 策略。不要只在瀏覽器中隱藏結果，因為底層路由並未改變。
分應用代理的常見邊界
分應用功能通常透過納入或排除應用程式來決定路由。設定時容易混淆「只有選取的應用程式經過代理」與「選取的應用程式不經過代理」這兩種語意。更新用戶端後，應用程式路徑或程序名稱也可能改變，舊規則因此不再匹配。
瀏覽器還可能啟動多個輔助程序。將主程式加入規則，不一定能涵蓋由系統元件處理的請求。相對地，TUN 模式通常依網路流量與規則匹配，不完全取決於應用程式是否讀取代理設定，更適合檢查不支援系統代理的軟體。但 TUN 不代表無條件全域接管，區域網路、保留位址、直接連線網域與手動排除項目仍可能繞過代理。
| 接管方式 | 通常涵蓋的流量 | 容易遺漏的部分 | 適合的驗證方法 |
|---|---|---|---|
| 瀏覽器擴充功能 | 瀏覽器內由擴充功能處理的請求 | 其他應用程式、系統背景請求 | 分別檢查瀏覽器與命令列的出口 |
| 系統代理 | 遵循系統代理設定的應用程式 | 忽略系統代理的軟體、部分非網頁流量 | 逐一測試應用程式並查看記錄 |
| TUN 模式 | 進入虛擬網卡並符合路由規則的 IP 流量 | 排除路由、區域網路流量、未接管的協定堆疊 | 檢查路由、IPv6 與規則命中 |
| 應用程式內代理 | 該應用程式主動發往代理埠的請求 | 應用程式外流量、設定未涵蓋的連線 | 核對位址、埠號與應用程式記錄 |
從用戶端記錄定位連線層問題
如果出口與 DNS 都不符合預期，記錄比反覆切換節點更有效。記錄通常可以區分訂閱解析失敗、節點交握失敗、本機埠衝突、憑證或時間異常、路由寫入失敗，以及請求由哪條規則處理。閱讀時應從連線動作發生的時間點開始，避免受到較早的歷史錯誤干擾。
Shadowsocks、VMess、Trojan、VLESS、Hysteria2 與 TUIC 的交握方式不同，錯誤訊息也不完全一致，但排查順序相近：先確認設定完整，再確認節點可連線，接著確認本機監聽成功，最後查看目標請求是否進入對應的輸出。若交握成功但記錄中沒有目標請求，問題多半出在本機接管或分流規則，而不是遠端協定。
訂閱連結匯入失敗時，應先檢查連結是否完整、用戶端是否支援訂閱包含的設定格式，以及訂閱更新是否受到目前網路阻擋。成功匯入後還要選擇有效節點並啟動連線。只看到節點清單，不代表節點已被使用。
不同平台的檢查重點
Windows 上需要注意系統代理殘留、虛擬網卡狀態，以及應用程式是否使用 WinHTTP 或自有代理設定。macOS 上應核對目前網路服務的代理設定，並確認系統延伸功能或網路延伸功能取得所需權限。Linux 的桌面代理設定與終端機環境變數可能彼此獨立，瀏覽器生效不代表終端機命令也生效。
行動平台通常由系統 VPN 介面統一承載流量，但省電策略、依應用程式設定 VPN、永遠開啟連線與區域網路存取設定仍會改變結果。若背景恢復後失效，應重新開啟用戶端查看通道狀態與最近記錄，而不是只看狀態列圖示。
幾種「看似連上」的常見情況
瀏覽器正常，下載工具仍使用本地出口
這通常是系統代理涵蓋範圍的問題。瀏覽器讀取系統代理，而下載工具使用直接連線的網路堆疊。應檢查下載工具是否支援代理，或使用能涵蓋這類流量的 TUN 模式，再分別驗證兩個應用程式的出口。
切換節點後網頁地區沒有變化
先排除頁面快取與舊連線重用，再檢查規則模式是否讓檢測網域直接連線。如果記錄中沒有檢測請求，表示瀏覽器可能未進入目前的用戶端。若記錄顯示請求已經經過新節點，但地理資訊未更新，應以出口 IP 與網路歸屬為主，不要只看地區文字。
啟用連線後完全無法存取網路
如果啟用了斷線保護或類似的阻擋策略，節點交握失敗時，本地直接連線也可能被主動阻止。這種情況並非「流量偷偷直接連線」，而是保護規則在連線不可用時停止放行。應查看交握錯誤、本機時間、網路權限與節點可連線性。
只有部分網域連線失敗
優先檢查網域分流、DNS 回應結果與相關子網域。一項服務可能使用多個網域，主站與介面請求可能命中不同規則。只將主網域加入代理清單，不能保證所有資源都使用相同路徑。記錄中的規則命中資訊通常能直接指出差異。
直接連線、一般中轉與 IEPL 專線的結果不同
直接連線表示裝置直接連接遠端節點，路徑會受到公網路由影響。一般中轉會先連接中轉入口，再轉送至出口。IEPL 專線通常將入口與出口之間的傳輸放在專用鏈路中，但使用者到入口、出口到目標服務仍是完整路徑的一部分。線路類型會影響路由穩定性，卻不能取代本機代理與 DNS 檢查。即使使用專線，本機應用程式未進入通道，出口仍不會改變。
一套可重複執行的驗證順序
完整排查不需要同時修改大量設定。以下順序從最容易觀察的現象開始，逐步深入系統與用戶端內部。每完成一步都記錄結果；一旦發現異常，就停在該層處理，不必提前調整後面的協定參數。
- 中斷連線，記錄目標應用程式的出口 IP、IP 類型與網路歸屬，建立基準。
- 連線至目標節點，在同一個應用程式中重新檢測出口，確認請求是否改變路徑。
- 使用瀏覽器與系統工具分別檢查 DNS，結合用戶端記錄判斷解析方式。
- 檢查 IPv4 與 IPv6 是否都依預期被接管，避免雙堆疊環境出現路徑分離。
- 在實際發生問題的應用程式中重複測試，確認系統代理、TUN 或應用程式內代理的涵蓋範圍。
- 查看規則命中與輸出記錄，區分直接連線、代理、拒絕與解析錯誤。
- 最後再切換節點或協定，並維持其他條件不變，以便比較變化來源。
如果問題仍然存在，可以在用戶端內整理連線時間、平台、連線模式、協定類型、錯誤記錄與已完成的檢查項目，再透過站內 FAQ 或故障支援管道繼續定位。明確說明「哪個應用程式、哪個網域、出口是否變化、DNS 如何處理」，比只描述「連不上」更容易找到故障層級。