1 代理已开，DNS 为什么仍会「泄漏」
所谓 DNS 泄漏，在工程语境里通常指：本应随代理策略走的访问，其域名解析请求却落到了本地解析器、路由器或运营商递归上。对端看到的是「你问了什么域名」，而规则引擎却可能按另一套 IP 去做分流，于是出现解析与连接不一致：浏览器显示已代理，日志里却是直连 DNS；或国内规则本应运直连，却因解析到了「奇怪」的 CDN 出口而绕路。
常见诱因包括：应用使用自带解析器绕过系统设置、系统仍指向路由器 192.168.x.1、IPv6 未纳入隧道、仅开系统代理而命令行／游戏仍裸解析等。要「彻底」收敛，需要客户端 DNS 模块与接管方式（系统代理 / TUN）一起设计，而不是只改浏览器里一个开关。
下文默认你使用 Clash.Meta（Mihomo） 系内核，并已在 mode: rule 下工作。若你尚未让终端与 Docker 等流量进隧道，可先阅读《Clash Verge Rev TUN 模式完全指南》，再回来对照本文的 DNS 段落，整体闭环会更稳。
2 Meta 内核的 DNS 栈在做什么
Meta 在配置里的 dns 段，本质是内核内置解析器 + 与规则联动：它决定「这个域名先解析成什么 IP」，从而影响后续 GEOIP、IP-CIDR 与进程规则是否命中。常见 enhanced-mode 有 redir-host 与 fake-ip：前者更接近传统「先解析再匹配」，后者则把大量域名先映射到虚拟地址池，等真实连接建立时再按策略做远端解析。
nameserver 列表是主解析通路；fallback 常用于污染检测失败后的回退；default-nameserver 则用来解析 DoH／DoT URL 的主机名本身，避免「为了连上 DoH 却要先问运营商」的鸡生蛋问题。proxy-server-nameserver 负责解析代理节点域名，应优先走可信且可达的通路，否则会出现「订阅能下、节点域名却解析失败」的假死现象。
fake-ip-filter，并对局域网、内网与部分依赖真实 IP 的应用做例外。
3 FakeIP：原理、收益与必踩的坑
开启 enhanced-mode: fake-ip 后，对大部分域名，内核会先返回 fake-ip-range 内的一个地址给应用；当连接真正发起时，再由内核按规则选择直连或代理侧解析。这样，本地网络路径上往往只看到「连向 198.18.x.x」，而不是明文查询每一个站点域名。
fake-ip-range 与 filter
198.18.0.1/16 是社区常用的保留段，冲突概率低；若与你内网或测试环境撞车，可改为其他未在路由表中使用的私用段（需同时确保系统与 TUN 路由无重叠）。fake-ip-filter 应至少覆盖 *.lan、*.local、部分连通性探测域名与必须拿到真实 IP 的服务（例如某些 P2P、局域网设备发现）。漏配时常见症状是：国内站点异常慢、NAS 找不到、企业内网证书报错。
若你使用 geosite.dat / GEOIP 规则，可为国内或直连域名集单独放宽 FakeIP，思路是「该解析真实地址以便走 DIRECT 的，就别进虚拟池」。具体名单应随订阅与内网环境迭代，而不是复制粘贴后永不更新。
4 DoH 与分层：nameserver、fallback、policy
DoH（DNS over HTTPS）把查询封装在 TLS 里，降低链路被旁路篡改或窥探的概率；在 Meta 中写作 https://IP/dns-query 或带主机头的 HTTPS 端点均可。DoT 同理。实务上推荐主解析用延迟低、可审计的 DoH，fallback 再放一到两个国际公共解析，并配合 fallback-filter 识别「明显被污染的应答」。
nameserver-policy 适合精细场景：例如指定某些后缀或 geosite 集合固定走国内 DoH，其余走境外解析，减少不必要的跨境 RTT。策略写错时，表现往往是「只有几个站打不开」，而不是全线断网——这时应优先对照日志里的 DNS 阶段耗时与返回码。
命令行部署可参考《Linux 安装 Mihomo 并开机自启》中的目录与自检命令，把本文的 dns 段并入同一 config.yaml 后，用 mihomo -t -d 验证语法再重启服务。
5 生产向 YAML 模板（FakeIP + DoH）
下列片段可直接合并进现有配置，再根据你的节点地区、内网网段与是否启用 IPv6 做删减。listen 埠若与系统服务冲突请改掉；TUN 场景下请确保客户端已勾选「接管 DNS」或等价选项，使查询落到本机监听地址。
dns:
enable: true
ipv6: false
listen: 127.0.0.1:1053
enhanced-mode: fake-ip
fake-ip-range: 198.18.0.1/16
fake-ip-filter:
- '*.lan'
- '*.local'
- '*.localhost'
- '+.msftconnecttest.com'
- '+.msftncsi.com'
default-nameserver:
- 223.5.5.5
- 119.29.29.29
nameserver:
- https://dns.alidns.com/dns-query
- https://doh.pub/dns-query
proxy-server-nameserver:
- https://dns.alidns.com/dns-query
fallback:
- https://1.1.1.1/dns-query
- https://8.8.8.8/dns-query
fallback-filter:
geoip: true
ipcidr:
- 240.0.0.0/4
nameserver-policy:
'geosite:cn':
- https://dns.alidns.com/dns-query
若本地尚未加载 geosite 数据，可将 nameserver-policy 改为具体后缀（如 '+.qq.com'）或暂时删除该段，先保证服务能启动。proxy-server-nameserver 建议与 default-nameserver 使用你可直连且稳定的解析，以免启动阶段节点域名解析失败。
curl 命令交叉验证，比一次改十个字段更容易定位问题。
6 TUN、系统 DNS 与路由器的协同
仅系统代理时，不少应用仍会用自己的 DoH 或系统解析器，FakeIP 的收益会打折扣。TUN 模式把 IP 层流量纳入隧道后，再配合「DNS 指向本机 Clash 监听」或客户端自带的 hijack-dns 类能力，才能把解析与连接绑在同一条策略链路上。具体开关名称因 GUI 而异，但目标只有一个：别让查询在进隧道前就从网卡溜出去。
家用路由器若强制下发 DNS（DHCP Option 6），请在排错阶段观察 PC 网卡实际使用的解析器地址。双栈环境下若 IPv6 未走代理，也可能出现「解析走 AAAA、连接却走 IPv4 代理」的错位，此时要么在系统层关闭 IPv6 测试，要么在配置里显式声明 ipv6: true/false 与对应规则，保持与真实出口一致。
企业网络若对 DoH 域名或 IP 段有拦截，fallback 列表应具备可降级的备选（例如经公司允许的递归），否则会出现「规则全绿但解析全红」的现象。此类环境更要在变更前备份原配置，并与网管策略对齐。
7 验证与排错清单
- 看日志分段：区分是 DNS 超时、TLS 握手失败还是规则
MATCH到了意外策略组，避免把「解析错误」误判成「节点挂了」。 - 对照监听埠：确认没有其他服务占用
dns.listen；必要时换埠并在 TUN／系统设置里同步指向。 - 抽查直连域名：国内常用站应在日志中表现为
DIRECT且延迟正常；若走了代理，检查GEOIP与 DNS 返回的 IP 属地是否一致。 - 复查 filter：局域网设备、打印机、投屏协议等若异常，优先把相关后缀加入
fake-ip-filter再测。 - 第三方泄漏检测页：仅作辅助信号；不同测试站探测路径不同，应以内核连接日志 + 抓包结论为准。
8 总结
「彻底防止 DNS 泄漏」在真实世界里是一个系统工程：FakeIP 负责让应用侧少发明文查询、让规则先拿到可控的解析结果；DoH 与分层 nameserver 负责把远端解析放在加密与可信通路上；TUN 与系统 DNS 协同则堵住「代理开了但解析仍绕路」的最后一类口子。三者缺一，都可能留下可被观测或可被污染的解析路径。
与零散改 hosts、只换公共 DNS 相比，把策略写进 Meta 内核 YAML 的好处是可版本化、可回滚、可与 rules 同步演进。若你更习惯图形界面管理订阅与 TUN，可选用站内下载页推荐的客户端承载同一套内核逻辑；相比需要反复手动对齐系统设置的做法，一体化客户端在长期可维护性上往往更省心。
按本文模板落地后，建议保留一份「最小可工作配置」备份，再在副本上尝试 geosite 细分与 IPv6 策略，遇到异常即可快速二分回退。这样 DNS 与分流才能长期保持同一套叙事，而不是每次故障都从零摸索。
