nginx无传统缓冲区溢出漏洞，所谓“恶意大包攻击”实为超大请求头、超长请求体或慢速发送持续占用header/body/proxy缓冲区，致worker内存飙升被oom killer终止；防御需四层协同：精准限制请求头（client_header_buffer_size 2k; large_client_header_buffers 4 8k; client_header_timeout 6s）、分级控制请求体（client_max_body_size按location设5m/200m、client_body_buffer_size 4k、client_body_timeout 10s）、关闭代理二次缓存（proxy_buffering off; proxy_request_buffering off;）、系统级兜底（memorylimit=1g、open_file_cache_errors on）。
Nginx 本身没有传统缓冲区溢出漏洞，所谓“恶意大包攻击耗尽缓冲区内存”，实际是攻击者通过超大请求头、超长请求体或慢速分段发送等方式，持续占用 worker 进程的内存缓冲区（如 header buffer、body buffer、proxy buffer），最终导致 RSS 内存飙升、被 OOM Killer 杀掉，或服务响应迟滞甚至中断。防御关键不是堵一个点，而是从协议层拦截、内存分配控制、连接生命周期管理、系统级兜底四层协同。
精准限制请求头大小，防 JWT/Cookie 膨胀攻击
攻击者常在 Cookie、Authorization 或自定义头中塞入数 MB 的 Base64/JWT/Trace 数据，触发 large_client_header_buffers 频繁分配。
-
client_header_buffer_size 2k;：覆盖绝大多数合法请求（典型 JWT 约 1.5KB） -
large_client_header_buffers 4 8k;：总上限 32KB，单 buffer ≥ 初始 buffer，避免 400 报错 -
client_header_timeout 6s;：防止逐字节慢发头字段，超时即断连 -
underscores_in_headers off;：禁用下划线解析，阻断 X_Api_Key 类绕过
分级控制请求体上限，阻断上传类大包滥用client_max_body_size 是第一道硬闸门，必须在解析完请求头、读取 body 前就拦截，返回 413。
Browser Setup (No-Root Linux)
下载
在无 root/sudo 权限的环境（云容器、VPS、隔离主机）中安装并配置 OpenClaw 浏览器工具的 headless Chrome。适用场景：...
- 普通 API、登录页等非上传路径：保持
client_max_body_size 5m;或更小 - 明确上传接口（如
/api/upload）：单独设client_max_body_size 200M;，不放全局 - 同时配
client_body_buffer_size 4k;：中小请求走内存，超限自动落盘；该值必须 ≤ 对应 location 的client_max_body_size -
client_body_timeout 10s;：body 接收中断即断连，防慢速 POST
关闭代理层二次缓存，避免内存放大
反向代理场景下，Nginx 默认会缓存 client body 和 proxy response，形成双重持有，极易被利用。
-
proxy_buffering off;：禁用后端响应缓冲，流式透传 -
proxy_request_buffering off;（Nginx ≥1.16）：禁用原始 body 缓存，防止重放与重复解析 -
proxy_buffer_size 4k;：仅缓存响应头，不缓整个 body -
proxy_buffers 8 64k;：总 proxy buffer 上限 512KB，防后端吐大文件吃光内存
系统级兜底与可观测性加固
配置再严，失控 worker 仍可能因累积异常请求拖垮整机。
- systemd 启动时加
MemoryLimit=1G，硬约束单个 worker RSS -
open_file_cache_errors on;：快速释放因头过大失败导致的无效 fd，防句柄泄漏 - 监控
nginx_process_resident_memory_bytes，当某 worker 持续 > 300MB 且平均$request_length突增，即触发告警 - 用
map提取超长头特征：map $http_user_agent $ua_len { ~^(?<l>.{1000,}) $l; default ""; }</l>结合日志分析高频超长 UA 或含可疑 JWT 片段的 IP，自动加入
limit_conn黑名单 zone
