keepalive_timeout不能无限延长，因其本质是空闲连接释放倒计时而非保活机制；无限延长会导致fd资源耗尽、与后端连接错配、客户端不兼容引发僵尸连接，合理值需匹配后端超时并预留余量。
Nginx 中 keepalive_timeout 不能无限延长，根本原因在于它不是“保活”机制，而是空闲连接的释放倒计时——它控制的是连接在无任何数据交互时能“安静待命”的最长时间，而非持续维持活跃状态的手段。
无限延长会直接触发资源瓶颈和连接异常，具体体现在三方面：
连接资源被无效占用
每个 keepalive 连接都要占用一个文件描述符（fd）、内存缓冲区和内核 socket 结构。Linux 系统默认单进程 fd 上限通常为 1024 或 65535，若 keepalive_timeout 3600s（1 小时），而并发连接峰值达 5000，其中 3000 个处于空闲状态，这些连接将持续占满 fd 池一小时。新请求因无法获取 fd 而被拒绝，返回 503 Service Unavailable 或直接超时。
与后端服务形成“连接错配”
Nginx 不主动探测上游是否存活。若 keepalive_timeout 设为 300s，而后端（如 Spring Boot）connectionTimeout=60s，Nginx 会在连接空闲 60 秒后被后端静默断开，但自身仍认为该连接有效，继续往里发请求 → 触发 Connection refused 或 upstream prematurely closed connection 错误。连接池中“僵尸连接”越积越多，可用连接数线性衰减，最终枯竭。
客户端行为不可控，反而加剧问题
浏览器、移动端 SDK 等客户端对 Keep-Alive: timeout=xxx 响应头的实际遵循程度不一：Chrome 通常只维持 5–10 分钟，iOS WebView 可能仅 30 秒。你设 keepalive_timeout 86400，客户端早已关闭连接，Nginx 却还在等满一天 —— 此时连接状态变为 CLOSE_WAIT 或 TIME_WAIT，既不释放也不复用，纯粹浪费。
真正需要的不是“更长”，而是“匹配+可控”
- 对 API 网关类场景：设
keepalive_timeout 20s+keepalive_requests 1000，双保险快速释放 - 对长轮询或 SSE：需配合
proxy_read_timeout和后端心跳，而非靠keepalive_timeout硬扛 - 所有设置必须 ≤ 后端
keepAliveTimeout − 10s，留出网络抖动余量
本质上，keepalive_timeout 是一个资源回收策略，不是连接永生开关。它的合理值由后端承载力、客户端行为、系统 fd 限制共同决定，而非越长越好。
