Nginx 中 Worker Process 如何进行流量镜像复制

作者：袖梨 2026-08-10

Nginx流量镜像由核心在rewrite阶段末尾自动触发异步子请求，Worker Process仅执行该内建机制，不参与决策、不缓存、不等待响应；子请求复用原始请求信息并独立调度，响应被自动丢弃，主请求完全无感。

Nginx 的流量镜像（mirror）不由 Worker Process 主动“执行”复制逻辑，而是由 Nginx 核心在请求处理流程中自动触发的异步子请求机制。Worker Process 只是执行这个已内建的行为，不参与决策、不缓存、不等待镜像响应。

简单说：不是 Worker Process “去做镜像”，而是当 Worker Process 处理一个请求时，Nginx 内核根据 mirror 指令，同步派生一个后台子请求（mirror subrequest），并交由同一 Worker Process 异步发出——整个过程对主请求完全无感。

? 镜像动作实际发生在哪个环节？

Worker Process 在处理 HTTP 请求的 rewrite 阶段末尾、proxy_pass 前，检查是否配置了 mirror 指令。若存在，则：

立即创建一个内部子请求（非用户发起，无响应返回给客户端）；
子请求复用原始请求的 method、URI、headers；
若启用了 mirror_request_body on，则先完整读取并缓存请求体（此时会禁用 proxy_request_buffering off 的流式转发）；
该子请求被异步调度，由同一 Worker Process 发送到指定 mirror location（如 /mirror），再经 proxy_pass 转发出去；
主请求继续走正常 proxy_pass 流程，不受任何阻塞或延迟影响。

关键点：镜像子请求和主请求共享同一个 Worker Process，但彼此独立调度；子请求响应被 Nginx 自动丢弃，不写日志、不返回、不参与任何 upstream 负载均衡决策。

⚙️ Worker Process 相关配置注意事项

虽然镜像逻辑是自动的，但 Worker Process 的行为会影响镜像稳定性：

worker_processes auto; 或合理设置数值：避免单个 Worker 过载导致镜像请求积压（尤其高并发+大 body 场景）；
worker_connections 1024; 等需足够：镜像子请求也占用连接数，总连接数 = 主请求 + 镜像请求数 × 镜像目标数；
proxy_buffering off; 对主请求有效，但镜像请求受 mirror_request_body 控制：
1. 若未开启 mirror_request_body，Nginx 不读 body，镜像请求可能丢失 POST 数据；
2. 若开启，则强制读取并缓存 body，此时 proxy_request_buffering 自动失效，主请求也会变缓存模式（注意内存开销）。