Nginx平滑重载可保持长连接不断、新连接由新worker接管、无reset或超时：通过curl长连接+reload验证连接完整性，ss/netstat确认连接绑定原worker，access_log中$pid验证请求路由连续性，wrk压测确保高并发下零错误与稳定延迟。
测试 Nginx 平滑重载对长连接的影响，核心是验证“已有连接不中断、新连接由新 worker 接管、无 reset 或超时”。这不是看配置有没有写 keepalive，而是用真实流量跑通整个切换过程。
用 curl 模拟持续长连接并触发 reload
这是最轻量、最直接的验证方式：
- 在终端 A 执行：curl -v --http1.1 -H "Connection: keep-alive" http://your-domain.com/sleep-30（后端需返回 30 秒延迟响应，如 Flask 的
time.sleep(30)） - 在终端 B 立即执行：sudo nginx -s reload
- 观察终端 A：若返回完整 HTTP 200 + 正确内容，且耗时接近 30 秒，说明连接全程未断；若提前报 Connection reset by peer 或 Empty reply from server，则平滑失败
用 ss 或 netstat 观察连接归属进程
reload 后，旧连接应仍绑定在旧 worker 进程上，新连接才分配给新 worker：
- 重载前记录所有活跃连接：ss -tnp | grep :80 | grep nginx | head -5，记下 PID 和 fd 号
- 重载后再次执行相同命令，对比同一连接的 PID 是否不变——不变说明该连接仍在原 worker 中处理
- 同时观察 ps aux | grep 'nginx: worker'，应短暂出现新旧 worker 共存（如 4 个旧 + 4 个新），几分钟后旧进程自然退出
结合 access_log 验证请求路由连续性
如果日志中已启用 $pid 变量（如 log_format main '$pid $remote_addr ...';），可进一步确认：
- 在 reload 前后连续发起多个长连接请求（如 5 个并发 curl -N http://.../sleep-10）
- 查看 access.log，确认每个请求的 $pid 字段：旧连接始终对应旧 worker PID，新连接逐步落到新 worker PID
- 若某次请求日志中 PID 突然跳变或缺失，可能意味着连接被意外中止或 worker 异常退出
用 wrk 压测高并发长连接场景
单连接验证通过后，需模拟真实负载压力：
- 运行：wrk -t4 -c200 -d30s --http-version 1.1 -H "Connection: keep-alive" http://your-domain.com/health
- 在压测进行到第 10 秒时执行 nginx -s reload
- 观察 wrk 输出：错误率（Errors）应为 0，平均延迟波动不超过 20%，且无连接超时（Timeouts）
- 同时监控 nginx_stub_status 页面中的 Active connections 和 Reading/Writing/Waiting 分布，reload 后不应出现 Waiting 突增或 Active 断崖下跌
