IPv6 双栈下用 Clash TUN 仍漏地址？关闭 IPv6 与分流校准实测（2026）

1. 双栈不等于双倍保险：TUN 与两条出口的关系

在家庭宽带与多数数据中心网络里，运营商同时下发 IPv4 与 IPv6 已是常态。操作系统会对「同一域名」并行尝试 A 与 AAAA 记录；应用往往优先选择延迟更低或 Happy Eyeballs 判定更快的那条路径发起业务连接。Clash 的 TUN 模式负责把进入虚拟网卡栈的流量按规则分发，但若另一端地址根本没经过你期望的策略链——例如仍通过物理网卡上的原生 IPv6 出网——你在日志里就会看到一种割裂：IPv4 会话走代理、IPv6 会话直连，或测 IP 网站同时展示两条不同路径的信息。

这和「节点好不好」有时无直接关系，而是双栈下默认路由与 DNS 解析没有在用户心智里被拆成两条链路来设计。许多教程只验证浏览器里某个站点能开，却没有同时验证 IPv6 是否仍承担了一部分会话。本文后续章节会把它拆成：先约束系统是否还能「未经允许」用 IPv6，再在 mihomo 里让 DNS、Fake-IP、规则与 Sniffer 对齐到同一条决策逻辑。若你希望先复习规则顺序与策略组语义，可对照站内的 高级规则分流说明，再回头阅读 IPv6 场景。

2. 典型现象：测「双栈」、地区检测飘、部分业务仍直连

下列现象在论坛与 issues 里反复出现，且常和 IPv6 仍未被统一接管有关：在线 IP 检测页显示你所在地区的运营商公网地址，即便你确信已开 TUN；流媒体或版权方站点出现IPv4 区域正确、IPv6 区域错误；某些国内站点偶发「能打开但解析到境外 CDN」；P2P、游戏或 QUIC 流量在日志里表现为大量直连或走错策略组。它们共同点是：你只验证了单协议或单工具，没有同时观察双栈。

与之对照，若DNS 查询仍由路由器、运营商劫持或浏览器自带 DoH 完成，而连接阶段才进入 Clash，则容易出现解析结果与分流依据不一致——这也是广义上的 DNS 泄漏。在双栈场景里，还要多问一句：AAAA 记录是否在你不知情的前提下把会话拖回了直连。因此排查时不要把问题过早归结为「规则太少」；先用下一节的系统手段确认物理网卡上的 IPv6 是否仍在与 TUN 抢路由。

3. 系统与网卡层：关闭或约束 IPv6 的可逆做法

在动手改 YAML 之前，建议先完成一件「可逆」的事：让操作系统在全局或单网卡粒度上不再优先或不再使用 IPv6，以便把变量收敛到 IPv4-only 或「仅允许经 Clash 转发的 IPv6」。这不是否定 IPv6，而是在排错阶段先排除第二条出口；确认行为符合预期后再逐步恢复双栈，并同步更新 Clash 内相关选项。

Windows

在「网络适配器选项」中对活动网卡取消勾选 IPv6，或通过 PowerShell、注册表等方式临时禁用，是最直观的对照手段。若你在公司域或校园网环境，禁用前请确认不会影响刚需业务。与 TUN 与 UWP 专文 一起阅读时，请注意：某些系统组件仍可能使用独立于浏览器的网络路径，因此仅改 Chrome 设置不代表整机双栈已受控。

macOS

可在「网络 → 详情 → TCP/IP」中关闭 IPv6，或使用命令行对特定接口调整。若你使用 Verge Rev 一类客户端，还需注意系统扩展、权限与多配置文件是否导致「界面显示开启 TUN、实际路由未完全接管」的假阳性；这类问题要先于规则细调。

Linux

通过 sysctl 禁用或收紧转发、在 NetworkManager 里关闭 IPv6，或在特定发行版使用防火墙策略阻断未经 TUN 的 IPv6 出网，都是常见做法。与 Ubuntu systemd 部署文 对照时，请把「服务已自启」与「路由表是否唯一」分开验证；容器与宿主机双栈混用时尤需如此。

4. mihomo 侧：IPv6、TUN 与出站栈的一致性

