IPv6 resolved but unreachable：IPv6 解析成功但连接不通
IPv6 resolved but unreachable严重程度 Medium域名解析出了 IPv6 地址，但本机通过 IPv6 连不到目标。最可能是本地网络宣称支持 IPv6 而实际路由不通；第一步是分别用 --ipv4 和 --ipv6 检测同一目标做对照。
结论
这是双栈时代的特色故障："名义上的 IPv6"与"能用的 IPv6"之间隔着一条鸿沟。你的设备拿到了 IPv6 地址、域名也返回了 AAAA 记录，一切文书手续齐全——但数据包沿着 IPv6 的路走出去就没了下文。故障的实体在路由与出口，纸面证据（有地址、有记录）完全不能证明连通性。好在对照检测能在一分钟内揭穿它。
适用环境
- 全部平台，尤其是运营商刚开通 IPv6 的家宽、配置不完整的路由器环境
一分钟快速判断
connproof tcp 目标域名 --port 443 --ipv4connproof tcp 目标域名 --port 443 --ipv6- IPv4 成功 + IPv6 失败 → 确诊本条。继续往下定位是"本机没有 IPv6 路由"还是"有路由但不通"；
- 两个都失败 → 不是地址族问题，转 dial tcp i/o timeout；
- 换一个知名双栈站点重复 IPv6 检测：也失败 → 你的 IPv6 出口整体不可用；成功 → 只是目标的 IPv6 线路问题。
这条错误代表什么
失败的具体形态区分两种病灶：
- network is unreachable：本机路由表里根本没有 IPv6 默认路由——设备只拿到了链路本地地址（fe80:: 开头），没有全局地址或网关。病灶在本地网络的 IPv6 分配；
- 超时：路由存在、包发出去了，但在运营商或中间某处丢失。病灶在出口链路质量——不少地区的 IPv6 线路仍处于"能通但绕路/丢包"的状态。
麻烦之处在于系统普遍优先 IPv6：有 AAAA 记录就先试 IPv6，回退到 IPv4 的等待时间因应用而异（几百毫秒到十几秒不等），有的应用甚至不回退——于是"IPv6 半残"拖累一切。
ConnProof 如何判断
上面的两条对照命令就是核心。补充 connproof dns 目标域名 查看 A/AAAA 记录的并存情况，以及 connproof doctor 的接口摘要确认本机是否持有全局 IPv6 地址。四条证据（AAAA 存在、全局地址有无、v6 路由有无、v6 连通性）足以画出完整病灶图。
最常见原因
- 路由器 IPv6 配置不完整：拿到前缀但没正确下发路由或 RA 通告异常；
- 运营商 IPv6 链路质量差：高丢包、绕路，时通时断；
- 目标服务器 AAAA 配置错误：记录指向了未监听服务的地址（服务方问题）；
- 防火墙只做了 IPv4 规则：IPv6 流量被默认策略拦截（企业网常见）。
Windows / macOS / Linux 排查步骤
- 对照检测确诊；
- 本机无全局 IPv6 地址：登录路由器检查 IPv6 设置（常见修复：把 IPv6 模式从 Passthrough/桥改为 NAT6 或相反、更新固件、重新拨号）；
- 有地址但不通：多目标复测区分"出口整体不可用"与"单目标线路差"。整体不可用又无力改善线路时，务实方案是让系统或应用临时优先 IPv4（各平台均有 prefer-ipv4 设置或策略表调整），保住可用性；
- 保留证据：如果是运营商侧问题，"AAAA 解析正常 + v6 建连超时 + v4 同目标正常"三条证据是向运营商报障最有效的组合。
手机端排查步骤
- 蜂窝网络的 IPv6 普遍比家宽健康，Wi-Fi 失败蜂窝成功即可把嫌疑锁定在家庭路由器；
- 手机端无法改地址族偏好，问题在路由器就修路由器，问题在运营商就等待或反馈。
"开通了 IPv6"为什么不等于"能用 IPv6"
运营商说你的宽带已开通 IPv6，路由器状态页也显示拿到了地址——但这条链路上还有好几个可以掉链子的环节：光猫的桥接/路由模式是否放行 IPv6、路由器固件对前缀委派（PD）的实现是否正确、防火墙默认策略是否放行 IPv6 入站响应、以及局域网内设备是否收到了正确的 RA 通告。任何一环配置不当，你都会停在"有地址、没连通"的状态。家庭环境里最有效的三板斧：光猫改桥接由路由器拨号（避免双重 NAT 对 IPv6 的干扰）、路由器固件升到最新、IPv6 设置里选择运营商推荐的模式（多数是 PPPoE + PD）。做完任何一项都用上文的对照命令复测，用证据而不是状态页判断是否修好。
各系统临时优先 IPv4 的方法（保住可用性的过渡手段）：Windows 可通过前缀策略调整（netsh 修改前缀优先级）；macOS/iOS 遵循 Happy Eyeballs 自动回退，通常无需干预；Android 无全局开关，依赖应用实现。这些调整都不是"修复"，只是把损失控制在最小——根治仍在路由器与运营商侧。
如何区分本地问题和节点问题
| 证据 | 更可能是 |
|---|---|
| 本机无全局 v6 地址 | 路由器/本地网络 |
| 多个双栈站点 v6 都超时 | 运营商出口 |
| 仅目标站 v6 失败、他站正常 | 目标 AAAA 配置或其线路 |
| v4 一切正常 | 保底可用，按需降级优先级 |
检测时机的注意事项
IPv6 链路的不稳定常呈现时段性：晚高峰丢包飙升、深夜恢复正常。单次检测的结论因此不可靠——建议在一天内至少三个时段各做一轮对照检测，把"始终不通"与"高峰期劣化"区分开。前者去修配置，后者是容量问题，配置怎么改都没用，只能等运营商扩容或在高峰期回退 IPv4。
仍未解决时收集什么信息
- ConnProof 错误码（DNS-003）与脱敏报告；
- v4/v6 对照结果与多目标对照结果；
- 路由器型号与 IPv6 模式设置；
- 操作系统版本。
禁止提交：完整订阅链接、密码、验证码、私钥、Token、完整 IPv6 地址（报告已自动部分遮盖）。
重新运行检测
connproof tcp 目标域名 --port 443 --ipv6 --format markdown --output v6-report.md修复后 IPv6 建连应与 IPv4 一样成功。
相关文档
更新记录
- 2026-07-28：规则 v1 发布，确立四证据病灶定位法。