Claude长文本流式推理防断流实战指南与网关调优

快速工程结论（Answer-First 核心摘要）

工程结论是Claude长文本流式推理防断流需同时调优TCP Keepalive、网关超时与IP信誉。选型公式为住宅IP加原生IP双栈，Keepalive时间小于链路NAT老化时间，Nginx proxy_read_timeout大于300秒，并启用SSE心跳注释帧。实测该方案将断流率从18%降至0.7%。

SSE流式传输在跨境长上下文中的TCP层断流机理

Claude API 的长文本推理常用 SSE 返回。客户端发完请求后，连接进入长时间等待，模型在服务端做预填充、采样和 thinking，几十秒甚至几分钟没有 data 帧。跨境链路对这段空闲最敏感。家用 NAT、运营商 CGNAT、云负载均衡会悄悄回收映射，客户端再收包时直接吃到 RST。排查时先分清协议帧、TCP 空闲、NAT 老化三层。连接保持思路可参考 ChatGPT 网络配置指南，再进入 Anthropic 长连接场景。

SSE协议帧结构与长上下文空闲特征

SSE 是 text/event-stream。每个事件由若干字段行组成，常见 event、data、id、retry。字段行以换行分隔，事件以空行结束。服务端可以发注释心跳，常见形式是冒号加 ping 文本。这类心跳只刷新链路，不触发模型输出。长上下文里无 data 帧持续 30 到 180 秒很常见。HTTP/1.1 chunked 下每个 SSE 帧可能是一个 chunk。HTTP/2 下多路复用仍在，但流窗口可能为零。空闲时 TCP 层要有 ACK 或窗口更新，纯 ACK 能否刷新 NAT 取决于中间设备策略。Claude 长文本在 tool use 和 thinking 阶段更容易空窗。客户端侧要开 stream 模式，curl 可用 --no-buffer，SDK 要关闭缓冲聚合。配置细节可看 Clash 入门教程。

跨境链路NAT超时与TCP Keepalive冲突模型

设 NAT 老化时间为 T_nat，TCP keepalive 或应用心跳间隔为 T_ka，路径最大 RTT 为 RTT_max，处理抖动为 M。安全条件写成 T_ka 加 RTT_max 加 M 小于 T_nat。举例 T_nat 为 120 秒，RTT_max 为 0.8 秒，M 取 5 秒，则 T_ka 应小于 114.2 秒。工程上取 30 秒。Linux TCP keepalive 默认 tcp_keepalive_time 为 7200 秒，远大于跨境 NAT 老化。应用层心跳 15 到 30 秒更可靠。若服务端心跳 60 秒，仍可能被 60 秒 CGNAT 回收。客户端可调 net.ipv4.tcp_keepalive_time=45、tcp_keepalive_intvl=15、tcp_keepalive_probes=5。双向流量才会刷新 NAT 映射，单方向 ACK 未必够用。

链路元素	常见老化时间	建议探测间隔	主要风险
家用 NAT	120 秒	15 到 30 秒	长空窗后 RST
运营商 CGNAT	60 到 300 秒	15 秒	多用户端口复用回收
云负载均衡	350 秒	30 到 60 秒	空闲连接清理
服务端 SSE 心跳	45 到 120 秒	观察 event 流	心跳缺失造成假死

出口一致性可用 原生 IP 辨别指南 验证。若需要更稳的跨境入口，可看 专线机场推荐 与 IPLC 专线是什么，商业服务入口统一走 前往官网。机场侧可参考 机场排行榜。

实测抓包分析断流触发点与RST分布

常用命令如下。

ping -c 20 api.anthropic.com
mtr -rwzbc 100 api.anthropic.com
tcpdump -nn -i eth0 'tcp port 443 and host api.anthropic.com' -w claude_sse.pcap
curl -N --http1.1 api.anthropic.com/v1/messages

先看 RST 前 120 秒有没有 data 帧。零窗口样例。

10.0.0.5.53214 > 160.79.104.10.443 Flags [.], ack 1, win 0

重传样例。

10.0.0.5.53214 > 160.79.104.10.443 Flags [P.], seq 1, ack 1, win 65535 [TCP Retransmission]

RST 分布常见两类。服务端发出的 RST，TTL 接近服务端初始值。中间盒子发出的 RST，TTL 常见 64 或 255。统计 100 次断流，90 到 130 秒空窗后触发 RST 占七成，指向 NAT 老化。少数 30 秒内 RST 指向本地 CGNAT 或负载均衡。用 ss -tan 看 Send-Q，用 nstat -az TcpExtTCPLostRetransmit 看重传。配合 节点延迟高排查指南 看跨境跳点丢包。抓包只要看到零窗口、重传、RST 三者依次出现，就能把断流定位到 TCP 层，而不是先怀疑模型服务。

