DNS 洩漏和 WebRTC 洩漏經常被放在同一個檢測頁面，但它們不是同一件事。

兩種檢測都可能出現「另一個 IP」，但另一個 IP 不一定就是使用者的真實公網 IP，也不一定代表 VPN 已經失效。

先看結論

立即檢查目前的 IP、WebRTC 與連線協定觀察

本站模型提示（1.6.0）： Caylet 將「資料庫確認」「可用來源未發現」與「沒有資料」分開顯示；後兩者都不代表已證明安全。Caylet 綜合 IP 風險分值只使用 Scamalytics 與 AbuseIPDB 的有效數值，IP2Location 與 Feodo Tracker 結果獨立呈現，IPinfo Lite 僅作 ASN 背景參考。

DNS 是什麼？

DNS 是 Domain Name System，也就是網域名稱系統。

人們習慣輸入：

example.com

但裝置建立網路連線時，需要取得對應的 IP 地址。DNS 負責把網域名稱解析成可用的網路資料，例如：

一個簡化的 DNS 查詢流程是：

瀏覽器或 App
      ↓
作業系統／瀏覽器 DNS 元件
      ↓
Recursive Resolver
      ↓
Root、TLD 與 Authoritative DNS
      ↓
回傳查詢結果

使用者日常最常接觸的是 Recursive Resolver，也就是遞迴解析器。它可能由以下服務提供：

DNS 洩漏究竟是什麼？

「DNS 洩漏」不是 IETF 對單一協定錯誤的正式統一定義，而是隱私和 VPN 測試中常用的描述。

一般是指：

使用者預期 DNS 查詢應經過某個安全、加密或 VPN 路徑，但部分查詢實際由其他 Resolver 或其他網路介面處理。

例如，使用者啟用 VPN 後預期：

DNS 查詢
   ↓
VPN 隧道
   ↓
VPN Resolver

實際卻是：

DNS 查詢
   ↓
本地 ISP Resolver

這時本地 ISP 可能知道使用者查詢了哪些網域，而查詢結果也可能受到本地網路政策影響。

DNS 洩漏和「網站看到真實 IP」不是同一件事

DNS 洩漏測試通常能觀察到：

它不一定能直接看到：

所以較精確的說法是：

DNS 洩漏可能暴露所使用的解析路徑和網路供應商，但不必然直接暴露使用者的原始公網 IP。

DNS 洩漏測試是如何工作的？

一般網頁 JavaScript 沒有一個通用 API 可以直接詢問：

目前系統的 DNS Resolver IP 是多少？

因此，DNS 測試通常使用一組由測試服務控制的唯一網域名稱。

簡化流程如下：

  1. 測試頁生成一個隨機且唯一的子網域。
  2. 瀏覽器請求該網域對應的資源。
  3. 裝置或瀏覽器向 Recursive Resolver 查詢該名稱。
  4. Resolver 再向測試服務控制的 Authoritative DNS 查詢。
  5. Authoritative DNS 記錄前來查詢的 Resolver IP。
  6. 測試頁把觀察到的 Resolver 列出。

例如：

隨機名稱：
a8f31c.example-test.invalid

權威 DNS 觀察到：
203.0.113.53

這個 203.0.113.53 通常是 Resolver 或其出口，不一定是使用者本人的公開 IP。

為什麼一次測試可能看到多個 Resolver？

可能原因包括：

看到多個 Resolver 不等於一定洩漏。

什麼是 Recursive Resolver？

Recursive Resolver 代表用戶完成後續 DNS 查詢。

它會：

  1. 接收客戶端問題。
  2. 查詢 DNS 階層或使用快取。
  3. 取得最終答案。
  4. 把答案回傳給客戶端。

外部權威 DNS 通常看到的是 Resolver 來查詢，而不是每一台終端裝置直接查詢。

因此，假設：

公開 IP：198.51.100.20
Resolver IP：203.0.113.53

