413或502错误本质是nginx与后端（如php-fpm）在请求体大小、缓冲、超时及请求头限制上未协同放开所致；需在location块显式设client_max_body_size、修复temp目录权限、同步调大php参数及超时值，并检查large_client_header_buffers。
FastCGI 场景下出现“请求体过大”导致的 413 或 502 错误，本质是 Nginx 在接收、缓存、转发 PHP 等后端请求时，对客户端提交的 request body（如大 JSON、表单数据、文件上传）限制未协同放开。这不是单一参数问题，而是接收链路上多个环节卡点叠加的结果。
关键卡点：client_max_body_size 必须显式生效
这个指令控制 Nginx 允许接收的最大请求体大小，默认仅 1MB，且不自动继承父级配置。常见误区是只在 http 块设了 100m，但实际请求匹配的是 location ~ \.php$，而该块没重写该值，Nginx 就按默认 1M 处理，直接返回 413。
- 务必在具体 PHP 处理 location 块中设置，例如：
location ~ \.php$ {
client_max_body_size 100m;
fastcgi_pass php-fpm;
# 其他 fastcgi_* 参数...
} - 单位必须小写（如 100m），写成 100M 会报配置错误
- 设为 0 表示禁用检查，生产环境不建议
缓冲与临时文件权限必须到位
当请求体超过 client_body_buffer_size（默认通常 8k–16k），Nginx 会把多余部分写入磁盘临时文件。若 client_body_temp_path 目录无写权限或属主错误，就会静默失败，日志报 Permission denied，后端收不到完整 body，可能返回 500 或空 request_body。
- 查 Nginx worker 进程用户：ps aux | grep nginx | grep worker（常见为 nginx 或 www-data）
- 查 temp 路径：nginx -T 2>&1 | grep client_body_temp_path，未显式配置则用默认路径（如 /var/lib/nginx/client_body_temp）
- 修复权限：sudo chown nginx:nginx /var/lib/nginx/client_body_temp && sudo chmod 750 /var/lib/nginx/client_body_temp
- 同步检查 proxy_temp_path、fastcgi_temp_path 权限是否一致
后端与超时参数必须同步放宽
Nginx 放行 ≠ 后端能收。即使 Nginx 接收了 100MB 请求，PHP-FPM 或应用框架若仍卡在默认限制（如 PHP 的 post_max_size=8M、upload_max_filesize=2M），就会在解析阶段拒绝或超时，Nginx 最终返回 502 或 504。
- PHP 需同步调整 php.ini：
post_max_size = 80m
upload_max_filesize = 80m
max_execution_time = 300 - 超时要延长：大 body 传输耗时长，需调大 client_body_timeout（读 body）、fastcgi_read_timeout（等 PHP 响应）和 fastcgi_send_timeout（向客户端发响应）
- 建议值参考：client_body_timeout 120s; fastcgi_read_timeout 300s; fastcgi_send_timeout 120s;
别忽略请求头过大引发的连带问题
大量自定义 Header、长 JWT、嵌套代理头（如 X-Forwarded-For 多层追加）可能导致整个请求头总长超标。Nginx 在解析阶段就断连，不进 location，也不触发 client_max_body_size 检查，表现为 400 或静默失败，error.log 可能只有 “client sent too large header” 类提示。
- 检查是否命中头限制：curl -I -v https://your-site.com/api 观察请求头长度
- 必要时增大 large_client_header_buffers，例如：large_client_header_buffers 4 64k;
- 清理冗余 Header，避免在反向代理链中无节制添加