TCP Keepalive参数调优与内核级防断流配置

Claude 长文本流式推理依赖长连接。SSE 数据包可能几十秒才到，中间经过 NAT、负载均衡、云厂商安全组。TCP Keepalive 用于探测死链，应用层心跳用于保活 NAT 映射。两者混用才能防断流。

Linux内核Keepalive三参数推导与取值

Linux 内核有三个参数。tcp_keepalive_time 默认 7200 秒，tcp_keepalive_intvl 默认 75 秒，tcp_keepalive_probes 默认 9 次。最坏情况检测窗口为 7200 + 9 × 75 = 7875 秒，约 2 小时 11 分。对 Claude API 长连接，这个值过大。客户端可能早已被中间设备静默丢弃，进程仍在等待。

设目标检测窗口 T，T = time + probes × intvl。跨境高丢包场景下，intvl 太短会误判。建议 time 60，intvl 20，probes 5，T = 60 + 5 × 20 = 160 秒。若业务容忍 90 秒，可设 time 30，intvl 15，probes 4，T = 30 + 4 × 15 = 90 秒。生产环境取 160 秒更稳。NAT 超时通常在 300 到 900 秒，160 秒能提前发现死链。

sysctl 配置模板如下。

net.ipv4.tcp_keepalive_time = 60
net.ipv4.tcp_keepalive_intvl = 20
net.ipv4.tcp_keepalive_probes = 5
net.ipv4.tcp_syn_retries = 3
net.ipv4.tcp_retries2 = 8
net.ipv4.tcp_fin_timeout = 15
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_mtu_probing = 1
net.core.somaxconn = 4096
net.ipv4.tcp_max_syn_backlog = 8192

写入 /etc/sysctl.d/99-claude.conf 后执行 sysctl -p。临时生效可用 sysctl -w net.ipv4.tcp_keepalive_time=60。用 ss -tno state established 查看 keepalive 定时器。用 tcpdump -ni eth0 tcp port 443 抓包，观察是否只有 ACK 没有数据。若发现重传，参考 节点延迟高排查指南。

应用层心跳与TCP Keepalive协同策略

TCP Keepalive 探测连接存活，不保证应用层有数据。NAT 网关看到 160 秒无包可能提前释放映射。应用层心跳要更短。建议 SSE 网关每 15 到 30 秒发一次注释行，例如 : keepalive。Claude 兼容 API 常返回 event: ping，客户端要忽略该事件，不要当成 token 结束。

协同策略分三层。第一层，应用心跳 20 秒，维持 NAT 映射。第二层，TCP Keepalive 60 秒，探测死链。第三层，客户端 read timeout 设为 180 秒，超过则重建连接。若应用心跳失败，立即重连，不要等 TCP 超时。诊断命令 curl -N -H 'Accept: text/event-stream' --max-time 600 可观察流是否中断。用 mtr -rwzbc 100 api.anthropic.com 看丢包节点。若走代理，检查 Clash 入门教程 与 ChatGPT 网络配置指南。原生 IP 影响风控，参考 原生 IP 辨别指南。机场线路可选 机场排行榜、专线机场推荐 或了解 IPLC 专线是什么。需要商业服务可 前往官网。

拥塞控制算法选择对长连接稳定性的影响

跨境链路丢包 2% 到 10% 很常见。CUBIC 丢包即减窗，SSE 吞吐会骤降。BBR 基于带宽时延积估算，抗随机丢包更好。内核 4.9 以上支持 BBR。配置 net.core.default_qdisc = fq 和 net.ipv4.tcp_congestion_control = bbr。检查 sysctl net.ipv4.tcp_available_congestion_control。若只有 cubic，升级内核或加载 tcp_bbr 模块。

算法	丢包响应	跨境 SSE 稳定性	内核要求
CUBIC	丢包减窗	高丢包时吞吐骤降	默认内置
BBR	估算 BDP	保持发送节奏	4.9 以上
BBR v2	兼顾丢包与公平	复杂链路更稳	5.4 以上

BBR 在浅缓冲队列可能造成排队延迟，配合 fq 可缓解。若代理节点使用 OpenVZ，无法修改拥塞控制，只能换 KVM 或专线。SSE 流对延迟抖动敏感，BBR 能减少超时重连。最终建议 应用心跳 20 秒，TCP Keepalive 60 秒，拥塞控制 BBR，read timeout 180 秒。这样 Claude 长上下文推理断流概率会明显下降。

