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控制：- 若未开启
mirror_request_body，Nginx 不读 body，镜像请求可能丢失 POST 数据； - 若开启，则强制读取并缓存 body，此时
proxy_request_buffering自动失效，主请求也会变缓存模式（注意内存开销）。
- 若未开启
? 多镜像目标时，Worker Process 怎么处理？
可配置多个 mirror 指令（如 mirror /m1; mirror /m2;），Nginx 会为每个生成一个独立子请求：
- 所有子请求由同一个 Worker Process 并发发出（非串行）；
- 每个子请求走各自
location = /m1或/m2的 internal 分支； - 各自
proxy_pass到不同 upstream，互不影响； - 流量放大效果自然产生：1 次用户请求 → N 个镜像请求（N =
mirror指令出现次数）。
? 常见误区澄清
- ❌ Worker Process 不会“双写”或“复制 TCP 包”：这不是 tcp-copy 那类底层抓包，而是 HTTP 层语义复制；
- ❌ 不依赖多进程协作：单 Worker 即可完成主请求 + 多镜像子请求；
- ❌ 镜像失败（如 mirror 后端超时/502）完全不影响主请求，Nginx 忽略子请求所有结果；
- ❌
internallocation 不是安全隔离手段，只是防止外部直接访问，实际仍由 Worker Process 执行。
不复杂但容易忽略
