VPN 連線後，並不代表所有網路要求都一定經過同一條加密通道。最常見的例外是 DNS 查詢仍由原本的路由器或電信商解析，導致瀏覽過的網域名稱暴露給第三方；另一個容易忽略的來源是瀏覽器 WebRTC，它可能在建立即時通訊連線時取得本機或區域網路資訊。這些情況通常不等於帳號密碼已經外洩，但會讓「VPN 已連線」和「所有網路資訊都被隱藏」之間出現落差。

本文會先說明 DNS 洩漏和 WebRTC 暴露的差異，再提供不依賴特定網站的檢查方法、Windows、macOS、Android、iOS 與 Linux 的設定方向，以及使用 Clash Verge、sing-box 或 Shadowrocket 時應留意的選項。檢查時不要只看 VPN 圖示，而要從 DNS 伺服器、實際出口、瀏覽器行為和應用程式分流四個層面交叉確認。

DNS 洩漏是什麼，為什麼 VPN 連線後仍會發生

DNS 的作用，是把容易記憶的網域名稱轉換成 IP 位址。當你開啟網站、登入服務或使用手機應用程式時，裝置往往會先提出 DNS 查詢，再依照回覆連線。如果 VPN 只轉送網頁流量，卻沒有接管 DNS 查詢，查詢可能仍然送往家庭路由器、公司網路、公共 WiFi 的 DNS 服務或系統預設的電信商解析器。此時，實際頁面內容可能已經走過 VPN，但查詢紀錄仍可能透露你嘗試存取哪些網域。

DNS 洩漏和 IP 洩漏不是同一件事。IP 洩漏是外部服務仍看見原本的公網 IP；DNS 洩漏則是解析請求沒有依預期經過 VPN 通道。兩者可能同時發生，也可能只發生其中一種。例如，外部網站看到的是 VPN 出口，但 DNS 查詢卻由本地網路處理，這就是常見的部分洩漏。

DNS

檢查網域解析去向

IP

確認對外出口位置

WebRTC

檢查瀏覽器連線資訊

規則

確認分流是否繞過通道

造成洩漏的原因不只有客戶端故障。常見情況包括客戶端啟用分流但沒有設定遠端 DNS、作業系統保留了多個網路介面、IPv6 沒有被 VPN 接管、瀏覽器或應用程式使用自己的加密 DNS，以及斷線保護沒有啟用。部分客戶端還會把 DNS 分成「代理解析」「直連解析」和「本機解析」，名稱相似但行為不同，不能只看選項是否出現 DNS 字樣。

開始修復前：先確認檢查條件

檢查前先關閉不必要的代理程式與瀏覽器擴充功能，保留一個正在使用的 VPN 客戶端。若同時啟用兩個 VPN、系統代理、瀏覽器代理和安全軟體的自訂 DNS，結果可能受到多重規則影響，難以判斷究竟是哪一層改變了查詢路徑。檢查時也應記錄目前使用的網路類型，例如家用 WiFi、公司網路或行動數據，因為不同環境可能透過 DHCP 下發不同的 DNS 設定。

接著確認 VPN 客戶端已經完成連線，而不是隻顯示「啟動中」或已選取某個節點。查看連線記錄，留意是否出現 DNS、TUN、路由、IPv6、UDP 或隧道建立失敗等訊息。若使用訂閱連結匯入節點，請先更新訂閱並確認實際選取的節點與協議。Shadowsocks、VMess、Trojan、Hysteria2、WireGuard 等協議處理流量的方式不同，但 DNS 是否走隧道，仍主要取決於客戶端的路由與 DNS 實作。

DNS 洩漏檢查：從瀏覽器到系統指令

最簡單的方式，是先連線 VPN，再使用可信的 DNS 洩漏檢查頁面。標準檢查通常會列出多個 DNS 伺服器的 IP、所屬網路或大致位置。重點不是追求某個特定國家名稱，而是觀察結果是否仍包含家用路由器、公司網路或電信商的 DNS。若結果同時出現 VPN 服務提供的解析器與本地網路解析器，便需要進一步檢查分流和 IPv6。

瀏覽器測試只能反映瀏覽器可以觀察到的狀態，不能完全代表桌面應用程式、遊戲或手機 App 的行為。Windows 可以使用 nslookup 查詢網域並查看目前使用的 DNS 伺服器；macOS 和 Linux 可透過系統網路工具、NetworkManager 或 systemd-resolved 的狀態資訊核對解析器。不同作業系統版本的指令輸出會有差異，不必逐字比對範例，應以「查詢從哪裡送出、由誰回覆」為判斷核心。