mihomo（Clash Meta 系内核）提供了对 IPv6 与 TUN 的可配置项；不同客户端的图形界面会把它映射成「开关」或高级覆写。实务上请把握一条原则：若系统层仍有不受控的 IPv6 出网，内核配置再完美也会被掩盖。在已完成第三节的前提下，再检查你的配置中是否显式声明如何处理 IPv6，而不是依赖默认行为。

# Example only — field names vary by core version; align with upstream docs
ipv6: false
tun:
  enable: true
  # stack / auto-route / strict-route — follow your client + kernel pairing

上例中 ipv6: false 表示在内核代理侧不主动推进 IPv6 出站，常与「系统已关 IPv6」组合使用；若你需要代理侧 IPv6，则应改为与节点能力、策略组及 DNS 同步开启，并避免半开半关。TUN 相关字段如 auto-route、strict-route 等，会直接影响默认路由是否仍指向物理网卡；请始终以你所用版本文档为准，并在修改后重启内核与网卡再测。

若你最近在排查订阅无法更新或TLS 握手失败，请先与 订阅与 TLS 日志专文 区分：那类问题更多是远程服务器名与证书链，而本文侧重本地双栈路径与 DNS。

5. DNS 泄漏与分流校准：AAAA、本地解析与 Fake-IP

分流校准在双栈场景里，很大一部分是在校准 DNS 与连接两阶段的决策是否一致。若客户端先向路由器或运营商拿到含 AAAA 的解析结果，再发起连接，而 Clash 只在连接阶段介入，就会出现策略与探测工具读到的「出口」不一致。另一方面，Fake-IP 模式把本地解析阶段包裹进内核，但必须配合禁止外部 DNS 旁路与嗅探补全，否则会退化成「表面走了 Clash、实际解析仍外泄」。

操作建议包括：在 DNS 配置中明确如何处理 IPv6 查询；为需要代理的域名使用一致的远程解析源；在修改后清空本机与浏览器 DNS 缓存并重启内核。对已启用 HTTPS 的流量，若规则匹配仍异常，可短期开启 Sniffer 对照 TLS SNI，细节见 Sniffer 与 SNI 日志专文。把三套信息对照起来才容易判断：DNS 响应、连接日志里的目标 IP 版本、以及命中的规则名。

6. 规则与 GEOIP：IPv4 命中了，IPv6 仍直连怎么办

许多规则集以域名与 IPv4 GEOIP 为主；当会话落在 IPv6 地址 上时，若缺少对应的 IP-CIDR6、GEOIP（若数据源支持）或基于域名的前置规则，就会提前命中宽泛的直连/MATCH。这不是规则集「有错」，而是你当前的访问路径与规则假设的 IP 族不一致。

处理思路有两种层次：在排错阶段关闭系统 IPv6，让流量回落到 IPv4-only，规则立即「像预期那样」命中；或在长期保留双栈的前提下，为关键前缀补充 IP-CIDR6、更精确的域名集，并检查规则顺序是否把「大段直连」写在过于靠前的位置。若你同时使用 rule-providers 自动更新，记得核对 规则集更新是否成功拉取完整数据库；半吊子的 GEOIP 也会让 IPv6 判区失真。

7. 可复现实测顺序（2026）

建议按下列顺序做 2026 可复现实验，每次只改一类变量。第一步：在不开 TUN、仅系统代理的情况下记录基准。第二步：开启 Clash TUN，用同一组测 IP 与 DNS 工具分别观察 IPv4 与 IPv6。第三步：在系统层临时关闭 IPv6 后重复第二步，若异常消失，则问题已收窄到双栈。第四步：在 mihomo 中对齐 ipv6、tun、dns 三段配置后再次测试。第五步：打开连接日志，过滤同一站点在两种 IP 版本下的命中规则。第六步：若 HTTPS 仍异常，短期启用 Sniffer 对照 SNI。第七步：恢复系统 IPv6，并同步打开内核 IPv6 与完整规则，确认长稳。

尚未完成客户端安装与订阅导入的读者，请先走一遍 订阅导入教程，避免把「根本没连上节点」误判为 IPv6 特例。双机或多网卡用户建议在固定物理网卡与单一 Wi‑Fi 下复测，减少漫游与多路径干扰。

8. 排查清单