DNS 泄漏排查不是只看一次检测站，而是一条完整链路：ClashX 配置、系统网络栈、浏览器 DoH、结果复核。只要其中一层未统一，结论就会漂移。
什么才算 DNS 泄漏
只要 DNS 查询没有走预期代理链路，就是 DNS 泄漏。最典型场景是“出口 IP 在代理节点，但域名解析仍由本地运营商完成”。
DNS 泄漏本质是解析链路失控，而不是单纯网速问题。速度快慢不能直接证明是否泄漏，解析器身份才是关键。
| 检测结果 | 含义 |
|---|---|
| 出现本地 ISP DNS | 高概率泄漏，DNS 未被代理接管 |
| 出现代理地区 DNS | 通常正常，链路一致 |
| 同一时段多地 DNS 混合 | 多网卡并行或浏览器 DoH 干扰 |
| 浏览器与终端结论冲突 | 浏览器和系统在走不同解析路径 |
常见泄漏信号
- 切换节点后 DNS 身份不变。
- 出口 IP 在海外，DNS 仍是本地运营商。
- 刷新同一检测页，解析器地点来回跳。
- 终端命令正常，浏览器检测异常。
- 浏览器正常，终端却暴露本地 DNS。
ClashX 端关键配置
先确保 ClashX 这一层完整可用。多数泄漏来自 dns.enable 关闭、fallback 缺失或不可达、过滤条件未配置。
推荐配置（fake-ip）
dns:
enable: true
listen: 0.0.0.0:53
ipv6: false
enhanced-mode: fake-ip
fake-ip-range: 198.18.0.1/16
nameserver:
- https://223.5.5.5/dns-query
- https://119.29.29.29/dns-query
fallback:
- https://1.1.1.1/dns-query
- https://8.8.8.8/dns-query
fallback-filter:
geoip: true
geoip-code: CN
ipcidr:
- 240.0.0.0/4
domain:
- +.google.com
- +.github.com兼容配置（redir-host）
dns:
enable: true
listen: 127.0.0.1:53
enhanced-mode: redir-host
nameserver:
- 223.5.5.5
- 114.114.114.114
fallback:
- tls://1.1.1.1:853
- tls://8.8.8.8:853
fallback-filter:
geoip: true
geoip-code: CN1) dns.enable: false；2) 只配 nameserver 不配 fallback；3) fallback 地址不可达；4) 忘记 fallback-filter 导致回落系统 DNS。
fake-ip 防泄漏和性能更优，适合大多数常规使用；redir-host 兼容性更好，适合本地开发或特殊应用场景。
- 改配置后先重载，再做第一次检测。
- 切换两条不同地区节点做对照。
- 每次只改一个参数，记录结果。
系统网络层检查
ClashX 配置正确后，仍需验证系统 DNS 路径。macOS 在多接口并存时会出现解析优先级偏移，造成“偶发泄漏”的错觉。
关键命令
# 查看 DNS 解析器详情
scutil --dns
# 查看 Wi-Fi DNS
networksetup -getdnsservers Wi-Fi
# 查看以太网 DNS
networksetup -getdnsservers Ethernet
# 查看网络服务顺序
networksetup -listnetworkserviceorder
# 刷新缓存
sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder分步检查（建议照抄执行）
- 仅保留一个活跃网络接口，临时关闭其它网卡或 VPN 虚拟网卡。
- 固定 ClashX 节点，避免自动切换造成观察噪声。
- 执行
scutil --dns保存原始输出。 - 执行
networksetup -getdnsservers Wi-Fi对比系统配置。 - 清 DNS 缓存后再跑检测站，确认不是缓存命中。
- 记录时间、节点、结果，方便回滚对比。
Wi-Fi + 有线 + 企业安全客户端同时在线时，DNS 可能不按你想象的路径走。排查阶段先减变量，再逐项恢复。
浏览器 DoH 的影响
浏览器 DoH 可能直接绕过系统 DNS，导致“终端正常、浏览器异常”或反向冲突。排查阶段应统一关闭浏览器安全 DNS，先拿到稳定基线。
DoH 能防劫持，但也会引入独立解析路径。若你正在验证代理链路，一定先统一策略再测。
Chrome
- 打开
设置 → 隐私和安全性 → 安全。 - 找到
使用安全 DNS。 - 先关闭进行基线验证；验证后按需恢复。
Firefox
- 打开
设置 → 隐私与安全。 - 在 DNS over HTTPS 区域选
关闭。 - 重启浏览器并重新检测。
Edge
- 打开
设置 → 隐私、搜索和服务。 - 关闭
使用安全 DNS。 - 复测后再决定是否恢复。
终端显示正常解析器，浏览器却固定显示公共 DoH 供应商。此时优先排查浏览器，不要急着改 ClashX。
验证脚本与记录模板
防泄漏必须有可重复记录。下面的模板适合直接贴进工单或团队文档，方便复盘和交接。
终端验证脚本
date
echo "Node: ______"
echo "Mode: Rule/Global"
scutil --dns > /tmp/clashx-dns-check.txt
networksetup -getdnsservers Wi-Fi >> /tmp/clashx-dns-check.txt
echo "Visit: https://dnsleaktest.com"
echo "Visit: https://ipleak.net"
echo "Visit: https://browserleaks.com/dns"
echo "Expected Region: ______"
echo "Observed Region: ______"
echo "Leak? Yes/No"记录模板
【DNS 泄漏验证记录】
日期：
系统版本：
ClashX 版本：
模式：fake-ip / redir-host
节点：
系统层：
- scutil --dns：
- networksetup：
浏览器层：
- Chrome DoH：开/关
- Firefox DoH：开/关
- Edge DoH：开/关
检测层：
- dnsleaktest.com：
- ipleak.net：
- browserleaks.com：
结论：
- 是否泄漏：
- 判定依据：
- 改动项：
- 回滚点：标准验证流程
- 固定节点，关闭浏览器 DoH，记录系统 DNS。
- 跑两个检测站，保存截图。
- 切换节点后重复，观察解析器是否随节点变化。
- 如冲突，逐项恢复变量（DoH、多网卡、企业软件）。
- 最终沉淀“可复现的无泄漏基线”。
常见误判
误判往往比问题本身更耗时。先排除以下三类，再动配置。
高延迟和丢包会让体验变差，但不能直接证明 DNS 泄漏。要看解析器身份和路径一致性。
CDN 回源策略会导致地区显示偏差。只看“地区标签”容易误判，需结合出口 IP 与 DNS 列表。
零信任客户端、终端防护或公司网关可能改写 DNS。此类问题应优先在系统层定位，而不是反复改节点。
同时核对系统 DNS、浏览器 DoH、检测站解析器、代理出口 IP，四项一致再下结论。
常见问题 FAQ
Q1：什么是 DNS 泄漏？
A：DNS 查询绕过了你的代理解析链路，被本地系统或浏览器直接发出。即使出口 IP 正常，也可能暴露访问目标。
Q2：fake-ip 和 redir-host 哪个更安全？
A：多数场景下 fake-ip 更容易实现稳定防泄漏，redir-host 更偏兼容。建议先 fake-ip 建基线，再按业务兼容性调整。
Q3：为什么关闭系统 DNS 仍会泄漏？
A：常见原因是浏览器 DoH 仍启用，或企业安全软件接管 DNS。必须做系统层和浏览器层双重排查。
Q4：DoH 和 DoT 有什么区别？
A：DoH 走 HTTPS（通常 443），DoT 走 TLS（通常 853）。两者都会引入额外解析路径，排障时都要统一管理。
Q5：如何在终端验证 DNS？
A：用 scutil --dns 和 networksetup -getdnsservers Wi-Fi 先看系统层，再与检测站结果交叉验证。
Q6：为什么不同检测站结论不一样？
A：探测节点、缓存机制、展示逻辑都不同。建议至少双站验证并记录时间、节点、浏览器设置。
总结
DNS 防泄漏的正确姿势是“先统一链路，再验证，再记录”。只要你把 ClashX、系统网络和浏览器策略纳入同一检查清单，结果就能稳定可复现。