关键是要启用upstream_zone模块并配置zone指令，它通过共享内存使所有worker进程同步后端状态（如健康状况、连接数、哈希映射等），否则各worker状态隔离；需配合max_fails和fail_timeout才能触发自动故障标记。
要让 Nginx 多个 worker 进程共享同一套 upstream 后端节点状态（比如谁健康、谁失败过、当前连接数多少），关键就是启用 upstream_zone 模块并正确配置 zone 指令。它不是可选项，而是跨进程同步的基础设施。
zone 指令必须显式声明
默认情况下，每个 worker 进程各自维护一份 upstream 状态——彼此隔离。一旦某个 worker 把某台后端标记为 down，其他 worker 完全不知道，仍可能继续转发请求过去。加了 zone 才能打破这种隔离：
- 语法很简单：
zone name [size];，必须写在 upstream 块内部 - name 是自定义标识符（如
backend_zone），size 指定共享内存大小（例如64k或1m） - 没有默认值，不写就等于没开启共享；1.9.0 及以上版本才支持
共享内存里存什么
这个 zone 不是只存“谁挂了”这么简单，它承载的是整个 upstream 组的运行时上下文：
- 每个 server 的当前状态（up / down / unavail）、失败计数（max_fails）、上次失败时间
- least_conn 算法依赖的实时活跃连接数
- hash 和 ip_hash 的会话绑定映射关系（确保不同 worker 对同一 IP 总选同一台后端）
- slow_start 阶段的权重爬升进度
配合健康检查与动态算法才真正生效
光有 zone 不足以自动发现故障，还需搭配基础健康机制：
- 必须设置
max_fails和fail_timeout，否则即使加了 zone，Nginx 也不会主动标记节点为不可用 - 若 upstream 中只有一个 server，这两个参数会被忽略，该节点永远不会被标记为 down——哪怕它已失联
- least_conn、ip_hash 等算法只有在 zone 存在时，才能保证所有 worker 计算结果一致
- NGINX Plus 的 API 接口（如
/api/6/http/upstreams/backend）读取的正是这个 zone 里的数据
配置示例与注意事项
一个典型可用的 upstream 块长这样：
upstream backend {
zone backend_zone 64k;
least_conn;
server 10.0.1.10:8080 max_fails=3 fail_timeout=30s;
server 10.0.1.11:8080 max_fails=3 fail_timeout=30s;
}
注意点：
- 多个 upstream 块可以共用同一个 zone 名称，此时 size 只需在第一个里指定
- size 要足够容纳所有 server 条目及其状态，太小会导致 warning 甚至功能降级
- 修改 zone 名称或 size 后，必须 reload（不是 restart），否则新旧 worker 共存可能导致状态混乱
