VPN 已連線卻未生效？檢查出口 IP 與 DNS 的方法

VPN 已連線卻未生效時，最可靠的判斷標準不是用戶端上的綠色圖示，而是實際流量從哪裡離開裝置、網域由誰解析，以及目標應用程式是否遵循目前的路由。連線狀態只能表示用戶端完成某段交握或建立本機代理埠，無法單獨證明瀏覽器、下載工具和其他應用程式都已進入預期路線。

排查時不要同時修改路線、協定、DNS 和分流規則。多個變數一起改動，即使問題暫時消失，也很難確認是哪項設定發揮作用。較穩妥的做法是先記錄直連狀態，再連線路線，依序檢查出口 IP、DNS 和指定應用程式。每一步只回答一個問題。

先區分「已連線」和「流量已接管」

不同用戶端所說的「連線成功」並不完全相同。使用系統層級通道時，用戶端通常會建立虛擬網路介面，並將路由寫入作業系統。使用系統代理時，用戶端可能只是在本機開放 HTTP、SOCKS 或混合代理埠，再將系統代理指向該埠。還有些用戶端只啟動本機核心，是否接管應用程式流量則取決於瀏覽器設定、分流模式或個別配置。

因此，同一台裝置上可能出現瀏覽器已經經過代理，但終端機指令仍然直連的情況；也可能大部分網站經過路線，但區域網路、特定網域或指定應用程式依規則直連。這不一定是故障，也可能只是用戶端執行既定的分流規則。關鍵在於：目前結果是否符合使用者選擇的模式。

觀察到的現象	能夠說明什麼	不能單獨證明什麼	下一項檢查
用戶端顯示已連線	交握完成或本機代理核心已啟動	所有應用程式都已進入路線	比較連線前後的出口 IP
出口 IP 已變更	目前測試要求經過另一個出口	其他應用程式與 DNS 要求採用相同路徑	檢查 DNS 與分流規則
DNS 解析器已變更	目前網域查詢使用了不同的解析路徑	網頁內容要求一定經過代理	逐一驗證目標應用程式
某個網站可以正常存取	該網站目前的要求鏈路可用	整台裝置都已被接管	測試其他瀏覽器與獨立應用程式

Shadowsocks、VMess、Trojan、VLESS、Hysteria2 和 TUIC 等協定負責用戶端與遠端節點之間的資料傳輸，但「協定連線成功」和「系統流量進入協定核心」仍是兩回事。無論採用哪一種協定，最後都要回到路由、代理設定、DNS 與應用程式行為上驗證。只是不斷更換協定，通常無法修正系統代理未啟用或應用程式主動繞過代理的問題。

階段結論： 連線圖示是排查起點，不是驗收結果。先確認用戶端採用系統通道、系統代理還是僅本機埠模式，再解讀後續測試現象。

第一步：比較連線前後的出口 IP

出口 IP 是存取目標網站時，對方伺服器看見的公開位址。驗證時應先中斷路線，開啟可信任的 IP 查詢頁面，記下國家或地區、網路業者與位址；接著連線目標路線，重新整理同一頁面。若位址及其網路歸屬發生變化，且大致符合所選路線的地區，表示這次網頁要求已從代理出口離開。

測試前最好關閉查詢頁面後重新開啟，或使用瀏覽器的隱私視窗，避免頁面快取舊結果。若瀏覽器安裝了獨立代理擴充功能，也要記錄擴充功能是否啟用。擴充功能可能覆寫系統代理，讓瀏覽器結果與其他應用程式不同。測試期間應只保留一種接管方式，避免系統用戶端與瀏覽器擴充功能疊加。

中斷用戶端連線，關閉原有的 IP 查詢頁面，再開啟查詢頁並記錄直連結果。
連線準備驗證的路線，等待用戶端明確進入已連線狀態。
重新開啟查詢頁，不要只讀取舊分頁中已快取的文字。
比較位址、地區與網路歸屬，不要只看地圖上的定位點。
換用其他瀏覽器或獨立應用程式複查，確認結果是否一致。

