出口 IP：最先能確認的一項
連上之後，先開啟站內的 IP 查詢頁面，查看目前的出口 IP 與歸屬地。判斷標準只有一條：歸屬地應該是節點所在地，而不是本地電信業者。如果歸屬地仍是本地城市、組織名稱仍是本地寬頻業者，代表流量根本沒有進入通道，用戶端上的狀態燈只能證明程序在執行。
出口 IP 還要看兩處細節。第一處是 IPv6：瀏覽器與系統預設優先使用 IPv6，如果用戶端只接管了 IPv4，頁面可能直接顯示本地 IPv6 位址，看起來「IP 變了」，其實只變了一半。第二處是 WebRTC：部分瀏覽器會透過 WebRTC 暴露本機位址或區域網路位址，這與代理是否生效無關，需要在瀏覽器設定裡限制或關閉。
只在 IPv4 上生效的連線，遇到支援 IPv6 的目標網站會直接回落本地網路。自查時先看 IP 查詢頁是否同時給出 IPv4 與 IPv6 結果，再確認兩邊的歸屬地是否一致。
如果同一台裝置上還裝著瀏覽器代理擴充功能，擴充功能的優先順序通常高於系統代理。此時系統層面已經接管，瀏覽器卻仍在用擴充功能裡的線路，兩邊出口不同，很容易得出錯誤結論。驗證時先停用擴充功能，或改用一個沒有安裝任何擴充功能的瀏覽器設定檔對照一次。
DNS 外洩自查
DNS 查詢決定「存取的網域由誰解析」。系統預設把查詢送給本地電信業者；代理生效後，查詢應該改由節點一端發出。如果查詢仍然送到本地 DNS，解析請求本身就暴露了要存取的目標，同時可能拿到離本地更近、對目標網站並不合适的 CDN 結果。
自查方式是開啟 DNS 外洩檢測頁，頁面會列出參與解析的伺服器 IP 與歸屬。合格的狀態是解析器落在節點所在地，或至少與出口 IP 處在同一區域；如果列出的全是本地電信業者的解析伺服器，代表解析沒有走代理。
用戶端裡對應的開關通常叫「遠端 DNS」「DNS 走代理」或「防外洩」，不同用戶端措辭不同，作用一致：把解析請求交給通道另一端的解析器。開啟後要重新連線一次再看檢測結果，改完不重連往往不生效。
規則模式裡，中國大陸網域走本地 DNS 解析、直連存取本身就是設計目標。判斷外洩要看被代理的那部分網域——目標網站走代理、解析卻留在本地，才是需要處理的情況。
還有一種情況是應用程式內建的加密 DNS。瀏覽器或系統開啟 DoH / DoT 之後，解析請求走獨立的 HTTPS 連線，可能繞開用戶端設定的 DNS。這類選項在瀏覽器的隱私設定裡，驗證時先關掉，確認基準狀態之後再決定是否恢復。
分應用程式與分流驗證
出口 IP 與 DNS 都正確，仍然可能會有個別應用程式沒走代理。原因有兩類：應用程式不讀取系統代理設定，或者分流規則把目標網域判定成直連。
系統代理（HTTP / SOCKS 代理）依賴應用程式主動讀取系統設定。瀏覽器、系統更新、多數命令列工具會讀，部分桌面應用程式與遊戲用戶端不讀。要涵蓋這些程式，需要用戶端提供 TUN 或虛擬網卡模式，在網路層接管流量，代價是需要更高權限，部分系統上還要額外安裝網路元件。
分流驗證的做法是：先用全域模式確認基礎鏈路暢通，再切回規則模式，逐一開啟實際要用的服務。如果全域模式正常、規則模式下某個服務異常，問題在規則而不在線路。規則清單裡一般能看到命中的項目與走向，按網域或 IP 段補一條規則即可。
分應用程式代理在部分平台可用。開啟之後只有勾選的應用程式走通道，其餘應用程式直連。這種模式適合把工作軟體排除在外，但驗證時容易誤判：沒有勾選的應用程式顯示本地 IP 是預期行為，不是故障。
訂閱匯入也要一併檢查。訂閱連結更新後，用戶端裡的節點清單應隨之重新整理；如果節點名稱與數量長時間不變，可能是訂閱沒有拉取成功，或者用戶端仍在用舊的設定檔。節點清單裡延遲顯示為逾時，代表握手沒有完成，換一條線路再測一次。
看起來已連線卻沒走代理的六種情況
下面幾種情況在排查裡出現頻率最高，共同點是用戶端介面都顯示「已連線」。
- 系統代理沒有寫入。部分用戶端需要手動開啟「設定系統代理」，只連線路不會改動系統設定，瀏覽器之外的流量全部直連。
- 瀏覽器擴充功能覆蓋了系統代理。擴充功能的優先順序更高，兩個出口同時存在，IP 查詢結果取決於目前用的是哪一個。
- IPv6 優先。通道只接管 IPv4 時，支援 IPv6 的目標網站會由瀏覽器直接連上本地網路。
- 分流規則命中直連。規則按網域比對，目標網域被歸入直連分組，出口自然還是本地。
- 應用程式忽略系統代理。桌面應用程式、遊戲用戶端、部分同步工具不讀系統代理設定，必須靠 TUN 模式涵蓋。
- 應用程式內建加密 DNS 或獨立網路堆疊。解析與連線都不經過系統設定，系統代理對它沒有作用。
不同平台用戶端的差異
Windows：系統代理與 TUN 兩種模式
系統代理模式改動的是系統代理項目，瀏覽器和多數應用程式會跟隨；TUN 模式建立虛擬網卡，能接管不讀系統代理的程式，需要系統管理員權限。切換模式之後必須重新連線，否則舊模式殘留的設定還在生效。
macOS 與 iOS：授權沒給等於沒連
macOS 上使用網路擴充功能的用戶端會在系統設定裡請求授權，未授權時連線看似成功，實際沒有接管流量。iOS 走 Network Extension，首次連線必須在系統彈出視窗裡確認，拒絕之後用戶端內的開關不會起作用。
Android：分應用程式清單要自己核對
Android 基於系統的 VpnService，同樣需要彈出視窗授權。它的分應用程式代理更細，驗證時逐項核對勾選清單，比只看總開關更可靠。
協定差異：TCP 與 UDP 的表現不同
Shadowsocks、VMess、Trojan、VLESS 以 TCP 為主，UDP 支援取決於具體實作；Hysteria2、TUIC 基於 QUIC，全程走 UDP。用戶端裡看到的 ss://、vmess://、trojan:// 前綴就對應不同協定。網路對 UDP 限制嚴格時，表現是節點能選取、卻一直連不上，換回 TCP 類協定就能判斷問題出在哪一層。
一張自查表與判斷標準
把上面的檢查項目合成一張表，按現象對照處理即可。
| 現象 | 可能原因 | 處理 |
|---|---|---|
| IP 查詢顯示本地電信業者 | 系統代理未寫入，或 TUN 未啟動 | 檢查代理模式，重新連線 |
| IP 正確，解析器仍在本地 | DNS 沒有走代理 | 開啟遠端 DNS / 防外洩開關後重新連線 |
| 只有瀏覽器走代理 | 系統代理模式涵蓋不到其他程式 | 切換到 TUN / 虛擬網卡模式 |
| 目標網站仍判定為本地 | 分流規則命中直連 | 檢查規則清單，補充網域規則 |
| IPv6 位址仍是本地 | 通道只接管了 IPv4 | 關閉系統 IPv6，或啟用 IPv6 代理 |
| 節點可選但一直逾時 | 協定或連接埠被限制 | 換線路，或改用 TCP 類協定 |
逐項對照下面的結果，全部成立才算真正生效。
- ✅ 出口 IP 歸屬地為節點所在地，IPv4 與 IPv6 結果一致。
- ✅ DNS 檢測頁裡的解析器與出口 IP 處在同一區域。
- ✅ 全域模式下目標服務正常，切回規則模式後仍然正常。
- ✅ 不讀系統代理的桌面應用程式，在 TUN 模式下同樣顯示節點 IP。
- ❌ 只有瀏覽器顯示節點 IP，系統層級應用程式仍是本地位址——代表只寫入了系統代理，沒有接管全域流量。
- ❌ 檢測頁顯示已代理，解析器卻全是本地電信業者——代表 DNS 沒有跟著走。
判斷標準：不需要看用戶端的狀態燈，只需要三項證據同時成立——出口 IP 在節點一端、DNS 解析在節點一端、實際要用的應用程式確實走了通道。三者缺一，就按上面的表逐項排查，問題通常出在代理模式與分流規則，而不是線路本身。
需要對照多條線路時，可選範圍是 100+ 國家與 220+ 線路；不限台數意味著可以讓電腦與行動裝置同時在線對照，其中一端保持預設設定、另一端改成分流模式，差異會非常直觀。訂閱週期內如果發現某條線路長期逾時，直接換線路比反覆重裝用戶端更省時間。
如果自查全部通過、目標服務仍然異常，問題多半在目標網站一側的策略，而不是本地連線。這時換一條同地區的線路做交叉驗證，比繼續在用戶端裡反覆改設定更有效率；需要逐項重現操作時，可以參考使用指南裡的用戶端設定說明。