如何確認 VPN 是否真的生效？查詢出口 IP 與 DNS 的完整方法

確認 VPN 是否真的生效，不能只看用戶端顯示的「已連線」。這個狀態通常只代表用戶端與遠端節點完成交握，不一定表示瀏覽器、命令列工具及其他應用程式的流量都已進入指定線路。可靠的檢查方式是先記錄連線前的出口 IP，再連線並重新查詢，同時檢查 DNS 請求及不同應用程式的實際存取路徑。

如果出口 IP 已變更，表示至少有部分網路請求經過遠端線路；如果 DNS 仍由本地網路處理，或某個應用程式顯示的出口沒有變化，可能是分流規則、系統代理、隧道權限或應用程式本身的代理設定造成。以下將依照由簡入深的順序逐項檢查。

出口 IP 是最直接的檢查入口

出口 IP 是目標網站看到的公開網路位址。未連線線路時，請求通常會直接從目前的網路送出；連線並正確接管流量後，請求會先抵達遠端節點，再由節點存取目標網站，因此網站看到的出口位址與地區通常會改變。

可以先開啟本站的 IP 查詢 頁面，記錄目前顯示的位址、網路服務商與地區。接著連線至目標線路，重新整理查詢頁面。為避免瀏覽器快取舊結果，建議重新開啟頁面，或使用無痕視窗再次查詢。若前後結果不同，且連線後的地區與所選線路相符，瀏覽器流量大多已經經過該線路。

1. 中斷用戶端中的線路，並關閉瀏覽器中可能單獨啟用的代理擴充功能。
2. 開啟 IP 查詢頁面，記錄目前的出口位址與地區。
3. 連線至目標線路，等待用戶端明確顯示連線完成。
4. 重新開啟查詢頁面，不要只查看原頁面中尚未重新整理的舊結果。
5. 比較連線前後的出口位址、地區與網路服務商資訊。

為什麼線路已連線，出口 IP 卻沒有變化

最常見的原因是用戶端只設定了系統代理，而目前的應用程式沒有遵循系統代理。部分命令列工具、遊戲啟動器、虛擬機器及具有獨立網路設定的軟體會繞過系統代理。瀏覽器擴充功能也可能覆寫作業系統設定，讓同一台裝置上的不同瀏覽器採用不同路徑。

另一個原因是分流模式。規則可能將本地網站、區域網路位址或特定應用程式設定為直連。如果用於查詢的網站剛好符合直連規則，結果就不會改變。此時可以暫時切換至全域模式進行診斷；確認問題後，再恢復分流並檢查具體規則，而不是長期使用全域模式。

• ✅ 連線前後使用同一個查詢頁面，並主動重新整理結果。
• ✅ 檢查用戶端目前是全域模式、規則分流，還是僅代理指定應用程式。
• ✅ 暫停會改寫代理設定的瀏覽器擴充功能，再進行比較。
• ❌ 不要把用戶端中的連線時間當作流量已被接管的證據。
• ❌ 不要只根據網頁語言或搜尋結果地區判斷出口位置。

繼續檢查 DNS 解析 是否使用正確路徑

存取網域之前，裝置通常需要先將網域解析成可連線的位址，這個過程由 DNS 完成。即使網頁流量經過遠端線路，DNS 請求仍可能傳送至本地網路指定的解析服務，這就是常說的 DNS 洩漏。它不一定會導致網頁無法開啟，但會讓本地解析方看到裝置查詢過哪些網域，也可能造成解析結果與出口地區不一致。

檢查時，應觀察連線線路後實際使用的 DNS 服務來源，而不只是查看系統設定中填寫的位址。用戶端可能透過隧道轉送 DNS，也可能啟用加密 DNS；瀏覽器還可能使用自身的安全 DNS 設定，繞過用戶端或作業系統。因此，系統、用戶端與瀏覽器三個層級都需要納入判斷。

DNS 檢查結果應如何理解

