VPN 連線成功了嗎？出口 IP、DNS、分應用三步驗證指南

「用戶端顯示已連線，網頁卻打不開」和「用戶端顯示已連線，流量其實沒走線路」是兩個不同的問題。要判斷 VPN 到底連上了沒，只看用戶端圖示沒有意義：圖示只代表本機與節點完成了握手，不保證每個請求都進入隧道。下面這套三步驗證——出口 IP、DNS 歸屬、分應用測試——每一步都能獨立給出結論，也能互相印證。

驗證不需要額外工具，瀏覽器加上用戶端本身就能完成。順序建議固定下來：先確認出口位址換了，再確認網域名稱解析跟著換了，最後確認目標應用程式確實在使用這條線路。

• 3 步 出口 IP / DNS 歸屬 / 分應用，逐項給出結論
• 120+ 國家與地區的線路覆蓋
• 240+ IEPL 專線與中轉線路可選
• 7 天 無理由退款

為什麼「已連線」不等於流量真的走線路

用戶端上的「已連線」表示本機程式與節點之間握手成功：工作階段建立、驗證通過、金鑰協商完成。它不保證系統裡的每一個請求都會進入這條隧道。是否真的走線路，取決於用戶端的工作模式、分流規則，以及應用程式自己的網路設定。

工作模式決定涵蓋範圍

虛擬網卡（TUN）模式會建立一張虛擬網卡並接管系統路由表，TCP 與 UDP 預設全部進入隧道，只有命中分流規則放行的流量才直連。系統代理模式只修改系統的代理設定：遵循該設定的應用程式會走線路，自帶網路堆疊、不讀系統代理的軟體則直接連出去。同一個用戶端、同一條線路，兩種模式下的涵蓋範圍完全不同。

分流規則決定例外

分流不是故障，而是設計目標：本地網域與本地 IP 段預設直連，存取本地服務時不必繞遠路。風險在於誤判——目標網域被規則歸到直連那一側，表現就是「連上了但沒走」。規則集長期不更新，誤判會變多。

應用程式與快取帶來的干擾

瀏覽器可以有自己的代理設定，擴充功能也能接管請求；開啟安全 DNS 後，網域名稱解析可能完全繞過系統設定。切換線路之後，已經建立的長連線（HTTP/2、HTTP/3 工作階段）可能仍走舊路徑。切換後先重啟瀏覽器，再在系統層面清除 DNS 快取：

# Windows
ipconfig /flushdns

# macOS
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

# Linux（systemd-resolved）
sudo resolvectl flush-caches

出口 IP 核對：連線前後各查一次

出口 IP 是外界看到的你的位址，也是三步裡最容易重現的一項：連線前後各查一次，比對結果。檢測頁面盡量選能同時顯示 IP 歸屬地與電信業者的那類，資訊越完整，判斷越省事。

1. 中斷用戶端連線，打開檢測頁面，記錄三項資訊：出口 IP、國家 / 地區、電信業者或 ASN。
2. 連上用戶端，選擇一條線路。以日本或新加坡線路為例，檢測頁應顯示對應地區的位址。
3. 強制重新整理檢測頁，不要用快取頁面，比對 IP 是否變化、歸屬地是否與所選線路一致。
4. 單獨看 IPv6 欄位：如果顯示你的 IPv6 位址仍屬於本地電信業者，說明隧道只接管了 IPv4，部分同時提供 AAAA 記錄的網站會直接走 IPv6 出去。
5. 只在瀏覽器裡做驗證的情境，再看一次 WebRTC：它可能暴露本機位址或真實公網位址，與出口 IP 是兩條獨立路徑。

檢查項目	正常表現	需要處理的表現
IPv4 出口	顯示線路所在國家 / 地區的位址，與連線前不同	與連線前完全相同，或歸屬地仍是本地
IPv6 出口	沒有 IPv6 位址，或顯示線路側位址	顯示本地電信業者的 IPv6 位址
WebRTC	只出現隧道內或線路側位址	出現本機內網位址或真實公網位址
電信業者 / ASN	顯示為線路側的機房或電信業者	仍是本地寬頻電信業者

如果檢測頁列出了 IPv6 位址，而用戶端並沒有接管 IPv6，最省事的做法是在用戶端裡關閉 IPv6 轉送，讓網域回到 IPv4 路徑上。代價是純 IPv6 的網站無法存取，日常使用幾乎感覺不到。

DNS 歸屬核對：解析路徑在哪裡

出口 IP 只回答「資料從哪裡出去」，不回答「你查了哪些網域」。網域名稱解析的路徑決定了誰能看到你造訪的網站清單，所以第二步單獨查 DNS。

兩條解析路徑

隧道內解析：用戶端把 DNS 查詢一起送進隧道，由節點側解析器完成；Fake-IP 模式則是先在本地把網域對應成虛擬位址（常見做法是 198.18.0.0/15 這類保留段），真正的解析發生在節點側，連線按網域發起。本地解析：應用程式直接向路由器或電信業者解析器查詢，取得位址後再決定走哪條路。這種情況下，即使網頁流量進了隧道，網域清單仍留在本地網路裡——這就是一般所說的 DNS 洩漏。

怎麼測

