VPN 已連線，如何確認生效？出口 IP、DNS 與個別應用檢查指南

先確認連線模式與檢查範圍

常見用戶端的連線方式包括系統代理、虛擬網卡接管及應用程式內代理。系統代理會在作業系統中設定代理，但應用是否使用仍視各自支援情況而定；虛擬網卡模式透過路由接管更多流量，也可能受排除清單、應用分流及系統權限影響。瀏覽器擴充功能通常只會影響瀏覽器中的部分請求，不能據此推斷其他軟體的流量路徑。

用戶端中的「全域」也有作用範圍：它可能表示「所有進入代理核心的請求都選用代理」，不等於作業系統中的每個應用都已被接管。檢查前，先記下目前的線路名稱、規則模式及連線方式。如果用戶端提供規則比對或連線記錄畫面，請保持開啟，稍後可用來對照請求與出口。

出口 IP：在相同條件下比較前後結果

出口 IP 是目標伺服器所看到的來源位址。中斷連線時，先開啟網路檢測頁面，記下頁面顯示的公網 IP；連上線路後，再用同一個瀏覽器重新檢查。不要只看國家名稱或旗幟，應優先比對 IP 位址本身。位址歸屬資料庫可能更新較慢，城市標示尤其不適合用來判斷線路的實際部署位置。

1. 先儲存正在處理的工作，暫時停用其他代理擴充功能或同時執行的網路用戶端，避免設定彼此干擾。
2. 記下未連線時的公網 IP 與網路環境；連線後維持相同網路，不要同時切換無線網路。
3. 確認檢測網域符合預期規則。如果該網域設定為直接連線，檢測結果沒有改變，並不能說明國際網站也使用直接連線。
4. 重新送出請求，並比對用戶端記錄。必要時重新啟動瀏覽器，避免既有連線繼續沿用先前建立的路徑。
5. 情況允許時，可使用另一項獨立檢測交叉比對，並分別留意 IPv4 與 IPv6 的結果。

如果 IPv4 已變更，但 IPv6 仍顯示本地網路位址，表示至少這部分檢測流量可能未依預期被接管。先檢查用戶端的 IPv6 支援、系統路由及繞過設定，再決定是否調整；不要把停用 IPv6 當成通用解法。在雙堆疊網路中，不同應用可能選用不同的 IP 位址類型。

DNS 洩漏：先確認解析策略，再檢視檢測結果

DNS 會將網域名稱解析為 IP 位址，之後應用才會連線至目標伺服器。解析請求與網頁資料可能走不同路徑，因此網頁出口符合預期，不代表 DNS 解析也符合預期。是否屬於 DNS 洩漏，應配合策略判斷：原本應透過代理或指定解析器處理的網域，卻交由非預期的解析服務處理，才是需要追查的異常。

DNS 檢測通常會使用專用測試網域，觀察哪些遞迴解析器前來查詢。頁面顯示的地區與電信業者資訊僅供參考，無法呈現裝置到解析器之間的完整路徑。公用解析服務可能採用分散式出口；僅憑「解析器所在地區與線路地區不同」，不能判定發生洩漏。

依解析來源逐一排查

• 用戶端 DNS：檢查是否啟用內建解析、遠端解析或網域分流。代理網域與直接連線網域可能採用不同的解析策略。
• 瀏覽器安全 DNS：瀏覽器可能透過加密 DNS 自行解析。流量是否經過代理，仍取決於瀏覽器的代理行為與用戶端規則，需搭配連線記錄判斷。
• 系統與應用程式快取：切換線路後，先前的解析結果可能仍然有效。請重新執行檢測；必要時依照系統文件清除快取，不要只憑舊頁面下結論。
• 應用程式內建解析：部分應用會直接連線至自有解析服務。瀏覽器的檢測結果不能代表這些應用的情況。

如果用戶端採用 Fake-IP，系統或應用看到的位址可能是用戶端用來對應網域的合成位址，而非目標網站的實際位址。這是接管解析的一種機制，本身不能作為洩漏證據。更有效的做法是確認網域所符合的規則、解析請求的去向，以及最後是否成功連線。

個別應用檢查：瀏覽器、終端與桌面軟體

