確認 VPN 真的生效，不能只看用戶端顯示的「已連線」。這通常只代表本機用戶端與遠端節點完成交握，或系統已建立虛擬網路介面。至於瀏覽器、命令列、遊戲及其他應用程式是否經過預期出口，仍要分別核對出口 IP、DNS 解析路徑與分流結果。
一次可靠的檢查應回答幾個問題：公開網路看到的位址是否改變、位址位置是否符合所選地區、網域查詢交由誰處理、目標應用程式是否進入代理，以及斷線後流量是否會悄悄回到原本的網路。只檢查其中一項，很容易得到看似正常但不完整的答案。
先定義什麼叫真正生效
「生效」不是單一狀態，而是從應用程式到遠端出口的整條路徑都符合設定。用戶端交握成功只是路徑入口；系統路由、代理模式、DNS 設定與應用程式本身的網路堆疊，任何一處繞過設定，最終結果都可能不同。
| 檢查層級 | 應觀察的結果 | 常見誤判 |
|---|---|---|
| 用戶端連線 | 節點交握完成，虛擬介面或本機代理連接埠正常運作 | 把「交握成功」直接等同於所有流量都已轉送 |
| 公開網路出口 | 目標應用程式顯示預期的出口位址、地區與網路歸屬 | 只看地圖標籤，沒有核對業者或位址族 |
| DNS 解析 | 網域請求依照用戶端或系統規則送往預期的解析器 | 出口已改變，卻仍由本地網路直接完成解析 |
| 應用程式分流 | 應代理的應用程式進入線路，應直連的應用程式維持直連 | 只測試瀏覽器，就預設其他程式結果相同 |
| 異常回退 | 節點斷線後的行為符合阻斷或回退設定 | 斷線後自動直連，卻仍以為保護持續有效 |
因此，最小可用的驗證閉環是「連線前記錄、連線後比較、逐一複查應用程式、斷線後觀察」。如果出口與 DNS 都正確，但某個應用程式仍顯示原本的網路，問題通常不在線路本身，而在系統代理涵蓋範圍、應用程式代理設定或分流規則。
用出口 IP 檢查公開網路看到的位址
出口 IP 是最直觀的一層。連線前後，在同一個瀏覽器工作階段開啟可靠的 IP 查詢頁面，比較公開位址、國家或地區、自治系統與網路業者。地區符合預期但業者完全不同，不一定代表異常，因為資料中心、家用寬頻與行動網路位址的登記方式各不相同；但至少應與所選線路的性質相符。
檢查時不要只盯著地圖上的定位點。IP 地理資料庫不一定即時更新，同一個位址區段在不同資料庫中可能被標示為鄰近城市，甚至顯示網路業者的註冊地。對跨境線路而言，國家或地區、自治系統與服務存取結果，通常比城市層級定位更具參考價值。
同時檢查 IPv4 與 IPv6
有些用戶端只接管 IPv4，但裝置仍可透過原本的網路直接傳送 IPv6 請求。此時一般查詢頁面可能剛好使用代理後的 IPv4，看起來已完成切換；支援 IPv6 的應用程式卻可能走另一條路徑。若檢查頁面同時顯示兩種位址族，應分別確認。用戶端未處理 IPv6 時，可依實際需求停用該位址族，或改用能完整接管系統流量的模式。
排除瀏覽器快取與舊連線
瀏覽器可能重複使用連線前建立的工作階段。切換節點後立即重新整理，舊連線未必會立刻重建。較穩妥的做法是關閉相關頁面，等待舊工作階段結束，再開啟新的私密視窗檢查。命令列工具也適合交叉驗證，因為它能避開部分瀏覽器擴充功能、快取與安全 DNS 設定。
- 中斷用戶端連線，記錄目前的公開位址、地區與網路歸屬。
- 連線至目標節點，確認用戶端沒有持續重連或出現交握錯誤。
- 重新開啟查詢頁面，比較出口位址與位址族。
- 再使用另一個不共用瀏覽器設定的工具複查。
- 切換節點後重複檢查，確認出口確實隨線路改變。
檢查DNS 解析 是否繞回本地網路
存取網站前，裝置通常要先將網域解析成位址。網頁內容經過國際線路，不代表網域查詢也走同一路徑。如果 DNS 請求直接交給目前網路提供的解析器，外部仍可能觀察到你查詢了哪些網域；解析結果也可能與出口地區不一致，造成內容分區錯誤或連線至不合適的服務節點。
DNS 檢查頁面通常會列出參與解析的伺服器及其網路歸屬。連線後若看到本地網路業者的解析器，需要繼續排查；但看到與 VPN 出口不同的業者也不一定是外洩，因為公共解析服務會使用分散式節點，頁面顯示的可能是遞迴解析器出口，而不是你的實際位置。
瀏覽器安全 DNS 會改變觀察結果
現代瀏覽器可以自行使用加密 DNS，不完全遵循系統設定。因此同一台裝置上，瀏覽器檢測結果與命令列結果可能不同：瀏覽器將查詢交給自己的解析服務，其他應用程式仍使用系統 DNS。檢查時應先確認瀏覽器是否啟用了獨立的安全 DNS，再判斷這是預期設定，還是繞過了用戶端規則。
Fake IP 與遠端解析不能只看表面位址判斷
部分 TUN 用戶端使用 Fake IP 機制，先為網域配置一個保留用途的映射位址，再由用戶端在內部還原網域並交給遠端解析。應用程式看到的不是網站真實位址，但請求仍可能正確經過隧道。此時不要只憑本地解析結果判定異常，應檢查用戶端日誌中的網域比對、DNS 上游與最終路由。
- ✅ 分別在連線前後執行 DNS 檢查，並記錄解析器的網路歸屬。
- ✅ 比較瀏覽器與系統工具，確認兩者是否使用不同的解析路徑。
- ✅ 查看用戶端 DNS 模式、遠端解析設定與分流規則是否一致。
- ✅ 檢查 IPv4、IPv6 查詢是否都受到預期策略限制。
- ❌ 不要因為解析器地區與節點城市不同，就直接認定發生外洩。
- ❌ 瀏覽器啟用獨立安全 DNS 後，不要仍把結果當作系統 DNS 狀態。
依瀏覽器、命令列與應用程式逐一驗證
瀏覽器能正常使用，不代表所有應用程式都能正常連線。系統代理模式主要影響會主動讀取系統代理設定的軟體；忽略系統代理、自行建立 UDP 工作階段或使用獨立網路堆疊的程式，可能直接連線。TUN 模式通常涵蓋範圍更廣，因為它透過虛擬網路介面接管 IP 流量，但最後仍受路由表、排除項目與系統權限影響。
瀏覽器
先停用可能改寫代理設定的擴充功能，再檢查出口與 DNS。若瀏覽器正常而其他應用程式不正常，表示節點本身大致可用，應將注意力轉向系統代理涵蓋範圍與應用程式設定。若只有某個瀏覽器異常，還要檢查其安全 DNS、代理擴充功能、快取連線與企業政策。
命令列與開發工具
終端機程式是否繼承代理，取決於工具本身與環境變數。部分工具會讀取 HTTP 或 SOCKS 代理變數，部分工具則直接使用系統網路介面。使用本機代理連接埠時，要區分 HTTP 代理與 SOCKS 代理，也要確認網域是在本機解析，還是交由代理端解析。網頁存取正常但套件下載直接連線，常見原因就是命令列工具沒有讀取系統代理。
即時通訊、遊戲與其他獨立應用程式
這類應用程式可能混合使用 TCP、UDP、長連線與自訂 DNS。只看是否成功登入，無法判斷整條路徑。可以先完全結束應用程式，連線節點後重新啟動，再觀察用戶端連線日誌中的目標網域、位址與命中規則。若規則顯示直連，就應調整分流；若規則顯示代理但應用程式仍失敗，再檢查協定對 UDP 的支援、節點入口與目標服務限制。
應用程式分流還有一個容易忽略的方向：規則可能刻意讓本地服務直連。此時不同應用程式顯示不同出口是設計結果，不是故障。驗證的目標不是強迫所有請求走同一路徑，而是確認每一類請求都命中了預期規則。
理解協定與用戶端模式 的界線
Shadowsocks、VMess、Trojan、VLESS、Hysteria2 與 TUIC 都能承載代理流量，但它們不是「安裝後就自動接管所有應用程式」的開關。協定負責用戶端與伺服器之間如何傳輸資料；系統代理、TUN、路由規則與 DNS 模組，才決定哪些本機請求會進入這條傳輸通道。
Shadowsocks 是加密代理協定，通常由用戶端提供本機 SOCKS 或 HTTP 入口。VMess 與 VLESS 常見於支援多種傳輸組合的用戶端，其中 VLESS 本身不依賴協定內建加密，通常會搭配 TLS 或其他安全傳輸。Trojan 使用 TLS 承載流量。Hysteria2 與 TUIC 以 QUIC 概念處理傳輸，在網路抖動或封包遺失環境下，表現不同於傳統 TCP 代理，通常也更重視 UDP 能力。
協定名稱無法直接證明 DNS 已被接管，也無法證明應用程式已進入代理。即使訂閱成功匯入，用戶端仍可能停留在僅系統代理模式；即使啟用 TUN，排除路由或權限失敗也可能讓部分流量繞過。判斷問題時，應將「協定是否連通」與「系統是否正確導流」分開檢查。
訂閱連結與用戶端匯入
訂閱連結通常提供節點名稱、伺服器入口、連接埠、驗證資訊、傳輸參數與 TLS 相關設定。匯入成功只代表用戶端讀懂了設定，不代表節點可連線，更不代表目前已選取該節點。更新訂閱後，還要檢查目前設定是否被替換、群組是否選取正確線路，以及本機覆寫規則是否仍然生效。
Windows 與 macOS 用戶端通常同時提供系統代理與 TUN 選項，但系統權限、路由處理及 DNS 接管方式並不完全相同。Android 常透過系統 VPN 介面建立本機隧道，並可依應用程式納入或排除。iOS 同樣依賴系統提供的網路延伸能力，背景行為與規則實作取決於具體用戶端。跨平台移轉設定時，不應假設同名開關具有完全一致的效果。
直連、中轉與 IEPL 專線 會改變什麼
線路類型描述的是用戶端到出口之間經過何種網路路徑，不是代理協定。直連表示裝置直接連往境外節點入口，路徑簡單，但品質更依賴公網路由。中轉會先連線至較近的入口，再由服務端轉送到最終出口，可避開部分不穩定的公網區段。IEPL 專線通常指跨境專用承載路徑，重點在於入口到出口之間的傳輸組織方式。
無論使用哪種線路，最終驗證方法都不變：公開網路出口是否正確、DNS 是否依策略解析、應用程式是否命中預期出站。線路名稱不能取代結果檢查。中轉入口可能位於本地附近，但公開 IP 查詢應顯示最終出口；若顯示入口位址或原本的網路位址，就要檢查服務端轉送與用戶端路由。
線路可以連線但存取體驗異常，也不應立即歸因於協定。網域解析可能回傳不適合出口地區的位址，分流規則可能將靜態資源送往直連，目標網站也可能依據 IP 信譽或帳戶地區採取不同策略。分開記錄出口、DNS、規則命中與應用程式回應，比反覆切換節點更容易找出原因。
幾種看似連上卻未經過代理 的典型情況
- ❌ 用戶端交握成功，但系統代理開關未啟用，瀏覽器仍使用原本的網路。
- ❌ 瀏覽器讀取了代理，命令列工具卻沒有讀取代理環境，因此下載工作直接連線。
- ❌ IPv4 經過節點，IPv6 維持直連，支援雙堆疊的應用程式出現不同出口。
- ❌ 出口已經改變，DNS 卻仍由目前網路直接解析，導致地區判斷錯位。
- ❌ 分流規則將目標網域歸入直連，但用戶端日誌只顯示節點整體在線。
- ❌ 切換節點後瀏覽器重複使用舊連線，短時間內仍顯示上一條路徑。
- ❌ TUN 權限申請失敗，用戶端回退至涵蓋範圍較窄的系統代理模式。
- ❌ 節點斷線後自動回退直連，應用程式繼續運作，讓人誤以為隧道仍在。
遇到這些情況，先不要同時修改協定、節點、DNS 與分流。一次只改一個變數，再重複同一套出口與解析檢查。否則即使問題消失，也很難知道究竟是哪項設定真正發揮作用，下次故障仍要從頭猜起。
建議保留的檢查順序
- 保存連線前的出口與 DNS 基準資料。
- 確認訂閱已更新，並選取目標節點或策略群組。
- 確認目前使用系統代理還是 TUN，以及相應權限是否正常。
- 檢查 IPv4、IPv6 出口與 DNS 解析路徑。
- 分別測試瀏覽器、命令列與目標應用程式。
- 查看規則命中、出站選擇與錯誤日誌。
- 主動中斷節點，確認應用程式是遭到阻斷還是回退直連。
完整自我檢查的核心並不複雜：先確認公開網路看到哪個出口，再確認網域由誰解析，最後確認具體應用程式命中了哪條規則。連線圖示適合告訴你「用戶端開始運作了」，卻不適合替整條網路路徑背書。網路不會讀心，設定也不會。