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 负载均衡决策。

Nginx Hosting

通过服务器本地nginx实例实现零认证静态游戏托管。作为所有浏览器游戏的主要部署方式，无需登录、无需令牌、无需用户操作。

下载

---

⚙️ 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 忽略子请求所有结果；
• ❌ internal location 不是安全隔离手段，只是防止外部直接访问，实际仍由 Worker Process 执行。

不复杂但容易忽略