proxy_request_buffering必须保持on以增强安全防护；关闭它会削弱Slowloris等慢速攻击防御能力，导致后端直面异常流、超时失效、连接数激增。
不能用 proxy_request_buffering off 来防范慢速 HTTP 拒绝服务攻击——恰恰相反，关掉它会削弱防护能力。
proxy_request_buffering 的作用本质是增强缓冲与校验
该指令默认为 on，意味着 Nginx 会完整接收并暂存请求体（body），再整体转发给后端。这个过程带来三项关键安全收益：
- 强制校验
Content-Length：若客户端声明了 10MB 但只发了 1KB 就停住，Nginx 能识别不匹配并及时断连 - 启用 Slowloris 类防护：配合
client_body_timeout，未按时传完 body 的连接会被主动关闭 - 避免后端直面流式异常：后端无需处理半截请求、分段超时或粘包逻辑，由 Nginx 统一兜底
真正用于防御慢速攻击的核心参数
防范 Slow headers、Slow body、Slow read，应聚焦以下超时与资源控制配置：
-
client_header_timeout 10s：头部必须在 10 秒内收全，否则断开（防 Slow headers） -
client_body_timeout 15s：请求体传输间隙超 15 秒即中断（防 Slow body） -
send_timeout 10s：响应发出后，客户端 10 秒内不读取就关闭连接（防 Slow read） -
reset_timedout_connection on：超时后发送 RST 包，快速释放连接状态 -
limit_conn_zone $binary_remote_addr zone=perip:10m+limit_conn perip 10：单 IP 最多维持 10 个并发连接
误关 proxy_request_buffering 的风险
设为 off 后，Nginx 不再等待完整 body，也不校验长度，这会导致：
- Slow POST 攻击完全失效防护：攻击者可声明
Content-Length: 100M，然后每分钟发 1 字节，Nginx 照转不误，后端持续等待 - 无法触发
client_body_timeout：因为“接收 body”阶段被绕过，超时机制形同虚设 - 后端暴露于原始 TCP 流：需自行实现流控、超时、重试和完整性校验，大幅增加攻击面
Kubernetes Ingress 中的典型错误配置
有人在 Ingress 注解里写：
nginx.ingress.kubernetes.io/proxy-request-buffering: "off"却没同步收紧超时与限流，结果是：
- 业务流式上传场景受益有限，但整体抗攻击能力下降
- 安全扫描工具持续告警 “Slow HTTP DoS vulnerability”
- 真实攻击中，连接数在 2–3 分钟内爬升至 worker_connections 上限
