nginx worker_connections 不能热重载生效，仅在worker进程启动时读取；reload后新旧worker分别按新旧值独立运行，连接交替依赖socket继承与内核分发，非该参数变更驱动。
Nginx worker_connections 本身不能在热重载（nginx -s reload）时动态生效，它属于仅在 worker 进程启动时读取的静态限制值。热重载过程中新老连接的交替，与 worker_connections 的数值变化无关，而是由进程生命周期、监听套接字继承和内核分发机制共同决定的。
下面分三部分说清关键逻辑：
worker_connections 不参与热重载更新
该指令必须写在 events { ... } 块中，且仅在 worker 进程首次 fork 并初始化时解析一次：
- 旧 worker 进程已运行，其最大并发连接数（即
worker_connections所设值）已固定，无法被 reload 改变； - 新 worker 进程启动时，才按新配置中的
worker_connections值初始化连接池和 epoll/kqueue 句柄上限； - 若你修改了
worker_connections后执行reload，只有新 worker 受影响，旧 worker 仍按旧值运行，直到退出。
新老连接如何自然交替？靠的是 socket 继承 + 内核负载分发
reload 不重启监听端口，而是复用已有 socket：
- 主进程在 fork 新 worker 前，已用新配置重新调用
listen()（如新增端口会尝试打开），但对原有80/443等端口，直接将已打开的 listening socket 文件描述符继承给新 worker； - 新旧 worker 共享同一组 listening socket，内核通过
SO_REUSEPORT（Nginx 1.9.1+ 默认启用）将新到达的 TCP 握手请求（SYN）自动分发给新 worker； - 已建立的连接（ESTABLISHED）仍绑定在原 worker 的 epoll 实例上，继续由旧 worker 处理，不受 reload 影响。
实际连接数表现：两套独立上限并存
假设原配置 worker_connections 1024，新配置改为 2048，reload 后：
- 旧 worker 最多还能处理 1024 个并发连接（含已建立连接 + 新 accept 到的连接？不，它已停止 accept）；
- 新 worker 最多可处理 2048 个并发连接，且只接收新连接；
- 总并发能力 = 旧 worker 当前活跃连接数 + 新 worker 当前活跃连接数；
-
不会出现“连接被拒绝（EMFILE）”仅因改大了
worker_connections—— 因为旧 worker 不再 accept，新 worker 的上限更高，整体承载力实际提升。
⚠️ 注意：若你把
worker_connections调小了（比如从 2048 改成 512），新 worker 虽然限制更严，但只要它能正常启动，就不会立即丢连接；只是后续新连接在新 worker 达到 512 之后才会被内核排队或丢弃（取决于listen的backlog和系统 net.core.somaxconn）。旧 worker 仍按 2048 运行至退出。
本质上，worker_connections 是每个 worker 的“连接槽位容量”，不是全局开关。热重载时的连接平稳过渡，靠的从来不是这个数字变没变，而是 Nginx 的 master-worker 协作模型和操作系统对 socket 的精细管理。