地圖位置只能作為輔助資訊。IP 資料庫會根據註冊資訊、機房位置或歷史紀錄推斷地點，不同資料庫的標示可能有所差異。判斷是否切換出口時，位址變化和網路歸屬通常比地圖圖釘更有參考價值。如果所選節點位於日本，而查詢結果顯示為該路線使用的日本機房網路，測試方向基本正確；如果位址與中斷前完全相同，就應繼續檢查代理接管方式。

出口 IP 沒有變化時要檢查什麼

✅ 確認用戶端不只是啟動本機埠，而是已啟用系統代理或虛擬網卡模式。
✅ 確認瀏覽器沒有設定「直連」，或使用其他代理擴充功能覆寫系統設定。
✅ 檢查目前分流模式是否將 IP 查詢網站套用到直連規則。
✅ 關閉其他網路代理工具，避免多個用戶端爭用系統代理與預設路由。
❌ 不要只靠重新整理舊頁面判斷，快取內容可能沒有重新發出完整要求。
❌ 不要連續更換多個協定與節點，這會掩蓋真正的接管問題。

如果只有某個瀏覽器的出口沒有變化，可以檢查該瀏覽器是否啟用了獨立代理策略。部分瀏覽器遵循系統代理，部分命令列工具預設不讀取系統代理，下載器和遊戲也可能直接建立網路連線。系統代理模式本來就無法保證所有應用程式自動接入；需要整台裝置接管時，應使用用戶端支援的虛擬網卡或系統通道模式，並確認路由已成功寫入。

第二步：檢查 DNS 要求的去向

DNS 負責將網域轉換為可連線的位址。網頁內容經過代理，不代表網域查詢也一定經過相同路徑。如果系統仍向本地網路指定的解析器傳送查詢，存取方可能取得與代理出口地區不一致的解析結果。對於使用區域調度的串流媒體、下載鏡像和內容傳遞網路，這種不一致可能表現為頁面可開啟但內容報錯、節點選擇異常或載入速度不穩定。

所謂 DNS 洩漏，通常是指依照目前的隱私或路由目標，本應透過通道或指定加密解析器傳送的查詢，卻從本地網路介面交給了其他解析器。發現本地解析器不代表所有網頁內容都在直連，但這表示 DNS 路徑未依預期統一，需要繼續檢查用戶端的 DNS 接管選項。

驗證方法與出口 IP 類似：先在中斷狀態記錄解析器的網路歸屬，再連線路線並重新測試。重點是確認解析要求由哪個網路處理、地區是否與目標出口明顯衝突，以及重複測試時是否仍混入本地網路提供的解析器。不要只看解析出的網站位址，因為大型網站可能依地區、快取和負載回傳不同結果。

nslookup example.com

# 查看系統目前的 DNS 設定
# Windows
ipconfig /all

# macOS
scutil --dns

# 常見 Linux 環境
resolvectl status

這些指令處理的是不同問題。nslookup可以顯示目前查詢使用的解析伺服器及回傳結果；系統網路指令則用於查看作業系統設定了哪些 DNS；但它們都無法單獨證明瀏覽器使用了相同的解析器。現代瀏覽器可能啟用安全 DNS，也就是透過 HTTPS 個別傳送查詢，藉此繞過作業系統設定。排查瀏覽器與系統結果不一致時，應檢查瀏覽器的安全 DNS 選項。

DNS 結果異常的常見原因

用戶端可能只代理 TCP 或 UDP 應用程式流量，卻沒有接管系統 DNS；虛擬網卡模式可能已建立，但 DNS 路由仍指向原本的網路介面；瀏覽器也可能使用自己的加密 DNS；分流規則還可能規定特定地區網域直連解析，其他網域交由遠端解析。最後一種屬於常見的分流設計，不能只憑解析器不同就判定故障，應結合目標網域的匹配規則判斷。

修改 DNS 後若結果仍未變化，可能是系統、瀏覽器或本機代理核心保留了快取。此時先重新啟動瀏覽器，再中斷並重新連線用戶端。仍無法更新時，可使用作業系統提供的 DNS 快取清除功能。不要把「清除快取」當成長期修復手段；如果每次連線都要手動處理，就應回到用戶端 DNS 接管和路由設定，尋找根本原因。

