VPN 是否有效：新手完整驗證指南

判斷 VPN 是否有效，不能只看客戶端是否顯示「已連線」。這個狀態通常只能證明客戶端與遠端節點已建立工作階段，不能證明瀏覽器、桌面軟體與系統 DNS 都如預期經過線路。可靠的驗證應同時檢查出口 IP、DNS 解析路徑，以及特定應用程式的連線結果。

實際排查時，先記錄未連線狀態，再連線線路並重複相同測試。只有前後結果能夠比較，才能區分線路未接管流量、分流規則主動直連、應用程式忽略系統代理，以及檢測頁面快取舊結果等情況。以下流程會從最容易確認的出口位址開始，逐步深入路由模式、協定與平台差異。

先了解「已連線」究竟代表什麼

客戶端顯示已連線，通常表示本機軟體已與伺服器建立加密工作階段，驗證與協定交握也已完成。對於 Shadowsocks、VMess、Trojan、VLESS 等常見代理協定，這代表本機代理入口可以向節點傳送資料；對於採用 UDP 與 QUIC 特性的 Hysteria2、TUIC，這個狀態同樣主要反映傳輸工作階段是否建立。它並不自動等於所有系統流量都已進入該工作階段。

流量是否真正經過線路，還取決於客戶端採用哪種接管方式。系統代理會修改作業系統的代理設定，通常只影響遵循該設定的程式；TUN 模式透過虛擬網路介面接管更廣泛的 IP 流量；瀏覽器擴充功能通常只處理瀏覽器內部請求。部分應用程式擁有獨立網路堆疊、內建代理或自己的 DNS 機制，可能不會遵循系統代理。

使用出口 IP 完成第一輪驗證

出口 IP 是最直觀的檢查項目。先中斷客戶端連線，開啟能顯示公用位址與大致出口地區的檢測頁面，記錄目前結果。接著連線目標線路並重新整理檢測頁面。如果位址與出口地區依線路選擇出現相應變化，即可確認這次網頁請求已經過遠端出口。

測試時應盡量使用同一個瀏覽器、同一個檢測頁面與相近的網路環境。瀏覽器快取、頁面指令碼未重新執行，或網路在 Wi-Fi 與其他連線之間切換，都會讓比較失去意義。若只按一般重新整理仍顯示舊資料，可以關閉檢測分頁後重新開啟，或使用瀏覽器的私密視窗再次檢查。

1. 中斷線路，記錄目前的公用出口位址與地區。
2. 關閉可能自動選擇節點的功能，手動連線需要驗證的線路。
3. 重新開啟檢測頁面，不要只依賴先前分頁中的舊結果。
4. 比較連線前後的位址與地區，並確認結果符合所選節點。
5. 再使用實際需要存取的應用程式測試，避免只驗證瀏覽器。

如果出口位址沒有變化，先檢查客戶端模式。處於「系統代理」模式時，檢測瀏覽器必須遵循系統代理；若瀏覽器使用獨立代理設定，可能會繞過客戶端。處於「規則」模式時，檢測網站也可能被規則判定為直連，此時可以暫時切換至全域接管進行診斷。全域模式適合用來定位問題，不一定適合作為長期設定。

還要留意 IPv4 與 IPv6 的差異。有些網路同時提供兩類位址，而客戶端只接管其中一種。如果檢測頁面優先使用未被接管的位址，就可能暴露本地出口，或出現不同頁面顯示不同地區的情況。排查時應分別查看兩類連線結果，並確認客戶端、作業系統與目前節點對它們的處理方式一致。

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

存取網域之前，裝置通常需要先將網域解析為 IP 位址。DNS 洩漏是指原本應透過指定線路或指定解析器處理的查詢，意外傳送至本地網路提供的解析服務。此時網頁內容可能經過遠端出口，但網域查詢仍留在本地路徑。它不一定會造成連線失敗，卻表示實際流量路徑與設定預期不一致。

進行 DNS 檢查時，應先連線線路，再開啟 DNS 檢測頁面並發起新的查詢。重點不是要求解析伺服器一定與出口伺服器位於同一城市，而是判斷結果是否來自預期的解析方案。例如，客戶端可能使用伺服器端解析，也可能明確指定公共解析器；只要結果與設定一致，就不能僅憑地理位置不同判定為洩漏。

瀏覽器的安全 DNS 功能也會影響結果。啟用後，瀏覽器可能繞過作業系統的一般解析流程，直接向瀏覽器設定的解析服務傳送加密查詢。因此，檢測結果可能與其他應用程式不同。排查階段可以分別測試啟用與停用此功能時的表現，但不要在不了解原始設定的情況下長期修改。

