Nginx 登录回调报 upstream sent too big header，调缓冲仍无效

登录回调或某个接口返回 502，Nginx 错误日志包含 upstream sent too big header while reading response header from upstream。这表示 Nginx 在读取后端响应头时遇到了缓冲区限制，不能只看到“header”就去调整客户端请求头大小。

这个问题常在响应携带较多或较大的 Set-Cookie 时出现，也可能是其他响应头过大。先确认发生错误的请求由哪种后端协议处理，再判断该调哪组缓冲参数。

先从日志辨认 upstream

以下为删去业务信息后的日志片段示例：

upstream sent too big header while reading response header from upstream
upstream: "fastcgi://unix:/run/php/php-fpm.sock:"

如果 upstream 是 fastcgi://，请求走的是 FastCGI，例如 PHP-FPM，需要检查 fastcgi_buffer_size。如果是 http:// 或 https://，请求走的是 HTTP 代理，需要检查 proxy_buffer_size。uWSGI 等其他协议也有自己的参数，不能把两组设置一起粘贴后就认为覆盖了所有请求。

先定位实际命中的 server、location 和被包含的配置。Nginx 1.9.2 起可以用 nginx -T 查看展开的配置；非默认配置要使用运行实例相同的 -c 和路径设置。输出可能包含内部地址或敏感配置，不应直接公开。

nginx -T

如果下层 location 有自己的缓冲设置，或者改到另一个站点文件，顶层改动可能没有按预期作用于出错请求。配置修改后若检查失败，原工作进程仍可能在使用旧配置，此时继续重试接口不能验证新参数。

对发生错误的入口调整

proxy_buffer_size 和 fastcgi_buffer_size 用于读取后端响应的第一部分，其中通常包括响应头。它们默认按平台内存页大小设置为 4K 或 8K。增加 *_buffers 的数量，不等于已经扩大了用于接收响应头的这一块缓冲区。

下面是供有较大响应头的入口评估的配置片段，不是通用推荐值。应放在实际处理请求的现有 location 中，保留原有 proxy_pass 或 fastcgi_pass 及应用所需参数，不要新建一个缺少业务配置的入口。

HTTP 代理片段：

proxy_buffer_size 32k;
proxy_buffers 8 32k;
proxy_busy_buffers_size 64k;

FastCGI 片段：

fastcgi_buffer_size 32k;
fastcgi_buffers 8 32k;
fastcgi_busy_buffers_size 64k;

选择对应协议的一组。实际值需覆盖正常响应头，并与其余缓冲参数满足 Nginx 的配置约束。范围尽量限于受影响的入口；扩大缓冲会增加相关连接的潜在内存开销，不应把所有站点都改成极大的数值。

关闭 proxy_buffering 或 fastcgi_buffering 也不能自动消除这个限制。Nginx 仍需要读取响应头，不能将“关闭整个响应的缓冲”当作“响应头大小无限制”。

同时查清响应为什么变大

查看后端生成的响应头，重点检查重复 Set-Cookie、把过大认证数据直接放入 Cookie，以及应用异常时累积的头字段。认证回调中的 code、token 和 Cookie 都可能敏感，诊断记录应脱敏。

正常业务确实需要较大响应头时，可以按规模调整缓冲。如果头字段因为程序错误持续增长，扩大缓冲只会把下一次失败推迟，应修复头字段生成逻辑。large_client_header_buffers 控制的是客户端请求头，与这条后端响应头错误的方向不同。

备份原配置，在对应实例上执行 nginx -t，成功后再通过该实例的管理方式重载。检查失败时先修正配置；运行后出现异常则恢复原缓冲设置并重新检查、重载。

用相同登录流程和代表性的账号状态验证，确认接口返回预期响应，错误日志不再出现该请求的响应头过大记录。同时观察相关连接的内存开销，避免只以一次匿名请求成功作为登录问题已经恢复的证明。