DNS「泄漏」在代理场景里到底指什么
日常所说的 DNS 泄漏，并不单指「查询内容被第三方看见」这一件事，在 Clash / Meta 语境下更常指：应用程序发起的域名解析没有按你预期的路径进入内核的 DNS 模块，而是仍走系统网卡配置的递归解析（例如运营商或路由器下发的 DNS）。结果是：规则里写了某域名走代理，但连接建立前拿到的可能是未经隧道保护的解析记录，或与 FakeIP 策略不一致，从而出现连接失败、分流错乱，或在极端环境下暴露你正在访问的域名意图。
因此，防泄漏的核心不是「把 DNS 写得越复杂越好」，而是让需要被规则处理的流量在解析阶段就与内核策略对齐。若你尚未安装图形客户端，可先完成基础环境：Windows 下 Clash Verge Rev 完整安装教程，再回头调整 dns 段；否则界面与配置文件对不上，很容易在「订阅覆盖」与「本地覆写」之间来回打架。
Meta 内核里，DNS 请求大致怎么走
在 Meta（Mihomo） 中，dns.enable 打开后，内核会尝试接管或参与本机 DNS 查询的调度：根据 enhanced-mode 选择 FakeIP 或 Redir-Host 等行为，再按 nameserver、proxy-server-nameserver、fallback 等列表决定向上游递归的方式。与旧版 Clash 相比，Meta 对 Sniffer、TUN、ebpf 等能力集成更完整，但语义不变：规则匹配的是「连接五元组 + 域名信息」，而域名信息往往来自解析或嗅探，任何一环偏离预期，日志里都会表现为「看似命中规则，实际行为不对」。
建议你在调 DNS 时同时打开连接日志，关注三类信息：查询是否由内核发出、返回的是 FakeIP 还是真实 IP、后续连接是否走了正确策略组。这比死记某个开关名称更能帮你定位问题。图形端安装与日常更新请统一通过 Clash 客户端下载页 获取，避免把「测试版安装包」与「源码仓库说明」混在同一入口。
FakeIP：为什么能减轻泄漏感，又要注意什么
FakeIP（enhanced-mode: fake-ip）的思路是：为需要代理的域名在本地分配一段私有地址（常见为 198.18.0.0/16），应用程序拿到的是「假 IP」，真正的域名到上游解析由内核在隧道内完成。这样对上层应用而言，解析结果已经与规则决策绑定，可减少「应用先拿到真实 IP 再直连」的路径依赖。
使用 FakeIP 时务必核对：fake-ip-range 不与局域网段冲突；若开启 Sniffer，要理解它与 FakeIP 的互补关系；某些局域网设备、游戏主机、老旧应用若硬编码了「非 FakeIP 期望」的解析方式，需要单独策略或改用 Redir-Host。关于主机侧拓扑与 DNS 预期，也可对照 Nintendo Switch / PS5 局域网代理方案 中的说明，避免「电脑防住了、主机仍绕路」。
Redir-Host 与「真实解析」场景
Redir-Host（enhanced-mode: redir-host）更偏向让内核按真实解析结果做连接，再配合规则做分流。它并非「落后模式」，在需要与内网解析、企业域或某些 P2P / 游戏场景对齐时反而更直观。代价是：你必须更认真地配置 nameserver 与 fallback，并确认没有程序在系统层抢先解析导致与规则不一致。
DoH 与 DoT：加密 DNS 上游怎么接入
DoH（DNS over HTTPS）与 DoT（DNS over TLS）把客户端到递归解析器之间的传输加密，降低链路侧窃听与篡改风险。在 Meta 配置中，通常以 https:// 或 tls:// 前缀写在 nameserver 或 fallback 列表中。二者没有绝对优劣：DoH 常走 443，穿透性相对友好；DoT 使用独立端口，策略上更容易与「普通 HTTPS 流量」区分。
实务上建议：主备分层——nameserver 放你信任且延迟可接受的加密上游；fallback 放备用；再配合 fallback-filter（如 GeoIP 判定、域名后缀过滤）避免国内域名误走境外递归。具体域名列表与策略请按自身网络调整，不必照搬社交平台上「一键最优」。
一份可对照的 dns 配置骨架（示例）
下面是一段教学用骨架，字段名遵循常见 Meta 配置习惯，请按你的订阅与客户端版本微调；若与机场模板冲突，以「能稳定启动 + 日志无持续报错」为优先，再逐项收紧。
dns:
enable: true
listen: 0.0.0.0:53
ipv6: false
enhanced-mode: fake-ip
fake-ip-range: 198.18.0.1/16
fake-ip-filter:
- "*.lan"
- stun.*.*
nameserver:
- https://dns.google/dns-query
- tls://one.one.one.one
fallback:
- https://dns.cloudflare.com/dns-query
fallback-filter:
geoip: true
geoip-code: CN
ipcidr:
- 240.0.0.0/4将示例中的上游地址替换为你信任的服务商；若使用机场提供的专用 DoH，请确认证书与 SNI 要求。更多关于 YAML 结构与订阅合并顺序，可结合 Subconverter 订阅转换完全指南 一起阅读，避免远程配置覆盖了你本地 DNS 段。
TUN 模式与 dns-hijack：堵住 53 端口旁路
仅当系统或应用的 DNS 查询真正进入内核监听的 DNS 模块时，上述策略才完整生效。开启 TUN 后，若仍有程序直接向路由器或运营商 DNS 发 UDP 53，就会出现「FakeIP 不生效」的典型症状。Meta 文档与社区实践里常建议在 TUN 配置中加入对 53 端口的劫持（如 tun.dns-hijack 指向 any:53 等写法，具体以你所用版本说明为准），让 DNS 查询回到内核处理。
完整 TUN 前置条件、驱动与权限说明见 Clash Verge Rev TUN 模式完整开启教程。请避免在未理解劫持范围的情况下叠多个虚拟网卡类软件，否则排错会非常痛苦。
提示：企业网络或校园网若对 DNS 有强制策略，盲目劫持可能导致内网域名解析失败。此时应为内网后缀配置 fake-ip-filter 或拆分 nameserver-policy，在「可访问性」与「隐私策略」之间取平衡。
验证思路：怎样确认「没有明显旁路」
没有单一网站能覆盖所有协议路径，但你可以用分层验证：先在客户端日志确认 DNS 查询由内核处理；再用浏览器访问公开 DNS 检测页（仅作参考）；最后对「最担心的应用」做针对性抓包或日志核对。若发现只有特定应用异常，优先查该应用是否自带 DNS 或 DoH、是否绕过系统代理。
与分流规则联动时，可阅读 ACL4SSR 与 Loyalsoldier 规则集对比，理解规则集如何依赖域名与 IP 数据；当 DNS 与规则来源不一致时，「换规则」往往解决不了「解析先行」的问题。
关于 GitHub：Mihomo / Meta 内核与各类图形客户端的源码、Issue 与变更说明在 GitHub 上公开，便于审计与反馈；这与「在哪下载已签名的桌面安装包」是两条线。若需了解实现细节可自行访问仓库；日常获取客户端安装包仍建议通过 本站下载页，与源码浏览入口分开使用。
小结
DNS 防泄漏的本质，是让解析路径、规则与隧道三者对齐：FakeIP 解决「连接决策与域名关系」的一致性，DoH/DoT 降低递归链路的明文风险，TUN 与 dns-hijack 则减少系统侧旁路。2026 年的 Meta 内核与主流客户端已能较好地把这些能力放在同一配置语境下管理，剩下的是按你的网络环境做可复现的取舍，而不是追逐玄学参数。
相比在论坛碎片里搜零散字段，用一款界面清晰、能同时管理订阅与 DNS 段的统一客户端，把 YAML 与图形面板对照着改，长期维护成本会低很多；当你能稳定复现自己的配置时，换机与排错都会轻松一截。