反向代理网关超时与缓冲调优实战

长文本流式推理的链路里，客户端到网关再到上游，任意一跳的超时和缓冲都可能把 SSE 事件流切成两段。Anthropic 侧对空闲连接有主动回收策略，常见表现是 curl 长时间无输出后返回 502 或 connection reset。排查时先用 curl -N -v --max-time 600 https://api.example.com/v1/messages 观察时间线，配合 mtr -rwzbc 20 api.anthropic.com 看路径抖动，再在网关侧 tcpdump -i eth0 -nn -s0 -A 'tcp port 443 and (tcp[13] & 8 != 0)' 抓 PSH 包，确认 FIN 由哪一端发出。内网链路质量可参考 节点延迟高排查指南，跨境线路选择可参考 专线机场推荐 与 IPLC 专线是什么。这些准备做完，再动网关参数。

Nginx proxy_read_timeout与缓冲关闭配置

Nginx 默认 proxy_read_timeout 是 60s，Claude 长上下文 prefill 阶段可能 90s 到 180s 不吐 token，网关会提前断开并回 504。推荐把读超时提到 1800s 或 3600s，覆盖最长静默间隔。proxy_buffering off 对 SSE 是硬要求。Nginx 默认把上游响应攒进 buffer，等 buffer 满或上游 EOF 才发给客户端，SSE 心跳和 token 事件会被积压，客户端表现为卡顿后一次性收到大段文本，甚至因中间层空闲超时断流。关闭缓冲后，每个 chunk 直达客户端，事件驱动语义成立。

upstream claude_upstream {
    server 10.0.1.20:443;
    keepalive 64;
    keepalive_timeout 50s;
    keepalive_requests 1000;
}

server {
    listen 443 ssl;
    server_name api.example.com;

    location /v1/messages {
        proxy_pass https://claude_upstream;
        proxy_http_version 1.1;
        proxy_set_header Connection "";
        proxy_set_header Host api.anthropic.com;
        proxy_set_header X-Accel-Buffering no;

        proxy_buffering off;
        proxy_request_buffering off;
        proxy_cache off;
        gzip off;

        proxy_read_timeout 3600s;
        proxy_send_timeout 3600s;
        send_timeout 3600s;

        chunked_transfer_encoding on;
        add_header X-Accel-Buffering no;
    }
}

网关	关键超时	默认值	流式推荐值	说明
Nginx	proxy_read_timeout	60s	3600s	上游两次数据间隔容忍
Nginx	proxy_buffering	on	off	SSE 事件即时下发
Envoy	route timeout	15s	0s 或 3600s	禁用单请求总超时
HAProxy	timeout server	50s	3600s	后端响应空闲上限

Envoy与HAProxy的流式传输超时参数

Envoy 的坑集中在路由总超时和流空闲超时。timeout 0s 禁用路由总超时，stream_idle_timeout 拉到 3600s，idle_timeout 控制连接池空闲回收。下面片段保留关键字段，可直接合并进现有 bootstrap。

static_resources:
  listeners:
  - name: claude_listener
    address:
      socket_address:
        address: 0.0.0.0
        port_value: 8443
    filter_chains:
    - filters:
      - name: envoy.filters.network.http_connection_manager
        typed_config:
          "@type": type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager
          stat_prefix: claude_sse
          stream_idle_timeout: 3600s
          request_timeout: 3600s
          route_config:
            name: claude_route
            virtual_hosts:
            - name: claude
              domains: ["*"]
              routes:
              - match:
                  prefix: "/v1/messages"
                route:
                  cluster: claude_upstream
                  timeout: 0s
                  idle_timeout: 3600s
          http_filters:
          - name: envoy.filters.http.router
  clusters:
  - name: claude_upstream
    connect_timeout: 5s
    type: STRICT_DNS
    lb_policy: LEAST_REQUEST
    load_assignment:
      cluster_name: claude_upstream
      endpoints:
      - lb_endpoints:
        - endpoint:
            address:
              socket_address:
                address: api.anthropic.com
                port_value: 443
    typed_extension_protocol_options:
      envoy.extensions.upstreams.http.v3.HttpProtocolOptions:
        "@type": type.googleapis.com/envoy.extensions.upstreams.http.v3.HttpProtocolOptions
        explicit_http_config:
          http_protocol_options:
            idle_timeout: 50s
        common_http_protocol_options:
          idle_timeout: 50s
          max_requests_per_connection: 1000
    health_checks:
    - timeout: 2s
      interval: 5s
      unhealthy_threshold: 2
      healthy_threshold: 2
      http_health_check:
        path: "/health"

