AI 编程工具流式响应频繁中断？排查到最后是网络出口的问题

用 Claude Code、Cursor、GitHub Copilot 这类 AI 编程工具的人，应该都遇到过这种情况：代码生成到一半突然停了，光标闪了两下，然后弹出一句 Connection interrupted 或者干脆没有任何提示，输入框重新变回空白。

重试一次，好了。再跑一会儿，又断了。

这种问题最烦人的地方在于它不报错。日志里看不到异常堆栈，代码逻辑没有 bug，IDE 也没崩溃。你甚至没法确定它下次会不会断。

排查一圈之后，问题往往指向同一个地方：流式响应的连接被中途切断了。

一、流式响应和普通请求有什么不一样？

普通 HTTP 请求是“一问一答”：你发一个请求，服务器返回完整响应，连接关闭。

AI 编程工具的请求模式不是这样。它们几乎全部采用 SSE（Server-Sent Events） 或类似的流式传输方式：服务器返回的不是一次性响应体，而是一个持续推送的数据流。模型每生成一个 token，就往这个流里写一段数据，客户端边接收边渲染。

这种模式对网络的要求比普通请求高得多：

• 连接必须长期保持：一次代码生成可能持续几十秒到几分钟，期间连接不能断
• 不能有中间层缓冲：如果中间经过了会缓冲数据的节点，token 就不是“流式”到达的，而是一次性攒一堆再吐出来，体验直接崩掉
• 任何一次中断都会导致整个响应作废：不像普通请求可以断点重试，流断了就是断了，前面的 token 白生成

这就是为什么用同样的网络环境，浏览网页完全正常，但 AI 编程工具就是频繁断连。

二、几个具体的触发原因

原因一：网络出口的 MTU 不匹配

这个最隐蔽。某些网络出口的 MTU（最大传输单元）设置和链路实际支持的 MTU 不一致，导致大包被分片或者直接丢弃。普通请求因为数据量小，感觉不出来；流式响应持续传输大量小包，分片和重传的概率被成倍放大，表现出来就是连接时不时卡一下，最后超时断开。

表现：能连上，但流式响应经常中途卡住，等待十几秒后报超时。

排查方式：

# 测试 MTU 是否正常，逐步减小包大小直到不再分片
ping -M do -s 1472 gateway.example.com

原因二：出口 IP 被限速或降级

有些网络出口对特定类型的流量做了 QoS 限速。流式响应因为长时间占用连接，容易触发限速策略，导致 token 推送变慢，最终超时。

表现：响应不是直接断，而是越来越慢，最后卡死。

原因三：中间节点主动断开长连接

部分网络出口会在连接空闲一定时间后强制断开，或者对长连接做周期性重置。AI 编程工具的流式响应期间，虽然数据在持续推送，但在网络层看来，如果推送间隔较长（比如模型在“思考”阶段不输出 token），这个连接就可能被判定为空闲连接，被中间节点掐断。

表现：简单问题正常，复杂问题（模型思考时间长）频繁断开。

原因四：出口 IP 类型被识别

这一点和 API 网关的风控有关。数据中心 IP（AWS、GCP 等云服务商的 IP 段）在 AI 服务商的访问控制系统中信任等级偏低，可能被分配更严格的连接策略——包括更短的超时阈值、更激进的限流。

表现：换了网络环境之后，同样的代码同样的工具，稳定性明显不一样。

三、怎么定位问题到底出在哪一层

排查流式响应中断，建议按这个顺序走：

第一步：确认是不是工具本身的问题

换一个网络环境（比如手机热点）跑同样的任务。如果问题消失，说明是网络出口的问题。如果问题依旧，那可能是工具版本或者账号层面的问题。

第二步：测试网络出口的长连接稳定性

用 curl 测试 SSE 端点的连接能维持多久：

# 测试到 SSE 端点的连接稳定性，观察多久会断开
curl -N -H "Accept: text/event-stream" \
     https://api.example.com/stream \
     --max-time 300

如果连接在几分钟内被主动断开，说明出口存在长连接限制。

第三步：检查出口 IP 的类型

访问 IP 检测服务，确认出口 IP 的 ASN 归属。如果是云服务商（AWS、GCP、Azure 等），基本可以确定是 IP 类型导致的连接策略收紧。

四、配置示例

如果确认是出口 IP 的问题，可以换用住宅 IP 作为网络出口。住宅 IP 的 ASN 归属于当地运营商，在服务商的访问控制系统中不会被判定为数据中心流量，连接策略相对宽松。

以下是以 1024Proxy 长效静态住宅 IP 为例的配置方式：

# ============================================
# 使用 1024Proxy 住宅 IP 作为网络出口
# 官网：https://1024proxy.com/?kwd=hyj-txy
# ============================================

import httpx

# 住宅 IP 出口配置
proxy_url = "http://用户名:密码@gateway.1024proxy.com:端口"

# httpx 支持流式响应，配合住宅 IP 出口使用
with httpx.Client(
    proxy=proxy_url,
    timeout=httpx.Timeout(connect=10.0, read=120.0, write=10.0, pool=10.0)
) as client:
    with client.stream(
        "POST",
        "https://api.example.com/v1/chat/completions",
        json={
            "model": "your-model",
            "stream": True,
            "messages": [{"role": "user", "content": "写一个快速排序"}]
        }
    ) as response:
        for line in response.iter_lines():
            if line:
                print(line)

关键点：

timeout 里的 read 参数要设长一点。流式响应期间，模型可能在“思考”阶段长时间不输出 token，如果 read 超时设得太短，连接会被客户端主动断开。建议设在 60-120 秒之间。

如果用的是 Claude Code 这类命令行工具，通过环境变量配置出口：

# ============================================
# 使用 1024Proxy 住宅 IP 作为网络出口
# 官网：https://1024proxy.com/?kwd=hyj-txy
# ============================================

export HTTPS_PROXY=http://用户名:密码@gateway.1024proxy.com:端口
export HTTP_PROXY=http://用户名:密码@gateway.1024proxy.com:端口

# 关闭 HTTP/2，避免部分出口对 HTTP/2 长连接的限制
export NODE_OPTIONS="--no-http2"

五、几个容易忽略的细节

别把 read timeout 设太短。这是流式响应最常见的坑。普通请求 30 秒超时足够，但流式响应在模型思考阶段可能一分钟都不输出数据，超时设短了会误杀正常连接。

HTTP/2 不一定是好事。部分网络出口对 HTTP/2 长连接的支持不完善，反而更容易触发中断。遇到问题时可以试试禁用 HTTP/2。

连接池大小要匹配并发数。如果同时跑多个 AI 编程会话，连接池太小会导致新连接排队等待，表现出来也是“卡住”。

出口 IP 先测再用。1024Proxy 新用户有免费试用额度，先跑几十个流式请求，确认出口的稳定性，再决定是否长期使用。

流式响应的稳定性，最终取决于网络出口能不能稳定地维持长连接。工具版本、模型参数、代码逻辑都排查完之后，如果问题还在，就回头看看出口 IP 那一层。