验证Nginx动态后端代理滚动升级无损表现，核心是模拟真实发布节奏，确保请求不中断、不报错、不丢连接，覆盖短连接、长连接、流式响应及错误重试等多维度，并通过日志与指标实时观测静默切换效果。
要验证 Nginx 动态后端代理在滚动升级过程中的无损表现，核心是模拟真实发布节奏，并观测请求是否全程不中断、不报错、不丢连接。重点不在“能不能切”，而在“切得是否静默”——即客户端无感知、日志无异常、长连接不断开。
一、构造可验证的滚动升级环境
先确保后端服务具备基础就绪/终止能力：
- 每个实例暴露 /health（返回 200）和 /readyz（仅当完全初始化完成才返回 200）；
- 旧实例收到 SIGTERM 后，停止接受新请求，但保持已建立连接（含 keep-alive、WebSocket）直至超时或自然关闭；
- Nginx upstream 已启用主动健康检查（如
check interval=3 rise=2 fall=5），且配置了合理max_fails和fail_timeout。
二、执行可控的滚动动作并同步观测
不依赖自动化平台，手动分步操作更利于定位问题：
- 启动一个新后端实例，确认其
/readyz返回 200，且 Nginx 日志中出现upstream server temporarily disabled或upstream server restored类提示； - 向旧实例发送 SIGTERM，观察其 access log 是否停止新增请求，但仍在处理尾部连接（可通过
netstat -an | grep :8080 | grep ESTAB辅助判断）； - 等待 3–5 倍健康检查周期（如检查间隔 3s × fall=5 → 约 15s），确认该节点在
nginx -T | grep "down"或 Nginx Plus 的 dashboard 中标记为down。
三、多维度验证“无损”
不能只看 HTTP 状态码，要覆盖典型流量模式：
-
短连接请求：用
ab -n 1000 -c 50 http://your-domain/api/test持续压测，检查返回中Failed requests是否为 0，且无 502/503； -
长连接保活：发起一个带
Connection: keep-alive的持续请求（如 curl -H "Connection: keep-alive" --limit-rate 100B ...），在旧实例下线过程中观察是否被重置（TCP RST）或超时； -
流式响应场景：测试 SSE 或大文件下载，确认
proxy_read_timeout设置合理（建议 ≥90s），连接未被意外关闭； -
错误兜底行为：临时让新实例返回 502，验证
proxy_next_upstream error http_502是否触发重试，且客户端未收到错误响应。
四、关键日志与指标盯盘点
打开 Nginx 的详细日志级别，重点关注：
-
error.log中是否有no live upstreams、connect() failed、upstream prematurely closed connection； -
access.log中响应时间突增、状态码跳变（如某 IP 突然集中出现 502）、$upstream_addr 显示 fallback 到 backup 节点； - 用
ss -i或cat /proc/net/ip_vs_stats（若启用 ipvs）观察连接迁移是否平滑，worker 进程数是否稳定。
