必须关闭 proxy_buffering，因其默认开启会缓存后端响应，破坏流式传输的实时性，导致首字节延迟、消息堆积甚至连接中断；需配套禁用缓存、请求缓冲，启用分块编码与长连接超时等配置。
流式 API（比如 ChatGPT 的 token 逐块返回、SSE 推送、gRPC-Web 流）对实时性极度敏感，而 Nginx 默认开启的 proxy_buffering on 会严重破坏这种流式行为——它把本该“边生成边发”的响应攒在内存里，等缓冲区满了或连接关闭才吐给客户端，导致首字节延迟高、消息堆积、甚至连接中断。
为什么必须关掉 proxy_buffering？
ChatGPT 类接口通常使用 HTTP/1.1 + Transfer-Encoding: chunked，每生成一个 token 就 flush 一次。Nginx 若开启缓冲：
- 会等待凑够
proxy_buffers容量（默认 8×4k = 32KB）才转发，用户卡顿数秒才看到第一个字 - 若后端持续输出但客户端网络慢，worker 进程内存不断累积响应数据，可能触发 OOM 或被
proxy_read_timeout中断 - gzip 压缩会被自动禁用（Nginx 要求响应完整才能压缩），但更重要的是：它根本就不是为流式设计的
核心禁用配置项（缺一不可）
仅写 proxy_buffering off; 不够，必须配套以下指令，否则仍可能出问题：
- proxy_buffering off; —— 关闭响应体缓冲，收到即转
-
proxy_cache off; —— 防止 Nginx 把流式响应当静态资源缓存（尤其搭配
Cache-Control时易误判） - proxy_request_buffering off; —— 禁用请求体缓冲，避免大 prompt 上传被截断或延迟（对长上下文输入很关键）
-
chunked_transfer_encoding on; —— 显式启用分块编码，确保 Nginx 不尝试计算
Content-Length - proxy_http_version 1.1; 和 proxy_set_header Connection ''; —— 防止降级到 HTTP/1.0，保留 keep-alive 和流式语义
- proxy_set_header X-Accel-Buffering no; —— 向后端明确声明“我不缓冲”，部分框架（如 FastAPI、Starlette）会据此调整 flush 行为
超时与连接稳定性设置
流式连接常达数分钟甚至更久，需同步放宽超时限制：
- proxy_read_timeout 3600; —— 后端响应间隔（如两个 token 之间空闲时间）最大容忍 1 小时
- proxy_send_timeout 3600; —— Nginx 向客户端发送数据的单次阻塞上限（防弱网卡死）
- keepalive_timeout 3600; —— 客户端空闲连接保持时间，匹配后端心跳周期
- tcp_nodelay on; —— 关闭 Nagle 算法，避免小包合并延迟（对 token 级别推送至关重要）
可选但强烈推荐的加固项
进一步降低干扰、提升兼容性：
- proxy_set_header Accept-Encoding ''; —— 禁用后端 gzip，避免压缩逻辑与流式 flush 冲突
- proxy_set_header Cache-Control 'no-cache, no-store, must-revalidate'; —— 明确告知中间链路（包括浏览器）不要缓存流式响应
- proxy_buffer_size 0; —— 彻底禁用响应头缓冲（注意：某些旧版 Nginx 不支持设为 0，可设为 1k）
- proxy_max_temp_file_size 0; —— 禁用磁盘临时文件，防止缓冲溢出时写盘拖慢性能
大量免费API接口：立即使用
涵盖生活服务API、金融科技API、企业工商API、等相关的API接口服务。免费API接口可安全、合规地连接上下游，为数据API应用能力赋能！
