推荐在server块中配置client_max_body_size，因其优先级高于http块、低于location块，可精准控制单域名所有请求，单位需用小写（如500m），设为0表示不限制（仅限可信环境），并需同步调优client_body_buffer_size、client_body_temp_path及后端超时参数，最后执行nginx -t验证并-s reload生效。
在 Nginx 的 server 块中设置 client_max_body_size，是控制该虚拟主机（即单个域名或 IP 绑定的服务）整体上传限制的常用且推荐方式。它比全局 http 块更精准，又比每个 location 单独配更简洁，适合大多数单一上传场景。
直接写在 server 块里就生效
只要把指令加在对应 server 块内、大括号范围内任意位置（通常放在 server_name 下方或 location 外），就会作用于该 server 下所有未被子块覆盖的请求：
-
正确示例：
server {<br> listen 80;<br> server_name upload.example.com;<br> client_max_body_size 500m;<br> location / {<br> root /var/www/upload;<br> }<br>} -
单位注意：必须用小写
m、k或g，比如500m合法，500M会启动失败 -
设为 0 表示不限制：如
client_max_body_size 0;，仅建议用于可信内网或调试环境
但它不能替代 location 级别的精细控制
如果网站有多个上传入口（比如 /api/upload、/chunk、/admin/file），而你只在 server 块设了 500m，看似够用——但实际请求可能命中某个没显式声明 client_max_body_size 的 location，而该 location 又继承了更低的上级值（甚至默认 1MB），仍会返回 413 错误。
- 若上传路径明确且集中，
server级配置足够 - 若上传接口分散或需差异化限制（如管理后台限 50MB、用户上传限 2GB），应在每个相关
location块中单独设置 - 优先级规则始终有效：
location > server > http，越靠近请求路径，控制越准
配套参数不能漏，否则照样失败
client_max_body_size 只决定“让不让进”，真正影响大文件上传是否稳定，还得看这几个关联项，建议和它写在同一作用域（比如同在 server 块里）：
-
client_body_buffer_size 512k;：内存缓冲区大小，避免频繁写临时文件；默认 8k 容易触发额外限制 -
client_body_temp_path /var/tmp/nginx/client_body 1 2;：确保路径存在、磁盘空间足、Nginx 运行用户（如www-data）有读写权限 -
client_max_body_size数值应略大于后端限制（如 PHP 的post_max_size），建议多留 10–20MB 余量 - 如果是代理后端（如转发给 Node.js 或 Spring Boot），还需同步调整
proxy_read_timeout 3600;和proxy_send_timeout 3600;，防止传输中途超时断连
改完必须重载才生效
保存配置文件后，别忘了执行命令让改动落地：
- 推荐平滑重载：
sudo nginx -s reload（不中断服务） - 也可重启：
sudo systemctl restart nginx（会有短暂连接中断） - 执行前先验证语法：
sudo nginx -t，避免配置错误导致服务不可用
