VPN 已連線卻沒生效？檢查出口 IP、DNS 與分流規則的完整指南

VPN 已連線卻沒生效，通常不是狀態圖示本身出了問題，而是「隧道建立」、「路由接管」和「特定應用程式使用線路」被混為一談。用戶端顯示已連線，只能代表它已與某個節點完成通訊；網頁、DNS 請求與其他應用程式是否經過該節點，仍須分別驗證。

最可靠的判斷方式不是反覆查看用戶端顏色，也不是只開啟一個網站測試速度，而是保留連線前的基準，再依序檢查出口 IP、DNS 解析路徑與應用程式流量。三項結果相互印證，才能區分線路故障、分流規則、瀏覽器設定與系統網路快取。

連線狀態為什麼不等於流量生效

大多數用戶端將「連線成功」定義為本機已與節點建立可用工作階段。這個工作階段可能採用 Shadowsocks、VMess、Trojan、VLESS、Hysteria2 或 TUIC 等協定，也可能由系統提供的 VPN 網路延伸功能承載。協定交握成功後，用戶端還需要寫入系統路由、啟用虛擬網卡或開放本機代理連接埠，應用程式流量才有機會進入線路。

如果用戶端使用全域模式，通常會嘗試接管更廣泛的流量；如果使用規則模式，則由網域、IP、程序或應用程式規則決定直連與代理。瀏覽器也可能另外設定代理，部分應用程式則會使用自己的網路堆疊。因此可能出現用戶端已連線、某個網頁可以存取，但另一個應用程式仍然直連的情況。

第一步：核對出口 IP

出口 IP 是最直觀的第一項證據。中斷線路時，檢測頁面通常會顯示本地網路供應商提供的公開網路出口；連線後，如果測試請求經過所選節點，頁面應顯示線路出口，而不是原本的網路接入出口。重點是比較連線前後是否有變化，以及顯示地區是否大致符合所選線路。

1. 完全中斷用戶端連線，開啟網路檢測頁面，記下出口地區與網路供應商資訊。
2. 連線至目標線路，等待用戶端狀態穩定後，再重新整理檢測頁面。
3. 關閉檢測頁面後重新開啟，或使用新的瀏覽器工作階段複核，避免舊頁面快取造成干擾。
4. 再使用目標應用程式內建的網路診斷或地區資訊功能，確認應用程式結果與瀏覽器結果一致。

出口地區與節點名稱不必精確到同一座城市。IP 資料庫的地理資訊可能更新較慢，線路也可能在鄰近地區完成最終出站。因此，判斷重點是原本的出口是否已被替換、國家或地區是否合理，而不是把城市欄位當成實體機房位置。

如果出口完全沒有變化，先確認用戶端模式。僅代理模式通常只接管明確使用本機代理連接埠的應用程式；虛擬網卡模式或系統 VPN 模式則能涵蓋更多程式。還要檢查瀏覽器是否啟用了獨立代理、系統是否殘留舊代理位址，以及規則是否將檢測網域設定為直連。

• ✅ 連線前後使用相同網路環境，結果才具備可比性。
• ✅ 新出口與所選線路地區大致一致，原本的網路接入出口不再出現。
• ✅ 瀏覽器與目標應用程式得到一致的出口判斷。
• ❌ 只查看用戶端節點名稱，沒有實際查詢公開網路出口。
• ❌ 切換本地網路後直接比較，把網路接入變化誤認為線路生效。

第二步：檢查DNS 解析路徑

存取網域之前，裝置通常要先將網域解析為可連線的位址。網頁內容經過線路，不代表 DNS 請求也會自動採用相同路徑。如果解析仍由本地網路處理，就可能出現 DNS 路徑與內容出口不一致；在需要依網域分流的情境中，也可能導致規則判斷異常。

檢測時要同時查看「誰在解析」以及「目前用戶端如何設計 DNS」。如果用戶端明確使用遠端 DNS、加密 DNS，或由線路端處理解析，檢測結果應符合這項設計。若瀏覽器啟用了自己的安全 DNS，它可能繞過系統 DNS，但這不一定等同於洩漏：關鍵在於它是否符合預期，以及是否將資訊暴露給不希望參與解析的一方。

因此，不能單純因為「DNS 供應商名稱與線路品牌不同」就判定為洩漏。公共解析服務、瀏覽器內建解析與用戶端指定解析，都可能顯示為獨立供應商。真正需要處理的是：連線前後的 DNS 完全相同、解析仍明確落在本地網路，且用戶端原本設定要求遠端解析。

DNS 結果異常時如何處理

• ✅ 查看用戶端是否提供遠端解析、代理 DNS 或防洩漏選項，並確認已依預期啟用。
• ✅ 檢查瀏覽器是否啟用獨立安全 DNS，避免它與系統策略互相覆蓋。
• ✅ 重新連線至線路後再發起全新的網域查詢，不要重複使用已開啟的頁面。
• ✅ 在規則模式下確認 DNS 請求本身也有對應規則，而不只是網頁網域設有規則。
• ❌ 只因解析服務名稱陌生，就直接認定所有流量都發生洩漏。

第三步：依應用程式驗證分流規則

瀏覽器驗證通過後，還要檢查真正需要使用線路的應用程式。桌面用戶端、遊戲平台、命令列工具與系統服務可能各自採用不同網路路徑。規則模式又可能按照網域、目標位址、應用程式程序或規則集合分配流量，因此「瀏覽器生效」不代表「整台裝置生效」。

