error_log的warn级别日志是定位413错误根源的关键：出现“client intended to send too large body”需调client_max_body_size；“Permission denied”指向临时目录权限问题；“upstream timed out”则属超时配置不当。
看到日志里反复出现 client intended to send too large body，别急着调大 client_max_body_size。这个报错只是表象，背后可能是配置、权限或超时问题——关键得靠 error_log 里的线索来判断。
先确认 error_log 级别是否足够
默认 error_log 级别常设为 error，但这条提示实际在 warn 级别才输出。不改级别，就看不到真正原因。
- 在
nginx.conf的http或server块中明确设置：error_log /var/log/nginx/error.log warn; - 改完后执行
nginx -t && nginx -s reload生效 - 再复现一次上传，立刻查看 error.log 是否新增 warn 行
根据 error_log 具体内容区分真实原因
同一句报错，不同上下文指向完全不同的问题：
- 含
client intended to send too large body: XXX bytes→ 确实是大小超限，需调client_max_body_size - 含
open() "/var/lib/nginx/tmp/client_body/" failed (13: Permission denied)→client_body_temp_path目录权限不对或磁盘满，和大小参数无关 - 含
upstream timed out或read timeout→ 是proxy_read_timeout或后端响应慢，Nginx 在读取请求体过程中卡住，不是拒绝上传
检查 client_max_body_size 的作用范围是否匹配
这个指令可放在 http、server 或 location 块，优先级从低到高：
- 全局生效：写在
http{}里，影响所有 server - 按域名控制：写在某个
server{}里，只对该站点有效 - 按路径精细控制：写在
location /upload { }里，仅对上传接口生效 - 注意：如果多个层级都设置了，以最内层（如 location）为准
别忽略 client_body_temp_path 的实际状态
即使 client_max_body_size 调得再大，临时目录不可写照样失败：
- 查当前配置的临时路径：
nginx -V 2>&1 | grep -o 'with-http' | head -1不够用，直接看 conf 中是否有client_body_temp_path；没配则默认是prefix/client_body_temp - 检查该目录是否存在、属主是否为 nginx 运行用户（如 www-data 或 nginx）、是否有写权限
- 用
df -h看对应磁盘剩余空间，尤其注意 tmpfs 类型挂载点是否已满