這兩個 IP 不同是正常的。真正需要判斷的是 Resolver 是否符合預期，例如：

為什麼 DNS Resolver 和公開 IP 的國家不同？

1. 公共 DNS 使用 Anycast

大型 DNS 服務常使用 Anycast。

同一個 Resolver IP 可以從多個國家或城市宣告。使用者通常會被路由到較合適的節點，但 GeoIP 資料庫仍可能把該 IP 固定顯示在另一個地區。

所以：

公開 IP：日本
Resolver GeoIP：美國

不一定表示查詢真的跨越太平洋，也不一定是 DNS 洩漏。

2. 瀏覽器啟用 DoH

瀏覽器可能繞過作業系統設定，直接向所選的 DoH Resolver 發送加密 DNS 請求。

這時：

Mozilla 的 Firefox 提供不同 DoH 保護層級，並可能依瀏覽器設定和網路訊號決定使用方式。

3. 公司或學校統一解析

企業可能把 DNS 送往：

員工在香港，Resolver 顯示新加坡或美國，可以是正常政策。

4. 行動網路或漫遊

手機連接當地基地台，但 DNS 和數據流量可能由漫遊核心網路在另一個國家處理。

5. GeoIP 判定錯誤

Resolver IP 的城市或國家也可能因資料庫未更新、Anycast 或網段註冊資訊而顯示錯誤。

了解 IP 位置為什麼可能顯示其他城市或國家

DoH 和 DoT 是什麼？

DNS over HTTPS

DNS over HTTPS，簡稱 DoH，使用 HTTPS 傳送 DNS 查詢。RFC 8484 定義了這種方法。

DoH 的主要作用是：

DNS over TLS

DNS over TLS，簡稱 DoT，使用 TLS 保護 DNS 傳輸。RFC 7858 定義了相關協定。

DoT 和 DoH 的共同點是：

加密 DNS 不等於完全匿名

DoH 或 DoT 不能保證：

它主要解決的是傳輸路徑上的機密性和完整性問題，而不是讓 DNS 從所有參與方完全隱形。

為什麼使用 VPN 後仍可能出現 DNS 洩漏？

1. VPN 沒有接管系統 DNS

VPN 建立了流量隧道，但作業系統仍使用原本的 ISP Resolver。

2. 瀏覽器 DoH 獨立運作

瀏覽器可能直接連接自訂 DoH Resolver。這不一定是不安全，但可能不符合使用者「所有 DNS 都走 VPN Resolver」的預期。

3. Split Tunneling

分流設定會讓部分 App、目的地或協定不經過 VPN。

DNS 也可能依設定分流：

4. 多張網卡

裝置可能同時啟用：

不同介面可能各有 DNS 設定。

5. IPv4 和 IPv6 路徑不同

VPN 可能只處理 IPv4，但 DNS Resolver 或目的地可以透過 IPv6 連線。

6. VPN 斷線或切換期間

VPN 重連時，系統可能短暫回到原有 DNS。

7. 作業系統的智慧多宿主解析

部分系統可能同時向多個網路介面查詢，以提高解析速度或可靠性。這可能造成非預期的 Resolver 被觀察到。

EDNS Client Subnet 是否會暴露使用者 IP？

EDNS Client Subnet，簡稱 ECS，是 RFC 7871 定義的一項 DNS 擴充。

Resolver 可以在向權威 DNS 查詢時，附帶一段經截短的客戶端網路前綴，協助 CDN 回傳更接近使用者的結果。

例如，它可能傳送：

客戶端 IPv4 前綴：198.51.100.0/24

而不是完整單一地址：

198.51.100.37

ECS 可能透露什麼？

它可能讓權威 DNS 或 CDN 了解：

ECS 不一定會被使用

是否傳送、傳送多長前綴，取決於：

所以，DNS 洩漏測試看到 Resolver IP，不代表一定同時看到 ECS；即使存在 ECS，也不應直接說成完整真實 IP。

WebRTC 是什麼？

