OpenClash 开启 IPv6 后节点域名解析失败？DNS 分层排查指南

先识别是“节点域名”还是“访问域名”失败

开启 IPv6 后“所有节点变红”并不等同于 IPv6 节点不可用。第一步要区分两个名称解析对象：代理服务器本身可能以 node.example.com 形式出现在配置里，内核必须先把它解析成 IP 才能建立隧道；浏览器访问的目标域名，则在隧道建立前后按当前 DNS 与规则处理。前者失败时，任何业务网站都可能表现为节点超时；后者失败时，已有节点连接可能仍然正常。

查看 OpenClash 的内核日志，寻找代理服务器域名、lookup、no such host、超时或 DNS 请求去向。不要把真实节点域名和订阅令牌贴到公开论坛。可把域名替换成占位符，同时保留错误类型、OpenClash 版本、路由器系统版本和复现步骤。

关键边界：dns.ipv6: false 影响 Mihomo 对 AAAA 查询的回答，但不能替代路由器自身的 IPv6、上游 DNS 和节点域名引导解析检查。

保存配置并采集一组可比较结果

先导出 OpenClash 配置与覆写，记录启用 IPv6 前后唯一发生变化的开关。不要同时切换 Fake-IP/Redir-Host、TUN、SmartDNS 和多组上游。重启 OpenClash 后保存首次错误日志，因为不断刷新配置可能覆盖最有价值的启动阶段信息。

记录路由器 WAN 与 LAN 是否都获得预期 IPv6 地址和默认路由。
在路由器上分别查询节点域名的 A 与 AAAA 记录。
指定当前 IPv4 DNS 和 IPv6 DNS 各查询一次，比较是否超时或返回异常。
确认内核启动前后查询结果是否改变。
只临时关闭 OpenClash 的 IPv6 DNS 接管，观察节点解析是否恢复。

nslookup node.example.com 可以作为基础观察，但不同 BusyBox 版本的参数不完全相同。重点是比较“同一个域名、同一个上游、开启前后”的结果，而不是把任意公共 DNS 的一次成功当成完整结论。

检查 default-nameserver 与 proxy-server-nameserver

Mihomo 的 default-nameserver 用于解析后续 DNS 服务地址等引导任务，官方说明要求使用 IP 形式的服务器；proxy-server-nameserver 则专门用于解析代理节点的域名。若节点域名只能依赖一个还没有建立的代理才能解析，就形成“先有节点还是先有 DNS”的循环依赖。

YAMLdns:
  enable: true
  ipv6: true
  default-nameserver:
    - 1.1.1.1
    - 8.8.8.8
  proxy-server-nameserver:
    - https://1.1.1.1/dns-query
  nameserver:
    - https://dns.google/dns-query

这只是字段关系示例，不代表这些上游在你的运营商网络一定可达。先选能从路由器直连访问、不会依赖当前代理的引导 DNS，再配置节点专用解析。若使用加密 DNS 域名，其自身仍需被引导解析。修改 LuCI 选项或覆写后，应查看最终生成配置，而不是只看页面表单。

核对 IPv6 DNS 上游与劫持路径

IPv6 启用后，路由器可能从 ISP 获得 IPv6 DNS，LAN 客户端也可能通过 RA/DHCPv6 学到新的解析器。SmartDNS、dnsmasq、OpenClash 和客户端私人 DNS 若同时存在，请求可能经过与 IPv4 完全不同的路径。先画清“客户端 → 路由器端口 → 本地 DNS 服务 → 上游”的实际链路，再决定在哪一层抓日志。

检查对象	典型问题	验证方式
IPv6 上游 DNS	路由或防火墙不通	指定该服务器查询 A/AAAA
节点域名解析	循环依赖代理	使用可直达的专用上游
LAN 客户端	绕过路由器 DNS	检查 RA、私人 DNS 与抓包
Fake-IP 返回	被不应接管的本机查询获得	对比内核启停前后的响应

暂时关闭某一层的 IPv6 DNS 代理可以用于定位，但不应直接写成永久答案。若关闭后恢复，应继续确定是上游不可达、53 端口被错误劫持、Fake-IP 进入了路由器本机解析，还是规则遗漏。确认原因后只修复对应链路。

如何看待 v0.47.133 的已报告问题

OpenClash 官方仓库的 Issue #5251 报告了一个具体环境：OpenClash v0.47.133 与特定 ImmortalWrt 版本下，路由器本机发往公网 IPv6 DNS 的请求被规则接管并返回 Fake-IP，随后导致代理节点域名解析失败。该问题单已经关闭。它能证明“IPv6 DNS 劫持可能影响节点解析”这一故障路径，但不能证明所有 OpenClash 版本、所有固件或所有 IPv6 故障都有同一根因。

如果你的版本、日志和数据包路径与报告不一致，不要照搬 issue 中的临时改法。先检查当前发布说明、最终防火墙规则与维护者结论；若能稳定复现，再用不含密钥的最小配置提交问题。仅凭“开启 IPv6 后坏了”不足以判断是 OpenClash 回归、固件网络栈、ISP DNS 还是自定义覆写。

不要长期依赖手改生成规则：OpenClash 重启或升级可能重建防火墙与 DNS 配置。未经维护者确认的临时修改应保留记录，并准备回退。

恢复顺序与最终验收

完成修改后，先重启 DNS 服务，再重启 OpenClash 内核，避免旧缓存掩盖结果。依次确认：路由器能用指定引导 DNS 解析节点域名；代理节点能建立连接；普通 A 与 AAAA 查询返回符合配置；LAN 客户端没有绕过预期解析器；规则模式下直连与代理目标都正常。最后再恢复 SmartDNS 或其他高级组件，每次只加一层。

当前字段与注释可对照 OpenClash 官方 default.yaml及 Mihomo DNS 文档。版本特定案例见 OpenClash Issue #5251，引用时应保留其版本与固件边界。

真正的完成标准不是“关掉 IPv6 就能用”，而是能够说明哪类 DNS 请求走哪条链路、节点域名不再依赖尚未建立的代理，并且重启路由器后仍可复现正确结果。

官方来源与版本边界

版本号、文件名和界面文字可能随项目更新而变化，操作前请以链接中的项目文档为准。