必须配置zone指令才能让Nginx多个worker进程共享upstream状态；zone需置于upstream块内，格式为zone name size，且依赖它才能实现ip_hash一致性、least_conn全局连接数统计、健康检查及sticky cookie会话保持。
要让 Nginx 多个 worker 进程共享 upstream 后端的状态（比如谁健康、当前连接数多少、IP 哈希绑定结果是否一致），必须在 upstream 块中显式配置 zone 指令。它不是可选优化，而是跨进程同步的硬性前提。
zone 指令的基本写法和位置要求
zone 必须写在 upstream 块内部，语法为：zone name size;
-
name 是自定义标识符，如
backend_zone，不能含点号（.）或特殊字符，建议只用字母、数字和下划线 -
size 指定共享内存大小，常见值有
64k（适合小规模集群）、1m（节点多或启用slow_start时更稳妥）；太小会报warning: no memory，太大则浪费资源 - 一个
upstream块只能有一个zone；多个upstream块可共用同一name，但size只需在第一个中指定
哪些功能依赖 zone 才能跨进程生效
光加 zone 不代表状态就自动同步——它只是提供共享内存“容器”，具体能力还需搭配对应模块和参数：
-
ip_hash / hash $arg_key：没有
zone，不同 worker 对同一客户端 IP 可能选不同后端，会话中断；加了才能保证哈希映射全局一致 -
least_conn：各 worker 需读取同一份实时连接数，否则负载倾斜；
zone是前提，否则仅在单个 worker 内有效 -
健康状态标记（up/down）：必须配合
max_fails和fail_timeout，否则即使某节点失联，Nginx 也不会将其置为down -
sticky cookie：如
sticky cookie srv_id ... zone=backend_zone;，zone是必填项，用于持久化会话绑定关系
验证 zone 是否真正起作用
最直接的方式是结合日志压测观察：
- 在
log_format中加入$pid和$upstream_addr，例如：log_format main '$pid - $upstream_addr - $remote_addr'; - 对同一客户端 IP（或固定
hash参数）发起多次请求，检查不同$pid（即不同 worker）是否始终转发到同一个$upstream_addr - 若结果一致，说明
zone+ip_hash或hash已协同生效；若不一致，先确认 Nginx 版本 ≥ 1.9.0，再检查zone是否写在upstream块内且无拼写错误
常见限制与注意事项
zone 功能有明确平台和版本边界，忽略会导致配置失败或行为异常：
-
Windows 原生版不支持：启动会报
"zone" directive is not supported on this platform；原因是依赖 POSIX 共享内存（shm_open），而官方 Windows 编译未实现；推荐改用 WSL2 + Linux 版 Nginx -
修改后必须 reload，不能 restart：执行
nginx -s reload，避免新旧 worker 同时访问共享内存引发争抢或状态错乱 -
单 server 的 upstream 会忽略 max_fails：即使写了
max_fails=3 fail_timeout=30s，该节点也永远不会被标记为down，需至少两个 server 才触发故障检测逻辑