DNS 結論： 理想結果不是看到某個特定解析器名稱，而是解析路徑符合目前的用戶端模式，且不會讓目標服務同時觀察到互相衝突的出口與解析地區。

第三步：逐一驗證瀏覽器與應用程式

確認瀏覽器出口和 DNS 後，仍不能直接推斷所有軟體都已生效。應用程式是否進入路線，取決於它是否遵循系統代理、是否被虛擬網卡接管、使用哪種傳輸協定，以及分流規則如何匹配目標位址。瀏覽器、終端機、遊戲平台、影片用戶端和下載工具可能得到不同結果。

建議建立一份簡單的驗證紀錄：應用程式名稱、預期路徑、實際出口、DNS 表現和存取結果。先測試最重要的應用程式，不要用「某個網頁能開啟」取代整台裝置驗收。若某個應用程式異常而其他應用程式正常，問題通常在應用程式代理設定、協定支援或分流規則，而不是節點整體失效。

應用程式類型	常見接管方式	產生差異的原因	驗證重點
瀏覽器	系統代理、擴充功能或安全 DNS	擴充功能覆寫系統設定，DNS 個別解析	出口 IP、瀏覽器 DNS 與擴充功能狀態
命令列工具	環境變數、明確代理或虛擬網卡	預設不讀取系統代理	同一要求在終端機與瀏覽器中的出口差異
串流媒體用戶端	虛擬網卡或系統路由	地區驗證同時參考出口與 DNS	目標網域規則及解析地區一致性
遊戲與即時通訊	虛擬網卡、程序代理或路由規則	可能使用 UDP，系統代理未必能接管	程序是否符合規則、UDP 是否進入路線
下載工具	內建代理或系統通道	可能自行解析網域或直接連線至位址	工具內的代理設定與實際連線路徑

系統代理主要適用於會讀取代理設定的應用程式。虛擬網卡模式在網路層的接管範圍更廣，通常更適合不支援代理設定的程式，但仍會受到路由優先順序、排除規則和用戶端實作影響。Windows、macOS、Android、iOS 與 Linux 的網路堆疊和權限模型各不相同，同一份訂閱匯入不同用戶端後，可用的系統代理、虛擬網卡、依應用程式分流及 DNS 接管能力也可能不同。

訂閱連結只負責向用戶端提供節點與相關設定。成功匯入表示用戶端取得了設定，不代表作業系統已授權建立通道，也不代表分流規則適用於目前平台。首次匯入後，應確認已選取節點、啟用正確模式，並處理系統跳出的網路設定授權。如果訂閱已更新但用戶端仍使用舊節點，可在用戶端內重新整理訂閱後再次選擇路線。

全域、規則與直連模式如何影響結果

全域模式通常會讓更多目標進入代理，但區域網路、用戶端自身通訊和必要的系統服務仍可能被排除。規則模式依網域、位址、地區或程序決定代理與直連，最容易產生「部分生效」的感覺。直連模式則會保留節點設定，但不轉送一般流量，適合暫時停用代理；若誤選此模式，用戶端可能仍在執行，但出口不會改變。

規則匹配也有先後順序。某個網域若先符合直連規則，後面的代理規則就不會再處理它。網域解析後直接連線至位址的應用程式，也可能繞過只依網域編寫的規則。排查時可暫時切換至涵蓋範圍較廣的模式進行對照：若應用程式隨後恢復，節點本身大致可用，問題應集中在原有分流規則；完成對照後再恢復規則模式並修正匹配項目。

看似連線卻未經過代理的常見原因

用戶端只啟動了本機代理埠

部分桌面用戶端允許核心獨立執行。此時節點連線已建立，本機也有可用代理埠，但系統代理開關未開啟，普通瀏覽器和應用程式仍會直連。解決方向不是更換節點，而是啟用系統代理、為應用程式填入本機代理位址，或切換至虛擬網卡模式。

多個網路工具同時修改路由

兩個用戶端同時執行時，後啟動的軟體可能覆寫系統代理，虛擬網卡路由也可能產生優先順序競爭。表面上看，兩邊都顯示連線正常，實際流量卻進入了另一條路徑。排查時請退出其他代理、過濾器和網路除錯工具，只保留目前用戶端，再重新比較出口。

