如何確認 VPN 是否真的生效：查 IP、查 DNS 的新手完整自我檢查

如何確認 VPN 是否真的生效，不能只看用戶端是否顯示「已連線」。這個狀態通常只能證明用戶端完成握手，無法單獨證明瀏覽器、命令列工具與其他應用程式的流量都經過通道。可靠的檢查方式，是先建立斷線時的基準，再依序核對出口 IP、DNS、IPv6、系統路由與應用程式分流。

最實用的方法不是尋找某個「一鍵通過」的結果，而是進行連線前後的同條件對照。使用同一台裝置、同一個網路與同一個檢測頁面，記錄斷線和連線時的差異。如果出口位址已變更，但 DNS 仍由本地網路提供，表示網頁流量與網域名稱解析可能走了不同路徑；如果瀏覽器有變化而其他應用程式沒有，通常與系統代理、TUN 模式或分應用程式規則有關。

先建立未連線時的網路基準

檢查前先完全中斷用戶端連線，並確認沒有其他代理程式、瀏覽器擴充功能或舊連線仍在執行。開啟本網站的 IP 檢測頁面，記錄目前出口 IP 所屬的網路業者、國家或地區，以及位址類型。這裡的重點是「對照」，不是判斷基準位址本身是否正常。

接著查看目前使用的 DNS 解析器。不同檢測工具對解析器名稱與地區的辨識可能不一致，因此不要只盯著地圖位置。更有價值的是確認解析器是否明顯屬於本地網路業者、路由器，或先前手動設定的公共 DNS 服務。

• ✅ 中斷用戶端連線後重新整理 IP 檢測頁面，記錄出口網路與地區。
• ✅ 關閉可能獨立代理流量的瀏覽器擴充功能，避免基準受到舊設定影響。
• ✅ 記錄 DNS 解析器名稱，不要直接把地理位置偏差判定為洩漏。
• ✅ 確認裝置目前連線至預期網路，排除網路切換造成的出口變化。
• ✅ 保留檢測頁面，建立連線後使用同一頁面重新測試。

連線後檢查出口 IP 是否切換

啟動用戶端、選擇線路並等待狀態穩定，然後回到原本的檢測頁面重新載入。在全域通道模式下，公網出口通常應從本地網路的出口切換至所選線路對應的出口網路。如果位址、網路業者和地區都沒有出現符合預期的變化，應先按「未生效」處理，而不是繼續依賴用戶端圖示。

出口 IP 發生變化是必要的檢查項目，但仍不是完整結論。瀏覽器可能透過擴充功能或系統代理進入線路，而其他應用程式繼續直接連線；反過來，啟用 TUN 後，大部分系統流量可能已進入通道，但被規則指定為直連的網站仍會顯示本地出口。測試前必須先確認用戶端目前採用的是全域、規則或直連模式。

為什麼只檢查一個網頁還不夠

系統代理主要影響會讀取系統代理設定的應用程式。部分命令列工具、遊戲、更新程式與採用自有網路堆疊的軟體可能會忽略這項設定。TUN 模式則會建立虛擬網路介面，並透過系統路由接管更多流量，但仍可能受到排除規則、介面優先順序與系統權限影響。

瀏覽器擴充功能的涵蓋範圍更窄，通常只處理該瀏覽器中的請求。看到網頁出口已經變更，不能因此推斷整台裝置都已進入通道。需要保護其他應用程式時，應檢查用戶端是否啟用系統代理或 TUN，以及目標應用程式是否被加入繞過清單。

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

造訪網站時，裝置通常會先將網域名稱交給 DNS 解析器，再連線至解析出的伺服器位址。即使網頁資料已經透過通道傳輸，DNS 查詢仍可能被瀏覽器、安全軟體、作業系統或本地網路單獨處理。所謂 DNS 洩漏，關注的正是解析請求是否意外離開預期路徑。

連線至線路後執行 DNS 檢測，並與基準結果比較。如果仍出現本地網路業者的解析器，而用戶端表示 DNS 應由通道接管，就需要進一步排查。若結果顯示公共 DNS 或線路提供的解析器，則不能只因解析器所在地與線路地區不同，就判定為異常。公共 DNS 廣泛採用任播網路，檢測資料庫也可能將同一項服務標示在不同地區。

瀏覽器加密 DNS 會改變結果

部分瀏覽器可以獨立啟用加密 DNS。啟用後，網域名稱請求可能繞過作業系統預設解析器，直接傳送給瀏覽器設定的服務。這種行為不一定代表洩漏，但會讓瀏覽器與其他應用程式使用不同的解析路徑。排查時應查看瀏覽器的安全 DNS 設定，並確認是否符合目前需求。

