深色模式
upstream 健康检查
摘要：负载均衡没探活 = 把流量送给已死的后端。本文用开源 Nginx 的被动探活（
max_fails/fail_timeout）配出「坏节点自动摘除」，并补充主动健康检查思路。
适用环境
bash
nginx -v
# 被动探活：所有版本支持；主动 health_check：需 Nginx Plus 或搭配 nginx-upsync/第三方模块1
2
2
操作步骤
1. 被动探活（最通用，推荐先上）
nginx
# /etc/nginx/conf.d/lb.conf
upstream app {
server 127.0.0.1:8081 max_fails=3 fail_timeout=30s;
server 127.0.0.1:8082 max_fails=3 fail_timeout=30s;
}
server {
listen 80;
location / {
proxy_pass http://app;
proxy_next_upstream error timeout http_502 http_503;
}
}1
2
3
4
5
6
7
8
9
10
11
12
2
3
4
5
6
7
8
9
10
11
12
含义：某后端在 30 秒内失败 3 次，就被标记为不可用 30 秒；期间请求只发给健康节点。proxy_next_upstream 让一次失败自动重试下一个节点。
2. 让后端暴露健康检查端点
bash
# 后端增加 /healthz 返回 200（以 python 简单示例）
# 实际业务在代码里加：GET /healthz → 200 OK1
2
2
3. 主动健康检查（Nginx Plus / 第三方）
nginx
# Nginx Plus 语法示意
upstream app {
zone app 64k;
server 127.0.0.1:8081;
server 127.0.0.1:8082;
health_check uri=/healthz interval=5s fails=2 passes=2;
}1
2
3
4
5
6
7
2
3
4
5
6
7
4. 测试并 reload
bash
sudo nginx -t && sudo nginx -s reload1
验证
bash
# 停掉一个后端，观察请求是否全部落到存活节点
kill %1 # 假设 8081 是作业 1
for i in $(seq 1 5); do curl -s -o /dev/null -w "%{http_code}\n" http://127.0.0.1/; done
# 短暂 502/重试后稳定 200，且不再出现持续报错 = 探活生效1
2
3
4
2
3
4
常见坑
WARNING
被动探活靠「真实请求失败」来判定，存在探测延迟——坏节点可能在 fail_timeout 窗口内仍收到少量流量。对可用性要求高的场景，应上主动健康检查（独立探测，不依赖业务流量）。
DANGER
fail_timeout 设太短、max_fails 设太小，会在后端轻微抖动（如 GC 停顿）时频繁摘挂，引起流量抖动。建议 fail_timeout=10~30s、max_fails=2~3 起步，按实际调。