WebRTC 是瀏覽器內建的即時通訊技術，常用於：

為了讓兩端在 NAT、防火牆和不同網路環境下建立連線，WebRTC 使用 ICE，也就是 Interactive Connectivity Establishment。

ICE 會收集多種可能的連線地址，稱為 Candidates。

WebRTC 的 ICE Candidate 有哪些類型？

常見候選類型包括：

Candidate 類型 簡寫 基本含義
Host host 裝置網路介面可使用的本地候選
Server-reflexive srflx STUN 伺服器觀察到的 NAT 外部映射
Peer-reflexive prflx 連線檢查過程中發現的映射
Relay relay 經 TURN 中繼伺服器提供的候選

RFC 8445 定義 ICE 的核心機制，RFC 8489 定義 STUN。

Host Candidate

Host Candidate 可能是：

現代瀏覽器可能限制直接暴露本地介面地址，RFC 8828 也專門規定 WebRTC 的 IP 地址處理要求。

Server-reflexive Candidate

STUN 伺服器可以告訴瀏覽器：

我從外部看到你的來源映射是這個 IP 和 Port。

在家庭 NAT 環境中，這通常是路由器或網路出口的公網映射。

Relay Candidate

當直接連線不可行或隱私政策要求使用中繼時，可以透過 TURN Server 中轉。

此時對端主要透過 Relay Candidate 連線，而不是直接使用本地或 NAT 映射地址。

什麼是 WebRTC 洩漏？

一般語境中的 WebRTC 洩漏是指：

網站透過 WebRTC ICE 候選觀察到，除了正常 HTTP 出口之外的額外網路地址，尤其是未經預期 VPN 路徑處理的公網地址。

例如：

HTTP 公開 IP：
203.0.113.20（VPN，美國）

WebRTC Server-reflexive IP：
198.51.100.37（本地 ISP，香港）

這種結果表示網站可能觀察到另一條公網路徑，值得檢查。

但下面這種情況不同：

HTTP 公開 IP：
203.0.113.20

WebRTC Host Candidate：
192.168.1.12

192.168.1.12 是私有 IPv4，不能在公共網際網路路由。它可能透露裝置位於一個常見家庭 LAN，但不是家庭寬頻的公網出口。

私有 IP、共享位址和公網 IP 要如何區分？

常見 IPv4 私有範圍

10.0.0.0/8
172.16.0.0/12
192.168.0.0/16

電信商共享位址空間

100.64.0.0/10

它通常用於 CGNAT 內部，不是一般公共路由位址。

本機迴圈

127.0.0.0/8

IPv6 本地與特殊位址

IPv6 也有：

因此，WebRTC 顯示一個 IPv6 時，必須先判斷它是否為全球可路由地址，不能只因格式看起來陌生就當成洩漏。

了解公網 IP、私有 IP、IPv4 與 IPv6

為什麼 WebRTC 可能顯示另一個公網 IP？

1. VPN 沒有處理 IPv6

這是常見情況之一：

IPv4：經 VPN
IPv6：直接經 ISP

HTTP 檢測若只顯示 IPv4，使用者可能以為所有流量都在 VPN 中；WebRTC 或支援 IPv6 的測試則可能看到原生 IPv6。

2. 多張網路介面

裝置同時連接 Wi-Fi 和乙太網路，或存在虛擬網卡。

WebRTC 可能收集多條可用路徑。

3. VPN Split Tunneling

VPN 政策可能讓即時通訊流量、UDP 或某些 App 走直接路徑。

4. 瀏覽器與 VPN 的整合差異

不同瀏覽器、作業系統和 VPN Client 對 WebRTC、UDP、IPv6 和路由表的處理不同。

5. 企業或遠端桌面環境

瀏覽器運行在：

可能產生不同的候選地址。

6. 測試工具把地址分類錯誤

測試頁可能：

所以測試結果必須顯示 Candidate Type 和地址類型。

WebRTC 能否在沒有攝影機權限時工作？