檢測頁面顯示的解析服務不一定與出口 IP 屬於同一家網路，這是正常現象。公共解析服務、加密 DNS 及節點端轉送都可能讓兩者顯示不同機構。真正需要關注的是：連線前後的解析路徑是否如預期變化，以及是否仍出現明確屬於目前本地網路的解析服務。

如果瀏覽器啟用了獨立的安全 DNS，可能會將查詢直接傳送至瀏覽器指定的服務。此時結果不一定表示用戶端失效，而是說明 DNS 路徑由瀏覽器單獨決定。要驗證用戶端的 DNS 接管能力，可以暫時關閉瀏覽器的獨立解析設定，重新連線後再測試。完成診斷後，再依照隱私與相容性需求決定使用哪一層的 DNS 功能。

系統代理 與隧道模式為何會產生不同結果

許多桌面用戶端提供系統代理與隧道模式。系統代理會修改作業系統的代理入口，遵循該入口的應用程式會將請求交給用戶端；不讀取系統代理的應用程式則可能繼續直連。隧道模式通常透過虛擬網路介面接管更多網路流量，因此與不支援系統代理的程式相容性更好，但需要相應的系統權限，也可能與其他網路工具發生路由衝突。

這也解釋了常見現象：瀏覽器中的 IP 已變更，命令列下載工具、遊戲或開發工具卻仍使用原出口。瀏覽器通常支援系統代理，而某些工具會直接建立連線。反過來，如果瀏覽器安裝了獨立代理擴充功能，也可能在系統尚未連線線路時單獨生效。

協議名稱不決定接管範圍

Shadowsocks、VMess、Trojan、VLESS、Hysteria2 和 TUIC 描述的是用戶端與伺服器之間傳輸資料的方式。它們會影響交握、傳輸方式及網路適應性，但不會自動決定作業系統中的所有應用程式是否被接管。真正決定涵蓋範圍的是用戶端如何將本機流量送入協議連線，例如系統代理、虛擬網路介面、應用程式層級代理或路由規則。

因此，看到協議已成功完成交握，不代表所有請求都進入該協議。診斷時應將「遠端連線是否建立」與「本機流量是否導入連線」分開處理。前者失敗通常表現為節點無法連線；後者失敗則更容易出現用戶端顯示正常，但出口 IP 不變或只有部分應用程式生效。

逐一驗證應用程式，找出部分生效的位置

如果瀏覽器檢查正常，下一步應依照實際使用情境逐一驗證。不要假設同一裝置上的軟體會共用完全相同的網路路徑。瀏覽器、終端機、遊戲平台、虛擬機器與容器都可能擁有獨立的代理、DNS 或路由環境。

1. 先測試主要瀏覽器：關閉代理擴充功能後查詢出口 IP，再恢復擴充功能並重新測試，用於判斷擴充功能是否覆寫系統設定。
2. 再測試另一個瀏覽器：如果結果不同，優先比較兩者的代理擴充功能與安全 DNS 設定。
3. 檢查命令列工具：查看工具是否讀取系統代理，或是否設定了獨立的代理環境。不要只憑瀏覽器結果推斷終端機流量。
4. 檢查虛擬環境：虛擬機器與容器可能使用獨立閘道。主機系統的代理設定不一定會傳入其中。
5. 最後驗證目標應用程式：完全退出後重新開啟，避免舊連線繼續沿用切換線路前建立的工作階段。

長連線尤其容易干擾判斷。某些應用程式在切換線路前已建立連線，切換後仍嘗試重用舊工作階段。此時用戶端可能已接管新請求，但舊工作階段尚未重建。退出應用程式、中斷線路、重新連線後再啟動應用程式，可以讓測試條件更清楚。

• ✅ 同時記錄瀏覽器、目標應用程式與 DNS 的結果，不要混為一個結論。
• ✅ 修改分流規則後徹底重新啟動目標應用程式，讓舊連線失效。
• ✅ 檢查規則順序，確認較寬泛的直連規則沒有提前命中。
• ✅ 虛擬機器與容器應在各自的網路環境中獨立驗證。
• ❌ 不要因為用戶端的流量計數增加，就判斷目標應用程式已經使用線路。

