如何確認 VPN 是否真的生效？出口 IP、DNS 與分應用程式驗證方法

如何確認 VPN 是否真的生效，不能只看用戶端是否顯示「已連線」。這個狀態通常只能代表本機代理核心已啟動，或用戶端與所選線路完成握手；無法單獨證明瀏覽器、桌面軟體和命令列程式的流量都經過目標出口。可靠的判斷方式是同時檢查出口 IP、DNS 解析路徑，以及特定應用程式的實際行為。

驗證前，先確認連線模式。啟用 TUN 的用戶端通常會建立虛擬網路介面並接管系統路由；系統代理模式主要影響遵循作業系統代理設定的軟體；瀏覽器擴充功能只處理對應瀏覽器中的請求；分流模式則會讓部分目標使用代理、部分目標維持直連。模式不同，「生效」的範圍也不同，不能用單一結果概括整台裝置。

判斷標準：出口 IP 符合所選線路、需要代理的網域透過預期的 DNS 路徑解析、目標應用程式確實使用代理介面，三項結果能互相印證，才算完成連線驗證。

先確認用戶端究竟接管了哪些流量

Shadowsocks、VMess、Trojan、VLESS、Hysteria2 與 TUIC 都能承載代理流量，但協定名稱本身不會決定系統流量如何進入通道。真正影響涵蓋範圍的是用戶端採用的入口方式，例如系統代理、TUN 虛擬網卡、應用程式內代理或手動設定的本機連接埠。即使節點連線正常，未接入代理入口的應用程式仍會直接連線網路。

連線方式	通常涵蓋的範圍	「已連線」通常代表什麼	仍需檢查的項目
TUN 模式	由系統路由送入虛擬介面的流量	虛擬介面與代理核心已在運作	預設路由、排除規則、IPv6 路徑
系統代理	遵循系統代理設定的應用程式	本機代理連接埠已啟動並寫入系統設定	應用程式是否忽略代理、代理設定是否被覆寫
瀏覽器代理	指定瀏覽器或指定設定檔	擴充功能或瀏覽器代理設定處於啟用狀態	其他應用程式仍可能直連，瀏覽器 DNS 也需單獨核對
分流模式	僅符合規則的網域、位址或應用程式	規則引擎與線路可用	目標請求命中代理規則還是直連規則

訂閱連結也只是設定入口。用戶端匯入訂閱後，會取得線路、協定參數以及可能存在的分流規則，但匯入成功不代表系統代理已啟用。部分桌面用戶端會將「選擇節點」「啟動核心」「設定系統代理」分成獨立操作；行動平台則通常透過系統的 VPN 介面接管流量。驗證時應先查看目前模式，再判斷測試結果是否合理。

✅ 已確認目前選擇的是預期線路，而非自動選擇或上次使用的線路
✅ 已確認系統代理、TUN 或應用程式內代理至少有一種入口處於啟用狀態
✅ 已確認分流模式名稱，並知道測試網域預期使用代理還是直連
❌ 只看到用戶端計時或狀態變色，就直接認定所有應用程式都已接管
❌ 匯入訂閱後沒有啟動線路，也沒有將流量送入本機代理介面

用出口 IP 進行前後對照

出口 IP 是最直接的驗證項目。正確做法不是只在連線後開啟查詢頁面，而是先中斷 VPN，記錄目前公網出口的位址、網路業者和大致地區；接著關閉測試頁面，連線至目標線路，再重新開啟查詢。如果位址與網路歸屬出現符合預期的變化，表示目前的測試請求很可能已經經過代理出口。

暫時中斷用戶端連線，並關閉可能獨立設定代理的瀏覽器擴充功能。
在瀏覽器中查詢公網 IP，記錄位址、網路歸屬與地區資訊，作為直連基準。
連線至需要驗證的線路，確認系統代理或 TUN 模式已啟用。
使用新的隱私視窗重新查詢，避免舊頁面快取或長連線干擾結果。
再用另一個應用程式發出請求，檢查是否取得相同的代理出口。

提示：IP 資料庫的地區標籤可能延遲，也可能只顯示資料中心的登記地。驗證重點應放在出口位址和網路歸屬是否改變，不要只憑城市名稱判斷線路失效。