如果希望所有應用程式都由用戶端統一處理 DNS，可以先暫時關閉瀏覽器的獨立解析，再重新檢測。若關閉後結果恢復正常，問題通常位於瀏覽器設定，而不是節點協定。若結果仍指向本地網路，則繼續檢查用戶端的 DNS 接管、TUN 權限與系統網路設定。

排查 IPv6、WebRTC 與分流規則

部分網路同時提供 IPv4 與 IPv6。如果用戶端只接管 IPv4，而系統仍優先透過 IPv6 存取目標，檢測結果可能出現兩套出口：IPv4 來自線路，IPv6 來自本地網路。這種情況通常稱為 IPv6 洩漏。

處理方式取決於用戶端能力。支援完整雙堆疊 TUN 的用戶端可以同時路由兩類流量；有些用戶端會在連線期間關閉未接管的 IPv6；另一些則要求在系統網路設定中個別處理。不了解影響前，不要長期修改系統設定。較穩妥的順序是先更新用戶端設定、檢查 TUN 與 DNS 選項，再依照用戶端文件調整系統網路。

WebRTC 是瀏覽器中的即時通訊能力。檢測頁面有時會顯示本地介面位址、虛擬介面位址，或經過匿名化處理的候選位址。看到區域網路位址不代表公網出口已洩漏，因為區域網路位址本身不能直接代表外部存取路徑。判斷重點仍是是否暴露了不應出現的公網直連出口。

分流會讓不同網站看到不同出口

規則模式會依照網域名稱、IP、應用程式或規則集，決定走線路還是直連。例如本地服務可以直連，國際網站則透過線路。此時兩個檢測頁面得到不同出口不一定是故障，也可能只是它們符合了不同規則。

排查分流時，先將用戶端暫時切換至全域模式，再重複出口與 DNS 檢查。如果全域模式正常、規則模式異常，表示連線與節點本身大致可用，問題更可能出在規則比對。接著查看用戶端連線記錄，確認檢測網域名稱符合代理、直連還是拒絕規則。

1. 中斷目前連線，記錄 IP 與 DNS 基準。
2. 啟用全域模式，並重新連線至同一條線路。
3. 重新整理同一個檢測頁面，核對出口、DNS 與 IPv6。
4. 恢復規則模式，再觀察結果是否改變。
5. 查看連線記錄中的網域名稱比對結果與最終出站。
6. 修正規則後重新測試，不要用舊頁面結果取代新請求。

依平台確認路由是否真的變更

不同平台賦予用戶端的網路權限不同，檢查入口也不完全一致。Windows 與 macOS 通常同時存在系統代理與虛擬網路介面兩種實作；Linux 更常直接查看路由表、策略路由與 DNS 服務；iOS 與 Android 主要透過系統提供的 VPN 介面運作，應用程式端可見的底層路由資訊較少。

Windows

在用戶端內確認目前模式。如果只啟用系統代理，瀏覽器可能正常，而忽略代理設定的程式仍會直接連線。需要更廣泛的涵蓋範圍時，檢查用戶端是否支援並啟用 TUN，同時確認虛擬介面沒有被安全軟體阻擋。可在終端機執行以下命令查看路由表：

route print

檢查是否出現由用戶端建立的虛擬介面，以及預設路由或目標網段是否指向該介面。路由表內容會因用戶端實作而異，不能只依介面名稱判斷；應結合連線記錄與出口檢測一併確認。

macOS 與 Linux

macOS 可透過系統網路設定查看代理狀態，也可以檢查路由表是否出現通道介面。Linux 桌面環境、網路管理服務與命令列用戶端的組合較多，尤其要留意策略路由與 DNS 服務是否同時更新。

netstat -rn
ip route

macOS 環境通常使用前一個命令查看路由；Linux 可使用後一個命令。若用戶端採用透明代理，也可能借助系統防火牆規則重新導向流量，此時僅查看預設路由未必能呈現完整路徑，需要結合用戶端記錄判斷。

iOS 與 Android

行動裝置通常會顯示系統層級的 VPN 狀態，但狀態圖示仍只代表系統介面已建立。應在連線前後使用同一個 IP 檢測頁面進行對照，並檢查用戶端是否啟用按應用程式繞過、僅代理指定應用程式或本地網路直連等選項。

如果切換網路後連線狀態仍在，但網頁無法存取，可以先中斷連線，再重新建立通道。網路介面變更可能導致舊工作階段失效，而用戶端介面尚未及時更新。若某個應用程式始終直接連線，則檢查該應用程式是否被分應用程式規則排除。

