2026年IPv6代理进阶实战：双栈分流、纯IPv6机器出网与「免流」口径

2026年7月28日，《中国IPv6发展报告（2026）》在雄安发布：截至2025年底，我国IPv6活跃用户数达8.69亿，五年增长88%；移动网络IPv6流量占比70.85%，固定网络IPv6流量占比32.38%，五年分别增长3.1倍和7.1倍。报告里还提到，今年6月全球IPv6用户渗透率43%，雄安新区IPv6单栈部署行动同步启动。

这组数字的含义很直接：IPv6 已经是你手机和宽带上的默认路径，而不是「未来某天要面对的问题」。对代理用户来说，IPv6 科学上网完全指南已经把「怎么不泄露」讲过了——关掉 AAAA、别让 v6 流量绕过代理；客户端防泄漏那篇则把检测手段铺全了。这两篇解决的是「堵」。本篇解决另外三件事：① 双栈环境下怎么按地址族主动分流，而不是一刀切删掉 IPv6；② 只有 IPv6 的机器怎么出网、又怎么对外提供服务；③ 校园网里传了很多年的「IPv6 免流」到底是什么口径、前提是什么、代价在哪。

先立一个前提，后面所有配置都靠它：分流策略能不能落地，取决于两端的地址族能力——本地网络拿到什么地址、出口节点支持什么地址。自由猫这类 IEPL 专线节点解决的是「出海这一段」的稳定性，而地址族怎么选、怎么分流是客户端侧的活儿，两者别混为一谈——换个节点并不会自动修好你的双栈配置。

一、双栈不是「多一个协议」，是多一层路由决策

很多教程把双栈说成「本机既能连 IPv4 也能连 IPv6」。这只说了一半。真实的情况是：一条连接要经过两段，每段都能独立选地址族。

第一段：本机 → 代理节点（或直连目标）。这一段由 DNS 返回的 A/AAAA 记录和操作系统的地址族优先策略决定。绝大多数「配置没改但突然不通了」都出在这里。
第二段：代理节点 → 最终目标。这一段由服务端或客户端的解析策略决定（比如把域名原样交给远端解析，还是在本地先解析成 IP）。

两段各有两种地址族选择，于是实际存在四种组合。这张表是全文的地基：

本机→节点	节点→目标	实际效果	什么时候用
IPv4	IPv4	最传统的路径，兼容性最好	目标站只有 A 记录，或节点只有 v4 出口
IPv4	IPv6	本机不感知 v6，出口用 v6 落地	落地机只有 v6、或想拿 v6 出口 IP
IPv6	IPv4	本地走 v6，出海仍用 v4	校园网/双栈宽带里常见（详见第五节）
IPv6	IPv6	全程 v6，路径最短	两端都支持 v6 且国际出口质量可用

「关掉 IPv6」只覆盖了第一段里的一种选择——它把「本机 → 节点」这一段钉死在 IPv4 上，代价是：国内本来可以走 v6 直连的那部分流量被迫回到 v4 出海口，多占一份出口带宽。对天天开着代理、又要从国内站点拉数据的人来说，这一份浪费是实打实的。

所以双栈分流的目标不是「两个都开着让它自己试」，而是让每一类目标只有一条确定的路径。「两个都试」看起来聪明，实际表现是：先试 v6、超时几秒、再回退 v4。sing-box 出站策略组那篇里讲过分流调优的思路，地址族分流完全同理：宁可提前一刀切干净，也不要留给运行时去猜。

二、客户端怎么按地址族分流：sing-box / mihomo / Xray 三条路线

三家客户端的思路不一样：sing-box 把地址族选择拆成了「DNS 策略 + 路由规则 + 出站绑定」三层；mihomo（Clash Meta 内核）主要在 DNS 层动手；Xray 则把控制点放在出站的解析策略上。逐个说，配置片段都能直接抄。

2.1 sing-box：三层全都能控

第一层是 DNS 的默认解析策略，官方文档写明 strategy 取值为 prefer_ipv4、prefer_ipv6、ipv4_only、ipv6_only 之一，作用范围是整个解析流程：

