error_log本身不控制上传限制，但通过其warn级别日志可精准定位413根源：出现“client intended to send too large body”即需调client_max_body_size，而权限、超时或磁盘问题则对应不同错误线索。
error_log 本身不直接控制上传大小限制，但它对排查 client_max_body_size 相关问题至关重要——413 错误是否真由大小限制触发、还是被其他环节拦截，全靠它揭示真相。
看 error_log 才能确认是不是真卡在 client_max_body_size
当上传失败返回 413 时，不能默认就是 client_max_body_size 不够。error_log 里会明确记录原因：
- 出现
client intended to send too large body→ 确实是大小超限，该调client_max_body_size - 出现
open() "/var/lib/nginx/tmp/client_body/..." failed (13: Permission denied)→ 是client_body_temp_path权限或磁盘问题，和大小参数无关 - 出现
upstream timed out (110: Connection timed out)或read timeout→ 实际是proxy_read_timeout或后端响应慢，不是 Nginx 拒绝上传
必须把 error_log 级别设到 warn 或更低
默认 error_log 级别常为 error，而 413 相关提示（如 body size 超限）往往只在 warn 级别输出。不调低级别就看不到关键线索：
- 在
http或server块中加：error_log /var/log/nginx/error.log warn; - 避免用
info或debug（日志爆炸，影响性能），warn是平衡点 - 确保日志路径可写，且 Nginx 工作用户（如
www-data）有权限写入该文件
结合 location 级 error_log 定位具体接口
如果只在全局 error_log 查日志，大量请求混在一起难定位。可在上传路径的 location 块中单独设日志，缩小排查范围：
location /api/upload { error_log /var/log/nginx/upload_error.log warn; client_max_body_size 500m; ... }- 这样所有该路径的错误（包括权限、超时、大小拒绝）都集中在此文件，不干扰主日志
- 配合
tail -f /var/log/nginx/upload_error.log实时观察上传过程，一试便知哪步断了
别忽略 error_log 中的“隐性失败”线索
有些上传失败根本不会报 413，而是静默中断或返回 500，这时 error_log 更关键：
-
client_body_in_file_only on但临时目录满 → 报No space left on device -
client_body_buffer_size过小（如默认 8k），大文件反复刷盘失败 → 出现writev() failed或sendfile() failed - SSL 上传时证书或协议不匹配 → 可能提前断连，日志里只有
SSL_do_handshake() failed
