VPN 生效了嗎？查看出口 IP、DNS 與分應用驗證完整教學

判斷 VPN 是否生效，不能只看用戶端顯示的「已連線」。這個狀態通常只代表用戶端已與遠端節點建立工作階段，不表示瀏覽器、桌面軟體和系統 DNS 都正在使用這條通道。可靠的檢查應分成三個層面：先比較連線前後的出口 IP，再確認 DNS 請求路徑，最後逐一驗證各應用程式的實際流量路徑。

這三個層面需要依序執行。出口 IP 是最直接的結果證據，DNS 能發現解析請求與網頁流量走不同路徑的情況，分應用測試則用來辨識系統代理伺服器、TUN 模式與分流規則造成的局部繞行。只檢查其中一項，很容易把「部分生效」誤判為「全部生效」。

出口 IP：確認測試請求從哪裡離開網路

出口 IP 是網站接收到的公開來源位址。VPN 處於全域通道模式時，發往公開檢測頁面的請求通常會從所選節點離開，因此檢測結果應與中斷連線時不同，且大致符合所選線路的國家或地區。這裡應比較的是變化關係，而不是只盯著頁面上的地區名稱。

1. 中斷 VPN，關閉檢測頁面後重新開啟，記錄基準出口 IP、地區與網路業者資訊。
2. 連線至目標線路，等待用戶端顯示連線完成，再使用新的瀏覽器分頁開啟同一個檢測頁面。
3. 比較兩次結果。如果位址與所屬網路出現預期變化，表示這次瀏覽器請求已經經過遠端出口。
4. 切換至另一條線路後再次檢查，確認結果會隨節點變化，而不是一直停留在舊快取。

地區資料庫並非即時更新。同一段網路位址在不同資料庫中，可能會顯示為鄰近城市；企業網路也可能顯示註冊地，而非機房所在地。因此，小範圍的位置差異不必直接視為連線失敗。更有價值的訊號是：位址是否不同於基準、網路業者是否改變，以及切換線路後結果是否跟著變化。

如果位址完全沒有變化，先不要反覆切換節點。檢查瀏覽器是否啟用了獨立代理伺服器擴充功能，用戶端是否處於僅代理部分應用程式的模式，以及目前存取的目標是否被分流規則判定為直連。某些用戶端的「規則模式」會讓本地網站直接存取，這是規則設計的結果，不代表通道沒有建立。

DNS 解析：辨識網頁流量與網域查詢是否分流

存取網域之前，系統或瀏覽器需要先將網域解析為網路位址。網頁請求可能經過 VPN，但 DNS 查詢仍交由本地網路處理；也可能由用戶端接管 DNS，再透過通道傳送。所謂 DNS 洩漏，通常是指解析請求偏離使用者預期的受控路徑，但判斷前必須先了解用戶端的 DNS 策略。

瀏覽器的加密 DNS、作業系統的安全 DNS、企業網路策略與用戶端內建解析器，都可能改變結果。檢測頁面顯示的解析服務不同於 VPN 出口業者，並不自動代表發生洩漏。例如，瀏覽器主動使用指定的公共加密解析器時，DNS 與出口網路名稱不同，可能是明確設定的結果。真正需要確認的是：解析器是否符合目前設定，以及查詢是否意外回到連線前的本地解析路徑。

桌面系統可以先查看目前介面與解析器，再決定是否清除快取。以下指令只會讀取狀態或重新整理本地快取，不會取代用戶端中的 DNS 設定：

Windows
ipconfig /all
ipconfig /flushdns
route print

macOS
scutil --dns
sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder
route -n get default

Linux
resolvectl status
resolvectl flush-caches
ip route

行動裝置通常無法直接查看完整路由表，可以採用對照法：中斷連線後測試一次，連線後關閉並重新開啟瀏覽器再測試，然後改用另一個應用程式存取相同目標。如果只有某個瀏覽器顯示異常，應優先檢查該瀏覽器自身的安全 DNS、內容過濾與代理伺服器設定，而不是先修改整個系統。

分應用驗證：確認每個程式是否進入通道

出口 IP 檢測通常在瀏覽器中進行，但實際使用還包括桌面用戶端、終端工具、協作軟體、下載程式與系統背景服務。它們不一定遵循同一套代理伺服器設定。瀏覽器可以讀取系統代理伺服器，某些桌面程式則會直接建立連線；TUN 模式通常涵蓋範圍更廣，但仍可能受到排除清單、區域網路繞過與自訂路由影響。

驗證時不要只反覆重新整理同一個網頁。選擇需要檢查的應用程式，在中斷與連線狀態下分別完成相同操作，並觀察出口、連線結果或用戶端記錄。若應用程式內提供代理伺服器選項，也要確認它使用系統設定、手動代理伺服器，還是直接連線。應用程式中設定的獨立代理伺服器，可能會覆蓋系統 VPN 路徑。

• ✅ 瀏覽器：建立新的無痕視窗，避免舊連線、快取頁面與擴充功能狀態干擾結果。
• ✅ 終端工具：發起一次新的網路請求，並與瀏覽器看到的出口資訊比較。
• ✅ 桌面應用程式：完全結束後重新開啟，避免繼續沿用連線前建立的長連線。
• ✅ 用戶端記錄：查看目標網域或連線是否被標記為代理伺服器、直連或拒絕。
• ✅ 分流規則：確認目標符合預期規則，而不是被地區、網域或程序規則改寫。
• ✅ 中斷後複測：中斷線路後再次執行相同操作，確認結果確實會隨連線狀態變化。

