在 linux 中测试 nginx 故障转移的切换灵敏度与耗时，核心做法是模拟上游服务宕机并记录客户端请求从失败到重试成功的时间差。具体操作需结合 keepalive 连接复用机制、nginx 的重试逻辑以及 proxy_next_upstream 配置，通过压测工具（如 wrk 或 ab）向 nginx 发送大量并发请求，同时监控上游服务的存活状态。
proxy_next_upstream 如何影响切换延迟
该指令决定了 Nginx 在什么条件下触发向上游其他节点的故障转移。默认情况下，Nginx 仅在遇到 502、503、504 等错误时才会尝试下一个节点，且如果启用了 keepalive，它可能会复用已建立但实际已失效的连接，导致首次请求超时后才触发转移。
upstream backend {
server 192.168.1.10:8080;
server 192.168.1.11:8080 backup;
}
server {
listen 80;
location / {
proxy_pass http://backend;
proxy_next_upstream error timeout invalid_header http_500 http_502 http_503 http_504;
proxy_next_upstream_tries 2;
proxy_connect_timeout 1s;
proxy_read_timeout 1s;
}
}
上述配置中，proxy_connect_timeout 和 proxy_read_timeout 共同决定了单次请求的最大等待时间。当主节点 192.168.1.10 宕机时，Nginx 会先尝试连接，若超过 1 秒无响应则判定为超时，随后根据 proxy_next_upstream 的规则触发对备份节点 192.168.1.11 的请求。切换总耗时近似等于 connect_timeout + read_timeout，加上网络往返时间（RTT）。若使用 wrk -t12 -c100 -d10s http://localhost/ 进行压测，观察返回结果中的平均延迟分布，可发现部分请求因触发故障转移而显著变长。
Keepalive 连接复用对故障检测的影响
启用 keepalive 后，Nginx 会保持与上游服务器的空闲连接池。当上游服务器突然关闭连接或宕机时，Nginx 并不会立即感知，而是直到下一次使用该连接发送请求时才发现连接已断开，从而触发故障转移。这会导致“冷启动”式的切换延迟。
upstream backend {
server 192.168.1.10:8080;
server 192.168.1.11:8080;
keepalive 32;
}
server {
listen 80;
location / {
proxy_pass http://backend;
proxy_http_version 1.1;
proxy_set_header Connection "";
proxy_next_upstream error timeout;
}
}
在此配置下，keepalive 32 表示最多保持 32 个空闲连接。当主节点宕机后，前 32 个复用该连接的请求仍会尝试发送数据，直到收到 ECONNRESET 或超时，才标记该节点为不可用并切换到备用节点。因此，故障转移的灵敏度受限于连接池大小和请求频率。若请求频率低，连接可能长时间处于空闲状态，导致 Nginx 无法及时更新节点健康状态。可通过调整 keepalive_timeout 或使用主动健康检查模块（如 nginx_upstream_check_module）来改善此问题，但标准开源版 Nginx 不支持主动健康检查，只能依赖被动检测。
基于 proxy_next_upstream_tries 参数的具体行为分析
proxy_next_upstream_tries 参数限制了单个请求最多可尝试的上游节点数量。当设置为 2 时，Nginx 最多尝试两个节点，若均失败则返回错误。这一参数直接影响故障转移的完整性和耗时上限。
在上述两节点配置中，若 proxy_next_upstream_tries 2，当主节点宕机时，Nginx 首先尝试主节点，超时后自动重试备份节点。若备份节点也宕机，则不再重试，直接返回 502 或 504 错误。此时，切换耗时主要由第一次超时的 timeout 值决定，后续重试几乎无额外开销。若将 tries 设为 1，则不会触发故障转移，所有请求直接失败。因此，合理设置 tries 值可平衡切换灵敏度和系统负载。在实际测试中，可通过逐步增加并发请求数，观察错误率与延迟的关系，验证故障转移是否按预期工作。
