Nginx 报 upstream sent too big header 怎么办？PHP、反向代理与 Cookie 排查

先看错误日志中的 upstream 类型，不要先调客户端请求头：Nginx 报 upstream sent too big header while reading response header from upstream 时，表示 PHP-FPM、Node、Java 或其他上游返回的响应头放不进读取第一段响应的缓冲区。先进入“宝塔面板 → 网站 → 目标站点 → 日志”查看同一时刻的错误日志和完整生效配置；fastcgi:// 分支检查 fastcgi_buffer_size，http:// 或 https:// 分支检查 proxy_buffer_size。

默认选择：先找出异常增大的 Set-Cookie、Location 或应用调试头并从应用侧缩短，只在确认业务确实需要较大响应头时，才对目标站点或 location 小幅增加对应上游缓冲。检查和改配置通常不额外收费；更大的缓冲会增加并发请求的内存占用。清理 Cookie 可能让用户退出登录，错误修改认证头或回调地址可能造成登录循环。

这条错误和 400、414、502 有什么区别

现象或日志	发生方向	应该检查
upstream sent too big header	上游应用返回给 Nginx 的响应头	上游协议、响应头内容、对应 buffer
400 Request Header Or Cookie Too Large	浏览器发给 Nginx 的请求头	客户端 Cookie、large_client_header_buffers
414 Request-URI Too Large	浏览器请求行或 URL	查询参数、重定向和请求行
一般 502 且日志为 connect() failed	Nginx 无法连接上游	进程、Socket、端口与权限
504 或 upstream timed out	上游已连接但响应超时	慢请求、数据库、外部依赖与超时

浏览器可能只显示 502 Bad Gateway，但决定修法的是 Nginx 错误日志。现有的宝塔 PHP 502 排查覆盖进程、Socket 和资源故障；本文只处理“上游响应头过大”这一条日志。若日志是超时，应转到Nginx 504 与上游超时排查。

先找到命中的是 FastCGI 还是反向代理

下面命令读取 Nginx 当前生效配置和最近错误，不会修改站点。配置和日志可能包含域名、源站地址、内部路径和请求参数，对外分享前必须脱敏。

sudo nginx -T 2>&1 | grep -nE 'server_name|location|fastcgi_pass|proxy_pass|fastcgi_buffer|proxy_buffer'
sudo grep -F 'upstream sent too big header' /var/log/nginx/error.log | tail -20

宝塔的站点错误日志路径可能在站点配置的 error_log 指令中，不一定是示例路径。以 nginx -T 输出为准：

• 日志中的上游形如 fastcgi://unix:/... 或配置使用 fastcgi_pass，通常是 PHP-FPM，需要检查 FastCGI 缓冲。
• 日志中的上游形如 http://127.0.0.1:端口，或配置使用 proxy_pass，通常是 Node、Java、容器或另一层 Web 服务，需要检查代理缓冲。
• 同一站点可能同时包含两种 location。配置写在没有命中请求的位置，即使语法正确也不会生效。

怎样确认到底哪个响应头过大

优先从服务器内直接访问上游，排除 CDN 和外层代理。请把域名、源站地址、端口和路径替换为真实值。响应头可能包含会话 Cookie、令牌、内部地址和用户信息，只在受控终端保存，公开时必须脱敏。

curl -sS -D /tmp/upstream-headers.txt -o /dev/null 'http://127.0.0.1:APP_PORT/PROBLEM_PATH'
wc -c /tmp/upstream-headers.txt
sed -n '1,80p' /tmp/upstream-headers.txt

如果上游依赖真实 Host 或 HTTPS，应按应用要求添加正确主机头并验证证书，不要用任意域名替代。对于 PHP-FPM，不能直接用 HTTP curl 访问 FastCGI Socket；可以在临时绕过 CDN 的受控请求中读取响应头，或从应用和 PHP 日志定位产生响应头的代码。

常见增大来源包括：

• 应用重复发送多个 Set-Cookie，旧 Cookie 没有正确覆盖或清理；
• 会话、JWT 或用户状态被放进过长 Cookie；
• 登录回调拼接了很长的 Location，甚至形成重定向循环；
• 调试、追踪或网关注入大量自定义响应头；
• 多层代理反复附加同类头字段。

如果只清除浏览器 Cookie 后暂时恢复，说明请求状态可能参与了异常响应，但并不能证明 Nginx 已修好。还要在服务端找出哪个响应头持续增长，并验证新会话、旧会话和登录回调。

为什么优先修应用而不是无限增大缓冲

Nginx 官方文档说明，fastcgi_buffer_size 和 proxy_buffer_size 用于读取上游响应的第一部分，而这部分通常包含响应头；如果头部超过该缓冲，响应会被视为无效。增大缓冲能让 Nginx 接收更大的头，但不会解决重复 Cookie、错误重定向或泄露调试信息。

