Nginx mirror指令需严格遵循三原则：必须置于location顶层（不可嵌套if/rewrite）、mirror upstream须独立配置并关闭proxy_buffering、镜像服务应快速返回204且禁用access_log。
能用，但必须绕开官方文档里没说清的三个默认行为，否则镜像流量会丢、会卡、会把上游打挂。
mirror 指令必须写在 location 块最顶层，不能嵌套在 if 或 rewrite 之后
Nginx 的 mirror 指令不参与条件判断流程，一旦被包裹在 if、rewrite 或 limit_req 块里，就会静默失效——请求根本不会发往镜像 upstream。线上曾有团队把 mirror 放在 if ($arg_debug = "1") 下，结果压测时 0% 流量被镜像，排查三天才发现是执行阶段跳过了该指令。
- 正确位置：直接写在
location / { ... }内第一级，和proxy_pass平级 - 错误写法：
if (...) { mirror /mirror; }或rewrite ^/api/(.*)$ /v2/$1 break; mirror /mirror; - 验证方法：开启
error_log /var/log/nginx/debug.log debug;，搜索mirror: enabled日志行
mirror upstream 必须用 proxy_buffering off + proxy_buffer_size 严格设小
默认开启的 proxy_buffering 会让 Nginx 缓存镜像请求的整个 body，等后端响应返回后再释放连接。这会导致镜像请求堆积、延迟飙升，甚至触发 proxy_busy_buffers_size 限制而丢包。真实压测中，某服务镜像 5% 流量就吃光 2G 缓冲区，下游压测系统收不到完整 POST body。
- 必须关闭缓冲：
proxy_buffering off;（注意：仅对 mirror location 生效，不影响主 upstream） - body 大小控制：
proxy_buffer_size 4k;+proxy_buffers 8 4k;，避免大文件阻塞 - 超时要激进：
proxy_connect_timeout 1s;proxy_send_timeout 2s;（镜像失败不应回退主链路）
mirror location 的 proxy_pass 不能指向和主服务相同的 upstream
看似省事，但共用 upstream 会导致连接复用冲突：主请求的 keepalive 连接可能被镜像请求意外复用或提前关闭。更严重的是，当镜像服务响应慢时，Nginx 会把该 upstream server 标记为 failed，连带影响主服务转发——这是生产事故高发点。
- 必须独立定义 upstream：
upstream mirror_backend { server 10.0.1.100:8080; } - 主 upstream 和 mirror upstream 的
max_fails、fail_timeout参数必须不同，建议 mirror 的max_fails=1 fail_timeout=1s - 镜像 location 中禁止使用
proxy_next_upstream，它会把失败镜像请求轮转到其他节点，污染压测数据
实际部署时，/mirror 接口要主动丢弃响应体并快速返回 204
镜像服务收到请求后，如果按常规方式处理（比如解析 JSON、查 DB、写日志），会拖慢整个 mirror 流程。Nginx 在等待镜像响应时会 hold 主请求的 connection，哪怕你配置了超时，也容易引发雪崩。
- 镜像服务应立即返回
HTTP 204 No Content，且响应头不含Content-Length或Transfer-Encoding - 所有业务逻辑异步落库，例如用 Kafka 或本地队列暂存原始 body，再由消费者处理
- 务必禁用镜像服务的 access_log：
access_log off;，否则磁盘 I/O 成为瓶颈
真正难的不是配通 mirror，而是让镜像路径不抢主路径的资源、不干扰主链路健康检查、不因镜像服务抖动导致主服务降级——这些都藏在 upstream 隔离、缓冲策略和响应协议细节里。