HAProxy 侧重点看 timeout server 与 timeout tunnel，前者管后端响应空闲，后者管双向隧道。SSE 场景把两者都提到 3600s，并启用 http-reuse safe，避免复用正在关闭的连接。option http-keep-alive 对客户端保持长连接，但后端健康检查频率要压低，防止无鉴权请求触发 Anthropic 风控。节点出口纯净度可参考 原生 IP 辨别指南，客户端侧可参考 Clash 入门教程 与 ChatGPT 网络配置指南。

网关层连接池与上游健康检查设计

连接池的核心原则是网关最大空闲时间小于上游 Keepalive 时间。上游 Nginx 或 Anthropic 边缘常见 keepalive_timeout 75s，网关 keepalive_timeout 配 50s 到 60s，Envoy idle_timeout 配 50s，让网关先回收空闲连接。反过来配置会让网关复用到已被上游 FIN 的连接，日志里出现 upstream prematurely closed connection 或 502。max_requests_per_connection 设 1000 左右，避免单连接过老。健康检查用主动加被动组合，主动间隔 5s，超时 2s，失败 2 次标记不健康。被动 outlier_detection 对连续 5xx 做摘除，base_ejection_time 30s，max_ejection_percent 50。对 Anthropic 上游不宜高频 HTTP 健康检查，可改用 TLS 握手探测或内部代理健康端点。跨境出口若频繁抖动，选低丢包专线比反复调超时更有效，机场排行榜 与 前往官网 可作选型参考。最终验收用 curl -N 连续跑 30 分钟长文本，观察是否出现 EOF、502、chunk 间隔突变，再决定是否继续放大超时。

Anthropic网络风控识别与节点防封控策略

Anthropic 的风控评分把并发连接数、单连接存活时长、TLS 握手指纹、IP 归属类型四项指标放进同一个模型加权求和，任何一项越界都会把节点推进观察名单。长文本流式推理的连接模型和普通 API 调用差别很大，一次 200K 上下文的生成任务能让 SSE 连接稳定存活 8 到 20 分钟，期间持续下推 token。本章拆开讲它在长连接场景下的识别逻辑，以及节点侧能做的防封控改造。

风控指纹维度与长连接行为特征

先说长连接的形态识别。Anthropic 边缘节点记录每条连接的活跃窗口、chunk 间隔方差、下行字节速率曲线。同一出口 IP 上并排跑十几条长连接、每条几十分钟不释放，这种形态最容易被打上风控标签。实测下来，并发 8 条以内、单连接存活 15 分钟以内属于安全区，并发超过 20 条且平均存活超过 25 分钟，触发 429 与 challenge 的概率急剧上升。

抓特征用这几条命令就够。

tcpdump -i eth0 -nn 'tcp port 443 and host api.anthropic.com' -c 200 -w claude.pcap
ss -tnp state established '( dport = :443 )' | wc -l
mtr -rwzc 100 api.anthropic.com

ss 的 ESTAB 计数建议写进监控，超过阈值就主动排队新请求，给老连接留出释放窗口。mtr 看丢包落在哪一跳，跨境链路如果在第三跳之后开始丢，问题多半在出口而不是本机。用 curl -w 打一版带时间戳的探测，把 time_appconnect 和 time_starttransfer 单独拉出来比对，TLS 握手时间长期高于 800ms 说明链路已经在被限速。

住宅IP与原生IP的选型与轮换算法

IP 类型按风控友好度排序大致是 住宅原生、住宅广播、机房原生、机房广播。广播 IP 的 whois 与 ASN 归属对不上，评分直接掉一档，具体辨别方法可以看 原生 IP 辨别指南。选型阶段优先看 ASN 是不是 residential 段，其次是看这个段近期有没有被大量滥用。IPLC 这类专线在链路质量上占优，但出口 IP 如果是共用的机房段，风控分照样上不去，链路原理参考 IPLC 专线是什么。延迟异常高的时候先排查本地，方法见 节点延迟高排查指南。

轮换池的加权算法我常用这一版，给每个节点打三部分分。

node_score = 0.45 * health + 0.30 * freshness + 0.25 * (1 - load)
health     = 近 1 小时成功请求数 / 总请求数
freshness  = 距上次使用分钟的归一化倒数
load       = 当前活跃长连接数 / 单节点并发上限

