先分清:連上了不等於走對線路
在用戶端裡按下連線、狀態列變綠,只代表本機到節點的隧道建立成功。它不保證出口 IP 落在你選的地區,不保證網域在遠端解析,也不保證所有應用程式都被接管。
隧道建立成功、節點實際不可用、訂閱到期、分流規則命中直連,都可能讓流量繞回本地出口,而用戶端介面不會有任何提示。所以「已連線」是一個動作的結果,不是線路生效的證明。
要確認線路真的生效,需要回答三個具體問題:流量從哪個 IP 出去、網域在哪裡解析、哪些應用程式進了隧道。
把這三件事展開成可核對的標準,就是下面這份清單。三項都滿足,才算流量確實走了國際線路。
- ✅ 查詢到的出口 IP 歸屬地與所選線路地區一致;
- ✅ 解析伺服器位於線路出口一側,清單裡沒有本地電信業者的 DNS;
- ✅ 需要走線路的應用程式全部命中代理規則,瀏覽器與終端機查到的結果一致;
- ❌ 只看到用戶端顯示「已連線」,其餘三項都沒有核對過。
第一步:核對出口 IP 與落地地區
出口 IP 是最直接的一項驗證:先斷開線路,記下目前的對外 IP 與歸屬地;連上線路後再查一次,對比兩次結果。查詢入口可以是在搜尋引擎裡搜「我的 IP」,也可以在終端機裡用一行指令。
# 連上線路後執行,查看目前出口 IP
curl -s https://ipinfo.io/ip
# 備用查詢入口
curl -s https://ifconfig.me/ip通過的標準很明確:連上後查到的 IP 歸屬地,應該與所選線路的地區一致。如果查到的還是本地電信業者的 IP,代表流量根本沒有進入隧道,後面兩步先別急,照最後一節排查。
有一個容易誤判的地方是 IPv6:不少用戶端預設只接管 IPv4,IPv6 請求會直連出去,而查詢網站可能優先回傳 IPv6 位址,看起來就像「連上了但沒生效」。處理方式是在用戶端裡開啟 IPv6 接管,或暫時停用 IPv6 再測一次。
第二步:做一次 DNS 洩漏檢查
隧道裡的流量有軍工級加密,但 DNS 請求是獨立於網頁流量的一條路徑。如果網域解析仍然送給本地電信業者的 DNS,就出現了 DNS 洩漏:IP 走了線路,網域卻在本地解析。結果是解析結果被就近調度回本地 CDN 節點,存取變慢甚至打不開;解析路徑本身也會暴露存取意圖。
檢查方式:搜尋「DNS 洩漏測試」,開啟任一測試頁,看回傳的解析伺服器清單。清單裡出現本地電信業者或本地城市的 DNS,就是洩漏;正常應該看到線路出口地區的解析伺服器。
終端機裡也能看:nslookup 的輸出會帶一行 Server,連接線路前後各執行一次,對比這行位址有沒有變化。
# 連接線路前後各執行一次,對比 Server 一欄
nslookup example.com出現洩漏時,在用戶端裡開啟「遠端 DNS」或「使用線路 DNS」,讓解析請求也走隧道;如果用戶端提供 DNS 處理模式的選項,就選由隧道接管。另外,瀏覽器內建的加密 DNS(DoH)會繞過系統設定,驗證時先把它統一,或暫時關閉。
第三步:應用程式與分流驗證
依應用程式分流在 Android 用戶端最常見:只有勾選的應用程式會進隧道,其餘維持直連。桌面端則更依賴分流規則:用戶端按規則庫把網域和 IP 分成代理、直連兩組,規則命中錯了,目標網站就會走本地出口。
驗證按四步走:
- 打開用戶端的連線日誌或規則命中記錄;
- 造訪一個需要走線路的目標網站,在日誌裡找到對應條目,確認命中的是代理規則,而不是直連;
- 對關鍵應用程式逐一重複:瀏覽器裡查一次出口 IP,終端機裡查一次出口 IP,對比兩者是否一致;
- 結果不一致的應用程式,回到應用程式清單或自訂規則裡單獨調整,再複測一次。
瀏覽器和終端機查到不同出口是常見現象:終端機預設不會走瀏覽器的代理設定;如果用戶端是 SOCKS 或 HTTP 代理模式,終端機需要另外設定代理環境變數,否則查到的還是本地 IP。這不是線路問題,而是接管範圍的問題。
「看起來連上了其實沒走」的常見狀況
下面這些現象的共同點是:用戶端的連線狀態都正常,但流量沒有照預期走線路。按現象對照原因排查,比反覆重新連線有效得多。
| 現象 | 實際原因 | 處理方向 |
|---|---|---|
| 用戶端顯示已連線,查到的仍是本地 IP | 節點交握失敗後退回直連,或訂閱已到期、流量用盡 | 換一條線路重測,並檢查訂閱狀態 |
| 網頁打得開,但影片一直緩衝 | 網域在本地解析,被調度回本地 CDN 節點 | 開啟遠端 DNS,重跑一次洩漏檢查 |
| 部分應用程式走了線路,部分沒有 | 應用程式分流沒勾選,或分流規則命中直連 | 對照應用程式清單與規則命中日誌 |
| 瀏覽器與終端機查到的出口不一致 | 瀏覽器裝了代理外掛,或有獨立代理設定 | 統一代理設定後重新查詢 |
| 只查到 IPv6 位址是本地 | 用戶端沒有接管 IPv6 | 開啟 IPv6 接管,或暫時停用 IPv6 |
| 連上後中國大陸網站反而打不開 | 全域模式把所有流量送出,或規則庫把中國大陸網域判成代理 | 切回規則分流模式,更新規則庫 |
不同平台的驗證重點
同一套驗證流程,在不同系統上的注意點並不一樣,按平台補一遍能少走冤枉路。
Windows 與 macOS
桌面用戶端常見兩種接管方式:系統代理與 TUN 模式。系統代理只涵蓋會讀取系統代理設定的應用程式,終端機和部分軟體會繞過;TUN 模式接管更徹底,但要注意別和系統代理同時開啟,兩者疊加容易出現規則衝突。驗證前先確認用戶端用的是哪一種模式。
Android 與 iOS
行動裝置走系統 VPN 設定,連線狀態在系統設定裡也看得到。Android 支援依應用程式分流,驗證時重點核對勾選清單;iOS 一般沒有分應用開關,更依賴規則分流,驗證重點放在 DNS 與規則命中上。另外,行動網路下的 DNS 由電信業者提供,洩漏檢查在行動數據下更值得做一次。
Linux 與路由器
Linux 上多用命令列用戶端,注意 systemd-resolved 會接管 DNS,resolvectl status 能看到目前使用的解析伺服器,確認它已經被隧道接管。線路部署在路由器上時,全網裝置共用同一個出口,在任一台裝置上驗證即可,但路由器本身的 DNS 轉發設定決定了解析路徑,洩漏檢查要從路由器這一層來看。
VPNYN 的用戶端涵蓋 Windows、macOS、iOS、Android、Linux,訂閱匯入後就能照上面的流程逐項驗證;同一個帳號不限裝置數量同時上線,多台裝置可以並行複測。
驗證不通過時的排查順序
照下面的順序走,每一步都能縮小一次範圍,避免同時改一堆設定。
- 換線路重測。同一份設定換一條線路,恢復正常就說明問題在節點側,不必動本機設定。
- 檢查訂閱狀態。訂閱到期或流量用盡,表現就是「連得上但沒有流量」,先確認這兩項。
- 停用瀏覽器代理外掛與內建加密 DNS,排除瀏覽器層的獨立設定。
- 檢查 DNS 接管。在用戶端裡開啟遠端 DNS,重新跑一次洩漏檢查。
- 檢查 IPv6。開啟接管或暫時停用,再測一次出口 IP。
- 重新啟動用戶端與網路。隧道與 DNS 設定會隨連線重建,路由器裝置也可以重啟一次。
- 記錄日誌。把用戶端日誌和三項驗證結果一起提交給客服,定位速度會快很多。
這套流程不需要額外工具:一個 IP 查詢入口、一個 DNS 洩漏測試頁、用戶端的連線日誌,就足以涵蓋全部三項。換線路之前,也可以先看一眼線路清單,挑一條地區對得上的線路再測。