VPN 已連線卻沒生效？出口 IP、DNS 與個別應用驗證完整指南

先釐清：連線狀態究竟代表什麼

有些用戶端在代理核心啟動後就會顯示運作中；有些會確認與遠端節點的握手；系統 VPN 通常還會建立隧道介面。這些狀態各自代表不同環節，單憑其中一項，無法判斷特定應用實際使用哪條路徑。最終出口仍取決於系統代理、路由表、應用程式設定與分流規則。

因此，「網頁能開啟」和「所有流量都符合預期」並非同一回事。先釐清目標：是只讓指定網站經由線路，還是希望用戶端支援的應用流量都進入隧道。目標不同，判定成功的標準也不同。

出口 IP：使用同一個瀏覽器前後比對

1. 建立基準資料。中斷用戶端連線，在瀏覽器查詢公用出口 IP，記下位址、所屬網路與大致位置。檢測頁可能會顯示網路資訊，請勿任意公開完整結果。
2. 連線後重新查詢。選擇目標線路，確認用戶端已啟用預期的系統代理或隧道模式，再重新載入檢測頁。不要只看頁面上保留的舊結果。
3. 核對規則。若 IP 沒有變化，先在用戶端的連線清單中查找該檢測網域，確認它被判定為直連或代理。若檢測網站符合直連規則，結果不代表其他網站也會直連。
4. 分別檢查 IP 位址類型。裝置同時支援 IPv4 和 IPv6 時，應分別核對。只看到其中一種出口變更，不能推斷另一種流量也已經過線路。
5. 交叉驗證。使用不同的檢測來源比對 IP 位址。地理位置資料庫可能更新較慢；國家或城市標示不一致時，先比對實際位址與所屬網路，不要只憑地圖判定失敗。

若啟用了瀏覽器代理擴充功能，測試系統用戶端時，應先停用可能衝突的擴充功能並記下原設定。企業網路、其他 VPN 或安全軟體也可能改寫路由；排查時盡量只保留待驗證的流量接管工具，請勿擅自停用組織要求的安全措施。

DNS：分辨正常解析與意外洩漏

DNS 負責將網域名稱解析為連線所需的位址。網頁內容經過代理，不代表網域查詢也一定經過代理。應用可能使用系統 DNS、瀏覽器的安全 DNS，或用戶端提供的解析服務；有些連線方式會將網域交由遠端解析，有些則會先在本機解析。

判斷 DNS 是否洩漏，應以預期策略為準。若原本預期相關網域透過隧道解析，卻意外送往本地網路的解析器，就需要檢查設定。反過來說，規則模式若刻意讓本地網站在本地解析，就不能只因出現本地解析器而認定故障。

• ✅ 先查看用戶端的 DNS 模式、上游解析設定，以及 DNS 查詢是否由用戶端接管；相關選項可能稱為 DNS 劫持、DNS 路由或類似名稱。
• ✅ 使用 DNS 檢測頁觸發新的測試查詢，與中斷連線時的結果比對，同時查看用戶端是否有相應的解析記錄。
• ✅ 檢查瀏覽器的安全 DNS 設定。加密 DNS 能保護查詢傳輸，但單靠這項設定無法證明解析請求經過 VPN 出口。
• ❌ 不要只因解析器所在國家與節點不同，就認定發生洩漏。公用解析服務可能使用分散式節點，檢測結果也可能反映其網路歸屬。
• ❌ 不要任意改用陌生的 DNS 位址。先確認用戶端文件中的要求，以免影響內部網域、公司服務或既有分流策略。

DNS 檢測頁通常觀察的是向其測試網域發出查詢的遞迴解析器，不一定是裝置直接連線的伺服器。系統設定、瀏覽器設定與用戶端記錄應一併檢視。快取也可能讓查詢暫時不顯示；請重新觸發測試，不要直接把記錄空白視為異常。

系統代理與 TUN：為什麼只有部分應用生效

系統代理會提供代理入口，讓願意遵循該設定的應用使用。瀏覽器通常支援，但有些桌面軟體、命令列工具或遊戲會忽略設定，或使用自己的代理配置。HTTP 代理與 SOCKS 代理能否使用，也取決於用戶端和應用的實作；不能只看到「系統代理已啟用」，就認定所有連線都已接管。

TUN 模式透過虛擬網路介面搭配路由接管流量，涵蓋範圍通常比系統代理更廣，但仍受應用排除設定、目標網段、DNS、權限與協定支援影響。TUN 不代表「所有流量必定經過遠端」。在規則模式下，進入 TUN 的流量也可能依用戶端規則直連。

逐一為應用建立驗證依據

