client_header_buffer_size 通过限制单行请求头（如Cookie）的初始缓冲区大小（默认1k）来拦截超长Cookie：若整行Cookie长度超过该值，Nginx立即返回400错误，不触发扩容；它仅控单行长度，非总头长，盲目调大（如64k）易引发内存耗尽攻击。
client_header_buffer_size 本身不用于“防御攻击”，而是控制 Nginx 解析请求头时的初始内存分配。它在超大 Cookie 场景中起关键作用，是因为当 Cookie 行过长、超出该缓冲区时，Nginx 会直接拒绝请求并返回 400 错误——这种“严格截断”行为客观上构成了第一道防线，但前提是配置得当且配合其他机制。
它怎么拦住超长 Cookie？
Cookie 是 HTTP 请求头中的一行（Cookie: key1=val1; key2=val2; ...），Nginx 按行处理请求头。client_header_buffer_size 决定了每行开头能用多大内存来接收。默认通常为 1k（1024 字节），如果整行 Cookie 长度超过这个值，Nginx 就不会等后续扩容，而是立即报 400，并在 error.log 中记录 “client sent too large header” 或 “request header or cookie too large”。
注意：它只限制单行长度，不是整个请求头总长；也不影响请求体（body）或响应。
为什么单靠调大它反而危险？
盲目增大 client_header_buffer_size（比如设成 64k）看似能“兼容更多 Cookie”，实则削弱了防护能力：
- 一个恶意客户端可构造单行 60KB 的 Cookie，触发 Nginx 分配大块内存，反复发起即可耗尽 worker 进程内存
- 它跳过了“按需扩容”的检查逻辑，让攻击更隐蔽、更高效
- 真正起扩容作用的是 large_client_header_buffers，而非 client_header_buffer_size 本身
安全有效的配置组合
合理配置应体现“分层拦截+最小够用”原则：
- client_header_buffer_size 设为 4k 或 8k：覆盖绝大多数合法请求（含 SSO Token、A/B 参数等），避免首行就溢出
- large_client_header_buffers 设为 4 16k：允许最多 4 行超长头，每行上限 16KB；这样单行 Cookie 最长支持约 15.8KB（扣除换行符等开销）
- 同步设置 client_header_timeout 5s：防止慢速发送攻击，让连接无法长期占着缓冲区
比调参数更根本的防护手段
缓冲区调优是兜底措施，主动防控更可靠：
- 前端避免在 Cookie 中塞 Base64 JSON、完整 JWT payload 等冗余数据
- Nginx 层用 proxy_set_header 清理非必要头（如 X-Debug-*、重复的 X-Forwarded-*）
- 在 CDN 或 API 网关前置层对单个 Cookie > 8KB 的请求直接 400 拒绝
- 后端改用 short token + server-side session，把状态存在服务端而非 Cookie