{
  "dns": {
    "servers": [
      { "tag": "cn", "address": "https://doh.pub/dns-query" },
      { "tag": "proxy", "address": "https://1.1.1.1/dns-query", "detour": "proxy" }
    ],
    "rules": [
      { "rule_set": "geosite-cn", "server": "cn" }
    ],
    "final": "proxy",
    "strategy": "prefer_ipv4"
  }
}

第二层是路由规则里的 ip_version 字段：官方文档的取值说明只有一句——「4 或 6。留空表示不限制」。也就是说你可以写一条规则，只匹配目标地址族为 v6 的流量，把它固定到某个出站或直接放行到物理网卡。

{
  "route": {
    "rules": [
      { "ip_version": 6, "ip_is_private": false, "outbound": "proxy" },
      { "ip_version": 4, "rule_set": "geoip-cn", "outbound": "direct" }
    ]
  }
}

第三层是出站绑定：Dial Fields 里有 inet4_bind_address 与 inet6_bind_address 两个字段，用来指定出站连接绑定的本机地址族。当一台机器同时有公网 v4 和 v6、而你想让某类出站只用其中一种源地址时，这比在系统路由表上动手脚干净得多。

⚠️ 一个正在发生的变化：Dial Fields 里的 domain_strategy（旧值是 prefer_ipv4 / prefer_ipv6 / ipv4_only / ipv6_only）从 1.12.0 起废弃，1.14.0 起移除，官方给的新路径是改用 domain_resolver。网上大量老教程还在写 domain_strategy，抄之前先看版本号。

2.2 mihomo / Clash Meta：主要在 DNS 层解决

mihomo 的 dns.ipv6 字段，官方文档的原话是：Whether to resolve IPV6; if set to false, it will respond with empty resolutions for AAAA records. —— 关掉不是「报错」，而是对 AAAA 查询返回空解析。这个区别很重要：应用程序拿不到 v6 地址，就会老老实实走 v4，不会卡在超时上。

如果你只想对某几个 DNS 服务器屏蔽某一种记录，可以在 nameserver 条目上加参数：disable-ipv4 表示丢弃 A 响应，disable-ipv6 表示丢弃 AAAA 响应。这是「按解析通道」而不是「全局」地控制地址族，适合国内服务器只查 v4、海外服务器两者都查的配置。

dns:
  enable: true
  ipv6: false
  respect-rules: false
  default-nameserver:
    - 223.5.5.5
  nameserver:
    - https://doh.pub/dns-query
    - https://dns.alidns.com/dns-query
  nameserver-policy:
    "+.openai.com": "https://1.1.1.1/dns-query"

还有一个容易被忽略的开关：respect-rules。官方说明是「DNS 连接遵循路由规则，需要同时配置 proxy-server-nameserver」，并且强烈不建议与 prefer-h3 一起使用。它把「DNS 查询本身走不走代理」也纳入分流，双栈环境下很实用——DNS 查询走本地 v6、业务流量走代理 v4 是完全可以的，但前提是两条路都得通。

路由层还有两张牌：IP-CIDR6（按 IPv6 地址段匹配，常配 no-resolve）和 SRC-IP-CIDR（按来源网段匹配）。前者用来处理「某些 v6 段必须走特定出口」，后者在多设备环境里更好用：给 IoT 段、访客段分别指定地址族策略，比在每台设备上改配置省事——网段划分的做法可以参考软路由网段隔离那篇。

2.3 Xray：控制点在出站的解析策略上

Xray 的 OutboundObject 里有 targetStrategy 字段，官方给出的取值是 AsIs、UseIP、UseIPv6v4、UseIPv6、UseIPv4v6、UseIPv4、ForceIP、ForceIPv6v4、ForceIPv6、ForceIPv4v6、ForceIPv4 共 11 个。默认值是 AsIs——把目标域名原样交给远端服务器解析；其余取值控制「是否在本地先把域名解析成 IP」以及「哪种地址族优先/强制」。

