為什麼「已連線」不等於流量走了線路
打開用戶端,狀態變成「已連線」,只代表本機與線路伺服器之間的通道建立成功。流量有沒有真的進入這條通道,還要看用戶端的工作模式、分流規則,以及應用程式本身的網路行為——這三件事與「已連線」是分開的。
工作模式通常分兩類。系統代理模式只改寫系統的代理設定,只有讀取這份設定的應用程式才會把請求交給通道:瀏覽器一般會讀,部分桌面應用程式不讀。TUN / 虛擬網卡模式會在系統裡建立一張虛擬網卡並接管路由表,絕大多數應用程式的流量都會被送進通道,包括不讀系統代理的應用程式。同一個訂閱,在兩種模式下驗證結果可能完全不同。
第二層是分流規則。規則清單把網域或 IP 分成直連、走代理、拒絕幾組;如果目標網域被判定為直連,即使通道完全正常,這次存取走的也是本地出口。規則集過舊,或不同用戶端內建的預設規則不同,就會出現「同一個網站,有的裝置走了線路、有的沒走」。
第三層在應用程式自己身上。部分應用程式內建獨立網路堆疊,不讀系統代理;部分應用程式優先使用 IPv6,而通道只接管了 IPv4;基於 UDP 的流量(QUIC、語音通話、部分遊戲)在只支援 TCP 轉送時會被退回或直連。這些情況都會造成「用戶端顯示已連線、應用程式卻仍是本地出口」。
判斷是否生效,不看用戶端狀態,只看三個外部證據:出口 IP 的歸屬地、DNS 解析伺服器的歸屬地、目標應用程式的實際可用性。
三步自查:出口 IP → DNS → 應用實測
三步按「從外到內」的順序排列:先確認流量有沒有進通道,再確認通道內的解析是否乾淨,最後確認具體應用程式在真實情境下能不能用。
- 中斷與連線各查一次出口 IP,比對國家 / 地區與電信業者歸屬。
- 查 DNS 解析由哪一台伺服器完成,確認解析請求沒有落到本地電信業者。
- 對真正要用的應用程式逐一實測,而不是只打開一個網頁看看。
三步是遞進關係,任何一步不通過,都代表「已連線」還沒有轉化為「已生效」。定位到具體是哪一步出問題,再決定是換線路、改模式,還是更新規則。
第一步:查出口 IP,看地區是否與所選線路一致
查出口 IP 的工具很多,重點是「比對」:先中斷連線查一次並記錄結果,再連上線路、用無痕視窗查一次,兩次放在一起看。命令列方式適合需要反覆驗證的情境。
# 查目前出口 IP(Windows / macOS / Linux 通用)
curl -s https://ifconfig.me
# 需要地區與電信業者資訊,可以改用回傳 JSON 的查詢介面
curl -s https://ipinfo.io/json網頁方式更直觀:打開任一 IP 查詢頁,同時看 IPv4 與 IPv6 兩項。只有一項變了,代表另一項還在走本地出口。
| 連線後看到的出口 | 說明 | 處理 |
|---|---|---|
| 與所選線路的國家 / 地區一致 | 流量已進入通道 | 繼續第二步 |
| 仍是本地電信業者與本地城市 | 流量沒有進通道 | 檢查工作模式與分流規則 |
| 是所選國家,城市與線路標註不同 | 出口池調度,屬正常現象 | 無需處理 |
| IPv4 變了,IPv6 仍是本地位址 | IPv6 未接管,存在洩漏 | 開啟 IPv6 接管,或暫時關閉系統 IPv6 |
查 IP 前先關掉瀏覽器裡的代理類外掛,並用無痕視窗重新打開查詢頁。外掛代理會覆蓋系統代理,頁面快取也會讓你讀到上一次的結果。
第二步:查 DNS 解析,確認沒有洩漏
DNS 洩漏指的是:網頁流量走了通道,但網域名稱解析請求仍然送給了本地電信業者的 DNS。它有兩個後果——存取意圖暴露給本地解析方;解析結果指向離本地最近的節點,導致片庫不符或速度異常。DNS 洩漏不會讓用戶端斷線,所以只看連線狀態永遠發現不了。
檢查方法有兩種。瀏覽器裡打開 DNS 洩漏檢測頁,頁面會列出這次解析用到的伺服器及其歸屬地;命令列裡看解析伺服器的位址,同樣可以判斷。
# macOS / Linux:查看解析伺服器
dig example.com | grep SERVER
# Windows:查看解析伺服器與解析結果
nslookup example.com判讀標準很直接:解析伺服器的歸屬地應與線路所在地區一致,或顯示為通道內部的 DNS 位址。如果顯示的仍是本地電信業者的解析伺服器,代表解析請求沒有走通道。
改過 DNS 設定或切換線路之後,先重新整理系統 DNS 快取再複查,否則看到的還是舊結果。
# Windows
ipconfig /flushdns
# macOS
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
# Linux(systemd-resolved)
sudo resolvectl flush-caches第三步:分應用程式驗證,別只看瀏覽器
瀏覽器是最容易走代理的應用程式,因為它會讀取系統代理設定。真正決定體驗的往往是其他應用程式。驗證時按實際使用情境來,而不是隨便打開一個網頁就算通過。
| 應用程式類型 | 驗證動作 | 生效表現 |
|---|---|---|
| 瀏覽器存取國際網站 | 打開目標網站並登入 | 頁面正常,地區提示與線路一致 |
| 串流播放頁 | 打開播放頁並播放一分鐘 | 片庫與線路地區一致,播放不中斷 |
| AI 工具 | 發起一次長對話 | 工作階段保持,不出現地區限制提示 |
| 應用程式商店 / 系統更新 | 查看商店區域與下載來源 | 區域與線路地區一致 |
命令列與開發工具單獨驗證
git、套件管理器這類命令列工具預設不讀系統代理,需要設定 HTTP_PROXY / HTTPS_PROXY 環境變數,或改用 TUN 模式由虛擬網卡接管。驗證方式和瀏覽器一致:在命令列裡查一次出口 IP,與瀏覽器裡看到的結果比對,兩邊不一致就代表有一邊沒走通道。
「看起來連上了其實沒走」的幾種常見情況
下面這些現象在排查中出現頻率最高,按「現象 → 原因 → 處理」對號入座即可。
| 現象 | 常見原因 | 處理 |
|---|---|---|
| 瀏覽器顯示本地地區,其他應用程式正常 | 瀏覽器裝了代理類外掛,覆蓋了系統代理 | 關閉外掛後重測 |
| 瀏覽器正常,桌面應用程式提示地區不符 | 該應用程式不讀系統代理 | 切換 TUN 模式,或在應用程式內單獨填寫代理 |
| 剛連上可用,過一會兒失效 | 分流規則把目標網域判為直連,或規則集過期 | 更新訂閱與規則集後重測 |
| 多數網站正常,個別網站仍顯示本地位址 | 該站走 IPv6,而通道只接管了 IPv4 | 開啟 IPv6 接管,或暫時關閉系統 IPv6 |
| 網頁能開,語音 / 遊戲 / QUIC 流量異常 | 目前模式不支援 UDP 轉送 | 切換支援 UDP 的協定或線路類型 |
| 換一個用戶端後結果不同 | 兩端預設模式與規則集不一致 | 統一模式與規則集後重新比對 |
換個用戶端,結果為什麼不一樣
訂閱連結只承載線路資訊——伺服器位址、連接埠、協定參數,不承載「怎麼用」的策略。同一個訂閱匯入不同用戶端,預設模式可能是全域、規則或直連;規則集也可能一份來自用戶端內建、一份來自訂閱方,比對順序不同,結果就不同。
協定差異同樣會影響驗證結果。Shadowsocks、VMess、Trojan、VLESS 以 TCP 為主,部分實作支援 UDP 轉送;Hysteria2、TUIC 基於 QUIC,天生走 UDP,在 UDP 受限的網路裡可能連不上或表現不穩。如果出口 IP 與 DNS 兩步都通過、只有某類應用程式異常,先懷疑協定與 UDP 支援,而不是線路本身。不同線路類型(直連、中轉、IEPL 專線)的差異,可以參考節點頁的說明。
平台之間也有差別:桌面端可以建立虛擬網卡接管全部流量;行動端受系統限制,通常按設定檔或按應用程式接管;路由器端整網接管,但要單獨確認 DNS 是否也被轉送。
判斷是否生效,以出口 IP、DNS 解析、目標應用程式三項同時通過為準。只憑用戶端狀態或某一次網頁能否打開下結論,都會誤判。
一張可重複使用的自查清單
把上面的步驟壓縮成一份清單,換裝置、換線路、換用戶端之後照著走一遍即可。更完整的用戶端匯入操作見使用教學。
- ✅ 中斷連線,記錄本地出口 IP 與 DNS 解析伺服器,作為對照
- ✅ 連上線路後,用無痕視窗複查出口 IP,確認與所選線路地區一致
- ✅ 同時查看 IPv6 位址,確認沒有繞過通道
- ✅ 重新整理 DNS 快取後複查解析伺服器歸屬地
- ✅ 對真正要用的應用程式逐一驗證,不只看瀏覽器
- ✅ 更換線路、用戶端或規則集後,把這套步驟重新走一遍
這套步驟一次只需要幾分鐘,卻能把「感覺連上了」和「確認生效了」分開。先定位是哪一步不通過,再決定換線路、改模式還是更新規則,比反覆重連有效得多。
常見問題
用戶端顯示已連線,但網頁打不開,是不是沒生效?
已連線只代表通道建立成功。網頁打不開可能是分流規則把目標網域判成了直連、解析請求沒有走通道,或者線路目前壅塞。按出口 IP → DNS → 應用程式三步排查,通常能定位到具體環節,再決定是改模式、更新規則還是換線路。
只有一個應用程式不走線路,需要換線路嗎?
通常不需要。先看這個應用程式是否讀取系統代理、是否內建獨立網路堆疊,再考慮切換 TUN 模式或在應用程式內單獨填寫代理。線路本身的問題會影響所有應用程式,而不是只影響某一個。
換裝置之後還要重新驗證嗎?
要。驗證結果與裝置上的工作模式、規則集、DNS 設定綁定,和帳號本身無關。同一個訂閱在新裝置上匯入後,建議把三步自查重新走一遍,尤其是行動端與桌面端之間切換時。
為什麼行動端和桌面端的結果不一樣?
行動端對背景流量與虛擬網卡的限制更多,通常按設定檔或按應用程式接管;桌面端可以整機接管。比對之前,先確認兩端的模式與規則集是否一致,否則結論沒有可比性。