Nginx反向代理的后端连接按需建立且优先复用：在upstream阶段选peer后，由ngx_http_upstream_connect触发建连，先查keepalive池，失败才调用ngx_event_connect_peer异步发起TCP连接，全程事件驱动、非阻塞。

当 Nginx 作为反向代理运行时，ngx_http_proxy_module 负责将客户端请求转发到后端服务器。其后端连接的建立并非在收到请求头后立即发起，而是延迟到真正需要发送请求体或等待响应时才触发——核心在于“连接复用”与“按需建连”的设计思想。

后端连接的真正发起时机

连接不是在 ngx_http_proxy_handler 中直接建立的，而是在后续的写事件驱动阶段（如发送请求头/体）中，由 ngx_http_upstream_connect 统一调度。该函数会先尝试复用已存在的空闲连接（来自 upstream 的 keepalive 连接池），失败后才调用 ngx_event_connect_peer 发起新连接。

• 若配置了 proxy_http_version 1.1 和 proxy_set_header Connection ''，Nginx 更倾向复用连接
• 若后端拒绝复用（如返回 Connection: close），当前连接会在读完响应后主动关闭，并从连接池中移除
• 超时控制由 proxy_connect_timeout 决定，底层通过 ngx_event_connect_peer 设置 connect timer

upstream 与 peer 的初始化关键点

在 ngx_http_proxy_create_request 完成请求构造后，Nginx 进入 upstream 阶段：调用 ngx_http_upstream_init_request 初始化 upstream 上下文，并通过 ngx_http_upstream_get_peer 选择后端 peer（支持 round-robin、ip_hash 等算法）。此时只是逻辑选节点，尚未建连。

• peer 获取成功后，u->peer.connection 仍为 NULL，表示物理连接未建立
• ngx_http_upstream_connect 是第一个真正调用 socket 相关操作的函数，它内部调用 ngx_event_connect_peer
• ngx_event_connect_peer 封装了 connect() 系统调用，并根据返回值区分同步成功、同步失败、异步进行三种情况

异步连接的事件驱动处理

Linux 下绝大多数情况下 connect() 返回 EINPROGRESS，Nginx 将 socket 设为非阻塞，并注册写事件监听器 ngx_http_upstream_connect_peer_handler。当 socket 可写时（即 TCP 三次握手完成），该 handler 被触发，再调用 ngx_http_upstream_connect 继续后续流程（如发送请求头）。

• 连接成功后，u->peer.connection 被赋值，后续所有 I/O（send/recv）都基于此 connection
• 若连接失败（如超时、被拒），ngx_http_upstream_next 触发重试逻辑：标记当前 peer 不可用、尝试下一个 peer 或返回错误
• 整个过程不阻塞 worker 进程，符合 Nginx 的事件驱动模型本质

连接复用与健康检查的协同机制

连接复用依赖于 upstream 模块的 keepalive 功能（需显式开启 keepalive 指令）。空闲连接保存在 u->conf->keepalive_pool 中，由独立的 idle timer 管理。健康检查（如 health_check）则通过定时发起探测请求更新 peer 状态，两者共用同一套 peer 状态位（failed, down）。

• 复用前会校验连接是否活跃（ngx_http_upstream_check_broken_connection）、peer 是否 still alive
• 若复用连接发送失败（如 ECONNRESET），会立即关闭该连接并标记 peer failed，避免后续请求继续使用
• 健康检查成功可将 peer 状态从 down 恢复为 live，使其重新进入负载均衡候选集

理解这套流程的关键，在于把握 upstream 框架对连接生命周期的抽象：从 peer 选择 → 连接获取（复用 or 新建）→ 异步建连 → 请求转发 → 响应接收 → 连接归还/关闭，每个环节都由清晰的回调和状态机驱动，而非线性阻塞执行。