官方文档里有一句提示值得单独拎出来：targetStrategy 管的是被代理的请求；如果你想控制的是代理服务器自身域名的解析策略，得去配 Sockopt 里的 domainStrategy。这两个位置在旧版文档里都叫 domainStrategy，是配置写错却「看起来没错」的高频原因。

另一个双栈相关的字段是 sendThrough：它指定发起外部连接时使用的 IP 地址，默认 0.0.0.0。官方明确写了可以填一个 IPv6 地址段（文档示例给的是 114:514:1919:810::/64 这种形式），Xray 会从段内随机取一个地址发起连接。官方同时提醒：NDP 接入方式下不建议把前缀设得比 /120 更小，否则可能造成 NDP 泛洪、把路由器的邻居缓存打爆——这是「一段 /64 想拆成几千个出口 IP」时最容易踩的坑。

{
  "outbounds": [
    {
      "tag": "proxy",
      "protocol": "vless",
      "sendThrough": "0.0.0.0",
      "targetStrategy": "UseIPv4",
      "settings": { "vnext": [ { "address": "node.example.com", "port": 443 } ] },
      "streamSettings": { "network": "tcp", "security": "reality" }
    }
  ]
}

2.4 三层各管什么：一张对照表

层	管什么	配置位置	典型写法
DNS 层	让哪个地址族出现在解析结果里	sing-box `dns.strategy`；mihomo `dns.ipv6`	全局 prefer_ipv4，或对特定域名段单独放行 v6
路由层	按目标地址族或来源网段决定走哪个出站	sing-box `ip_version`；mihomo `IP-CIDR6` / `SRC-IP-CIDR`	国内 v6 直连、出海固定走代理
绑定层	出站连接用哪个本机源地址（含端口/邻居缓存影响）	sing-box `inet4_bind_address` / `inet6_bind_address`；Xray `sendThrough`	多 IP 机器指定源地址，或从 /64 里随机取址

三层配好之后，最后一个变量是出口本身。地址族选对了，落地线路差还是慢——尤其是拿一台设备专门跑下载、同步、镜像拉取的时候，出口的流量额度和单价会比协议细节更影响体验。像瑶瑶领先的入门档「小流量」是 ¥9.9/月 384GB（站内后台套餐数据），折算约 0.026 元/GB，比较适合放到那台只做后台任务的机器上，把延迟敏感的交互流量留给主线路——这也是把「哪个设备走哪条路」落实下来的实际做法，而不只是配置文件里的几行字。

三、只有 IPv6 的机器，怎么出网

先明确这类机器从哪来：便宜小鸡的常态配置是「只给一个 v6 地址 + 共享/独立 NAT v4 端口」；也有机房直接把 v4 段回收了，只保留 v6。这类机器上 curl 一个只有 A 记录的域名，报的是 Network is unreachable——不是 DNS 问题，是本机根本没有 v4 出口。

三条路线，按落地难度排序。

3.1 WARP 隧道：借 Cloudflare 的入口拿一个 v4 出口

关键在于 WARP 的入口同时有 IPv6 网段。Cloudflare 官方文档列出的 WARP 入口（Cloudflare One Client 连的地址）是：WireGuard 模式为 IPv4 162.159.193.0/24 与 IPv6 2606:4700:100::/48，默认端口 UDP 2408，备用端口 500 / 1701 / 4500；MASQUE 模式为 IPv4 162.159.197.0/24 与 IPv6 2606:4700:102::/48，默认端口 UDP 443。文档还注明，登录组织前可能看到的是面向消费级 WARP 的 162.159.192.0/24。

既然入口有 v6 地址，纯 v6 机器就能把隧道建起来；而 wgcf 生成的标准配置里 AllowedIPs 覆盖 0.0.0.0/0 与 ::/0，本机随之拥有了 v4 出海口（以你生成出来的文件为准，不同版本可能略有差异）。生成配置用的是社区工具 wgcf（作者在 README 里明确写了这是 unofficial 的 CLI），两步：wgcf register 注册账户并落盘 wgcf-account.toml，wgcf generate 生成 wgcf-profile.conf，再交给系统或容器里的 WireGuard 使用。具体到「WARP 落地解锁哪类服务」的实测玩法，WARP 落地那篇讲得更细，这里只讲它在纯 v6 场景里的角色：它不是加速器，是补地址族。

