client_max_body_size遵循“就近生效、内层覆盖外层”规则：http块设10m为兜底，server块设200m则覆盖全局并作用于该虚拟主机所有请求，location块设1g仅对该路径生效，其余路径仍用server级200m。
client_max_body_size 在 Nginx 中遵循“就近生效、内层覆盖外层”的继承规则。全局（http 块）设置只是兜底值，真正起作用的是最匹配当前请求的配置层级。
当你在 server 块中显式写入 client_max_body_size，它就会完全覆盖 http 块里的同名设置——对这个虚拟主机下的所有请求生效，无论是否进入某个 location，只要没被更内层（如 location）再次覆盖。
覆盖逻辑很直接
不是叠加或累加，而是替换：
- `http { client_max_body_size 10M; }` → 所有未被覆盖的 server 都默认用 10M
- `server { client_max_body_size 200M; }` → 这个域名下所有上传请求上限变成 200M，不再看 http 块的 10M
- `location /api/upload { client_max_body_size 1G; }` → 只有访问该路径时才升到 1G，其余路径仍按 server 块的 200M 走
为什么必须靠 server 块覆盖？
因为 `http` 块是全局作用域，无法区分不同业务场景：
- 一个博客站可能只需 10M 上传限制
- 一个视频后台却要支持 2G 文件
- 共用一台服务器时，只靠 http 级配置会“一刀切”，要么太严卡住业务，要么太松带来风险
常见误操作：以为写了就生效
实际配置中容易踩坑：
- 只在 `http` 块设了值，但 `server` 或 `location` 里有正则匹配（如 `location ~ \.php$`）且没重写该指令 → 可能继承了更小的隐式值或默认 1M
- 多个 `server` 块监听同一端口但 `server_name` 不匹配，导致请求落到默认 server → 此时生效的是那个默认 server 的设置，未必是你想改的那个
- 修改后没重载 Nginx（nginx -s reload），配置仍不生效
验证是否覆盖成功
最可靠的方式是结合日志和实测：
- 上传一个略超旧限制（如 15M）、略低于新限制（如 150M）的文件，看是否返回 413
- 检查 error 日志，出现 "client intended to send too large body" 就说明限制仍在起作用，且数值是你刚配的
- 用 curl -X POST --data-binary @largefile.zip 模拟上传，比浏览器更干净、无缓存干扰
