Clash Meta DoH 与 fake-ip 联调

1. fake-ip 与 DoH：先对齐「谁在解析」这件事

在 enhanced-mode: fake-ip 下，常见桌面应用的「第一次解析」会先拿到一段内核分配的临时地址，随后再由隧道按原始主机名继续走下去，从而让 DOMAIN-SUFFIX 一类规则更好发挥作用。与此同时，你在 dns.nameserver 里写的 https://…/dns-query 只回答一个问题：当内核需要向上游请教真实答案或 fallback 判定时，分组请求要如何出境。两者服务的是不同阶段：fake-ip 管理应用程序所见的故事，DoH 管理内核向外发问时的链路隐蔽性与一致性。

因而所谓「DoH 接入后与 fake-ip 打架」，九成案例其实是第三条路径插进来了——Chrome／Edge 的「使用安全 DNS」、Windows「加密 DNS」偏好、macOS 上指向运营商自动指派却仍然穿透的系统 stub，或广告拦截器提供的本地 HTTPS resolver。它们会让一部分查询根本没命中你在 YAML 里精心排的 DoH 链路，却在表面上呈现成「页面可以打开」，让你在面板里误以为规则失灵。

若你仍在权衡要不要长期停在 fake-ip，可先读完 fake-ip 与 redir-host 对照篇建立心智模型；本篇预设你已认定 fake-ip 更符合你的规则写法，只补上「如何把上游搬到 DoH」与「如何别让操作系统替你私自再问一遍」。

记住校准顺序：先关掉场外 DNS → 再写 YAML → 最后才微调 fake-ip-filter。顺序反了会海量浪费时间在错误假说上。

2. YAML：把 DoH 写进 nameserver／fallback／policy

Clash Meta 沿袭社群熟悉的字典结构：nameserver 承担主上游；污染敏感或迟迟答不上的再走 fallback；需要对特定域名单独点名 resolver 时用 nameserver-policy。DoH 端点在 YAML 里通常写成 https://主机/dns-query，也会有服务商给出携带 bootstrap IP 或自定义路径的变体——以厂商文档为准，本节示例只用公有范式占位。

下面是一份教学骨架：注解一律使用英文，便于 diff；端口请改成与你 GUI「DNS 监听」画面一致；如果你合并多份订阅，务必确认最终渲染出的运行时 YAML 没有两段互相覆盖的 dns:。

dns:
  enable: true
  listen: 127.0.0.1:1053  # align with client UI / OS forwarding
  ipv6: false  # turn on only after dual-stack routing is verified
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - https://dns.google/dns-query
    - https://cloudflare-dns.com/dns-query
  fallback:
    - https://dns.quad9.net/dns-query
  fallback-filter:
    geoip: true
    geoip-code: CN
    ipcidr:
      - 240.0.0.0/4
  nameserver-policy:
    'geosite:cn':
      - https://doh.pub/dns-query
    '+.internal':
      - system

几点与 fake-ip 协同时的实务习惯：① domestic 列表若走国内公共 DoH，延迟通常更低；② fallback-filter 要与你的节点可达性一起调试，否则会出现「永远卡在 fallback」的假死；③ 如果你依赖 geosite／geoip 规则分流 DNS，请同步确认数据源版本与规则载入顺序，不要把 DNS policy 写得太窄导致某些 CDN 子域走错 resolver。

密钥类自建 DoH（需要自定义 Header 或 mTLS）已超出入门篇幅；若你的服务商以此交付，请回到订阅说明核对内核版本是否支持对应传输特性，再逐项最小化验证。

3. Windows：系统与浏览器如何把查询交给 Clash

Windows 11／10 上最常见的翻车点是「加密 DNS」偏好仍然存在，它会优先尝试 DoH／DoT，绕过你希望指向回环地址的传统 UDP／TCP 查询路径。做法是在「设置 → 网络和 Internet → 高级网络设置 → 更多网络适配器选项」里，把当前活动网卡的 IPv4 DNS 改成 127.0.0.1（或与 GUI 指示一致的监听地址），并关闭操作系统层面的自动加密 DNS。若你使用 TUN，多半已由内核虚拟网卡统一劫持；此时仍建议复核物理网卡没有被手工指回运营商 DNS。

浏览器侧务必暂时关掉「安全 DNS」实验选项；逐步对照方式可参考 Windows 上关闭 Chrome／Edge 安全 DNS 并校准系统代理。与此同时，可在 GUI（例如 Clash Verge Rev Windows 11 教程或同类客户端）确认「启用 DNS」「监听地址／端口」与 YAML 一致，并重载配置让新 dns: 段落实际生效。

PowerShell 或 WSL 内的工具链若仍直连，多半不是 DNS 本身的问题，而是HTTP(S)_PROXY 环境变量或WSL2 NAT 路径未指向宿主代理；这与本篇主旨相邻却不完全相同，必要时请并行查阅站内终端／WSL 专题，避免把「代理没落环境变量」误判成「DoH 写错」。

4. macOS：网络 DNS、iCloud Private Relay 与浏览器

