proxy_buffer_size仅缓存后端返回的响应头，不防范客户端大Token导致的内存压力；真正影响请求头处理的是client_header_buffer_size和large_client_header_buffers。
proxy_buffer_size 本身不防范“大 Token 挤爆内存”，它只负责缓存后端返回的响应头（headers），且仅占固定一小块内存。真正因大 Token 导致内存压力的，通常是客户端请求头中携带超长 JWT、Authorization 或自定义认证字段，而 Nginx 默认用很小的缓冲区接收这些请求头——这时起作用的是 client_header_buffer_size 和 large_client_header_buffers，不是 proxy_buffer_size。
先分清谁在处理哪个方向的 Token
– 如果 Token 是客户端发给 Nginx 的（如 WebSocket 握手、API 登录请求里的 Authorization: Bearer xxx 或 X-Auth-Token），那是请求头，Nginx 用 client_header_buffer_size 和 large_client_header_buffers 接收，和 proxy_buffer_size 无关。
– 如果 Token 是后端返回给 Nginx 的（比如登录成功后 Set-Cookie 带了长 JWT，或反射回 Authorization 头），那才是 proxy_buffer_size 管的范围——但它只管这一小段 header 缓冲，不参与响应体或全局内存调度。
真正需要调的参数（针对客户端发来的大 Token）
在 http 或对应 server 块中设置：
- client_header_buffer_size 2k; —— 提升初始请求行+短头的缓冲，默认 1k，微增即可
- large_client_header_buffers 4 16k; —— 关键！表示最多分配 4 个缓冲区，每个 16KB，总容量 64KB，足以容纳含 8–10KB JWT 的完整请求头
-
underscores_in_headers on; —— 若 Token 放在带下划线的自定义头（如
X-Api-Token）中，需开启才透传 - ignore_invalid_headers off; —— 避免非法字符头被静默丢弃，便于定位 Token 解析失败问题
proxy_buffer_size 只在后端返回大 Token 头时才相关
例如后端把用户凭证反射进响应头（X-User-Profile、Set-Cookie 含长 JWT），此时：
- 用
curl -v http://backend/ |& grep '^ 实测响应头总字节数 - 设
proxy_buffer_size为实测值 +20%～30%，常见值：8k（多数场景）、16k（SSO/多 Cookie）、32k（遗留系统，不建议更大） - 该值必须 ≤ 单个
proxy_buffers大小（如proxy_buffers 8 32k，则proxy_buffer_size最大只能是 32k）
治本：别让 Token 进 Header
靠调缓冲只是兜底，长期应优化后端行为：
- JWT 不直接塞进
Authorization或响应头，改用短 session ID + 后端查表 - 合并多个
Set-Cookie，避免重复写入相同域的长 Cookie - 禁用非必要调试头（
X-Powered-By、X-Debug-Info） - 对 WebSocket 握手等敏感路径，增加前置校验，拒绝明显超长 Token 的请求（如 >4KB）