1. 打開一個 DNS 洩漏檢測頁面，它會列出為你的查詢提供解析的解析器位址與歸屬地。
2. 連上線路後重新整理幾次，讓檢測頁發起多個不同網域的查詢。
3. 看解析器清單：正常情況下只應出現節點側解析器；如果混進本地電信業者解析器與你的城市，說明這些查詢走了本地。

瀏覽器安全 DNS 是常見的干擾項

Chrome、Edge、Firefox 都提供安全 DNS（DoH）開關，開啟後瀏覽器會直接向 DoH 服務商發起加密查詢。TUN 模式下這些查詢本身也進入隧道，只是解析器換成了 DoH 服務商；系統代理模式下，請求可能完全繞過隧道直連出去。排查時先把這個開關關掉，或者確認它走的是隧道。

處理方式

• 在用戶端裡開啟 DNS 接管（DNS 劫持），把送往 53 埠的查詢重新導向到隧道內的解析器。
• 關閉瀏覽器的安全 DNS，或把它指向隧道內的解析器。
• 不要同時執行兩個代理工具，它們會互相搶路由表與 DNS 設定。

分應用與分流規則測試

前兩步驗證的是系統層面，第三步驗證的是應用程式層面。分應用代理讓你指定哪些應用程式走線路，分流規則決定哪些網域走線路，兩者都會讓同一個 IP 檢測頁給出不同答案。

分應用代理的驗證方法

1. 在同一台裝置上，用兩個不同的應用程式存取同一個會顯示出口 IP 的頁面。
2. 一個是被代理的應用程式（通常是瀏覽器），一個是未被代理的應用程式。
3. 前者的出口 IP 應該是線路側位址，後者應該仍是本地位址。兩者都符合預期，說明分應用設定生效。
4. 如果兩者顯示同一個位址，回去檢查用戶端的應用程式清單：桌面系統按行程名稱比對，行動系統按應用程式套件名稱比對，重新安裝或改名後需要重新選擇。

分流規則的比對順序

規則由上而下逐條比對，命中即停，所以順序本身就是設定的一部分。常見類型如下：

規則類型	比對對象	典型用途
DOMIN	完整網域	精確放行或代理單一網域
DOMAIN-SUFFIX	網域後綴	涵蓋一個網站及其全部子網域
DOMAIN-KEYWORD	網域中的關鍵字	批次比對同類網站
IP-CIDR	IP 位址段	依位址範圍分流
GEOIP	IP 歸屬國家 / 地區	本地直連、海外走線路
RULE-SET	外部規則集合	引用持續維護的規則清單
MATCH	其餘全部流量	備援規則，放在最後一條

驗證分流是否按預期運作，最直接的辦法是看連線日誌：多數用戶端提供即時連線清單，每筆記錄會寫明命中了哪條規則、走的是代理還是直連。目標網域顯示 DIRECT，說明是規則放行，不是線路故障。規則集有更新時間，長期不更新會把新網域判錯；在用戶端裡手動更新訂閱與規則集，是最省事的修復方式。

「看起來連上了、其實沒走」的常見情況

下面這些現象在排查裡出現頻率最高，按現象、原因、處理三欄對照即可。

現象	可能原因	處理
用戶端顯示已連線，瀏覽器仍是本地 IP	瀏覽器使用自有代理設定，或擴充功能接管了請求	關閉瀏覽器的代理類擴充功能，統一由用戶端接管
部分網站打不開，另一些正常	目標網域命中直連或 REJECT 規則，規則集過期	在連線日誌裡看規則命中，更新訂閱與規則集
IPv4 已切換，IPv6 仍是本地	隧道未接管 IPv6，本地網路又提供了 IPv6	在用戶端內關閉 IPv6 轉送，或讓隧道接管 IPv6
檢測頁出現本地 DNS 解析器	瀏覽器安全 DNS 直連，或系統代理模式下本地解析	開啟 DNS 接管，關閉瀏覽器安全 DNS
連線成功但請求全部逾時	節點出口異常、MTU 與分片問題、UDP 被封鎖	換線路、切換協定（TCP / QUIC）、調整 MTU
切換線路後仍顯示舊 IP	長連線重用與 DNS 快取	清除 DNS 快取，重啟瀏覽器，中斷後重新連線

還有一件事要分清：驗證只能說明流量走了線路，不能說明線路品質。線路類型決定的是穩定性——直連線路由用戶端直接連上海外節點，全程走公網，晚高峰容易受壅塞影響；中轉線路先連近端入口再轉送到出口，路徑可控一些，但後半段仍依賴公網；IEPL 專線走專線通道，不經過公網，抖動與封包遺失更小。三步都通過、速度仍不理想時，問題在選線，不在驗證。

排查清單與判斷標準

把上面三步濃縮成一份清單，逐項對照即可：

• ✅ 出口 IP 與所選線路的歸屬地一致，且與連線前不同
• ✅ 檢測頁沒有出現本地電信業者的 IPv6 位址
• ✅ 被代理網域的解析器位於節點側，沒有混入本地解析器
• ✅ 連線日誌顯示目標網域命中代理規則，而不是 DIRECT
• ✅ 被排除代理的應用程式確實顯示本地位址，說明分應用設定生效
• ❌ 檢測頁顯示的仍是本地寬頻位址，清除快取、重啟瀏覽器後不變
• ❌ 解析器清單裡同時出現本地電信業者與本地城市
• ❌ 連線日誌裡目標網域全部命中 DIRECT 或 REJECT

常見問題