Nginx多进程架构负责并发连接处理，不决定后端分发策略；真正的负载均衡策略（如轮询、加权、ip_hash、least_conn）由upstream模块在http块内统一配置，所有worker进程共享该策略，proxy_pass引用对应upstream名称实现流量分发。
Nginx 的多进程架构本身不直接参与“负载策略”的配置，它负责的是请求的并发处理与资源调度；而真正的负载均衡策略（如轮询、加权、IP哈希等）是在 upstream 模块中定义的，作用于后端服务器之间的流量分发。两者分工明确：worker 进程处理客户端连接，upstream 策略决定把请求发给哪个后端。
下面从实际配置角度说清楚关键点：
多进程模型对负载均衡的影响
Nginx 启动后有一个 master 进程和多个 worker 进程。每个 worker 都能独立接收并转发请求，但它们共享同一个 upstream 配置。也就是说：
- 所有 worker 使用完全相同的负载策略（比如都走
least_conn） - 不需要为每个 worker 单独配置策略，策略在
http块里全局生效 - worker 数量建议设为 CPU 核心数（
worker_processes auto;），避免进程争抢过多影响吞吐
upstream 中配置负载策略才是核心
真正控制“请求分到哪台后端”的地方是 upstream 块，例如：
upstream backend {
# 选一种策略写在 upstream 块开头（或省略，默认轮询）
least_conn; # 或 ip_hash; 或 keepalive 32;
server 192.168.1.10:8080 weight=3 max_fails=2 fail_timeout=30s;
server 192.168.1.11:8080 weight=1;
server 192.168.1.12:8080 backup;
}常见策略及其适用情况：
- 轮询（默认）：不写任何关键字，适合后端性能一致、无状态服务
-
加权轮询：用
weight=明确分配比例，比如旧机器配weight=1，新机器配weight=3 -
IP 哈希：加
ip_hash;，保证同一 IP 总打到同一台后端，用于会话保持（注意增减节点会打乱哈希） -
最少连接：加
least_conn;，适合长连接或处理时长差异大的场景（如 WebSocket、报表导出）
注意几个易忽略的细节
-
upstream必须定义在http{}块内，不能放在server{}或location{}里 -
proxy_pass http://backend;中的backend要和 upstream 名称严格一致（区分大小写） - 如果用了
ip_hash，至少得有两个server，否则会报错 -
backup和down标记可用于维护或容灾，不影响主策略运行
不复杂但容易忽略