瀏覽器快取與長連線沒有重建

切換路線後，已開啟的頁面可能重複使用現有連線，DNS 結果也可能仍在快取中。因此新開啟的查詢頁顯示新出口，舊分頁卻維持原本狀態。關閉對應分頁或瀏覽器後重新測試，比連續按重新整理鍵更可靠。對於長時間維持連線的桌面應用程式，也應完全退出後再開啟。

IPv4 與 IPv6 路徑不一致

網路可能同時提供 IPv4 與 IPv6，但用戶端只接管其中一種路徑。若目標網站優先選擇未被接管的協定族，就會出現出口與預期不一致。檢查時應觀察查詢頁分別回報的位址類型，並查看用戶端是否明確支援及接管目前系統啟用的協定族。不要只停用某種協定作為長期方案，應優先修正用戶端與路由設定。

規則讓目標網域直連

在規則模式下，廣告過濾、保留區域網路、地區分流和自訂規則都可能影響結果。IP 查詢網站本身也可能被列入直連集合，導致測試頁顯示原本的出口，而其他目標已經經過代理。可改用另一種查詢方法交叉驗證，並查看用戶端連線記錄中的規則命中資訊。記錄用於確認網域匹配和出站選擇，不應只盯著交握成功那一行。

系統時間或憑證驗證異常

Trojan、VLESS 搭配 TLS 等設定依賴正確的憑證驗證，其他基於 TLS 或 QUIC 的傳輸同樣可能受系統時間影響。若時間偏差導致交握失敗，用戶端通常會在記錄中顯示憑證、逾時或交握錯誤，而不是穩定進入可傳輸狀態。此類問題應先恢復系統自動校時，再檢查伺服器名稱、傳輸參數和訂閱設定是否完整。

一套可重複執行的最終檢查清單

完成單項排查後，依固定順序再進行一次驗收。這樣既能避免遺漏，也方便在更換網路、用戶端或路線後重複使用。記錄每一步的實際結果，比只保存一張「已連線」截圖更具診斷價值。

✅ 中斷路線並記錄基準出口 IP、網路歸屬和 DNS 解析路徑。
✅ 連線目標路線，確認用戶端模式是系統代理、虛擬網卡還是本機埠。
✅ 重新開啟查詢頁面，確認測試要求的出口出現預期變化。
✅ 檢查 DNS 解析路徑，並對照瀏覽器安全 DNS 與系統設定。
✅ 分別測試瀏覽器、終端機和目標應用程式，不要用單一網頁代表全部流量。
✅ 查看分流規則命中結果，確認異常目標沒有被意外分配至直連。
✅ 檢查 IPv4 與 IPv6 是否由同一套接管策略處理。
✅ 只變更一個變數後重新測試，並記錄修改前後的差異。
❌ 不要把用戶端圖示、節點名稱或訂閱匯入成功當成最終證據。
❌ 原因尚未明確時，不要同時更換節點、協定、DNS 和用戶端。

如果出口 IP 已變更、DNS 路徑符合預期，但特定應用程式仍無法使用，應將問題縮小到該應用程式：檢查它是否支援系統代理、是否使用 UDP、是否有獨立代理設定，以及是否命中分流規則。若所有應用程式的出口都沒有變化，就回頭檢查用戶端接管方式、系統權限和路由寫入。若出口反覆變化或連線頻繁中斷，再查看用戶端記錄中的逾時、交握和網路切換紀錄。

IEPL 專線、中轉路線與公網直連描述的是節點之間或使用者到出口之間的傳輸路徑，不會改變上述驗證原則。IEPL 通常強調專用跨境承載，中轉路線會先到中轉入口，再轉送至出口；公網直連則直接連線遠端節點。無論路線結構如何，目標網站最終看到的仍是出口節點位址；本機是否將流量送入該路線，仍需透過出口、DNS 和應用程式測試確認。

最終判斷： 出口 IP 符合所選路線、DNS 路徑符合目前模式，且目標應用程式也命中預期出站，才能認為連線真正生效。任一項不一致，都應沿著對應層級繼續排查，而不是只看連線按鈕。