許多 WebRTC 網路連線和 ICE 收集並不等同於存取攝影機或麥克風。

瀏覽器可以建立 RTCPeerConnection 並收集部分網路候選，而不一定先取得影音裝置權限。

但現代瀏覽器會依：

限制或調整暴露的地址。

因此，不能依賴十年前的結論，認定所有瀏覽器都會把所有本地與公網地址完整交給任意網站。

現代瀏覽器如何降低 WebRTC IP 暴露？

RFC 8828 討論了 WebRTC 建立連線所需的地址可用性與隱私風險。

瀏覽器可能採用：

所以：

WebRTC 具備觀察額外網路資訊的能力，不代表每個瀏覽器、每個網站都能看到相同內容。

DNS 洩漏和 WebRTC 洩漏有什麼核心差別？

項目 DNS 洩漏 WebRTC 洩漏
主要觀察 DNS 查詢由誰解析 ICE 收集到哪些候選地址
常見可見對象 Recursive Resolver IP Host、Server-reflexive、Relay 等地址
是否一定看到原始公網 IP 不一定 額外 srflx 或全球地址時有可能
是否依賴 WebRTC 否 是
DoH／DoT 是否相關 直接相關 通常不是核心
IPv6 是否可能造成 可以 可以
常見誤報 Anycast、公共 DNS、企業 Resolver 私有 IP、mDNS、地址類型誤判
正確判讀重點 Resolver 是否符合預期 額外地址是否為可路由公網地址

DNS 和 WebRTC 測試常見的四種狀態

任何提供這類測試的工具都不應只顯示「安全／洩漏」，而應區分：

1. 未觀察到額外資訊

例如：

2. 觀察到差異，但存在合理解釋

例如：

3. 觀察到高價值不一致

例如：

4. 測試失敗或資料不足

例如：

第四種不能顯示為「沒有洩漏」。

如何判讀一個 DNS 測試結果？

第一步：確認測試看到的是 Resolver

不要把 Resolver IP 直接當成使用者真實 IP。

第二步：查看 Resolver 的 ASN 和服務名稱

判斷它是：

第三步：比較預期路徑

使用者是否預期：

沒有「唯一正確 Resolver」，只有是否符合當前設定。

第四步：考慮 Anycast 和 GeoIP

不要只因城市或國家不同就下結論。

第五步：重複測試並排除快取

唯一隨機子網域可以降低快取干擾，但不同 App 和系統服務仍可能有各自 DNS 路徑。

如何判讀一個 WebRTC 測試結果？

第一步：查看 Candidate Type

至少區分：

第二步：分類地址

判斷它是：

第三步：與 HTTP 公開 IP 比較

如果完全相同，通常表示 WebRTC 只觀察到同一出口。

如果不同，再比較：

第四步：確認測試是否完整

STUN 被封鎖時，可能無法取得 srflx。

沒有結果不等於沒有風險。

第五步：避免把本地 IP 寫成「真實 IP 已暴露」

應明確標示：

觀察到區域網路私有位址，該地址不能直接在公共網際網路路由。

使用 VPN 時出現另一個 IP，應該先檢查什麼？

正常的診斷順序是：

  1. 確認另一個地址是否為公網地址。
  2. 確認它是 IPv4 還是 IPv6。
  3. 查看 Candidate Type。
  4. 比較另一個地址的 ASN 和 ISP。
  5. 確認 VPN 是否支援 IPv6。
  6. 檢查是否啟用 Split Tunneling。
  7. 確認瀏覽器 DoH 和系統 DNS 設定。
  8. 比較 Wi-Fi、乙太網路和其他介面。
  9. 重新連線後再次測試。
  10. 查看測試是否明確成功，而不是超時或被阻擋。

這是排查設定一致性的正常方法，不是規避平台安全檢測。

關閉 WebRTC 是不是最好的做法？

不一定。

完全停用 WebRTC 可能影響：

對一般使用者，應先確認：

