Claude Code 输出到一半突然停掉，是网络问题还是 API 限流？

Claude Code 走的是 SSE（Server-Sent Events）流式长连接。如果服务端已经成功返回了头几个 token、中途突然中断，一般不是限流（限流通常会直接返回 429），而是链路层面的问题——可能是 DNS 解析被拦截、MTU 不匹配导致分片丢失、中转出口抖动、或者本地代理客户端的连接维持时间过短。建议先排查链路稳定性，再怀疑账号或配额问题。

接了代理后 Claude Code 能启动但回答特别慢，怎么加速？

慢通常有三层原因：一是 DNS 解析没走代理——本地 DNS 把 api.anthropic.com 解析到了远距离节点、增加首包延迟；二是代理出口到 Anthropic 的中间链路跳数多、延迟高（有些机房 IP 的中转段超过 15 跳）；三是本地 MTU 过大导致 TCP 分片重传。最快见效的优化是把 DNS 改为远程解析、并确保出口 IP 距离 Anthropic 服务节点较近（美西最好）。

Claude Code 和 claude.ai 网页端的网络问题一样吗？

不一样。网页端 claude.ai 的验证偏风控信号（IP 归属类型、账号地区一致性），断连少见；Claude Code 走的是 api.anthropic.com 的 API 网关，对长连接稳定性要求高得多。一个很常见的情况是网页端正常但 CLI 各种断——这说明 IP 本身没被标记，但通往 Anthropic API 的中转链路质量不好。解决方案是用美国住宅 IP（最短路径、低跳数）替代机房中转。

怎么确认是本地环境还是代理的问题？

一个简单的方法：在代理环境下执行 curl -v https://api.anthropic.com/v1/messages，观察 TLS 握手是否顺畅（有 SSL connection using TLS 字样则 OK）；然后去掉代理、用本地网络直连一遍对比。如果代理环境下 TLS 握手耗时明显长（>800ms）或反复 reset，说明问题出在代理链路。另外可以 ping api.anthropic.com 看丢包率——丢包超过 5% 就值得换出口了。

换成住宅 IP 之后 Claude Code 还会断吗？

住宅 IP 解决的是 IP 归属类型和地区一致性问题，这是基础。但即使是住宅 IP，如果从中国大陆到美国住宅的中转链路质量差、或者本地 DNS 没配好，仍然可能出现延迟高和偶发断流。最好的配置是：固定一个美国住宅 IP + 远程 DNS + 加密隧道（WireGuard / VLESS）+ 适当调整 MTU。四层一起做好，断连概率会降到非常低。

Claude Code · 开发者

Claude Code 频繁断连、SSE 中断？终端网络环境排查指南

Claude Code 输出到一半突然停掉、打字速度忽快忽慢、频繁提示 connection error？你遇到的不是 AI 不稳定，而是终端网络环境没有针对长连接做适配。

关键词：Claude Code 断连、SSE 中断、Claude CLI 网络、Anthropic API 排查

先讲结论：Claude Code（CLI 编程工具）走的是 api.anthropic.com 的 SSE（Server-Sent Events）长连接流式输出，和 claude.ai 网页端的 HTTP 短连接完全不一个量级的网络要求。网页端能打开不代表 CLI 环境稳定。导致断连的根因大多在 IP 类型 + DNS + 中转链路 + MTU 这四层。下面从最常见到最隐蔽，一层一层排查。

第一层：确认网络环境基准（10 秒自查）

Claude Code 的 CLI 本质是一个 HTTP 客户端，它通过你在终端或系统代理设置里配的 HTTP(S)_PROXY 访问外部 API。第一步是确认出口 IP 的"身份"是否干净：

查 IP 类型：在终端执行 curl https://ipinfo.io/json，看 org 字段。如果返回 AS15169 Google LLC / AS14061 DigitalOcean / AS20473 Vultr 这类云服务商 ASN，说明出口是机房 IP。Claude Code 的请求对这种出口的容忍度比网页端更低——因为 API 网关对请求模式的异常更敏感。
看 IP 一致性：确认 ipinfo 返回的 country/city 和你预期的一致。如果你在美国注册的 Claude 账号、出口 IP 却显示其他国家，地区跳变会叠加风险。
检查 TLS 握手：执行 curl -v https://api.anthropic.com/v1/messages 看 TLS 阶段是否正常。如果看到 ssl handshake failed / connection reset 反复出现，基础连接就有问题。

如果基础网络不通或不干净，后面的排查可以跳过——直接换个干净的美国住宅 IP 是最快见效的办法。

第二层：DNS 配置 —— 最容易忽略的瓶颈

