VPN 如何確認正常運作？出口 IP 與 DNS 洩漏檢測教學

確認 VPN 是否正常運作：先分清連線狀態與網路路徑

確認 VPN 是否正常運作，不能只看用戶端的連線圖示。查詢出口 IP 可判斷連線從哪裡出去；DNS 洩漏測試可檢查網域解析路徑；目標應用程式是否正常，則需要另外驗證。綜合這些結果，才能分辨正常分流與設定遺漏。

用戶端顯示已連線，通常表示通道或代理服務已啟動，不代表所有流量都會經過代理。系統代理可能只影響遵循系統設定的軟體；TUN 模式則透過虛擬網路介面接管符合條件的流量，但仍會受到路由、排除規則和平台權限影響。兩種模式都不能只看名稱就判斷涵蓋範圍。

測試前先確認目的：只讓指定的國際網站經過代理，還是希望裝置上的外部連線都進入通道？在規則模式下，本地服務維持直連可能正是預期行為。若把所有直連都視為洩漏，可能為了修正不存在的問題，反而破壞正常分流。

比對連線前後的出口 IP

先在可安全中斷代理的環境記錄基準資料。若目前的工作無法承受直連，請勿為了測試而主動中斷；可以先查看用戶端記錄，待情況合適時再補充基準資料。記錄時留意完整 IP、網路業者和位址類型，不要只記下頁面顯示的國家或地區。

1. 中斷連線後開啟IP 查詢頁面，記錄瀏覽器目前的公網出口。若頁面分別顯示 IPv4 和 IPv6 結果，請各自保存。
2. 連線至預計使用的線路，確認訂閱可用、已選取節點，並已啟用系統代理或所需的 TUN 模式。
3. 重新載入查詢頁面，避免只查看舊分頁中的快取內容。比對連線前後的完整位址，不要只看地區名稱。
4. 開啟用戶端連線記錄，確認查詢網域符合哪條規則、使用哪個出口。若查詢頁面本身設定為直連，就不能用來代表代理出口。
5. 改用另一個獨立查詢來源交叉檢查，再到目標應用程式進行驗證。不要因為某個網站無法開啟，就直接認定整條線路都失效。

IP 歸屬地資料來自資料庫，可能更新較慢，也可能與線路名稱不一致。地區相同不代表出口相同；地區改變也不代表所有流量都經過代理。更可靠的依據是位址確實改變，而且用戶端記錄顯示該請求走的是預期線路。

DNS 洩漏檢測：檢查解析路徑，不只看地區

DNS 會將網域名稱轉換成可連線的位址。應用程式流量經過代理，不代表網域查詢也一定經過代理：查詢可能由系統送出，也可能交由瀏覽器的安全 DNS、用戶端內建解析器或代理伺服器處理。是否屬於洩漏，需依照原本希望隱藏或控制的解析路徑判斷。

你可以使用獨立檢測網站，例如 DNSLeakTest。執行網站提供的測試，記錄回傳的解析器業者，再與系統、瀏覽器及用戶端的 DNS 設定比對。檢測網站會接收測試請求，使用前請自行評估其隱私政策。

這類測試通常會讓瀏覽器向特別產生的網域發出請求，再觀察哪些遞迴解析器曾查詢該網域。因此，頁面主要顯示的是測試網域對應的解析器，不是裝置上所有應用程式的完整 DNS 清單。即使結果未顯示本地解析器，也不能據此推論背景應用程式不會使用其他路徑。

若預期所有外部 DNS 查詢都經過通道，卻反覆看到本地網路業者的解析器，就應進一步排查。即使看到公共解析服務，也不能只憑所在國家或品牌判斷安全與否。瀏覽器透過加密 DNS 直接連線至公共解析器，與透過通道連線至同一解析器，可能會顯示相似結果，但實際網路路徑不同。

• 檢查用戶端是否啟用 DNS 接管、遠端解析或相關 DNS 路由規則；實際名稱請以用戶端說明為準。
• 確認瀏覽器安全 DNS 是否使用獨立服務。若需要統一解析路徑，應讓相關設定與用戶端方案相互配合，不要盲目疊加。
• 變更設定後，清除相關 DNS 快取或重新啟動受影響的應用程式，再重新測試，避免沿用既有解析結果。
• 若用戶端使用 Fake-IP，應用程式可能會先取得對應位址，再由用戶端處理連線。這不代表應用程式取得的位址就是公網出口。

常見結果與後續排查

在同一輪測試中一起檢視出口、解析器和連線記錄。每次只變更一項設定，並保留變更前的結果，才能判斷是哪項變更產生影響。下表提供排查方向，並非對單次檢測結果的絕對判定。

