Nginx 的 client_max_body_size 设置了不生效怎么办？

排查清单：①指令位置——http/server/location 三层中更具体的层级会覆盖外层**，确认你的设置真正作用于出问题的 location；②改完必须 nginx -t && systemctl reload nginx；③上传还经过别的代理（CDN、云负载均衡、网关）的话，那一层也有自己的体积限制；④报 413 未必是 Nginx——PHP 的 upload_max_filesize/post_max_size、应用框架的 body 限制可能更小。**

第一层：指令放对位置

http {
    client_max_body_size 10m;      # 全局默认

    server {
        listen 80;
        client_max_body_size 20m;  # 覆盖全局

        location /upload {
            client_max_body_size 100m;   # 最具体，赢
        }
    }
}

规则：内层覆盖外层。你在 http 设了 100m 但 server 里有条 1m 的旧配置，上传还是被卡——用 grep -r client_max_body_size /etc/nginx/ 找出所有出现点。

第二层：确认已生效

sudo nginx -t                    # 语法检查
sudo systemctl reload nginx      # 应用配置

reload 后才生效；改了配置文件没 reload 是最常见的"不生效"。

第三层：看清 413 是谁发的

浏览器开发者工具看响应头：

• Server: nginx 且响应体是 Nginx 默认错误页 → Nginx 的限制
• 响应头带 CDN/网关标识（cloudflare、awselb…） → 上游链路某层的限制
• 应用自定义 JSON 错误（如 "file too large"）→ 应用/框架层限制

CDN/云 LB 场景要把这些层级的限制一并调大（如 Cloudflare 免费版限制 100MB）。

第四层：应用层限制同步调

PHP 经典三连：

upload_max_filesize = 100M
post_max_size = 100M
memory_limit = 256M

Node/Express：app.use(express.json({ limit: '100mb' }))；其他框架类似。任何一环比 Nginx 小，就还会失败。

观测云对照

413 错误也要被看见。 Nginx 访问日志经 DataKit 采集、Pipeline 解析状态码后，413 的出现频率可直接查询告警；上传功能异常不再只靠用户反馈。

常见问题（FAQ）

Q：默认值是多少？
A：1MB——这就是为什么表单传个稍大的附件就 413。

Q：设成 0 是什么意思？
A：不限制请求体大小。慎用，暴露给公网上传等于放弃一道防线。

Q：超大文件上传的正确姿势？
A：分片上传/断点续传（前端切片 + 后端合并），比硬扛单个大请求稳得多；对象存储场景用直传（预签名 URL）绕开 Web 服务。