如果連線前後的位址完全相同，先不要立刻認定節點故障。瀏覽器可能啟用了獨立代理擴充功能，系統代理可能沒有成功寫入，目標網站也可能重用了連線前建立的長連線。關閉相關頁面並重新開啟，或改用沒有擴充功能的瀏覽器測試，即可排除這些干擾。

也要注意分流規則。在規則模式下，中國大陸網站、區域網路位址或指定服務可能預設直連，因此查詢直連目標時看到原本的網路出口並不矛盾。應選擇明確命中代理規則的目標進行驗證，或暫時切換至全域代理進行對照。測試完成後再恢復原本的分流模式，避免不需要代理的流量長期繞行。

瀏覽器結果改變，其他軟體卻沒有變化

這種情況通常表示代理只涵蓋瀏覽器。常見原因是啟用了瀏覽器擴充功能，或桌面用戶端只設定了系統代理，而目標軟體選擇忽略系統代理。遊戲啟動器、同步工具、命令列程式和部分採用自有網路堆疊的軟體，都可能不讀取系統代理設定。需要為應用程式單獨設定代理，或改用能接管其流量的 TUN 模式。

檢查 DNS 請求是否沿預期路徑解析

出口 IP 改變後，仍需檢查 DNS。DNS 會將網域名稱轉換為網路位址。如果網頁請求經過代理線路，但網域仍由本地網路的解析器處理，存取目標和解析路徑就會分離。這通常稱為 DNS 洩漏。不過，在明確設計的分流方案中，直連網域使用本地 DNS、代理網域使用遠端 DNS 也可能是正常策略，判斷時必須配合規則預期。

瀏覽器中的 DNS 檢測頁面可以顯示參與解析的伺服器及其網路歸屬。連線至線路後，如果代理網域仍持續由本地網路提供的解析器處理，應檢查用戶端的 DNS 模式、遠端解析選項和瀏覽器本身的加密 DNS 設定。瀏覽器可能繞過作業系統解析器，用戶端也可能透過虛擬 DNS 或網域嗅探配合分流；兩者設定衝突時，結果會變得難以解讀。

在系統層級，可以先查看目前的 DNS 設定。以下命令僅用於檢視，不會修改網路設定：

Windows
ipconfig /all
nslookup example.com

macOS
scutil --dns
nslookup example.com

Linux
resolvectl status
nslookup example.com

nslookup 顯示的是目前查詢所使用的解析器，但不一定完全代表瀏覽器的解析路徑。如果瀏覽器啟用了自己的安全 DNS，系統命令與瀏覽器檢測結果可能不同。因此，系統查詢與瀏覽器查詢都要查看，並結合用戶端記錄中是否出現目標網域來判斷。

不要只看解析速度：回應快慢會受快取、網路距離和解析器負載影響，無法證明 DNS 是否經過代理。應查看解析伺服器的歸屬、用戶端規則命中情況，以及代理網域是否使用預期的遠端解析。

為什麼 IPv6 會讓結果看起來矛盾

裝置可能同時具備 IPv4 與 IPv6 網路能力。如果用戶端只接管其中一種協定，而瀏覽器優先選擇另一條可用路徑，就會出現部分請求經過線路、部分請求維持直連的情況。此時 IP 查詢頁面可能顯示與預期不一致的出口，DNS 回傳的位址類型也可能影響最終路徑。

排查時應查看用戶端是否宣告支援 IPv6、TUN 介面是否取得對應路由，以及分流規則是否同時處理兩類位址。不要把關閉 IPv6 當作永久通用答案；更穩妥的做法是確認用戶端能正確接管，或明確讓系統不向目標應用程式提供未受管理的路徑。

逐一驗證應用程式，避免用瀏覽器代表整台裝置

瀏覽器測試通過，只能證明目前瀏覽器的請求很可能走了預期出口。如果使用情境包含會議軟體、雲端硬碟、程式碼工具、桌面用戶端或終端程式，還需要逐一驗證。應用程式可能採用不同的代理讀取方式，也可能繞過系統設定直接建立連線。

先保持目標線路連線，並確認瀏覽器出口已改變。
完全退出待測應用程式，再重新啟動，避免沿用連線前建立的工作階段。
在用戶端連線記錄中觀察該應用程式存取目標時是否產生新請求。
如果用戶端支援依程序或規則查看命中結果，請確認請求進入了代理規則。
切換為直連後重複相同操作，比較應用程式行為與記錄是否發生變化。

