nginx平滑重载时后端长连接真正保持需验证三方面：连接池复用（$upstream_connect_time≈0、established数平稳）、worker进程共存与优雅退出（ps查看新旧worker并存、无rst日志）、端到端连通性（tcpdump无reload后突增fin、客户端无502/504）。
验证 Nginx 平滑重载期间后端长连接是否真正保持，不能只看服务是否“没报错”，而要确认旧连接是否仍在复用、未被强制中断、数据持续通达。关键在观测连接生命周期、连接池行为和日志痕迹三方面。
观察 upstream 连接池复用状态
Nginx 的后端长连接由 upstream keepalive N 控制，重载时旧 worker 会继续使用已有空闲连接。可通过以下方式确认：
- 启用
log_format记录 upstream 连接复用字段：添加$upstream_addr、$upstream_bytes_received、$upstream_connect_time等变量到 access_log，重载前后对比同一客户端 IP 的请求是否始终落在相同后端地址且connect_time接近 0（说明复用了已有连接） - 检查 Nginx 状态页（需编译含
ngx_http_stub_status_module）：访问/nginx_status，关注Active connections和Reading/Writing/Waiting数值——重载过程中该总数应基本平稳，无断崖式下跌 - 用
ss -tnp | grep :<port></port>或lsof -i :<port></port>在重载前后分别查看 Nginx worker 进程持有的 ESTABLISHED 连接数，若旧连接未突降、新连接逐步增长，说明复用正常
检查 worker 进程的存活与连接处理行为
平滑重载的核心是“旧 worker 不立即退出”。验证点包括：
- 执行
nginx -s reload后，运行ps aux | grep nginx，应同时看到旧 worker（PPID 是原 master）和新 worker（PPID 是新 master）共存；等待数秒后旧 worker 逐渐消失，而非瞬间清零 - 确认
worker_shutdown_timeout已设为合理值（如 60s），且大于proxy_read_timeout；否则旧 worker 可能在连接未结束前就被强制 kill，导致 RST 包发出 - 查看 error.log 中是否有
upstream prematurely closed connection或client closed connection等异常关闭记录——大量出现说明连接被非自然中断
模拟真实长连接场景做端到端验证
仅靠命令行或日志不够直观，建议构造可控测试：
- 启动一个持续发送 HTTP/1.1 请求并保持 Keep-Alive 的脚本（如用 curl 加
--keepalive-time 60），或建立 WebSocket 连接；在连接活跃时执行 reload，观察客户端是否收到连接重置、响应延迟突增或 502/504 - 对后端服务开启访问日志，记录每个请求的 socket fd 或连接 ID；reload 前后比对同一客户端的请求是否始终由同一个后端进程处理（说明连接未重建）
- 用 tcpdump 抓包过滤 Nginx 到后端的流量，搜索 FIN/RST 包出现时机——若 reload 后立刻出现大量 FIN，说明旧连接被主动关闭；理想情况是 FIN 出现在连接自然空闲超时之后
注意几个易被忽略的失效点
即使 reload 成功，以下配置错误也会导致长连接“看似平滑、实则断裂”：
-
upstream块中漏写keepalive 32，或 location 中未设proxy_http_version 1.1和proxy_set_header Connection ""，Nginx 会退化为 HTTP/1.0 每次新建连接 - 后端服务自身设置了较短的
keepAliveTimeout（如 Tomcat 默认 20s），早于 Nginx 的proxy_read_timeout，导致后端先断连，Nginx 被迫重建 - 配置中误加
proxy_buffering off配合大响应体，可能触发内核缓冲区耗尽，间接导致连接异常关闭
