proxy_request_buffering on 能缓解 Slow Body 攻击，因其强制 Nginx 完整读取请求体并配合 client_body_timeout 断连未完成上传，但需同步配置超时与限流参数才有效。
开启 proxy_request_buffering 是防御 Slow Body 类慢速攻击的有效手段，但不能单独依赖它 —— 它只解决“请求体未传完就卡住”的一部分问题，且关闭后反而会放大风险。
为什么 proxy_request_buffering on 能缓解 Slow Body 攻击
Slow Body 攻击的核心是：客户端声明一个很大的 Content-Length（比如 100MB），却以极低速率（如每秒 1 字节）发送请求体，让 Nginx 或后端长时间维持连接并分配缓冲资源。
当 proxy_request_buffering on（默认值）时：
- Nginx 会主动读取完整个请求体（内存或磁盘缓存），并在收到全部数据后才转发给后端；
- 配合
client_body_timeout（如设为20s），超时未传完就直接断连，不把半截请求甩给后端； - 避免后端被“假大文件”拖住，也防止攻击者用单连接持续占用 worker 进程。
⚠️ 注意：proxy_request_buffering 对 Slow Headers 和 Slow Read 无效 —— 它只作用于请求体（body）阶段。
必须同步收紧的超时参数，否则 buffering 形同虚设
仅开 proxy_request_buffering 不设超时，攻击者仍可缓慢填满 Nginx 缓冲区，耗尽内存或磁盘临时空间。
以下参数需在 http 或 server 块中显式配置：
-
client_body_timeout 15s：从开始接收 body 到结束，超过即断连； -
client_max_body_size 100M：硬限制最大允许上传大小，防恶意大值声明； -
client_body_buffer_size 128k：控制内存缓冲上限，超出部分写磁盘，避免 OOM； -
reset_timedout_connection on：超时后发 RST 包强制释放连接，不等 TCP 自然关闭。
这些值需根据业务实际调整。例如视频上传服务若需支持 2GB 文件，client_max_body_size 必须放宽，但 client_body_timeout 仍建议 ≤60s，并搭配限速策略。
安装并运行 Aperture（Lightning Labs 的 L402 闪电反向代理），用于创建 L402 付费墙、配置付费 API 端点、为其他代理托管付费内容或测试 L402 认证流程。
Kubernetes Ingress 中关闭 buffering 的反模式风险
很多用户为“优化大文件上传”在 Ingress 注解里配 nginx.ingress.kubernetes.io/proxy-request-buffering: "off"，这会让 Slow Body 攻击直接穿透到后端。
此时 Nginx 变成纯流式代理，不再校验 body 完整性，也不触发 client_body_timeout —— 后端服务（如 Python Flask、Node.js Express）可能自己没做超时控制，瞬间被拖垮。
若必须关 buffering，请确保：
- 后端已实现请求体读取超时（如 Express 的
req.setTimeout()）； - Ingress 层启用了
limit_conn和limit_req限制单 IP 并发与速率； - 监控
nginx_ingress_controller_requests_total{status=~"499|500"}等指标，及时发现异常中断。
验证是否生效的关键检查点
别只看配置写了没，要确认运行时行为：
- 进 Ingress Controller Pod，执行：
kubectl exec -it，确认生成的-n ingress-nginx -- grep -r "proxy_request_buffering" /etc/nginx/ nginx.conf中对应location块有该指令； - 用
curl -X POST --data-binary @/dev/zero -H "Content-Length: 100000000" http://your-domain/模拟慢传，观察连接是否在client_body_timeout秒内被断开（用tcpdump或ss -tni验证 RST 包）； - 查 Nginx error log，出现
client timed out (110: Connection timed out) while reading client request body即表示超时机制已起效。
真正难控的是攻击者混在正常流量里的低频慢传 —— 它不触发限速，又刚好卡在 timeout 边缘。这种场景下，光靠 buffering 和超时不够，得结合连接数限制与日志异常检测联动。