• 只有瀏覽器結果異常：檢查瀏覽器安全 DNS、擴充功能與獨立代理設定。
• 所有應用程式都出現本地解析：檢查客戶端 DNS 接管、TUN 設定與系統網路優先順序。
• 切換節點後仍保留舊解析：清除系統與瀏覽器 DNS 快取，再發起新的網域請求。
• 結果來自明確指定的公共解析器：對照客戶端設定判斷，不要只依地區推測。

在規則分流環境中，DNS 也會參與網域分類。部分客戶端會先解析網域再比對 IP 規則，部分客戶端則優先依據網域規則決定直連或代理。如果規則集過舊，或網域被錯誤分類，可能出現頁面主體走線路、圖片或登入介面走直連的混合狀態。此時需要查看連線記錄中的網域、比對規則與最終出站，而不是反覆更換節點。

驗證瀏覽器與桌面應用程式是否分別生效

透過網頁確認出口後，還應測試實際使用的軟體。瀏覽器、下載工具、遊戲、命令列程式與商店應用程式對系統代理的支援並不一致。有些程式會自動讀取系統代理，有些只支援自己的代理設定，另一些則更適合透過 TUN 虛擬介面接管。只測試一個網頁，很容易忽略分應用程式差異。

可以先選擇一個能顯示網路地區或連線狀態的網頁服務，在不同瀏覽器中分別開啟，再測試目標桌面應用程式。如果其中一個瀏覽器的出口有變化、另一個沒有，問題通常出在瀏覽器代理設定、擴充功能或安全 DNS。如果瀏覽器正常但桌面軟體仍使用本地網路，優先檢查該軟體是否忽略系統代理，以及客戶端是否提供 TUN 或應用程式層級分流。

分流規則本身並不是故障。規則模式通常會讓本地服務直連，讓指定網域或地區經過線路。因此，看到不同網站使用不同出口，可能正是設定預期的行為。驗證時應先釐清目標：是希望所有流量統一經過線路，還是只讓特定應用程式與網域經過線路。目標不同，正確結果也不同。

若客戶端支援連線記錄，可以在開啟目標應用程式的同時觀察新出現的連線紀錄。記錄通常會顯示目標網域或位址、命中的規則，以及最終選擇的直連或代理出站。記錄比單純觀察「已連線」更有診斷價值，但其中可能包含存取網域，分享截圖前應先檢查並遮蓋不希望公開的資訊。

了解直連、中轉與 IEPL 線路的驗證差異

線路名稱描述的是裝置到出口之間採用的路徑，不會改變驗證的基本原則。直連通常表示裝置直接連線至遠端節點，路徑結構較簡單，但品質更依賴目前網路到節點的公網路由。中轉線路會先連線入口或中繼節點，再由中繼轉送至出口，用於調整跨網路徑或改善某些網路環境下的連線表現。

IEPL 通常指電信業者提供的國際乙太網路專線能力。在代理服務的線路架構中，它常用於入口到服務商端交付點之間的專用傳輸區段；最終存取目標網站時，仍可能從出口接入公用網際網路。不同服務商對線路名稱的使用方式可能不同，因此應結合線路說明理解，不能僅憑名稱推斷整條路徑的所有細節。

無論使用直連、中轉或 IEPL，出口 IP 檢測看到的通常都是最終出口，而不是中繼節點。中轉是否存在，也不能只靠一般網頁檢測準確判斷。對一般使用者而言，更重要的是確認最終出口地區正確、目標應用程式確實走線路、DNS 路徑符合設定，以及切換線路後舊連線能夠重新建立。

切換線路後，有些應用程式會繼續重用已建立的長連線，因此出口檢測頁面已更新，應用程式內的工作階段卻仍維持舊路徑。此時應關閉應用程式內的活動頁面，必要時完全退出應用程式後重新啟動。若客戶端提供斷線時阻止流量的選項，也應另外驗證線路意外中斷後，應用程式是停止連線，還是回落至本地網路。

訂閱匯入成功但流量沒有經過節點，該怎麼辦？

訂閱連結的作用是向客戶端提供節點與相關設定。成功匯入只能表示客戶端能讀取訂閱內容，不代表節點可連線，也不代表系統流量已被接管。更新訂閱後，應確認目前實際選取的節點、代理模式、系統代理或 TUN 狀態，以及規則集是否已完成載入。

Shadowsocks、VMess、Trojan、VLESS、Hysteria2 與 TUIC 對客戶端能力及傳輸參數有不同要求。較舊的客戶端可能能顯示訂閱中的節點名稱，卻無法完整識別某些協定欄位。遇到節點持續逾時、交握失敗或連線後沒有流量時，應先使用服務提供方支援的客戶端版本重新匯入，而不是手動猜測加密方式、傳輸層或憑證參數。

