client_max_body_size必须在目标location块内显式配置才生效,如/location /api/upload { client_max_body_size 500m; },否则继承默认1mb;需同步设置client_body_buffer_size、proxy_temp_path权限及超时参数。

直接在对应 location 块里写缓冲区指令,Nginx 不会自动继承父级的缓冲配置,必须显式声明才能生效。
client_max_body_size 要按上传路径单独设
这个参数控制客户端请求体上限,但只在它出现的 location 块内起作用。比如上传接口是 /api/upload,即使你在 http 或 server 块里设了 client_max_body_size 500m,只要 location /api/upload 里没重写,它仍用默认的 1MB。
- 务必在目标 location 内直接配置,例如:
location /api/upload {
client_max_body_size 500m;
proxy_pass http://backend;
} - 多个上传路径要分别配,比如 /files 和 /avatar 需各自写 location 块并设对应值
- 注意同步调大 client_body_buffer_size(如设为 32k),避免大请求体被频繁刷到磁盘
proxy_buffering 及相关参数需按响应类型分 location 控制
是否开启代理缓冲、怎么分配缓冲空间,得看后端返回的是普通 JSON、大 HTML 还是 SSE/流式数据。不同场景不能共用一套配置。
在无 root/sudo 权限的环境(云容器、VPS、隔离主机)中安装并配置 OpenClaw 浏览器工具的 headless Chrome。适用场景:...
- 普通 API 或静态资源:开启缓冲,例如
location /api/ {
proxy_buffering on;
proxy_buffer_size 16k;
proxy_buffers 8 256k;
proxy_busy_buffers_size 512k;
} - 日志推送、LLM 流响应等:必须关缓冲,否则卡住或超时
location /stream {
proxy_buffering off;
proxy_buffer_size 4k;
proxy_read_timeout 300;
} - proxy_buffer_size 始终生效,不管 buffering 开关如何,建议所有涉及 JWT 或多 Cookie 的 location 都设为 8k~16k
请求头缓冲也要按业务 location 精细调整
长 URL、大量自定义 Header 或微服务网关透传场景,容易触发 400 或 414 错误。不能只靠全局设置,得在关键 location 里加强。
- 普通页面访问可保持默认(client_header_buffer_size 1k)
- 网关类 location(如 /gateway/)建议:
location /gateway/ {
client_header_buffer_size 4k;
large_client_header_buffers 4 8k;
} - 注意:large_client_header_buffers 中的单个 size 才是硬限制,请求头必须能放进一个 buffer,不是总和
别漏掉临时文件和权限配套项
缓冲区调大后,如果响应体或请求体超出内存容量,Nginx 会写临时文件。这要求对应 location 下的 proxy_temp_path 目录可写,且大小限制合理。
- 在 location 内或其上级 server 块中确认:
proxy_temp_path /var/tmp/nginx/proxy 1 2;
proxy_max_temp_file_size 1g; - 确保该路径存在、属主为 nginx 运行用户(如 www-data)、有读写权限
- 若 location 指向不同后端,还可配合 proxy_redirect 或 proxy_set_header 做差异化处理










