Least Connections 负载下需按最宽响应头设 proxy_buffer_size：实测各上游最大响应头字节数，加20%余量后向上取整至2的幂（如16k），并确保 ≤ proxy_buffers 单块大小，同时启用 proxy_buffering、配置 proxy_buffers 和 proxy_busy_buffers_size，并在HTTP/2时同步调大 http2_max_field_size。
Least Connections 是 Nginx 负载均衡的调度算法，它只决定把新请求分发给哪个上游服务器，和 proxy_buffer_size 没有直接关系。proxy_buffer_size 控制的是单个请求响应头的缓存大小，属于代理缓冲机制，与负载算法无关。
所以问题本质不是“Least Connections 下怎么配”，而是：用 Least Connections 做负载时，如何合理设 proxy_buffer_size 防止响应头溢出导致 502。
为什么 Least Connections 场景下更要关注 proxy_buffer_size？
使用 Least Connections 通常意味着后端节点能力不均、长连接多、会话粘性弱，容易出现：
- 某些节点承担更多认证类请求（如带 JWT、多 Set-Cookie 的登录/回调接口）；
- 同一节点被反复选中，其响应头可能更复杂（如链路追踪头叠加、动态 Cookie 膨胀）；
- 错误日志里
upstream sent too big header往往集中在少数几个 upstream server 上 —— 这正是 Least Connections “倾向选择空闲少但响应快”的副作用。
所以，不能按平均值设 buffer，而要按最宽响应头场景来配置。
如何实测并设定合理的 proxy_buffer_size
-
抓取真实最大响应头
CPA Update - Secure CLI Proxy API Maintenance下载安全更新和维护 CLI Proxy API（CPA）部署与配置。用于 CPA 镜像升级、配置变更、认证目录兼容修复、上线验证与回滚。适用于用户提到“CPA 更新/升级/配置改了/容器重建/回滚”等场景。
curl -v https://your-api/ 2>&1 | grep '^< ' | wc -c
注意：结果含每行末尾
\r\n（各 1 字节），实际字节数 = 统计值。 取所有上游中最宽的那个头 如果你有 3 个 upstream server，分别测试它们返回的登录接口，记录最大值（比如 A 节点返回 13782 字节，B 和 C 只有 4200 字节），就以 13782 为准。
-
加 20% 余量，向上取整到 2 的幂次
- 13782 × 1.2 ≈ 16538 → 最近的 2 的幂是 16384（16k）
- 配置即：
proxy_buffer_size 16k;
确认不超过单块 proxy_buffers 大小 若你设了
proxy_buffers 8 128k;，那16k完全合规；
若只设了proxy_buffers 4 8k;，则proxy_buffer_size 16k会启动失败 —— 必须先调大单 buffer size。
必须配套调整的参数（避免“只改一个却仍 502”）
proxy_buffering on;
关闭后proxy_buffer_size不生效。proxy_buffers 8 16k;
第一个 buffer 专供响应头，其余 7 个用于 body；proxy_buffer_size必须 ≤16k。proxy_busy_buffers_size 32k;
设为单 buffer 大小的 2 倍，保证边收边发不卡死。http2_max_field_size 16k;（若启用 HTTP/2）
否则即使proxy_buffer_size调大，HPACK 解码单字段仍可能截断，照样报 502。
更治本的做法：从上游精简响应头
- 关掉后端调试头（如
X-Trace-ID多层注入、X-Request-ID重复生成）； - 合并或压缩 Cookie，避免
Set-Cookie行数爆炸； - 减少
Vary字段数量（尤其不要Vary: Cookie, User-Agent, Accept-Encoding全写）； - OAuth2/JWT 场景下，考虑用 short-lived token + 后端 session 查表，而非把全部权限塞进 header。
不复杂但容易忽略
