VPN 連上了但沒生效?查 IP、查 DNS 的完整驗證方法

用戶端顯示「已連線」,瀏覽器裡的目標網站卻依舊打不開;或者頁面能開啟,但查詢出口位址時顯示的仍是本機電信業者的歸屬地。這類情況在排查紀錄裡出現頻率很高,而且多數不是線路故障,而是流量根本沒有走進隧道。判斷 VPN 是否真的生效,不能看介面上的連線狀態,要看兩個可驗證的指標:出口 IP 有沒有換、DNS 解析有沒有跟著換。

本文提供三步驗證法:查出口 IP、查 DNS 洩漏、分應用程式比對測試,並拆解六種「看起來連上了其實沒走」的典型情況與對應修法。整套流程涵蓋 Windows、macOS、iOS、Android 與 Linux,不需要安裝額外的檢測工具,用到的都是瀏覽器頁面與系統內建指令。

為什麼「已連線」不等於已生效

用戶端裡的連線狀態,只說明用戶端程序與線路入口之間的握手成功了,它不保證系統裡其他程式的流量會走這條隧道。真正決定「生效」的是接管層級:用戶端用哪種方式把流量導向隧道,以及 DNS 與 IPv6 有沒有被一併接管。

接管層級:擴充功能、系統代理與 TUN

三種方式沒有絕對優劣。系統代理部署輕、對系統改動小,但涵蓋範圍窄,只對讀取系統代理設定的應用程式有效;TUN 接管涵蓋範圍廣,代價是需要更高權限:Windows 上要安裝虛擬網卡驅動程式,macOS 與 Linux 上要授權網路擴充功能或以相應權限執行。如果你的目標是讓所有程式都走線路,應先確認用戶端處於 TUN / 全域接管模式,而不是系統代理模式。

另一個常被忽略的層面是 DNS。即使流量已經走進隧道,解析請求仍可能發給本機網路下發的解析器,拿到被就近調度或被替換的結果,表現就是「連上了,但網域打不開,或者開啟的是另一個區域的版本」。所以驗證必須同時看 IP 和 DNS,缺一不可。

第一步:查出口 IP,看流量有沒有換出口

這一步的目標很簡單:拿到連線前後的兩個出口位址做比對。按下面的順序做一遍,基本上就能定性。

1. 中斷用戶端連線,先測一次,記錄出口 IP、歸屬地與電信業者(ASN)。
2. 連上用戶端,確認目前使用的是哪條線路、哪個地區。
3. 用同一個查詢服務再測一次,比對 IP 與歸屬地是否發生變化。
4. 單獨查一次 IPv6 出口。IPv6 常被忽略,它是「連上卻沒走」的高發區。
5. 換一個查詢服務複測一次,排除頁面快取造成的誤判。

查詢服務本身也可能受 CDN 影響:部分查詢站點走 CDN,傳回的歸屬地是 CDN 節點所在位置,而不是你的真實出口。遇到「IP 變了但歸屬地看著不對」的情況,換一個查詢服務,或直接看 ASN 欄位再判斷。

# 目前出口 IPv4
curl -4 -s https://api.ipify.org

# 目前出口 IPv6(沒有輸出通常表示本機沒有 IPv6 出口)
curl -6 -s https://api.ipify.org

# 附歸屬地與 ASN 的查詢
curl -s https://ipinfo.io/json

• ✅ 連線前後出口 IP 不同,歸屬地與所選線路地區一致
• ✅ IPv4 查詢結果指向線路出口;本機沒有 IPv6 時,IPv6 查詢無輸出
• ✅ 在同一台裝置上用第二個查詢服務複測,結果一致
• ❌ 介面顯示已連線,出口 IP 與中斷時完全相同:流量沒有被接管
• ❌ 瀏覽器裡出口變了,命令列工具查出來仍是本機位址:目前是系統代理或單一應用程式代理模式
• ❌ IPv6 查詢傳回本機電信業者位址:IPv6 流量繞過了隧道

第二步:檢查 DNS 洩漏,確認解析也走了線路

DNS 查詢發生在建立連線之前。如果解析請求發給了本機網路下發的解析器,那麼即使後續流量走了隧道,你也可能拿到被就近調度或被替換的解析結果,表現為「連上了但打不開」「開啟的是錯誤區域版本」「時快時慢」。這類情況通常被統稱為 DNS 洩漏,它和線路品質無關,屬於接管範圍的問題。

DNS 檢測結果怎麼看

檢測頁會列出本次解析使用的解析器 IP、歸屬地與電信業者。判斷方法:解析器歸屬地應與線路出口一致,或至少屬於同一服務商網路。如果顯示的是你本機寬頻或行動網路的電信業者名稱,那就是洩漏;如果解析器位址與出口 IP 同網段或同 ASN,屬於正常。

