Claude Code 频繁断连、SSE 中断？终端网络环境排查指南
Claude Code 输出到一半突然停掉、打字速度忽快忽慢、频繁提示 connection error？你遇到的不是 AI 不稳定，而是终端网络环境没有针对长连接做适配。
关键词：Claude Code 断连、SSE 中断、Claude CLI 网络、Anthropic API 排查
最后更新： · 内容维护：易联 Residential IP Solution
api.anthropic.com 的 SSE（Server-Sent Events）长连接流式输出，和 claude.ai 网页端的 HTTP 短连接完全不一个量级的网络要求。网页端能打开不代表 CLI 环境稳定。导致断连的根因大多在 IP 类型 + DNS + 中转链路 + MTU 这四层。下面从最常见到最隐蔽，一层一层排查。- Claude Code 走 api.anthropic.com 的 SSE 长连接，网页能打开不代表终端环境稳定。
- 断连的根因多在四层：出口 IP 类型、DNS 解析、链路质量、MTU；按顺序一层层排查。
- 先用 curl ipinfo.io/json 和 curl -v 看出口类型与 TLS 握手，基础不干净，后面都白查。
第一层：我的出口 IP 到底干不干净？（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 是最快见效的办法。
这一步可以交给 Agent Skill 来做
IP 判官有一个终端出口自检的 Agent Skill。装上之后，在 Claude Code 里说一句「检查终端出口」，它会运行同一个只读检查，并把结果整理成这几项：api.anthropic.com 看到的出口、不走代理时的出口、这个出口 IP 的判定，以及本次没能完成的项。未完成会明确标出来，不会当成通过。检查本身不修改任何设置。看源码。
npx skills add ipjudge/ipjudge --skill ipjudge-exit-check --agent claude-code
第二层：Claude Code 特别慢，会不会是 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 查询回退本地。
第三层：能连上但一直断流，是链路问题吗？
是。如果头几个 token 正常返回、中途才断，九成是链路问题而不是限流——限流会直接返回 429。
跨境链路的质量差异极大：有些便宜机房中转的中间跳数超过 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 就已经偏慢了。
如果链路质量差到丢包明显、延迟高且波动大，你需要在「链路更稳的中转」和「换一个更近的出口」之间选择。具体哪一种更好，以你本地实测的延迟和丢包为准。
第四层：输出到一半突然停住，为什么 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 却说连接已关闭？
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——是所有优化的前提。