OpenClash DNS泄漏怎么解决：按链路排查、修复与验证
简答：先不要看到 198.18.x.x 就判定 DNS 泄漏：OpenClash 的 Fake-IP 模式本来就可能返回 198.18.0.1/16。正确做法是确认客户端的 DNS 请求是否经过路由器、dnsmasq 和 OpenClash，再排查 IPv6、浏览器安全 DNS、Android 私人 DNS 及其他本地 DNS 服务绕过。
定义：OpenClash DNS 泄漏，是指客户端的域名解析请求绕过预期的 OpenClash DNS 链路，直接发送给运营商、客户端手动指定的 DNS 或其他未纳入策略的解析服务。
先试这一步：确认是不是把 Fake-IP 当成了泄漏
如果检测结果显示某个域名返回 198.18.x.x，这通常只能说明 OpenClash 正在使用 Fake-IP 地址池，不能单独证明 DNS 泄漏。OpenClash 当前默认配置文件将 Fake-IP 地址段写为 198.18.0.1/16，同时支持 fake-ip 和 redir-host 两种增强模式，具体以当前生成配置为准。可查看OpenClash 默认配置核对字段。
- 在路由器后台确认 OpenClash DNS 功能处于启用状态。
- 确认局域网设备的首选 DNS 是路由器 LAN 地址，而不是外部 DNS 地址。
- 分别测试普通域名和代理相关域名，不要只看一次在线检测结果。
- 只有当客户端实际把 DNS 请求发往路由器之外，或 OpenClash 未接收到该请求时，才进入泄漏修复流程。
| 现象 | 更可能的含义 | 下一步 |
|---|---|---|
| 返回 198.18.x.x | Fake-IP 正常工作 | 检查请求路径，不要直接判定泄漏 |
| 客户端 DNS 显示外部地址 | 客户端手动 DNS、浏览器或应用绕过 | 关闭覆盖设置并重新获取网络配置 |
| IPv4 正常、IPv6 检测异常 | IPv6 RA、DHCPv6 或 IPv6 DNS 未纳入策略 | 暂时关闭 IPv6 验证，或补齐 IPv6 代理和 DNS 配置 |
| 改完后只有部分设备正常 | 设备缓存或设备级 DNS 设置不同 | 逐台清缓存并检查 DNS 配置 |
按正确链路逐层检查
理想链路应是：客户端 → 路由器 LAN 地址或 dnsmasq → OpenClash DNS 监听端口 → 配置中的上游 DNS。OpenWrt 默认使用 dnsmasq 提供 DNS 转发和 DHCP 服务，配置主要位于 /etc/config/dhcp；可参考OpenWrt dnsmasq 文档。
- 检查客户端：确认设备通过 DHCP 获得路由器地址作为 DNS。删除手动填写的 DNS，关闭会覆盖系统解析的浏览器或应用设置后重新连接 Wi-Fi。
- 检查 dnsmasq：确认 dnsmasq 没有继续直接使用 WAN 下发的 DNS 作为最终解析出口，也没有被其他 DNS 服务接管 53 端口。
- 检查 OpenClash：确认 DNS 监听地址、增强模式、上游 nameserver 和本地 DNS 劫持设置彼此匹配。OpenClash 的配置覆写文件明确区分 Dnsmasq Redirect、Firewall Redirect 和禁用三种 DNS 重定向方式，详见OpenClash 配置覆写参数。
- 检查上游：不要同时让多个组件各自承担最终解析。SmartDNS、AdGuard Home、mosdns 与 OpenClash 共存时，先确认谁监听 53 端口，其他服务改用明确的备用端口，再让 OpenClash 只连接一个清晰的上游链路。
如果可以 SSH 登录路由器，可分别执行以下基础查询，比较不同入口返回的服务器信息；其中地址请替换为你的路由器 LAN 地址和实际 DNS 监听地址：
nslookup example.com 192.168.1.1nslookup example.com 127.0.0.1
两次查询结果不能单独证明“没有泄漏”，但可以帮助判断请求是否经过预期的本地 DNS 入口。若客户端查询结果与路由器本地查询明显不同，优先检查客户端自定义 DNS、浏览器安全 DNS或应用内置解析。
OpenClash DNS 劫持方式怎么选
OpenClash 当前源码将 DNS 重定向分为 Dnsmasq Redirect 和 Firewall Redirect，并保留禁用选项。不要只按别人的截图照搬，先确认你的网络结构是主路由、旁路由还是多 DNS 服务共存。
| 环境 | 优先检查 | 处理思路 |
|---|---|---|
| OpenClash 运行在主路由 | 客户端 DHCP、dnsmasq 和 53 端口 | 让客户端统一使用路由器 DNS，再选择一种重定向方式 |
| OpenClash 运行在旁路由 | 主路由 DHCP、网关和 DNS 是否仍指向主路由 | 确认客户端的 DNS 请求确实到达旁路由 |
| SmartDNS、AdGuard Home 或 mosdns 占用 53 | 监听端口和转发方向 | 避免两个服务同时抢占 53 端口，明确唯一入口 |
| 使用 Fake-IP | Fake-IP 过滤列表和非 Fake-IP 域名 | 只对确有兼容性需求的域名加入过滤，修改后重新生成配置 |
| 使用 Redir-Host | 域名解析结果与规则分流 | 确认解析结果没有被客户端或其他 DNS 服务提前固定 |
OpenClash 的配置界面还包含 Fake-IP 过滤模式、上游 DNS、Fallback-Filter、IPv6 DNS 和 DNS 重定向等独立选项。修改前建议导出当前配置或保存截图；每次只改一组设置，验证失败时先恢复上一组设置。
IPv6、浏览器和手机设置造成的绕过
OpenWrt 支持 DHCPv6 客户端、RA/DHCPv6 服务和 IPv6 防火墙，因此即使 IPv4 链路正常，IPv6 仍可能形成另一条 DNS 路径。可参考OpenWrt IPv6 配置文档检查 RA、DHCPv6 和 IPv6 DNS 通告。
- 在一台测试设备上暂时关闭 IPv6，重新检测。如果问题消失，重点检查 IPv6 DNS 通告、OpenClash IPv6 DNS 和 IPv6 代理模式。
- 如果不需要 IPv6，先在路由器或局域网 DHCP 配置中关闭相关通告，再重连设备验证。
- 如果需要 IPv6，必须让 IPv6 DNS 和 IPv6 流量进入同一套可验证的策略，不要只修 IPv4。
- Android 检查“私人 DNS”。如果设备被设置为指定主机名，它可能不再使用路由器下发的普通 DNS。
- Chrome 检查“使用安全 DNS”。Google 说明 Chrome 的安全 DNS 可使用加密解析，并允许自定义服务商；排查时可暂时关闭该功能，再与开启状态对比，相关路径见Chrome Android 安全设置。
修改后如何验证与回滚
- 保存当前 OpenClash、DHCP、IPv6 和其他 DNS 服务配置。
- 只修改一个变量，例如先关闭客户端手动 DNS，再测试；不要同时切换 Fake-IP、IPv6 和 DNS 劫持。
- 重启或重新加载 OpenClash、dnsmasq 以及实际参与解析的 DNS 服务。
- 让测试设备断开并重新连接网络，清理系统 DNS 缓存；浏览器也要完全退出后重新打开。
- 分别在路由器、Windows/macOS 和手机上查询同一域名，记录 DNS 服务器、返回地址和是否出现超时。
- 使用至少两个网络环境或两台设备复测。若只有某一台设备异常，优先处理该设备的浏览器、VPN、私人 DNS 或应用级设置。
回滚标准是：恢复上一次保存的配置，重新加载相关服务，并确认局域网设备可以正常解析。不要为了让某个检测网站显示“通过”而永久关闭 IPv6 或删除所有 DNS 分流规则；应以实际网络结构和可重复的查询结果为准。
安全提醒
- 不要把在线 DNS 检测页面的一次结果当成完整证据，尤其不要把 198.18.x.x 自动判定为泄漏。
- 不要同时启用多个未知来源的 DNS 重写、Hosts、Fallback 和过滤规则，否则出现异常后很难定位。
- 不要直接复制与当前 OpenClash、OpenWrt 或内核版本不一致的完整配置；字段和界面可能已经变化。
- 修改前保留备份，修改后记录每一步变化，出现断网时优先回滚最近一次改动。
常见问题
看到 198.18.0.1 就是 DNS 泄漏吗？
不是。它可能是 Fake-IP 地址池中的返回地址。需要继续确认 DNS 请求实际发往哪里，以及该请求是否绕过了 OpenClash。
关闭 Fake-IP 能彻底解决泄漏吗？
不能。Fake-IP 只是解析模式，真正泄漏可能来自客户端手动 DNS、IPv6、浏览器安全 DNS或其他本地 DNS 服务。
为什么路由器测试正常，手机测试仍然异常？
手机可能启用了私人 DNS、浏览器安全 DNS、应用内置 DNS 或缓存。先关闭这些覆盖项，重新连接 Wi-Fi 后再测。
主路由和旁路由场景有什么不同？
主路由通常负责 DHCP、网关和 DNS；旁路由则可能只负责部分流量。旁路由场景必须确认客户端的 DNS 请求确实到达运行 OpenClash 的设备。
SmartDNS、AdGuard Home 和 mosdns 能否同时使用？
可以共存，但必须明确监听端口和转发方向。先确定谁是唯一的最终 DNS 入口，避免多个服务同时占用 53 端口或互相循环转发。
是否应该直接关闭 IPv6？
如果当前没有 IPv6 使用需求，可以暂时关闭作为诊断手段；如果依赖 IPv6，则应补齐 IPv6 DNS 和流量策略，而不是把临时关闭当成最终方案。
常见问题
看到 198.18.0.1 就是 DNS 泄漏吗？
不是。198.18.0.1/16 可能是 OpenClash Fake-IP 地址池，必须结合实际 DNS 请求路径判断。
关闭 Fake-IP 能彻底解决泄漏吗？
不能。泄漏也可能来自客户端手动 DNS、IPv6、浏览器安全 DNS或其他 DNS 服务。
为什么路由器正常，手机仍然检测异常？
手机可能启用了私人 DNS、浏览器安全 DNS或应用级解析，也可能仍在使用旧缓存。
旁路由场景如何确认请求经过 OpenClash？
检查客户端 DHCP 获得的 DNS 地址，并在旁路由与客户端分别查询同一域名，对比请求入口和结果。
SmartDNS、AdGuard Home 和 mosdns 能一起运行吗？
可以，但要明确 53 端口的唯一入口、各服务监听端口及转发方向，避免端口冲突或循环转发。
是否应该永久关闭 IPv6？
不一定。关闭 IPv6可以作为定位步骤；如果业务依赖 IPv6，应配置完整的 IPv6 DNS 和流量策略。