必须配置upstream块内的zone指令才能实现多worker进程共享状态和计数器；语法为zone name size，如zone backend_pool 64k；需配合max_fails、fail_timeout等健康检查参数，并通过压测验证一致性。
要让 Nginx 多个 worker 进程真正共享 upstream 状态（比如谁健康、连接数多少、IP 哈希绑定结果）和实时计数器（如 least_conn 的活跃连接数），必须显式配置 upstream 块内的 zone 指令。它不是可选项，而是打破进程隔离、实现状态与计数器全局一致的硬性前提。
zone 指令必须写在 upstream 块内部
默认情况下，每个 worker 各自维护一套 upstream 数据——彼此完全独立。加了 zone 才能共用同一块共享内存：
- 语法格式为：zone name size;，例如
zone backend_pool 64k; -
name 是自定义标识符（如
backend_pool），只能含字母、数字和下划线，不能带点号（.）或特殊字符 -
size 要合理预估：64k 可支撑约 10–20 个后端节点；节点多、启用了
ip_hash或slow_start时建议设为1m - 多个 upstream 块可复用同一个 name，但 size 只需在第一个中声明，后续重复会警告
共享内存里存的是完整运行时上下文
这块内存不只是记“up/down”，而是承载 upstream 组的核心状态与计数器：
- 每台 server 的实时状态（
up/down/unavail）、失败次数、上次失败时间 -
least_conn所依赖的各后端当前活跃连接数——所有 worker 读取同一数值，避免负载倾斜 -
ip_hash或hash $arg_key的客户端到后端映射关系，确保不同 worker 对同一 IP 总选同一台后端 -
slow_start阶段中权重的动态爬升进度
光有 zone 不会自动更新状态，必须搭配健康机制
zone 提供共享载体，但不主动探测故障。要让状态真实反映后端情况，必须配合基础参数：
- 每个
server行必须设置 max_fails 和 fail_timeout，例如：server 10.0.1.10:8080 max_fails=3 fail_timeout=30s; - 若 upstream 中只有一个 server，这两个参数会被忽略，该节点永不标记为不可用
-
proxy_next_upstream的重试逻辑也依赖 zone 中的实时状态，建议按地域调优超时值（如亚洲用户访问美国节点设为 3s）
验证是否真正生效的实用方式
别只检查配置语法，要压测观察行为一致性：
- 在
log_format中加入$pid和$upstream_addr，例如：log_format main '$pid - $upstream_addr - $remote_addr'; - 用同一客户端 IP 发起多次请求，检查不同
$pid（即不同 worker）是否始终转发到同一个$upstream_addr - 手动停掉一台后端，观察所有 worker 是否在
fail_timeout时间内统一将其标为unavail，而非部分 worker 仍持续发请求
