关键是要让client_header_buffer_size和large_client_header_buffers协同工作：前者设为略大于实测最大请求头（如4k），后者单buffer大小须≥前者（如4 8k），且必须置于http或server块顶层，配合client_header_timeout等加固措施。
要防止 Nginx 因请求头过大返回 400 Bad Request（常见提示：“request header or cookie too large”），关键不是盲目调大参数，而是让 client_header_buffer_size 和 large_client_header_buffers 协同工作，在解析阶段就合理拦截或接纳真实流量。
它不是内存保护，而是结构化拒绝
这个参数不负责“防止缓冲区溢出漏洞”，也不依赖运行时内存检查。它的作用是：为每个新连接预分配一块固定大小的内存，只用来存请求行（如 GET /path HTTP/1.1）和所有请求头字段（包括键、值、冒号、空格、换行符）。一旦超限，Nginx 立即放弃该请求，返回 400，并记日志——不进入后续处理流程，也不占用更多资源。
- 默认值仅 1k，连一个中等长度的 JWT Token（常 2–4KB）都装不下
- 它只是“第一道缓冲”，能否撑住取决于实际请求头总长度，而非单个字段
- 若失败，Nginx 才会尝试启用
large_client_header_buffers；但后者也有总量上限
必须和 large_client_header_buffers 配套设置
单独改 client_header_buffer_size 没用。这两个参数是绑定关系：
-
client_header_buffer_size 4k表示每个连接先分 4KB 初始缓冲 -
large_client_header_buffers 4 8k表示最多再分配 4 块 8KB 缓冲，总上限 32KB - 注意：后者的“单块大小”（如 8k）必须 ≥ 前者（如 4k），否则 Nginx 启动报错
- 配置位置只能在
http块或server块顶层，不能写在location里
按业务场景设最小够用值
安全不是越大越好，而是贴合真实头部长度。建议参考这些典型值：
- 普通静态网站或后台管理页：保持
client_header_buffer_size 1k即可 - 带 SSO 登录、多域名 Cookie 或灰度标识头：设为
2k或4k - API 网关、微服务入口（含长 JWT + traceparent + 自定义头）：至少
4k，推荐8k，配套large_client_header_buffers 8 16k - 对外登录接口等高敏路径：可收紧为
1k+2 4k（总上限 8KB），并开启错误日志采样
别忘了配合超时与行为控制
光加缓冲区防不住慢速攻击——攻击者可以每秒只发 1 字节头字段，长期占着连接。还需：
-
client_header_timeout 8s：读取请求头超过 8 秒直接断连 -
reset_timedout_connection on：对超时连接发 RST，快速释放内存 -
underscores_in_headers off：禁用下划线，防绕过鉴权或框架歧义解析
