worker process 不直接处理配置指令，而是由 master 进程解析后初始化并传递参数；高频指令如 keepalive_timeout、client_header_timeout 等在事件循环中被 worker 频繁调用计时判断，reload 后新连接立即生效，但 worker_processes 等需重启才生效。
Worker Process 本身不直接“处理”配置指令，而是由 Master 进程读取并解析全部配置后，将生效的参数（如 worker_connections、use epoll、accept_mutex 等）初始化并传递给每个 Worker。所谓“高频配置指令”，实际是指那些在运行时频繁影响 Worker 行为、且需与 Worker 模型深度协同的关键参数。
高频配置指令如何影响 Worker 运行
这些指令不是 Worker 主动执行的命令，而是在启动或重载时被加载进 Worker 的运行上下文，决定其事件循环行为和资源边界：
-
events 块内的指令：如
worker_connections定义单个 Worker 能同时管理的连接上限；use epoll决定底层 I/O 多路复用机制；accept_mutex on控制新连接分发逻辑，避免惊群效应 -
全局块指令：如
worker_processes和worker_cpu_affinity决定进程数量与 CPU 绑定关系，直接影响 Worker 的调度位置和缓存局部性 -
HTTP 层超时类指令：如
keepalive_timeout、client_header_timeout、send_timeout，由 Worker 在事件循环中计时并触发连接关闭，属于运行时高频判断逻辑
哪些配置需要 Worker 频繁参与决策
以下指令会在每个请求/连接生命周期中被 Worker 反复调用或检查，属于真正意义上的“高频”：
-
keepalive_timeout：Worker 对每个空闲连接持续倒计时，超时即关闭；若启用keepalive_requests，还需计数已处理请求数 -
client_header_timeout和client_body_timeout：Worker 在接收请求头/体阶段实时监控时间，一旦超时立即中断连接 -
send_timeout：Worker 向客户端发送响应时启用计时，两次写操作间隔超时则断开 -
multi_accept on：Worker 被唤醒后一次性从内核就绪队列中取出多个连接，减少系统调用频率
修改高频指令是否需要重启 Worker
大多数高频指令属于运行时可热重载范畴，但效果生效方式不同：
-
nginx -s reload会启动新 Worker 并优雅退出旧 Worker，所有新连接自动应用更新后的keepalive_timeout、worker_connections等值 -
worker_processes、worker_cpu_affinity、use等必须重启才能生效，因为涉及进程结构和事件引擎初始化 -
client_max_body_size、client_header_buffer_size等虽属 HTTP 指令，但只在请求解析阶段使用，reload 后新请求立即生效
高频指令调优的关键注意事项
这些参数看似简单，但组合不当会引发隐性瓶颈：
- 设
keepalive_timeout过长（如 300s），而worker_connections固定，会导致大量空闲连接长期占位，挤压新连接空间 -
client_header_timeout设太短（如 5s），在弱网或含大 Cookie 的场景易触发 408 错误 - 开启
multi_accept on时，需确保系统net.core.somaxconn足够大，否则内核队列溢出，丢连接 -
send_timeout若远小于后端响应时间（如反代慢接口），可能在传输中途断开，造成客户端收不到完整响应
