Node.js中设置过大Keep-Alive参数会产生哪些副作用？

你之前遇到502错误的核心原因是Node服务的keepAliveTimeout短于上游反向代理（Nginx、云负载均衡等，通常默认65s）的长连接超时时间：服务端先断开连接时，上游刚好复用该连接转发请求就会收到RST包，触发502错误。你把配置从：

const app = express();
const server = app.listen(port);
server.keepAliveTimeout = 61 * 1000;
server.headersTimeout = 65 * 1000;

调整为：

const app = express();
const server = app.listen(port);
server.keepAliveTimeout = 120 * 1000;
server.headersTimeout = 125 * 1000;

后Node侧超时时间长于上游，问题自然解决，但调大KeepAlive超时确实会带来明确的副作用：

主要副作用 #

• 文件描述符耗尽风险：每个TCP连接都会占用一个文件描述符，Node.js单进程默认的文件描述符上限通常为1024或4096。如果后续QPS持续升高，大量空闲长连接会持续占用文件描述符，一旦占满就会拒绝新的连接请求，抛出EMFILE错误，直接导致服务不可用。
• 内存占用升高：内核和Node进程都会为每个活跃TCP连接维护状态数据、读写缓冲区，长连接持有时间越长，高并发场景下内存占用越高，严重时会触发系统OOM机制，直接杀掉Node进程。
• 慢速攻击防御能力下降：调长超时时间后，攻击者可以通过极低的速率占用长连接不释放，用很低的成本就能耗光你的服务连接资源，导致正常用户的请求无法进入，放大了慢速HTTP攻击的危害。
• 连接资源利用率下降：普通用户的单次访问会话通常不会超过几十秒，超过合理阈值后再拉长超时时间，持有的大部分都是无请求的空闲僵尸连接，反而会降低连接资源的有效利用率，不会带来额外的性能收益。

优化建议 #

• 不需要盲目设置过大的超时值，只要保证keepAliveTimeout比上游反向代理的长连接超时时间大3~5s即可，headersTimeout只要比keepAliveTimeout大5s左右就足够，多余的时长只会带来副作用没有收益。
• 提前调高Node进程的文件描述符上限，可以通过ulimit -n 65535临时调整，也可以修改系统配置永久生效，适配后续高并发的连接需求。
• 配置server.maxConnections参数限制服务的最大连接数，避免极端情况（比如攻击、流量突增）下资源被打满导致服务完全不可用。
• 后续QPS提升到一定量级后，建议采用Node多进程集群部署，分摊单进程的连接和请求压力。

内容的提问来源于stack exchange，提问作者JAN