必须在匹配上传路径的location块中显式配置client_max_body_size，因Nginx优先级为location>server>http；还需同步调大client_body_buffer_size、client_body_temp_path权限、proxy_read_timeout等配套参数，否则仍会因缓冲、超时或权限问题导致上传失败。
只改不能解决上传失败问题，413 错误只是表象，背后常是缓冲、权限或超时连环失效。
为什么改了
还报 413？
因为 Nginx 的匹配优先级是
>
>
。如果你在
块里设了
，但上传请求走的是
，而该
块里没重写这个值，它就会继承更上层的默认值（通常是 1m），而不是你期望的 500m。
浏览器上传接口路径是
，就必须在对应
里显式写
在
块设虽能覆盖多数路径，但会把登录、表单等非上传接口也放宽，增加攻击面
单位拼写敏感：
合法，
或
可能因大小写不一致被忽略
必须和哪些参数一起调？
它只管“让不让进”，不管“稳不稳传”。大文件上传要跑通，以下三项必须同步检查：
Docker Desktop（linux）
当前 Docker 最新稳定版本之一，主要针对稳定性和兼容性进行了修复优化，适合生产环境与日常开发使用。该版本继续强化 AI 开发支持、容器日志管理以及 Docker Engine 的安全能力，对 Windows/macOS/Linux 平台兼容性进行了进一步优化。
下载
：建议设为
～
。太小（如默认
）导致频繁刷盘到磁盘；太大（比如设成和
一样）会吃光内存，仅适合极低流量场景
：确认路径（默认
）磁盘空间充足，且 Nginx 运行用户（如
或
）对该路径有读写权限，否则日志里会出现
和
：建议都设为
（1 小时）。Nginx 在转发给后端前需完整收完请求体，超时就直接断连，前端看到的是网络错误，不是 413
怎么验证配置真生效了？别只信浏览器
浏览器点选上传容易受前端 JS 校验、缓存或网络抖动干扰，真实验证得用命令行发原始 multipart 请求：
用
测试，观察返回码是 200 还是 413
实时盯
，出现
表示限制已起效；出现
或
则说明是权限或超时问题
如果后端是 PHP，还要同步检查
、
、
等，否则请求会在 Nginx 之后卡死
最容易被忽略的是
权限和
——它们不出现在任何错误页里，却能让上传在无声中失败。上线前务必用真实大文件 +
+
三者交叉验证。
client_max_body_sizeclient_max_body_sizelocationserverhttphttpclient_max_body_size 500mlocation /api/uploadlocation/uploadlocation /upload { ... }client_max_body_sizeserver500mb500MB500Mbclient_max_body_sizeclient_body_buffer_size512k1m8kclient_max_body_sizeclient_body_temp_path/tmpwww-datanginxopen() failed (13: Permission denied)proxy_read_timeoutproxy_send_timeout3600curl -F "file=@test.zip" http://your-domain.com/api/uploadtail -f /var/log/nginx/error.logclient intended to send too large bodyPermission deniedupstream timed outupload_max_filesizepost_max_sizemax_execution_timeclient_body_temp_pathproxy_read_timeoutcurlerror.log