沒有必要因檢測頁顯示 192.168.1.5，就認定必須停用整個 WebRTC。

DoH 是否應該關閉，讓 DNS 跟隨 VPN？

這取決於實際需求和 VPN 設計。

可能適合保留 DoH 的情況

可能需要調整的情況

重點不是「DoH 一定好」或「DoH 一定是洩漏」，而是：

實際 DNS 路徑是否符合使用者與網路管理者的安全預期。

DNS 或 WebRTC 洩漏會造成什麼影響？

可能影響包括：

隱私

本地 ISP 或其他 Resolver 可能看見 DNS 查詢；網站可能觀察到額外的網路地址。

地區判斷

DNS 或額外 IP 的國家不同，可能影響 CDN、內容和風控判斷。

企業政策

DNS 沒有經過公司安全 Resolver，可能繞過惡意網域過濾或內部網域解析。

VPN 完整性

額外的原生 IPv6 或 srflx 地址可能表示部分流量未走預期隧道。

誤報

公共 DNS、企業 Resolver、Anycast 和私有地址可能被低品質測試頁錯誤標成嚴重洩漏。

DNS 洩漏是否等於 DNS 查詢內容被網站看見？

不完全是。

目標網站通常知道使用者正在訪問自己，因為使用者已經向它建立連線。

DNS 洩漏的主要額外隱私問題是：

但使用 HTTPS 時，DNS 本身通常不包含完整 URL 路徑，例如：

example.com/private/page?id=123

DNS 一般解析的是網域名稱，而不是完整網頁路徑。

DNS 與 WebRTC 工具應如何顯示結果？

目前 Caylet IP 不執行 DNS 洩漏檢測，因此不會顯示 Resolver 或對 DNS 路徑作出結論；網站目前只提供有限的 WebRTC 額外公網 IP 觀察。以下 DNS 欄位是對一般檢測工具的設計建議，不代表本站現有功能。

DNS 區塊

建議顯示：

建議文案示例：

觀察到公共 DoH Resolver。Resolver 的 GeoIP 國家與目前公開 IP 不同，但公共 DNS 可能使用 Anycast，因此不能只靠國家差異判定 DNS 洩漏。

WebRTC 區塊

建議顯示：

建議文案示例：

觀察到一個私有 IPv4 Host Candidate。該地址不能在公共網際網路路由，不代表家庭寬頻公網 IP 已暴露。

或者：

觀察到另一個全球可路由 IPv6，ASN 屬於本地 ISP，與目前 VPN IPv4 出口不同。這可能表示 IPv6 未經相同隧道路徑處理，建議檢查 VPN 的 IPv6 支援。

三態和測試狀態

不要只使用：

至少應包括：

使用 Caylet 檢查目前的 IP、WebRTC 與連線協定觀察

常見誤解

誤解一：DNS 測試顯示另一個 IP，就是我的真實 IP

錯誤。它通常是 Recursive Resolver 的 IP。

誤解二：Resolver 在另一個國家，就一定發生 DNS 洩漏

錯誤。Anycast、公共 DNS、DoH、企業網路和 GeoIP 誤差都可能造成差異。

誤解三：WebRTC 顯示 192.168.x.x，代表網站知道我的住址

錯誤。這是私有區域網路位址，不能直接對應門牌地址。

誤解四：WebRTC 沒有返回額外 IP，就證明 VPN 完全安全

錯誤。測試可能被瀏覽器限制、STUN 失敗或只覆蓋部分協定。

誤解五：DoH 一定會繞過 VPN

不一定。DoH 連線本身也可能經 VPN，取決於路由和設定。

誤解六：DoH 就能讓 DNS 完全匿名

錯誤。DoH Resolver 仍需要處理查詢，權威 DNS 也會收到 Resolver 的後續請求。

誤解七：停用 WebRTC 是唯一解決方案

錯誤。應先判斷地址類型並修正實際的 IPv6、DNS 或分流問題。

常見問題

DNS 洩漏是否代表網站看到了我的真實 IP？