3.2 DNS64 + NAT64：让解析层帮你把 v4 目标「翻译」成 v6

这套机制是两个标准配合的：RFC 6146 定义了有状态 NAT64（把来自 IPv6 客户端的连接翻译成 IPv4），RFC 6147 定义了 DNS64（当目标只有 A 记录时，用 A 记录合成一条 AAAA 记录）。实现细节在 RFC 7050 里给了一个很妙的探测办法——用一个「只应该有 A 记录」的固定域名 ipv4only.arpa 去查 AAAA，如果解析器返回了合成的地址，就说明链路上存在 DNS64，同时还能反推出翻译用的前缀。这个域名的 A 记录是 192.0.0.170 与 192.0.0.171。

Cloudflare 的 1.1.1.1 官方文档里明确写了它支持 DNS64：在没有 AAAA 记录时用 A 记录合成 AAAA，让纯 IPv6 客户端拿到可用的 v6 地址、再经网络侧的 NAT64 网关出去。但同一页也给足了警告，值得逐条抄下来：

只有在管理或使用纯 IPv6 网络时才应该打开 DNS64——双栈网络开了反而添乱；
它无法为合成记录生成 DNSSEC 签名，做签名校验的客户端会拒绝这些合成记录；
NAT64 是网络层面的能力，DNS64 只负责把地址备好——网络里没有 NAT64 网关，DNS64 合成出来的地址就是个死地址；
官方建议客户端到解析器之间用 DoT/DoH，避免链路上被窃听或篡改。

列表里的第三条最容易被忽略，也是这套方案在 VPS 上最常见的失败原因：你在机器上把 DNS 改成 1.1.1.1，解析器好心给你合成了一个 64:ff9b:: 开头的地址，但你这台机器所在的网络没有 NAT64 网关，包发出去直接黑洞。DNS 解析和地址优化那点事，DNS 解析优化那篇里有更细的分层思路，但结论在这里很简单：先确认网络里有 NAT64，再谈 DNS64。

3.3 借一台双栈机器做中转：最土也最可控

如果前两条路要么依赖第三方、要么依赖机房能力，第三条就是自己动手：找一台有 v4 的机器（国内中转机或海外落地机都行），用 realm、gost 这类端口转发工具把它变成入口，纯 v6 机器只负责监听和服务。这样做的好处是出口 IP 归你控制、链路可测量、出问题能按跳排查。国内中转机 + 海外落地机的组合在自建中转加速那篇里有完整做法（包括 UDP 中继），纯 v6 机器在这里扮演的是「内网服务节点」的角色。

3.4 三条路线怎么选

方案	额外成本	可控性	硬依赖	适合
WARP / wgcf	0（免费额度内）	低——出口 IP 不归你	能连上 WARP 入口（v6 可达）	只求「能出网」，比如拉依赖、装包、更新系统
DNS64 + NAT64	0，或用机房自带网关	低——取决于网络侧	链路上必须存在 NAT64 网关	机房明确提供 NAT64 的纯 v6 环境
双栈机器中转	一台机器的钱	高——出口 IP 归你	得有一台双栈机器	对外提供服务、需要稳定出口 IP 的场景

顺便说一句反向选择：如果你的纯 v6 机器只是用来做内网服务、镜像缓存、定时任务，出海这一段完全没必要自己扛。把「出网」这件事外包给机场节点，机器本身专心做它的事，成本往往比折腾 NAT64 更低——比如SS-ID是全 IEPL 专线的机场（站内后台套餐从 100GB ¥20/月起），链路类型单一、排查时变量少，适合放在这条链路上当固定出口。

四、只有 IPv6 的机器，怎么对外提供服务

出网解决的是「我能不能访问别人」，这一节解决「别人能不能访问我」，而这里的「别人」绝大多数只有 IPv4。

4.1 Cloudflare 橙云 + AAAA：把地址族问题交给边缘