可採取的做法是逐一關閉目標應用程式，連線至線路後重新啟動，再觀察應用程式內的地區資訊、連線記錄或用戶端連線紀錄。如果用戶端能顯示命中的規則，重點查看該應用程式的請求最後落在代理、直連還是拒絕項目。不要只看流量計數增加，因為背景更新、連線檢查與 DNS 請求也會產生流量。

應用程式分流代理也要留意系統差異。在 Windows 與 macOS 上，虛擬網卡模式通常比單獨設定系統代理涵蓋範圍更廣，但部分程式可能繞過系統代理。Android 的 VPN 介面可以依應用程式納入或排除；如果目標應用程式被排除，就會繼續使用本地網路。Apple 平台上的網路延伸功能由系統管理，切換設定後應重新開啟目標應用程式，讓既有連線重新建立。

1. 退出目標應用程式，避免重複使用連線前建立的長連線。
2. 連線至線路，並確認出口 IP 已經變更。
3. 重新啟動目標應用程式，執行一次明確需要連網的操作。
4. 查看用戶端連線記錄或規則命中結果，確認目標請求不是直連。
5. 切回中斷連線狀態重新比較差異，排除應用程式快取與帳號地區設定的影響。

串流影音、商店與內容平台還會綜合帳號地區、快取、定位授權與付款資料等資訊。即使出口已經變更，頁面內容也可能暫時不變。這種情況不能直接證明 VPN 未生效，應先用網路層證據確認出口與 DNS，再個別處理應用程式快取或帳號端的地區邏輯。

如何核驗訂閱連結與協定設定

訂閱連結的作用是向用戶端提供節點與規則設定。成功匯入只代表用戶端讀取到設定，不代表每個節點都能連線，也不代表系統流量已被接管。訂閱更新後，如果節點名稱變更、舊節點失效或規則集未重新整理，用戶端仍可能保留看似正常的舊設定。

遇到異常時，可以先更新訂閱，再確認目前選取的節點確實來自最新設定。接著檢查協定參數是否完整。Shadowsocks 需要加密方式與連線參數相互匹配；VMess、Trojan 與 VLESS 通常要配合傳輸層、TLS 和網域設定；Hysteria2 與 TUIC 採用不同的傳輸設計，也需要用戶端版本支援相應協定。不要將某種協定的欄位手動套用到另一種協定。

協定只負責建立通訊方式，線路類型則描述流量如何抵達出口。直連通常由裝置直接連接遠端節點；中轉會先進入中間接入點，再轉送至最終出口；IEPL 專線用於承載特定區段的國際傳輸。無論採用哪種路徑，最終是否生效仍應回到出口 IP、DNS 與應用程式命中結果，而不能根據線路名稱推斷。

常見的「已連線卻未經過線路」情況

檢測網站被規則設為直連

部分規則集合會將本地服務、區域網路位址或特定檢測網域設為直連。此時用戶端運作正常，但檢測頁面會刻意繞過線路。可以暫時切換至全域模式複查；如果全域模式下出口有變化，問題通常出在規則，而不是節點。

應用程式重複使用舊連線

瀏覽器分頁、下載工具與即時通訊應用程式可能維持長連線。切換線路後，舊工作階段不會立即依新路由重建。完全退出應用程式後重新開啟，比只重新整理頁面更能反映目前路徑。

系統代理與虛擬網卡互相覆蓋

裝置上同時執行多個網路工具時，後寫入的代理、路由或 DNS 設定可能覆蓋先前設定。排查時應只保留一個負責接管流量的用戶端，確認結果後再逐項恢復其他網路工具。

規則只涵蓋網域，未涵蓋直接連線的位址

部分應用程式不會再次查詢網域，而是直接連線至快取中的位址。如果規則僅依網域比對，這類請求可能落入預設直連。檢查規則記錄即可確認請求是否命中預期項目，再決定是否補充位址規則或調整預設策略。

瀏覽器與系統採用不同代理

瀏覽器擴充功能、本機代理設定與系統 VPN 可以同時存在。檢測網頁可能經過瀏覽器擴充功能，其他應用程式則仍然直連；反過來也可能發生。驗證時應先確認目前由哪一層接管，不要把多層代理疊加後的結果當成單一用戶端的表現。

完整複查清單

如果前面的檢查結果互相矛盾，可以依照下列順序從網路層逐步收斂到應用程式層。每次只修改一項，並在修改後重新測試，才能確認哪項設定真正影響結果。

• ✅ 中斷線路，保存出口 IP 與 DNS 基準結果。
• ✅ 更新訂閱，確認節點、協定與用戶端版本能夠配合。
• ✅ 連線至線路，重新確認出口是否替換為合理的線路出口。
• ✅ 核對 DNS 是否符合遠端解析或既定的安全 DNS 方案。
• ✅ 退出並重新啟動目標應用程式，檢查實際命中的規則。
• ✅ 暫時切換至全域模式，用來區分節點問題與分流規則問題。
• ✅ 排除同時執行的其他代理、網路延伸功能與舊系統代理設定。
• ❌ 只因用戶端顯示「已連線」就停止驗證。
• ❌ 同時修改協定、DNS、節點與規則，導致無法定位變數。

完成核驗後，可以保存目前有效的節點、模式與 DNS 組合。日後遇到存取異常，先用同一套方法區分「線路未建立」、「路由未接管」與「應用程式規則未命中」，再決定要切換節點、更新訂閱，或調整分流。隱私政策則應另行查看服務說明；如有此類需求，選擇明確標示匿名且不記錄連線的服務，並依自身網路環境持續驗證實際連線結果。