linux 中 nginx 平滑重载时，stream 模块的 tcp 连接通过“优雅关闭”机制切流：主进程接收 hup 信号后启动新工作进程并逐步停止旧进程，旧进程在收到退出指令后不再接受新连接，但会等待已建立的连接处理完毕或超时后才关闭 socket，从而实现无中断切换。
Nginx Stream 模块如何处理 TCP 连接的优雅关闭
当执行 nginx -s reload 时，Nginx 的主进程（Master）不会立即终止，而是先 fork 出新的工作进程（Worker），待新进程就绪后，再向旧工作进程发送退出信号。对于 Stream 模块，其核心逻辑在于旧工作进程在关闭监听套接字（Listen Socket）之前，会遍历所有已接受的连接，并尝试让它们在关闭前完成数据收发。如果连接处于空闲状态，它会直接关闭；如果连接正在传输数据，它会等待一个短暂的宽限期（Grace Period），确保客户端能感知到连接断开或完成当前事务。
events {
worker_connections 1024;
}
stream {
upstream backend {
server 192.168.1.10:8080;
server 192.168.1.11:8080;
}
server {
listen 9090;
proxy_pass backend;
# 关键配置：设置优雅关闭的超时时间
# 默认情况下，Nginx 会等待连接完成，但可以通过以下参数微调
# proxy_timeout 控制单个连接的超时
proxy_timeout 1m;
}
}
上述配置展示了 Stream 模块的基本结构。在实际的重载过程中，关键在于 proxy_timeout 和 Nginx 内部的关闭逻辑。当旧 Worker 进程准备退出时，它会停止接受新的 TCP 握手请求，但对于已经建立的连接，它会继续处理直到 proxy_timeout 到期或连接自然结束。这意味着，如果在重载瞬间有大量的长连接存在，旧进程可能会持有这些连接几秒钟，直到它们被清理。这种机制确保了正在进行的数据库查询、文件传输等 TCP 会话不会因为服务器重启而突然中断，除非连接本身超时或被客户端主动断开。
如何验证 Stream 模块 TCP 连接在重载时的行为
为了验证这一过程，我们可以使用 netstat 或 ss 命令观察连接状态的变化，并结合 nginx -s reload 触发重载。在重载前后，观察 ESTABLISHED 状态的连接数量变化以及 TIME_WAIT 状态的产生情况，可以直观地看到连接是如何从旧进程迁移或关闭的。
# 模拟一个长连接保持打开状态 while true; do echo "test" | nc -q 0 localhost 9090; sleep 5; done & # 在另一个终端观察连接状态 watch -n 1 'ss -tnp | grep nginx' # 执行重载 nginx -s reload # 观察输出：旧进程的 PID 会逐渐减少，新进程的 PID 会增加 # 已建立的连接会经历 CLOSE_WAIT -> FIN_WAIT -> TIME_WAIT 状态 # 最终所有连接都会被关闭
运行上述脚本后，你可以看到在 nginx -s reload 执行后，旧的 Nginx Worker 进程并不会立即消失，而是会继续处理现有的连接。通过 ss -tnp 的输出，你会发现连接的状态从 ESTABLISHED 逐渐转变为 CLOSE_WAIT，这表示本地应用层已经关闭了连接，但远端还在发送数据或等待确认。随后，连接进入 FIN_WAIT 和 TIME_WAIT 状态，最终完全释放。这个过程证明了 Nginx Stream 模块确实实现了 TCP 连接的平滑过渡，避免了因服务重启导致的连接重置（RST）包发送给客户端，从而保证了业务的连续性。
基于 proxy_timeout 参数对重载期间长连接的影响
在 Stream 模块中，proxy_timeout 参数不仅影响正常运行的连接超时，还直接影响重载期间的连接保留时间。如果设置为较短的时间，如 1s，那么在重载时，旧进程会在 1 秒后强制关闭那些尚未完成数据传输的连接，这可能导致部分数据丢失或客户端报错。相反，如果设置为较长的时间，如 10m，则旧进程会等待更久，确保所有活跃连接都能安全关闭，但这也会延长重载的整体耗时，因为主进程需要等待所有旧 Worker 进程完全退出后才能完成整个重载流程。
