Clash 實際 IP 洩露檢查：DNS、WebRTC、IPv6

本文目錄

先回答「有沒有洩露」：看公用網路出口，不看一個綠色提示

Clash 不會自動保證所有應用、DNS、WebRTC 和 IPv6 都經過同一出口。要判斷是否洩露，需要分別記錄開啟代理前後的公用網路 IPv4、IPv6、DNS 伺服器和 WebRTC 候選。

看到 192.168.x.x 這類私有位址，並不能說明實際公用網路 IP 已經暴露。真正要處理的是代理開啟後仍出現本機營運商的公用網路位址。

不要混為一談

檢測項	它回答的問題	異常才是什麼
公用網路 IPv4	網站看到哪個出口	開啟代理後仍是明確的本機營運商出口
公用網路 IPv6	IPv6 是否走同一接管方式	IPv4 走節點、IPv6 仍從本機直出
DNS 伺服器	查詢可能由誰完成	與設定不符並導致網域繞開預期規則
WebRTC 候選位址	瀏覽器為實時通訊發現了什麼位址	出現不符合預期的實際公用網路出口；192.168/10.x 本身不是公用網路洩露

檢測頁本身不是結論，前後兩次結果才有意義。使用同一個瀏覽器、同一個網路和同一檢測頁，只改變 Clash 的接管方式，並把四項結果並排儲存。

可比較的測試

Chrome 在「設定 → 隱私和安全 → 安全性」裡可以單獨啟用安全 DNS；Firefox 的 DNS over HTTPS 位於隱私設定。瀏覽器啟用獨立 DoH 後，查詢可能不再經過系統 DNS，Clash 的系統代理又未必接管這條解析請求。

短時間關閉瀏覽器 DoH，完全退出並重開瀏覽器。如果 DNS 結果回到 Clash 預期入口，原因已經確定；隨後可以選擇繼續由瀏覽器處理，或者統一交給 Mihomo，重點是不要在三處同時覆蓋。

WebRTC 為語音、影片和點對點通訊收集候選位址。現代瀏覽器可能把本機位址隱藏成 mDNS 名稱，也可能顯示私有網段；這些資訊能說明區域網路環境，卻不能從網際網路直接路由到你的電腦。

真正需要處理的是代理開啟後仍出現本機營運商的公用網路 IPv4 或 IPv6。完全停用 WebRTC 會讓網頁會議和螢幕共享失效，優先使用瀏覽器的位址限制選項，並在 Zoom、Meet 或 Slack Huddle 裡重新驗證功能。

系統代理通常處理應用明確交給代理的請求，不保證所有 IPv6 連線都被接管。TUN 是否處理 IPv6 又取決於用戶端版本、路由和設定。先確認業務是否需要 IPv6；不能接管時，臨時關閉 IPv6 做對照比在規則末尾盲目 REJECT 更能說明原因。

dns:
  enable: true
  ipv6: false
  enhanced-mode: fake-ip

# 若明确需要 IPv6，应改为让当前 TUN 与规则完整接管，
# 而不是长期依赖 ipv6: false。

DNS 伺服器和出口節點不在同一地區並不一定異常，WebRTC 出現私有位址也不代表發生洩露。確認某一項仍暴露不該出現的公用網路出口後，再針對該項處理。

瀏覽器請求沒有進入代理，查系統代理、擴展或規則命中。

查 TUN 的 IPv6 路由；不需要 IPv6 時可按系統方式停用做對照。

查瀏覽器 DoH、系統 DNS 與 Mihomo DNS 誰在實際處理。

先確認是否還有實際公用網路候選，不要把私有位址直接判為洩露。