在Nginx入口层用client_max_body_size做硬拦截最有效，但需确保配置在匹配的location块、设定合理阈值、同步调优配套参数，并通过curl测试、后端日志和nginx-T命令交叉验证是否生效。
直接在 Nginx 入口层用 client_max_body_size 做硬拦截，是最有效的防超限手段——它在请求头解析完成后、开始读取请求体前就判定并返回 413，不占后端连接、不写临时文件、不触发代理转发。但“设了值”不等于“真生效”，关键在位置、阈值、配套和验证四个环节。
必须写在最匹配的 location 块里
该指令支持 http / server / location 三级作用域，但实际生效的是**最内层且命中请求路径的配置**。很多故障源于只在 http 或 server 块设了值，而上传接口（如 /api/upload）落在独立的 location 块中，且该块未显式覆盖，结果仍沿用默认 1MB。
- ✅ 推荐：在具体上传路径的 location 中设置，例如：
location /api/upload {<br> client_max_body_size 500m;<br> proxy_pass http://backend;<br>} - ⚠️ 慎用：在 server 块统一设大值，会放宽所有 POST 请求（含登录、表单），扩大攻击面
- ❌ 无效：仅在 http 块设值，但 location 块未继承或被覆盖，实际不生效
设定合理阈值，兼顾防护与业务
数值不是越大越好，核心是略大于业务最大单次上传规格，既防恶意载荷，又避免为小请求预留过大缓冲空间。
- 普通文档/图片上传：20m～50m 足够
- 视频或工程包上传：可设 200m～1g，需同步确认
client_body_temp_path磁盘空间充足 - 严禁设为 0：等于主动关闭第一道防护，攻击者可构造超大 payload 挤占 worker 内存或耗尽临时目录 inode
- 单位要写对：支持
k、m、g（大小写不敏感），如500m、2G；500MB或500Mb易因拼写疏忽失效
配套参数必须同步调优
client_max_body_size 只管“让不让进”，真正影响上传稳定性的还有三项：
-
client_body_buffer_size：建议 512k～1m。太小（如默认 8k）会频繁刷盘拖慢速度；太大浪费内存 -
client_body_temp_path：确认路径（如/var/tmp/nginx）磁盘空间充足，且 Nginx 运行用户（如www-data）有读写权限，否则报 500 而非 413 -
proxy_read_timeout和proxy_send_timeout：建议设为 3600（1 小时），防止 Nginx 在接收或转发过程中超时断连
这些参数需和 client_max_body_size 写在同一作用域（如同在 /api/upload 的 location 块内），否则无法协同生效。
验证是否真正生效
配置重载后，不能只看 nginx -s reload 成功，需交叉验证三处：
- 用
curl -F "file=@large.zip" http://host/api/upload发送略超限请求，观察是否返回 413 - 检查后端日志——如果完全没记录这次请求，基本可断定是 Nginx 拦截
- 运行
nginx -T | grep client_max_body_size，查所有已加载配置中该指令的实际值和所在位置