先完全結束目標應用，再連線至線路並重新開啟應用，排除沿用舊連線的可能。接著執行容易辨識的操作，例如重新整理遠端內容或重新連線至服務；在用戶端連線清單中尋找應用程序或目標網域，確認符合的規則、策略群組與最終節點。

若用戶端沒有連線記錄，可使用目標應用內建的網路診斷，或可信的遠端連線記錄輔助判斷。單憑軟體介面語言、推薦內容或存取速度變化，無法準確推斷出口。請勿為了測試而將存取權杖、訂閱連結或密碼傳送至陌生的檢測工具。

在 Windows 上，有些程式使用獨立的代理堆疊；在 macOS 上，請確認已核准用戶端所需的網路權限。iOS 和 Android 則應檢查系統 VPN 狀態，以及用戶端是否設定了個別應用排除。Linux 的桌面代理設定與終端機環境變數也可能互不相關，必須分別驗證。

使用系統指令輔助檢查，但別把設定當成結果

以下指令只會讀取相關設定，不會替你變更網路設定。這些資訊有助於了解應用可能使用的路徑，但不能取代出口 IP 與應用實際連線的驗證。請在對應系統的終端機中執行，不要直接貼上其他平台的指令。

macOS：查看系統代理與解析設定

scutil --proxy
scutil --dns

前一項會顯示系統代理相關設定，後一項會顯示解析器與適用範圍。看到代理位址只代表設定存在；應用是否遵循、代理入口是否可用，仍須實際測試。系統可能同時列出多個解析器，不能把其中一列當成所有請求的唯一去向。

Windows：分別查看 WinHTTP 與 DNS 設定

netsh winhttp show proxy
Get-DnsClientServerAddress

後一項指令需在 PowerShell 中執行。WinHTTP 設定不等同於瀏覽器通常使用的使用者代理設定，因此即使輸出顯示直接存取，也不能證明瀏覽器沒有使用代理。DNS 位址清單只顯示介面設定，不一定包含瀏覽器安全 DNS 或用戶端內部解析路徑。

Linux：核對終端機代理環境變數

env | grep -i proxy

檢查是否有代理變數或略過清單。沒有輸出不代表沒有隧道；有環境變數也不表示所有工具都會讀取。分享指令結果前，請遮蔽內部位址、使用者名稱，以及可能包含憑證的代理 URL。

常見誤判：依據現象找出故障環節

訂閱更新成功，卻無法存取目標網站

訂閱更新成功只表示設定已成功取得，不代表其中的節點目前可連線，也不代表正在使用剛匯入的設定。請核對目前使用的設定檔、選取的節點與連線記錄。Shadowsocks、VMess、Trojan、VLESS、Hysteria2、TUIC 等協定，必須有相應支援的用戶端；能開啟訂閱連結，不代表能正確處理所有項目。

瀏覽器正常，其他軟體仍無法使用

優先檢查應用是否忽略系統代理、是否有獨立代理設定或被排除，以及目前方案是否支援該應用所需的流量類型。不要只靠切換節點來解決流量接管範圍的問題；若請求根本沒有進入用戶端，切換出口通常不會改變結果。

出口已變更，網站仍拒絕存取

網站也可能參考帳戶地區、既有工作階段、定位授權或出口網路信譽。請在遵守網站規則的前提下，先確認帳戶與工作階段狀態，不要持續快速切換地區。出口變更只能證明網路路徑有所改變，不能保證網站會接受該出口或帳戶。

改用專線，結果還是一樣

IEPL 專線、中轉與直連描述的是線路傳輸方式，不是應用接管方式。這些方式不會自動解決瀏覽器擴充功能衝突、DNS 設定或分流錯誤。延遲較低、測速較快也不代表路徑驗證成功；應先確認流量的去向，再檢視傳輸表現。

判斷結果與提供排查資訊

需要協助時，請整理裝置系統、用戶端名稱、目前的流量接管模式、故障應用、目標網域，以及連線前後觀察到的差異。附上已遮蔽敏感資訊的規則命中記錄或錯誤記錄，並說明是否有其他 VPN、代理擴充功能或企業網路要求。請勿提供完整訂閱連結、密碼或存取權杖。

依固定順序處理：先確認設定與節點，再檢查流量接管，接著核對出口和 DNS，最後排查目標服務本身的限制。每次只調整一項相關設定，重新測試後記錄結果。這樣更容易找出故障範圍，也能避免為了解決單一應用的問題，反而改變其他應用原本正確的路徑。

用戶端安裝與匯入訂閱的方式，請參閱使用教學；如需了解 VPNBoat 的服務範圍與常見操作，請參閱常見問題。登入管理面板後即可取得用戶端與訂閱，個別平台的取得條件請以面板資訊為準。