nginx通过两级缓冲区（client_header_buffer_size与large_client_header_buffers）、超时控制（client_header_timeout）、禁用下划线解析等机制主动防御请求头溢出，而非被动防崩溃。
Nginx 对请求头解析的缓冲区溢出防护，不是被动“防崩溃”，而是主动设限、分层拦截。它不依赖运行时内存检查，而是通过预分配、超时控制和结构化拒绝，在数据进入处理流程前就切断异常路径。
请求头缓冲区的两级分配机制
Nginx 用两套缓冲区协同管理请求头：先尝试用小块内存装下整个头，失败再启用备用池，超出总容量即拒收。
- client_header_buffer_size 是每个请求的初始缓冲区，默认仅 1KB。它够存普通 GET 请求头，但 JWT Token（常超 2KB）、多域名 Cookie 或嵌套 traceparent 头很容易填满它
-
large_client_header_buffers 是备用缓冲池，格式如
large_client_header_buffers 4 8k，表示最多使用 4 块 8KB 缓冲 → 总上限 32KB。只要请求头总长度（含所有字段名、值、换行符）超过这个值，Nginx 立刻返回 400，并在 error.log 记录 request header or cookie too large
防慢速头攻击的关键超时控制
光调大缓冲没用——攻击者可以逐字节发头字段，拖住连接不释放，耗尽 worker 连接槽位和内存。
- client_header_timeout 控制读取请求头的等待时间，建议设为 5s～10s。超时即断连，不给慢速攻击留窗口
- 配合 reset_timedout_connection on，对空闲超时连接立即发送 RST，快速释放缓冲区和连接资源
- 禁用下划线解析：underscores_in_headers off，防止攻击者用 X_Api_Key 绕过某些鉴权逻辑或触发框架歧义解析
与业务场景匹配的典型配置参考
安全不是越大越好，而是贴合真实流量特征。例如带 JWT 的 API、多租户 SSO 场景，需兼顾兼容性与防御强度。
- 常规 Web 应用：
client_header_buffer_size 2k; large_client_header_buffers 4 8k;（总上限 32KB） - 含长 Token 或全链路追踪的微服务网关：
client_header_buffer_size 4k; large_client_header_buffers 8 16k;（总上限 128KB），同时收紧client_header_timeout 8s - 严格限制场景（如对外暴露的登录接口）：可进一步缩小缓冲，例如
client_header_buffer_size 1k; large_client_header_buffers 2 4k;（总上限 8KB），并开启日志采样便于识别异常头模式
日志与可观测性是定位依据
错误日志不是辅助手段，而是判断是否真为缓冲区问题的第一证据。
- 出现 request header or cookie too large → 明确指向头缓冲超限，优先检查上述两个 buffer 参数
- 若日志无此记录，但仍有 400 错误 → 可能是语法错误（如非法字符、换行缺失）或第三方模块拦截，需结合 access_log 中的 $status 和 $request_length 排查
- 大量同 IP 短时间内触发该错误 → 高概率是头泛洪攻击，应联动
limit_req做速率限制