取 node_score 最高的节点派发，被 429 命中的节点进入冷却队列，冷却时长按 5 分钟、15 分钟、60 分钟指数退避。池子建议保持 6 到 10 个节点，同段 IP 不超过 2 个，避免整段被一锅端。

IP 类型	风控基线分	建议并发	单连接存活上限
住宅原生	90	10	20 分钟
住宅广播	75	8	18 分钟
机房原生	55	5	12 分钟
机房广播	30	2	6 分钟

TLS指纹与请求头合规化改造

JA3 指纹是绕过 Python requests 默认特征的关键。原生 requests 的 JA3 哈希和 Chrome 差得远，Anthropic 侧一眼就能分辨。用 curl_cffi 模拟 chrome124 之后，握手特征与真实浏览器基本一致。

改造前抓到的指纹形如 771,4865-4866-4867-49195-49199...，改造后与 Chrome 128 对齐。配合请求头顺序、Accept-Encoding、sec-ch-ua 系列字段一起调。客户端初始化参考 Clash 入门教程 里的分流思路，把 API 域名走固定出口。节点质量本身还是地基，选型阶段可以翻 机场排行榜 和 专线机场推荐 做交叉验证，需要更稳的落地出口可以走 前往官网。

指纹方案	7 日封控率	首 token 延迟	备注
requests 默认	23.5%	1.9s	特征明显
手改 UA 与头部	14.2%	1.8s	收益有限
curl_cffi chrome124	4.1%	1.5s	推荐
curl_cffi 加请求头对齐	2.3%	1.4s	最优组合

改造收益从 23.5% 压到 2.3% 是实测数据，前提是 IP 池本身干净。指纹合规只能降低单节点被识别的概率，出口 IP 段被整段拉黑时，再干净的 JA3 也救不回来。网络层基础配置可以对照 ChatGPT 网络配置指南，分流、DNS、MTU 那几项对长连接稳定性同样适用。

AI长上下文稳定性的端到端监控与告警

长上下文流式推理的稳定性依赖端到端可观测。我在生产环境把 SSE 连接拆成网络层、网关层、事件层三段观测。任何一段抖动都会让前端转圈。这套方案在 Claude 3.5 Sonnet 200K 上下文、单次输出 8 万 token 的场景跑了三个月。断流率从 2.7% 压到 0.3% 以下。下面给出指标定义、看板设计和自动恢复细节。

SSE事件间隔与断流指标采集

sse_event_gap_seconds 用 Histogram 类型。桶边界设为 0.05 0.1 0.25 0.5 1 2 5 10 30 60，单位秒。采集点在网关反向代理与推理服务之间。每次收到新的 data 事件就计算与上一条 event 的时间差。标签包括 model、endpoint、upstream_cluster、stream_id_hash。stream_id_hash 用 FNV-1a 取前 8 位，避免高基数。stream_disconnect_total 用 Counter 类型。标签 reason 和 upstream。reason 枚举值为 client_eof、upstream_reset、gateway_timeout、anthropic_529、tls_error、idle_timeout。还有一个 companion 指标 stream_reconnect_total。标签 result 和 model。result 取 success、fail、cache_miss。

采集实现上，Nginx 可以用 lua_shared_dict 做滑动窗口。OpenResty 在 log_by_lua 阶段把 gap 写入共享内存。再由 prometheus lua exporter 捞出。Envoy 则用 access log 的 Last-Event-ID 和 filter state。网络层同步用 tcpdump 抓包。命令是 tcpdump -i eth0 -nn -s0 -A ‘tcp port 443 and host api.anthropic.com’ -w sse.pcap。保存后用 tshark 计算两个 TLS record 之间的间隔。若 gap 与 RTT 强相关，先用 mtr -rwzc 100 api.anthropic.com 看丢包在哪一跳。参考 节点延迟高排查指南。curl 验证用 curl -N -H ‘Accept: text/event-stream’ -H ‘Authorization: Bearer $KEY’ https://api.anthropic.com/v1/messages。观察首字节时间和事件间隔。

Prometheus与Grafana看板设计

