nginx官方不支持random负载均衡算法；截至2026年7月，原生仅支持round_robin、weight、ip_hash、least_conn及hash $key consistent五种策略，random属已停维护的第三方模块或旧实验补丁，不可用于主流版本。
Nginx 官方 不支持 random 负载均衡算法。截至 2026 年 7 月，upstream 模块原生支持的负载均衡策略只有以下几种：
-
round_robin（默认，轮询） -
weight（加权轮询） -
ip_hash（IP 哈希） -
least_conn（最少连接） -
hash $key consistent（一致性哈希，需指定变量）
⚠️ 注意：random 不是 Nginx 内置指令，也未被 upstream 模块任何稳定版本采纳。网上部分文章提到的 random 或 random two 属于第三方模块（如 nginx-upstream-random）或旧版实验性补丁，早已停止维护，且不兼容主流 Nginx 1.20+ 版本（包括当前稳定版 1.24/1.25）。
那“完全随机”还能实现吗？
可以，但需明确两点：
- 真·每次请求独立、无状态、等概率选后端 —— 这不是 Nginx 原生能力；
- 近似随机效果可通过组合策略 + 工程手段达成，适用于大多数业务场景。
替代方案：用 least_conn + 动态权重模拟随机性
当后端服务器性能相近、响应时间波动小、连接数快速释放时，least_conn 在高并发下行为接近随机：
因为连接建立/关闭存在微秒级时序差异，各节点“当前连接数”在毫秒尺度上近乎不可预测，调度结果呈现统计意义上的均匀分布。
upstream backend_random_like {
least_conn;
server 192.168.1.10:8080;
server 192.168.1.11:8080;
server 192.168.1.12:8080;
}
✅ 优点：无需编译模块，零依赖，稳定可靠
❌ 缺点：非严格数学随机，强会话粘性场景不适用
更贴近随机的实践方式：客户端侧散列 + Nginx hash
如果你能控制请求来源（如 App、前端 SDK），可在客户端生成一个随机值（如 UUID、时间戳纳秒哈希），通过自定义 Header 或 URL 参数传入，再由 Nginx 做 hash 调度：
upstream backend_random {
hash $http_x_req_id consistent; # 使用客户端传的随机 ID 散列
server 192.168.1.10:8080;
server 192.168.1.11:8080;
server 192.168.1.12:8080;
}
server {
location / {
proxy_pass http://backend_random;
proxy_set_header X-Req-ID $request_id; # 或从 $arg_rid / $http_x_custom_rid 获取
}
}
✅ 效果：每个唯一随机 ID 映射到固定后端，全局请求 ID 充分随机 → 实际调度高度均匀
✅ 可控、可审计、无状态、兼容所有 Nginx 版本
不推荐的做法
- 尝试打补丁编译
nginx-upstream-random：该模块最后更新于 2017 年，与现代 OpenSSL、HTTP/2、gRPC 等特性冲突，极易引发段错误或连接复用异常； - 用
if+$random变量做条件 proxy_pass：Nginx 的$random是 0–0.999 的伪随机浮点数，但不能在upstream或proxy_pass中动态计算目标，仅可用于日志、限流等只读上下文； - 依赖 Lua（OpenResty）做
math.random()调度：可行但引入运行时依赖，偏离轻量反向代理定位，运维复杂度陡增。
Nginx 的设计哲学是“简单、可靠、高性能”，它把复杂调度逻辑留给上游服务发现系统（如 Consul + Envoy）或应用层。真需要强随机，建议在业务网关层（如 Spring Cloud Gateway、Traefik）或服务网格中实现，而非强求 Nginx 承担非核心职责。
