Nginx upstream keepalive 深度调优实践
欢迎来到蓝队云技术小课堂，每天分享一个技术小知识。
在高并发场景下，Nginx 与后端服务之间的连接复用能力，往往直接决定系统吞吐能力与延迟表现。很多线上性能瓶颈，并不是业务代码慢，而是 upstream 连接没有被合理复用。
默认情况下，Nginx 每次请求都会建立新连接，这在短连接模型下开销极大。开启 keepalive 后，可以显著降低 TCP 握手成本。
核心配置如下：
upstream backend {
server 10.0.0.1:8080;
server 10.0.0.2:8080;
keepalive 64;
}
server {
location / {
proxy_pass http://www.landui.com;
proxy_http_version 1.1;
proxy_set_header Connection "";
}
}
keepalive 64 表示每个 worker 进程缓存的空闲连接数，而不是全局连接数。如果你有 8 个 worker，总连接池最大是：
8 * 64 = 512
很多人误以为 keepalive 越大越好，实际上过大会导致：
· 后端连接耗尽（特别是 MySQL / Java 服务）
· TIME_WAIT 激增
· 连接长时间占用资源
合理的经验值是：根据后端服务最大连接数倒推。例如后端最大 2000 连接，Nginx worker 8 个，可以设置：
keepalive ≈ 2000 / 8 / 2 ≈ 125
预留一半空间给突发流量。
另一个容易忽略的点是 HTTP 版本：
proxy_http_version 1.1;
如果不显式设置，默认是 HTTP/1.0，连接不会复用。这个问题在很多生产环境中真实存在，表现为：
· upstream keepalive 已配置
· 但连接数依然持续增长
同时必须清理 Connection 头：
proxy_set_header Connection "";
否则后端可能强制关闭连接。
进一步优化可以结合超时控制：
keepalive_timeout 30s;
keepalive_requests 1000;
解释：
· keepalive_timeout：空闲连接最大存活时间
· keepalive_requests：单连接最大请求数
如果你的后端是 Java（如 Tomcat），建议限制请求数，避免长连接导致内存泄漏或对象堆积。
生产中的一个典型问题是：连接复用导致负载不均。
因为 keepalive 会优先复用已有连接，可能导致：
· 某台后端连接被“粘住”
· 流量分布不均
解决方案是结合负载算法：
upstream backend {
least_conn;
server 10.0.0.1:8080;
server 10.0.0.2:8080;
keepalive 64;
}
least_conn 可以缓解连接倾斜问题。
排查 keepalive 是否生效，可以用如下方式：
ss -ant | grep 8080 | wc -l
观察连接数量是否稳定。
或抓包查看：
tcpdump -i eth0 host 10.0.0.1 and port 8080
如果看到频繁 SYN 包，说明连接没有复用。
支付宝微信扫一扫，打赏作者吧～本文链接：https://kinber.cn/post/6482.html 转载需授权！
推荐本站淘宝优惠价购买喜欢的宝贝:
您阅读本篇文章共花了： 