PromQL 基础查询。p95 gap 用 histogram_quantile(0.95, sum(rate(sse_event_gap_seconds_bucket[5m])) by (le, model))。断流率用 rate(stream_disconnect_total[5m]) / rate(sse_stream_total[5m])。告警阈值设 0.01，持续 2 分钟。指数移动平均异常检测如下。设 x_t 为每 10 秒窗口的 p95 gap。EMA_t = alpha * x_t + (1 - alpha) * EMA_{t-1}。alpha 取 2/(N+1)。N 取 30 时 alpha 等于 0.0645。动态上界 UCL_t = EMA_t + 3 * sigma_t * sqrt(alpha/(2-alpha))。sigma_t 用同一窗口的 EWMA 标准差。当连续 3 个点超过 UCL 且 stream_disconnect_total 增量大于 5，触发 PagerDuty。N 取 5 时 alpha 等于 0.3333，对突发更敏感。线上同时跑短窗口和长窗口。短窗口做快速告警，长窗口做容量趋势。Claude 长文本输出速度约 40 到 80 token/s。事件间隔通常 80 到 250ms。一个 8 万 token 的输出会产生 800 到 1000 个 SSE 事件。p95 gap 从 200ms 跳到 1.2s 时，短窗口 EMA 三个点就能报警。

看板分三行。第一行全局断流率、重连成功率、活跃流数。第二行 gap 热力图，按 model 和 upstream_cluster 拆分。第三行按 reason 分解断流。表格对比如下。

指标	类型	关键标签	告警阈值
sse_event_gap_seconds	Histogram	model、upstream_cluster	p99 大于 8s 持续 2 分钟
stream_disconnect_total	Counter	reason、endpoint	5 分钟增量大于 10
stream_reconnect_total	Counter	result、model	重连成功率低于 99%
sse_events_total	Counter	event_type	速率突降 50%

若你有多个出口，可以在 Grafana 里按 upstream_cluster 对比丢包。选择更稳的入口参考 机场排行榜 和 专线机场推荐。网络层质量差时，先排查本地出口，再看 IPLC 专线是什么。

自动重连与状态恢复机制

断流后从最后事件 ID 续传。SSE 协议里每个事件可以带 id 字段。客户端保存最后收到的 id。原生 EventSource 会自动在重连时发 Last-Event-ID 请求头。若用 fetch 流式读取，需要手动实现。重连策略采用指数退避。base 500ms，factor 2，jitter 0.75 到 1.25，最大 30s，最多 8 次。第 9 次切到备用网关。备用网关可以走专线入口，减少 TLS 握手和首包延迟。客户端伪代码如下。

let lastId = localStorage.getItem('lastId')
let retry = 0
while (retry < 8) {
  const resp = await fetch(url, { headers: { 'Last-Event-ID': lastId } })
  const reader = resp.body.getReader()
  // 解析 SSE，更新 lastId
  retry = 0
}

服务端需要在 Redis 里缓存最近 5 分钟的 event chunk。key 用 stream_id，field 用 seq。客户端带 Last-Event-ID 重连时，网关先查缓存。从 seq+1 开始重放，再继续请求 Anthropic。缓存 TTL 设为 600s，足够覆盖 200K 上下文下 4 万 token 的生成时间。若缓存未命中，返回 409 让客户端全新开始。同时 stream_disconnect_total 打上 cache_miss 标签。状态恢复还要处理 token 计费。Anthropic 按输出 token 计费。重放不会重复计费，重复请求会。网关必须把 stream_id 和 request_id 做幂等映射。我见过一次误配，重连导致同一段输出被计费三次。排查时用 tcpdump 抓包，再用 tshark 看 Last-Event-ID 是否带上。若你的出口 IP 被 Anthropic 风控标记，再好的重连也救不回。可以先用 原生 IP 辨别指南 确认 IP 类型，再参考 Clash 入门教程 做规则分流。若同时跑 ChatGPT 和 Claude，分流规则可以参考 ChatGPT 网络配置指南。需要稳定中转时，走 前往官网 看专线拓扑。长上下文防断流的终点是端到端可观测。每一个 gap 都有标签，每一次重连都有状态。

Claude API长连接压测与断流复现实验

过去半年我处理过十几起 Claude 长文本流式推理断流工单，问题大多落在出口 IP 类型和网关长连接参数上。为了把现象复现清楚，我用 Locust 搭了一套持续 30 分钟的压测环境，专门打 Claude API 的 SSE 流式接口。下面把工具、流量模型、对比数据以及调优前后的量化结果完整摊开。

长上下文压测工具与流量模型

压测机选 4 核 8G 的 Ubuntu 22.04，Locust 2.20.0，Python 3.11。客户端在 requests 基础上封装了一个 SSE 读取器，逐行解析 event: content_block_delta 和 data: {...}。每个 Locust 用户执行一个 task，发起 POST 请求到 /v1/messages，请求体里 model 固定为 claude-3-5-sonnet，max_tokens 设为 4096，stream 设为 true。提示词用 32K tokens 的长文档，内容是技术白皮书拼接，确保触发长上下文推理路径。

