安全与隐私 · Clash 技术博客

Clash 会泄露真实 IP 吗？DNS、WebRTC 与 IPv6 泄露检查方法

检测页出现本地地址或不同地区，不一定就是泄露。先分别记录出口 IP、DNS、WebRTC 和 IPv6，再只修真正绕过 Clash 的那一项。

阅读正文返回博客
  • DNS 泄露
  • WebRTC
  • IPv6
  • 隐私
本文目录
文章作者
Clashare
发布日期
更新时间
预计阅读
约 9 分钟

先回答“有没有泄露”：看公网出口，不看一个绿色提示

Clash 不会自动保证所有应用、DNS、WebRTC 和 IPv6 都经过同一出口。要判断是否泄露，需要分别记录开启代理前后的公网 IPv4、IPv6、DNS 服务器和 WebRTC 候选。

看到 192.168.x.x 这类私有地址，并不能说明真实公网 IP 已经暴露。真正要处理的是代理开启后仍出现本地运营商的公网地址。

不要混为一谈

检测项它回答的问题异常才是什么
公网 IPv4网站看到哪个出口开启代理后仍是明确的本地运营商出口
公网 IPv6IPv6 是否走同一接管方式IPv4 走节点、IPv6 仍从本地直出
DNS 服务器查询可能由谁完成与配置不符并导致域名绕开预期规则
WebRTC 候选地址浏览器为实时通信发现了什么地址出现不符合预期的真实公网出口；192.168/10.x 本身不是公网泄露

直连、系统代理、TUN 各测一次

检测页本身不是结论，前后两次结果才有意义。使用同一个浏览器、同一个网络和同一检测页，只改变 Clash 的接管方式，并把四项结果并排保存。

可比较的测试

  1. 完全退出代理记录直连

    保存 IPv4、IPv6、DNS 和 WebRTC 四项，不只截一个绿色结果。

  2. 开启系统代理

    新建无痕窗口再次检测，确认浏览器请求的出口变化。

  3. 需要时开启 TUN

    仍用同一网络和节点测试，观察 IPv6 与不读取系统代理的应用。

  4. 每次都看连接页

    检测域名出现、规则和出站一致，结果才与当前 Clash 配置相关。

只有 Chrome 的 DNS 结果不同，检查安全 DNS

Chrome 在“设置 → 隐私和安全 → 安全性”里可以单独启用安全 DNS；Firefox 的 DNS over HTTPS 位于隐私设置。浏览器启用独立 DoH 后，查询可能不再经过系统 DNS，Clash 的系统代理又未必接管这条解析请求。

短时间关闭浏览器 DoH，完全退出并重开浏览器。如果 DNS 结果回到 Clash 预期入口，原因已经确定；随后可以选择继续由浏览器处理，或者统一交给 Mihomo，重点是不要在三处同时覆盖。

WebRTC 显示 192.168.x.x 时，先确认它是不是私有地址

WebRTC 为语音、视频和点对点通信收集候选地址。现代浏览器可能把本地地址隐藏成 mDNS 名称，也可能显示私有网段；这些信息能说明局域网环境，却不能从互联网直接路由到你的电脑。

真正需要处理的是代理开启后仍出现本地运营商的公网 IPv4 或 IPv6。完全禁用 WebRTC 会让网页会议和屏幕共享失效，优先使用浏览器的地址限制选项，并在 Zoom、Meet 或 Slack Huddle 里重新验证功能。

IPv4 正常、IPv6 直出时，再决定接管还是关闭

系统代理通常处理应用明确交给代理的请求，不保证所有 IPv6 连接都被接管。TUN 是否处理 IPv6 又取决于客户端版本、路由和配置。先确认业务是否需要 IPv6；不能接管时，临时关闭 IPv6 做对照比在规则末尾盲目 REJECT 更能说明原因。

只作排查示意，启用前确认客户端生成配置不会覆盖
dns:
  enable: true
  ipv6: false
  enhanced-mode: fake-ip

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

按不一致的那一项修，不追求四栏同一个地区

DNS 服务器和出口节点不在同一地区并不一定异常，WebRTC 出现私有地址也不代表发生泄露。确认某一项仍暴露不该出现的公网出口后，再针对该项处理。

公网 IPv4 仍是本地出口

浏览器请求没有进入代理，查系统代理、扩展或规则命中。

IPv4 是节点，IPv6 是本地出口

查 TUN 的 IPv6 路由；不需要 IPv6 时可按系统方式禁用做对照。

只有 DNS 与预期不同

查浏览器 DoH、系统 DNS 与 Mihomo DNS 谁在实际处理。

只显示局域网私有地址

先确认是否还有真实公网候选，不要把私有地址直接判为泄露。

参考资料