关闭proxy_request_buffering off是解决实时交互代理延迟的关键，必须配合client_max_body_size、proxy_read_timeout、proxy_buffering off及http/1.1头透传等配置协同生效。
要解决实时交互类业务的代理延迟，proxy_request_buffering off 是关键一环——它让 Nginx 放弃“收完再转”的惯性逻辑，改为边接收客户端请求体、边转发给后端，从而消除首字节转发延迟。但仅关这一项远远不够，必须围绕流式传输构建完整配置链。
哪些实时交互场景必须关闭 proxy_request_buffering
以下业务对端到端时延敏感，Nginx 默认缓存整个请求体会直接破坏实时性：
- AI 推理服务接收音频流+文本 prompt，后端需逐 token 开始处理，不能等上传结束
- FFmpeg 或 GStreamer 接收 RTMP/HTTP-FLV 推流，要求毫秒级字节透传
- WebSocket 升级前的 POST 请求体（如携带鉴权 token 或元数据），缓冲可能导致握手超时或截断
- 前端通过 fetch 流式上传大视频分片，后端做实时校验或直传 S3，依赖原始 chunk 边收边发
- Jenkins CLI、Git over HTTP 等工具链，依赖未缓冲的原始请求流解析协议
只关 proxy_request_buffering off 为什么还不够
关闭请求缓冲后，Nginx 不再保护后端免受慢速客户端影响，也不再校验请求完整性。若不配套调整，容易出现连接挂起、502、卡在 99% 或后端读取阻塞等问题：
-
client_max_body_size 必须显式放大（如设为
2G或0），否则未缓冲前就因大小限制返回 413 -
client_body_timeout 建议设为
300s以上，适应弱网下分片上传暂停 -
proxy_read_timeout 需同步延长（如
300s），避免 Nginx 在等待后端响应时主动断连 - proxy_buffering off 必须同步开启，防止后端返回的进度事件、SSE 流或 WebSocket 消息被二次积压
协议层必须透传的关键支持
流式交互依赖 HTTP/1.1 的长连接语义和特定头部，Nginx 默认行为可能破坏它们：
FastAPI Flask Proxy
下载
FastAPI + Flask 混合部署最佳实践，解决路由定义、API 代理等常见问题，适用于同时运行 FastAPI API 与 Flask 前端的场景。
- 启用
proxy_http_version 1.1;，确保支持Transfer-Encoding: chunked - 清空连接头：
proxy_set_header Connection "";，防止 WAF 或负载均衡器误判并关闭连接 - 透传断点续传相关头：
proxy_set_header Range $http_range;和proxy_set_header If-Range $http_if_range; - WebSocket 场景还需：
proxy_set_header Upgrade $http_upgrade;和proxy_set_header Connection "upgrade";
Kubernetes Ingress 中的正确写法
在 NGINX Ingress Controller 中，不能直接编辑 nginx.conf，需用注解方式声明：
nginx.ingress.kubernetes.io/proxy-request-buffering: "off"
注意：值必须是带双引号的字符串 "off"，写成 false、0 或不加引号均无效。配置后建议进入 Ingress Controller Pod，检查生成的配置片段是否已生效。
