用戶端圖示變綠、狀態寫著「已連線」，打開網頁卻還是原本的速度、原本的內容——這是「VPN 連上了卻沒生效」最典型的樣子。問題通常不在線路本身，而在流量有沒有真的被送進線路：系統代理模式只對會讀取代理設定的應用程式生效，分流規則可能把目標網域判定成直連，DNS 解析也可能根本沒走線路。判斷方法不複雜，順序是固定的：先查出口 IP，再查 DNS，最後按應用程式逐一驗證。三步走完，絕大多數「看起來連上了、其實沒走」的情況都能定位到具體原因。
為什麼「已連線」不等於真的生效
用戶端和線路之間建立連線，只說明控制通道通了：節點資訊拿到了、認證過了、心跳也正常。流量有沒有真的進入這條通道是另一回事，取決於三個變數——用戶端的工作模式、分流規則，以及你正在用的那個應用程式是否讀取代理設定。
常見的工作模式有三種，涵蓋範圍差別很大：
- 系統代理模式：用戶端修改的是作業系統的代理設定（HTTP / SOCKS）。只有主動讀取這項設定的應用程式才會走線路。大多數瀏覽器會讀，終端機、部分桌面軟體和遊戲啟動器不會。
- TUN / 虛擬網卡模式：用戶端在系統裡建立一張虛擬網卡並接管路由表，多數應用程式的流量被整體接管，不再依賴應用程式自己去讀代理設定。
- 全域 / 規則模式：這是「哪些流量走線路」的策略。全域把所有請求都送進線路；規則模式按網域、IP 段、地區清單逐條判斷，命中直連規則的網域不會經過線路。
所以「已連線」只是必要條件。要判斷是否真的生效，得看實際資料：出口 IP 變了沒、DNS 解析走了誰、每個具體應用程式拿到的來源位址是什麼。
同一個「沒生效」現象，在系統代理模式和 TUN 模式下的原因完全不同。打開用戶端設定，確認目前處於哪種模式，後面的檢查才有方向。
查出口 IP：比對連線前後的位址
出口 IP 是判斷生效與否最直接的證據。流量走了線路，外部網站看到的來源位址就是線路落地的位址；沒走線路，看到的還是本地寬頻或行動網路的位址。做法只有四步：
- 連線之前，先打開一個會顯示來源位址的頁面，記下位址和歸屬地。
- 連上線路，等狀態穩定 5~10 秒再操作。
- 重新整理同一個頁面，比對前後兩次的位址。
- 換一個查詢來源再查一次，排除頁面快取造成的誤判。
| 比對結果 | 說明 | 下一步 |
|---|---|---|
| 位址變了，歸屬地與所選節點一致 | 資料通道已經生效 | 繼續檢查 DNS 與應用程式 |
| 位址完全沒變 | 目前應用程式的流量沒有進入線路 | 檢查工作模式與分流規則 |
| 位址變了，歸屬地卻不是所選地區 | 入口與落地可能不在同一地區，或頁面顯示的是 CDN 邊緣位址 | 換查詢來源交叉驗證，再看用戶端的節點詳情 |
出口 IP 與線路類型的關係
直連、中轉與 IEPL 專線改變的是「從本地到落地」這段路徑：直連由用戶端直接連到境外節點，走公共國際出口；中轉先連到中轉伺服器，再由它轉發到境外落地；IEPL 專線走國際乙太網路專線鏈路，不經過公共網際網路出口。三者影響的是延遲與封包遺失的穩定性，而出口 IP 由落地節點決定——換節點會換出口位址，把直連換成中轉並不會改變歸屬地。
查 DNS：解析請求去了哪裡
網域要先被解析成 IP 位址，連線才能建立。如果 DNS 查詢沒有走線路，而是交給本地電信業者的解析器，通常有兩個後果：存取目標在解析階段就暴露給本地網路；解析結果可能指向鄰近但不可達、甚至被污染的位址，表現就是「連上了卻打不開」或「時好時壞」。
檢查方式有兩種：
- 打開一個 DNS 洩漏檢測頁面，看它列出的解析伺服器。清單裡如果出現本地電信業者的位址，說明解析請求沒有走線路。
- 用命令列確認。Windows 執行
nslookup example.com；macOS / Linux 執行dig +short example.com；macOS 還可以用scutil --dns查看目前的解析器順序。
DNS 沒走線路的三個常見原因
- 瀏覽器自己開了安全 DNS（DNS over HTTPS）。瀏覽器直連 DoH 伺服器，繞過系統 DNS，用戶端接管不到。處理方式：在瀏覽器設定裡把安全 DNS 關掉，或改成「跟隨系統」。
- 用戶端只代理了 TCP，沒有接管 UDP 53。處理方式：在用戶端裡開啟 DNS 接管或遠端解析相關選項。
- 分流規則把 DNS 請求判定成直連。處理方式：檢查規則清單，讓 DNS 跟隨代理。
如果本地網路配發了 IPv6 位址，而線路只代理 IPv4，一部分流量可能繞過線路走 IPv6 直連。要嘛在用戶端裡開啟 IPv6 支援，要嘛暫時關掉系統的 IPv6 再測一次。
按應用程式逐個驗證：瀏覽器通了不代表終端機通了
瀏覽器是最容易被代理涵蓋的應用程式，所以只測瀏覽器，結論往往過於樂觀。更穩妥的做法是挑三類典型情境各測一次。
- 瀏覽器：打開會顯示來源位址的頁面，確認位址與所選節點地區一致。
- 終端機：Windows 10 / 11 內建 curl，直接執行
curl https://api.ipify.org；PowerShell 用Invoke-RestMethod https://api.ipify.org；macOS / Linux 用curl -s https://api.ipify.org。 - 桌面軟體與行動裝置：郵件用戶端、同步雲端硬碟、遊戲啟動器多數不讀系統代理，需要在應用程式內單獨設定，或依賴 TUN 模式；手機上切換 Wi-Fi 與行動網路之後，要重新確認一次。
終端機與瀏覽器結果不一致怎麼辦
如果瀏覽器顯示的是線路位址，終端機回傳的卻是本地位址，基本上可以確定目前是系統代理模式——終端機預設不讀系統代理。兩種處理方式：開啟用戶端的 TUN 模式，讓路由層接管；或者只給目前的終端機工作階段臨時指定代理。
# 只給目前終端機工作階段指定代理，連接埠以用戶端介面顯示的本地連接埠為準
export https_proxy=http://127.0.0.1:7890
export http_proxy=http://127.0.0.1:7890
# 再次確認出口位址
curl https://api.ipify.orgWindows PowerShell 裡對應的寫法是 $env:https_proxy="http://127.0.0.1:7890"，只在目前視窗有效，關掉視窗即失效。
看起來連上了，其實沒走的常見情況
下面這張對照表涵蓋了新手最常遇到的幾類情況。檢查順序建議由上往下：先確認整體是否生效，再處理單一應用程式或單一網站的例外。
| 現象 | 可能原因 | 處理方向 |
|---|---|---|
| 出口 IP 前後完全一致 | 用戶端處於系統代理模式，目前應用程式不讀代理設定 | 切換到 TUN 或全域模式，或給該應用程式單獨設定 |
| 瀏覽器正常，終端機回傳本地位址 | 終端機預設不讀系統代理 | 開啟 TUN 模式，或設定 http_proxy / https_proxy 環境變數 |
| 個別網站不走線路，其他都正常 | 分流規則把該網域判定成直連 | 查看用戶端的連線紀錄與規則命中，把網域加入代理清單 |
| 換了節點，出口位址還是原來那個 | 節點沒有真正切換，或舊連線仍在使用 | 中斷連線後重新連線，並在用戶端裡確認目前選取的節點 |
| DNS 檢測頁出現本地電信業者的解析器 | 瀏覽器安全 DNS 繞過系統解析，或用戶端沒有接管 DNS | 關閉瀏覽器的安全 DNS，開啟用戶端的 DNS 接管 |
| 換一個協定就能連，原來的連不上 | 網路環境丟棄了 UDP 封包 | 改用可走 TCP 傳輸的協定對比測試 |
| 網頁能開，語音通話仍走本地 | WebRTC 或應用程式內建的 P2P 直連繞過了代理 | 關閉瀏覽器的 WebRTC，或在應用程式內限制直連 |
| 狀態顯示已連線，實際完全沒有網路 | 系統裡殘留了舊代理設定，指向已經關閉的軟體連接埠 | 檢查系統代理設定，重設為自動或關閉後重新連線 |
Hysteria2、TUIC 這類協定基於 QUIC，依賴 UDP；Shadowsocks、VMess、Trojan、VLESS 可以走 TCP 傳輸。遇到「節點正常卻連不上」時，先換傳輸方式，再考慮換節點——公司網路與校園網路丟棄 UDP 的情況並不少見。
三步自查清單與結論
把上面的內容濃縮成一份可以照著做的清單，每次換網路環境、換節點之後重跑一遍：
- ✅ 連線前後各查一次出口 IP，位址有變化，且歸屬地與所選節點地區一致。
- ✅ DNS 檢測頁列出的解析伺服器裡，沒有本地電信業者的位址。
- ✅ 終端機
curl與瀏覽器回傳同一個出口位址，不只是瀏覽器生效。 - ✅ 真正要用的應用程式逐一打開驗證一次，而不是只測瀏覽器首頁。
- ✅ 切換 Wi-Fi 與行動網路之後重新確認一次，不要沿用上一次的結論。
如果問題反覆出現在同一段線路上，例如晚間尖峰時段持續封包遺失、UDP 類協定長期被阻擋，那就不是用戶端設定能解決的了，該考慮線路類型。VPNBF 提供 100+ 國家、230+ 線路，包含 IEPL 專線與中轉線路，線路全程軍規級加密，不限台數同時在線，支援 Windows / macOS / iOS / Android / Linux；註冊只需使用者名稱和密碼，無需電子郵件地址；7 天無理由退款，流量包永久不過期。
- 100+國家與地區
- 230+線路可選
- 不限台數同時在線
- 7 天無理由退款