413错误是Nginx在请求入口处拦截超限请求体所致，必须在匹配上传路径的location块中配置client_max_body_size（如location /api/upload { client_max_body_size 500m; }），并同步调整proxy_read_timeout、client_body_buffer_size等参数及后端限制，最后执行nginx -t && nginx -s reload生效。
413 错误是 Nginx 在请求刚进入时就拦截了超大的请求体，根本没传到后端——所以改前端、调后端代码或只 reload 服务都没用，必须精准调整 Nginx 的 client_max_body_size 及其配套参数。
必须写在匹配上传路径的 location 块里
该指令按 location > server > http 优先级生效。很多人在 http 块设了 500m，但实际请求走的是 location /api/upload，而这个块里没写配置，就会继承默认的 1m，照样报 413。
- ✅ 正确做法：在转发上传请求的 location 中直接设置，例如：
location /api/upload {<br> client_max_body_size 500m;<br> proxy_pass http://backend;<br>} - ⚠️ 若多个上传接口分散（如
/upload、/chunk、/file），可在每个对应 location 中分别设置，更安全 - ❌ 避免只在 http 或 server 块统一放宽——会误放开登录、管理等非上传接口，扩大攻击面
配套参数不调，大文件照样失败
client_max_body_size 只决定“让不让进”，真正影响上传稳定性的是缓冲、超时和临时文件机制。
-
client_body_buffer_size：建议设为
512k～1m。太小（如默认 8k）会导致频繁刷盘；太大则浪费内存 -
proxy_read_timeout 和 proxy_send_timeout：建议设为
3600（1 小时），防止 Nginx 在接收完整请求体或转发给后端时超时断连 -
client_body_temp_path：确认该路径（默认
/tmp）磁盘空间充足，且 Nginx 运行用户（如www-data或nginx）有读写权限，否则会转为 500 错误
后端限制必须同步对齐
Nginx 放行后，请求会继续流转。若后端自身限制更小，仍会失败，且错误可能表现为 400、500 或连接中断，而非 413。
- PHP：需同时调大
upload_max_filesize和post_max_size（后者 ≥ 前者），单位用M，如upload_max_filesize = 500M - Spring Boot：在
application.yml中配置：spring:<br> servlet:<br> multipart:<br> max-file-size: 500MB<br> max-request-size: 500MB
- Node.js（Express + Multer）：初始化时指定
limits: { fileSize: 500 * 1024 * 1024 }
验证是否真生效，别只信 reload
配置改完不等于问题解决，必须实测+日志交叉验证。
- 用
curl -F "file=@test.zip" http://yourdomain.com/api/upload上传一个略超原限制（如 1.1MB）、但小于新限制（如 500MB）的文件 - 检查 Nginx 错误日志：
tail -f /var/log/nginx/error.log，搜索client intended to send too large body—— 若无此记录，说明已放行 - 确认响应头含
Server: nginx且状态码是 413 → 是 Nginx 拦截；若含X-Powered-By: Express或Spring→ 是后端拒绝 - 执行
nginx -t检查语法，再nginx -s reload（或systemctl reload nginx）使配置生效