延遲測試成功，只代表某種探測請求收到回應，不代表網頁、登入介面、圖片資源和即時連線都經過相同路徑。同樣地，能開啟首頁也不代表應用程式中的所有網域都符合規則。請根據實際失敗的操作，尋找對應記錄。

依應用程式驗證：瀏覽器、桌面與行動裝置

Windows 與 macOS：確認哪些程式正在使用代理

先檢查系統網路代理設定是否與用戶端一致，再確認瀏覽器擴充功能是否覆寫系統設定。桌面應用程式可能使用系統代理，也可能採用獨立的網路堆疊。對於必須經過代理的軟體，請實際操作一次，例如登入、載入內容或發送請求，同時查看用戶端記錄。

開發工具和終端機尤其需要另外檢查。有些程式會讀取 HTTP_PROXY、HTTPS_PROXY 或 ALL_PROXY，有些則需要個別設定，不能假設設定環境變數就能涵蓋所有指令。若已設定本機代理連接埠，請從用戶端目前的設定複製，不要沿用其他教學中的連接埠。

iOS 與 Android：確認接管範圍

確認系統允許目前的用戶端建立 VPN 連線，並檢查是否有其他 VPN 設定正在接管網路。Android 用戶端可能提供依應用程式納入或排除的規則，請確認目標應用程式位於正確範圍。iOS 的 VPN 狀態標示同樣不能取代出口與應用程式測試；實際路由取決於用戶端設定。

Linux：分辨桌面設定與程序環境

桌面環境中的代理選項不一定會套用至背景服務、容器或終端工具。請檢查程序實際使用的設定與環境變數；若使用 TUN，也要確認路由和權限設定。容器若有獨立網路環境，主機上的瀏覽器結果就不能直接代表容器內的請求。

Shadowsocks、VMess、Trojan、VLESS 等代理協定的名稱，也無法說明用戶端採用哪種系統接管方式。協定只決定部分連線機制；系統代理、TUN 和分流規則則決定哪些請求會交由代理處理。排查時別把「更換協定」和「擴大接管範圍」混為一談。

IPv6、WebRTC 與斷線後的風險範圍

IPv4 檢測正常，仍應留意 IPv6。若裝置和網路支援 IPv6，而用戶端未依預期處理，部分連線可能改走其他路徑。請優先核對用戶端的支援狀況和路由策略；了解影響後，才考慮暫時調整系統設定，並在變更後重新測試。

WebRTC 用於瀏覽器即時通訊，測試頁面可能會顯示主機、伺服器反射或中繼候選位址。私有位址或經過隱藏處理的主機候選位址，不等於真實公網出口洩漏。若頁面偵測到與預期出口不同的公網位址，再搭配瀏覽器策略、UDP 路徑和用戶端記錄進一步調查。

若要確認斷線保護是否有效，請在不涉及敏感工作的測試環境中觀察：通道中斷後，原本應經過代理的請求是失敗，還是改為直連。設定頁面出現相關開關，不代表保護必然有效；也不要在實際工作階段中貿然中斷網路進行測試。

IEPL 專線、中轉和直連描述的是線路組織方式，無法代替本機完成 DNS 接管或應用程式分流。改用其他類型的線路可能改變網路表現，卻不會自動修正瀏覽器獨立代理、應用程式排除規則或遺漏的 IPv6 路由。

重新測試清單與結果記錄

完成調整後，請回到先前發生問題的應用程式和操作重新測試。建議記錄連線模式、線路名稱、符合的規則、出口查詢結果和檢測時間。如需協助，可透過說明中心了解處理方式，或參照使用教學檢查用戶端設定。

• ✅ 查詢請求符合預期規則，出口位址與目標路徑一致。
• ✅ DNS 檢測結果能與系統、瀏覽器及用戶端的解析設定相互對照。
• ✅ 目標應用程式已完成實際操作，不只是用戶端顯示連線成功。
• ✅ 在適用的網路環境中，分別檢查了 IPv4、IPv6 和即時通訊路徑。
• ✅ 變更設定後，重新建立相關連線，避免根據舊工作階段的結果判斷新設定。
• ✅ 分享截圖或記錄前，請遮蔽訂閱連結、憑證、權杖及不必要的個人資訊。

訂閱連結可能包含存取憑證，不應貼到公開檢測網站或討論區。排查通常只需要已去識別化的規則命中、錯誤訊息和出口結果，無須公開整份設定檔。若不確定記錄中的哪些欄位屬於敏感資訊，請先詢問支援人員需要哪些最少資訊。