压测这件事，用ab或者jmeter模拟出来的流量，再怎么调参数也和真实用户的访问模式差那么一口气：请求分布不均、长尾连接、异常包、突发峰值，这些只有线上才有的特征很难凭空造出来。tcpcopy解决了这个痛点，它可以把生产环境Nginx服务器上收到的真实请求数据包原样复制一份，投递到测试机上，让新版本代码吃真实的流量。整个过程对线上服务几乎零侵入，测试机的应答也不会回流到真实用户。下面详细讲解原理、部署和常见坑。
tcpcopy的工作原理与架构组成
tcpcopy由两个组件构成，这是理解它的关键。第一个组件叫tcpcopy本身，部署在生产服务器上（也就是跑Nginx的那台机器），它的职责是通过抓包的方式截获本机对外提供服务的TCP请求数据包，把这些包复制一份后转发给测试机。第二个组件叫intercept，部署在测试服务器上，负责拦截测试机发出的应答包（也就是响应给伪造客户端的回包），并在应答包中提取必要的信息回传给生产机上的tcpcopy，帮助tcpcopy维持TCP状态机的正确运转。
整个数据流向是这样的：用户请求到达Nginx所在的生产机，tcpcopy抓到请求包后，将源IP地址改写为保留的真实用户IP，然后通过路由把副本包送到测试机。测试机上的应用（比如另一套Nginx+PHP-FPM）处理完请求后，会把应答发往那个被伪造的源IP。此时intercept在工作于ip_queue或者nfqueue模式下拦截这些应答，向tcpcopy回送路由信息，同时把应答包丢弃，不让它真正走出测试机。这样设计的好处是：真实用户完全感知不到复制行为，测试机上的回包也不会污染网络。
需要注意tcpcopy有离线和在线两种模式。在线模式是实时复制线上流量；离线模式则可以先用tcpdump抓取pcap文件，再通过tcpcopy回放，适合不方便在生产机上装软件的场景。另外从1.0版本开始，tcpcopy默认采用新架构（使用raw socket发送），不再依赖pcap库，性能和部署难度都改善了不少。
生产机与测试机的安装部署步骤
先在生产机上编译安装tcpcopy。下载源码后标准的configure、make、make install三步走即可，示例中使用1.2版本的目录名，请根据实际下载的版本调整路径：
cd /usr/local/src wget https://github.com/session-replay-tools/tcpcopy/archive/refs/tags/1.2.0.tar.gz -O tcpcopy-1.2.0.tar.gz tar zxvf tcpcopy-1.2.0.tar.gz cd tcpcopy-1.2.0 ./configure --prefix=/usr/local/tcpcopy make && make install # intercept同样需要编译，下载地址类似 wget https://github.com/session-replay-tools/intercept/archive/refs/tags/1.2.0.tar.gz -O intercept-1.2.0.tar.gz tar zxvf intercept-1.2.0.tar.gz cd intercept-1.2.0 ./configure --prefix=/usr/local/intercept make && make install
生产机上还需要调整内核参数。tcpcopy修改包源IP后，内核可能会发送RST包中断复制的连接，因此要把当前连接的rp_filter关掉，最稳妥的做法是编辑/etc/sysctl.conf，加入net.ipv4.conf.all.rp_filter = 0，然后执行sysctl -p生效。如果只针对单个网卡设置，可以把all换成具体网卡名，比如eth0。
测试机上除了安装intercept，还要加一条路由，把发往伪造源IP段的包导向回环地址，让应答包留在本机交给intercept处理。假设线上用户IP分布很广，最简单的做法是给整个公网段加路由：
# 测试机上执行：将应答包路由到lo，交给intercept拦截 route add -net 0.0.0.0 netmask 0.0.0.0 gw 网关内网IP dev eth0 # 常见简化写法：只针对来源IP段加路由 route add -net 111.0.0.0 netmask 255.0.0.0 dev lo
两台机器都准备好后，按顺序启动。必须先在测试机上启动intercept，再到生产机上启动tcpcopy，顺序反了会导致复制连接建立失败。
# 测试机：监听队列，拦截应答 /usr/local/intercept/sbin/intercept -i eth0 -F
# 生产机：复制本机80端口的请求，发往测试机10.0.1.20的80端口 /usr/local/tcpcopy/sbin/tcpcopy -x 80-10.0.1.20:80 -c 192.168.100.x
上面-x参数的格式是本地端口-目标IP:目标端口，-c参数指定伪造的源IP地址段，这样测试机上看到的请求源IP就是192.168.100.x这个网段的地址，方便在Nginx日志里区分真实流量和复制流量。验证是否生效，直接看测试机的Nginx访问日志有没有源源不断的请求进来，或者用tcpdump -i lo port 80观察回环上的流量。
实际使用中的常见问题与调优
第一个高频问题是测试机应答干扰线上。表现为用户收到重复响应或线上出现异常连接，原因多半是测试机的路由没配对，应答包真实发出去了。排查思路是在测试机上抓包，确认应答包是否只出现在lo口。如果使用了-c参数统一伪造源IP，只需针对该网段加一条指向lo的路由即可，比全网段路由安全得多，推荐用这种方式。
第二个问题是丢包。线上QPS高的时候，tcpcopy的抓包和转发能力可能跟不上，包在复制过程中丢失，测试机上看到的请求数明显少于线上。可以从几个方向缓解：一是升级到新架构版本，raw socket模式丢包率更低；二是用-n参数控制放大倍数之外，用--connflood、--tuned等参数做性能调优；三是确认生产机的net.core.rmem_max、net.core.netdev_max_backlog等内核缓冲区参数足够大，避免内核层面就丢包。
第三个问题是日志与业务副作用。复制过来的请求是真实用户发起的，测试机处理时会真实写数据库、发短信、调用第三方支付。这在生产数据安全上是灾难，务必在测试机上做请求隔离：要么把应用指向独立的测试数据库，要么在代码层面根据来源IP网段判断后走mock逻辑。Nginx侧也可以给复制流量单独打标记，方便日志统计和后续清理。另外可以按需控制复制比例，比如只需要百分之一的流量时，用-n 0.01参数即可，不必全量复制。
最后提一句适用边界：tcpcopy工作在四层，对于HTTPS流量，生产机上抓到的已经是TLS握手和密文，测试机没有对应证书私钥无法解密，所以它只适合明文HTTP或者在后端解密的场景。如果站点已全站HTTPS，可以考虑在Nginx七层做镜像，或者结合Nginx本身的mirror模块配合tcpcopy使用：mirror在应用层复制请求，tcpcopy复制TCP层流量，两者各有取舍。理解了这些限制和搭配方式，就能搭出一套既真实又安全的引流测试环境，让每次发版前的验证都有底气。