proxy_request_buffering off 主要解决大请求体上传延迟与资源积压，适用于视频流、实时日志、AI流式推理等需边收边传场景；默认开启是为了防慢速客户端攻击、支持请求体校验及连接保护。
禁用 proxy_request_buffering 主要解决的是“大请求体上传时的延迟与资源积压”问题，尤其适用于视频流、实时日志上报、大模型推理输入等需要边收边传的场景。它不是通用优化项，而是一项有明确代价和适用边界的针对性调整。
为什么默认开启？它到底在缓冲什么
proxy_request_buffering on（默认）意味着：Nginx 会先把整个客户端发来的请求体（比如一个 500MB 的视频文件、一段持续推送的二进制流）完整读入自己的内存或临时磁盘缓冲区，确认收完后，再一次性转发给后端服务。
这样做的好处很实在：
- 防止慢速上传客户端（如弱网手机）拖垮后端——后端不用一直等着收数据
- 便于 Nginx 层做完整性校验（例如限制最大上传体积、检查文件头）
- 避免后端被未完成的请求长时间占用连接
什么时候必须关？典型触发信号
当你的业务出现以下任一现象，且已排除后端瓶颈，就该重点排查 proxy_request_buffering：
- 前端上传大文件时，后端“迟迟收不到第一字节”，进度条卡在 0% 几秒不动
- 实时音视频推流首帧延迟高，或出现断续卡顿（非网络原因）
- 后端是流式处理服务（如 FFmpeg 转码、AI 流式 inference），要求数据抵达即开始计算，但实际收到的是整块数据
- Nginx 日志中频繁出现
client closed connection while reading client request body，且客户端并未主动断开
关闭后的关键配套动作
单独写 proxy_request_buffering off; 不够，必须同步调整其他参数，否则可能引发新问题：
WebChat Voice Proxy
下载
⚠️ 已弃用 — 该技能已拆分为两个独立技能，以提升模块化程度：**webchat-https-proxy**（HTTPS/WSS 反向代理）和 **webchat-voi...**
-
延长超时时间：后端处理变长，需调大
proxy_read_timeout和proxy_send_timeout（例如设为600s或更高） -
显式透传连接控制头：加
proxy_set_header Connection '';防止 Nginx 错误地关闭长连接 -
禁用响应缓冲（如适用）：若后端也返回流式响应（如 SSE、chunked JSON），需同步关
proxy_buffering off;和proxy_cache off; - 注意客户端兼容性：部分旧版 HTTP 客户端不支持流式请求体转发，建议服务端增加 fallback 逻辑（如降级为分片上传）
Kubernetes Ingress 中的正确写法
在 Ingress 资源中不能直接写 NGINX 原生指令，要用注解方式，且值必须是字符串：
❌ 错误写法：nginx.ingress.kubernetes.io/proxy-request-buffering: falsenginx.ingress.kubernetes.io/proxy-request-buffering: "false"✅ 正确写法：nginx.ingress.kubernetes.io/proxy-request-buffering: "off"
配置示例：
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: upload-ingress
annotations:
nginx.ingress.kubernetes.io/proxy-request-buffering: "off"
nginx.ingress.kubernetes.io/proxy-read-timeout: "600"
nginx.ingress.kubernetes.io/proxy-send-timeout: "600"
spec:
rules:
- host: upload.example.com
http:
paths:
- path: /stream
pathType: Prefix
backend:
service:
name: stream-processor
port:
number: 8080
验证是否生效的实操方法
别只信配置文件，要看到真实行为：
- 进入 Ingress Controller Pod，运行
nginx -T | grep -A5 'location /stream'，确认生成的配置里含proxy_request_buffering off; - 用
curl -v -X POST --data-binary @large-file.bin http://upload.example.com/stream抓包，观察 TCP 层是否在传输中途就开始向后端发 SYN/ACK 和数据包（而非等整个文件读完才连后端） - 在后端服务加日志，打印接收到第一个字节的时间戳，对比 Nginx access log 中
$request_time，延迟差应明显缩小
