Claude Code 双栈连接排查：何时检查 IPv4 与 IPv6
看到 IPv6 地址，不代表连接泄漏或账号风险更高。需要排查的是：当前应用采用了哪种连接方式，它是否符合你的网络设计，以及故障是否只出现在某条路径。本文帮助你用对照测试检查双栈环境，不把关闭系统 IPv6 当作默认解决办法。
一、先分清三个容易混淆的对象
设备拥有 IPv6 地址、域名提供 IPv6 目标地址、某一次请求实际使用 IPv6，是不同的事情。设备接口上存在地址，不说明所有应用都会使用它；查询到 AAAA 记录，也不保证当前网络能到达该地址。只有结合应用连接信息，才能确认某次请求走了哪条路径。
双栈客户端可能根据可达性和连接建立情况在地址族之间选择或尝试连接。相关机制可参考 RFC 8305：Happy Eyeballs。因此，浏览器与终端表现不同不一定异常；它们可能使用不同运行时、代理设置或解析策略。
二、什么现象值得做双栈对照
如果同一应用在某个网络稳定超时、切换到另一个获准测试的网络后恢复，或者连接日志显示某类地址持续失败，可以把双栈问题列为候选原因。还应同时考虑目标服务是否支持该地址族、组织是否设计为仅允许某类连接，以及中间设备的规则是否一致。
仅因为 IP 查询页显示了一串带冒号的地址，不足以说明配置被绕过。若你使用的通道承诺同时接管 IPv4 和 IPv6，应核对实际配置与日志；如果组织本来就允许一部分流量直接连接，应先理解这一设计，而不是用“所有出口都必须一致”作为统一判断。
三、在应用实际运行的位置检查
Claude Code 可能运行在本机、容器或远程主机。浏览器中的检测只代表浏览器访问检测网站的情况，不能替代远程环境的连接记录。先写清运行位置，再确认那个环境的 DNS、网络接口及代理设置；本机回环地址指向的服务，在容器或远程机器中可能并不存在。
也要区分客户端到代理、代理到目标这两段连接。客户端即使通过 IPv4 连接代理，也不能据此推断代理只用 IPv4 访问上游。若你无法查看代理出口，应请管理员提供相应连接记录，不用终端里的单个参数作过度推断。
四、设计一个可解释的最小测试
- 保存当前网络配置，记录系统、客户端版本、认证方式和测试时间。
- 确认要测试的目标是否提供对应地址记录，以及当前网络是否预期支持它。没有目标 IPv6 地址时，不把 IPv6 测试失败当作本地故障。
- 在相同运行环境、相同网络条件下，使用能够明确控制地址族的诊断工具进行低频对照。
- 记录失败发生在解析、连接、TLS 还是应用响应阶段，不只记录“成功/失败”。
- 若仅某一路径异常，把证据交给管理员或服务商，再决定是否调整应用或通道设置。
命令行工具的强制地址族选项，控制范围应以该工具与代理模式的文档为准。经过代理时，目标解析可能由代理完成，因此诊断参数不一定约束上游连接。测试前明确这个范围，可以避免得到一个看似清楚、实际上比较对象不同的结果。
五、优先修正局部配置
如果发现某个应用未使用组织要求的通道，应修正该应用的配置。如果是网络设备对 IPv6 的路由或防火墙规则有遗漏，应由管理员处理相应规则。针对已经证实的路径故障，临时选择可用路径可以作为恢复手段，但要记录这是临时措施，并保留后续修复与恢复计划。
不建议在没有证据时同时关闭所有网卡的 IPv6、改 DNS、换线路并修改语言时区。这样既可能影响局域网功能，也会让你无法判断究竟哪项变化有用。设备由组织管理时，更应遵循其配置策略，而不是照搬适用于另一套系统的命令。
六、不要把双栈故障与账号决定混为一谈
网络连接恢复后，如果仍收到认证、权限或额度提示，应转到相应账户和工作区排查。IPv4 与 IPv6 只是连接层面的区别，不能据此推断平台如何计算内部风险，更不能以“改成 IPv4”承诺解决所有验证问题。
同样，测试中观察到的 WebRTC 地址属于浏览器相应接口的结果，不能直接当作终端 API 请求的出口证据。对当前应用，最有价值的是它本身的连接日志、错误响应和可重复的操作记录。需要了解不同应用为何可能显示不同出口，可阅读应用出口差异教程。
七、怎样验收与留档
验收至少包含原先失败的操作能够完成、必要的其他网络功能未受影响，以及配置恢复方式仍然明确。记录每次变更前后使用的网络、地址族、请求目标和结果，不把无关的网页测速当作最终验收。
如果暂时无法证明根因，可以准确写成“在某网络仅观察到某类连接失败，原因待管理员确认”。这样的记录比“IPv6 天然不稳定”更有用。进一步排查可结合域名与企业网络配置和服务状态时间线，逐步区分连接问题、服务事件与账号问题。