常見的「已連線但未生效」情況

訂閱已匯入，但節點設定沒有更新

訂閱連結用於向用戶端提供節點與規則資訊。成功匯入只表示用戶端已讀取設定，不代表目前節點一定能連線，也不表示後續變更已同步。遇到節點資訊異常時，可以手動更新訂閱，重新選擇線路，再檢查出口 IP。更新前若曾自行修改設定，也應留意用戶端是否覆寫本機變更。

分流規則將目標網域設為直連

規則模式會依網域、位址範圍、應用程式或其他條件決定路徑。若目標服務符合直連規則，用戶端仍會顯示連線狀態，但該請求不會經過遠端線路。診斷時可暫時使用全域模式進行比較。如果全域模式有效，問題通常位於規則集、規則順序或網域比對，而不是節點本身。

瀏覽器代理擴充功能覆寫了系統設定

擴充功能可以將瀏覽器請求傳送至另一個代理，也可以設定為直連。此時瀏覽器結果可能與系統中的其他應用程式完全不同。應先停用擴充功能，使用系統路徑測試，再單獨啟用擴充功能。這樣可以確認是哪一層在控制瀏覽器流量。

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

兩個用戶端同時啟用系統代理或虛擬網路介面時，後啟動的軟體可能覆寫前者設定，路由優先順序也可能改變。診斷階段只保留一個網路工具執行，確認出口與 DNS 正常後，再逐一恢復其他工具。這比反覆更換節點更容易找出衝突來源。

休眠或切換網路後保留舊狀態

裝置從休眠狀態恢復，或從一個網路切換至另一個網路後，用戶端介面可能仍顯示已連線，但底層連線已失效。此時應主動中斷並重新連線。如果仍無變化，可以退出用戶端後重新開啟，再次確認系統代理或虛擬網路介面是否恢復。

不同平台的檢查重點

Windows 上應重點檢查系統代理是否殘留，以及隧道模式使用的虛擬網路介面是否正常。用戶端異常退出後，系統代理偶爾可能仍指向已停止運作的本機連接埠，導致中斷線路後網頁也無法存取。重新開啟用戶端並正常中斷連線，通常比直接刪除網路設定更穩妥。

macOS 的不同用戶端可能使用系統代理或網路延伸功能。若權限未完整授予，介面可能可以匯入訂閱及選擇節點，但流量接管不完整。可以在系統網路設定中確認對應設定是否啟用，再分別檢查瀏覽器與不讀取系統代理的應用程式。

行動裝置用戶端通常透過系統提供的 VPN 介面建立隧道。若同時啟用了應用程式分流，應確認目標應用程式是否包含在規則中。切換網路後，重新連線並重新測試出口 IP 與 DNS，可以排除舊網路工作階段造成的干擾。

Linux 環境差異較大。桌面應用程式可能讀取圖形環境中的代理設定，命令列工具則可能依賴各自的設定或環境變數。使用虛擬網路介面時，還要檢查路由與 DNS 是否由用戶端正確更新。瀏覽器測試成功後，仍應在實際使用的終端機工具中單獨驗證。

建立一套可重複的驗證流程

一次可靠的檢查應包含基準、連線後結果、DNS 路徑及應用程式層級結果。先在中斷狀態記錄出口，再連線至目標線路重新測試；接著檢查 DNS 是否仍由本地網路處理；最後開啟真正需要使用的應用程式，確認它沒有被直連規則或獨立設定繞過。

如果出口與 DNS 都符合預期，但目標服務仍無法使用，問題可能不在用戶端是否生效，而在目標服務本身的政策、線路品質、帳號地區、快取或應用程式工作階段。此時繼續重複連線意義不大，應將檢查範圍轉向目標應用程式，並保留已確認正常的網路條件。