很多 CLI 用户的终端继承了系统 DNS 设置，而系统 DNS 往往走的是本地运营商。这导致 api.anthropic.com 被解析到离你很远、甚至和出口 IP 地理矛盾的节点。对 Claude Code 的 SSE 流来说，DNS 解析慢 = 首包延迟高，而「IP 在美国、DNS 在国内」的地理矛盾也是 Anthropic 风控信号。

排查：

连接到代理后，终端执行 nslookup api.anthropic.com —— 看返回的 IP 是否在你出口 IP 的同一地区。
执行 dig api.anthropic.com +short @1.1.1.1 用 Cloudflare DNS 解析一次作为对照。如果本地解析快很多但 IP 不一致，说明你的 DNS 走了本地。

修复：在代理客户端的 DNS 设置中切换为远程解析（Remote DNS）。如果你用的是系统代理 + HTTP_PROXY 环境变量，在 ~/.zshrc 或 ~/.bashrc 里补充 export no_proxy=localhost,127.0.0.1 避免 DNS 查询回退本地。

第三层：中转链路 —— 跳数多、抖动大

从中国大陆到 api.anthropic.com 不可能直连（GFW 会 reset）。所有请求都必须经过中转。而中转的质量差异极大：有些便宜机房中转的中间跳数超过 15 跳、丢包率 5% 以上，对普通网页浏览可能没感觉，但对 SSE 长连接的破坏是致命的——每一次丢包都可能导致流中断或重新 connect。

怎么排查链路质量：

traceroute / MTR：执行 mtr -r api.anthropic.com 看中间经过多少跳，重点看第 3-5 跳的延迟和丢包率。如果中国到香港段就 80ms+ 且波动大，链路质量不好。
ping 丢包率：执行 ping -c 50 api.anthropic.com 测 50 个包，丢包超过 5% 说明链路不可靠。
测首包延迟：在代理下 curl API 时看 -w "%{time_connect} / %{time_starttransfer}"，TLS 握手 > 800ms 就已经偏慢了。

如果链路质量差到丢包明显、延迟高且波动大，你需要在「链路更稳的中转」和「换一个更近的出口」之间选择。一般情况下，经香港中转的美国住宅 IP 对大陆用户的链路最均衡（HK 段短 + 美国段直连 Anthropic）。

第四层：MTU 与本地网络栈

MTU（最大传输单元）是特别隐蔽的一个坑。如果你的本地网络 MTU 偏大（比如 1500），但中转加密隧道有额外报头占用，产生的包超过链路最大尺寸，就会被中间路由器静默丢弃——你的 SSH/CLI 不报错，但 Claude Code 的输出就是会突然停住。

排查：

在代理下执行 ping -M do -s 1472 -c 3 api.anthropic.com 看是否需要分片。
如果 ping 大包失败或延迟异常增大，在你的代理客户端或 WireGuard 配置里把 MTU 降低到 1300-1400。
用 clash/stash/sing-box 的用户：检查 global-client-fingerprint 和 utls 设置，部分指纹模拟会导致额外的 TLS record 分层，增加 MTU 压力。

第五层：代理客户端的连接保持

Claude Code 的 SSE 长连接在"思考"和"生成"两阶段都可能持续几十秒甚至几分钟。如果你的代理客户端或系统防火墙把长连接判定为"空闲连接"并自动切断，就会出现「明明 API 没问题但 Claude Code 说 connection closed」的情况。

排查：

确认代理客户端有没有 keepalive / timeout / idle timeout 配置。有的话调到 300 秒以上。
macOS 用户：系统默认的 TCP keepalive 较短。执行 sysctl net.inet.tcp.keepidle 看当前值（默认 7200000=2小时，通常是够的——但如果被改过就可能不对）。
如果你用的代理加密隧道（WireGuard / VLESS）是 UDP 承载的，确认 UDP 会话没有被 NAT 或路由器超时丢弃。

动手顺序：一个拿到就做、越做越排查的路

先去 AI IP 检测页看 IP 类型和 DNS
用 curl -v https://api.anthropic.com/v1/messages 做 TLS 基准
接上代理后重复 TLS 检测，对比延迟和成功率
改 DNS 为远程解析
测 MTR / ping 丢包，判断链路是否需要更换
调 MTU 到 1300-1400
确保代理客户端 keepalive ≥ 300s

如果前三点做完已有明显改善，后面可以先不做。反之，越往下走越接近真因。

大多数 Claude Code 的"不稳定"，本质是机房 IP + 本地 DNS + 劣质中转链路三者叠加。解决这三个，剩下的调 MTU / keepalive 属于锦上添花。第一步——确认出口 IP 是干净的住宅 IP——是所有优化的前提。

检测当前 IP 纯净度查看住宅 IP 套餐