必须显式配置 upstream 块内的 zone 指令（如 zone backend_zone 64k），它通过共享内存使所有 worker 进程同步后端状态（健康状况、连接数、ip 哈希映射等）；仅配置 zone 不足，还需为每个 server 设置 max_fails 和 fail_timeout 才能触发自动故障标记。

要让 Nginx 多个 worker 进程真正共享 upstream 后端的运行状态（比如谁健康、连接数多少、IP 哈希映射是否一致），必须显式配置 zone 指令。它不是增强项，而是打通进程隔离的唯一方式。

zone 是跨 worker 共享状态的前提

默认情况下，每个 worker 进程各自维护一份 upstream 状态：一个 worker 把某台后端标记为 down，其他 worker 完全不知情，仍可能转发请求过去，造成失败或超时。zone 指令启用共享内存，让所有 worker 读写同一块区域：

• 必须写在 upstream 块内部，格式为：zone name size;（如 zone backend_zone 64k;）
• name 是自定义标识符，不能含点号或特殊字符；size 要预估足够，64k 可支撑约 10–20 个后端，节点多可设为 1m
• Nginx 1.9.0+ 才支持；Windows 原生版不支持，会报 "zone" directive is not supported on this platform

zone 共享内存里实际存什么

这块内存不只是记“up/down”，而是承载整个 upstream 组的核心运行时数据：

Nginx Config Linter

对 Nginx 配置文件进行语法检查、验证和安全、性能审计。

下载

• 每台 server 的实时状态（up/down/unavail）、失败次数、上次失败时间
• least_conn 所需的各后端当前活跃连接数（确保所有 worker 计算结果一致）
• ip_hash 或 hash $arg_key consistent 的客户端到后端的绑定映射
• slow_start 阶段中权重的动态爬升进度

光有 zone 不够，必须搭配健康机制

zone 提供存储载体，但不会自动判断故障。要真正触发状态变更，还需基础健康参数：

• 每个 server 行必须设置 max_fails 和 fail_timeout（如 max_fails=3 fail_timeout=30s）
• 若 upstream 中只有一个 server，这两个参数会被忽略，该节点永不标记为 down
• proxy_next_upstream 的重试行为也依赖 zone 中的实时状态，建议按地域调优超时值

验证是否生效的实用方法

配置完成后，别只看语法是否通过，要实测状态是否真被共享：

• 在日志中加入 $pid 和 $upstream_addr，用同一客户端 IP 发起多次请求
• 观察不同 $pid（即不同 worker）下，$upstream_addr 是否始终指向同一台后端（尤其对 ip_hash）
• 手动停掉一台后端，观察所有 worker 是否在 fail_timeout 后同步将其标记为 down，不再转发
• 修改 zone 配置后务必执行 nginx -s reload，避免新旧 worker 争抢共享内存