處理方式按優先順序排列:

• 在用戶端裡開啟 DNS 接管(有的用戶端叫 DNS 劫持、DNS 代理),讓解析請求走隧道。
• 改用線路側下發的解析器位址,避免繼續使用路由器下發的本機位址。
• 檢查瀏覽器是否開啟了加密 DNS。它會繞過系統 DNS 設定,排查時先關掉再檢測。
• 路由器端如果啟用了 IPv6,確認 IPv6 的 DNS 也被接管,否則解析可能從 IPv6 通道漏出去。

# Windows:查看系統目前使用的 DNS 伺服器
ipconfig /all

# macOS:查看系統解析器設定
scutil --dns

# Linux:查看目前解析設定
cat /etc/resolv.conf

# 傳回的位址就是解析器出口,可與出口 IP 比對
nslookup whoami.akamai.net

第三步:分應用程式、分場景比對測試

出口 IP 和 DNS 都對,仍然可能有個別應用程式不走線路。這一步的目標是把「哪個應用程式沒走」定位出來,而不是籠統地歸因於線路。

1. 瀏覽器:用無痕視窗或先清一次快取後造訪目標網站,記錄結果。
2. 命令列:用 curl 查出口 IP,與瀏覽器結果比對。命令列工具預設不讀系統代理,需要明確設定 http_proxy / https_proxy 環境變數,或者依賴 TUN 接管。
3. 桌面應用程式:在用戶端的分應用程式代理清單裡確認該應用程式被標記為走線路;以 UDP 為主的軟體在系統代理模式下通常不會被代理。
4. 行動裝置:Android 上確認 VPN 權限已授予、用戶端在省電白名單裡;iOS 上確認 VPN 設定處於已連線狀態,沒有被隨需連線規則提前中斷。
5. 交叉驗證:在同一帳號的另一台裝置上複測。VPNDX 不限裝置數同時在線,換裝置複測不需要額外操作。

依平台差異逐項確認

• Windows:排查前先看「設定 → 網路和 Internet → 代理」是否被其他軟體改回自動設定;部分應用程式走 WinHTTP 代理,可以用 netsh winhttp show proxy 單獨確認。TUN 模式依賴虛擬網卡驅動程式,安全軟體攔截驅動會導致接管失敗。
• macOS:部分應用程式不讀系統代理;用 scutil --dns 看系統解析器,用 networksetup -getwebproxy Wi-Fi 看目前代理項目。使用網路擴充功能接管時需要在系統設定裡授權。
• iOS:由系統 VPN 設定統一接管,通常不需要分應用程式設定;低耗電模式會限制背景重新整理,長時間切到背景後要重新喚起用戶端確認狀態。
• Android:分應用程式代理是系統層級能力,可以在系統 VPN 設定或用戶端內選擇只讓部分應用程式走線路;省電策略可能回收用戶端程序,造成看似連線實則中斷。
• Linux:建立 TUN 裝置需要 root 或相應權限;命令列工具預設不讀系統代理,要嘛設定環境變數,要嘛走 TUN。

六種典型「連上卻沒走」的情況與修法

把上面三步的結果對照下表,基本上可以直接定位到原因。

什麼時候必須重新驗證

三步驗證不是一次性動作。下面這些時點之後,接管狀態可能已經改變,建議重新走一遍。

• 更換網路環境後:從家用寬頻到公司網路、從 Wi-Fi 切到行動熱點,路由與代理設定都會重建。
• 切換線路或線路地區後:分流規則與解析器可能隨線路變化。
• 用戶端或作業系統大版本更新後:網路擴充功能權限、系統代理設定都可能被重設。
• 路由器重新啟動或更換後:下發的 DNS 位址與 IPv6 前綴都會改變。
• 出現「能開啟但很慢」「個別站點打不開」時:先做驗證,再判斷是不是線路側的問題。

把出口 IP 查詢頁加入書籤,三步走完通常不超過兩分鐘。多數「線路故障」在這一步就能定性:是本機接管沒生效,還是線路側確實異常。VPNDX 提供 120+ 國家 / 220+ 線路,涵蓋 IEPL 專線與中轉、直連線路,不限裝置數同時在線,用戶端涵蓋 Windows、macOS、iOS、Android、Linux,採用軍工級加密,註冊無需電子郵件地址,支援支付寶、微信與 USDT 付款,並提供 30 天無理由退款。站內線路頁可以查看線路狀態,與本機驗證結果對照,能更快判斷問題出在哪一端。