如何確認 VPN 是否真正生效？先查出口 IP，再檢查 DNS，最後在目標應用程式中確認分流結果。連線圖示只能表示系統或用戶端建立了某種連線狀態，無法證明所有應用程式和網域都經過預期線路。判斷標準應是：需要代理的請求走代理，需要直連的請求則依規則直連。
先建立連線前後的對照
先暫停下載、同步等背景工作，記下目前的網路、用戶端模式及準備測試的應用程式。如果正在遠端操作裝置，請勿直接中斷維持遠端連線的通道；應先安排可復原的操作方式。檢測期間盡量維持同一個網路，避免把切換網路造成的出口變化誤認為代理生效。
暫時中斷代理後，開啟可信任的公網 IP 查詢頁面，記下 IP 位址、電信業者和大致位置。重新連線用戶端，再用同一個頁面重新查詢。IP 位址屬於個人網路資訊，留存在本機即可，不必將完整結果貼到公開討論區。
在分流模式下，本地查詢頁面可能原本就依規則直連。因此，應選擇明確需要走代理的檢測目標，或暫時將該目標設為代理後再比較。用戶端中的「全域」通常只是把已交由用戶端處理的請求統一套用指定策略，不一定涵蓋整台裝置。
- 記下尚未連線時的公網出口，以及檢測頁面的網域。
- 確認訂閱已匯入、節點已選定，且代理或通道開關已開啟。
- 連線後重新載入頁面，確認位址變化及目標規則。
- 若要切換模式進行驗證，請先記下原有設定，完成後再還原。
把三個問題分開看。訂閱更新成功，只代表已取得設定；節點探測有回應，只代表探測請求收到回覆；目標應用程式的請求經過預期出口，才是驗證本次用途的關鍵。
確認出口 IP，不要只看地區文字
公網 IP 查詢頁面顯示的是存取該頁面之請求的來源。連線後位址有所變化，且用戶端連線紀錄顯示該網域符合代理策略，可據此判斷「這個瀏覽器的這次請求走了代理」，但不能直接推論其他應用程式也是如此。
地區資訊來自 IP 資料庫，更新可能較慢。節點名稱也可能代表入口或線路群組，不一定等於出口所在地。若地區資訊不一致，先比對其他可信任的查詢結果與線路說明；不要只憑城市標籤判斷線路失效。
| 觀察結果 | 可判斷的事項 | 接著檢查 |
|---|---|---|
| 瀏覽器出口已變更 | 該次檢測請求的出口已變更 | 目標應用程式是否也由用戶端接管 |
| 出口未變，規則設定為直連 | 可能是符合預期的分流結果 | 改測明確設定為走代理的目標 |
| 出口未變，規則設定為代理 | 請求路徑與預期不符 | 快取、系統代理、通道與繞過項目 |
| 出口已變，平台地區仍未變 | 網路出口並非平台唯一的判斷依據 | 帳號地區、定位權限與既有工作階段 |
| 不同 IP 位址類型的結果不一致 | 網路接管範圍可能不一致 | 用戶端對不同 IP 位址類型的路由支援 |
雙堆疊網路也要留意 IPv4 與 IPv6。瀏覽器可能優先使用其中一種連線，而用戶端只接管另一種。請使用能分別回報兩者結果的工具，並參考用戶端文件確認支援範圍。不要為了讓檢測頁面「全綠」就隨意關閉系統網路功能。
檢查 DNS 解析路徑，分辨洩漏與分流
DNS 負責將網域名稱解析為 IP 位址。DNS 檢測通常會讓瀏覽器存取測試網域，再觀察負責查詢的遞迴解析器。結果呈現的是解析器線索，並非裝置上每個應用程式的完整解析路徑，也無法直接證明所有請求內容的傳輸方式。
先確認預期路徑：如果目標網域應透過通道解析，查詢卻交由本地網路的解析器處理，就值得進一步排查；如果本地網域依規則直連並使用本地 DNS，則不一定是洩漏。關鍵在於實際路徑是否偏離明確設定的目標。
瀏覽器安全 DNS、系統加密 DNS 和用戶端 DNS 模組都可能參與解析。瀏覽器使用加密 DNS，不代表請求就一定經過代理；加密 DNS 也可以直接連線。若檢測結果出現公共解析服務名稱，應一併確認該解析請求的路由，不要只憑名稱就下安全結論。
- ✅ 查看用戶端是否接管 DNS，以及代理網域和直連網域分別採用哪種解析策略。
- ✅ 確認瀏覽器安全 DNS 與系統 DNS 設定，記下差異後逐項驗證。
- ✅ 變更設定後清除相關解析快取，或重新啟動測試應用程式，再觸發新的查詢。
- ❌ 不要把「解析器位於境外」直接等同於請求經過代理。
- ❌ 不要因為檢測頁面未發現異常，就認定整台裝置沒有任何流量繞過代理。
需要找出衝突原因時，每次只改一項設定再重新測試。若同時更換節點、瀏覽器和 DNS，就很難判斷是哪項變更發揮作用。檢測結果恢復預期後，請重新啟用暫時關閉的防護項目，並再做一次最終驗證。
逐一驗證應用程式，不要拿瀏覽器代表全部
瀏覽器正常、其他應用程式卻無法連線，常見原因是流量接管範圍不同。Windows 和 macOS 上的系統代理通常只影響遵循系統代理設定的程式；忽略該設定、使用內建代理或直接建立網路連線的程式，可能會走不同路徑。
TUN 等虛擬網卡方式可接管更多流量，但仍會受到路由、排除項目、權限和用戶端實作方式影響。「全域規則」和「TUN 接管」不是同一個開關。前者決定已進入用戶端的請求如何處理，後者則關乎哪些流量能進入用戶端。
Android 用戶端可能提供分應用程式的包含或排除清單。請確認目前清單的設定意義：勾選的應用程式是「走代理」，還是「不走代理」。iOS 個人 VPN 設定與受管理裝置的依應用程式 VPN 並不相同，不能假設所有用戶端都能任意選擇要處理的應用程式。可用功能應以目前用戶端和系統提供的選項為準。
在目標應用程式中重新測試實際操作
先完全關閉目標應用程式，再重新開啟並執行需要連網的操作，例如重新整理內容、搜尋資料或載入媒體。只看到舊頁面不算驗證成功，因為內容可能來自快取。接著查看用戶端是否出現對應連線、命中哪條規則，以及使用哪個策略群組。
部分應用程式會連線至多個網域，成功登入不代表媒體請求也能正常運作。應分別測試登入、內容清單和實際播放。平台也可能依據帳號地區、付款地區、裝置定位和過往工作階段判斷可觀看內容，因此應針對目標平台進行驗證，不要無條件認定內容一定可用。
用戶端的本機連線紀錄有助於確認規則，但可能包含瀏覽過的網域；排查完成後，可視需要關閉暫時啟用的詳細紀錄。若要提供資料給支援人員，請隱藏訂閱連結、憑證和無關的存取紀錄。
排除「看起來已連線」的常見情況
已匯入訂閱，但尚未啟用設定
訂閱連結是取得節點與設定的入口，本身並不代表已建立連線。請確認已匯入相容的用戶端、啟用設定，並選取可用策略。訂閱連結通常包含存取憑證，不應貼到公開檢測網站。使用 VPNPO 時，登入控制台後即可取得訂閱，用戶端下載權限以控制台顯示為準。
支援該協定，但流量接管方式不相符
Shadowsocks、VMess、Trojan、VLESS 等協定能否使用，取決於用戶端核心及其對特定設定的支援。協定名稱本身不代表已接管系統流量。匯入失敗時，先確認訂閱格式與核心相容性；若瀏覽器能用、其他應用程式卻不行，優先檢查代理模式和分應用程式規則。
把線路名稱當成生效證明
IEPL 專線、中轉與直連描述的是線路架構，不能取代終端驗證。中轉通常會經過額外入口轉送，直連通常不經過這類中轉入口；IEPL 標籤也無法單獨證明所有流量實際採用的傳輸方式。無論選擇哪種線路，都應確認出口、DNS 與應用程式請求。
瀏覽器擴充功能或其他網路工具接管了請求
瀏覽器代理擴充功能、其他 VPN 用戶端和企業網路工具都可能覆蓋設定。先保留必要連線，再依照各工具說明逐項排除衝突。如果瀏覽器出口已變更，但用戶端沒有相應連線紀錄，也要考慮瀏覽器使用了另一套代理，而非目前的用戶端已生效。
也要慎選檢測服務。查詢公網出口與 DNS 不需要提供訂閱連結、密碼或付款資訊。若頁面要求上傳完整設定檔，或安裝來源不明的憑證才能繼續，請停止操作。
進一步檢查斷線保護與瀏覽器流量繞行
如果使用情境要求代理中斷後停止連網，請確認用戶端是否提供斷線保護，並了解它與系統「永遠開啟 VPN」等設定的適用範圍。儲存工作後，在可控環境中主動中斷連線，觀察目標應用程式是否仍能發出新的外部請求，再重新連線測試。
瀏覽器 WebRTC 檢測可能會顯示區域網路位址、經過隱藏處理的主機名稱，或公網候選位址。出現區域網路位址，不代表實際公網出口已暴露；若出現原本不應直接外露的公網位址，則需進一步確認瀏覽器策略、UDP 路由及用戶端接管範圍。
公網出口變更，也不代表帳號身分隨之消失。目標服務仍可使用登入狀態、Cookie 和裝置權限。VPNPO 的隱私政策是不記錄日誌，但這是服務政策，不能取代終端設定檢查，也無法證明目標網站不會記錄其收到的存取請求。
結論：依請求驗證，不要依圖示判斷。先確認目標請求的出口，再檢查 DNS 路徑，最後逐一確認應用程式規則。結果一致時，可確認本次測試範圍內的代理行為符合預期；更換網路、用戶端設定或規則後，應重新驗證相關用途。
若仍無法找出問題，請整理系統與用戶端名稱、使用模式、異常應用程式、命中規則及已遮蔽敏感資訊的檢測差異，前往故障排除指南繼續檢查，或透過支援頁面回報問題。說明「哪一項請求未依預期傳輸」，通常比只寫「已連線但無法使用」更容易縮小問題範圍。