413错误本质是Nginx主动拒绝过大的请求体，需在http/server/location中正确配置client_max_body_size并重载，且后端限制须≥Nginx值。
413 错误本质是 Nginx 主动拒绝了过大的请求体，不是 PHP 或应用层的问题，所以改 php.ini 里的 upload_max_filesize 或 post_max_size 无法绕过这一关。关键难点在于：配置位置不对、未生效、或与其他限制叠加导致“改了也没用”。
client_max_body_size 必须放在正确的作用域里
Nginx 的 client_max_body_size 支持在 http、server、location 三个层级设置，作用范围逐级收窄：
-
http{ }中设置 → 影响所有 server 块，适合统一策略，但不够灵活 -
server{ }中设置 → 只影响该域名或端口的全部请求，推荐大多数场景使用 -
location{ }中设置 → 仅对匹配路径生效（如location /upload），精准但易遗漏主入口
常见错误是只在 http 块加了配置，但实际请求走的是某个 server 块——而该 server 块又显式写了 client_max_body_size 1m，就会覆盖上级设置。
Azure Linux App Service 等托管环境不能直接改系统 nginx.conf
这类平台不开放 root 权限或 /etc/nginx 配置目录写入权限，必须用平台支持的方式注入自定义配置：
- 先通过 Kudu SSH 执行
cp /etc/nginx/sites-available/default /home/site/wwwroot/default - 再在
/home/site/wwwroot/default文件中添加client_max_body_size 20M;（注意分号） - 确保该配置出现在
server{ }块内（不是最外层http），否则无效 - 无需重启 Nginx，App Service 会自动加载新配置
改完没生效？检查是否被其他限制拦截
即使 Nginx 层放行，上传仍可能失败，因为还有两道常见关卡：
-
PHP 层限制：确认
upload_max_filesize和post_max_size都 ≥ 你设的 Nginx 值（例如 Nginx 设 20M，PHP 至少也要设 20M） -
超时问题：大文件上传耗时长，Nginx 默认
client_header_timeout和client_body_timeout往往只有 60 秒，可同步增加：client_header_timeout 300;<br>client_body_timeout 300;
验证配置是否真正生效
别只信 reload 成功提示，要实测：
- 用
nginx -t检查语法（托管环境通常不可用） - 在 Kudu 的
Process Explorer查看当前加载的配置路径，确认读取的是你修改的文件 - 上传一个略大于原限制（如 1.1MB）、但小于新限制（如 20MB）的文件，观察是否仍报 413
- 查看 Nginx error log（
/var/log/nginx/error.log或 App Service 的诊断日志），搜索 “client intended to send too large body” 关键字
