Nginx 413 上传失败怎么解决？请求体大小与多层限制排查
小文件能上传，大文件立即返回 413，通常值得先检查请求体限制。但“用户选了二十兆文件”并不等于整次 HTTP 请求只有二十兆，表单字段和编码也会占用空间。本文适用于 Nginx 代理或 PHP-FPM 网站，具体阈值需要根据业务文件规格确定。
确认哪一层返回了错误
记下失败文件大小、类型、上传路径和发生时间，观察是否所有账号、所有网络都能复现。检查 Nginx 访问与错误日志中是否出现对应请求。如果源站没有收到请求，优先核对 CDN、网关或前置代理的上传限制，而不是改源站后反复重试。
如果日志包含请求体过大的提示，核对它对应的站点和 location。一个服务器可以同时承载多个站点，修改了默认站点不代表上传路径会使用这份配置。还要检查应用是否自己返回 413，不能只根据错误页面中的服务器名称判断。
在正确范围设置有限阈值
client_max_body_size 用于约束请求体大小，可以按站点或路径设置。下面仅演示给既有上传 location 增加一条限制，其他代理或 FastCGI 指令仍保留原有配置：
# 加入实际上传 location，示例值需按业务调整
client_max_body_size 25m;
若业务允许单个二十兆文件，应为表单开销保留合理余量，同时核对一次能否上传多个文件。不要为了让一次测试通过就设为无限制，因为请求体的接收、暂存和后端处理都要消耗资源。Nginx 核心模块说明
对普通页面维持较小限制、对确需上传的路径单独放宽，通常更容易管理。更改之前查清是否存在更内层的覆盖值，并保留修改前配置，防止站点范围与实际生效范围不同。
应用限制需要与代理协调
PHP 网站还要核对运行中的 FPM 环境，而不只是命令行 PHP。upload_max_filesize 影响单文件上传，post_max_size 约束 POST 数据，后者应考虑多个文件与其他字段。超过应用限制后的表现可能是错误页面，也可能是应用拿不到预期上传数据。
PHP 的配置文件、FPM 池覆盖项和应用自身验证都可能参与限制。先用受控方式确认实际生效值，再修改对应位置；不要把显示全部配置的调试页面公开留在站点上。PHP 核心配置手册
Node.js、Python 等应用也可能由框架、中间件或服务器限制请求大小，应查对应版本的官方设置。Nginx 放行只意味着请求能够继续向后传递，不能替代文件类型、身份、配额与业务层校验。
检查临时存储与上传处理方式
阈值提高后，磁盘临时目录、应用保存目录和用户配额可能成为下一处瓶颈。确认目标文件系统有空间与 inode 余量，运行账号有必要写入权限，并安排未完成上传的清理策略。不能因为出现写入错误就把整个上传目录设成任意人可写。
超大文件还应考虑对象存储直传、分片上传或断点恢复，但这些需要应用支持和完整验证。单纯增加超时不会解决请求体限制，单纯增加大小也不会解决中途断网，两类故障要分别处理。
用边界样本验收并准备回退
配置语法检查通过后再重新加载；若调整 PHP-FPM，按照本机服务方式应用更改。准备明显低于阈值、接近业务上限以及超过允许上限的测试文件，使用获准的测试账号上传，确认合法请求成功、超限请求得到清楚错误。
验收不仅看状态码，还要检查文件完整性、保存位置、应用记录和临时文件是否合理释放。移除测试内容时遵循应用正常管理流程。若提高限制引发资源异常，恢复原值并暂停受影响上传功能，再重新评估业务上限与处理架构。