client_header_buffer_size仅影响单次请求头解析，与长连接复用无关；它决定初始缓冲区大小，若请求头超长（如jwt、cookie）则触发400错误；需按实测最大单行头长度配置，并配合large_client_header_buffers使用。
client_header_buffer_size 对长连接本身没有直接影响，它只管请求头的初始解析阶段，和连接是否复用（keepalive）无关。
它真正起作用的地方是每次新请求的头部读取
即使启用了长连接，每个 HTTP 请求仍需独立解析请求行和请求头。Nginx 为每个新请求分配一个初始缓冲区，大小由 client_header_buffer_size 决定。如果某次请求带了超长 Cookie、JWT 或多层代理透传头，而这个缓冲区装不下其中任意一行（比如整条 Authorization:），就会触发错误 —— 此时连接可能还活着，但这次请求直接被拒（400）。
长连接场景下更需谨慎配置
长连接意味着客户端会在一个 TCP 连接上发多个请求，其中某些请求可能头部极短（如静态资源），有些却极长（如带 Token 的 API 调用）。若只按平均值设缓冲，容易在某个“重头”请求上失败，导致整个连接后续请求受影响或被客户端主动断开。
- 建议按业务中实测的单行最大请求头长度（如最长的 Cookie 或 Authorization 值）向上取整设值
- 必须同步配好
large_client_header_buffers，确保单块大小 ≥client_header_buffer_size - 对高风险路径（如
/api/）可单独加大，公开路径（如/health）保持默认 1k，缩小攻击面
它不解决 keepalive 超时或连接空闲问题
长连接的维持靠的是 keepalive_timeout 和 keepalive_requests。这两个参数控制连接复用时长和请求数上限，和请求头缓冲完全无关。调大 client_header_buffer_size 不会让连接保持更久，也不会提升并发能力；它只避免因头部过大导致的单次请求失败。
验证是否适配长连接下的真实流量
抓取生产环境长连接中实际发出的“最重”请求头：
- 用
curl -v或浏览器 DevTools 复制完整请求头 - 执行
echo -n "头内容" | wc -c算字节数 - 查 access log 中
$request_length，分离出头部占比（通常请求行+头占前 1–2KB，其余为 body） - 若实测最大为 5200 字节，推荐设
client_header_buffer_size 8k+large_client_header_buffers 4 16k
