用戶端視窗裡亮著「已連線」,不等於流量真的從國際線路出去。要確認 VPN 真的生效,得把三件事分開看:出口 IP 有沒有換成節點所在地、DNS 查詢由誰解析、正在用的那個應用程式有沒有被規則涵蓋。下面按這三步給出可複製的檢查方法,再列出幾種「連上了卻沒走通」的典型情況。

連上、接管、生效是三件事

很多人把這三步當成一步,於是排查時無從下手。它們其實可以互相獨立:

  • 隧道建立:用戶端與節點完成握手。Shadowsocks、VMess、Trojan、VLESS 一般跑在 TCP 或 WebSocket 一類傳輸上;Hysteria2、TUIC 基於 QUIC,底層是 UDP。握手成功只說明這條鏈路通了。
  • 流量接管:用戶端把本機流量交給隧道。TUN 模式接管全部 IP 流量,系統代理模式只影響那些會讀取代理設定的應用程式。
  • 出口生效:目標網站看到的來源位址是節點位址,而不是本地電信業者配發的位址。

三者分離時,最容易出現的錯覺就是「用戶端一切正常,但開啟網頁仍是本地結果」。這通常不是用戶端在騙人,而是接管範圍或分流規則沒有涵蓋到你測試的那個目標。

第一步:查出口 IP

連線前後各查一次,是最直接的判斷方式。用瀏覽器開啟任一 IP 查詢頁面可以看位址與歸屬地;命令列更適合做前後對比,因為輸出乾淨、便於記錄。

# 連線前:記錄基準
curl -s https://api.ipify.org; echo

# 連線後:再查一次
curl -s https://api.ipify.org; echo

# 同時查看出口地區
curl -s https://www.cloudflare.com/cdn-cgi/trace | grep -E '^(ip|loc)='

正常結果是兩次位址不同,且第二次的歸屬地與所選節點一致。若兩次完全相同,先檢查分流規則是不是把這個查詢網域判成了直連,再檢查目前的接管模式是不是系統代理。

IPv6 與 WebRTC 是兩個常見漏點

多數隧道預設只接管 IPv4。如果本地網路有原生 IPv6,存取支援 IPv6 的網站時會直接用本地位址出去,而 IPv4 的檢查結果看起來一切正常。單獨查一次 IPv6 出口:curl -6 -s https://api64.ipify.org,回傳本地位址就說明 IPv6 沒有被接管。

瀏覽器還有一條獨立通道:WebRTC 可以在不經過代理的情況下取得本機位址。用一個沒裝任何擴充功能的瀏覽器對比一次,或者在瀏覽器設定裡限制 WebRTC,就能判斷問題是不是出在這裡。

命令列工具不讀系統代理。curl 需要明確加上 -x,或設定 http_proxy / https_proxy 環境變數才會走代理。所以在系統代理模式下,終端機查到的位址與瀏覽器不同屬於預期行為;切到 TUN 模式後,兩者應當一致。

第二步:查 DNS 由誰解析

DNS 負責把網域換成位址。流量走了隧道、解析卻仍交給本地電信業者,會帶來兩個後果:存取意圖暴露給本地解析器;解析結果按本地位置回傳,拿到的是就近節點,於是「已經切到海外」的預期落空。

檢查方式有三種:

  • 線上 DNS 洩漏測試頁面會列出本次解析實際使用的解析器,適合快速看一眼。
  • Windows 用 nslookup example.com,macOS 與 Linux 用 dig example.com,看回傳的 SERVER 段是哪一台。
  • macOS 還可以用 scutil --dns 查看系統解析器的排列順序,判斷預設走哪一個。

判斷標準不是「有沒有出現本地 DNS」,而是「你關心的那個網域由誰解析」。分流模式下,本地網域走本地解析、國際網域走隧道解析,本來就是設計目標;把本地網域也強行送進隧道,反而會讓本地網站變慢。

分流模式裡出現本地解析器不等於洩漏。真正要確認的是:存取國際網站時,那條解析請求有沒有經由隧道發出。

第三步:分應用驗證

同一個節點,不同應用程式的接管方式並不一樣。把「瀏覽器能開啟」當成全部走通,是排查裡最常見的誤判。

  • 瀏覽器通常讀取系統代理設定,是最容易走通的一類。
  • 桌面應用程式有的讀系統代理,有的只認 TUN 模式。
  • 命令列與開發工具多數不讀系統代理,需要環境變數或 TUN 才能接管。
  • 行動裝置由系統層級 VPN 設定接管,涵蓋面最廣,但背景省電策略可能把連線掐斷。