記錄比「能不能開啟」更具判斷價值。某項服務在直連和代理環境下都能正常存取時，僅憑頁面可用無法確認路徑。如果用戶端記錄顯示目標網域、目標位址、規則名稱和所選線路，就能將應用程式行為與實際轉送路徑對應起來。分享記錄前，應先移除訂閱連結、驗證資訊和完整設定內容。

命令列工具也常需要單獨設定。終端機中的環境變數、工具本身的代理參數與系統代理可能彼此不同。如果瀏覽器出口已經改變，但終端機請求仍走直連，應檢查目前終端機工作階段是否繼承了舊的代理環境，或使用中的工具是否明確忽略系統代理。修改後重新開啟終端機，通常比在舊工作階段中反覆測試更容易取得穩定結果。

分應用程式結論：同一台裝置出現不同出口不一定是故障。先確認這是分流設計、應用程式忽略系統代理，還是 TUN 路由遺漏，再決定是否需要調整模式。

顯示已連線但流量未經過線路的常見原因

系統代理沒有成功寫入

用戶端核心可以正常連線節點，但作業系統仍保留舊代理、手動代理或自動設定指令碼。此時用戶端會顯示已連線，卻沒有應用程式將請求送入本機代理連接埠。可以先關閉其他代理工具，檢查系統網路設定，再於用戶端重新啟用系統代理。

TUN 路由被其他網路工具覆蓋

虛擬機器、容器、企業網路用戶端和其他虛擬網卡都可能修改路由優先順序。TUN 介面雖然存在，但預設流量可能被優先順序更高的路由帶走。排查時可暫時退出會修改網路路徑的程式，重新連線線路，再逐項恢復，以找出衝突來源。

規則將測試目標判定為直連

網域規則、位址規則和地理規則可能產生不同結果。目標網域先經 DNS 取得位址後，也可能被另一條位址規則覆蓋。查看用戶端記錄中的最終命中規則，比只閱讀規則清單更可靠。如果全域模式測試正常而規則模式異常，問題通常在規則與 DNS 的配合，而不是線路握手。

瀏覽器保留舊連線或使用獨立 DNS 設定

現代瀏覽器會重用連線，也可能啟用自己的加密 DNS。連線 VPN 後直接重新整理舊頁面，不一定會建立新的網路工作階段。完整關閉瀏覽器後重新開啟，使用新的隱私視窗，再比較系統 DNS 與瀏覽器 DNS 結果，可以減少誤判。

更新訂閱後仍在使用舊設定

更新訂閱可能會改變線路參數或規則，但部分用戶端需要手動切換至新節點，或重新載入設定後才會套用。請確認目前作用中的設定名稱、更新時間與所選線路，不要只看訂閱清單中是否出現新內容。訂閱連結本身屬於敏感憑證，不應貼到公開檢測網站或放入截圖。

依固定順序完成最後排查

面對「用戶端顯示已連線，但存取路徑沒有改變」的情況，最有效的方法是從入口到出口逐層檢查，而不是頻繁更換協定或節點。每次只改變一個條件，才能確認是哪項設定造成結果變化。

✅ 核對目前設定、線路與連線模式是否符合預期
✅ 中斷線路並記錄直連出口，連線後使用新視窗重新對照
✅ 檢查代理目標的 DNS 解析器與用戶端 DNS 設定
✅ 分別測試瀏覽器、桌面應用程式與命令列程式
✅ 查看記錄中的最終規則、目標位址與實際所選線路
✅ 檢查 IPv6、虛擬網卡和其他網路工具造成的旁路
❌ 同時修改節點、協定、DNS 和分流規則，導致無法定位變數
❌ 將地區標籤不精確直接視為連線未生效的證據

如果出口 IP 沒有改變，優先檢查流量入口與系統代理；如果出口改變但 DNS 路徑異常，檢查遠端解析、瀏覽器 DNS 與分流策略；如果瀏覽器正常而單一應用程式異常，檢查該應用程式是否讀取系統代理，以及是否需要 TUN 接管；如果只有部分目標異常，則重點查看規則命中和位址類型。依照這個順序，可以將問題縮小至用戶端入口、DNS、路由或應用程式設定的其中一層。

完成標準：保留一份自己的直連基準，並在每次更換用戶端、網路環境或分流規則後，重新進行出口 IP、DNS 與目標應用程式測試。結果一致時，就不必依賴用戶端的狀態圖示猜測。