如何通过Nginx的Upstream-Check机制监控并实现微服务节点的平稳下线？

本文共计948个文字，预计阅读时间需要4分钟。

在默认编译的Nginx中，使用如`check`、`check_http_send`等指令将会报错：

验证方式很简单：

nginx -V 2>&1 | grep -o 'upstream_check'

没输出就说明没启用。临时补救只有两个选择：自己编译带模块的 Nginx，或改用官方健康检查（health_check 指令，仅限 Plus 版本）或基于 proxy_next_upstream 的简易探测（无主动探活能力）。

配置 Upstream-Check 时必须关闭 keepalive 冲突

常见错误是把 keepalive 和 check 放在同一 upstream 块里，例如：

upstream backend { server 10.0.1.10:8080; check interval=3 rise=2 fall=3 timeout=1; keepalive 32; }

这会导致 Nginx 启动失败，报错：keepalive cannot be used with health check。原因是 upstream_check_module 自己维护连接池，与官方 keepalive 机制不兼容。

正确做法是：

• 移除 upstream 块内的 keepalive 指令
• 若需长连接，在 location 块中用 proxy_http_version 1.1 + proxy_set_header Connection "" 透传给后端
• 对上游连接复用依赖 check 自带的连接管理（它会在探活时复用底层 socket）

平滑下线依赖 check 的状态同步与 proxy_next_upstream 配合

upstream_check_module 本身只负责探测并标记节点为 down，但 Nginx 默认不会自动跳过已 down 的节点——除非你明确告诉它“哪些失败要重试”。否则，请求仍可能打到刚被标记为 down、但尚未从负载均衡列表中剔除的节点上（尤其在高并发下）。

关键配置组合如下：

upstream backend { server 10.0.1.10:8080 max_fails=0 fail_timeout=0; server 10.0.1.11:8080 max_fails=0 fail_timeout=0; check interval=3 rise=2 fall=3 timeout=1 type=http; check_http_send "HEAD /actuator/health HTTP/1.1\r\nHost: localhost\r\n\r\n"; check_http_expect_alive http_2xx http_3xx; } server { location / { proxy_pass http://backend; proxy_next_upstream error timeout http_500 http_502 http_503 http_504; proxy_next_upstream_tries 3; proxy_next_upstream_timeout 5s; } }

注意点：

• max_fails=0 必须设为 0，否则 Nginx 会用自己的被动健康检查逻辑覆盖 check 的结果
• check_http_send 要匹配后端真实健康接口路径和协议头（Spring Boot 默认是 /actuator/health，且需支持 HEAD）
• proxy_next_upstream 必须包含 error 和 timeout，才能在节点被 check 标记为 down 后，首次请求失败时触发重试

如何确认节点真的“平滑”下线了

光看 check 日志（如 upstream_check_status 页面）显示某节点为 down 不够——得验证流量是否彻底绕过它。最直接的方式是：

• 在目标后端节点停服务前，用 curl -v http://your-nginx/ 多次请求，记录响应头中的 X-Upstream-Addr（可配合 proxy_set_header X-Upstream-Addr $upstream_addr; 输出）
• 手动停掉该节点（比如 kill -15 Spring Boot 进程）
• 等待 3–6 秒（即 interval × fall），再快速发 10+ 请求，检查返回的 X-Upstream-Addr 是否完全不包含该节点 IP

如果仍有请求打过去，大概率是 proxy_next_upstream 没生效，或者客户端（如浏览器）因 HTTP/1.1 keepalive 复用了旧连接，误以为还在通信——这时需要加 proxy_force_ranges off 或更激进地设 proxy_buffering off 来暴露问题。真正平滑的下线，是业务无感知的，而这个“无感知”的边界，往往卡在连接复用和重试策略的缝隙里。