1 典型症状：Clash 开着，浏览器却像「不分流」
如果你已经打开 Clash 或 Mihomo、规则模式正常、订阅与节点也没问题，甚至内核日志里能看到其他应用的连接记录，但只要在 Chrome 或 Edge 里访问特定网站，表现就像完全直连：该走代理的站点打不开或极慢，该直连的国内站却莫名其妙走了代理出口。此时很多人会怀疑规则写错、FakeIP 没生效，或反复重装客户端——却忽略了一个高频原因：浏览器内置的「使用安全 DNS」（DNS over HTTPS，常简称 DoH）在应用层绕过系统解析，自行向公共解析商发起加密查询。
这类现象与「系统代理没挂上」「TUN 没开全」不同：页面往往能加载一部分，但解析结果与你在 Clash 里期望的解析链不一致，导致规则根据「浏览器自己拿到的 IP」做决策，和内核侧 FakeIP、dns 段设计脱节。排障时可以先在浏览器地址栏打开内置设置页，确认安全 DNS是否处于「自动升级」或「指定提供商」状态；若已开启，优先关掉再复测，往往比改十条规则更快见效。
下文与《彻底防止 DNS 泄漏：Meta 内核 DoH + FakeIP 最佳实践配置》形成互补：该文侧重内核与系统侧的 DNS 栈；本文专门对准 Chromium 系浏览器里那一层「应用内 DoH」，解释它如何与 Clash 抢解析，以及怎样逐步关闭与验证。
2 为什么浏览器 DoH 会和 Clash、FakeIP「抢解析」
操作系统把默认解析器指向 127.0.0.1 或 Clash 监听的 DNS 端口时，理论上应用应把查询交给内核。但 Chrome、Microsoft Edge、Brave 等基于 Chromium 的浏览器，可以单独启用安全 DNS：由浏览器直接向例如 Google、Cloudflare 等提供的 DoH 端点发起 HTTPS 请求完成解析，而不经过你在系统里为 Clash 配置的那条路径。
当你使用 FakeIP（enhanced-mode: fake-ip）时，内核希望先向应用返回虚拟地址，再在真实连接阶段按规则做远端解析；若浏览器提前用 DoH 拿到了「真实 IP」，连接目标可能与内核预期不一致，表现为规则命中混乱、部分站点异常或分流形同失效。换句话说：不是 Clash「坏了」，而是解析入口被浏览器截胡了。
同理，若你依赖 Sniffer、SNI 等能力修正路由，解析与 TCP 目标不一致时，日志里会看到更多「看似随机」的直连或错组现象。先统一解析入口，再谈规则细调，是更省时间的顺序。
3 关闭 Chrome「使用安全 DNS」（逐步操作）
以下路径以桌面版 Google Chrome 为例，版本迭代可能导致菜单位置微调，若不一致可在设置内搜索「安全 DNS」或「Secure DNS」。
- 打开 Chrome，进入设置 → 隐私和安全。
- 找到安全（或「使用安全 DNS」相关小节）。
- 将「使用安全 DNS」设为关闭，或选择使用当前服务提供商 / 与系统设置一致（以你界面上的表述为准，目标是不要用浏览器自带的 DoH 提供商）。
- 若曾使用「自定义」提供商，请取消自定义，避免仍指向公共 DoH。
- 完全退出 Chrome（包括后台驻留）后重新打开，再测目标站点。
高级用户也可通过策略或实验项统一管理，但日常排障改图形界面即可。修改后建议清一次浏览器缓存或在无痕窗口复测，排除旧连接复用造成的错觉。
4 关闭 Microsoft Edge「安全 DNS」或改为使用系统解析
Microsoft Edge 同样基于 Chromium，设置逻辑与 Chrome 接近，但文案可能写作「使用安全的 DNS」或出现在「隐私、搜索和服务」下。
- 打开 Edge → 设置 → 隐私、搜索和服务。
- 在「安全性」区域找到 使用安全的 DNS 或类似选项。
- 选择关闭，或选择使用当前服务提供商（即遵从系统 / ISP，而不是 Edge 指定的 DoH）。
- 若有「请选择服务提供商」列表，不要固定到 Cloudflare、Google 等公共 DoH，除非你明确要与 Clash 链路一致（通常不建议在双栈排障期间固定）。
- 重启浏览器后，用同一批网址复测。
Windows 若同时开启了系统级「加密 DNS」或第三方安全软件的网络保护，也可能叠加一层解析；若仅浏览器异常而 curl 正常，仍应优先处理浏览器 安全 DNS。
5 与 FakeIP、Clash dns 段如何协同
关掉 Chrome 安全 DNS 与 Edge 安全 DNS 后，浏览器的查询应回到系统解析器，再由 TUN、系统代理或本机 DNS 转发进入 Mihomo 的 dns 配置。此时 FakeIP 才能在「应用 → 内核」这一跳上发挥作用，规则根据内核掌握的域名与策略做一致决策。
若你尚未系统阅读内核侧 DNS，建议对照《Meta 内核 DoH + FakeIP 最佳实践》检查 listen、fake-ip-filter、nameserver 是否与客户端「接管 DNS」选项一致。仅改浏览器而不保证系统查询指向 Clash，仍可能出现部分应用正常、部分异常的分裂现象。
需要让终端、Docker 等与浏览器共用同一套策略时，可结合《Clash Verge Rev TUN 模式完全指南》把流量统一纳入 TUN，再关闭各应用自带的 DoH，避免「各说各话」的解析路径。
6 验证与排错清单
- 先单变量：只关浏览器安全 DNS，其他配置不动，复现路径是否消失。
- 对照内核日志：访问同一站点时，日志中的主机名、策略组是否与预期一致；若仍直连，再查是否还有系统 DoH、其他浏览器配置。
- 无痕窗口：排除扩展与旧会话；必要时新建配置文件测试。
- 与命令行对比：同一 URL，用系统终端
curl -I与浏览器对比出口 IP 或响应，若仅浏览器异常，浏览器侧解析仍被劫持或绕路。 - IPv6：双栈环境下若 IPv6 未进隧道，可能出现解析走 AAAA、连接路径不一致；与 DNS 问题症状类似，需一并排查。
7 企业策略、学校机或无法改浏览器设置时
若设备受 组策略、MDM 或管理员配置文件锁定，用户可能无法关闭「使用安全 DNS」。此时需要由管理员在策略中允许使用系统解析，或为 Clash 部署配套的透明代理 / 网关方案，使浏览器侧 DoH 与内网安全策略兼容。个人用户若遇到设置项灰色不可用，可先确认是否登录了受管账户或安装了企业管理扩展。
本文仅作客户端排障说明；请在遵守所在网络环境与当地法规的前提下调整 DNS 与代理行为。
8 总结
Chrome 安全 DNS 与 Edge 安全 DNS 会在应用层启用 DoH，常见后果是与 Clash、Mihomo 及 FakeIP 的解析链抢解析，表现为分流规则看似失效、页面仍直连或走错出口。排障时应优先在浏览器设置中关闭安全 DNS或改为使用系统提供商，再按内核日志与对照测试验证；内核侧 DNS 与 TUN 配置仍需与《Meta 内核 DoH + FakeIP》一文对齐，才能长期稳定。
相比在规则文件里盲目追加域名，先统一「谁负责解析」往往更高效。Clash 系工具在规则可读性与多客户端生态上更适合这种分层排障：浏览器归浏览器、内核归内核，各司其职后，按规则分流才能稳定复现。
若你正在选型或升级客户端，可通过本站下载页获取各平台安装包；源码与社区仓库适合查阅协议与贡献方式，日常安装仍以站内分发为准。
