如何確認 VPN 是否生效：一次檢查出口 IP 與 DNS

如何確認 VPN 是否生效？先比對出口 IP，再檢查 DNS，最後驗證目標應用程式。用戶端顯示「已連線」，只代表連線狀態，無法單憑這點證明所有要求都經過所選線路。檢查結果必須搭配目前的模式與分流規則判讀。

本文依照實際排查順序說明。重點不是讓檢測頁上的所有欄位都顯示相同地區，而是確認該經代理的要求確實經過代理、網域解析符合設定，直連要求也符合預期。

先確認「生效」的檢查範圍

系統通道、系統代理伺服器與瀏覽器代理伺服器的涵蓋範圍各不相同。系統代理通常只影響遵循該設定的軟體；瀏覽器擴充功能可能只接管瀏覽器要求。通道模式可接管較多流量，但仍會受路由、排除的應用程式及分流規則影響。看到系統中的 VPN 圖示，不代表每個應用程式都已由 VPN 接管。

在規則模式下，本地網站直連、國際網站經代理可以同時成立。出口 IP 檢測網站也可能符合直連規則。用戶端中的「全域」通常表示已接管的要求統一選擇代理，並不代表會自動接管所有應用程式的流量。

檢查前先記下目前的模式、節點名稱、瀏覽器安全 DNS 設定，以及是否啟用通道。接著每次只變更一個條件，才能找出結果改變的原因。

出口 IP：先比對連線前後的結果

出口 IP 是遠端網站看到的公開 IP 位址，不是裝置在區域網路中的位址。中斷連線時，用瀏覽器開啟可信任的公開 IP 檢測頁，記下位址與網路歸屬。接著連上所選線路，再用同一個瀏覽器重新檢測。不要拿很久以前的截圖比對，因為本地網路的公開 IP 也可能改變。

1. 中斷連線，記錄目前網路的公開 IP；如果檢測頁分別顯示 IPv4 與 IPv6，請一併保留結果。
2. 連上線路後，確認用戶端沒有顯示交握失敗、驗證失敗或設定錯誤。
3. 重新載入檢測頁；必要時使用新的無痕視窗，排除頁面快取的影響。
4. 開啟用戶端連線記錄，確認檢測網域符合哪條規則，以及使用了哪個出口。
5. 再用另一個獨立的檢測服務核對位址，不要只看地圖上的城市名稱。

連線後位址改變，且記錄顯示該要求經過所選代理，才能構成較完整的佐證。地理位置資料庫可能已過時，城市顯示不準不代表線路失效。判斷時應優先檢查位址、網路歸屬與要求路徑，不要只憑國旗或地區標籤下結論。

位址沒有改變，也不必立刻認定連線失敗。先檢查檢測網域是否被規則設為直連、瀏覽器是否繞過系統代理，以及檢測頁是否只顯示其中一種位址類型。如果要暫時使用全域策略進行比對，測試完成後請恢復原設定。

DNS：解析器不同，不一定代表洩漏

DNS 會將網域名稱解析為位址。DNS 檢測頁通常會使用特別產生的測試網域，觀察哪些遞迴解析器向該網域的權威伺服器送出查詢。顯示的通常是解析器對外查詢時使用的位址，而非裝置自己的公開出口，因此 DNS 位址與網頁出口 IP 不同很常見。

比對時應查看解析器的歸屬與設定，而非要求所有結果都位於節點所在的地區。公共 DNS 可能採用分散式服務，檢測頁顯示的地區只是資料庫定位結果。用戶端可能依網域分別使用本地解析、遠端解析或合成位址機制，這些策略都會影響結果。

更值得進一步檢查的情況是：原本預期所有相關解析都經過代理，檢測卻一再出現本地網路業者的解析器，而且記錄或設定也能確認查詢確實繞過預期路徑。只看到熟悉的公共 DNS 品牌，還不足以判定發生洩漏。

加密 DNS 與代理出口是不同問題。瀏覽器使用 DoH 可以加密瀏覽器到解析服務的查詢，但這段連線仍可能採直連。使用加密 DNS，不代表 DNS 查詢已經經過所選線路。

先檢查瀏覽器的安全 DNS，再查看用戶端的 DNS 策略與系統設定。有些瀏覽器會自行解析，繞過用戶端預設的解析服務；有些用戶端則會將 DNS 要求交由內部模組處理。不要照抄檢測頁的結果來修改設定，也不要一次替換所有解析設定。

逐一驗證應用程式，不要把瀏覽器的結果套用到整台裝置

瀏覽器出口正確，只能證明測試網頁的要求符合預期。桌面軟體、遊戲、終端機與背景服務可能使用不同的網路堆疊。有些應用程式不讀取系統代理設定，有些使用 UDP，還有些既有連線不會因切換節點而立即轉移。

實際檢查時，先完全結束目標應用程式，再重新開啟並執行明確的連網操作。同時查看用戶端連線記錄，尋找目標網域、程序或目的位址，核對符合的規則與出口。如果只看總流量增加，很難分辨那是應用程式要求還是系統背景流量。

