VPN 連線後如何確認真的生效，不能只看客戶端中的「已連線」。這個狀態通常只能表示客戶端已完成握手，或已建立與伺服器的工作階段；無法單獨證明瀏覽器、下載工具及其他應用程式的流量都經過預期線路。可靠的驗證方式是先記錄原本的網路狀態，再核對出口 IP 與 DNS，最後逐一驗證各應用程式的實際路徑。
這套檢查不依賴特定協定。Shadowsocks、VMess、Trojan、VLESS、Hysteria2、TUIC，以及由系統接管的 VPN 設定，都可能因代理模式、分流規則、權限狀態或應用程式本身的設定，出現「客戶端在線上，但目標流量未進入線路」的情況。協定握手成功只是起點，流量路徑才是最終結果。
先了解「已連線」實際代表什麼
客戶端顯示已連線，通常表示本機客戶端與遠端節點可以通訊、驗證資訊有效，且協定工作階段已建立。不同客戶端對狀態的判定不完全相同：有些在握手完成後立即顯示連線成功，有些則會等到系統代理、虛擬網卡或路由規則寫入完成後才更新介面。
因此，連線狀態與流量接管是兩個檢查點。前者回答「客戶端能否連絡節點」，後者回答「指定應用程式送出的要求是否進入這條路徑」。如果系統代理未寫入、虛擬網卡權限未生效、分流規則命中直連，或應用程式繞過系統代理自行連線，就會出現狀態正常但出口不變的現象。
| 觀察位置 | 可以證明 | 無法單獨證明 |
|---|---|---|
| 客戶端連線狀態 | 本機客戶端與節點的工作階段已建立 | 所有應用程式都經過節點 |
| 出口 IP 查詢 | 目前的查詢要求從哪個公網地址離開 | 其他應用程式採用相同路徑 |
| DNS 查詢結果 | 網域名稱解析要求由哪些解析器處理 | 網頁內容要求一定經過相同線路 |
| 目標應用程式實測 | 該應用程式在目前規則下可以完成實際要求 | 系統內其他應用程式也已被接管 |
檢查時還要區分代理客戶端與系統層級隧道。瀏覽器代理通常只處理遵循系統代理設定的程式；虛擬網卡模式會在網路層接管更多流量，但仍可能受到路由表、排除規則與本機網路保護規則影響。不能因為某個應用程式的出口已改變，就推斷整台裝置的所有連線都已改變。
第一步：比較出口 IP 與歸屬地
出口 IP 是最直接的起點。中斷線路後，開啟可信任的 IP 查詢頁面，記錄公網 IP、網路業者歸屬與大致地區。接著連線至目標線路，關閉剛才的查詢頁面並重新開啟，或強制重新整理，再觀察結果是否改變。
- 在客戶端中中斷線路，確認網路恢復為平常的連線狀態。
- 查詢目前的公網出口，記錄地址、網路歸屬與地區資訊。
- 連線至準備使用的節點，等待客戶端完成路由或代理設定。
- 重新發起查詢，不要只讀取舊分頁中已載入的結果。
- 比較連線前後的公網地址，並核對新地址是否符合所選線路的預期地區。
- ✅ 公網 IP 已變更，歸屬地與目標線路基本一致，可以繼續檢查 DNS 與應用程式路徑。
- ✅ IP 已變更但地區顯示為鄰近城市，先交叉查詢，不要只根據單一地理資料庫判定失敗。
- ❌ 公網 IP 完全未變，優先檢查代理模式、虛擬網卡權限、系統代理寫入與分流規則。
- ❌ 瀏覽器出口已變更而其他應用程式未變，表示目前設定可能只接管瀏覽器，或只接管遵循系統代理的程式。
IP 地理位置資料庫可能有更新延遲，同一個地址在不同查詢服務中可能顯示不同城市。驗證時應更重視公網地址是否變更、網路歸屬是否合理，以及國家或地區是否符合預期，不要把城市層級標籤視為精確定位。如果幾個查詢來源顯示的地區不同，可以結合目標網站實際回傳的區域內容繼續判斷。
第二步：檢查 DNS 是否經過預期路徑
造訪網站前，裝置通常要先將網域名稱解析為可連線的地址。如果內容要求經過線路，而 DNS 仍交由原本網路提供的解析器處理，就可能暴露本地網路的解析路徑，也可能因解析結果與出口地區不一致而導致存取異常。這類情況通常稱為 DNS 洩漏。
檢查時應分別在中斷與連線狀態下執行 DNS 查詢測試，比較解析器的網路歸屬與地區。連線後仍看到本地網路常用的解析器，不一定代表內容流量沒有經過線路，但表示 DNS 路徑需要繼續核對。較穩妥的設定是讓客戶端依設計接管 DNS，並使解析策略與代理規則保持一致。
DNS 結果不必機械式地要求與出口 IP 完全位於同一城市。服務商可能使用公共解析器、任播解析器或遠端轉送，顯示的組織名稱也可能與節點營運方不同。真正需要留意的是：連線前後解析路徑完全沒有變化、出現明顯屬於原網路的解析器，或在不同規則下持續得到與目標地區衝突的解析結果。
瀏覽器加密 DNS 會改變測試意義
部分瀏覽器可以啟用獨立的加密 DNS。啟用後，瀏覽器可能繞過作業系統的預設解析設定，直接向瀏覽器指定的解析服務發出要求。此時，網頁測試呈現的是瀏覽器本身的 DNS 路徑，不一定代表系統內其他應用程式。
排查時可以先確認瀏覽器是否啟用了獨立解析，再決定測試目標：如果要檢查系統 DNS，應使用遵循系統設定的工具；如果要檢查瀏覽器的實際存取路徑，則保留瀏覽器目前的設定。不要在測試途中反覆切換設定，否則前後結果無法對應。
檢查順序
中斷線路 → 記錄出口與 DNS
連線線路 → 重新檢查出口與 DNS
核對瀏覽器獨立 DNS → 再測試瀏覽器
核對客戶端 DNS 策略 → 再測試其他應用程式第三步：依應用程式驗證分流規則
完成出口與 DNS 檢查後，還要回到真正需要使用的應用程式。現代代理客戶端通常支援規則分流：本地網站直連，指定網域或網路區段經過代理，區域網路地址維持直連。規則模式原本就不是讓所有要求採用同一個出口，因此「某個網站仍顯示原出口」可能是規則預期，也可能是規則遺漏。
最清楚的驗證方式，是暫時比較全域代理與規則代理的結果。在全域模式下，目標應用程式可以改變出口；在規則模式下卻沒有改變，問題通常出在規則比對、規則順序或應用程式繞過設定。全域模式下仍未改變，則應繼續檢查系統代理、虛擬網卡、路由衝突與客戶端權限。
不同平台的接管範圍
桌面平台上的系統代理主要影響遵循系統代理介面的應用程式。一些下載工具、開發工具與遊戲平台擁有獨立的代理設定，可能直接連線網路。虛擬網卡模式可以涵蓋更多以 IP 為基礎的連線，但仍需正確寫入路由，並處理本地網路、私有地址與 DNS。
Android 與 iOS 上的客戶端通常透過系統提供的 VPN 介面建立隧道。若啟用了分應用程式代理或排除應用程式，被排除的程式會繼續使用原網路。系統同時只允許目前生效的隧道設定接管相應流量，因此切換客戶端後應重新確認設定狀態，而不是只查看舊客戶端的歷史記錄。
瀏覽器擴充功能通常只影響該瀏覽器中的網頁要求，無法代表其他程式。命令列工具還可能讀取自己的環境變數，例如 HTTP_PROXY、HTTPS_PROXY 或 ALL_PROXY。開發者測試介面要求時，應同時核對終端機環境、應用程式設定與客戶端規則。
- ✅ 瀏覽器、目標應用程式與命令列工具分別發起實際要求，並各自核對出口。
- ✅ 在規則模式下確認目標網域命中了代理規則，而不是預設的直連規則。
- ✅ 使用虛擬網卡時檢查系統授權、路由寫入與 DNS 接管狀態。
- ❌ 只用瀏覽器擴充功能測試，就推斷裝置內所有程式都已使用同一條線路。
- ❌ 只看到客戶端產生流量，就認定目標應用程式的要求已被接管。
線路類型會影響排查位置
直連線路表示客戶端直接與目標節點建立連線，鏈路結構較簡單。若握手成功但出口不變，排查重點通常在本地代理模式、路由與應用程式設定。中轉線路會先連線至中轉入口，再由中轉網路轉送至出口節點；客戶端看到的是入口工作階段，網站看到的則應是最終出口地址。
IEPL 專線通常用來描述入口與出口之間採用專用承載或受控傳輸的線路設計。它與一般公網中轉的差異主要在中間傳輸路徑，不代表本地應用程式會自動正確分流。無論採用直連、中轉或 IEPL，驗證方式都相同：核對最終出口、DNS 路徑與目標應用程式要求。
協定名稱也不能取代路徑驗證。Shadowsocks 與 Trojan 常作為代理協定使用；VMess 與 VLESS 依賴客戶端核心及傳輸設定；Hysteria2 與 TUIC 基於 QUIC 類傳輸，更需關注特定網路條件下的連線表現。它們的封裝、驗證與傳輸方式不同，但客戶端顯示握手完成後，仍要檢查系統是否將目標流量送進對應工作階段。
| 線路或模式 | 網站應觀察到的出口 | 優先排查項目 |
|---|---|---|
| 直連節點 | 所選節點的公網出口 | 系統代理、虛擬網卡、路由與應用程式設定 |
| 公網中轉 | 最終出口節點，而非中轉入口 | 入口可達性、中轉轉送與出口設定 |
| IEPL 專線 | 最終出口節點 | 本地接管、入口連線與出口對應 |
| 規則分流 | 由命中的規則決定 | 規則順序、網域比對與預設策略 |
常見的「看似已連線」情況
系統代理未成功寫入
客戶端已連線至節點，但系統代理仍為空白，或已被其他網路工具覆寫。此時遵循系統代理的瀏覽器與應用程式不會進入線路。可以在客戶端中重新切換系統代理，並檢查作業系統的網路設定是否隨之變更。
規則將目標要求判定為直連
網域規則、網路區段規則與預設規則有優先順序。若目標網域先命中直連項目，後續的代理規則就不會再處理。排查時應查看客戶端連線記錄或規則命中資訊，確認實際使用了哪一條規則，而不是只檢查規則清單中是否出現目標網域。
應用程式擁有獨立代理設定
部分應用程式不會跟隨系統代理，或在內部保存了舊代理地址。有些應用程式也會直接使用自己的網路堆疊與 DNS。遇到瀏覽器正常、特定程式不變時，應先檢查該程式的網路選項，再決定是否改用虛擬網卡模式。
訂閱已更新，但目前節點尚未重新載入
訂閱連結用於向客戶端提供節點與規則設定。匯入訂閱或執行更新後，部分客戶端需要重新選擇節點並重新連線，才會使用新設定。只看到訂閱更新時間改變，不能證明目前工作階段已切換至更新後的出口。
切換網路後仍保留舊工作階段
裝置從一個網路切換至另一個網路時，原有連線可能中斷或進入等待恢復狀態。客戶端介面未必會立即更新。此時應主動中斷並重新連線，再重新執行出口與 DNS 檢查，避免依據切換前的工作階段作判斷。
WebRTC 結果被誤讀
瀏覽器的 WebRTC 檢測可能顯示區域網路候選地址、經過隱藏處理的候選名稱或公網候選地址。看到本地私有地址不代表公網出口沒有改變。應區分區域網路地址與可由網際網路存取的公網地址，並結合一般出口查詢判讀 WebRTC 結果。
一份可重複執行的驗證清單
首次設定、切換客戶端、修改分流規則或更換網路後，都可以依相同順序重新檢查。固定流程的價值在於快速定位變化發生在哪一層，而不是反覆切換節點碰運氣。
- 中斷線路，記錄原始公網出口與 DNS 解析路徑。
- 連線至目標節點，確認客戶端完成握手與系統接管。
- 重新查詢公網出口，核對地址、網路歸屬與預期地區。
- 執行 DNS 測試，檢查是否仍明顯使用原網路的解析器。
- 在瀏覽器、目標應用程式與必要的命令列工具中分別發起要求。
- 規則模式異常時，比較全域模式並查看實際命中的規則。
- 網路環境或設定發生變更後，重新執行完整檢查。
若出口沒有變化，從系統代理、虛擬網卡與路由開始；若只有部分應用程式沒有變化，從應用程式獨立設定與分應用程式規則開始；若出口正確但網域存取異常，從 DNS、瀏覽器加密 DNS 與規則解析方式開始。依層次排查，比頻繁更換協定更容易找出原因。