nginx keepalive 优化需客户端、nginx、后端三方协议与超时对齐：客户端侧按场景设 keepalive_timeout（cdn 10–30s、移动端 5–15s、web 30–65s），https 配 tls 复用；nginx 到后端须三件套齐备——proxy_http_version 1.1、proxy_set_header connection ""、upstream 内 keepalive n；并配 keepalive_timeout（小于后端空闲超时）和 keepalive_requests；验证需结合 ss、debug 日志及 curl 端口复用观察。
要让 Nginx 在 Linux 环境下真正通过 keepalive 优化代理连接复用，关键不是加一行参数，而是把客户端、Nginx、后端三段连接的协议行为、头部控制和超时策略全部对齐。否则容易出现“配置写了却没效果”或“复用失败反报 upstream timed out”的情况。
客户端到 Nginx 的 keepalive 要贴合真实访问节奏
这个环节决定浏览器或 App 是否愿意复用连接发后续请求：
- 静态资源多、加载快的站点（如 CDN 边缘节点）：keepalive_timeout 设为 10–30 秒较合适；设太长会积压空闲连接，浪费文件描述符
- 移动端 API 场景：5–15 秒更稳妥；App 切后台后常在 60 秒内主动断连，Nginx 设再高也无效
- 常规 Web 页面（含 HTML + JS/CSS 并行加载）：30–65 秒合理；首屏关键请求集中在前 20 秒内，留出余量即可
- HTTPS 必须配 TLS 会话复用：ssl_session_cache shared:SSL:10m; ssl_session_timeout 4h;，否则 TCP 复用但 TLS 握手仍重做，TTFB 改善有限
Nginx 到后端的 upstream keepalive 必须三件套齐备
这是降低后端建连压力的核心，漏掉任意一项都会导致 keepalive 形同虚设：
- proxy_http_version 1.1;：写在 location 块中；HTTP/1.0 默认不支持长连接，不设此项后端收到请求就断连
- proxy_set_header Connection "";：同样写在 location 中；清空客户端传来的 Connection: close，避免透传误导后端
- upstream 块内 keepalive 32;：只能出现在 http 块下的 upstream 块里；表示每个 worker 进程对单台后端最多缓存 32 个空闲连接
注意：keepalive 不能写在 server 或 location 内，否则 Nginx 启动报错 “unknown directive”。如果后端有 2 台、Nginx 有 4 个 worker，理论最大空闲连接数是 4 × 2 × 32 = 256 条。
超时与请求数必须分层匹配后端能力
只设连接池大小不够，还要防止连接“老而不死”或“用完即弃”：
- upstream 块中建议加 keepalive_timeout 20s;：必须比后端空闲超时小（如 Tomcat 的 connectionTimeout=30s），否则 Nginx 拿到已关闭的 socket 导致 502
- upstream 块中加 keepalive_requests 500;：默认 100 在高并发 API 下太激进；限制单连接请求数可防内存泄漏或状态堆积
- 不要混淆 client 和 upstream 的超时：keepalive_timeout（在 server/location 中）只管客户端连接，对 upstream 完全无影响
验证是否真生效，别只看配置有没有写
用实际现象判断比查文档更可靠：
- 在后端执行 ss -s | grep -i time_wait：复用率提升后，TIME_WAIT 数量应明显下降
- 在 Nginx 开启 debug 日志，搜索 keepalive.*reuse 或 create connection：看到 reuse 表示复用成功，频繁 create 则说明配置未生效
- 用 curl -v http://your-proxy/ 连续请求两次，配合 ss -t | grep :80 观察源端口是否复用：相同端口重复通信 = TCP 连接复用成功