不一定。DNS 洩漏通常表示 DNS 查詢由預期路徑之外的 Resolver 處理。網站或測試服務可能看到 Resolver 的 IP，而不是使用者原本的公網 IP。若 Resolver 與公開出口不一致，仍需結合 ASN、國家、DoH／DoT、Anycast 和企業網路情境判讀。

WebRTC 顯示 192.168.x.x 是否代表真實 IP 洩漏？

通常不是。192.168.x.x 屬於私有 IPv4，只在區域網路中使用，不能直接在公共網際網路路由。它可能透露本地網路結構，但不等於公開網站已取得家庭寬頻的公網 IP。

WebRTC 顯示另一個公網 IP 是否一定是 VPN 洩漏？

不一定，但值得檢查。另一個公網 IP 可能來自未經 VPN 處理的 IPv6、第二張網卡、分流設定、企業網路或真正的 WebRTC 路徑暴露。應比較地址是否為公網、ASN 和國家是否不同，以及候選類型和測試是否成功。

DNS Resolver 顯示另一個國家是否一定是 DNS 洩漏？

不是。公共 DNS 和企業 Resolver 可能使用 Anycast，GeoIP 也可能定位到營運節點而非實際處理位置。瀏覽器 DoH、公司安全網路和漫遊出口也可能造成不同國家。國家不同是需要解釋的訊號，不是單獨的定論。

使用 DoH 或 DoT 是否就完全沒有 DNS 洩漏？

DoH 和 DoT 可以加密客戶端到所選 Resolver 的 DNS 傳輸，但不保證查詢一定經過 VPN，也不隱藏 Resolver 向權威 DNS 發出的後續查詢。是否符合預期仍取決於瀏覽器、作業系統、VPN 和網路設定。

關閉 WebRTC 是否是解決問題的唯一方法？

不是。WebRTC 是視訊、語音和即時通訊的重要網頁技術，現代瀏覽器也具備 IP 隱私處理。正常使用者應先確認是否真的暴露額外公網 IP，再檢查 VPN 的 IPv4／IPv6、DNS 和分流支援，而不是因看到本地位址就直接停用所有 WebRTC 功能。

總結

DNS 洩漏和 WebRTC 洩漏都與「實際網路路徑是否符合預期」有關，但觀察對象不同。

DNS 洩漏主要關注：

WebRTC 洩漏主要關注：

正確判讀需要區分：

最重要的原則是：

看到另一個 IP，不要立刻下結論；先確認它是誰的 IP、屬於哪種地址、從哪個協定和測試步驟被觀察到。

主要資料來源

  1. RFC Editor, RFC 1034: Domain Names — Concepts and Facilities
  2. RFC Editor, RFC 1035: Domain Names — Implementation and Specification
  3. RFC Editor, RFC 7858: Specification for DNS over Transport Layer Security
  4. RFC Editor, RFC 8484: DNS Queries over HTTPS
  5. RFC Editor, RFC 7871: Client Subnet in DNS Queries
  6. RFC Editor, RFC 8445: Interactive Connectivity Establishment
  7. RFC Editor, RFC 8489: Session Traversal Utilities for NAT
  8. RFC Editor, RFC 8828: WebRTC IP Address Handling Requirements
  9. RFC Editor, RFC 8826: Security Considerations for WebRTC
  10. MDN Web Docs, RTCIceCandidate
  11. MDN Web Docs, RTCIceCandidate: type property
  12. MDN Web Docs, RTCIceCandidate: address property
  13. MDN Web Docs, RTCIceCandidate: relatedAddress property
  14. Mozilla Support, Configure DNS over HTTPS protection levels in Firefox

本文提供一般網路技術、隱私與安全診斷資訊，不提供規避網站安全或平台風控的方法。DNS、WebRTC、IPv4／IPv6 和 VPN 行為會因瀏覽器、作業系統、供應商與時間而變化，任何單次測試都不應視為絕對結論。