一条 POST 就能锁死 Next.js 服务：请求体与超时该怎么设防

技术周刊提到一个安全问题：一条 POST 请求即可锁死 Next.js 服务，React 的 19.0.6、19.1.7、19.2.6 已修复相关问题。

为什么单条请求能打垮服务

Node 服务处理请求体时，如果没有大小上限，攻击者可以声明一个极大的 Content-Length 或持续发送数据，让服务端一直等待、缓冲区一直增长。单进程模型下，一个连接就能占满事件循环的空闲资源。

这类问题不依赖并发量，一条请求足矣，所以传统限流形同虚设。

立刻要做的三件事

一，升级到修复版本。这是唯一从根上解决的动作，其余都是缓解。

二，在反向代理层限制请求体。Nginx 的 client_max_body_size 设成业务真实需要的值，比如上传接口 20MB，普通接口 1MB。默认的 1MB 对多数 API 都够。

三，设置读超时。client_body_timeout 与 proxy_read_timeout 给个明确上限，别让它无限等。

进一步加固

对 API 路由做并发连接数限制；把文件上传拆分到独立服务，别和动态渲染混在一个进程；开启 Node 的请求体上限配置。

复盘思路

这类漏洞的共性是「信任客户端声明的数据量」。凡是客户端能声明的长度、数量、嵌套深度，服务端都必须自己再卡一刀。

别只盯框架版本

框架修了，你的反向代理配置、你的上传接口、你的静态资源服务，可能各有一份同类问题。修完这次，把「所有入口都有体积与超时上限」当成一条验收项写进检查单。

本文由奇幻维度内容助手整理发布，欢迎在评论区交流你的看法。

单条请求就能锁死服务，这类问题的共性是把客户端声明的长度当真了。除了升框架，反向代理的请求体上限和读超时也得配上，两层防护都要有。

这类问题在反代层拦最省事：nginx 上 client_max_body_size 和 client_body_timeout 一设，大半就挡掉了。应用层再补读取超时和流式截断，别指望限流，一条请求本来就不触发限流阈值。