为什么「开了代理」仍会看到本机公网或同城 IP

许多用户会把「网页里显示的 IP」等同于「出口是否走了节点」。但在浏览器里，至少有两条并行故事线：HTTP(S) 资源请求，往往确实通过你配置的系统代理或浏览器代理扩展进入 Clash；而 WebRTC 为实时通信做的 ICE（交互式连接建立）过程，会在候选地址收集阶段把本机网卡、局域网段、以及通过 STUN 探测到的公网映射地址汇报给检测页面里的脚本。测速站或「泄露检测」工具如果读的是 WebRTC 结果，就可能与「顶部显示为代理出口的 IP」不一致——于是出现你主观上的「明明代理了还像本地」。

另一个常见误会，是把这种现象与 Fake-IP 或 IPv6 双栈混为一谈：前者是 DNS 返回虚拟地址、连接阶段再解析；后者是系统仍有一个直连 IPv6。它们在日志与测站上的表现各不相同。若你看到运营商下发的 IPv6 仍在活跃，可先对照 IPv6 双栈与直连规则 专文，避免调了半天规则其实根因在网卡双栈；若 Fake-IP 下局域网访问异常，则参见 Fake-IP 与局域网 的说明。

ℹ 记住一句话：能限制「脚本通过 WebRTC 读到你哪些候选 IP」的，主要是浏览器策略与实际 ICE 行为；Clash 负责的是策略路由与隧道覆盖哪些流量。两边要一起核对，而不是默认「开 TUN 就自动消灭所有泄露」。

先排除：不像 WebRTC 的几类情况

在改浏览器之前，建议用 5 分钟做分层对照，避免把 DNS 泄漏、系统代理残留或规则看错当成 WebRTC。若泄漏站只检测 DNS，而你的浏览器开了独立 DNS over HTTPS，显示结果可能与 Clash 的 dns 模块无关，这时应回到 Clash Meta DNS 配置 与系统「加密 DNS」开关的对照。若仅系统代理开启、部分应用自带走本地 SOCKS/DoH，也可能出现「浏览器像走了代理、底层解析仍在外面」的错觉；整体验证思路与「退出后无网络、代理残留」类问题有交集，可参考 退出 Clash 后无法上网与代理残留 中的环境对照方法。

当你确认：同一浏览器里纯 HTTP 检测已显示节点侧出口，而WebRTC 区块仍出现本地或同城地址，再继续下文会省很多时间。规则侧若担心误判，可复习 规则分流最佳实践 中的匹配顺序，避免把「泄露」与「某条直连规则过宽」捆在同一结论里。

Chromium（Chrome / Edge / Brave）：改策略或限制 ICE

Chrome 系浏览器对 WebRTC 的可调项会随版本与企业策略变化；家庭用户通常有两条路：安装扩展在页面层阻止或改写候选，或使用面向开发者/进阶用户的标志位与组策略做更底层限制（具体键名以当前稳定版说明为准，避免照抄过期截图）。实务上更稳妥的顺序是：先用无痕窗口 + 仅装一个可信扩展做 A/B，确认页面检测确实依赖 WebRTC 再做长期配置。

若你使用仅系统代理而不开 TUN，某些检测页的行为会与「整台系统进隧道」不一致：前者更容易出现「HTTPS 走节点、ICE 仍贴网卡」的断层。希望应用统一从隧道进出时，通常更推荐开启 Clash 的 TUN 并核对路由与劫持，细节见 TUN 模式深入解析。即便如此，浏览器是否仍向外展示本地候选，最终仍取决 WebRTC 实现与扩展，而不是单靠「开了 TUN」四字概括。

团队环境若被企业策略锁定了浏览器，个人侧改 flag 可能无效；这时应与管理员确认是否允许 WebRTC、或换用策略更透明的渠道访问检测页。

Firefox：media.peerconnection 与隐私档

在 Firefox 中，与 WebRTC 相关的设置历史上通过 about:config 中的 media.peerconnection.* 系列项调节（不同版本可见项略有差异）。更面向普通用户的路径，是使用增强型跟踪保护或自带/第三方隐私档，它们可能以「限制指纹识别」为名影响 WebRTC 的可观测行为。与 Chrome 系一样，建议先在一个干净配置文件里试，再合并进日常配置，以免与日常依赖的媒体功能冲突。

如果你在 Firefox 里同时装了代理类扩展，请确认「冲突优先级」：有的扩展会接管联网路径，使得连接日志里出现重复或绕行的目标。解读握手与超时可搭配 Clash 连接日志与 TLS，区分是 ICE 层表现还是代理链本身的失败。

