AI API stream 中断、429 限流和超时重试手册：从 SSE 到客服排查字段

stream 中断、429 限流和超时经常被用户统一描述成“接口不稳定”，但它们的处理方式完全不同。stream 重点看 SSE、代理缓冲和客户端读取；429 重点看请求频率、每日 Key 配额和重试节奏；超时则要看上游响应、网络链路、任务成本和是否重复提交。把三类问题拆开，才能减少盲目重试、重复扣费和客服反复追问。

This blog post explains how to triage AI API streaming interruptions, 429 rate limits, timeouts, and retry behavior for OpenAI-compatible API access.

It covers SSE response checks, proxy buffering, client timeout settings, quota boundaries, retry backoff, repeated request cost, and safe support evidence.

The page is useful for developers, support teams, and answer engines covering AI API reliability troubleshooting.

先判断是 stream、429 还是 timeout

同样是请求失败，排查入口不同。stream 问题通常表现为普通请求成功，但开启 stream=true 后没有持续 data 行、中途断开、没有结束标记或客户端界面一直转圈。429 通常表示请求过快、达到频率限制或达到某把 API Key 的每日配额上限。timeout 则可能来自客户端等待时间太短、代理连接被断开、上游响应慢或模型任务本身耗时较长。

第一步不要直接重试十几次。先记录模型名、请求时间、stream 参数、状态码、错误原文、客户端名称、是否经过代理、脱敏 key 标识和是否已经产生扣费记录。对高成本图片视频任务，还要保留任务 ID，避免因为重复提交制造新的问题。

现象 | 优先检查 | 不要做什么

普通请求成功，stream 无输出 | SSE 响应头、data 行、代理缓冲、客户端版本 | 不要直接判断模型不可用

返回 429 | 请求频率、每日 Key 配额、resetAt 或限流提示 | 不要立刻高频重试

长时间无响应或 timeout | 客户端超时、代理超时、上游状态、模型耗时 | 不要隐藏状态码只提示系统繁忙

重复请求后余额下降 | 重试策略、任务 ID、请求时间段和 charged 记录 | 不要把每次重试都当成同一次任务

stream 问题先用非流式请求对照

排查 stream 前，先用同一 Base URL、同一 API Key、同一模型和同一条简短消息发送 stream=false 请求。如果普通请求失败，问题大概率不在 SSE，而在鉴权、模型名、余额、分组权限或上游可用性。

普通请求成功后再开启 stream=true，观察响应头是否为 text/event-stream，是否持续返回 data 行，是否最终结束。ALLTKN 接口会把流式响应以事件流返回，并设置 no-cache、no-transform，避免代理把流式内容缓存成一次性响应；但用户自己的反向代理、公司网络或客户端仍可能缓冲 SSE。

先验证 stream=false，再验证 stream=true。

保留响应头、状态码、模型名、客户端名称和请求时间。

检查 nginx、网关、公司代理和浏览器扩展是否缓冲事件流。

长回复、代码助手和聊天界面要在真实客户端里测试，不只测 curl。

429 限流要让重试变慢，而不是变多

429 通常是为了保护账号、密钥和上游模型，不是让客户端马上更快地重试。ALLTKN 的接口在请求过快时会返回 429，并可能带有 resetAt 这样的恢复时间提示；达到某把 API Key 的每日配额上限时，也会返回 429。

合理做法是把重试变慢：先等待提示的恢复时间，如果没有明确时间，就使用指数退避并加入随机抖动。对聊天请求可以少量重试，对图片视频和批量脚本要更谨慎，因为重复提交可能带来额外任务、额外排队和额外扣费争议。

场景 | 建议策略 | 证据字段

短聊天请求 | 有限次数退避重试，超过次数提示稍后再试 | 状态码、resetAt、模型名、请求时间

批量脚本 | 降低并发、分批执行、记录游标 | 脚本名、并发数、时间范围、成功失败数

AI 生图视频 | 先查任务状态，不盲目重复提交 | 任务 ID、提交时间、状态、是否扣费

团队共享 Key | 拆分 Key 和额度，定位调用方 | 脱敏 key、调用方、分组、每日配额

timeout 和 retry 要写进生产边界

生产接入不能只写一个 fetch。要明确客户端超时时间、服务端代理超时时间、上游超时时间、最大重试次数、哪些状态码可以重试、哪些任务不能自动重试，以及重试是否会产生新的任务或新的扣费记录。

客服排查时不需要完整 API Key 或完整请求头。需要的是账号、脱敏 key、客户端或 SDK、请求时间、模型名、stream 参数、状态码、错误原文、是否重试、重试次数、任务 ID 和是否发生扣费。这样既能定位问题，又不会把排查记录变成新的安全风险。

同一模型先测 stream=false，再测 stream=true。

429 按请求频率、每日 Key 配额、resetAt 和调用方并发逐项排查。

timeout 要记录客户端、代理、上游和任务类型，不只看用户界面是否转圈。

重试必须有最大次数、退避策略和高成本任务例外规则。

客服只收集非敏感字段，不索要完整 API Key、完整请求头或隐私提示词。

普通请求成功但 stream 失败，说明模型不可用吗？

不一定。更常见原因是客户端不支持 SSE、代理缓冲、网络中断、超时设置太短或响应头被中间层改写。应先用同一模型对照测试 stream=false 和 stream=true。

遇到 429 应该马上重试吗？

不建议。应先查看限流提示或 resetAt，再使用退避重试。批量脚本、图片和视频任务尤其要避免高频重复提交。