keepalive_timeout设得太短会显著降低性能：客户端未发第二请求连接即被关闭，导致TCP/TLS频繁握手、TTFB升高、TIME_WAIT激增、端口耗尽，并使移动端复用率趋近于零。
keepalive_timeout 设得太短，会让 Nginx 在客户端还没来得及发第二个请求时，就把连接关掉了。表面看是“及时释放资源”，实际却引发一连串连锁反应，性能不升反降。
频繁重连拖慢响应速度
每次连接关闭后，客户端再发请求就得重新走 TCP 三次握手 + 四次挥手。在移动网络或跨地域场景下，延迟明显上升；HTTPS 还要叠加 TLS 握手（除非会话复用生效），首字节时间（TTFB）和 CPU 占用双双升高。浏览器加载一个页面要请求 JS、CSS、图片等十几二十个资源，若 timeout 只设 5 秒，很可能第一个请求刚结束，连接就断了，后续请求全变成新连接。
系统资源反而更紧张
- 内核 TIME_WAIT 状态激增，可能快速耗尽本地端口或 conntrack 表项
- worker 进程频繁创建销毁 socket，增加上下文切换开销
- 错误日志里出现大量 “client closed connection while waiting for request” 或 “connection reset by peer”
移动端和小程序特别吃亏
这类客户端常批量拉取数据后休眠几秒，比如加载完首页资源就暂停 2–3 秒。如果 keepalive_timeout 设为 10 秒以下，大量连接建立即闲置、闲置即关闭，复用率趋近于零。结果是并发数没涨，握手开销和日志写入量却翻倍。
后端压力间接加大
前端连接反复重建，意味着后端也要频繁处理新连接、初始化 SSL 上下文、分配线程/协程。尤其当 Nginx 作为反向代理时，上游连接池也因下游不稳定而频繁震荡，可能触发更多 502 错误或超时重试。
