Nginx多进程不直接分配路由任务，路由由各worker独立完成全链路决策；location匹配、rewrite、proxy_pass等均在单个worker内执行，配置全局同步确保一致性。
Nginx 多进程架构本身不直接“分配路由任务”，它不解析 URL 路径、不判断 location 匹配逻辑、也不决定请求该进哪个 upstream。真正的路由分发由单个 worker 进程内部完成，而多进程的作用是让多个 worker 同时、并行、无干扰地各自执行这套完整路由逻辑。
每个 worker 独立完成全链路路由决策
当客户端连接到达，由某个 worker 接收后，该 worker 就全程负责这个请求的：监听套接字读取 → HTTP 解析 → location 匹配 → rewrite 重写 → proxy_pass 转发 → 缓存查找/写入 → 响应组装与发送。整个过程不跨进程，也不依赖其他 worker。
- location 块匹配完全在当前 worker 内完成，基于配置树做最长前缀或正则匹配，不共享、不协商
- rewrite 指令（如 rewrite ^/api/(.*) /$1 break;）在同一 worker 内即时生效，修改后的 URI 继续参与后续匹配
- proxy_pass 引用的 upstream 名称（如 http://backend）在 worker 初始化时已加载为内存结构，转发目标由 upstream 策略实时计算（如 least_conn）
多进程如何间接提升路由效率
虽然路由逻辑不跨进程协作，但多进程模型通过资源隔离和并发能力，让路由处理更稳定、更可扩展：
- worker_processes auto 配合 worker_cpu_affinity auto，使每个 worker 绑定独立 CPU 核心，避免 cache line 争抢，location 匹配和正则计算更快
- multi_accept on 让一个 worker 在一次 epoll_wait 后尽可能多地 accept 新连接，减少“惊群”带来的重复匹配开销
- 每个 worker 拥有独立的连接队列与内存池，大量并发请求进来时，不同 worker 同时匹配不同请求的 location，整体吞吐线性提升
路由一致性靠配置全局同步，而非进程协同
所有 worker 进程启动时，从 master 进程继承完全相同的配置副本（包括所有 server、location、upstream 块），因此它们对同一请求的路由行为天然一致：
- master 在 reload 时校验新配置语法，只有全部通过才 fork 新 worker；旧 worker 和新 worker 不会同时运行不同配置
- upstream 中的 ip_hash 或 least_conn 等策略由每个 worker 独立执行，但由于共享同一份 server 列表和权重参数，结果等价于集中式调度
- 涉及状态协同的场景（如 limit_req 使用 shared memory zone），由 master 预分配共享区，worker 通过原子操作更新计数器，保证限流/路由分流逻辑全局有效
典型路由分发配置的关键点
实际部署中，路由分发效果取决于配置层级是否合理，而非 worker 数量多少：
- server 块定义监听地址和 host 匹配，是第一层入口筛选
- location 块按顺序或优先级匹配路径，建议用 = 精确匹配静态资源，^~ 快速前缀匹配 API，~* 处理大小写无关正则
- proxy_pass 必须引用已定义的 upstream 名称，不能写死 IP；若需动态路由（如按 path 分发到不同后端），可用 map 指令预生成变量，再在 proxy_pass 中引用
- rewrite 应放在 location 内部，并注意 break 与 last 的语义区别：break 终止当前 location 再匹配，last 重新发起全路径匹配
