確認是否生效：連線狀態不是最終證據
VPN 連線後如何確認是否生效？先檢查出口 IP，再查 DNS，最後逐一驗證各應用程式。只有目標應用程式的新請求確實符合預期路徑，才能判定該應用程式已生效；用戶端的連線圖示只能表示某個連線環節已建立。
代理用戶端可能只是啟動本機監聽，也可能已完成遠端交握，但尚未接管瀏覽器以外的流量。規則模式也可能刻意讓部分網站直連。因此，「所有查詢結果都必須改變」並不是正確的判斷標準。應先明確設定預期：哪個應用程式、要連線哪個網域，以及應該直連還是經由代理。
如何比對連線前後的出口 IP
使用同一個可信任的公網 IP 查詢工具進行比對。連線前記下 IP 位址、位址族，以及電信業者或網路歸屬；連線後重新查詢。請勿把裝置設定中的區域網路位址當成公網出口，也不要只憑地圖顯示的城市名稱判斷。
- 建立基準。中斷連線，確認沒有其他代理擴充功能接管瀏覽器，再查詢公網 IP。記下目前使用的網路，避免測試期間切換網路而造成誤判。
- 連線至目標節點。確認用戶端目前的模式，以及查詢網站應命中的規則。如果規則原本就要求該網站直連，出口沒有變化並不代表發生故障。
- 重新送出請求。重新開啟查詢頁面並重新整理結果，同時查看用戶端的連線清單。必要時重新啟動瀏覽器，排除沿用既有連線的影響。
- 交叉比對。改用不同的查詢來源，比較 IP 位址和網路歸屬。地理資料庫的更新時間可能不同，城市標籤不一致不能單獨證明節點位置異常。
如果目前的網路同時支援 IPv4 和 IPv6，請分別確認兩者的流量路徑。若只代理其中一種位址族，網站可能優先透過另一種位址族連線。因此，某個查詢頁面顯示出口已變更，但另一個應用程式仍直連，兩者並不矛盾。
DNS 檢查：確認解析路徑，不只看地區
DNS 負責將網域名稱解析為可連線的 IP 位址。網站請求經過代理，不代表 DNS 查詢也一定走相同路徑。一般所說的 DNS 洩漏，是指原本應受通道或代理政策限制的解析請求，卻經由預期之外的本地網路或解析服務送出。
執行 DNS 檢測時，工具通常會產生測試網域，再根據收到查詢的遞迴解析器推測解析路徑。頁面顯示的是解析服務的相關資訊，不一定是裝置直接連線的那台伺服器，也不是裝置公網出口的另一種表示方式。
- 先記錄連線前的結果。保存解析服務的名稱和網路歸屬，方便連線後比對。
- 檢查用戶端設定。確認是否啟用 DNS 接管、遠端解析或依規則選擇解析器；不同用戶端的功能名稱可能不同。
- 檢查瀏覽器安全 DNS。瀏覽器可能使用獨立的加密 DNS 服務，而不沿用系統解析設定。若結果與用戶端不同，應進一步確認連線路徑。
- 測試新的網域請求。既有快取可能讓請求不再觸發 DNS 解析；依照系統或用戶端文件清除快取後，再重新檢測。
解析器所在區域與節點所在區域不同，不代表發生 DNS 洩漏。公共解析服務可能使用任播網路，檢測資料庫也可能只標示服務商的登記地點。反過來說，解析器顯示位於目標區域，也不能證明所有應用程式流量都經由代理。關鍵在於解析器是否符合設定，以及 DNS 請求實際如何送出。
逐一驗證應用程式：瀏覽器通過不代表全部通過
系統代理通常是一組供應用程式讀取的代理設定。應用程式是否採用，取決於其本身的實作方式。瀏覽器、命令列工具、聊天應用程式和遊戲可能各自使用不同的網路路徑；瀏覽器擴充功能也可能只接管目前的瀏覽器。
虛擬網卡模式常稱為 TUN。它會透過系統路由接收符合條件的流量，再交由用戶端處理，涵蓋範圍通常較廣，但仍會受到排除路由、權限、程序規則和位址族設定影響。啟用 TUN 也不能取代實際驗證。
| 接管方式 | 常見限制 | 驗證重點 |
|---|---|---|
| 瀏覽器代理擴充功能 | 通常只影響該瀏覽器中的請求 | 檢查擴充功能規則，並另外測試桌面應用程式 |
| 系統代理 | 應用程式可能忽略系統設定，或使用獨立代理 | 確認應用程式設定與用戶端的新連線紀錄 |
| 虛擬網卡模式 | 仍可能有排除路由或程序繞過代理 | 檢查權限、路由、DNS 接管與位址族 |
| 應用程式內建代理 | 通常只影響該應用程式中支援代理的功能 | 分別測試登入、內容載入與即時通訊 |
讓目標應用程式送出可辨識的新請求
先開啟用戶端連線清單，再啟動目標應用程式，並執行重新整理內容、載入新頁面或重新連線等操作。依時間、網域或程序尋找相符紀錄，查看命中的規則、出口策略與錯誤訊息。並非所有平台都會顯示應用程式程序資訊；若看不到程序名稱，可用請求時間和目標網域協助比對。
如果沒有紀錄，先排除沿用舊連線、快取命中和日誌篩選的影響，不要直接判定流量發生洩漏。若出現明確的直連紀錄，再檢查是否命中直連規則、應用程式排除項或獨立代理設定。流量計數增加本身，不能證明增加的流量來自正在測試的應用程式。
如何處理平台差異
在 Windows 和 macOS 上，應分別確認系統代理與虛擬網卡模式；Linux 桌面環境的代理設定也不一定會傳遞給命令列程式。Android 用戶端可能設有應用程式包含或排除清單。iOS 則應檢查實際使用的用戶端設定和系統 VPN 狀態，不要直接套用桌面版的操作選單。具體設定位置請以用戶端文件和目前介面為準。
看似已連線，實際未經代理的常見原因
已匯入訂閱，但尚未切換執行中的設定
訂閱連結是取得節點和相關設定的入口，不是接管流量的開關。更新訂閱後，仍須確認目前啟用的設定、選取的節點和代理模式。有些用戶端會儲存新設定，卻繼續執行原本的設定。
規則判斷結果與預期不同
規則可能依據網域、目標位址或程序決定流量路徑，通常依照用戶端規定的優先順序比對。應用程式登入和內容載入也可能使用不同網域。如果「可以登入但內容無法開啟」，應分別檢查失敗的請求，不要只加入應用程式首頁的網域，就認為已涵蓋所有功能。
舊連線、其他代理或權限造成干擾
切換節點不保證既有長連線會立即改道。可以先讓目標應用程式重新連線，再觀察新的連線。如果同時執行其他 VPN、代理擴充功能或企業網路用戶端，也可能發生設定遭覆寫、路由競爭或存取受限。請只在有權調整的環境中逐項排查，不要擅自停用組織要求的安全設定。
不要混淆線路類型與流量接管
IEPL 專線、中轉和直連描述的是線路路徑或組織方式，並不決定本機應用程式是否進入代理。Shadowsocks、VMess、Trojan、VLESS、Hysteria2、TUIC 等協定，也不能取代規則與路由檢查。換用其他線路可能改變連線狀況，卻不會自動修正應用程式繞過代理的問題。
隱私界線：檢測通過不代表匿名有保障
出口檢查能顯示某次請求對外呈現的位址，DNS 檢查則有助於了解解析路徑，但兩者都不是完整的隱私稽核。已登入的帳戶、網站 Cookie、裝置特徵，以及應用程式主動提供的資訊，仍可能讓瀏覽行為與使用者產生關聯。匿名和無日誌是服務的隱私政策聲明，無法透過單次 IP 查詢證明。
瀏覽器的 WebRTC 檢測也要搭配情境判讀。頁面顯示本機介面資訊、經過隱私處理的主機名稱或公網候選位址，各有不同意義；不能把所有位址欄位都當成公網出口洩漏。如果出現不符合預期的公網位址，應一併檢查瀏覽器政策和用戶端對 UDP 流量的接管狀況。
提交排障資料時，保留模式、規則名稱、錯誤時間和必要的目標網域即可。分享截圖前，請遮蔽訂閱連結、存取權杖、帳戶資訊和無關的瀏覽紀錄。訂閱連結可能包含驗證資訊，不應貼到公開的檢測頁面或討論區。
檢查清單與結果判斷
- ✅ 已記錄未連線時的公網出口，並在相同網路下比對連線後的結果。
- ✅ 已確認查詢網站命中的規則，而非預設它一定會經過代理。
- ✅ 已檢查目前可用的位址族，並確認 DNS 與瀏覽器安全 DNS 的設定。
- ✅ 已讓目標應用程式送出新請求，並在用戶端確認相應的連線路徑。
- ✅ 已區分舊連線、快取命中、應用程式獨立設定與真正的直連繞過。
- ✅ 已保存必要的排障資訊，且未公開訂閱憑證。
如果仍無法找出原因，可先依照使用教學確認匯入與接管設定，再前往支援頁面提交已去識別化的連線紀錄。如果路徑已符合預期，但目標平台仍拒絕存取，請繼續確認平台的地區政策、帳戶資格和目前出口判定，不要把所有存取失敗都歸因於線路未生效。