为什么「打开 IPv6」反而让一些站变得难访问
在双栈网络里，解析器通常会同时返回 IPv4（A） 与 IPv6（AAAA）。浏览器或系统栈在 Happy Eyeballs 一类机制下，可能优先尝试 IPv6：如果你的 IPv6 上游路由不完整——例如光猫发了前缀但海外方向的 v6 本身不通、或你的代理节点对目标域名的 v6 路径质量很差——表面现象就是首开慢、卡死、或直接超时，而同一站点在只走 IPv4 时又正常。
Clash Meta 这一层还会叠加：规则是基于连接五元组与域名信息做决策的，而域名信息可能来自本地 DNS、FakeIP 或 Sniffer。当你把 dns.ipv6 打开、又在外层打开了「优先 v6」类开关时，内核拿到的地址族、应用实际拨号使用的地址族、以及规则里写的 GEOIP / IPCIDR 有可能短暂不一致——日志里表现为「看似命中了规则，握手却完不成」。这与单纯「把 DNS 加密」不是同一类排错，因此在读过 Meta 内核 DNS 防泄漏总览 之后，仍需要单独理解 IPv6 的分支路径。
先把现象归类：解析异常还是链路异常
建议准备两类最小对照：同一域名在关闭 IPv6 相关开关后是否立即恢复；以及在日志里该连接的目标地址是 v4 还是 v6。Mihomo 连接面板或日志里若能直接看到目标 IP 的版本，往往能省掉一半猜测。若只有「DNS 查询失败」而没有后续 TCP，则优先怀疑 nameserver、fake-ip-filter、或 dns-hijack 与系统解析打架；若 DNS 已成功、长时间卡在连接阶段，则更偏向出口 / 节点 / IPv6 路径。
图形端若同时开了 系统代理 与 TUN，请确认没有多份软件重复接管——这一点与 Clash Verge Rev TUN 模式教程 中的前置说明一致：栈一乱，IPv6 更容易「走错门」。
1核对 dns.ipv6：是否真的需要 AAAA
在配置树的 dns: 段，ipv6 控制内核是否为适用域名发起 AAAA 查询。若你暂时只想验证「是不是 AAAA 惹祸」，可以把它关回 false，观察问题站点是否立刻恢复——这是可逆实验，不是让你永久关 IPv6，而是帮助确认因果方向。
dns:
enable: true
ipv6: false # temporary A/B: set true only after path is healthy
# ... nameserver / enhanced-mode ...
若关断 dns.ipv6 后问题消失，下一步再回头检查：你的递归上游是否返回了「空泛或质量差」的 AAAA、以及策略组走的节点是否真的适合双栈目的地。不要把「关 AAAA」当成最终方案，除非你的网络环境客观上只能稳定用 v4。
2prefer-ipv6 与图形端「优先 IPv6」
不同客户端把「拨号时偏好 AAAA」暴露在 UI 上的名字不一，有些对应配置里的 prefer-ipv6 语义：当同一主机名同时有 A 与 AAAA 时，更倾向先走 v6。若你的 v6 出口并没真正跑通，这个偏好会把失败面放大成全站级卡顿。
实操建议：先关闭 UI 里的「优先 IPv6 / Prefer IPv6」，或在 YAML 侧找到等价项后设为不优先，再复测同一批站点。若关闭后立即正常，说明瓶颈在 IPv6 路径或节点对 v6 的支持，而不是 DNS 上游本身。随后再决定是否升级节点、换机房，或仅在局域网等受控环境重新打开偏好。
3双栈下的 DNS 上游与 nameserver-policy
有些公共解析在双栈返回上很快，但若与你当前的落地出口所在地组合后，返回的 AAAA 指向对你链路不友好的 POP，也会触发超时。把「境内外域名走不同递归」写在 nameserver-policy 里，往往比在论坛抄一段 DoH 列表更稳妥——关键是让解析结果与分流意图一致。
若你为内网后缀、或其他必须走本地递归的域名单独配了策略，记得检查这些域是否被错误地套上了「只走境外 DoH」——这在开启 v6 后更容易暴露，因为某些企业内网仅对 v4 做了拆分。更系统的 DNS 段搭法仍以 DNS 防泄漏长文 的流程为准，本文只强调AAAA 这一维。
4FakeIP、Sniffer 与「看到的是哪个地址族」
使用 enhanced-mode: fake-ip 时，应用侧看到的是内核分配的假地址；真实对外解析由内核在隧道内完成。若你在排错时只盯着系统 dig 输出，会与 Clash 内部路径对不上号。遇到「HTTPS 站点空白」时，应结合连接日志里还原出的 SNI / 域名与远端握手地址族一起看。
需要放行局域网或旁路直连的域名时，可参考 FakeIP filter 与局域网直连域名 的写法，避免假地址与真实解析混用导致浏览器长期 pending。对 IPv6 而言，多一份「地址族错了」的错觉，排错就会绕远路。
5TUN、系统 IPv6 与规则里的 IP 类型
开启 TUN 后，若系统仍对同一目标同时尝试 v6 与 v4，而你的策略只对其中一种地址族写了精细规则，可能出现看似命中 GEOIP、实际另一族偷偷直连或走错组的情况。读一遍 Clash Meta 规则顺序与 MATCH 能避免「改 DNS 无效，其实是规则提前匹配」的陷阱。
Linux 全机 TUN 与 systemd 场景下，网卡转发与策略路由更复杂，可对照 Linux 上 Mihomo TUN 与 systemd 路由 检查是否只对 v4 做了 masquerade，却忘了 v6 的前缀与策略，从而导致部分站点只能间歇成功。
可打印的简要清单（从快到慢）
- 关 UI / YAML 中的 prefer-ipv6 或「优先 IPv6」，复测问题站。
- 将
dns.ipv6临时设为false，若恢复则重点查 AAAA 与节点 v6 质量。 - 固定一个节点，排除 url-test 在 v6 握手期间「乱跳」。
- 核对
nameserver/fallback/nameserver-policy是否让境内外域名走了预期递归。 - FakeIP 场景下用内核日志确认域名与地址族，而非仅看系统解析工具。
- TUN 与系统代理择一为主，避免多栈重复劫持；检查规则对 v4/v6 是否一致。
提醒：运营商或校园网可能对 53/853/443 有策略；修改 DNS 或劫持范围前请遵守本地政策。若你在企业设备上操作，先征得运维同意。
下载入口：日常安装包请以 本站下载页 为准；GitHub 可用于查阅 Mihomo 发行说明与提交记录，与「获取已打包客户端」分开即可。
小结
IPv6 不是开关一开就自动比 v4「更先进」——在 Clash Meta 里，它牵连 DNS 是否查询 AAAA、拨号是否偏好 v6、以及规则与隧道是否对两种地址族同样完整。把问题拆成解析 → 选路 → 握手三步，用可逆的小实验（关 prefer、关 dns.ipv6、固定节点）定位层级，通常比盲目换机场更省时间。
相比在论坛碎片里试参数，用一款能同时展示连接日志、当前配置合并结果与 DNS 段的客户端长期维护，会把双栈带来的不确定性压到最低；这与站内其它「场景 + 分流」文章是同一套方法论，只是 IPv6 多了一维地址族要对齐。