Cloudflare 的 IPv6 兼容性文档写得很清楚（该页最近更新于 2026 年 8 月）：Cloudflare 默认在所有域名上启用 IPv6，开启兼容性时会自动生成 AAAA DNS 记录让 IPv6 客户端接进来；对于同时有 IPv6 和 IPv4 源站地址的已代理记录，Cloudflare 连源站时会优先使用 IPv4。可用性上，免费、Pro、Business、Enterprise 全部支持，只有「自定义」能力限企业版。

把这条规则反过来读，就是纯 v6 源站的做法：源站只挂 AAAA，橙云代理由 Cloudflare 的边缘同时提供 v4/v6 入口，源站侧按 DNS 记录的地址族建连。也就是说，纯 IPv6 机器 + 橙云代理 = 对全球 v4 用户可达，不需要你自己做任何翻译。反过来那一半文档也写了：要让 IPv6-only 的客户端连上 IPv4-only 的源站，保持 IPv6 兼容开启并配置 Pseudo IPv4。

同一页还有一个常被误解的细节：即使把 IPv6 兼容性关掉，域名仍可能收到 IPv6 流量（比如来自 Tor）。文档给的办法是关闭 Onion Routing 之外，再加一条 WAF 自定义规则匹配 ip.src in {::/0}；如果把规则加在 Worker 场景，还需要附上 cf.worker.upstream_zone == "" 条件，否则会连带拦掉 Worker 的子请求——因为 Workers 的子请求本身就使用 IPv6 地址。

4.2 监听地址的坑：`0.0.0.0` 在纯 v6 机器上会直接失败

纯 v6 机器没有 v4 栈，任何软件里写 listen 0.0.0.0 都会绑定失败，必须写成 :: 或具体的 v6 地址。而绑 :: 又会带来一个反向的意外：Linux 的 /proc/sys/net/ipv6/bindv6only 默认值是 0（man7 与 Debian manpages 都明确写了默认 false），意味着 v6 socket 同时接收 IPv4-mapped 地址——在双栈机器上，绑 :: 会把 v4 流量也一起接下来。如果你要的是「这个端口只对 v6 开放」，得把这个 sysctl 设为 1，或者干脆绑到具体的 v6 地址上，而不是依赖应用层去区分。

4.3 证书：DNS-01 比 HTTP-01 稳

纯 v6 源站申请证书时，HTTP-01 验证要求 CA 的验证节点能访问你的 v6 地址——这一步能不能通，取决于 CA 那侧的网络，你不可控。省事的做法是走 DNS-01：把验证记录写进 DNS，CA 只要能查 DNS 就行。泛域名证书 + DNS 自动续期的完整命令在自建节点 CDN 中转那篇里给过，纯 v6 场景可以原样复用。

4.4 地址族解决「能不能连」，出口 IP 类型解决「像不像人」

对外服务如果面向的是跨境账号体系（店铺后台、社媒多账号、广告账户），那么决定成败的往往不是 v4 还是 v6，而是出口 IP 的类型与纯净度。机房 IP 段被大量共享，风控系统一眼就能看出来；住宅或原生 IP 段的可信度完全不同。这也是仙路湾这类机场的定位——站内套餐把原生 IP（¥9.9/月 50GB 起）与住宅 IP（铂金会员 ¥30/月 100GB）分开列，就是给这类场景用的。地址族是技术层的选择，IP 类型是业务层的选择，两件事都要做对才不白折腾。

五、「免流」能省的是哪一段：口径、前提与代价

这一节不教操作，只把口径和代价讲清楚——因为「怎么免流」的教程全网都是，但很少有人告诉你它到底在省什么、前提是什么、什么时候会翻车。

5.1 能成立的口径：计费系统统计的是哪一段流量

高校校园网里被反复验证过的做法是这样的：部分学校的计费口径只统计 IPv4 下行流量（有的连 IPv4 上行和 IPv6 上下行都不计）。于是就有了一条非常朴素的路子——把「请求」放在计费的那一侧、把「内容」放到不计费的那一侧。请求通常只有几 KB，响应可能几十 MB，下行挪到 v6 之后，计费口径上就看不见了。开源社区里能查到多个高校的具体实现记录（例如以「仅上传 IPv4 流量、接收 IPv6 流量」为核心的方案），也有把家里的路由器当作 v6 中转节点、在校园网侧通过 v6 访问的写法。

