Nginx默认轮询不支持毫秒级响应延迟判断，但可通过proxy_read_timeout + max_fails + fail_timeout组合实现延迟敏感型自动隔离：设proxy_read_timeout为业务P95耗时的1.5–2倍（如1s），max_fails=2、fail_timeout=15s，配合proxy_next_upstream error timeout http_500实现失败重试与平滑切流。
Nginx 默认轮询本身不支持“响应延迟阈值”这种毫秒级动态判断，它只按顺序分发请求，不测量后端耗时。但你可以通过组合健康检查参数与上游重试机制，**模拟实现基于延迟的自动隔离效果**——关键不是测延迟本身，而是让超时失败触发剔除。
用 proxy_read_timeout + max_fails 实现延迟敏感型隔离
真正起作用的是连接和读取阶段的超时行为。当某台后端响应慢到触发超时，Nginx 就会记为一次失败；连续达到 max_fails 次，就进入 fail_timeout 隔离期。
-
proxy_read_timeout：定义从后端读取响应体的最长时间（单位秒），建议设为业务 P95 响应时间的 1.5–2 倍，比如后端通常 200ms 返回，可设为
proxy_read_timeout 1s; - max_fails=2：只要连续 2 次因超时或 5xx 失败，就标记该节点不可用
- fail_timeout=15s：被标记后 15 秒内不再转发请求，之后自动试探恢复
配置示例：
upstream backend {<br>
server 192.168.1.10:8080 max_fails=2 fail_timeout=15s;<br>
server 192.168.1.11:8080 max_fails=2 fail_timeout=15s;<br>
}
location / {<br>
proxy_pass http://backend;<br>
proxy_read_timeout 1s;<br>
proxy_connect_timeout 3s;<br>
proxy_send_timeout 3s;<br>
}
配合 proxy_next_upstream 提升容错弹性
仅靠轮询+超时剔除还不够——用户请求仍可能卡在慢节点上。启用 proxy_next_upstream 可在单次请求失败后，自动转向下一个可用节点，避免用户感知长延迟。
- 推荐配置：
proxy_next_upstream error timeout http_500; - 注意不要加
http_503或invalid_header，除非你明确需要这些条件重试 - 搭配
proxy_next_upstream_tries 2;控制最多重试 1 次（默认为 1，即总共最多尝试 2 台）
真正监控延迟差异才能及时干预
轮询不会告诉你哪台更慢，所以必须主动观测：
- 开启
log_format记录$upstream_response_time和$upstream_addr - 用日志分析工具（如 awk / Grafana + Loki）统计各节点平均响应时间、P95、失败率
- 若发现某节点
upstream_response_time持续高于均值 3 倍，且upstream_addr日志中失败频次高，说明轮询已失效，该升级为least_conn或加权策略
