双栈下三类常见错觉：解析、路由与 Happy Eyeballs

当你已经打开 TUN、也写了看似完整的 直连规则，却在测速或泄漏站上仍看到运营商分配的 IPv6，先不要急着断定「规则失效」。在 双栈网络里，应用往往同时对 IPv4 与 IPv6 做解析与建连；浏览器与部分库还会用 Happy Eyeballs 抢先连上「更快」的那条路。结果是：你以为所有流量都进了 Clash 虚拟网卡，实际上仍有连接走了系统默认的 IPv6 出口，看起来像Clash IPv6「关不干净」。

把问题拆成三层最省事：DNS 是否仍把 AAAA 交给不可控解析器、规则是否对 AAAA 返回的地址族给出一致策略、操作系统是否仍在并行宣告可用的 IPv6 前缀。DNS 总结构与 dns-hijack 的配合，建议先对照 Clash Meta DNS 配置指南；TUN 如何把流量与 53 端口拉进内核，可并行阅读 TUN 模式深度解析。下文按「先 DNS、再规则、后系统」的顺序，把DNS 泄露与路由异常收敛到可验证的步骤上。

第一步：在 dns 里约束 IPv6 与 AAAA

在 Clash Meta（Mihomo）系内核中，dns 段里的 ipv6 开关决定内核是否积极处理 IPv6 解析路径。对多数「节点 IPv6 不完整、但运营商给了原生 IPv6」的家庭宽带，最稳妥的起点是显式 ipv6: false，让解析侧先不要引入 AAAA 变量，避免后续规则在双地址族上「各命中一半」。这与你在 DNS 指南 里为 nameserver、fallback 设计的意图一致：先保证解析链单一、可预期，再谈分流美学。

同时请核对：dns.enable 为 true，且合并订阅后没有第二段 dns: 静默覆盖；TUN 场景下 tun.dns-hijack 是否仍劫持 any:53（或你本地实际查询端口）。若系统或浏览器开启了「私人 DNS / DoH」，仍可能绕过劫持窗口，使泄漏站看到与 Clash 无关的解析器——这类现象更像路径分叉，而不是节点质量问题。

YAML — dns ipv6 off (illustrative) 
dns:
  enable: true
  ipv6: false
  listen: '0.0.0.0:1053'
ℹ 何时再打开 ipv6: true：当你确认节点与路由全链路支持 IPv6，并希望利用双栈带宽时，再逐步放开；每次只改一项，配合下文泄露测试对照。

第二步：直连规则要覆盖 IPv6 地址族

仅有「国内域名走 DIRECT」并不自动等价于「国内流量的 IPv6 也直连」。若解析阶段仍返回了某服务的 AAAA，而你的 rules 只对域名或 IPv4 段做了匹配，连接可能在 IPv6 上落到默认路由，从而表现为「仍像走了代理」或「延迟与出口不一致」。实践上请在规则集中显式考虑 IP-CIDR6、GEOIP 对地址族的覆盖，并检查 MATCH 之前的顺序——过宽的 GEOIP 或过早的 MATCH 都会让排障看起来像玄学。写法与顺序细节可复习 规则分流最佳实践。

若你使用 Fake-IP，请同步维护 fake-ip-filter，避免局域网与依赖真实 IP 的名字在双栈下反复抖动；这类「像 DNS 坏了」的误判，在 Fake-IP 与局域网 / 路由器 一文中有更贴近家庭拓扑的说明。软路由或旁路网关场景下，网关与 DNS 重定向还会叠加一层，可参考 OpenWrt 上 OpenClash 与网关 DNS 的整体顺序，再回落到单机的 Clash 配置。

YAML — rules excerpt: GEOIP before MATCH (illustrative) 
rules:
  - GEOIP,CN,DIRECT
  - MATCH,<your-proxy-group>

第三步：TUN、auto-route 与接口探测