这里没有任何「破解」技巧，全是计费口径和信息流方向的数学。理解这一点，才能判断它什么时候会失效：只要学校改了计费口径（比如开始统计 v6、或者按端口聚合统计），整套做法当天就归零。

5.2 三个必须同时成立的前提

远端要有 v6，且路径要通。校园网/运营商的 v6 与公网 v6 之间是否互通、走哪条国际出口，各校差别很大。只在局域网里通 v6 是没有意义的。
策略路由要对。「v4 发请求、v6 收内容」意味着同一台设备上要有明确的分流规则，否则 DNS 会把请求也解析到 v6，整套逻辑就退化成普通的 v6 访问。
回程质量要能接受。这一点最容易被教程忽略。公开的技术讨论里，有人把链路搭完后的结论是「能通但网页奇慢」，原因就是 v6 侧的路径绕远、单程延迟高。省流量的代价可能是体验倒退，而且这个代价在配置阶段完全看不出来。

5.3 代价与风险，别只看省下来的那点流量

校园网与运营商的《网络使用协议》里，对「以规避计费为目的的网络配置」通常有明确禁止条款。实际风险包括：被限速或断网、被要求补缴、在极端情况下影响个人在校记录。更要紧的是信息真伪：网络上流传的「运营商免流卡」「套餐免流代码」之类的说法，我查不到任何可核验的运营商公开条款，绝大多数是过期经验或者干脆是卖卡的话术。判断标准很简单——如果一条「免流」教程给不出官方计费口径的出处，就当作推销。

5.4 被忽略的正当用法：把 v6 当「第二张网」

校园网/双栈宽带里 v6 不计费这件事，本身有一个完全正当的用法：用它跑国内资源。教育网与国内主流站点的 v6 覆盖本来就好，这一段走 v6 直连既不占代理出口带宽、也不触发计费；把需要付费出口的那部分流量（出海访问、AI 服务、国外包管理源）留给代理节点。这就是第一节里「按地址族主动分流」的现实收益——同样的订阅额度，能多用一段时间。

换个说法：v6 在这里的角色是「另一张不计量的网」。把它当成免费的内网出口用，比把它当成逃费工具用，收益更稳定，也不用担心哪天学校改了口径。

5.5 想省流量的第一步不是改配置，是核实计费口径

大部分人一上来就问「怎么配」，正确的第一步其实是打开学校的网络自助服务，拉一份自己的流量明细。看三件事：明细里统计的是 IPv4 下行，还是上行下行都算；明细里有没有出现 v6 条目；统计是按端口/协议聚合的，还是按网络类型分开列。这三件事决定了整套方案的可行性——如果明细里根本没有 v6 字段，说明 v6 确实在计费范围之外；如果它按端口聚合统计，那么「请求走 v4、内容走 v6」在聚合视图里依然是一个账号的完整流量，很容易被看出来。十分钟的核对，能省掉后面几个小时的调试，也能避免把别人的结论直接套到自己的环境上。

运营商侧的判断逻辑一样：流量明细在官方 App 里能查，但不同套餐的统计口径并不对外公开说明。所以「某运营商 IPv6 不计费」这类说法，只能以你自己账单上的明细为准，不能以别人的教程为准。

六、双栈环境排错清单

双栈问题的特点是：症状看起来像「代理坏了」，实际根因在地址族选择上。下面这张表按症状对照，命令都是随手能跑的。

