不支持直接克隆数据库流量——stream_mirror是Nginx 1.19.4+的stream模块功能，仅支持TCP/UDP单向镜像复制，不解析应用层协议，无法识别MySQL等数据库的query包边界，镜像端因缺少握手响应或状态交互会断连。
Stream-Mirror模块是否支持数据库流量克隆
不支持直接克隆数据库流量——stream_mirror 是 Nginx 1.19.4+ 引入的 stream 模块功能，仅作用于 TCP/UDP 流量的**单向镜像复制**，但它**不解析应用层协议**，也不维护连接状态。对 MySQL、PostgreSQL 等数据库流量，它能转发原始字节流，但无法识别 query、响应包边界，更不能做语义审计。
常见误判是以为开启 stream_mirror 就能“旁路抓包式审计”，实际它只是把一份 TCP 数据包副本发给镜像 upstream，而数据库客户端/服务端通常依赖连接上下文（如 handshake、auth token、sequence ID），镜像端若无对应服务接收并模拟交互，连接会立即中断或触发 RST。
- MySQL over TCP：镜像端收不到合法 initial handshake response，直接断连
- PostgreSQL：镜像端未发送 StartupMessage 回应，backend 关闭连接
- Redis：虽为纯文本协议，但镜像端若不回送 +OK/-ERR，client 侧超时失败
真正可行的异步克隆方案：tcpdump + socat + 自定义解析器
要实现对数据库流量的**无侵入、异步、可审计**克隆，必须绕过 Nginx stream 层限制，改用链路层/网络层捕获。核心思路是：在数据库服务器网卡上抓包 → 实时转发到分析服务 → 原始流量不经过任何代理节点，避免引入延迟或状态干扰。
典型组合命令：
tcpdump -i eth0 -s 0 -w - 'port 3306 and tcp[12] & 0xf0 > 0x50' | \ socat -t 0 -u - tcp4:audit-server:8080
说明：
-
tcpdump中tcp[12] & 0xf0 > 0x50过滤出含 payload 的 TCP 包（跳过 SYN/ACK/empty ACK），减少无效转发 -
socat使用-u单向模式，避免反向阻塞；-t 0禁用超时，防止长连接中断 - 审计服务需自行解析 MySQL protocol packet（如解析
COM_QUERY、提取user@host、SQL 文本、执行耗时等）
为什么不能用 Nginx stream_proxy + mirror 同时转发
有人尝试这样配置：
stream {
server {
listen 3307;
proxy_pass db_real;
mirror mirror_server;
}
server {
listen 12345;
proxy_pass audit_handler;
}
}这看似“双发”，但实际会失败，因为：
-
mirror在 stream 模块中仅支持 HTTP 协议（Nginx 官方明确限定），对非 HTTP 流量，mirror指令会被忽略，且不报错 - 即使强制启用（通过 patch 或旧版 hack），镜像连接无法复用主连接的 TLS session key，导致 TLS 握手失败（MySQL 8.0+ 默认 require TLS）
- 主连接和镜像连接共用同一个 client fd，Nginx 无法对 TCP 流做无损分帧，镜像端收到的是粘包或半包数据
审计服务接收端的关键处理点
镜像流量不是标准数据库连接，接收端不能用 mysql -h 或 psql 直连。必须自己实现协议解析层：
- MySQL：按 Client/Server Protocol 解析 packet length（前 3 字节）、sequence ID、command type
- 必须忽略 server handshake、不发送 auth response，只做 read-only 解析；否则会污染真实连接状态
- 建议加一层 ring buffer + 多线程 parser，避免
tcpdump突发包导致丢帧 - SQL 文本提取后，需过滤敏感字段（如
PASSWORD、SET PASSWORD），避免审计日志泄露凭据
真正难点不在克隆，而在如何从裸 TCP 流中稳定还原出逻辑 SQL 事件——这需要理解协议分帧逻辑，而不是依赖 Nginx 的“透明”假象。
