AI 长连接（SSE/WebSocket）频繁断流？延迟与丢包的根因排查与优化

用 ChatGPT/Claude/Gemini 时输出到一半突然停住、过几秒又蹦出一段、或者干脆报 network error——这不是 AI 故障，是你的网络环境没针对长连接做适配。

关键词：SSE 断流、AI 长连接优化、Claude 网络中断、WebSocket 延迟、MTU TCP 排查

第一层：出口 IP —— 地基不牢一切白搭

出口 IP 的"身份"是 AI 长连接的第一道关：

• 数据中心 IP：ASN 归属云服务商（AWS/GCP/DO/Vultr 等）。AI 服务商的风控模型对这类 IP 的"连接保持信任度"较低——即使首包通过了，后续的持续连接也可能被中间审查节点掐断。
• 共享 IP / 轮换 IP：如果同一个 IP 同时有多个用户在做 AI 请求（常见于公共机场的出口），AI 服务端可能因并发数异常而主动限速或中断。
• 住宅 IP：ISP 分配的独享 IP。ASN 不在"数据中心"名单里，AI 服务对它的长连接信任度最高，不容易被中途掐断。

第一层不是让你"翻墙"，是让你的出口在 AI 服务的判断里看起来像一个正常的、合法的个人用户。

第二层：DNS 解析 —— 延迟的第一责任人

DNS 是对延迟影响最大、却最容易被忽略的一层。

核心矛盾：如果你的代理客户端的 DNS 设置是"本地解析"（Local DNS），系统会用你大陆运营商的 DNS 去解析 api.anthropic.com / api.openai.com。这些域名的 CDN/Anycast 会根据 DNS 来源返回离中国大陆最近的节点——但这个节点往往不在你代理出口的同一地区。结果：出口 IP 在美国，但 DNS 把域名解析到新加坡或日本的 IP——延迟凭空多了几十毫秒，且地区不一致是附加风控信号。

解法：把代理客户端的 DNS 策略从"本地解析"改为"远程解析"（Remote DNS / DNS over Proxy）。出口在哪里，DNS 就在哪里解析——做到 IP 和 DNS 在同一地区。

验证方法：

• 在代理下执行 curl -v https://api.anthropic.com/v1/messages 2>&1 | grep "TLS" 看握手时间。
• 对比关代理直连和开代理的 TLS 握手耗时——开代理后应该 ≤800ms（美国西海岸正常延迟）。

第三层：中转链路 —— 长连接的隐形杀手

从中国大陆无法直连到美国的 AI 服务（GFW 会发 TCP Reset 掐断）。所有请求必须经过中转。中转链路的质量用三个指标衡量：

• 跳数（Hops）：用 mtr -r api.anthropic.com 数中间经过多少跳。如果是中→港→美三段，期望 10-15 跳。超过 18 跳说明路由很差。
• 丢包率（Packet Loss）：用 ping -c 50 api.anthropic.com 测。丢包 >5% 意味着每 20 秒左右就可能有一个包丢失，对应 AI 流式输出的大约每 20 秒一次"卡住"。
• 抖动（Jitter）：延迟的变化幅度。用 mtr -r 看每跳的 Avg 和 Max 差值。Max - Avg > 40ms 说明这跳不稳定。

链路选择建议：

• 电信用户 → 走 CN2 GIA 或 4837 中美直连（延迟最优）
• 联通用户 → 走 9929 中美直连或经香港中转
• 移动用户 → 走 CMIN2 或经香港中转
• 三网通用最稳方案 → 经香港中转的美国住宅 IP（HK 段就近 + 直连美国住宅，延迟均衡在 190-220ms）

第四层：MTU 与 TCP MSS —— 最隐蔽的坑

MTU（Maximum Transmission Unit，最大传输单元）决定了每个 IP 包的上限。如果你的网络环境和 AI 服务端之间的 MTU 不匹配，大的 TCP 包会被中间路由器静默丢弃——不报错、不通知、就像什么都没发生。TCP 会尝试重传，但同样大小的包还是被丢，结果就是连接卡住不动。

为什么加密隧道会让情况更糟：

• 隧道加密头（VLESS/XTLS ~40 字节、WireGuard ~60 字节、OpenVPN ~40-80 字节）占用 MTU 的空间
• 你的本地 MTU 可能是 1500，但隧道路径上的链路 MTU 可能只有 1460 或更低
• TCP 三次握手时协商的 MSS（最大段大小）不包含隧道头，协商出来的是错的
• 结果：发出去的包 > 真实 MTU → 被扔 → 连接卡住

排查方法：

1. 用 ping -M do -s 1472 -c 3 api.anthropic.com 发大包测试，如果有分片告警，MTU 有问题。
2. 从 1400 开始逐渐加大，找到刚好能过不需要分片的最大值。
3. 在代理客户端或 VPN 配置里设这个值。

建议值：用 WireGuard 的设 MTU=1380；用 VLESS/Vision 的设全局 MTU 1300-1400；用 Clash/Stash 的检查 tun.mtu 设置。

第五层：Keepalive 与超时 —— "思考"时间的长连接

AI 从收到你的问题到开始输出 token 的"思考"阶段，可能持续 5-30 秒（复杂的推理任务甚至更长）。这段时间长连接是打开的但没有数据在传输。

如果中间有 NAT 设备或防火墙，它的"空闲连接超时"默认可能在 60-120 秒——超过这个时间没数据就自动切断。对于网页浏览来说这个时间完全够（一个请求 < 2 秒），但对 AI 的长时间思考就不够。

解法：

• 确认代理客户端的连接保持时长 ≥ 300 秒（5 分钟）
• 如果你用的是 UDP 承载的隧道（WireGuard / Hysteria），确认 UDP 会话的超时足够长
• macOS 用户确认 sysctl net.inet.tcp.keepidle 没被改小（默认 7200000=2小时没问题）

五层检查清单（照着做）

遇到 AI 长连接断流/卡住，按这个顺序排查，每一步都有明确的验证方法：

1. ☐ IP 类型：curl ipinfo.io/json → org 不是云服务商 → 住宅 IP ✅
2. ☐ DNS 远程解析：代理客户端 DNS 策略 = Remote → 同地区 ✅
3. ☐ TLS 基准：curl -v API → TLS 握手 ≤800ms → 正常 ✅
4. ☐ 链路跳数：mtr API → 跳数 ≤18 跳 → 正常 ✅
5. ☐ 丢包率：ping -c 50 API → 丢包 ≤3% → 正常 ✅
6. ☐ MTU：ping -M do 大包检查 → 无分片告警 → 正常 ✅
7. ☐ Keepalive：代理客户端连接保持 ≥ 300s → 正常 ✅

前 3 项是前提，修好前 3 项 80% 的断流都解决。后 4 项属于深度优化，每多修一项，稳定性再提一档。