一、为何「代理已开」仍像泄露真实 IP
不少用户遇到的现象是：Clash 托盘图标正常、策略组也显示走了节点，但打开某些「查询本机 IP」的页面时，仍能看到中国大陆运营商、校园网或家庭宽带的公网地址，甚至与路由器管理页上看到的 WAN 一致。第一反应往往是「规则没命中」或「节点失效」，于是反复换节点、重载订阅，却收效甚微。
实际上，网页里展示的「IP」并不只有一个含义。浏览器访问检测站时，至少存在三条并行通道：普通 HTTPS 请求经过系统代理或 TUN 后的出口地址；用于音视频通话协商的 WebRTC 可能直接向对端暴露本机网卡候选地址；以及页面发起的DNS 查询若未进入 Clash 的 DNS 模块，就会在你当前网络环境下直接解析，从而显示「解析服务器所在地区」或本地递归路径。三条通道任意一条仍指向本地或境内，就会在页面上形成「像没开代理」的观感，与 fake-ip 与 DNS 排障 一文里强调的「解析与连接要分开看」是同一逻辑：先对齐你正在看的是哪一类结果，再动配置。
二、三类检测：HTTP 出口、WebRTC、DNS
HTTP/HTTPS 出口 IP：由访问检测站主文档与接口请求时的 TCP 连接决定。系统代理或 TUN 把流量交给 Clash 后，远端看到的源地址应是节点侧公网 IP。若这一段仍显示本地地址，才需要查规则是否命中、是否走了 DIRECT、或是否存在分流漏项。
WebRTC：实时通信栈会在 ICE 收集中枚举主机候选（host candidate），其中常包含局域网地址或通过 STUN 映射得到的公网地址。这条路径不一定走 HTTP 代理，因此即使网页主体请求已代理，检测脚本仍可能读出「真实」出口特征，被误报为泄露。
DNS：页面可能单独发起 DNS 泄露测试，观察查询是由谁发起、解析经过哪些服务器。若操作系统或浏览器启用了独立 DoH/DoT，而 Clash 侧又配置了 dns 与 fake-ip，两套解析路径不一致时，测试页会列出非节点所在地区的解析链路，同样容易造成误解。这与 WSL2 与 DNS 排查 中「谁持有 53 端口与谁发起查询」的讨论相通：要把查询发起方与出站隧道对齐。
| 页面区块常见标签 | 优先怀疑方向 |
|---|---|
| Public IP / 出口 IP | HTTP 是否经系统代理或 TUN；规则是否误直连；是否仅 QUIC 未接管 |
| WebRTC / ICE / local IP | 浏览器 WebRTC 是否未禁用；扩展或内核标志是否覆盖 |
| DNS / resolver | 系统 DNS、Clash dns、浏览器安全 DNS（DoH）是否分流一致 |
三、WebRTC：浏览器侧关闭与验证
在确认 HTTP 出口已是节点地址的前提下，若页面仍列出本地局域网段或国内公网作为 WebRTC 相关结果，下一步应在浏览器内限制 WebRTC 暴露本机地址。不同浏览器选项名称略有差异，常见思路包括：将「默认路由」改为仅使用代理转发后的候选（若客户端提供）、关闭非代理 UDP、或使用策略限制 mDNS 与 host 候选。桌面 Chromium 系可检索与 WebRTC IP handling、UDP 相关的实验项做对照；Firefox 用户可在 about:config 中调整与 media.peerconnection 相关的开关，将候选限制在可代理路径上。
若你不希望改动全局标志，可临时使用仅用于测试的配置档案或干净配置文件，在仅启用扩展、不混装多个代理扩展的前提下验证。部分「隐私类」扩展会同时改写 WebRTC 与代理，冲突时表现为随机失效，建议一次只保留一类改写工具。验证时先打开开发者工具网络面板，确认检测页的主文档与脚本均走预期策略组，再观察 WebRTC 区块是否随关闭候选而消失。
四、DNS：系统、Clash 与浏览器 DoH 对齐
DNS 泄露在用户体验上常表现为：检测页列出运营商或本地宽带 DNS，或显示与你节点所在国家不一致的解析路径。排查时建议按顺序回答三个问题：谁在做 DNS 查询（系统、Clash、浏览器）？查询是否被 redir-host 或 fake-ip 改写？最终出站是否与网页流量同一策略？
当 Clash 启用 dns.enable 且 enhanced-mode 为 fake-ip 时，应用若将查询发往本地 Clash 所监听的 DNS 地址，通常会进入内核 DNS 模块；但若操作系统仍把默认解析指向路由器或运营商 DNS，而浏览器又单独开启了安全 DNS（DoH）直连公共解析商，则检测页会看到多套解析源并存。此时并非 Clash「坏了」，而是解析路径未统一。可先在浏览器中暂时关闭安全 DNS，或在系统层将 DNS 指向 Clash 提供的本地监听地址（具体以你所用客户端文档为准），再复测泄露区块是否收敛。
若你希望继续使用 DoH，应确保DoH 查询本身也经代理出口，或与 Clash 的 nameserver 列表语义一致，避免出现「网页走节点、DoH 直连出境」的分裂。对于分域策略较重的配置，可配合 nameserver-policy 将特定后缀交给可信上游，并与 配置文档 中的 DNS 段示例对照，避免重复定义 dns: 键导致合并覆盖。
五、Clash 与系统代理核对清单
下列项适合在修改浏览器前快速自检，逐项打勾可显著缩短排障时间。
- 系统代理或 TUN 是否生效：仅开 Clash 但未打开「系统代理」或虚拟网卡时，部分应用仍直连；浏览器若使用独立代理插件，也可能与系统代理叠加冲突。
- DNS 是否指向 Clash：在系统网络设置或所用 TUN 文档建议中，确认 DNS 请求进入 Clash 监听地址；若使用
dhcp-dns等特殊模式，以当前内核说明为准。 - fake-ip 与规则一致性：若检测站域名被标为直连却走了假地址，或反之，可参考 fake-ip 专文中的
fake-ip-filter思路微调，避免解析语义与策略组不一致。 - UDP 与 QUIC：部分站点使用 HTTP/3，若规则或模式未覆盖 UDP，可能出现「页面一部分信息仍像直连」；可结合 TUN 与防火墙排查 核对是否放行内核所需协议。
完成清单后，再在检测页分别截图 HTTP 出口、WebRTC 与 DNS 三块结果，对比修改前后差异；每次只改一类变量，避免同时调整扩展、DNS 与订阅导致无法归因。
六、检测页对照实验的注意点
各类「泄露检测」站点实现细节不同，有的会并行发起多区域探测，有的会等待 WebRTC 完成 ICE 后再展示结果。建议在同一浏览器会话内先硬刷新、再禁用缓存复测，并避免同时打开多个检测标签互相干扰。若使用隐私模式，注意扩展策略可能与常规模型不一致。
企业网络或校园网环境中，出口 NAT、透明代理与 DNS 劫持可能让任意配置都呈现复杂结果，此时最有价值的是同一网络下改前改后的纵向对比，而不是与他人的截图横向对比。若仅在某一类浏览器内核上出现 WebRTC 区块异常，可换另一内核做对照，以判断是全局网络问题还是单浏览器策略问题。
最后需强调：本文目的是帮助理解常见误判场景与自查顺序，并非鼓励规避监管或违反当地法律与服务商条款。请在你有权使用的网络环境中操作，并遵守所在单位与服务商政策。
七、小结
Clash 已开代理却仍在浏览器里看到「真实 IP」，多数并非节点瞬间失效，而是 HTTP 出口、WebRTC 与 DNS 三类路径未同时走同一套隧道。先分清页面上每一块结果对应哪条通道，再按顺序处理：确认系统代理或 TUN 与规则命中；在浏览器侧限制 WebRTC 候选；最后统一系统 DNS、Clash dns 与浏览器 DoH，使解析发起与流量出站一致。
与单纯「换节点」相比，这种分层排查更能稳定解决「像没开代理」的体验问题，也与本站 fake-ip 与 DNS、TLS 握手等排障文形成互补：一则管解析与假地址，一则管握手与规则，本文则侧重浏览器侧泄露检测的常见误解。
相比其他同类工具，Clash 系列在 DNS 与多模式协同上可配置项丰富；把 WebRTC 与 DNS 对齐后，日常测速与隐私类自检也会清晰许多。