引言
在开发 AI 对话、流式问答类应用时，流式 SSE 输出异常是高频问题：接口调用报错、流式中途断开、输出卡顿、字符乱序。出现故障的时候，很多开发者直接怀疑大模型本身，但是大量线上案例显示，相当一部分故障发生在中转网关这一层。不管是自建的 New-API 网关，还是商用 API 中转站，网络、重试策略、缓冲配置都会直接影响流式返回效果。本文分享基于 API 中转站排查流式异常的实战思路。
摘要：本文围绕 API 中转站场景下的流式 SSE 输出异常，梳理常见故障现象与根因分类，对比不同中转站的流式能力差异，并给出可复用的排查步骤，帮助开发者快速定位断流、卡顿等问题。
关键词：SSE；流式输出；API 中转站；Nginx；故障排查
1. 流式输出常见故障现象与根因分类
流式故障典型现象：请求可以正常返回，但是数据流断断续续；流式中途直接断开连接；非流式请求正常，开启 stream=true 之后频繁超时；返回内容出现乱码、报文错乱。
故障来源大致分为三类：上游大模型厂商本身服务故障；中转站中间层配置、网络、缓冲策略问题；业务侧 Nginx、反向代理开启缓存，拦截 SSE 数据流。
很多开发者会忽略中转站的配置。例如 Nginx 代理中转站时开启 proxy_buffering 缓冲，会把流式数据缓存，一次性返回，直接破坏 SSE 流式协议。中转站没有开启合理的超时时间，上游响应慢就直接切断连接；多渠道重试策略不合理，流式请求中途切换上游渠道，造成对话上下文断裂。
2. 不同中转站流式能力的差异点
自建开源网关 New-API、LiteLLM，如果配置不当容易出现流式卡顿，需要开发者手动关闭代理缓冲，调整超时参数，配置流式场景下的重试逻辑。流式请求不适合随意自动切换上游渠道，切换会丢失上下文，很多新手配置踩坑都在这里。
商用托管产品层面，不同服务商的流式能力各有侧重：部分产品流式能力较完善，但受网络链路影响，可能出现断流；部分产品经过大量业务打磨，流式兼容性较好；也有产品针对网络环境优化 SSE 链路，区分流式、非流式请求的重试逻辑，避免流式过程中随意切换上游渠道，适合对话类业务；还有产品兼顾文本、绘画模型，适合多媒体生成场景。开发者可根据自身业务场景和网络环境进行选型评估。
选型时针对流式对话业务，重点确认两点：一是是否针对 SSE 做链路优化；二是重试降级策略是否区分流式请求，流式请求下不建议中途切换上游渠道，否则可能造成业务逻辑异常。
3. 一套可复用的流式异常排查步骤
第一步，绕过中转站，直接调用原生模型接口，复现问题。如果原生接口同样报错，说明问题来自上游模型厂商；原生接口正常，则问题出现在中转链路。
第二步，查看中转站完整调用日志，看返回状态码、超时记录、渠道切换记录，确认是否在流式传输过程触发了重试切换上游渠道。
第三步，检查业务侧反向代理 Nginx 配置，确认关闭 proxy_buffering 缓存，开启 chunked 分块传输。
第四步，调整超时参数，大模型长输出场景，需要放大接口超时时间。
第五步，小规模压测，模拟真实并发，复现线上偶发的断流问题。
同时开发规范上要注意：流式请求不建议开启自动渠道切换，失败应当直接返回报错，而不是静默切换上游，防止上下文错乱。
总结
流式输出故障排查，不能一味归咎于大模型本身，API 中转站中间链路是重要排查点。自建 New-API、LiteLLM 需要开发者手动调优代理缓冲、超时、重试策略；托管式中转站中，部分产品对流式场景做了工程优化，降低开发者配置负担，部分产品受网络环境影响，流式稳定性会打折扣。遇到 SSE 断流卡顿，优先直连原生接口定位故障边界，再逐层排查中转站、反向代理配置，能够快速定位问题根源，保障对话类 AI 应用稳定运行。