OpenWrt + OpenClash DNS 泄漏完整排查与最终配置记录
前言
这篇文章记录一次 OpenWrt + OpenClash 环境下的 DNS 泄漏排查全过程，并整理出最终稳定可复用的配置思路，方便路由重装后快速恢复。
本文只保留最终确认有效的步骤，删除中途误判、绕路和无效尝试，目标是：
- 消除
ipleak.net检测中的 DNS 泄漏 - 保留 OpenClash 正常代理能力
- 尽量兼容 IPv6
- 保持配置简单，避免后期再次踩坑
一、问题现象
最开始的表现是这样的：
ipleak.net检测中出现多个中国 DNS- 检测结果里经常出现中国电信 IPv4 / IPv6 DNS 地址
- 即使 OpenClash 配置里已经使用了
1.1.1.1/8.8.8.8这类上游 DNS，仍然会看到中国 DNS - 浏览器关闭“安全 DNS”后，泄漏依旧存在
- Windows 电脑上 DNS 看起来已经是路由器地址，但检测结果还是有国内 DNS
这说明问题不一定在浏览器，也不一定在客户端本机，而更可能出现在路由器实际使用的上游 DNS 链路中。
二、最终定位结论
经过 OpenClash 日志、LAN 抓包、WAN 抓包交叉验证，最终确认：
1）客户端本身没有直接把 ipleak 查询发到外部 DNS
客户端对 ipleak.net、ipv4.ipleak.net、ipv6.ipleak.net、fallback-ipv6.ipleak.net 等域名的查询，都是先发给路由器 192.168.1.1:53。
也就是说：
- 电脑没有直接去查外部 DNS
- 电脑本机不是这次
ipleak泄漏的直接根因 - 客户端到路由器这段链路基本正常
2）ipleak.net 网站访问本身已经走代理
OpenClash 日志显示：
ipleak.net:443ipv4.ipleak.net:443
都已经通过 OpenClash 代理组走新加坡节点出站。
这说明：
- 网站主站访问路径本身不是问题
- “网页访问直连导致检测异常”这一条可以排除
3）真正的泄漏发生在路由器上游 DNS
WAN 抓包最终抓到关键证据：
路由器在查询 ipleak.net 相关测试域名时，实际把 DNS 请求发给了：
202.100.192.68:53
这个地址属于中国电信 DNS。
也就是说，真正的问题不是 OpenClash 主站访问没代理，而是：
路由器拿到客户端 DNS 请求之后，并没有统一走我们以为的上游 DNS，而是有一部分查询仍然走了运营商自动下发的 DNS。
4）最终根因
OpenWrt 的 WAN 口启用了“自动获取 DNS 服务器”。
只要这个选项开着，系统就可能把运营商下发的 DNS 写入自动配置文件，然后被某一层解析组件继续读取，最终造成 DNS 泄漏。
关闭它之后，测试恢复正常，泄漏消失。
三、最终正确思路
本次最终采用的思路不是“拼命加更多 DNS”，而是：
核心原则
- WAN 不再自动接收运营商 DNS
- 客户端统一只问路由器
- 路由器自己的 DNS 上游必须手工指定
- OpenClash / AdGuard Home / dnsmasq 三者不要互相混乱继承系统 DNS
- 能少写 policy 就少写，先保持链路简单稳定
- 先解决 DNS 泄漏，再考虑 IPv6 共存
四、最终推荐配置
4.1 OpenWrt WAN 设置
路径：
网络 -> 接口 -> WAN -> 编辑 -> 高级设置
必改项
- 自动获取 DNS 服务器：关闭
说明
这是整次排查中最关键的一项。
如果这一项打开，运营商 DNS 可能会被写入系统自动 DNS 文件，然后被 dnsmasq、某些服务、或者系统链路读取，从而导致 DNS 泄漏。
建议
关闭“自动获取 DNS 服务器”之后：
- 不要再让系统自由继承运营商 DNS
- 如果路由器自身还需要 DNS，可手工指定干净的公共 DNS
- 更推荐由 AdGuard Home 或 OpenClash 统一管理上游 DNS
4.2 LAN 与客户端 DNS 思路
客户端侧的原则很简单：
- 客户端 DNS 只使用路由器地址，例如
192.168.1.1 - 不让客户端自行拿到运营商 DNS
- 不让客户端绕过路由器去访问外部 53 端口
Windows 客户端建议
- IPv4 DNS：填
192.168.1.1 - 不使用运营商手工 DNS
- 浏览器关闭“安全 DNS”
- 如果有安全软件、优化软件、国产联网组件，尽量留意是否存在独立 DNS 行为
说明
本次抓包证明客户端对 ipleak 测试域名本身是先问 192.168.1.1 的，这才是正确状态。
4.3 OpenClash DNS 设置
OpenClash 这一部分建议保持简单、明确、可控。
已验证稳定的思路
- 使用 OpenClash 自身 DNS
- 上游 DNS 只保留可信公共 DNS
- 不追加运营商 DNS
- 不混用复杂的 fallback
- 不随意增加 nameserver-policy
推荐方向
dns:
enable: true
listen: 0.0.0.0:7874
ipv6: false
enhanced-mode: fake-ip
respect-rules: false
use-hosts: true
default-nameserver:
- 1.1.1.1
- 8.8.8.8
nameserver:
- tls://1.1.1.1
- tls://8.8.8.8
fallback: []
说明
这套思路的重点在于：
- 上游 DNS 足够少
- 不再让运营商 DNS 混进来
fallback为空，避免多条链路并行后更难排查respect-rules: false保持 DNS 处理链更干净
不建议做的事
- 不要开启会把系统 DNS 混进来的“追加上游 DNS”类功能
- 不要轻易写很多
nameserver-policy - 不要把“自定义上游 DNS”和系统 DNS 混用
- 不要一边用 AGH，一边又让 dnsmasq 和系统自己递归，各走各的
4.4 关于 nameserver-policy
后续曾考虑过添加这样的内容：
nameserver-policy:
ce.ganzi.cc.cd:
- "https://doh.ganzi.cc.cd/ganzi"
cloudflare-ech.com:
- "https://doh.ganzi.cc.cd/ganzi"
最终建议
不是必须项。
什么时候才建议加
只有当你明确遇到以下情况时，才考虑加：
ce.ganzi.cc.cd解析不稳定cloudflare-ech.com相关握手失败- 某些特定节点必须依赖单独 DNS 才能正常工作
为什么默认不加
因为当前最重要的是保持 DNS 链路简单稳定。
一旦写了 nameserver-policy，虽然只影响指定域名，但也会让 DNS 链条更复杂，后期排查问题会更麻烦。
注意
如果要写进 YAML，必须写普通字符串，不能写成 Markdown 链接形式。
正确写法如下：
nameserver-policy:
ce.ganzi.cc.cd:
- "https://doh.ganzi.cc.cd/ganzi"
cloudflare-ech.com:
- "https://doh.ganzi.cc.cd/ganzi"
4.5 AdGuard Home 设置思路
如果使用 AdGuard Home，必须注意：
AGH 的上游 DNS 必须手工指定，不能继承系统 DNS。
路径：
AdGuard Home -> 设置 -> DNS 设置
建议
上游 DNS 服务器：手工填写可信 DoH / DoT- 不要留空
- 不要继承系统 DNS
- 不要让它回落到 WAN 自动获取的 DNS
推荐思路
例如：
tls://1.1.1.1tls://8.8.8.8
或者对应的 DoH。
说明
本次排查中，AGH 查询日志并不是最终定位根因的关键证据。
真正抓到问题的是 WAN 抓包。
这也说明：
- AGH 日志可以辅助观察
- 但不能完全替代抓包
- 看到
127.0.0.1 / localhost也不代表真正上游就是本机 - 真正有没有走运营商 DNS，还是要看 WAN 出口抓包
4.6 OpenClash 的 IPv6 相关设置
在 OpenClash 插件设置中，后续还遇到两个选项：
IPv6 流量代理允许 IPv6 类型 DNS 解析
最终建议
对于本次这类场景，优先建议：
- 不要开启
IPv6 流量代理 - 如需恢复 IPv6 域名解析，可开启
允许 IPv6 类型 DNS 解析
理由
当前主要目标是：
- 保持 DNS 无泄漏
- 尽量保留 IPv6 可用性
- 不把 IPv6 整条代理链搞复杂
如果直接开启 IPv6 流量代理，前提是：
- 节点本身支持 IPv6
- OpenClash / Mihomo 配置完整支持 IPv6 出站
- 整个链路已经确认稳定
否则容易引入新的问题。
实际建议
- 想要稳：先不开 IPv6 流量代理
- 想恢复 AAAA 解析：可以尝试只开“允许 IPv6 类型 DNS 解析”
- 改完后再次测试是否影响 DNS 泄漏结果
4.7 IPv6 共存建议
在本次排查中，最终确认一点：
IPv6 是否存在，并不等于一定泄漏；真正关键的是 DNS 链路是否干净。
推荐目标
- 保留原生 IPv6 地址能力
- 不向客户端通告运营商 IPv6 DNS
- 客户端仍然只使用
192.168.1.1作为 DNS - 路由器自己的上游 DNS 使用手工指定的干净 DNS
如果只想要最稳结果
最简单的策略是：
- DNS 先完全修干净
- IPv6 暂时只保留基础能力
- 之后再逐步恢复 AAAA 解析和原生 IPv6 访问
五、重装后推荐恢复顺序
如果路由器重装，建议按下面顺序恢复，不要一上来全开：
第一步：恢复基础网络
- 配好 WAN 拨号
- 先确认能正常上网
- 先不要折腾复杂 DNS 分流
第二步：第一时间关闭 WAN 自动获取 DNS
路径：
网络 -> 接口 -> WAN -> 编辑 -> 高级设置
- 关闭：
自动获取 DNS 服务器
这一步要尽早做。
第三步：恢复 OpenClash
- 导入配置文件
- 确认 OpenClash 正常启动
- 检查最终生成配置中的 DNS 段是否符合预期
第四步：只保留干净上游 DNS
建议：
1.1.1.18.8.8.8- 或你自己确认干净稳定的 DoH / DoT
第五步：客户端 DNS 统一指向路由器
例如：
- Windows DNS ->
192.168.1.1
第六步：关闭浏览器安全 DNS
包括：
- Edge
- Chrome
- Firefox（若启用了 DoH）
第七步：验证无泄漏后，再慢慢恢复 IPv6
顺序建议：
- 先确认 DNS 无泄漏
- 再确认主站访问路径正常走代理
- 再恢复 AAAA 解析
- 最后才考虑 IPv6 流量代理
六、重装后验证方法
建议每次只做最小化验证，不要同时开很多页面。
1）先看 OpenClash 日志
验证以下域名是否走代理：
ipleak.netipv4.ipleak.net
如果这两个走了代理，说明主站访问路径正常。
2）再看 DNS 是否还走运营商
必要时抓 WAN 包，重点看有没有出现：
202.100.192.68:53
只要这类地址再次出现，就说明路由器某一层又读回了运营商 DNS。
3）看客户端 DNS 是否仍只发给路由器
抓 LAN 包时，客户端正确行为应当是：
192.168.1.x -> 192.168.1.1:53
而不是：
- 客户端直接访问外部
x.x.x.x:53
4）最终再用 ipleak.net 复测
理想状态：
- 主站 IP 为代理出口
- DNS 不再出现中国电信 DNS
- 不再出现运营商 IPv6 DNS
- 若保留 IPv6，则仅在你预期范围内出现
七、常见坑位总结
1）WAN 自动获取 DNS 没关
这是本次真正的根因，也是最关键的坑。
2）以为 OpenClash 配了公共 DNS 就万无一失
实际上如果系统层仍在读取运营商 DNS，仍然会泄漏。
3）只看浏览器，不看路由器出口
浏览器安全 DNS 只是其中一层，真正的根因可能在路由器上游。
4）只看 AGH 日志，不抓 WAN
AGH 日志有帮助，但最终是否真的走了运营商 DNS，WAN 抓包最直接。
5）过早折腾 IPv6 代理
IPv6 没完全理顺前，先把 DNS 泄漏修好更重要。
6）DNS policy 写太多
nameserver-policy 不是越多越好。
能不用就不用，先保持稳定。
7）配置里写 Markdown 链接
YAML 中必须写普通字符串，不能写博客里的 Markdown 链接格式。
八、我的最终稳定策略
这次排查后，我最终采用的策略是：
- WAN 关闭自动获取 DNS
- 客户端 DNS 统一指向路由器
- OpenClash DNS 只保留少量干净上游
- 不追加运营商 DNS
- 不乱加
nameserver-policy - 先不启用 IPv6 流量代理
- 若要保留 IPv6，优先恢复 AAAA 解析，不急着代理 IPv6 流量
一句话总结就是：
先把 DNS 链路彻底收干净，再谈 IPv6 共存和更复杂的分流。
九、重装后快速检查清单
下面这份可以直接照着核对：
OpenWrt
- WAN 已关闭“自动获取 DNS 服务器”
- 没有再继承运营商 DNS
- 客户端 DNS 统一走路由器
OpenClash
- DNS 已启用
- 上游 DNS 为手工指定
-
fallback未乱填 - 未启用会混入系统 DNS 的功能
- 未乱加
nameserver-policy
AdGuard Home（如使用）
- 上游 DNS 已手工填写
- 未继承系统 DNS
- 未回落到运营商 DNS
客户端
- DNS 指向
192.168.1.1 - 浏览器安全 DNS 已关闭
- 无明显第三方软件直连外部 53 端口
验证
-
ipleak.net主站出口正常 - 无中国 DNS 泄漏
- WAN 抓包无
202.100.192.68:53
十、结语
这次排查最重要的收获，不是改了多少参数，而是确认了一件事：
DNS 泄漏往往不是“配置文件看起来写对了就一定没问题”，而是要看实际出口到底发给了谁。
只要抓住这条线，很多看起来很复杂的问题，最后都会变得非常明确。
