Claude Code 用着用着突然没反应、请求一直转圈、或者直接报超时，十次里有大半是网络链路的问题，不是账号或额度问题。这份指南按"从近到远"的顺序排查：先看本地，再看链路，最后看服务端。以下步骤适用于当前版本客户端（2026年8月），后续版本界面若有调整，排查思路依然通用。
第一步：确认是不是本地网络问题
先排除最简单的可能性——本地 Wi-Fi/宽带本身是否正常。打开任意一个海外网站（不经过任何加速工具）测一下基础延迟，如果连普通网页都打不开，问题出在本地网络而不是 Claude Code。
第二步到第四步：逐层排查链路
第二步：检查 DNS 解析是否正常
命令行执行 nslookup api.anthropic.com，如果解析不出 IP 或者解析出的 IP 明显异常（比如指向一个不属于 Anthropic 的地址段），问题出在 DNS 层，可以尝试更换公共 DNS 或检查加速工具的 DNS 设置。
第三步：测试到目标 IP 的连通性
拿到正确的 IP 后用 ping 或 curl -v 直接测这个 IP 的连通性和延迟。如果 ping 不通或延迟异常高（超过 500ms），问题多半出在出口线路——这一步如果频繁超时，通常是出口 IP 质量不稳定，和你换了几个客户端都没关系。
第四步：检查是否命中限流
观察报错信息：如果是 429（Too Many Requests）一般是限流，等待或降低并发即可；如果是连接直接被拒绝或长时间无响应，更像是链路层被干扰，而不是账号层面的问题。
第五步：排查客户端本身的配置
确认代理设置、环境变量（如 HTTPS_PROXY）是否和实际使用的加速工具匹配，有些用户换了加速工具但客户端配置还指向旧端口，表现出来就是"看起来连了但一直超时"。
第六步：换一条出口线路做对照测试
如果前面几步都排查完还是不稳定，最直接的验证方法是换一条完全不同的出口线路重试同样的请求——如果换线路后立刻恢复正常，基本可以确认是原线路的出口质量问题，而不是 Claude Code 或本地设备的问题。我们自己测试时，用 TonBoVPN 的独享 IP 线路替换掉原本不稳定的共享出口，同样的请求超时率明显下降，原因是独享出口不会被其他用户的异常流量拖累。
用 curl 把每一段耗时拆开看
前面几步提到 curl -v,实际排查时还可以让它直接输出各阶段耗时,一眼看出时间花在了哪里:
curl -o /dev/null -s -w "dns=%{time_namelookup} tcp=%{time_connect} tls=%{time_appconnect} total=%{time_total}\n" https://api.anthropic.com这条命令不关心返回内容,只看四个数字。读法如下:
| 数字偏大的阶段 | 说明 | 处理方向 |
|---|---|---|
| dns | 域名解析慢或失败 | 更换公共 DNS,检查加速工具的 DNS 设置 |
| tcp 与 dns 的差值 | 建立连接慢,出口线路延迟高或有丢包 | 换出口线路对照测试 |
| tls 与 tcp 的差值 | 握手阶段慢,常见于丢包导致的重传 | 多测几次看是否波动,波动大说明链路不稳 |
| total 远大于前三项之和 | 连接建立后传输阶段慢 | 留意是否在高峰时段,尝试换时间或线路 |
单次结果意义有限,建议连续测五到十次,看数值是稳定偏高还是忽高忽低,后者更像出口质量不稳。
终端为什么不走系统代理
这是第五步里最容易被忽略的一点:很多命令行工具并不会自动继承系统层面的代理设置,浏览器能正常访问,不代表终端里的 Claude Code 也走了同一条路。可以用 env | grep -i proxy 查看当前终端里是否设置了 HTTPS_PROXY、HTTP_PROXY,以及端口是否和加速工具当前监听的端口一致。同一个终端窗口里设置的变量,只对该窗口以及之后从它启动的进程生效,换了窗口要重新确认。
另外,官方 CLI 自带诊断类命令(例如 claude doctor),可以检查安装与环境状况,具体用法以当前官方文档为准。
第七步：仍未解决时如何进一步定位
如果换线路后问题依旧，再收集完整的请求日志（时间戳、报错码、涉及的域名）提交给对应支持渠道，这类信息能帮排查者判断是服务端问题还是特定链路的问题，比一句"连不上"有效得多。