应用侧先做四项检查：

1. 用相同账号和路径复现，比较正常请求与故障请求的响应头差异。
2. 检查 Cookie 是否重复设置、值是否包含本应保存在服务端的状态、域名和路径是否导致多份 Cookie 并存。
3. 检查登录、支付回调和反向代理地址是否形成循环拼接。
4. 关闭只为临时诊断启用的响应头，并确认链路追踪 ID 有固定上限。

WordPress 接入 CDN 或反向代理后若同时出现登录跳转循环，应先核对站点地址、代理 HTTPS 和 Cookie 作用域，可结合WordPress 反向代理无限重定向排查。不要通过放大缓冲掩盖循环。

确实需要更大响应头时怎么改

修改前保存 nginx -T 输出和站点配置备份。下面的 16k、缓冲数量和大小只是演示语法，不是所有服务器的固定答案。应根据已经测得的响应头、并发量和内存预算选择略高于实际需求的最小值，并放在实际命中的 server 或 location。

PHP-FPM 使用 FastCGI 时，示例为：

location ~ \.php$ {
    # 保留站点现有 include、SCRIPT_FILENAME 和 fastcgi_pass
    fastcgi_buffer_size 16k;
    fastcgi_buffers 8 16k;
}

Node、Java 或容器通过 HTTP 反向代理时，示例为：

location / {
    # 保留站点现有 proxy_pass 和请求头设置
    proxy_buffer_size 16k;
    proxy_buffers 8 16k;
    proxy_busy_buffers_size 32k;
}

不要把两组指令一起无差别加到全局 http 区块。fastcgi_buffers 或 proxy_buffers 主要参与整个响应的缓冲，真正读取第一段响应头的是对应的 *_buffer_size；相关缓冲参数之间还有大小约束。若只为单个登录路径需要更大头，应尽量缩小生效范围。

宝塔里改完为什么没有生效

常见原因不是数值太小，而是改错层级或文件被其他 include 覆盖。保存后按下面顺序检查：

sudo nginx -t
sudo nginx -T 2>&1 | grep -nE 'fastcgi_buffer_size|proxy_buffer_size|server_name'
sudo systemctl reload nginx
sudo systemctl status nginx --no-pager

nginx -t 必须成功后才能重载。nginx -T 中要看到目标域名、目标 location 和新值处于同一配置路径。宝塔可能把站点配置、PHP include 和反向代理配置拆成多个文件；只改主配置但请求命中另一个片段时不会生效。

如果语法测试失败，不要重启 Nginx。恢复刚才的站点配置备份，再次运行 nginx -t，保持当前工作进程继续提供旧配置。若重载成功但内存快速增长，应回退新缓冲值并从应用侧继续缩短响应头。

客户端请求头参数什么时候才相关

client_header_buffer_size 和 large_client_header_buffers 处理的是浏览器发给 Nginx 的请求头。Nginx 官方核心模块文档说明，请求行过大可返回 414，请求头字段放不进缓冲可返回 400。这与“读取上游响应头时过大”方向相反。

只有错误日志和状态明确指向客户端 Cookie 或请求头时，才检查客户端缓冲。看到 upstream sent too big header 就增加 large_client_header_buffers，通常改不到真正失败的位置。

修复后怎样验证

1. 从源站受控访问原故障路径，确认返回预期状态码，错误日志不再出现同一条上游头错误。
2. 从公网和 CDN 路径再次访问，比较状态码、跳转链和响应头，不把缓存的旧 502 当成当前结果。
3. 分别测试未登录、已登录、旧 Cookie、新 Cookie和权限不同的账号，确认不是只修好一个会话。
4. 完成登录、后台操作、支付或 OAuth 回调等产生较多响应头的关键动作。
5. 观察 Nginx 内存、工作进程和错误率，确认缓冲调整没有带来不可接受的资源增长。

网站恢复后，敏感路径和原有访问限制仍应保持。若同时处理过 403，不要为解决响应头问题删除安全规则，可参考Nginx 403 日志分流确认边界。

回退与长期治理

配置导致新错误时，恢复目标站点的上一版配置，执行 nginx -t，成功后平滑重载。应用侧若修改 Cookie 或会话格式，先保留兼容读取窗口；需要强制失效旧 Cookie 时，应提前说明用户会退出登录，并确认没有把购物车或未提交表单只保存在客户端状态中。

长期应为响应头大小、重定向次数、登录失败率和 Nginx 502 建立监控。每次新增认证代理、A/B 测试、追踪系统或 CDN 规则时，检查是否重复注入 Cookie 与调试头。缓冲值只是容量边界，不能替代对响应头责任人的治理。

官方资料

• Nginx：FastCGI 响应首段与 fastcgi_buffer_size
• Nginx：HTTP 上游响应首段与 proxy_buffer_size
• Nginx：客户端大请求头与请求行缓冲边界