Nginx 中负载均衡中记录集群转发分担比例-Nginx-PHP中文网

nginx 本身不内置实时统计各集群流量比例功能，但可通过 access_log 记录 $upstream_addr 或 $cluster_name 配合日志分析（如 awk）反推实际分担比例；也可借助 nginx-module-vts 查看 requests 与 weight 对比验证；split_clients 可实现可控分流并用日志验证，需注意 weight 仅为调度倾向而非硬性比例。

nginx 中负载均衡中记录集群转发分担比例

Nginx 本身不内置实时统计或日志记录“各集群实际承接流量比例”的功能，但可以通过配置组合 + 外部手段实现对转发分担比例的可观测性与验证。

用 access_log 记录后端服务器标识，反推实际分担比例

核心思路：在日志中明确标记每个请求最终被 proxy_pass 到哪台后端（或哪个 upstream 组），再通过日志分析得出真实分发比例。

log_format upstream_log '$remote_addr - $remote_user [$time_local] '
                         '"$request" $status $body_bytes_sent '
                         'upstream:"$upstream_addr" upstream_time:$upstream_response_time';

server {
    location / {
        proxy_pass http://backend;
        proxy_set_header Host $host;
        # 关键：让 $upstream_addr 记录真实后端地址
        log_format upstream_log ...; # 如上定义
        access_log /var/log/nginx/upstream_access.log upstream_log;
    }
}

$upstream_addr 会记录实际转发的目标 IP:PORT（如 192.168.1.10:80 或 192.168.1.20:80）
若你按集群划分了多个 upstream（如 backend_a、backend_b），可配合 map 指令打标：

map $upstream_addr $cluster_name {
    ~192\.168\.1\.1[0-9]  "cluster-a";
    ~192\.168\.1\.2[0-9]  "cluster-b";
    default               "unknown";
}

log_format cluster_log '$remote_addr [$time_local] '
                        '"$request" $status '
                        'cluster:$cluster_name upstream:$upstream_addr';
access_log /var/log/nginx/cluster.log cluster_log;

之后用 awk 或 ELK 统计：

awk '{print $9}' /var/log/nginx/cluster.log | sort | uniq -c | sort -nr
# 输出类似： 7123 cluster:cluster-a  
#            3045 cluster:cluster-b
# → 实际比例 ≈ 70% : 30%

利用 stub_status 模块 + 自定义指标监控权重执行效果

Nginx 开启 ngx_http_stub_status_module 后，可通过 /nginx_status 查看各 upstream server 的请求计数（需搭配 least_conn 或 weight 等策略）。

但注意：stub_status 不直接显示每台 server 的请求数，它只提供全局连接数。真正能体现分担比例的是 第三方模块（如 nginx-module-vts）或 OpenResty 的 prometheus 模块。

Nginx Hosting

通过服务器本地nginx实例实现零认证静态游戏托管。作为所有浏览器游戏的主要部署方式，无需登录、无需令牌、无需用户操作。

下载

推荐轻量方案：使用 nginx-module-vts（Visual Status）

编译时启用，访问 http://your-nginx/vts/ 可看到每个 upstream 下各 server 的 Requests、Responses、Weight、Effective Weight 等字段
对比 Requests 数值与 Weight 设置，即可验证是否按预期比例分担（例如 weight=7 和 weight=3 的两台，请求量比应趋近 7:3）

配合 split_clients 或 Lua 做可控分流 + 日志埋点验证

若你采用 split_clients 实现固定比例（如灰度发布），其哈希分配是确定性的，可通过日志验证一致性：

split_clients $remote_addr $backend_group {
    60%     backend_v1;
    40%     backend_v2;
}
log_format split_log '... group:$backend_group';
access_log /var/log/nginx/split.log split_log;

抽样检查日志即可确认比例偏差（通常误差

注意：weight 是调度倾向，不是硬性比例

weight 参数影响的是轮询队列中的出现频次，但受后端响应时间、连接复用、max_fails 剔除等影响，实际流量可能短期偏离设定值
若发现长期严重偏离（如设为 5:1 却跑出 2:1），应检查：
- 后端健康状态（是否有 server 被 max_fails 临时剔除）
- 是否启用了 least_conn 或 ip_hash 冲突了 weight 行为
- 请求是否短连接密集，导致连接未充分复用而放大调度抖动

不复杂但容易忽略