加权轮询本身不涉及“绝对路径错误”，weight参数仅影响upstream中server的请求分发比例，与文件系统路径、proxy_pass地址等完全无关；其失效主因是混用ip_hash、健康检查异常或后端摘除等配置逻辑问题。
加权轮询本身不涉及“绝对路径错误”——这个说法存在概念混淆。Nginx 的 weight 参数只影响 upstream 中各 server 的请求分发比例，和文件系统路径（如 root、log、proxy_pass 后端地址等）完全无关。所谓“加权轮询配置中的绝对路径错误”，实际是把两类问题混在一起了：一类是负载均衡策略配置，另一类是文件或服务访问路径配置。
先确认你真正遇到的是哪类问题
如果你在启用 weight 后发现请求没按预期比例分配，那问题出在轮询逻辑或健康检查上；如果你看到 403、404、502 等错误，或者 Nginx 启动失败、日志写不进、静态资源打不开，那才可能是路径或权限问题——但和 weight 无关。
加权轮询失效的常见真实原因
这些才是真正会影响 weight 行为的因素，排查时应优先检查：
-
混用了 ip_hash 或 hash 指令：只要 upstream 块里写了
ip_hash;或hash $request_uri;，轮询（包括加权轮询）就完全失效，请求被强制绑定到固定后端 -
某台 server 显式写了 weight，其他没写：Nginx 默认 weight=1，但一旦出现显式 weight，整个 upstream 就进入加权轮询模式；但如果部分 server 缺少
max_fails/fail_timeout，健康状态不同步，会导致实际参与轮询的节点数动态变化，权重比例失真 -
后端服务响应异常触发摘除：比如 A 节点因超时被临时剔除（
max_fails=1），剩下 B 和 C 继续按 weight=2:1 分发，此时 A 不在轮询队列里，看起来像“权重没生效”
如果确实遇到路径相关报错（如 403/502），按这个顺序查
这类问题常被误认为和 weight 有关，其实是独立的配置环节：
-
检查 proxy_pass 后端地址是否可通：用
curl -v http://192.168.1.10:8080/health直连每台后端，确认协议、端口、路径都正确，尤其注意末尾斜杠是否一致 -
确认 Nginx worker 进程对目标目录有权限：运行
grep 'user' /etc/nginx/nginx.conf查用户（如www-data），再执行ls -ld /var/www/myapp看属主和权限，目录需有x（执行）位才能进入 -
验证 error_log 和 access_log 路径是否存在且可写：例如
error_log /var/log/nginx/backend_error.log;要求/var/log/nginx/目录存在，且 nginx 用户对该目录有写权限
验证加权轮询是否真正生效的方法
别靠猜，用日志+串行请求实测：
- 在 upstream 每个 server 后加唯一注释或标签，例如：
server 192.168.1.10:8080 weight=3; # app-v1 - 配置 access_log 记录
$upstream_addr，例如：log_format upstream '$remote_addr → $upstream_addr [$time_local] "$request" $status'; - 用
ab -c 1 -n 100或for i in {1..100}; do curl -s http://lb-ip/ > /dev/null; done发起串行请求（避免 keepalive 干扰） - 查看日志中
$upstream_addr出现频次是否接近权重比（如 3:2:1 → 约 50% : 33% : 17%）
