加权轮询不直接导致504，但会放大后端响应不均——当高权重节点因CPU/IO瓶颈、连接池打满或配置失配（如低配机器设高权重）而变慢时，Nginx持续分发请求并触发proxy_read_timeout返回504；需结合日志定位慢节点、验证真实P95耗时、按路径精准调大proxy_read_timeout并启用max_fails自动剔除。
加权轮询本身不会直接导致504，但它是放大后端响应不均的“放大器”——当某些上游节点处理能力弱、负载高或网络延迟大时，加权轮询会按权重持续把请求分发过去，一旦这些节点响应变慢，Nginx在等待其返回时就容易触发proxy_read_timeout，从而返回504。排查关键不是看“轮询是否生效”，而是看“谁在拖慢整条链路”。
确认504是否真由加权轮询引发
先排除干扰：504是网关层超时，和轮询策略无直接因果关系。需验证是否仅出现在特定上游节点上：
- 查 Nginx error.log，搜索
upstream timed out，注意日志中是否带具体 upstream 名称或 IP，例如：upstream: "backend_servers"或10.0.1.12:8080 - 对比 access.log 中
$upstream_addr和$upstream_response_time字段，例如某次 504 日志行：192.168.1.5 - - [16/Sep/2026:17:22:03] "GET /api/order" 504 0 "-" "curl/7.68" "10.0.1.11:8080, 10.0.1.12:8080" "0.003, 127.412"→ 表明第二次重试落到10.0.1.12，耗时 127 秒，极可能是该节点慢 - 临时将 upstream 改为单节点（如只留
server 10.0.1.11:8080 weight=1;），复现相同请求，若 504 消失，则问题集中在某个上游实例
检查加权配置与实际负载是否匹配
权重只是“理想分配比例”，不代表真实承载能力。如果高权重节点 CPU 已满、连接数打满或磁盘 I/O 阻塞，它就会成为瓶颈：
- 登录各上游服务器，运行
top -H查看 Java/PHP 进程线程状态，重点关注%CPU和RES内存占用；用ss -s或netstat -ant | grep :8080 | wc -l看 ESTABLISHED 连接数是否接近应用最大连接池（如 Tomcat 的maxConnections） - 检查 Nginx upstream 配置中是否混用了不同规格机器却设了相同权重，例如：
server 10.0.1.10:8080 weight=3;（4核16G）和server 10.0.1.11:8080 weight=3;（2核4G）——物理能力差异大，权重却一样，后者极易被压垮 - 确认是否启用了
max_fails和fail_timeout。若未启用，Nginx 不会自动剔除慢节点，仍会持续转发请求过去；建议至少配max_fails=2 fail_timeout=30s
区分是节点真实慢，还是 Nginx 等待太急
加权轮询下偶发 504，大概率是某节点响应时间波动大（比如数据库慢查询偶发、GC 暂停、下游依赖抖动），而 Nginx 的 proxy_read_timeout 又没预留足够缓冲：
- 在 Nginx 服务器上直连慢节点测试：
curl -w "%{time_total}\n" -o /dev/null -s http://10.0.1.12:8080/api/slow-endpoint，多次执行观察 P95 响应时间。若稳定在 80–150 秒，而proxy_read_timeout是默认 60 秒，那必然 504 - 不要全局拉长 timeout，而是对问题 location 局部调整。例如：
location /api/report { proxy_read_timeout 300; proxy_connect_timeout 10; proxy_send_timeout 60; proxy_pass http://backend_servers; } - 同步检查该节点上的应用超时设置（如 Spring Boot 的
server.tomcat.connection-timeout、PHP-FPM 的request_terminate_timeout），确保它们 ≥ Nginx 的proxy_read_timeout，否则应用先断连，Nginx 会记作 502 而非 504
验证轮询行为本身是否异常
加权轮询是静态哈希+计数器实现，本身极稳定。但以下配置错误会导致“看似轮询，实则倾斜”：
- 检查是否有
ip_hash或hash $request_uri等指令与weight共存——权重会被忽略，请求全打到同一台 - 确认没有误写
down或backup标志，导致可用节点只剩一个，权重失去意义 - 用
nginx -T | grep -A 10 "upstream backend_servers"输出完整 upstream 块，人工核对权重总和与 server 数量是否符合预期（例如两个节点 weight=2 和 weight=1，理论分发比应为 2:1）
