流量镜像通过Nginx mirror指令异步复制请求至测试后端，需≥1.13.4版本，配置upstream与/mirror location，可条件触发、控制请求体传递及Host头，并注意监控、日志与安全限制。
流量镜像（Traffic Mirroring）是将生产环境的请求复制一份，发送到测试或预发布后端，而不影响原始请求响应的一种灰度验证手段。Nginx 从 1.13.4 版本起原生支持 mirror 指令，可安全、低侵入地实现该能力。
启用 mirror 指令并配置镜像上游
Nginx 的 mirror 指令必须在 location 块中使用，它会异步发起一个与原始请求方法、URI、头信息（部分）、请求体完全一致的副本请求，但不等待其响应，也不影响主流程。需注意：镜像请求默认不携带原始请求体（除非启用 mirror_request_body on），且不继承主请求的超时、重试等策略。
- 确保 Nginx ≥ 1.13.4（推荐 ≥ 1.21.0，修复了早期版本中镜像请求体丢失的问题）
- 在
http或stream块外定义镜像上游（upstream），例如：upstream mirror_backend { server 192.168.10.50:8080; } - 在目标
location中添加mirror /mirror;，并单独配置location = /mirror转发至镜像上游
控制镜像行为与请求体传递
默认情况下，Nginx 镜像请求不发送请求体（如 POST 数据），这对 API 测试可能造成偏差。需显式开启并注意内存限制：
- 在
location中添加mirror_request_body on; - 若请求体较大（如文件上传），需同步调整
client_max_body_size和client_body_buffer_size，避免因缓冲不足导致镜像失败 - 镜像请求的 Host 头默认为原始请求 Host；如需修改（例如指向测试域名），可在
location = /mirror中用proxy_set_header Host "test-api.example.com"; - 建议关闭镜像请求的响应体读取（加
proxy_buffering off;+proxy_ignore_client_abort on;），防止阻塞主流程
按条件触发镜像（如仅特定路径或 Header）
生产环境通常只需对部分接口或带特定标记的流量做镜像。可通过 mirror 指令配合变量实现条件化：
- 使用
map定义镜像开关变量，例如只镜像/api/v2/下的 POST 请求：map "$request_method:$uri" $do_mirror { "POST:/api/v2/" 1; default 0; }
然后在 location 中写：mirror $do_mirror; - 也可基于请求头判断，例如只镜像带
X-Env: staging的请求：map $http_x_env $do_mirror { "staging" 1; default 0; } - 注意：变量值为非空字符串（如 "1"）即触发镜像；空字符串或未定义则跳过
监控与安全注意事项
镜像本身不返回结果，但错误堆积或目标不可达可能引发资源泄漏或日志污染：
- 为镜像 upstream 单独配置
proxy_next_upstream error timeout http_500;和max_fails=1 fail_timeout=10s;，避免持续探测失败节点 - 建议在镜像 location 中关闭访问日志（
access_log off;），或使用独立日志文件便于排查 - 禁止将敏感接口（如支付回调、密码重置）加入镜像范围；必要时在镜像后端主动过滤或脱敏请求体
- 镜像请求不会继承原始连接的 TLS 信息（如 client cert），如测试依赖证书校验，需在镜像后端模拟或改用其他方案（如 Envoy）
