如何確認 VPN 是否正常運作，不能只看用戶端是否顯示「已連線」。這個狀態通常只能表示本機用戶端完成交握，或已建立通往入口節點的工作階段；無法直接證明瀏覽器、命令列工具和其他應用程式都在使用該路線。可靠的方法是保存連線前的網路基準，再依序核對出口 IP、DNS 解析路徑，以及指定應用程式的實際流量。
檢查前也要先釐清預期結果。全域代理應讓大部分公網流量經過選定出口；規則分流只處理符合規則的請求；分應用程式模式則只接管指定程式。三種模式的正確結果不同。若把分流狀態誤當成全域狀態，常會出現「瀏覽器已變更，但其他程式沒有變化」的表象，而這不一定代表故障。
先建立連線前後的可比基準
排查的重點不是觀察某個孤立結果，而是比較同一台裝置、同一個網路，以及同一個檢測入口在連線前後的差異。開始前先關閉舊的代理擴充功能、退出其他網路工具，並確認系統時間正常。接著記錄未連線時的公網出口地區、網路業者歸屬與 DNS 解析結果。完成連線後，再使用同一個檢測頁面重複檢查。
VPNFe 的 IP 檢測頁面可用來查看目前的網路出口。核對時不必執著於某個地址長期不變，因為節點調度、出口池切換與網路重新連線都可能造成地址變化。更重要的是出口歸屬是否符合所選地區，以及中斷路線後是否恢復至原本的網路。
| 核對項目 | 連線前記錄 | 連線後預期結果 | 異常線索 |
|---|---|---|---|
| 公網出口 IP | 目前接入網路的出口 | 變為所選路線的出口 | 地址與歸屬完全沒有變化 |
| 出口地區 | 本地接入地區 | 與節點目標地區一致 | 顯示非預期地區或頻繁跳動 |
| DNS 解析路徑 | 本地網路的預設解析路徑 | 符合用戶端的 DNS 與分流設定 | 查詢仍固定交由本地網路處理 |
| 指定應用程式 | 直連存取結果 | 符合全域、規則或分應用程式策略 | 只有部分程式發生變化 |
- 中斷所有路線，記錄目前的出口歸屬與 DNS 結果。
- 清除可能影響判斷的瀏覽器代理擴充功能，並關閉檢測頁面的舊分頁。
- 連線至目標路線，等待用戶端狀態穩定後重新開啟檢測頁面。
- 比較出口、DNS 與應用程式行為，不要只比較頁面能否載入。
- 中斷路線後再測試一次，確認結果能恢復至基準。
第一步：確認出口 IP 是否確實變更
出口 IP 是外部服務所看到的請求來源。若路線已生效，檢測網站通常會看到遠端節點的出口，而不是本地接入網路的公網出口。此處應同時查看地址、網路歸屬與地區，不能只看地圖標籤。地理資料庫可能有更新延遲，同一個出口在不同資料庫中也可能顯示為鄰近城市，因此城市名稱不是唯一判斷依據。
使用不同入口複核結果
瀏覽器可能保留頁面快取，也可能啟用了獨立的代理擴充功能。比較結果時應開啟新分頁並強制重新整理，再使用另一個未安裝代理擴充功能的瀏覽器複核。如果兩個瀏覽器的結果不同，問題多半出在瀏覽器擴充功能、瀏覽器專用 DNS 或系統代理的繼承方式，而不是節點本身。
命令列程式也值得單獨驗證。部分用戶端只設定系統代理，而命令列工具不一定會讀取該設定；另一些用戶端啟用 TUN 後，會在系統路由層接管更多流量。若瀏覽器顯示目標出口，但終端機請求仍顯示本地出口，應先檢查用戶端目前使用的是系統代理、TUN，還是僅限瀏覽器擴充功能模式。
- ✅ 連線前後使用同一個檢測入口，結果才具備可比性。
- ✅ 出口歸屬與所選路線一致，中斷後能夠恢復。
- ✅ 瀏覽器與需要使用路線的應用程式分別完成檢查。
- ❌ 只看到用戶端顯示已連線，就直接判定所有流量都已生效。
- ❌ 只因城市標籤不同，就判斷路線一定有問題。
第二步：確認 DNS 是否沿預期路徑解析
DNS 負責將網域名稱轉換為可連線的地址。即使網頁請求經過遠端出口，網域查詢仍可能由本地網路解析，這種路徑不一致通常稱為 DNS 洩漏。它可能暴露正在查詢的網域，也可能讓內容傳遞網路回傳不適合目前出口的地址，造成網頁速度緩慢、地區判斷衝突或部分資源載入失敗。
但不能只因解析伺服器顯示在本地附近，就立即認定發生洩漏。公共 DNS 可能採用任播調度，檢測資料庫也可能只記錄業者主體，無法準確反映查詢路徑。更穩妥的判斷方式，是比較連線前後的解析服務歸屬，並結合用戶端 DNS 設定、瀏覽器安全 DNS 設定與分流規則共同確認。
瀏覽器安全 DNS 可能繞過用戶端設定
部分瀏覽器會自行傳送加密 DNS 請求。若用戶端只接管系統 DNS，這類請求可能繼續傳送至瀏覽器指定的解析服務。結果是系統檢測正常，但瀏覽器中的 DNS 結果與預期不同。排查時可以暫時讓瀏覽器跟隨系統設定，再重新測試；若結果恢復一致，就應繼續核對瀏覽器設定，而不是反覆更換節點。
分流 DNS 需要同步檢查網域規則
成熟的規則模式可能為直連網域與代理網域採用不同的解析路徑。這不代表發生洩漏，而是刻意設計的 DNS 分流。判斷標準是：需要經過國際路線的網域是否由對應路徑解析，直連網域是否維持本地解析，以及解析後的連線是否仍遵循同一組規則。若網域查詢經由代理，實際連線卻被規則判定為直連，也會出現路徑不一致。
- ✅ 比較連線前後的 DNS 歸屬，不依賴單次檢測結果。
- ✅ 檢查瀏覽器安全 DNS 是否覆蓋系統設定。
- ✅ 在規則模式下分別驗證代理網域與直連網域。
- ❌ 把解析伺服器的城市標籤當作唯一判斷依據。
- ❌ 修改多項 DNS 與代理設定後一次重新測試，導致無法定位變因。
第三步：依序驗證瀏覽器、終端機與指定應用程式
不同應用程式讀取網路設定的方式並不一致。瀏覽器通常會繼承系統代理，但也可能由擴充功能覆寫；命令列工具可能只讀取環境變數；遊戲、會議軟體與同步程式可能直接建立 UDP 連線；部分程式還會固定使用自己的 DNS，或繞過系統代理。因此，「瀏覽器已生效」不能推導出「所有應用程式都已生效」。
驗證時應先寫清楚目標：某個應用程式需要全程使用路線，還是只有特定網域需要分流。接著維持其他變因不變，啟動該應用程式執行一次可觀察的網路操作。可以結合用戶端連線記錄、規則命中記錄與出口檢測結果進行判斷。記錄應關注請求是否命中代理、直連、阻擋或兜底規則，不要把「本機連接埠已建立」誤認為遠端請求成功。
系統代理與 TUN 的涵蓋範圍不同
系統代理通常適合遵循作業系統代理介面的 HTTP 與 HTTPS 應用程式。它設定清楚、變更較少，但不保證能接管所有程式。TUN 模式透過虛擬網路介面處理更廣泛的 IP 流量，適合需要統一分流的情境；同時也更依賴系統權限、路由表與 DNS 設定。兩者沒有絕對優劣，應依應用程式的涵蓋範圍選擇。
分應用程式模式要檢查排除清單
行動平台與部分桌面用戶端支援按應用程式選擇。若目標程式未加入接管清單，或被放入排除清單，就會繼續直連。反過來，若原本應直連的本地服務被納入代理，也可能造成存取失敗。檢查清單時應確認應用程式識別資訊對應目前安裝的版本，調整後再完全退出應用程式並重新開啟，避免舊連線持續被重用。
| 對象 | 常見接管方式 | 驗證重點 | 常見偏差 |
|---|---|---|---|
| 瀏覽器 | 系統代理、擴充功能或 TUN | 出口、瀏覽器 DNS、擴充功能優先順序 | 擴充功能覆寫系統代理 |
| 命令列工具 | 環境變數、明確代理或 TUN | 程序是否讀取代理設定 | 瀏覽器生效但終端機直連 |
| 桌面應用程式 | 系統代理、應用程式內代理或 TUN | 協定類型與規則命中 | 應用程式繞過系統代理 |
| 行動應用程式 | 系統 VPN 介面與分應用程式策略 | 接管清單、背景限制、舊連線 | 目標應用程式位於排除清單 |
看似已連線但流量未經預期路徑的常見原因
用戶端成功連線，只代表本機與入口節點之間可能已建立工作階段。後續流量還會經過訂閱設定、節點參數、路由規則、DNS、系統權限與應用程式本身的設定。任何一層不一致，都可能出現「狀態正常但存取路徑錯誤」。排查應從影響範圍最小、最容易驗證的項目開始。
訂閱已匯入，但目前設定不是最新版本
訂閱連結用於取得節點與規則設定。匯入成功不代表後續自動更新一定完成；用戶端可能仍在使用舊節點、舊憑證資訊或舊規則。先手動更新訂閱，再確認目前選取的設定確實來自更新後的群組。更新失敗時應查看錯誤提示，不要連續重複匯入同一個訂閱，以免產生多個名稱相近的設定。
協定可以連線，但傳輸參數不相容
Shadowsocks、VMess、Trojan、VLESS、Hysteria2 與 TUIC 是不同的代理協定或傳輸方案，設定欄位不能互相套用。Shadowsocks 需要匹配加密方式與憑證；VMess、Trojan 和 VLESS 還可能依賴傳輸層、TLS 與伺服器名稱等參數；Hysteria2 和 TUIC 主要基於 UDP 傳輸，網路環境若限制 UDP，表現可能與基於 TCP 的方案不同。
協定名稱本身不能證明連線品質。真正需要檢查的是用戶端是否支援該協定、設定是否完整、交握是否成功，以及實際請求是否進入對應的出站。若更新用戶端後才出現問題，也應核對設定格式是否正確遷移。
規則優先順序讓檢測請求採用直連
分流通常依照從具體到兜底的順序，比對網域、地址、程序或地區規則。若前面的直連規則涵蓋範圍過大，後面的代理規則就不會執行。反之，過寬的代理規則也可能接管原本應直連的服務。查看記錄時應找出目標請求實際命中的規則，而不是只看規則檔案中「存在一條代理規則」。
中繼、直連與 IEPL 被混為同一層概念
直連通常指用戶端直接連線至遠端節點；中繼路線會先連線至較近的入口，再由中繼轉送至目標出口；IEPL 專線描述的是入口與遠端之間的專線傳輸形式。它們屬於承載路徑，不等同於 Shadowsocks、VLESS 等應用層代理協定。檢查是否生效時，最終仍應查看公網出口與規則命中，不能因設定名稱含有「中繼」或「專線」就預設流量已經抵達目標出口。
各平台應重點檢查哪些位置
Windows 上先區分系統代理與 TUN。系統代理生效時，遵循系統設定的應用程式通常會切換出口，但部分程式仍可能直連；TUN 異常時則應檢查虛擬網路介面、路由衝突與權限。若裝置同時執行其他網路元件，應暫時退出後重新建立基準。
macOS 用戶端通常透過網路延伸功能或系統代理接管流量。首次啟用網路延伸功能時，若尚未確認系統權限，用戶端介面可能仍保留設定，卻無法完整接管流量。可在系統網路設定中確認對應設定已啟用，再分別測試瀏覽器與終端機。只關閉視窗通常不等於退出背景網路延伸功能。
Android 與 iOS 主要透過系統 VPN 介面運作。排查重點包括分應用程式清單、系統的背景限制、自動連線策略，以及應用程式是否重用了連線前建立的工作階段。切換路線後若只有某個應用程式的結果不變，應先完全結束該應用程式再重新開啟，不要立即判斷節點失效。
Linux 環境差異較大。桌面應用程式可能讀取系統代理，終端程式可能依賴環境變數，而服務程序又可能擁有獨立的執行環境。啟用 TUN 時還要檢查路由表、DNS 管理服務與權限。驗證某個背景工作時，應以該工作實際執行的使用者與環境為準，互動式終端機中的測試結果不能直接代表服務程序。
- ✅ Windows：確認目前使用的是系統代理還是 TUN，並檢查虛擬介面狀態。
- ✅ macOS：確認網路延伸功能權限與系統網路設定已啟用。
- ✅ Android 與 iOS：檢查分應用程式策略，並重新啟動仍在重用舊連線的應用程式。
- ✅ Linux：分別核對桌面、終端機與服務程序的代理環境。
- ❌ 用一個瀏覽器的結果代表整台裝置的所有網路請求。
按照固定順序完成最終核對
一套可重現的排查流程，應能回答三件事：外部服務看到的出口是什麼、網域由哪條路徑解析，以及目標應用程式最終命中了哪條規則。若其中任何一項缺乏證據，就只能表示「可能已連線」，還不能確認完整生效。
- 中斷路線並記錄出口與 DNS 基準。
- 更新訂閱，確認目前節點、協定與設定群組無誤。
- 連線至路線，透過同一個檢測入口比較公網出口。
- 核對系統 DNS、瀏覽器安全 DNS 與分流 DNS。
- 分別測試瀏覽器、終端機與目標應用程式。
- 查看用戶端記錄中的規則命中與出站結果。
- 中斷後再次檢測，確認網路恢復至原始基準。