檢查層級 要觀察的內容 可能代表的問題
外部 DNS 檢查 解析器是否包含本地電信商或路由器 DNS 沒有完全進入 VPN 或存在分流例外
系統 DNS 目前網路介面、解析器與 IPv6 狀態 作業系統仍優先使用未受保護的介面
客戶端記錄 DNS 轉送、TUN、路由和錯誤訊息 客戶端設定未套用或通道建立不完整
瀏覽器 WebRTC 是否顯示本機或非預期網路位址 瀏覽器即時通訊功能繞過一般代理行為

如果檢查結果只顯示 VPN 服務或你主動指定的安全 DNS，通常表示基本解析路徑符合預期；但仍應確認斷線時是否會停止外部流量。若結果顯示多個來源，先不要立即更換節點。可以依序停用 IPv6、關閉瀏覽器安全 DNS 進行對照，再查看客戶端是否啟用「遠端 DNS」「DNS 代理」「Fake-IP」或「DNS 劫持」等功能。這些功能名稱和支援程度會因客戶端而異。

檢查結論： DNS 洩漏的判斷重點是解析器來源與請求路徑，而不是單看外部網站顯示的出口 IP。

動手修復：逐層調整 DNS、IPv6 與分流

修復時建議一次只改一個設定，然後重新連線並再次檢查。若一次同時修改系統 DNS、瀏覽器 DNS、路由器和客戶端規則，問題即使暫時消失，也很難知道真正有效的變更。完成一項調整後，應先清除本機 DNS 快取，再關閉並重新開啟 VPN 連線。

先處理 VPN 客戶端

在原生客戶端中，查看網路、DNS、路由或進階連線設定，優先選擇由 VPN 通道處理 DNS 的模式。如果有「防止 DNS 洩漏」「DNS 透過代理」「全域 TUN」或「阻止 VPN 斷線時流量」等選項，先理解其說明再啟用。部分應用程式的「全域模式」只代表所有網域使用代理，並不一定代表 DNS 已經透過隧道，因此仍需要外部檢查。

若使用 Clash Verge，應檢查 DNS 模式、TUN 是否啟用，以及規則是否把 DNS 請求送往代理。Fake-IP 和 Redir-Host 會影響網域解析方式，切換後可能需要重新啟動核心或重新載入設定。若使用 sing-box，則要核對 DNS server、route rule、auto route、strict route 和 DNS detour 等設定是否互相配合。不要直接複製不明來源的完整設定檔；同一個欄位在不同版本中的語意可能不同。

Shadowrocket 等行動客戶端通常會將 DNS、代理模式和按需連線分開設定。iOS 可能限制部分低層網路操作，因此應確認系統 VPN 權限已授予，並在 WiFi 與行動數據切換後重新測試。Android 若使用私人 DNS、應用程式分流或電池最佳化，也可能改變結果；請確認 VPN 應用程式沒有被系統背景限制。

再檢查作業系統與瀏覽器

Windows、macOS、Linux、Android 和 iOS 都可能同時存在多個網路介面。包括實體 WiFi、有線網路、虛擬網卡、行動數據與 IPv6。若 VPN 只接管 IPv4，而瀏覽器或應用程式優先使用 IPv6，外部查詢就可能從另一條路徑離開。可以在客戶端文件允許的前提下測試停用 IPv6，或啟用支援 IPv6 的隧道；不要只在系統介面中更換 DNS，因為這不一定能阻止其他介面重新接管查詢。

瀏覽器的安全 DNS 通常會把 DNS 查詢包在 HTTPS 或 TLS 中，這能減少本地網路直接查看查詢內容，但不等於一定會使用 VPN。它可能繞過客戶端指定的 DNS 策略，也可能因瀏覽器政策、登入狀態或網路封鎖而改用其他方式。若你的目標是讓 VPN 客戶端統一管理 DNS，應確認瀏覽器設定沒有與客戶端策略衝突。

WebRTC 是瀏覽器支援即時音訊、視訊和資料通訊的技術。它為了建立點對點連線，可能透過 ICE 機制收集候選位址。現代瀏覽器通常會限制暴露程度，但不同版本、權限和網站設定仍可能造成差異。對不需要視訊通話或瀏覽器即時通訊功能的使用者，可以在瀏覽器隱私設定中限制 WebRTC，或使用具備 WebRTC 防護功能的瀏覽器擴充功能。使用前要確認擴充功能來源可信，並測試視訊會議、語音通話和需要 WebRTC 的網站是否仍正常。

不同平台的排錯重點

Windows 的問題常與多個網路介面、系統代理和 DNS 快取有關。切換客戶端後，舊的虛擬網卡或代理設定可能仍然存在。排錯時先確認目前啟用的介面，再檢查系統代理是否指向仍在運作的本機端口。若瀏覽器正常但其他應用程式不通，可能是該應用程式不遵循系統代理，需要 TUN 或系統級 VPN 模式。