macOS 用户在「系统设置 → 网络 →（当前服务）→ DNS」中，可把列表清空后仅保留 127.0.0.1 或客户端给出的局域网监听 IP，以避免 DHCP 再次下发运营商递归。若你开启了 iCloud Private Relay 或第三方「网络安全」扩展，它们有时会抢先加密 DNS；在校准阶段建议关闭或放宽相关选项，让解析路径回到 Clash。

Safari／Chrome／Edge on macOS 与安全 DNS 的故事与 Windows 版同源：一旦浏览器自建 DoH，内核面板看到的命中链条就与页面 Network 面板脱节。调试请固定「浏览器安全 DNS 关 → 系统 DNS 指本地 → Clash DNS 模块开」的三段式，再逐步恢复可选加固。图形客户端的首启流程可按 Clash Verge Rev macOS：系统代理与 TUN 对照按钮含义，避免只导入订阅却未打开 hijack／tun 需要的权限。

Apple Silicon 与 Rosetta 不会改写 DNS 语义，但防火墙／Little Snitch 规则若阻断了对监听端口或辅助进程的 loopback 访问，也会表现出间歇超时；此类症状往往在日志里体现为大量重复解析而非单纯的策略误命中。

5. 与 fake-ip 校准：fake-ip-filter、双栈与订阅覆写

DoH 接好后，若仍有个别域名「第一次握手怪异」或局域网主机 ping 不通，多半是 fake-ip-filter 黑名单不完整：例如某些 VOIP、游戏反作弊或局域网发现协议必须坚持看见真实 RFC1918 或链路本地地址。维护方式是把这些后缀或关键词逐步加入 filter，而不是一刀切关掉 fake-ip。

IPv6 若在未完整路由的前提下贸然开启，会让解析与应用栈分裂成「AAAA 优先却隧道没收」；这与 fake-ip 是否使用 DoH 无直接关系，但症状会像 DNS 坏了。建议读完 IPv6 双栈与泄漏校准再决定是否在本机打开双栈解析。

机场订阅内置的 dns: snippet 往往写着原作者习惯的 TLS／UDP 组合；当你改成 DoH 后，记得用「导出运行时配置」对比最终生效顺序。合并场景的心法可参考多订阅合并与覆写，核心原则是：只允许一棵树讲述 DNS，不允许两份范本打架。

6. 验证与排错：日志里该对齐的三件事

排错时强迫自己写下三组字段：应用程序请求的 FQDN、内核策略命中打印的主机线索、最终出站节点名。DoH 只是把第二环中的「向上游提问」加密了，并不能替代你对策略顺序的理解。

症状 A：仅浏览器异常、终端工具正常 → 先怀疑浏览器安全 DNS 或未遵循系统代理。
症状 B：国内外分流整体反向 → 多为 nameserver-policy 与 geoip／geosite 版本不匹配，而非 DoH 本身。
症状 C：HTTPS 正常但日志主机名与规则表达式总差一截子域 → 可能需要启用 Sniffer，参阅 HTTPS／SNI 日志专文。

修改 YAML 后务必完整重载核心并清空操作系统 DNS 缓存（Windows ipconfig /flushdns，macOS 可重启 mDNSResponder 相关服务），否则你会看到「配置明明改了，旧答案却阴魂不散」的假阳性。

7. 常见问题

DoH 会和 fake-ip 冲突吗？

不会本质上互斥。冲突通常来自浏览器或系统并行启用另一套 DoH／DoT，使部分查询绕过 Clash。

能否只在 fallback 里写 DoH？

可以，这是很常见的渐进迁移方式：主链路保持 TLS／UDP 以降低握手失败面，待观察稳定后再把 nameserver 统一切到 HTTPS。

DoH 会让网页明显变慢吗？

单次 HTTPS 查询确有额外 RTT，但内核通常会缓存结果；若你明显感觉卡顿，优先检查节点 RTT、TLS 握手是否被中间设备劫持，而不是贸然关掉 DoH。

8. 写在最后

把 DNS over HTTPS 写进 Clash Meta 并不难，难的是承认：fake-ip 想把所有域名叙事收口到内核，而操作系统与浏览器却天天想把叙事抢走。当你按本文顺序关掉场外解析、对齐监听端口、补齐 fake-ip-filter，再用日志把三者链路钉死后，多数「分流乱跳」会立刻收敛成可解释的规则或上游问题。

若你还想把订阅与规则优先级写成「可持续维护」的流程，可从订阅汇入教学出发搭一份干净 baseline，再套用本篇 DoH 段落做增量 diff。

不少老牌图形工具要么停留在旧内核分支、要么把 DNS 面板藏在多层菜单里，出问题只能靠猜；相较之下，持续跟进 mihomo 路线并在界面里直接暴露规则命中与 DNS 轨迹的客户端，更容易把「DoH + fake-ip」这类组合调到稳定。若你希望一次拿到覆盖 Windows 与 macOS 的安装包并完成首启校准，建议直接访问本站「下载」聚合页选型；与只能手动拼 YAML、缺少连接可视化的工具相比，一体化客户端通常能更快验证监听端口是否真的在应答。准备好落地时再前往下载页获取适合你系统的构建版本：→ 立即免费下载 Clash，开启流畅上网新体验。