流式回答最后才显示：按应用、代理与浏览器逐层定位
接口采用流式响应，页面却等到结束才一次性显示，可能是生成端没有及时输出，也可能是中间缓冲或前端读取方式造成。看到这种现象，不应直接认定模型没有流式能力，更不必同时修改应用、代理和页面代码。
接口采用流式响应，页面却等到结束才一次性显示，可能是生成端没有及时输出，也可能是中间缓冲或前端读取方式造成。看到这种现象，不应直接认定模型没有流式能力，更不必同时修改应用、代理和页面代码。
先确认数据在哪里开始积压
在受控测试环境分别观察直接访问应用和经过反向代理的响应时间线。若应用本身也到最后才输出，先查生成与刷新逻辑；若直连正常、经过代理后聚集，再查代理缓冲、压缩和上游链路。保留同一输入和测试时间，避免把不同任务速度当成配置差异。
修改必须限定到具体接口
Nginx文档说明代理响应缓冲会影响转发方式。确需调整时，只在对应流式路由评估缓冲策略，并检查应用使用的响应协议与消息边界。不要把所有网站接口都改成同一种策略，也不要靠无限延长超时掩盖没有心跳或没有结束标记的问题。
以完整交互验收
除观察首段何时出现，还要测试中途断开、长时间等待、服务返回错误及正常结束。前端应逐步处理数据，而不是先等待完整文本再渲染。断线后应明确提示任务状态，不能把重新提交当成无成本重试。本文提供定位顺序，不代表某项缓冲设置适合所有代理和应用组合。
资料与继续阅读
Nginx代理缓冲文档 · 整理日期：2026-10-30。本文为独立编辑整理，操作建议不代表本站已经完成实测。
本文新增价值
围绕“流式回答最后才显示”给出适用条件、判断顺序与具体检查办法，区分需要修改的环节和可以保留的设置，并用可观察的结果验收，避免只提供笼统建议。
围绕“流式回答最后才显示”给出适用条件、判断顺序与具体检查办法，区分需要修改的环节和可以保留的设置，并用可观察的结果验收，避免只提供笼统建议。