怎麼確認 VPN 真的生效：出口 IP、DNS 與 分應用 三步驗證
連上了不等於走對了：查出口 IP、查 DNS、分應用程式驗證三步走，並列出「看起來連上其實沒走」的幾種常見情況。
用戶端狀態燈亮著，網頁打開卻還是原來的樣子——這是「怎麼確認 VPN 真的生效」最常見的提問。答案不是再看一眼連線狀態，而是按三個層面依序核對：出口位址有沒有真的換掉、網域名稱解析有沒有跟著隧道走、正在使用的那個應用程式有沒有被納入代理。三步都過，才算走對了；只過第一步就收工，漏掉的往往正是後面兩層。
為什麼「已連線」不等於生效
狀態燈只說明一件事：本機到節點這一段的隧道已經建立。它不說明流量有沒有被接管，不說明接管之後走了哪條規則，也不說明網域名稱解析跟著走了沒有。這三件事分別由用戶端的接管模式、分流規則和 DNS 設定決定，任何一環出偏差，表現都是「顯示已連線，實際沒走」。
接管方式常見三種。系統代理只對讀取系統代理設定的程式生效，瀏覽器通常會讀，很多桌面用戶端不讀；TUN 虛擬網卡在網路層接管 IP 流量，覆蓋面最廣；分應用程式代理只把名單裡的應用程式送進隧道，名單外的應用程式照舊直連。判斷「是否生效」的方法，取決於目前用的是哪一種。
協定是另一層。Shadowsocks、VMess、VLESS、Trojan 負責把流量封裝後送到節點，Hysteria2、TUIC 基於 QUIC、以 UDP 承載，弱網環境下更穩。協定決定的是「怎麼送」，不決定「哪些流量被送」，所以換協定修不好分流誤判，只能改善鏈路品質。
訂閱連結只是節點清單的載體。用戶端匯入訂閱後按連結裡的節點清單產生設定；訂閱過期或連結失效，節點清單不再更新，但本機已儲存的節點仍可能握手成功。這類情況下狀態燈同樣會亮，實際卻轉發不出去。
第一步：核對出口 IP 與 所在地
先記錄基準。連線之前，在瀏覽器打開任意位址查詢頁，或在終端機執行一條指令，把目前的出口位址與所在地記下來。
# 連線前：記錄出口位址與所在地
curl -s https://ipinfo.io/json
# 連線後：ip 與 country 兩項都應該改變
curl -s https://ipinfo.io/json連上節點之後，換一個無痕視窗再查一次。用無痕視窗是為了排除快取與瀏覽器擴充功能的干擾——有些代理類擴充功能會自行接管請求，讓結果看起來與用戶端無關。
判斷標準只有兩條：位址變了；所在地與所選節點所在區域一致。兩條同時滿足，才說明流量確實從境外出口出去。
有幾種情況需要區別對待。公開的位址歸屬資料庫之間存在差異，任播位址與跨國廣播位址可能顯示為鄰近區域，這不算異常；串流平台用的是自己的判定資料庫，不以公開資料庫為準，所以「位址歸屬正確、平台仍按本地顯示」是可能出現的結果。反過來，位址沒變也不一定是故障：分流模式下存取境內網站本來就該走本地出口，需要測的是境外網站那一次請求。
分流模式下存取境內網站顯示本地位址是設計如此。測出口位址時，務必用一個確定會走代理的境外網站，或暫時切到全域模式再測一次做對比。
第二步：確認網域名稱解析沒有落回本地
DNS 洩漏指的是：流量進了隧道，網域名稱解析請求卻沒有跟著進去，而是發給了本地電信商。後果有兩層——存取清單暴露給本地解析方，以及解析結果按本地位置回傳，於是出現「出口位址是境外的，拿到的內容還是本地的」。
驗證方法並不複雜：打開一個 DNS 洩漏檢測頁，它會列出實際應答的解析伺服器及其歸屬。正常表現是應答伺服器位於出口地區，或屬於服務商下發的 DNS；異常表現是應答伺服器為本地電信商。檢測時同樣用無痕視窗，避免瀏覽器快取的解析結果干擾判斷。
分流模式下有一個例外：境內網域走本地 DNS 是設計如此，不算洩漏。要看的是境外網域那一部分的應答伺服器。
瀏覽器內建的安全 DNS（DoH）會繞過系統與用戶端的 DNS 設定，直接向第三方解析伺服器發查詢，這是「IP 對了、內容還是本地」的高頻原因。檢測前先在瀏覽器設定裡確認「使用安全 DNS」的狀態，關閉後再測一次做對比。
IPv6 是同一類問題的另一面。隧道只接管 IPv4 時，支援 IPv6 的網站會從本地 IPv6 出口出去，檢測頁回傳的就是本地位址。處理方式有兩種：在系統裡關閉 IPv6，或讓用戶端接管 IPv6 流量。
第三步：分應用與分流規則逐項確認
第三層最容易被跳過，因為它不在用戶端主畫面上。分應用程式代理的邏輯是「只代理名單裡的應用程式」：名單外的應用程式即使隧道已經建立，流量依舊直連。核對方式是打開用戶端的分應用程式清單，逐項確認要用的應用程式在不在裡面，改完名單後重新啟動目標應用程式——多數程式只在啟動時讀取一次代理設定。
平台之間的差異
桌面端常見系統代理與 TUN 兩種模式，TUN 覆蓋所有程式，系統代理只覆蓋讀取系統設定的程式；Android 用戶端普遍提供依應用程式代理；iOS 受系統限制，通常以整條隧道的方式運作，沒有同等的依應用程式開關；Linux 上多為命令列與系統代理，需要手動設定 http_proxy、https_proxy 環境變數，或改用 TUN 模式。同一份訂閱在不同平台上表現不一致，多數時候是這一層造成的。
分流規則怎麼影響判斷
規則通常按網域後綴、GeoIP 地區、行程名稱比對，命中直連的網域不會進隧道。判斷方法很直接：把用戶端暫時切到全域模式，再存取同一個網站。切全域後正常、切回分流又不正常，問題就在規則，而不是節點。線路類型（IEPL 專線、中轉、直連）影響的是鏈路穩定性與繞行路徑，不會改變「哪些流量被代理」，排查時不要把兩者混在一起。
| 層面 | 怎麼查 | 正常表現 | 異常訊號 |
|---|---|---|---|
| 出口位址 | 連線前後各查一次位址與所在地 | 位址改變，所在地與節點地區一致 | 位址未變，或所在地與節點不符 |
| 網域名稱解析 | DNS 洩漏檢測頁 | 應答伺服器在出口地區，或為服務商下發 | 應答伺服器是本地電信商 |
| 分流規則 | 切全域模式，對比同一網站 | 全域與分流結果一致 | 只有全域模式正常 |
| 分應用程式 | 用戶端的分應用程式清單逐項核對 | 目標應用程式在代理名單內 | 應用程式不在名單，實際走直連 |
| IPv6 | 支援 IPv6 的檢測頁 | 與 IPv4 出口一致，或不回傳 | 回傳本地 IPv6 位址 |
七種 常見情況：狀態正常卻沒走隧道
下面這些情況，狀態燈都是正常的，實際卻沒有按預期走。按現象對照排查，比反覆重新連線有效。
| 現象 | 常見原因 | 處理 |
|---|---|---|
| 狀態已連線，瀏覽器仍顯示本地位址 | 用戶端處於系統代理模式而該程式不讀系統代理；或網域命中直連規則 | 改用 TUN 模式，或把網域加入代理規則後重測 |
| 出口位址正確，部分網站仍按本地顯示 | 瀏覽器安全 DNS 繞過用戶端 | 關閉瀏覽器安全 DNS 後重測 |
| 只有某個應用程式不走隧道 | 該應用程式不在分應用程式名單裡 | 勾選後重新啟動應用程式再試 |
| 檢測頁回傳本地 IPv6 位址 | 隧道只接管 IPv4 | 關閉系統 IPv6，或讓用戶端接管 IPv6 |
| 換節點後仍打不開，過一會又正常 | DNS 快取與連線重用 | 用無痕視窗或清除快取後重測 |
| 所有境外網站都打不開 | 訂閱過期、流量用盡或節點故障 | 查看訂閱狀態，換節點或換線路類型複測 |
| 連線時提示憑證或時間錯誤 | 系統時間偏差過大，握手階段就失敗 | 同步系統時間後重新連線 |
一次完整的 自查清單
把上面三層合成一份可以照著做的清單。每次換節點、換裝置、換網路之後走一遍，通常兩三分鐘。
- ✅ 連線前記錄一次本機出口位址與所在地，作為對照基準。
- ✅ 連線後用無痕視窗複查出口位址，排除快取與擴充功能干擾。
- ✅ 用 DNS 洩漏檢測確認應答伺服器不在本地電信商。
- ✅ 明確目前是全域還是分流模式，知道目標網域走哪條規則。
- ✅ 在分應用程式清單裡逐項核對要用的應用程式，改完重新啟動應用程式。
- ✅ 關閉或統一瀏覽器內建的安全 DNS，避免繞過用戶端。
- ✅ 檢查訂閱有效期與剩餘流量，確認節點清單是最新的。
- ✅ 同步系統時間，避免在握手階段就失敗。
- ❌ 只看用戶端狀態燈就認定已經生效。
- ❌ 用同一個分頁反覆重新整理來判斷結果。
- ❌ 用延遲或頻寬數字判斷出口是否正確，兩者不是一回事。
把三步固定成習慣
三步的順序不能顛倒：先確認出口位址變了，再確認解析跟著走，最後確認正在用的應用程式在代理範圍內。順序顛倒的代價是誤判——只看了第一步就認為一切正常，後面兩層的偏差會被帶進日常使用，表現成「有時候能打開、有時候不能」。
結論：出口位址、網域名稱解析、分應用程式與分流，三層都通過才算真的生效。任何一層異常，先用全域模式做一次對照測試，就能把問題定位到規則、DNS 還是應用程式本身，而不是在節點之間反覆切換。
本服務目前提供 90+ 國家 / 160+ 線路，用戶端涵蓋 Windows、macOS、iOS、Android、Linux，不限台數，不記錄日誌，7 天無條件退款；註冊只需使用者名稱與密碼，無需電子郵件地址。換節點之後按上面的三步複測一遍，比憑感覺判斷更省時間。