• 確認訂閱內容已更新，目前選取的不是已移除或失效的設定。
• 確認客戶端支援節點所使用的協定與傳輸參數。
• 檢查系統代理或 TUN 是否真正啟用，而不只是節點按鈕處於連線狀態。
• 暫時使用更直接的路由模式測試，以排除規則誤比對。
• 查看連線記錄，區分節點交握失敗、DNS 失敗與路由直連。
• 恢復規則模式後，再逐一驗證瀏覽器與目標應用程式。

如果客戶端同時提供「延遲測試」與「連線測試」，還要了解兩者並不等價。節點能夠回應探測，只表示探測請求可到達；實際網頁與應用程式還涉及 DNS、TCP 或 UDP 連線、TLS 交握、路由規則及目標服務本身的狀態。因此，即使節點列表顯示可用，仍應完成出口 IP 與實際應用程式驗證。

不同平台上的重點檢查項目

Windows

Windows 客戶端常見系統代理與 TUN 兩種接管方式。系統代理適合遵循作業系統代理設定的軟體，但部分命令列工具、商店應用程式或獨立網路程式可能繞過它。TUN 的涵蓋範圍通常更廣，但可能受到其他虛擬網卡、安全軟體與路由優先順序影響。排查時可查看系統代理是否已寫入，並確認退出客戶端後設定是否正確恢復。

macOS

macOS 客戶端可能透過系統代理或 Network Extension 建立通道。系統設定中的 VPN 狀態與客戶端狀態應保持一致。如果其他網路工具也安裝了網路擴充功能，規則可能互相競爭。遇到只有部分應用程式生效時，先停用重複的代理設定，再重新連線並檢查出口與 DNS。

iOS 與 iPadOS

行動作業系統上的客戶端通常透過系統提供的 VPN 介面接管流量。狀態列標示表示設定處於連線狀態，但應用程式內已有的工作階段仍可能短暫重用舊連線。切換線路後，可以完全關閉目標應用程式再重新開啟。瀏覽器內容過濾、私密轉送類功能或其他 VPN 設定也可能改變觀察結果，應避免同時啟用用途重疊的網路設定。

Android

Android 客戶端可能支援按應用程式分流。若某個應用程式被排除，它會繼續使用本地網路，即使其他應用程式已經經過線路。還應檢查系統是否限制客戶端在背景執行；客戶端暫停後，既有的 VPN 標示與實際連線狀態可能不同步。診斷時應讓客戶端保持在前景執行，並核對按應用程式設定的規則。

平台差異不會改變核心驗證順序：先確認客戶端工作階段，再比較出口 IP，接著檢查 DNS，最後逐一測試目標應用程式。不要在尚未確定問題層級時同時修改節點、協定、DNS 與分流規則，否則很難判斷是哪項調整真正解決了問題。

已連線但無法存取時的排查順序

當客戶端顯示已連線，但網頁無法開啟或目標應用程式仍使用本地出口時，最有效的方法是一次只改變一個變數。先確認中斷線路時本地網路可正常使用，再檢查節點連線；接著檢查接管模式、DNS 與分流規則。如此可以將問題定位至本地網路、節點工作階段、系統路由或單一應用程式。

1. 中斷線路，確認本地網路本身能正常解析並存取常用頁面。
2. 重新連線目前節點，查看客戶端記錄是否出現交握或驗證錯誤。
3. 更換同類線路測試，區分單一節點問題與客戶端設定問題。
4. 檢查系統代理或 TUN 狀態，並暫時排除其他網路工具的干擾。
5. 使用出口 IP 頁面確認檢測請求是否進入遠端出口。
6. 檢查 DNS 結果，再查看規則記錄中的比對結果與最終出站。
7. 完全退出目標應用程式後重新開啟，避免舊工作階段繼續重用原本的路徑。

如果出口 IP 正確，但某項服務仍顯示原本地區，可能是該服務保留了帳戶地區、快取、定位權限或舊工作階段資訊，不一定代表線路失效。反過來，即使頁面可以開啟，也不能據此斷定流量一定經過線路；直連同樣可能存取成功。最終仍應根據出口結果、DNS 路徑與應用程式記錄的綜合證據判斷。

驗證完成後，將暫時切換為全域模式的路由設定還原為日常配置，並再次測試重要應用程式。若需要向技術支援提交問題，建議提供平台與客戶端版本、節點協定、接管模式、發生問題的應用程式類型，以及移除敏感內容後的錯誤記錄。清楚描述「哪個應用程式沒有經過線路」，會比只說「VPN 無法運作」更容易定位問題。