Node.js 流式调用为什么在 Nginx 后面变成“一次性输出”
模型明明逐字输出,经过 Nginx 后却等几十秒一次性返回,最常见原因是代理缓冲。普通网页适合 buffering,但 SSE/流式文本通常需要关闭缓冲并延长 read timeout。
模型明明逐字输出,经过 Nginx 后却等几十秒一次性返回,最常见原因是代理缓冲。普通网页适合 buffering,但 SSE/流式文本通常需要关闭缓冲并延长 read timeout。
一、为什么会出现这个问题

- 错误可能由 Nginx、Cloudflare、应用网关、第三方平台或真正的模型上游任意一层返回。
- 代理 read timeout、buffering、连接复用等默认值并不适合 AI 长请求。
- 流式 SSE 在中间层被缓存、提前关闭或事件格式被改写。
- 只看客户端最后一行错误,无法判断真正的故障来源。
二、推荐的排查顺序
1. 确认错误来自哪一层
保留响应头、request id、Cloudflare Ray ID、Nginx access/error log 和应用日志,同一时间点对齐分析。
2. AI 路由单独配置
SSE、长文本、Agent、视频任务不要直接套普通网站的 timeout 和 buffering。对 /v1/ 等接口单独设置更容易维护。
3. 只对暂时性错误重试
502/503 等可以有限重试;401、403、参数错误等确定性问题不应该盲目重试。
三、可以直接复制的排查示例
location /v1/ {
proxy_pass http://127.0.0.1:3000;
proxy_http_version 1.1;
proxy_buffering off;
proxy_cache off;
gzip off;
proxy_read_timeout 600s;
}
四、使用建议
不要全站关闭 buffering。只对真正需要流式的 API 路由单独配置。
原创文章,作者:Codex中文网,如若转载,请注明出处:https://codex-zh.com/posts/nodejs-streaming-nginx-buffering/
相关文章
API 经常出现 502、503、504,应该重试还是换接口
5xx 表示服务链路某一层出了问题,但如果你的请求经过 Cloudflare、Nginx、应用网关和第三方接口,任意一层都可能生成 502/503/504。正确做法不是立刻“换接口”,而是找到第一处失败点。
Codex 处理大型仓库的正确方式
几百个文件的小项目,可以让 Codex 很快建立全局理解;但面对大型 Monorepo,如果一开始就要求“分析整个项目并优化”,效果通常不好。
Codex 上传文件提示过大怎么办?附件大小和上下文优化
围绕「Codex 上传文件提示过大怎么办」给出面向 Codex 用户的原理、配置、操作步骤、排查方法与常见问题,适合新手直接照着实践。
Codex 总想重构代码,但我只想修一个 Bug
线上紧急 Bug 和代码重构是两种不同任务。Agent 如果发现旧代码风格差,往往会顺便“整理”,结果把风险从一个小补丁放大成大面积变更。紧急修复应该强调 Minimal Patch。