用戶端上那個「已連線」的標記,只說明本機隧道握手成功,不表示資料真的從線路出去了。判斷 VPN 是否生效,要看三個可以各自獨立出錯的訊號:出口 IP、DNS 解析位置,以及個別應用的實際走向。三個裡有兩個對不上,就當作沒生效處理。
先分清三件事:連線狀態、出口 IP 與 DNS 解析
連線狀態是用戶端自己的判斷,它只涵蓋到「隧道建立」這一步。隧道建好之後,哪些流量進隧道、網域交給誰解析、某個應用是否繞開系統設定,都由另外的設定決定。所以驗證要分開做,不要用一個「能不能開啟網頁」的結論去涵蓋全部。
| 檢查項目 | 怎麼查 | 正常表現 | 異常訊號 |
|---|---|---|---|
| 出口 IP | 連線前後各查一次公網位址 | 位址改變,且落在所選線路的落地地區 | 與連線前完全一致,或落在與所選地區無關的地方 |
| DNS 解析 | 查解析器的公網出口,比對解析結果 | 解析器出口與線路出口同地區 | 解析仍由本地網路完成,或結果指向本地節點 |
| 分應用走向 | 在目標應用內單獨查一次出口 | 該應用出口與線路一致 | 只有這一個應用仍是本地出口,其餘應用正常 |
順序建議是:先看出口 IP,最直觀;再看 DNS,最容易被忽略;最後按應用逐個確認,最容易被誤判。
快取會騙人。同一個頁面第二次開啟可能來自本機快取或 CDN 邊緣節點,線路已經斷開也照樣顯示。驗證時用無痕視窗,或者換一個先前沒造訪過的網域。
方法一:查出口 IP,確認流量從哪裡出去
出口 IP 是外部網站看到的來源位址。做法很簡單:斷開連線查一次,連上之後再查一次,兩次結果不同、且新位址落在你選的地區,這一步就算通過。命令列取到的是純文字回傳值,不依賴任何用戶端介面。
# macOS / Linux 終端機
curl -s https://ifconfig.me/ip
# Windows PowerShell
(Invoke-RestMethod https://ifconfig.me/ip)
# 單獨查 IPv6 出口
curl -s -6 https://ifconfig.me/ip也可以在瀏覽器裡開啟查 IP 的頁面,但要確認頁面顯示的是純出口位址,而不是被 CDN 判斷出來的城市名稱——後者經常和真實落地差得很遠,拿來當結論容易誤判。
出口 IP 和所選地區對不上,先別急著判定失敗
下面三種情況屬於正常,需要分開看待:
- 中轉線路:入口在近處、落地在目標地區,你看到的應該是落地位址。如果看到的是入口位址,表示這條流量被分流規則判成了直連。
- IP 歸屬資料庫滯後:廣播位址段、剛調整過的位址,歸屬地標註可能比實際晚一段時間,換個查詢來源交叉核對更穩妥。
- 雙棧只接管了一半:IPv4 走了線路、IPv6 仍是本地出口。瀏覽器和系統通常優先使用 IPv6,這時頁面看起來「沒連上」,其實是走了另一條路。
排查雙棧就用上面那條帶 -6 的指令,再跑一次不帶 -6 的,兩個結果要一起看,只看其中一個都會得出錯誤結論。
方法二:查 DNS 解析,確認網域在哪裡被解析
DNS 洩漏的意思是:流量進了隧道,網域卻還是交給本地網路裡的解析器去問。結果是解析按你本地位置回傳,平台同時收到兩套位置訊號;有時表現為能連上但載入很慢,有時表現為登入被要求二次驗證,串流平台則直接判定地區不符。
# 查看某個網域目前解析成什麼
nslookup www.wikipedia.org
# 查詢解析器在公網上的出口位址(不帶 @ 參數,走系統目前解析器)
dig +short TXT o-o.myaddr.l.google.com
# Windows 下同樣的查詢
nslookup -type=TXT o-o.myaddr.l.google.com第二條指令回傳的是遞迴解析器在公網上的出口位址。把它和第一步查到的出口 IP 放在一起看:兩者落在同一地區,表示解析跟著線路走了;解析器仍然是本地電信業者,表示 DNS 沒有接管成功。
三種讓 DNS 悄悄漏掉的原因
- 瀏覽器內建的安全 DNS 開著。它繞過系統解析器,用戶端接管 DNS 也攔不到。驗證時先在瀏覽器設定裡關掉安全 DNS,再測一次,兩次結果對比就能定位。
- 用戶端把 DNS 交給本地處理。部分用戶端預設「本地解析 + 遠端連線」,網域在本地就解析完了。改成由線路側解析,再複測。
- 分流規則本來就把這個網域判成直連。規則模式下這是預期行為,要驗證的是被判走線路的那部分網域,別拿直連網域當樣本。
用 nslookup 時注意看它列印的「Server」那一行,那是目前生效的解析器。如果這一行還是路由器位址或電信業者位址,後面的解析結果就沒有參考價值。
方法三:分應用驗證,確認指定應用是否走線路
分應用代理在 Android 用戶端上最常見;桌面端多數是全域 TUN,想做分應用得靠路由表、獨立瀏覽器代理或虛擬機。這一項最容易誤判,因為不同用戶端的勾選語意相反:有的是「只代理所選」,有的是「跳過所選」。
-
先確認勾選方向
開啟分應用清單,看介面寫的是「僅代理所選應用」還是「跳過所選應用」。這一步弄反,後面全錯,再仔細的對比也沒有意義。
-
在被勾選的應用裡查一次出口 IP
用應用內嵌的瀏覽器開啟查 IP 頁面,記錄結果,和連線前記下的基準比對。位址改變且落在所選地區,這一項通過。
-
在未勾選的應用或系統瀏覽器裡再查一次
兩個結果應該不同。相同,表示分應用沒有生效,流量還是統一走了一條路。
-
結果相同就查兩處
一是清單方向是否選反,二是這個應用是否走自己的網路堆疊。內建代理、私有協定、系統級下載器都可能繞開系統設定,這類情況換用戶端設定解決不了。
-
留一份基準記錄
系統大版本更新、用戶端升級之後,分應用清單可能被重設。按這份基準複測一遍,比出問題後再回頭找原因省事得多。
桌面端沒有分應用開關時,判斷方法換一種:在同一台機器上,分別用系統瀏覽器和一個自帶代理設定的應用去查,看兩者出口是否一致。一致表示全域接管生效;不一致表示有應用繞開了隧道,需要單獨為它設定代理。
看起來連上了其實沒走:常見情況對照
下面這些情況在排查裡出現頻率最高,可以當作逐項對照表使用:
- ❌ 用戶端顯示已連線,但訂閱連結早就過期,節點清單是舊的,連上的是已經下線的位址。
- ❌ 系統代理模式下,只有會讀取系統代理設定的應用走線路,不讀這項設定的應用照舊直連。
- ❌ 瀏覽器開著安全 DNS,解析繞過用戶端接管,出口 IP 變了而解析仍在本地完成。
- ❌ 只接管了 IPv4,IPv6 仍是本地出口,雙棧網站優先走 IPv6,頁面表現就像沒連上。
- ❌ 分應用清單方向選反,以為代理了,實際是被排除在外。
- ❌ 分流規則把目標網域判成直連,或者規則集長時間沒有更新。
- ✅ 正確狀態:斷開與連線兩次查到的出口 IP 不同且落在所選地區,解析器出口與線路同地區,目標應用單獨查也是線路出口。
判斷標準可以很硬:三個訊號裡有兩個對不上,就當沒生效處理。先回用戶端查訂閱狀態與分流模式,再查 DNS 與雙棧,最後才懷疑線路本身。順序反了,容易在沒問題的環節上反覆折騰。
一次驗證流程走完
把上面的方法串成一條固定流程,每次換網路、換裝置、用戶端大版本更新之後跑一遍,幾分鐘就夠。
- 斷開連線,記錄基準:IPv4 出口、IPv6 出口、解析器出口,三項寫下來。
- 連上一條線路,重複同樣三項查詢。
- 比對:出口是否改變、地區是否與所選線路一致、解析器是否跟著變。
- 開啟目標應用,在應用內單獨查一次出口。
- 有任何一項沒變,按上一節清單逐條排查,一次只改一個設定,改完立刻複測。
- 換一條線路再跑一遍,排除單條線路的問題,而不是直接判定整項服務不可用。
線路數量多,意味著複測成本低:一條線路的出口不對,換同地區的另一條再跑同樣的三項查詢,就能分清是線路問題還是本地設定問題。線路列表按地區分組,挑同地區的備用線路很方便。本服務不記錄日誌,訂閱用量與流量包餘量在面板裡可以自行核對;7 天無理由退款期內發現問題,直接走退款流程,不必先做一堆排查。
建議把驗證記錄留存:日期、網路環境、線路地區、三項結果。真的出問題時,這份記錄比任何口頭描述都有用,也能看出問題是從哪一次變更開始的。
結論:能不能開啟網頁不是判斷標準,三個訊號一致才是。出口 IP、DNS 解析位置、分應用走向,三項都對得上,才算真的生效。