Nginx默认client_header_buffer_size为1k、large_client_header_buffers为4 8k，易因JWT或长Cookie触发400错误；需在http或server块中显式配置client_header_buffer_size 4k和large_client_header_buffers 4 16k，并重载生效。
phpEnv 默认的 Nginx 配置不支持大 Header，直接触发 400 错误，必须手动调大两个缓冲区参数才能解决。
确认当前 large_client_header_buffers 和 client_header_buffer_size 值
phpEnv 的 Nginx 配置通常位于 C:\phpenv\nginx\conf\nginx.conf（Windows）或 /usr/local/phpenv/nginx/conf/nginx.conf（Linux/macOS）。不要依赖“没报错就默认 OK”——默认值极可能不够用：
-
client_header_buffer_size默认是1k，连一个长 JWT 就可能撑爆 -
large_client_header_buffers默认是4 8k，即单个请求头最多只能塞进一个8k缓冲区
运行以下命令快速验证生效值：
nginx -t && nginx -T | grep -E "(client_header_buffer_size|large_client_header_buffers)"
注意大小写；若输出为空，说明配置文件里没显式设置，走的就是编译默认值。
立即学习“PHP免费学习笔记（深入）”；
修改 phpEnv 的 Nginx 配置文件
在 http 块（全局生效）或 server 块（仅该站点）中添加或修改这两行：
client_header_buffer_size 4k;<br>large_client_header_buffers 4 16k;
解释：
-
client_header_buffer_size 4k：把初始缓冲从1k提到4k，避免小幅度超限就立刻 fallback 到 large 缓冲 -
large_client_header_buffers 4 16k：允许最多 4 个16k缓冲区，但关键点是——单个请求头字段仍不能超过16k（比如一个Cookie或Authorization字段）
别设成 4 64k 这类值：内存开销翻倍，且对大多数业务无意义；4 16k 已覆盖含完整权限声明的 JWT 场景。
常见踩坑点和验证方式
改完必须做三件事，缺一不可：
- 运行
nginx -t检查语法——phpEnv 的路径常带空格或中文，容易因引号缺失报错 - 用
nginx -s reload重载（不是restart），否则 php-fpm 连接可能中断 - 触发一次真实大 Header 请求并看错误日志：
tail -f C:\phpenv\nginx\logs\error.log（Win）或/usr/local/phpenv/nginx/logs/error.log（Linux/macOS）；若仍有client sent too large header，说明还没生效或某个location块覆盖了全局设置
特别注意：large_client_header_buffers 不影响请求体（body），上传大文件要另配 client_max_body_size；也和 proxy_set_header 无关——那是发给后端用的，不是收客户端的。
比调参更治本的做法
单纯放大缓冲只是兜底，长期来看容易掩盖设计问题：
- 前端把多个
Cookie合并成一个长串？改成sessionStorage存 token，只传短 ID - SSR 框架（如 Next.js）注入大量
X-Debug-*头？构建时关掉调试头，或用proxy_hide_header X-Debug-*在入口层过滤 - OAuth2 流程带超长
Authorization: Bearer ...？后端应支持short_token → session lookup，而不是透传原始 JWT
缓冲区调大是 quick fix，但 header 膨胀本身往往意味着链路中某一层在滥用 header 传数据——这才是最该被揪出来的点。
