Nginx作为反向代理使用时，客户端请求并不会直接抵达后端服务，而是由Nginx主动向后端发起连接取回数据，这个过程叫作回源。回源连接复用是指Nginx在代理多笔请求到同一后端时，不每次都新建TCP连接，而是保持已建立的连接反复使用，从而降低握手开销、提升吞吐。
要理解复用机制，得先明白Nginx的事件驱动模型。Worker进程借助epoll等机制同时管理大量连接，当启用upstream keepalive后，完成一次后端响应并不会立即关闭套接字，而是把连接放进空闲池。后续同后端的新请求优先从池中拿连接，跳过TCP与TLS握手。在高并发场景下，这种复用可让后端看到的连接数稳定在一个较小范围。
从运维视角看，日志是观察复用最直观的窗口。虽然默认日志格式不直接记录连接是否复用，但我们可以通过连接持续时间、后端地址重复度以及响应延迟分布侧面判断。例如同一客户端IP在毫秒级连续访问，后端IP相同且Nginx未出现大量TIME_WAIT，就说明复用正在发生。
回源连接复用在日志中的表现
在access日志里，若配置了 upstream_addr 与 upstream_response_time 等变量，就能看到后端地址被频繁复用。假设某接口每秒百次请求，但 upstream_addr 始终指向同一组服务器且响应时间极低，基本可确认连接池在生效。相反，若 upstream_connect_time 每次都接近TCP握手耗时，则复用可能未开启或池已满。
error日志则会在连接异常时给出线索。当空闲连接被后端单方面关闭，Nginx复用时会收到错误并重新建连，此时日志可能出现 recv() failed 或 connection reset 等记录。这类信息不代表系统故障，而是复用连接失效后的正常降级，但频繁出现就需检查后端超时设置。
常用日志字段对照
下面列出与复用判断相关的字段，帮助你在现有日志中做排查：
| 字段名 | 含义 | 复用相关说明 |
|---|---|---|
| upstream_addr | 实际后端地址 | 连续请求值相同暗示复用 |
| upstream_connect_time | 建连耗时 | 接近0或缺失说明取自连接池 |
| upstream_response_time | 后端响应耗时 | 稳定偏低受复用减少握手影响 |
如何提升回源连接复用率
核心配置是 upstream 块中的 keepalive 指令，它定义每个worker保留的空闲连接数。设置过小，并发一来池就满，新请求被迫新建连接；设置过大，又会占用后端文件描述符。一般线上可根据后端承载量与请求密度调整为32到128之间。
另外，代理配置需使用 http1.1 并清除 Connection 头部，否则后端按短连接处理。示例如下：代理到后端时写明 proxy_http_version 1.1 与 proxy_set_header Connection 空值，才能配合 keepalive 实现长连接复用。若后端是HTTPS，还要考虑SSL会话复用减少TLS开销。
经验上，观察后端 netstat 的 ESTABLISHED 数量是否远低于Nginx请求速率，是验证复用最朴素的办法。
常见误区与排查思路
有人看到Nginx日志里后端连接少就怀疑代理没正常工作，其实恰恰相反，那是复用健康的表现。真正要警惕的是空闲连接被后端超时断开导致的复用失效，此时应比对后端 keepalive_timeout 与Nginx空闲连接存活时间。
还有一类问题是多后端负载不均。当 keepalive 池按worker隔离，某些worker恰巧绑定特定后端，日志会显示部分后端连接集中。这属于连接亲和现象，可通过一致性哈希或增大池子缓解，不必急于改动整体架构。