Nginx mirror模块实现流量镜像的核心是无感知复制请求至镜像服务且不影响主链路，原生mirror指令（1.13.4+）轻量可靠但功能有限，第三方模块或OpenResty可支持条件镜像、多目标、请求改写及异步发送等高级能力。
使用 Nginx 的 mirror 模块做流量回放压测，核心在于“不干扰线上、复制真实请求、异步转发到影子服务”，而非直接把生产流量打到测试环境。它不是全链路压测，但轻量、低侵入、可快速验证接口兼容性和性能水位。
mirror 模块怎么做到“无损”？
所谓无损，是指对原始请求的响应路径完全透明：客户端发一个请求，Nginx 正常处理并返回，同时在后台悄悄复制一份（含 headers、body、method、query），发给镜像上游——整个过程不增加主链路延迟，也不依赖客户端重试或改造。
关键点：
- mirror 请求是异步非阻塞的，失败不影响主流程
- 默认只复制 GET/HEAD 请求；若需 POST/PUT，必须显式开启
mirror_request_body on - 镜像请求的 URI 可重写（如加前缀 /mirror），便于影子服务识别和分流
- 原始响应头、状态码、Body 不受 mirror 行为影响
最小可行配置示例
以下是一个可直接运行的 Nginx 配置片段（假设线上服务跑在 http://backend，影子服务在 http://shadow-backend）：
upstream backend {
server 127.0.0.1:8080;
}
<p>upstream shadow-backend {
server 127.0.0.1:8081;
}</p><p>server {
listen 80;
location / {</p><h1>主请求走线上</h1><pre class="brush:php;toolbar:false;"> proxy_pass http://backend;
# 同时镜像一份（带 body）
mirror /mirror;
mirror_request_body on;
# 镜像请求的内部 location
location = /mirror {
internal; # 仅限内部调用，禁止外部访问
proxy_pass http://shadow-backend$request_uri;
proxy_pass_request_body on;
proxy_set_header X-Mirror-Original-URI $request_uri;
proxy_set_header X-Mirror-Original-Method $request_method;
}
}
}
注意：internal 必须加，否则可能被恶意触发镜像；$request_uri 包含 query string，比 $uri 更完整。
影子服务要配合做什么？
影子服务不是简单复刻线上逻辑，它需要具备几个关键能力：
-
识别镜像流量：通过
X-Mirror-Original-*等自定义 header 判断是否为回放请求，避免写入真实数据库或触发通知 -
隔离数据源：连接独立的影子库、缓存实例，或在 SQL 中自动改表名（如
user → user_shadow） - 记录与反馈：记录镜像请求的响应时间、状态码、错误堆栈，供后续比对分析（例如用 ELK 或 Prometheus + Grafana 聚合）
- 不返回响应给 Nginx：mirror 请求的响应体被 Nginx 自动丢弃，影子服务只需完成处理即可，无需构造 HTTP 响应内容
压测中容易踩的坑
实际部署时常见问题：
-
POST/JSON 请求 body 丢失：未开启
mirror_request_body on，或前端用了Transfer-Encoding: chunked（mirror 模块不支持分块传输） -
镜像请求超时拖慢主流程：虽然 mirror 是异步的，但如果系统负载高、影子服务响应慢，可能耗尽 Nginx 的 worker_connections，建议设置
proxy_read_timeout和proxy_connect_timeout在 /mirror 块内 - HTTPS 流量无法镜像：mirror 模块工作在七层，能处理 HTTPS 解密后的明文请求；但如果你的 Nginx 不终止 TLS（即透传到后端），那它根本看不到请求内容，也就无法 mirror
- Cookie 或 Token 泄露风险：镜像请求携带了全部原始 header，包括敏感认证信息，务必确保影子服务网络隔离、日志脱敏、且不持久化用户凭证
这套方案不依赖复杂中间件，适合中小团队快速落地。重点不在“回放得多全”，而在于“每次变更都能用真实流量过一遍”。真正上线前，比任何模拟脚本都更有说服力。
