Nginx 中性能优化如何调整 keepalive_timeout 优化长连接复用减少握手开销

调 keepalive_timeout 是为匹配真实请求节奏以减少重复握手，需按业务类型设合理值（如静态资源10–30秒、移动端5–15秒、常规Web站点30–65秒），并协同 keepalive_requests、upstream 连接池及后端 keep-alive 配置，同时避开忽略客户端行为、未清空 Connection 头等常见误操作。

调 keepalive_timeout 不是为了“设个数”，而是让连接生命周期贴合真实请求节奏，从而减少重复握手。它本身不加速，但配对得当，能让浏览器或 App 复用一个 TCP 连接发多个请求，跳过三次握手和 TLS 协商，尤其在弱网、高延迟或小请求密集场景下效果明显。

按业务类型设合理值区间

不同流量特征需要不同空闲等待时长：

1. 静态资源站 / CDN 边缘节点：设为 10–30 秒。资源加载快、请求分散，过长反而积压连接
2. 移动端 API 接口：5–15 秒更稳妥。App 可能休眠或切后台，客户端主动断连早于 Nginx 超时，设太长无效
3. 常规 Web 站点（含 HTML/CSS/JS 并行加载）：推荐 30–65 秒。匹配主流浏览器默认行为（Chrome 约 300s，但首屏关键请求集中在前 10–20 秒）
4. 内网服务、SSE 或长轮询接口：可设至 60–300 秒，但需确保后端也维持对应 keep-alive 能力
5. 高并发网关或资源受限环境：≤5 秒，优先保文件描述符不耗尽

必须协同的三个关键配置

单改 keepalive_timeout 效果有限，以下三项缺一不可：

1. keepalive_requests 100：限制单连接最大请求数，默认值通常够用；若全是极小心跳包，可提高到 500–1000；若单次请求体大或耗时长，建议保持或略降，防连接长期被占
2. upstream 块中启用连接池：加 keepalive 32（数值建议为后端单实例并发能力的 1/4～1/2），并确保 proxy_http_version 1.1 和 proxy_set_header Connection "" 同时存在
3. 后端服务支持 keep-alive：如 Tomcat 需设 keepAliveTimeout="60000"、maxKeepAliveRequests="100"；Node.js 或 Go 服务也要显式开启 HTTP/1.1 keep-alive 且不主动关闭空闲连接

避开常见误操作

这些做法会直接抵消 keepalive_timeout 的作用：

1. 忽略客户端实际行为：比如设 300 秒，但 App SDK 默认 60 秒就断连，Nginx 等着没用
2. 未清空 Connection 头：proxy_set_header Connection "" 缺失会导致 Nginx 自动加 Connection: close，后端收不到 keep-alive 请求
3. HTTPS 下未配 TLS 会话复用：即使 TCP 复用了，TLS 握手仍可能重做。务必启用 ssl_session_cache shared:SSL:10m 和 ssl_session_timeout 4h
4. WebSocket 场景混用普通配置：需单独透传 Upgrade 和 Connection 头，并把 proxy_read_timeout 设为 86400 或更高，否则连接被误断

验证是否真正生效

不能只看配置写了没，要观察实际复用效果：

1. 用 netstat -an | grep :443 | grep ESTABLISHED | wc -l 查活跃连接数趋势，突增可能说明 timeout 过短或客户端异常
2. 检查 access log 中 $connection_requests 变量，看单连接平均处理请求数是否接近 keepalive_requests 设置值
3. 抓包观察浏览器发起的多个请求是否复用同一 TCP 流（源/目的 IP+端口不变）
4. 监控错误日志里 “client closed connection while sending response” 频次，过高说明客户端比 Nginx 更早断连，需下调 keepalive_timeout