用途与验证范围
上传失败显示 413 时，问题通常需要结合请求体限制排查。文件本身小于标注上限，也不一定说明请求必然小于上限：表单字段、边界和同时上传的多个文件都会占用请求体。应先定位返回错误的是哪一层，再决定是否需要调整。
AI 辅助撰写与整理。官方资料与流程核对；未在生产服务器或编辑器中执行。
适用环境
Ubuntu 上的 Nginx 与一个你有权管理的上传应用。下列命令只检查配置语法和日志末尾，不改配置、不重载服务，也不进行真实上传；未在生产环境执行。
操作步骤
记录失败时间、请求路径、文件数量和大致体积。先查看 Nginx 错误日志中是否有对应请求，再查看应用自己的限制与日志。只有确定业务确实需要更大请求体后，才规划一个有上限的调整，不直接使用无限制设置。
sudo nginx -t
sudo tail -n 40 /var/log/nginx/error.log预期结果与核对
配置语法通过只能说明 Nginx 配置能解析，不能证明上传上限合适。如果日志明确显示请求体过大，可以结合 client_max_body_size 所在的 http、server 或 location 作用域定位实际生效值。日志路径必须以你的安装配置为准。
常见问题
若 Nginx 没有对应错误，检查前置代理、CDN 或应用是否返回了 413。上传接口路径若匹配了不同 location，查看另一个站点块的配置不会解决问题。客户端压缩、multipart 编码和多个文件总量也可能使估算与实际请求体不同。
适用边界
调整大小限制会影响资源消耗和上传处理风险，应与应用允许类型、配额、存储空间和超时一起评估。本文不提供自动更改线上限制的脚本，不建议修改 SSH、防火墙或 TLS 设置来处理 413。