优化CDN回源Nginx Keepalive需配置upstream keepalive值（建议32–256），配合proxy_http_version 1.1和Connection头清空，确保源站返回Keep-Alive响应头并合理设置超时与keepalive_requests，再通过日志和监控验证复用效果。
要优化 CDN 回源时 Nginx 的 Keepalive 预连接数量，核心是合理配置 upstream 块中的 keepalive 指令，并配合连接复用策略与超时控制，避免连接池过小导致频繁建连，或过大造成后端资源占用。
设置 upstream 的 keepalive 连接池大小
Nginx 本身不主动“预创建”连接，但通过 keepalive N（N 为整数）可声明每个 worker 进程对上游服务器最多缓存的空闲长连接数。该值并非总连接数，而是每个 upstream server 实例（含 IP+端口）独立维护的连接池上限。
- 若回源地址是单个域名（如
origin.example.com），且 DNS 解析为多个 IP，需为每个解析出的 IP 单独分配池子 - 典型值建议从
32起调，高并发场景可设为128或256；超过512需谨慎，易引发上游端口耗尽或 TIME_WAIT 累积 - 必须搭配
proxy_http_version 1.1和proxy_set_header Connection ''使用，否则 HTTP/1.0 请求无法复用连接
确保上游服务支持并正确响应 Keepalive
Nginx 的 keepalive 是被动复用机制：只有上游明确返回 Connection: keep-alive 且未带 Content-Length 冲突或分块编码异常时，连接才进入空闲池。常见问题包括：
- 源站 Web 服务器（如 Apache、Tomcat）默认关闭 Keepalive，或设置了过短的
Keep-Alive: timeout=5 - 源站中间件（如某些 WAF、负载均衡器）主动关闭连接，或转发时误删
Connection头 - 源站返回
Transfer-Encoding: chunked但未正确结束流，导致 Nginx 认为连接不可复用
建议在源站侧检查响应头，确保稳定返回 Connection: keep-alive，并设置合理超时（如 timeout=15）。
调整 keepalive 超时与请求限制
keepalive 指令仅定义池大小，真正决定连接是否被回收的是两个隐含超时：
-
proxy_next_upstream_tries和proxy_next_upstream_timeout不影响 keepalive 复用，但影响失败重试逻辑 - 空闲连接在池中存活时间由上游的
Keep-Alive: timeout=XX响应头决定；若上游未返回该头，Nginx 默认按 75 秒清理（1.19.10+ 可通过keepalive_timeout显式配置） - 单个连接上最大请求数由
keepalive_requests控制（默认 100），建议根据业务平均响应体大小适当调高（如 1000），避免因请求计数满而提前断连
验证与监控关键指标
仅靠配置不能保证效果，需结合日志与指标确认实际复用率：
- 开启 Nginx 的
upstream_addr和upstream_cache_status日志变量，观察是否出现keepalive标识（如10.0.1.10:80, 10.0.1.10:80:keepalive） - 监控
nginx_upstream_keepalive（Prometheus + nginx-module-vts）或stub_status中的Active connections与Reading/Writing/Waiting分布 - 对比开启前后 TCP 连接新建速率（
netstat -ant | grep :80 | wc -l或ss -s），下降明显说明复用生效