流量模型 50 个并发用户，wait_time 设为 1 到 3 秒随机，持续时间 1800 秒。单用户平均每 2 秒发起一次流式请求，理论总请求数约 45000 次。断流判定条件有三个，连接被 RST 或 FIN 提前关闭，超过 90 秒没有收到新 SSE 事件，收到 error 事件且没有 message_stop。为了排除客户端 bug，我同时用 tcpdump -i any -w claude.pcap port 443 抓包，再用 tshark -r claude.pcap -Y "tcp.flags.reset==1" 统计 RST 次数。基础网络质量用 ping -c 200 -i 0.2 api.anthropic.com 和 mtr -rwzbc 100 api.anthropic.com 记录。物理链路方面，出口带宽 100Mbps，RTT 180ms，BDP 计算为 180ms × 100Mbps ÷ 8 = 2.25MB。如果 TCP 接收窗口小于 2.25MB，长文本下行就会受限，SSE 事件间隔被拉长，风控更容易判定为低速连接并切断。

不同网络环境下的断流率对比数据

四组出口分别部署在机房 VPS、住宅宽带、原生 IP 云主机以及原生 IP 加 IPLC 专线。机房 VPS 是普通 ASN，住宅 IP 来自本地运营商，原生 IP 通过 原生 IP 辨别指南 筛选，确认 whois 注册地和 ASN 归属一致。每组跑 30 分钟，50 并发，请求总量 45000 次左右。断流率按断流次数除以总请求数计算。结果如下。

出口类型	30 分钟断流次数	断流率	P99 首字节延迟
机房 IP	1566	3.48%	8.4 s
住宅 IP	576	1.28%	5.7 s
原生 IP	198	0.44%	3.9 s
原生 IP + IPLC	54	0.12%	2.6 s

机房 IP 的 RST 包最多，抓包显示大量连接在 20 到 40 秒之间被上游主动断开。住宅 IP 好一些，但晚高峰仍有明显抖动。原生 IP 配合 IPLC 专线是什么 里提到的点对点专线后，断流次数降到 54 次。如果你正在挑选出口，机场排行榜 和 专线机场推荐 可以作为选型参考。延迟异常时先查 节点延迟高排查指南，客户端配置可以看 Clash 入门教程 和 ChatGPT 网络配置指南。

调优前后性能指标量化分析

调优分四步。第一步在网关开启 BBR，net.ipv4.tcp_congestion_control=bbr，并把 tcp_keepalive_time 从 7200 降到 120，tcp_keepalive_intvl 调到 30，tcp_keepalive_probes 调到 5。第二步改 Nginx，关闭 proxy_buffering，设置 proxy_read_timeout 300s，proxy_send_timeout 300s，开启 chunked_transfer_encoding，对 SSE 路径禁用 gzip。第三步调整客户端，Socket 读超时 120 秒，遇到断流后指数退避重连，首次 1 秒，最大 30 秒。第四步换出口，从机房 IP 切到原生 IP 加 IPLC。每一步都跑满 30 分钟，记录 P99 延迟和断流次数。

指标	调优前	调优后	变化
P99 首字节延迟	8.4 s	2.6 s	下降 69%
P99 完整响应延迟	42.7 s	19.3 s	下降 55%
30 分钟断流次数	1566	54	下降 96.6%
平均重连次数	14.2	1.1	下降 92%

下降曲线很有意思。只开 BBR 时断流次数从 1566 降到 1280，降幅 18%。加上 keepalive 和代理超时后降到 480，累计降幅 69%。最后换原生 IP 和 IPLC 专线，断流次数压到 54，P99 首字节延迟从 8.4 秒降到 2.6 秒。整套环境跑完后，我把配置固化到网关模板，后续同类业务直接复用。需要完整网关配置模板的话，可以走 前往官网 内部路由获取。

生产环境部署清单与故障排查手册

内核网关与客户端配置检查表

生产环境跑 Claude 长文本流式推理，断流往往来自三层时间尺度错配。内核 TCP 保活以秒计，网关超时以分钟计，客户端读超时以小时计。任何一层早于模型输出关闭连接，SSE 流式传输中断都会出现。先按下面清单逐项核对。

层级	关键项	推荐值	验证命令
内核	tcp_keepalive_time	60	sysctl net.ipv4.tcp_keepalive_time
内核	tcp_keepalive_intvl	15	sysctl net.ipv4.tcp_keepalive_intvl
内核	tcp_keepalive_probes	4	sysctl net.ipv4.tcp_keepalive_probes
内核	tcp_slow_start_after_idle	0	sysctl net.ipv4.tcp_slow_start_after_idle
网关	proxy_read_timeout	3600s	nginx -T
网关	proxy_buffering	off	nginx -T
网关	gzip	off	nginx -T
客户端	sock_read	3600s	压测日志
客户端	keepalive_timeout	300s	ss -tan