瀏覽器可以正常連線、終端卻失敗時，應先檢查代理的適用範圍，而不是直接更換線路。命令列工具對系統代理的支援各不相同，有些依賴環境變數，有些則需要自行設定。即使終端已設定代理，編輯器中的背景程序也可能在啟動時沿用舊環境；重新開啟終端，不會自動更新已執行程式的設定。

• ✅ 瀏覽器：檢查擴充功能、自訂代理與安全 DNS，重新開啟目標頁面，並確認請求是否出現在用戶端連線記錄中。
• ✅ 終端：查看工具本身的代理設定說明，核對代理位址、通訊協定及本機監聽連接埠，再對相同目標送出請求。
• ✅ 編輯器與桌面軟體：檢查應用程式內的網路設定；調整後完全結束程式並重新啟動，再觀察實際業務請求。
• ✅ 行動裝置：檢查是否啟用依應用程式接管或排除規則，並確認測試的是前景中實際使用的應用程式。
• ❌ 不要把瀏覽器檢測通過寫成所有應用都已通過；也不要因某個應用沒有顯示記錄，就直接認定是線路故障。

在 Windows 與 macOS 上，系統代理和虛擬網卡模式是不同的接管機制，所需的授權也可能不同。在 Linux 上，桌面環境的代理設定不一定會傳遞給命令列程序。行動平台則受作業系統網路延伸功能與用戶端能力限制，實際選項請以用戶端為準。跨平台重現問題時，應維持檢查目標一致，而非只比較設定項目的名稱。

HTTP 代理與 SOCKS 代理在網域由哪一端解析方面也可能有所不同。排查終端時，不要照抄網路上來源不明的連接埠；請查看目前用戶端顯示的本機監聽設定，並確認工具支援該代理類型。如果工具支援遠端解析選項，再依照其文件確認是否啟用。

看似連線成功時常見的異常

規則選擇了直接連線，或訂閱尚未更新

匯入訂閱只是讓用戶端取得線路與設定，不代表目標請求一定會選用其中的代理。請確認目前使用的設定確實是剛匯入的訂閱、策略群組已選取可用線路，以及目標網域是否符合直接連線或排除規則。訂閱連結應視同憑證妥善保管，切勿貼到公開截圖、線上解析工具或公開討論區。

連線記錄中有請求，但服務仍無法使用

這表示排查還要繼續：檢查 DNS 結果、連線錯誤、目標服務狀態、帳號工作階段及地區限制。出口變更不保證平台授權、內容片庫或登入一定正常。也不要為了重現問題而連續更換地區；固定使用同一出口測試，更容易區分網路問題與工作階段風控。

網頁正常，但通話或其他即時功能異常

不同功能可能使用不同傳輸方式，一般網頁請求成功，不能證明 UDP 等流量已正確接管。請先確認用戶端模式是否涵蓋該流量、應用程式是否列於排除項目，再查看相關連線記錄。Shadowsocks、VMess、Trojan、VLESS、Hysteria2、TUIC 等協定名稱不能取代實際檢測；需一併確認協定支援、用戶端實作與系統接管方式。

IEPL 專線、中轉與直連主要描述線路路徑與承載方式，並非應用程式接管設定。即使更換線路類型，未使用系統代理的應用仍可能維持原有路徑。因此，先確認流量是否進入用戶端，再檢視線路表現，才能避免把設定問題誤判為線路問題。

整理檢查結果，再決定是否調整設定

重新測試時，每次只變更一個條件，例如只切換接管模式，或只調整目標網域的規則。保留變更前後的出口結果、規則比對與錯誤訊息。如果問題集中在晚間尖峰時段，請記錄實際發生時間與網路環境，並在相同應用、相同目標下重新測試；沒有觀察記錄時，不應直接歸因於網路壅塞。

聯絡客服時，提供作業系統、用戶端名稱、連線模式、所選線路、目標網域及錯誤訊息，即可作為有效的排查起點。分享截圖前，請遮蔽不希望公開的公網 IP 部分、訂閱連結、存取權杖與帳號資訊。用戶端連線記錄是本機排查資料，不等同於服務端的日誌政策說明。