症状	最可能的原因	怎么确认
代理已开，某个站就是连不上/极慢	该域名有 AAAA 记录，v6 直连绕过了代理	`dig AAAA 域名` 看有没有 v6 结果；`curl -4` 与 `curl -6` 分别试一次
测速结果好得离谱	测速站走了 v6 直连，没经过代理	先在代理里查出口 IP，再和测速站看到的 IP 对比
部分设备绕开代理	路由器只下发 v6 地址，或策略路由漏了 v6 段	`ip -6 addr`、`ip -6 route`、`ip -6 rule` 逐节看
只有 v6 的机器访问 v4 站点报 `Network is unreachable`	本机没有 v4 出口	`ip -4 addr` 确认；然后按第三节的三条路线处理
开了 DNS64 但目标依然连不上	链路上没有 NAT64 网关，合成地址是死地址	`dig AAAA ipv4only.arpa` 有合成结果 ≠ 网络能翻译
v6 通但路径绕远、延迟高	v6 国际出口与 v4 不是同一条路	`mtr -6 目标域名` 与 `mtr -4` 对比逐跳

排错顺序也有讲究，按下面这个次序走，能少绕很多弯路：先确认地址族（本机到目标到底走的 v4 还是 v6，用 dig 与 curl -4/-6 就能定性），再确认路径（mtr 看逐跳，确认是不是绕远或断在中途），最后才查协议与客户端配置。反过来先怀疑「协议被识别了」「节点被封了」，往往会在一个本来就正常的节点上白折腾半天。另一个纪律是：一次只改一层——DNS 层和路由层同时动，出问题后你无法判断是哪一层起了作用，这也是双栈排错最耗时间的原因。

看路径这件事值得单独提一句：mtr 的 v4/v6 对比是判断「这个 v6 出口到底能不能用」的唯一靠谱办法——只看「能 ping 通」会误判，因为能通和能跑是两件事。路由追踪那篇里有完整的读法（去程回程、AS 号、在哪一跳开始绕）。

七、路线选择与三个常见误判

你的情况	第一段怎么选	第二段怎么选	要不要动硬件
家里双栈宽带，只上外网	DNS 层统一 prefer_ipv4，别让 v6 抢跑	代理固定走 v4 出口	不用
有软路由、设备多（手机/电视/IoT）	按网段分流：IoT 段只走 v4，主力段可选 v6	国内 v6 直连、出海走代理	要（路由规则）
手里有一台纯 v6 小鸡	本机没有 v4，先解决「能出网」	用 WARP 或双栈中转补 v4 出口	不用，配置即可
跨境多账号/工作室	地址族不是重点，IP 类型才是	按账号绑定固定出口 IP	不用，但要在订阅层规划

7.1 三个最容易走错的方向

上面这张表是结论，下面三条是决策时最容易走偏的地方——它们比配置细节本身更常导致返工：

误判一：关掉 IPv6 就等于配置正确。关闭只是把双栈问题压回单栈，国内 v6 直连这条路也一起丢了。对流量计费的订阅来说，这等于花钱买了一部分本来免费的流量。
误判二：开了 IPv6 就会更快。v6 只是另一条路径，快不快取决于这条路径的出口质量。同一个目标站，v6 绕远、v4 直连的情况和反过来的一样常见——判断依据只能是逐跳数据。
误判三：纯 v6 机器必须先补齐 v4 才能干活。如果你的机器只对外提供服务、不需要访问 v4 目标，那它本来就不缺什么；真正需要补 v4 出口的只是「它自己要往外访问」这一类需求。

八、常见问题

Q1：关掉 IPv6 会影响国内网站的访问吗？

会，但影响的方向和很多人想的相反。关掉之后你依然能访问国内网站，只是那些本来走 v6 的国内资源会退回 v4 路径，多占一份出口带宽。如果你的订阅是流量计费的，这部分是白花的。更精细的做法是只对「需要走代理的域名」屏蔽 AAAA，而不是全局关闭。

Q2：机场节点支持 IPv6 吗？怎么查？

看订阅里的节点地址是域名还是 IP，以及服务商的说明——这件事不能靠猜，也不该靠第三方评测。自己验证的办法：导入订阅后，在客户端里对某个节点执行延迟测试，看它的连接目标是 v4 还是 v6；或者直接问服务商。需要提醒的是：节点支持 v6 和 节点有 v6 出口 是两回事，前者指你能通过 v6 连上它，后者指它能带你去 v6 目标。

