Nginx默认轮询在单节点宕机时依赖请求失败被动标记，首次失败后10秒内剔除该节点；显式配置max_fails=1 fail_timeout=3s可将故障窗口压缩至3秒内。
直接用 curl 搭配短连接 + 高频请求，配合手动停启后端节点，就能清晰观察 Nginx 轮询在单节点宕机瞬间的行为。关键不是“测出是否可用”，而是看失败请求是否可控、恢复是否及时、有无雪崩或长延迟。
一、准备可快速启停的后端服务（模拟节点）
启动 3 个轻量 HTTP 服务（如 Python Flask 或 netcat），分别监听 :8001、:8002、:8003，每个返回自身端口标识：
-
python3 -m http.server 8001 --bind 127.0.0.1:8001（简单静态服务，响应快） - 或用
while true; do echo -e "HTTP/1.1 200 OK\r\n\r\n8001" | nc -l -p 8001 -q 0; done（更贴近底层，无框架干扰） - Nginx upstream 配置为纯轮询（不加
max_fails/fail_timeout初始值，先看默认行为）：
server 127.0.0.1:8001;
server 127.0.0.1:8002;
server 127.0.0.1:8003;
}
二、用并发短连接暴力触发瞬时失败
不用长连接或压测工具——要的就是“刚发出去就撞上宕机”的真实感。执行：
for i in {1..50}; do curl -s -m 0.5 http://localhost/ 2>/dev/null &; done; wait- 在循环运行中，立刻
kill掉其中一个后端（如kill $(pgrep -f ":8002")） - 立即再补发一轮 50 次请求，观察输出和返回时间
你会看到：部分请求返回空、超时（curl: (28) Operation timed out）、或 502（如果 Nginx 已感知断连）。重点记录失败集中在哪几轮、持续几秒、是否连续失败同一节点。
三、验证 Nginx 的失败探测与摘除逻辑
默认配置下，Nginx 不会主动探活，仅靠请求失败被动标记。这意味着：
- 第一次请求打到已宕机节点 → 连接拒绝或超时 → Nginx 标记该 server 为
failed - 后续请求在
fail_timeout（默认 10 秒）内不再选它，转而轮询其余健康节点 - 但若你高频发送请求（如每 10ms 一个），且未设
max_fails，则可能在标记前已发出多个失败请求
建议显式配置提升健壮性：
server 127.0.0.1:8001 max_fails=1 fail_timeout=3s;server 127.0.0.1:8002 max_fails=1 fail_timeout=3s;
server 127.0.0.1:8003 max_fails=1 fail_timeout=3s;
这样只要一次失败，3 秒内自动剔除，大幅压缩故障窗口。
四、观察日志定位瞬时行为细节
打开 Nginx 错误日志（error_log /var/log/nginx/error.log notice;），复现宕机过程，搜索关键词：
-
no live upstreams→ 所有节点都被标记失败（说明没兜底） -
connect() failed或Connection refused→ 明确失败原因和对应 server -
upstream prematurely closed connection→ 后端中途断连，比拒绝连接更隐蔽
结合 access_log 中的 $upstream_addr 和 $upstream_response_time，可精确统计每类节点的失败率与延迟毛刺。