开启 TUN 后，请关注 tun.auto-route、tun.auto-detect-interface 与 tun.strict-route（若你的版本提供）是否与你当前操作系统路由表协同。双栈环境下，虚拟网卡与物理网卡会并行存在；若路由优先级或策略路由未按预期指向 utun/meta 接口，部分进程仍可能从物理 IPv6 出口逃逸。此类问题在「关代理就一切正常」与「仅 IPv4 正常」之间摇摆时尤其常见，可与 TUN 模式深度解析 中的栈与劫持章节交叉验证。

退出或切换模式时若出现残留系统代理与无网感，可对照 退出代理后清理系统代理与 TUN 的步骤，先排除「旧路由未回收」对对照实验的干扰，再谈 IPv6 泄露。

YAML — tun block excerpt (illustrative) 
tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - 'any:53'

第四步：在系统侧关闭或降级 IPv6（可选）

当 Clash 侧已把 DNS 与规则写齐，但操作系统仍向局域网广播可用的 IPv6 前缀，部分应用会优先尝试 IPv6 TCP。若你的目标就是「在双栈环境里强制走 IPv4 代理路径」，可以在操作系统网络适配器里关闭 IPv6或改为仅本地链路（以各系统 UI 为准），做一次硬对照。Windows 可在网卡属性取消 IPv6；macOS 可在网络高级设置里调低 IPv6 配置；Linux 可用 NetworkManager 或 sysctl 按接口禁用。该步骤属于环境约束，会改变整机网络特性，适合个人设备上的验证，而不替代 Clash 内的正确配置。

若你仅在特定客户端里遇到问题，优先查该客户端是否自带「优先 IPv6 / 禁用 IPv6」开关，比在系统层全局关闭更温和。无论选哪条路，都建议与下文泄露测试绑定，用前后截图而不是主观体感下结论。

泄露测试与对照实验（可重复）

选 1~2 个你信任的公开 泄露测试页面，在固定节点与固定规则集下做四组对照：仅系统代理、仅 TUN、TUN 加 dns.ipv6: false、以及在系统关闭 IPv6 后再测。记录四项：检测页展示的 DNS 出口、IPv4 与 IPv6 地址归属、WebRTC 是否与预期一致。对照实验的价值在于区分「解析分叉」「路由分叉」与「应用层并行建连」三类不同机制，避免把 Happy Eyeballs 误判为 DNS 泄露。

若日志里出现大量握手超时或 TLS 异常，可结合 连接日志与 TLS 排障 判断是否为解析结果与 SNI 不一致，而不是单纯 IPv6。完成收敛后，把最终生效的 dns 段与关键 rules 片段备份一份，避免下次合并订阅时再次被覆盖。

  1. 基线：记录当前 dns.ipv6、TUN 开关与系统 IPv6 状态。
  2. 单变量：每次只改一层（DNS、规则、系统 IPv6 三选一），重载配置后再测。
  3. 可重复：同一浏览器配置、同一节点组，避免把节点地区切换混入对照。
  4. 归档：保存泄漏站结果截图与配置片段，便于下次订阅更新后 diff。

常见坑：合并订阅、重复键与浏览器 DoH

结语

双栈不是「多一个开关」那么简单，而是 DNS、规则与操作系统三条线并行。把 dns 里的 IPv6 意图写清楚、让 直连规则覆盖 IPv6 地址族、必要时再在系统侧约束 IPv6，并用可重复的泄露测试验证，才能把「仍像走代理」的现象收敛到具体一层。相比反复换节点，这条路径更能稳定复现与修复问题。客户端与内核组合众多，选型可参考 如何选择适合自己的 Clash 客户端，再按你的平台微调 TUN 与 DNS。

若你希望在同一段配置里长期维护 DNS、TUN 与规则，图形界面能减少「改了一处、另一处被订阅覆盖」的摩擦；相比其他同类工具，Clash 在规则可读性与社区规则集生态上往往更省心。你可以从本站获取已对齐 Meta 系字段习惯的客户端，把本文步骤逐项落到界面与 YAML 里。

→ 立即免费下载 Clash，开启流畅上网新体验，在客户端中对照本文完成 IPv6、DNS 与直连规则的实测收敛。