最有效手段是在Nginx server块或http块中显式配置client_max_body_size做硬拦截，请求头解析后立即判定413，不占后端资源；location块内设置无效，未配置则沿用默认1MB；需结合timeout参数防慢速攻击，并通过curl测试、后端日志和nginx -T验证生效。
直接在 Nginx 入口层用 client_max_body_size 做硬拦截，是防止超限请求抵达后端网关的最有效手段——它在请求头解析完成后、开始读取请求体前就判定并返回 413，不占后端连接、不写临时文件、不触发代理转发。
明确拦截位置：必须落在请求进入的第一道配置块
Nginx 对请求体的校验发生在接收阶段早期，生效配置必须位于 server 块或 http 块，不能依赖 location 块兜底。原因在于：若 client_max_body_size 未在 server 级显式声明，Nginx 将使用默认 1MB 值；而 location 块中的设置仅在请求已通过 server 层准入后才参与后续处理，此时超限请求早已被拒，location 设置根本不会执行。
- ✅ 推荐写法（作用于整个虚拟主机）：
server {<br> listen 80;<br> server_name upload.example.com;<br> client_max_body_size 200m;<br> location / { proxy_pass http://backend; }<br>} - ⚠️ 不推荐写法（仅 location 里设）：
该配置对 413 拦截无效，因为请求尚未进入 location 就已被拒绝 - ❌ 错误写法（完全没设）：
沿用默认 1MB，所有 >1MB 的上传请求均在入口被 413 中断，但业务方常误以为是后端问题
设定合理阈值：兼顾防护与业务真实需求
数值不是越大越好，核心原则是略大于业务最大单次上传规格，既防恶意大载荷，又避免为小请求预留过大缓冲空间。
- 普通文档/图片系统：设为 50m～100m 已足够
- 视频或工程包上传：可设 200m～1g，需同步确认磁盘临时路径空间充足
- 严禁设为 0（不限制）：会失去第一道防护能力，攻击者可构造超大 payload 挤占 worker 进程内存或耗尽临时目录 inode
配套收紧时间窗口：堵住慢速分段攻击漏洞
仅限制大小不够——攻击者可能以极低速率分段发送超大 body，绕过 size 检查却长期占用连接和缓冲资源。必须联动 timeout 参数：
- client_body_timeout 12s：从收到请求头后开始计时，body 数据中断超过该值即断连
- client_header_timeout 60s：防止攻击者缓慢发送请求头耗尽连接池
- send_timeout 30s：控制向客户端发送响应的最长等待时间，防响应拖挂
验证是否真正生效：别只看 reload 成功
配置重载后，需交叉验证三处关键点：
- 用 curl 发送略超限请求（如设了 200m，则发 201m 文件），观察是否立即返回 413 且响应头含
Server: nginx - 检查后端服务日志——若完全无该请求记录，说明确由 Nginx 拦截
- 执行
nginx -T | grep client_max_body_size，确认实际生效值来自 server 块而非被覆盖的默认值