如果瀏覽器生效而桌面軟體未生效，常見原因是用戶端只設定了系統代理伺服器，而該軟體忽略系統代理伺服器。此時可以檢查用戶端是否支援 TUN 模式，或在軟體自身設定中指定支援的代理伺服器。反過來，如果桌面軟體生效而瀏覽器未生效，則要檢查瀏覽器擴充功能、獨立代理伺服器設定與加密 DNS。

分流規則也可能依網域、位址區段、程序或目標地區決定路徑。在規則模式下，部分網站直連、部分網站經過節點是正常行為。測試重點不是要求所有請求都顯示相同出口，而是確認每類請求都符合規則預期。若要進行全域驗證，可以暫時切換至用戶端提供的全域模式，完成測試後再恢復原本的分流策略。

協定與訂閱匯入：已連線為何仍可能沒有流量

Shadowsocks、VMess、Trojan 與 VLESS 通常由通用用戶端以本地代理伺服器或 TUN 方式接管流量。協定連線成功，只代表用戶端能與遠端服務通訊；如果系統代理伺服器未開啟、TUN 介面未啟用，或應用程式繞過本地代理伺服器，業務流量仍可能直連。

Hysteria2 與 TUIC 通常以 QUIC 和 UDP 傳輸。某些網路會限制 UDP，用戶端可能出現反覆握手、連線後沒有資料，或切換網路後失去可用路徑。排查時應先查看用戶端記錄是否持續傳輸，再檢查目前網路是否允許相應傳輸方式，並使用服務端實際提供的備用設定進行比較。不要因協定名稱相同，就認為設定可以互換；驗證資訊、傳輸參數與服務端能力必須相符。

訂閱連結本質上是用戶端取得節點設定的入口。成功匯入不代表節點內容會永遠保持最新。服務端設定更新後，舊用戶端可能仍保留快取；不同用戶端對訂閱欄位與進階參數的支援也可能不同。遇到「節點顯示正常但無法存取」時，應先更新訂閱、重新選擇節點，並確認用戶端是否支援該設定，而不是自行猜測並修改未知欄位。

1. 確認訂閱更新成功，清單中沒有明顯的解析錯誤或不支援提示。
2. 選擇一條設定完整的線路，檢查用戶端記錄是否能完成連線並持續傳輸。
3. 確認系統代理伺服器或 TUN 接管已啟用，再執行出口 IP 比較。
4. 檢查 DNS 與分流規則，確認測試目標沒有被設定為直連。
5. 改用同一服務提供的另一種可用設定進行比較，區分網路限制與單一節點問題。

IEPL 專線、中轉與直連：線路類型不等於路由結果

直連通常表示用戶端直接連線至遠端入口，路徑主要由目前網路與公網路由決定。中轉線路會先連線至較近或較適合接入的中轉節點，再轉往遠端出口。IEPL 專線通常表示跨境骨幹段採用專線資源，但產品標示本身無法證明本機所有應用程式都已進入該線路。

無論使用哪種線路，驗證方法都相同：先查看目標請求的出口，再確認 DNS 是否符合策略，最後確認應用程式是否符合對應規則。線路類型主要影響傳輸路徑與網路表現，不能取代本機路由檢查。即使遠端線路運作正常，只要系統代理伺服器未啟用或目標被設定為直連，出口檢測仍會顯示本地網路。

中轉線路也可能出現入口與出口歸屬不同的情況。用戶端實際連線的是入口，而公開網站看到的是最終出口，兩者並不矛盾。排查時不要把用戶端記錄中的接入位址直接當成網頁應顯示的出口位址，應分別依據服務設定說明與最終請求結果判斷。

典型誤判：看似已連線、實際上沒有經過 VPN

另一個常見誤判來自長連線。協作軟體、瀏覽器分頁與背景同步程式可能繼續使用連線 VPN 前建立的工作階段，短時間內不會重新選擇路徑。測試時應完全結束目標應用程式，再於連線完成後重新開啟。只重新整理介面不一定會關閉底層連線。

IPv4 與 IPv6 也需要同時考量。部分網路與用戶端只接管其中一種協定，應用程式可能優先選擇未被接管的路徑。若檢測工具分別顯示兩類出口，應確認它們是否都符合用戶端策略。用戶端明確只支援其中一種時，應依照其文件設定系統網路，避免另一類流量意外繞行。

排查順序：從本機設定到線路狀態

排查應由近到遠進行。先確認本機接管狀態與規則，再檢查協定工作階段，最後才判斷遠端線路。如此可避免在系統代理伺服器尚未啟用時反覆更換節點，也能將應用程式、DNS 與線路問題分開。

• ✅ 建立中斷狀態下的出口 IP 與 DNS 基準。
• ✅ 更新訂閱，並確認目前用戶端能完整識別所選設定。
• ✅ 檢查系統代理伺服器、TUN 介面或平台 VPN 介面是否已啟用。
• ✅ 使用新的瀏覽器工作階段複查出口 IP，並排除快取與擴充功能影響。
• ✅ 核對系統 DNS、瀏覽器安全 DNS 與用戶端 DNS 策略。
• ✅ 查看分流記錄，確認測試網域或程序符合預期規則。
• ✅ 完全重新啟動目標應用程式，避免連線前的長連線繼續重用。
• ✅ 更換同一服務內的其他可用線路，比較是否為單一線路問題。
• ✅ 切換網路後重新建立通道，檢查路由與傳輸是否恢復。

如果出口、DNS 與應用程式路由都符合預期，但目標服務仍無法使用，問題可能位於目標服務策略、帳號狀態、應用程式快取或目前網路品質，而不是 VPN 是否生效。此時應保留用戶端記錄、測試時間、所選線路與具體應用程式現象，再提交給服務支援排查。若記錄中包含訂閱連結、驗證欄位或連線憑證，應先移除這些敏感內容。