Safari 与其它环境：能改什么、改不了什么

Safari 与部分移动 WebView 对 WebRTC 的暴露面与桌面 Chromium 差异很大；若你在 iPhone 或嵌入式浏览器里做检测，结果不一定能与 macOS 桌面版对齐。此时更可靠的经验法则是：同一台机器上，用一两款你信任的主力浏览器完成闭环；不要仅凭某个 WebView 内嵌页的结论反推 Clash 未工作。

对移动端 App：很多 App 自带网络栈，既不读系统代理，也不走你桌面上的浏览器策略。若问题出在 App 而非 Safari，往往要回到 TUN/按应用分流或网关方案；选型见 如何选择适合自己的 Clash 客户端。这与「浏览器 WebRTC」是不同排障赛道。

与 Clash 对照：日志里如何验证「谁在泄露」

Clash 系列客户端的连接面板 / 日志是你最好的物证：当你刷新泄露检测页时，关注同时出现的新建连接。若页面发起的是对你当前策略出口的 HTTPS 请求，你会看到对应域名命中了代理策略；若仍有去往 STUN 服务器或非常规端口的 UDP，而你的目的是限制这类路径，就需要结合内核与模式判断它是否被 TUN 覆盖或被规则允许。不同内核、不同平台上 UDP 的处理差异很大，不要凭印象下结论。

分流验证的意义在于：把「出口更像节点」与「页面仍能看到本地候选」拆成两个可独立为真的命题。你可以临时建一个仅用于实验的策略组，只让泄露检测站的域名走固定节点，再观察 WebRTC 区块是否变化——若不变，更支持浏览器侧 ICE 行为而非 Clash 规则写错。规则集维护与顺序仍然建议遵循 规则分流最佳实践，以免对照实验被一条过宽的 MATCH 干扰。

可重复的验证步骤清单

按顺序做，可反复复现、也方便他人帮你远程排查。

  1. 固定环境：同一台电脑、同一浏览器主版本、暂时关掉无关代理扩展与「网页加速」插件。
  2. 确认 Clash 模式：记录当前是系统代理、TUN 还是混合；若刚切换模式，等路由表稳定后再测。
  3. 打开连接日志：复现检测页加载过程，看 HTTPS 目标与 UDP/STUN 相关条目是否如你预期。
  4. 对照 HTTP 与 WebRTC 区块：若前者已是节点出口、后者仍像本地，优先处理浏览器 WebRTC 策略。
  5. 关 WebRTC 后再测：按上节在 Chrome 或 Firefox 完成最小改动，再次加载同一检测页。
  6. 排除 DNS/IPv6：必要时并行参考 Fake-IP、IPv6 双栈专文，避免两类问题混在一起。
  7. 记录截图与版本号：包括浏览器小版本与 Clash 内核版本，利于复盘。

测速站与第三方检测脚本并不等价于权威审计工具：它们可能更新滞后、或对 QUIC/HTTP3 与 WebRTC 混合场景产生误报。把结果当作启发式线索，而不是司法结论。

⚠ 合规与安全：仅在你有权检测的网络环境中操作；不要尝试入侵他人系统或规避所在单位安全策略。扩展与第三方脚本请选择可追溯来源，避免「防泄露」变「装上新后门」。

结语

「开代理后浏览器仍像泄露真实 IP」里，很大一部分可归结为：WebRTC 这条并行通道与经典 HTTP(S) 浏览器代理并非同一抽象层；你需要在浏览器侧关闭或收紧 ICE，再配合 Clash 的分流验证与连接日志确认其它路径没有掉队。把两类现象拆开，排障会快得多。

相比反复换节点，先完成一次可重复的泄露对照，往往更能稳定你的路由与 DNS 配置预期；这与我们在 Fake-IP、IPv6、TUN 等文章里反复强调的「先分层、再归因」是同一套方法论。

当你需要把 DNS、TUN、局域网与规则维护放在同一套工作流里，图形化且日志友好的客户端会明显省时间；若尚未确定用哪一款，可从 如何选择适合自己的 Clash 客户端 一文对照你的平台与习惯。

相比其他同类工具，Clash 在规则透明度与连接可视性上往往更让人安心；当你把浏览器 WebRTC 与 Clash 日志两边对齐后，「代理了还像本地」的疑惑通常会收敛成几条可验证的事实，而不是玄学。

→ 立即免费下载 Clash，开启流畅上网新体验，在客户端里结合日志完成 WebRTC 关闭前后的对照测试。