keepalive_timeout 决定 nginx 主动关闭空闲前端连接的时间点，合理设为10–45秒可加速 fd 关闭、内存归还和 epoll 监听移除，降低 worker 资源占用；需配合 keepalive_requests 和 events 配置，并通过 curl、ss 等命令验证生效。
keepalive_timeout 本身不直接控制事件循环或释放内存句柄，它只决定 Nginx 主动关闭空闲前端连接的时间点。真正影响内存与文件描述符（fd）占用、进而关系到事件循环效率的，是连接是否及时断开——而 keepalive_timeout 正是这个“及时性”的关键开关。
理解 keepalive_timeout 对资源释放的实际作用
每个活跃的 HTTP 长连接会持续占用一个 worker 进程的文件描述符、内存缓冲区和事件循环中的监听状态。如果设为 300 秒（5 分钟），一个用户浏览完页面后，连接可能空等整整 5 分钟才被回收；1000 个并发用户就意味约 1000 个 fd 和对应内核结构体长期驻留。这不是“内存泄漏”，但确实是可避免的资源滞留。
合理调低该值（如 15–30 秒），能让连接在真实业务空闲后快速退出事件循环，触发 fd 关闭、内存归还、epoll 监听移除，从而减轻 worker 的调度压力和内存 footprint。
推荐取值与场景匹配
- 普通 Web 页面（含静态资源）：设为 20 秒。足够覆盖用户点击、滚动、预加载行为，又比默认 65 秒更早释放资源
- API 网关或 App 后端：设为 10 秒。移动端请求节奏快，空闲期短，长连接复用窗口窄，过长 timeout 反而积压无效连接
- 高负载管理后台（低频操作）：可放宽至 45 秒，但需同步检查 client_header_timeout ≤ 45，防止慢请求被误判为空闲
必须配合的两项配置
单设 keepalive_timeout 不足以保障高效释放：
- keepalive_requests：即使连接未超时，也应限制单连接处理请求数。设为 100（默认值）可防异常客户端长期霸占 fd；高并发静态服务可提至 500，但不宜无上限
-
worker_connections 与 events.use：确保 nginx.conf 中
events { use epoll; worker_connections 4096; }已启用高效 I/O 多路复用，否则大量空闲连接会拖慢事件轮询效率
验证是否真正生效
别只看配置文件——确认连接确实在预期时间关闭：
- 用
curl -v http://your.site/查看响应头是否有Keep-Alive: timeout=20 - 用
ss -tn state established '( dport = :80 )' | wc -l在空闲期后观察连接数是否回落 - 配合
nginx -T | grep keepalive检查实际加载的配置层级，避免被 server 或 location 块中的同名指令覆盖