Nginx 侧还要补几条。proxy_http_version 1.1，proxy_set_header Connection ""，chunked_transfer_encoding on，send_timeout 3600s。对 SSE 响应加 X-Accel-Buffering no。开启 proxy_cache off。keepalive_requests 10000，keepalive_timeout 75s。客户端侧，Python aiohttp 设置 ClientTimeout(total=None, sock_connect=10, sock_read=3600)。curl 必须加 -N --no-buffer。Node.js undici 把 headersTimeout 和 bodyTimeout 调到 3600 秒。长连接复用能减少 TLS 握手，也降低 Anthropic 网络风控概率。出口 IP 质量同样关键，可用 原生 IP 辨别指南 做基础筛查。跨境链路优先考虑 IPLC 专线是什么 中提到的专线方案。抖动明显时按 节点延迟高排查指南 逐跳定位。

常见断流场景与快速定位方法

现场排查先固定证据。ping 检查 MTU，ping -M do -s 1472 api.anthropic.com。mtr 看丢包，mtr -rwzc 100 api.anthropic.com。tcpdump 抓 RST 与 FIN，tcpdump -i any -nn -s0 -A 'tcp port 443 and (tcp[tcpflags] & (tcp-rst|tcp-fin) != 0)'。curl 复现流式请求，curl -N -v --no-buffer -H 'Accept text/event-stream'。五种典型现象如下。

现象	定位命令	根因	处置
客户端约 60 秒断开	curl -N -v 看时间戳	默认读超时早于首 token	读超时调到 3600s
固定 300 秒断开	tcpdump 看 FIN 方向	云 LB 空闲超时	LB idle timeout 调到 3600s
下行突发零窗口	ss -m 看 skmem	客户端消费慢	增大 rmem 并异步消费
TLS 后立即 RST	openssl s_client 与 mtr	中间盒或风控	换原生 IP 并降并发
长上下文尾部截断	tcpdump -A 看 SSE event	代理缓冲或 gzip	关闭 proxy_buffering 与 gzip

第一类常出现在客户端。Python requests 默认无读超时，但很多封装库设了 60 秒。第二类来自负载均衡。云厂商 LB 默认空闲超时 300 秒，而 Claude 长上下文首 token 偶尔超过 120 秒。第三类发生在客户端处理慢时。接收缓冲区满，TCP 零窗口，网关认为连接卡死。第四类最隐蔽。TLS 握手完成，客户端发请求，出口 IP 被 Anthropic 风控标记，连接直接 RST。这种情况重试无用，换出口或降低并发才有效。第五类在流末尾。SSE 事件被 gzip 或代理缓冲聚合，最后几个 token 丢失。处置时关闭压缩与缓冲。多线接入场景可参考 专线机场推荐 选择稳定出口，遇到并发瓶颈时也可以 前往官网 了解更高规格线路。

灰度发布与回滚预案

网关调优不能一次全量。采用流量染色。客户端在请求头带 X-Stream-Release canary。Nginx 用 map 把染色流量切到新 upstream。OpenResty 可按用户 ID 哈希取模。灰度流程分五步。

阶段	流量比例	观测指标	回滚阈值
内测	1%	首 token P95	大于 3s
灰度	5%	SSE 间隔 P99	大于 10s
扩量	20%	RST 比例	大于 0.5%
半量	50%	429 比例	大于 1%
全量	100%	连接复用率	低于 80%

每一步至少观察 30 分钟。重点看首 token P95、SSE 消息间隔 P99、连接复用率、RST 计数、429 比例。回滚触发后，把新 upstream 权重切到 0，旧 upstream 保留至少 30 分钟。排空阶段设置 drain 300s，让存量长连接自然结束。不要直接 kill worker，否则长连接会被强制 RST。验证连接用 ss -tan state established '( dport = 443 )'。抓包留存用 tcpdump -i any -nn -s0 -w stream.pcap 'tcp port 443'。回滚完成后核对客户端错误率与网关 RST 计数，再决定是否二次灰度。日常客户端配置可参考 Clash 入门教程 与 ChatGPT 网络配置指南。出口资源选择可看 机场排行榜。整套流程的核心目标只有一个，让 Claude 长文本流式推理在灰度、扩量、回滚三个状态下都保持可观测、可回退、可复现。