macOS 常見差異是 WiFi、有線網路、VPN 和其他虛擬介面同時存在。系統設定中的 DNS 順序不一定等於所有應用程式實際使用的順序，因此不能只看圖形介面。若使用原生客戶端，應優先查看其 VPN 連線記錄；若使用 sing-box 或其他 TUN 客戶端，還要核對系統是否允許擴充功能建立路由。

Android 需要特別留意「私人 DNS」、始終開啟 VPN、封鎖未使用 VPN 的連線，以及應用程式分流。不同手機品牌的省電策略也可能在螢幕關閉後停止 VPN，造成短暫直連。iOS 的限制較多，通常應確認 VPN 設定權限、按需連線規則和行動數據權限，並在系統更新後重新檢視客戶端設定。

Linux 的 DNS 行為可能由 systemd-resolved、NetworkManager、桌面環境或發行版自己的網路服務管理。若使用 TUN 模式，請確認路由表和 DNS 服務的接管狀態；若使用瀏覽器代理，則不能假設終端機、更新工具和其他應用程式也會沿用相同代理。伺服器或工作站若需要穩定連線，建議先保存原本的網路設定，再逐步修改。

平台 優先檢查 常見誤區
Windows 虛擬網卡、系統代理、DNS 快取 只設定瀏覽器代理，其他應用程式仍直連
macOS VPN 權限、介面順序、TUN 路由 只查看系統 DNS，忽略客戶端內部策略
Android 私人 DNS、始終開啟 VPN、省電限制 螢幕關閉後 VPN 被系統暫停
iOS VPN 設定授權、按需連線、行動數據 網路切換後仍沿用舊的檢查結果
Linux systemd-resolved、NetworkManager、路由表 終端機和圖形介面使用不同解析器

公共 WiFi、付款與登入時的安全習慣

VPN 可以降低本地網路直接觀察流量內容的機會，但它不是帳戶安全的全部。公共 WiFi 可能透過假冒名稱、強制入口頁或惡意 DNS 引導使用者前往仿冒網站。連線後仍要核對網址、憑證警告和網站名稱，不要因為 VPN 圖示存在就忽略瀏覽器警示。付款與登入時，建議使用網站或 App 的官方入口，避免從不明訊息中的短網址進入。

對重要帳號，啟用多因素驗證、使用獨立且不重複的密碼，並檢查登入通知。VPN 服務提供者可能看見部分連線中繼資料，因此應選擇有清楚隱私政策、支援必要平台且能正常更新的服務。若使用共享電腦或公共裝置，完成操作後要登出帳號，不要把訂閱連結、設定檔或客戶端日誌留在本機。

日常維護也很重要。客戶端、作業系統和瀏覽器更新後，DNS、WebRTC 或權限行為可能改變。當你更換節點、更新訂閱、切換路由模式或安裝新瀏覽器擴充功能，應重新做一次基本檢查。若只有某個網站出現問題，不要先判定是 DNS 洩漏，也可能是網站驗證、分流規則、IPv6 相容性或該節點暫時不可用。

使用結論： VPN 是降低網路暴露面的工具，不是取代 HTTPS、帳戶防護、軟體更新和使用者判斷的萬用方案。

常見問題

VPN 顯示已連線，是否代表一定沒有 DNS 洩漏？

不代表。VPN 狀態通常只表示隧道或本機 VPN 介面已建立，並不能證明所有 DNS 查詢、IPv6 流量和瀏覽器 WebRTC 請求都經過同一條路徑。應在連線後檢查外部 DNS 結果，再依客戶端記錄和系統設定確認。

把 DNS 改成公共 DNS，可以修復洩漏嗎？

不一定。改用公共 DNS 可能改變解析器，但如果請求仍從未受 VPN 保護的介面送出，仍然不是完整解決方案。更重要的是讓 VPN 客戶端正確接管 DNS，並確認分流、IPv6 和瀏覽器設定沒有繞過該策略。

DNS 檢查正常，還需要檢查 WebRTC 嗎？

建議檢查。DNS 和 WebRTC 是不同機制，前者處理網域解析，後者可能在瀏覽器建立即時通訊時收集連線候選位址。DNS 沒有洩漏，不代表 WebRTC 行為一定符合你的隱私需求；若限制 WebRTC，應同時測試視訊會議和語音網站。

客戶端更新或換網路後，為什麼要重新檢查？

因為更新可能改變 DNS 模式、TUN 實作或路由優先順序，而不同 WiFi、行動數據和 IPv6 環境也會提供不同的解析設定。重新檢查能確認目前實際狀態，避免把舊環境的結果誤套用到新環境。