• ✅ 瀏覽器：重新開啟檢測頁，核對出口位址及檢測網域所符合的規則。
• ✅ 目標應用程式：重新啟動後執行實際功能，查看是否出現相應的連線記錄。
• ✅ UDP 情境：核對用戶端的接管方式與線路支援，不要以瀏覽器連線代替驗證。
• ✅ 規則模式：分別檢查應經代理與應直連的要求，確認兩者都符合預期。
• ❌ 只憑頁面能開啟、應用程式圖示亮起或流量計數增加，就認定所有流量都已生效。

在 Windows 與 macOS 上，要分清系統代理與通道接管；在 Android 上，要查看是否排除了目標應用程式；在 iOS 上，允許加入 VPN 設定檔只代表取得系統授權，仍須檢查用戶端策略與實際連線。各平台的選單名稱可能不同，請以目前使用的用戶端說明為準。

終端機工具也可能受到代理環境變數影響。瀏覽器連線成功、命令列卻失敗時，先檢查命令列是否使用相同的代理路徑，不要立刻更換線路。如需設定說明，可參考快速入門中的接管與匯入步驟。

IPv6 與 WebRTC：檢查容易忽略的連線路徑

網路同時支援 IPv4 與 IPv6 時，應用程式可能優先使用其中一種。如果用戶端只接管部分流量，就可能出現網頁的 IPv4 出口已改變，但 IPv6 仍使用本地網路的情況。兩種位址都應分別檢查，不要只看檢測頁上最醒目的那一個。

本地網路沒有可用的 IPv6 時，檢測失敗不代表代理異常。如果檢測顯示本地網路的公開 IPv6，先確認該要求是否原本就允許直連，再查看通道、IPv6 路由與排除規則。暫時停用 IPv6 可協助定位問題，但不適合作為通用的長期修正方式。

WebRTC 用於瀏覽器即時通訊，可能透過不同於一般網頁要求的路徑探索候選位址。檢測結果中的區域網路位址、經隱藏處理的主機名稱與公開位址代表不同資訊，不要看到任何一個位址就一概稱為洩漏。

重點是是否出現不符合預期的本地公開出口。如果有，請檢查瀏覽器相關的隱私設定、用戶端的 UDP 接管方式與通道策略。變更前也要考量視訊會議等功能的需求，不要只為了讓檢測頁看起來一致，就貿然關閉必要功能。

已連線卻未生效？依照現象縮小問題範圍

已匯入訂閱，但選取的設定沒有更新

訂閱連結用於取得節點與設定，不代表連線已成功。更新失敗、用戶端格式不相容或仍在使用舊設定，都可能讓介面保留節點名稱，卻無法正常送出要求。請核對訂閱更新時間與錯誤訊息，再確認選取的節點確實來自目前的設定。用戶端必須支援訂閱所含的協定；節點名稱相同不能取代相容性檢查。

訂閱連結通常包含帳戶憑證。尋求協助時，不要公開完整連結，也不要將連結貼到來源不明的線上轉換工具。螢幕截圖與記錄中的存取權杖也應先遮蔽。

出口已改變，目標網站仍無法使用

此時應將「代理是否生效」與「網站是否接受這項要求」分開判斷。網站可能依據帳戶地區、先前的工作階段、出口信譽或服務政策進行判斷；應用程式也可能保留舊連線。請先重新啟動應用程式並核對新要求的記錄，再查看網站本身的提示。無法連線不一定是 DNS 問題。

重新連線或切換網路後，結果有所變化

切換網路可能會改變系統 DNS、預設路由與已建立的連線。瀏覽器頁面快取、系統 DNS 快取及用戶端解析快取也不一定會同步更新。先重新送出要求並重新啟動相關應用程式；若結果仍不一致，再依平台文件清除快取。記錄每次操作，不要同時清除快取、更換節點、修改 DNS 及切換模式。

IEPL 專線、中轉與直連描述的是線路傳輸方式，不是裝置端的接管範圍。專線無法自動解決應用程式繞過代理或分流錯誤的問題。可在線路與協定中進一步了解協定與拓樸。

整理檢測結果，留下可供複查的結論

一份有用的記錄應包含：網路環境、用戶端與模式、節點名稱、連線前後的出口、DNS 歸屬、目標應用程式的行為，以及記錄中符合的規則。保留時間與操作順序，之後在相同條件下重新測試，才能更容易區分偶發故障與設定問題。

如果仍無法判讀結果，可透過客服聯絡入口提交已去識別化的記錄。說明哪些要求預期經過代理，以及實際觀察到的狀況，比只寫「無法連線」更容易找出問題。若記錄包含完整公開 IP、存取網域或訂閱憑證，請只保留排查所需資訊。

最後，請還原測試期間暫時變更的設定，並再次檢查常用應用程式。檢測頁是觀察工具，不是最終目的；真正需要確認的是日常使用的要求是否持續依照自己的規則傳送。