驗證方法很直接:挑同一個目標,在瀏覽器與終端機各存取一次,對比出口位址。兩邊一致,說明接管範圍涵蓋到命令列;只有瀏覽器變了,說明目前是系統代理模式,或者分流規則把終端機存取的目標判成了直連。

平台之間的差異

Windows 上 TUN 模式需要安裝虛擬網卡,首次連線會有權限確認;macOS 需要允許網路擴充功能,安裝後通常要重新啟動用戶端才生效;Linux 下 TUN 需要 root 權限,或給執行檔 CAP_NET_ADMIN 能力,否則只能用系統代理;iOS 與 Android 走系統 VPN 框架,首次連線要確認設定,用戶端被背景清理後連線會斷,需要重新開啟。訂閱匯入方式也不同:桌面用戶端貼上訂閱連結後手動更新一次節點清單,行動裝置多數透過一次點擊完成匯入。

三項檢查對照表

把上面三步壓縮成一張表,排查時逐項核對即可:

三項檢查的判斷標準
檢查項目 怎麼查 正常結果 能說明什麼
出口 IP IP 查詢頁面、curl 查詢介面 連線後的位址與所選節點同地區 流量確實從節點出去
DNS 解析器 洩漏測試頁面、nslookup 或 dig 國際網域的解析在隧道內 解析沒有交給本地電信業者
分應用接管 瀏覽器與終端機各存取一次 兩邊出口位址一致 接管範圍涵蓋到該應用程式

常見的「假連通」

下面這些情況,用戶端狀態都是「已連線」,但流量並沒有按預期走國際線路:

  • ❌ 分流規則把測試目標判成直連,出口位址自始至終沒有變化。
  • ❌ 系統代理開著,但受測應用程式不讀代理設定,只有瀏覽器走了隧道。
  • ❌ 只接管 IPv4,本地有原生 IPv6,支援 IPv6 的網站仍從本地出去。
  • ❌ 流量進了隧道,DNS 仍由本地解析器處理,解析結果按本地位置回傳。
  • ❌ Hysteria2、TUIC 這類基於 QUIC 的協定,在網路限制 UDP 時表現為握手失敗或頻繁重連,看起來像「連上了,一會兒又斷」。
  • ❌ 訂閱連結過期或節點已下線,用戶端還留著舊的線路名稱,點連線只是反覆重試。
  • ✅ 出口位址變成節點所在地、國際網域的解析在隧道內、瀏覽器與終端機結果一致,三項同時滿足才算真的走通。

把流程固定下來

每次換線路、換協定、換用戶端之後,按同一套順序走一遍,比憑感覺判斷可靠得多:

  1. 連線前記錄一次出口位址與解析器,作為基準。
  2. 連上節點,記下所選地區與協定名稱。
  3. 再查一次出口位址,對比地區是否與所選節點一致。
  4. 查一個國際網域的解析器,確認解析走隧道。
  5. 瀏覽器與終端機各測一次,對比兩邊結果。
  6. 換一條線路或換一個協定複測,確認問題不是出在單條線路上。

結論:三項都通過,才算 VPN 真的生效——出口變了、解析走了隧道、受測應用程式被涵蓋。只滿足其中一項時,先查分流規則和接管模式,再懷疑線路本身。

驗證之後,再確認服務端幾件事

出口位址會隨所選線路變化,換線路複測的成本越低,排查就越快。VPNAJ 目前涵蓋 120+ 國家、180+ 線路,量子加密,不限台數同時在線,行動裝置、筆記型電腦與桌面可以各自跑一遍上面的三步;註冊只需使用者名稱與密碼,無需電子郵件地址。

120+ 涵蓋國家與地區
180+ 可選線路
7 天 無理由退款
不限 同時在線台數

如果換了兩三條線路、兩種協定之後三項檢查仍不通過,問題多半在本地接管方式上,而不是節點。這時先回退到 TUN 模式重測一次,再考慮重新安裝用戶端、重新匯入訂閱連結。

提示:驗證的價值在於可重複。同一套指令、同一張對照表,今天能用,換一台機器也能用,排查就不必從零開始猜。