協定、訂閱與線路類型不能取代驗證

Shadowsocks、VMess、Trojan、VLESS、Hysteria2 和 TUIC 都可以承載代理流量，但協定名稱本身不能證明系統流量已進入通道。Shadowsocks 屬於加密代理協定；VMess 與 VLESS 常見於支援多種傳輸方式的用戶端；Trojan 通常使用 TLS 外觀承載連線；Hysteria2 與 TUIC 採用 QUIC 方向的傳輸設計，更著重複雜網路環境下的傳輸表現。

這些協定解決的是用戶端與伺服器之間如何傳輸資料。系統代理、TUN、DNS 接管與分流規則解決的則是「哪些請求會交給這個連線」。節點握手成功，只能表示用戶端可以與伺服器通訊。如果應用程式沒有被路由至對應出站，仍可能使用本地網路。

訂閱連結也只是設定分發入口。匯入訂閱後，用戶端會取得節點、名稱與相關參數，但仍需選擇可用節點、建立連線，並啟用正確的系統接管方式。訂閱更新成功不等於目前節點已連線，選取節點也不代表系統代理或 TUN 已開啟。

IEPL 專線、中轉與直連描述的是用戶端到線路出口之間的上游路徑。直連通常由裝置直接連線至遠端入口；中轉會先進入中間節點，再轉送至出口；IEPL 專線通常強調營運端的跨境傳輸鏈路。無論上游採用哪種路徑，本地驗證方式都相同：檢查請求是否由用戶端接管、出口是否符合預期，以及 DNS 是否依設定處理。

看似連線成功但未生效的常見原因

如果用戶端顯示已連線，而檢測結果仍是本地出口，可以依照下列順序處理。每次只修改一項，然後重新連線並測試。一次修改多項設定，會讓故障來源難以判斷。

• ❌ 只選擇了節點，沒有開啟系統代理或 TUN。
• ❌ 瀏覽器擴充功能已連線，但其他應用程式不受擴充功能控制。
• ❌ 檢測網站被分流規則指定為直連。
• ❌ 目標應用程式位於按應用程式繞過清單中。
• ❌ 系統中仍有舊代理設定，流量被交給另一個本機連接埠。
• ❌ 未授予 TUN 所需權限，虛擬介面沒有正確建立。
• ❌ IPv4 已進入線路，但 IPv6 仍經由本地網路連出。
• ❌ 瀏覽器獨立 DNS 與用戶端 DNS 策略不一致。
• ❌ 切換網路後舊工作階段失效，用戶端狀態尚未重新整理。
• ❌ 多個用戶端同時修改系統代理或路由，設定彼此覆蓋。

遇到多個用戶端衝突時，應先全部中斷連線，退出不使用的用戶端，再清除系統代理並重新連線。切換用戶端前先中斷目前連線，可減少舊虛擬介面、舊 DNS 與殘留代理狀態造成的干擾。

若只有特定網站無法存取，不要立刻判斷整條線路失效。先測試其他網站，再觀察 DNS 是否能完成解析、連線記錄是否符合拒絕規則，以及網站是否主動限制目前出口。整條線路故障通常會影響多個目標；單一網站異常則更可能與分流、解析、出口限制或網站本身狀態有關。

建立可重複執行的完整自我檢查流程

一套穩定的驗證流程應能重複執行，而且每一步都有明確結論。先中斷連線建立基準，再以全域模式驗證線路的基礎能力，之後才恢復日常分流。如此可將節點問題、系統接管問題與規則問題分開處理。

1. 關閉其他代理程式與擴充功能，中斷用戶端連線。
2. 記錄本地出口網路、地區、DNS 與 IPv6 狀態。
3. 連線至目標線路，確認系統代理或 TUN 已啟用。
4. 在同一個頁面重新檢查出口 IP。
5. 執行 DNS 檢測，核對解析器歸屬。
6. 檢查 IPv6 是否進入通道或已正確處理。
7. 分別測試瀏覽器與實際要使用的應用程式。
8. 恢復分流規則，查看目標網域名稱符合的出站。
9. 切換網路後重新執行關鍵檢查，不要沿用舊結論。

最終判斷不依賴單一綠色提示，而是看多項結果是否一致。出口 IP 證明目前請求從哪裡離開公網，DNS 說明由誰解析網域名稱，IPv6 檢查補足雙堆疊路徑，應用程式測試則驗證分流範圍。四者都符合目前設定，才能較有把握地確認 VPN 已依預期生效。