Q3：开 TUN 模式后部分应用超时，和 IPv6 有关吗？

大概率有关。TUN 模式会把系统栈里的流量整体接走，如果 DNS 仍然返回 AAAA 记录、而节点侧只有 v4 出口，就会出现「先试 v6、超时后回退」的观感。处理办法按第二节走：DNS 层确认不再返回 AAAA，或路由层把 v6 目标显式指向直连。

Q4：纯 v6 机器能跑代理服务端吗？用 v4 的客户端能连上吗？

能跑，但客户端直连不了——中间必须有地址族转换。两条路：一是把域名挂到 Cloudflare 代理（只加 AAAA），由边缘提供 v4 入口，见第 4.1 节；二是前面放一台双栈机器做中转，见第 3.3 节。直接拿 v4 客户端去连一个只有 v6 地址的机器，是没有办法的。

Q5：用 WARP 补 v4 出口，会不会所有流量都被送进 Cloudflare？

看你写进去的 AllowedIPs。如果只为了让纯 v6 机器能访问 v4 目标，就把默认路由的范围控制好，别把 v6 出去的流量也一起塞进隧道——否则本来走 v6 直连的部分会平白绕一圈。这也是为什么第 3.1 节强调它「不是加速器，是补地址族」。

Q6：校园网里用 IPv6 分流，会不会被封？

技术上是可检测的：同一个账号的流量突然全部变成 v6、或者出现明显的「小请求大响应」模式，运维侧看聚合数据就能发现。风险的真实程度取决于学校的管理尺度与是否明确禁止，衡量下来远不如「用 v6 跑国内资源」这种正当用法划算。

Q7：为什么开了 DNS64 之后，某些域名解析反而失败？

两个原因。一是 DNSSEC——合成的 AAAA 记录没有签名，做校验的解析器/客户端会直接拒绝（Cloudflare 文档专门提示了这一点）。二是解析器本身不支持 DNS64，或者链路上根本没有 NAT64 网关，合成记录毫无意义。遇到「开了更糟」的情况，最快的处理是先关掉它，再逐项确认网络侧能力。

Q8：纯 v6 机器上跑 Docker，容器里也出不了网吗？

是的，而且原因一样：容器默认共享宿主的网络出口，宿主没有 v4 栈，容器也不会有。所以别指望「在容器里换个镜像」能解决，得在宿主层把 v4 出口补上（第三节的三条路线任选一条），再让容器复用宿主的网络。如果只是某个容器需要访问 v4 目标，也可以让它走一个代理，但那样只解决单点，宿主自身的包管理和系统更新仍然会失败。

Q9：既然客户端能分流，路由器上要不要干脆关掉 IPv6 下发？

不建议。路由器关掉 v6 下发是「一刀切」，等于放弃了国内 v6 直连这条免费路径，而且一旦某个设备需要 v6（比如只提供 v6 的目标站）就彻底没戏。开在路由器、控制在客户端，粒度更细，出问题时也更容易定位是哪一层。

Q10：IPv6 到底比 IPv4 快还是慢？

不存在普遍结论，这是双栈话题里最容易被拿来忽悠人的一问。同一个服务商的两条路径可能完全不同：有的 v6 直连更短，有的 v6 绕了大半个地球。唯一靠谱的判断办法是逐站对比——拿同一个域名分别用 curl -4 与 curl -6 跑几次，看的是建立连接与首字节的时间，而不是「能不能通」。所以别信任何「v6 一律更快」的说法，包括本机在别人的网络里测出来的结论。

Q11：智能电视、游戏机这类只支持 IPv4 的设备要单独配置吗？

不需要单独配置，但要确认它们没有被分流规则误指到 v6 出口。这类设备的固件往往只实现 v4 栈（或者实现了但不完整），一旦分流规则把它们的目标域名解析成了 v6 地址，表现就是「网络已连接但打不开」。处理办法是在路由层按来源网段把它们划到 v4 出口，或者干脆在 DNS 层对这类设备单独用一台只返回 A 记录的解析器——这也是按网段分流比按设备改配置省事的原因。