通过对比清洗前后的抓包文件，能直观暴露防护策略的三大类问题：攻击特征是否被精准识别、回源链路是否安全、业务协议是否被误伤。抓包是网络排障的“透视镜”，清洗前后的数据差异，往往比防护报表更能反映真实防护水平。
清洗前抓包和清洗后抓包有什么区别
理解清洗前后的差异,先要搞明白流量路径，正常情况下，用户请求先到达高防节点，防护系统过滤攻击流量后，再把“干净流量”回源到你的服务器，所以清洗前的抓包，抓的是高防节点入口的流量；清洗后的抓包，抓的是回源链路上的流量。
两者对比的核心逻辑就一句话：入口有、回源无的，是攻击流量；入口有、回源也有，但表现异常的，是清洗策略误伤了正常业务。
举个例子,你在一台服务器上执行抓包命令，分别在高防入口镜像口和源站服务器网卡上抓取一分钟的流量，对比后发现，入口处有大量SYN包只发不收，回源侧却完全没有这些连接记录，这说明清洗设备把SYN Flood挡在了门外，回源链路是干净的，反之，如果回源侧出现了大量TCP重传或RST包，那就说明清洗策略可能把正常连接也给切断了。
看报文特征：清洗掉了什么，放过了什么
抓包对比的第一个重点,是观察IP和TCP/UDP层的报文特征，攻击流量和正常流量在报文层面有非常明显的差异，清洗前后一对比，就能看出防护设备有没有“对症下药”。
攻击IP的分布变化
清洗前的抓包里,源IP通常呈现两个极端：要么是高度集中的少量IP在拼命发包，要么是极度分散的大量IP低频请求，集中型相对好处理，防护设备基于IP黑名单或速率限制就能解决，分散型则需要依赖行为分析，比如统计每个IP的请求频率、连接数等。
清洗后的抓包里,如果攻击源IP依然出现，说明防护策略没有生效，更隐蔽的情况是：IP变了，但报文特征没变，比如攻击者换了IP段，手法还是老一套，清洗设备却没有识别出来，所以单纯看IP维度是不够的，还要看握手特征。
标志位和重传行为
TCP报文头的SYN、ACK、RST标志位组合，能告诉你一个连接的状态，SYN Flood最典型的特征，是短时间大量SYN报文，没有对应的ACK应答，源IP随机分布，对比清洗前后，如果回源侧看不到这些SYN洪流，说明防护把攻击拦在了源头。
但有时候清洗后的抓包会暴露另一个问题防护设备把正常的TCP连接也重置了，你会看到回源侧出现大量RST包，导致客户端不断重连，这种情况常见于清洗设备的连接跟踪表被攻击流量打满，触发了过载保护，开始丢新建连接，业内专家指出，连接跟踪表溢出是清洗设备最常见的一种“副作用”。
七层攻击的报文特征
如果是CC攻击或者应用层攻击,抓包对比的视角就要从传输层切到应用层，清洗前，抓包里每个请求看起来都是“合规”的，请求路径正常，UA正常，但频率极高，清洗后，如果这些高频请求依然到达源站，说明防护设备没有启用七层HTTP指纹校验或人机识别。
一个典型的判断方法是：在回源侧抓包，统计同一IP的请求QPS，如果清洗后单个IP还能做到每秒几十次请求，那防护策略基本形同虚设。
看回源链路：源站是否还暴露在危险里
清洗前后的抓包对比,另一个关键价值是检验回源链路的安全性，很多防护问题不在清洗设备本身，而在回源环节。
回源IP是否绕过防护
最危险的一种情况是：攻击者搞到了你的源站IP，直接绕过高防打源站，这种情况下，清洗前后的抓包对比会出现一种诡异的现象清洗前没有攻击流量，清洗后源站被打得更狠了，因为高防把所有正常流量回源，反而暴露了源站IP。
判断方法很简单：在清洗前（未启用高防时）和清洗后（启用高防后）分别抓包，对比源站IP收到的攻击流量来源，如果清洗后的抓包里出现了大量直连源站IP的恶意请求，并且这些请求的源IP与高防回源IP段明显不同，那基本可以确定源站IP已泄露。
回源端口和SNI策略
如果高防只做了端口转发,比如把80端口回源到源站8080端口，抓包对比时要注意回源报文的目的端口，入口流量和回源流量端口不一致是正常的，但有些配置疏漏，比如回源线路未做传输加密，抓包里能看到HTTP明文请求，这意味着用户和源站之间的链路可能被中间人窥探。
另一种常见问题是SNI（服务器名称指示）策略，当高防节点将HTTPS请求转发到源站时，需要正确传递SNI，否则源站上的Nginx会返回403或4xx错误，清洗后的抓包里如果出现大量TLS握手失败或证书错误提示，就需要检查回源SNI配置。
看协议行为：TCP连接建立方式上的异常
除了四层和七层的常规对比,协议行为层面的差异能反映出更隐蔽的防护问题。
SYN重传与队列溢出
正常TCP握手是三次握手,SYN发出后等待SYN-ACK，清洗后的抓包若发现源站持续向高防回源IP发送SYN，且多次重传却没有收到响应，说明回源链路的SYN队列积压严重，这种情况通常发生在清洗设备处理能力不足，或者回源线路拥堵时。
从抓包里看具体表现,就是抓包文件里同一对IP+端口的SYN包出现了三次以上，且每次重传间隔逐步拉长，对比清洗前的入口抓包，入口处并没有这么多SYN重传，说明问题出在清洗设备和源站之间。
时间戳和TCP Options差异
TCP时间戳是抓包对比中容易被忽略的字段,攻击者发送的SYN包通常不带时间戳选项或者时间戳异常，清洗后的抓包里若发现大量异常时间戳的报文，说明防护设备的TCP协议栈没有对报文做“规范化”处理。
行业共识认为,防护设备对TCP报文的规范化处理能力，是衡量其性能的重要指标，正常的高防清洗应该会把非标准的TCP报头参数修正后再回源，如果原样转发，源站服务器内核可能直接丢弃这些报文，导致用户端表现为“打不开网站”。
高防IP清洗效果怎么看的实操清单
说了这么多理论,实际操作抓包对比的步骤是这样的：
- 准备抓包工具：在源站服务器上执行
tcpdump -i eth0 -w /data/after.pcap port 80，先抓清洗模式下回源侧的包。 - 对比基准：临时将解析切回裸IP（或者在一台没有接入高防的测试机器上），执行同样的抓包命令，获得清洗前的对照包。
- 切换流量：将域名解析指向高防IP，等流量稳定后停止抓包。
- 逐一对比：用Wireshark打两个pcap文件，按以下维度逐项核对TCP连接的完整性、SYN重传率、RST包占比、源IP的分布、HTTP状态码统计。
如果业务是HTTPS,还需要额外导出TLS握手日志，对比清洗前后握手成功率，实际案例里，有用户反映“接入高防后网站偶尔卡顿”，通过抓包对比发现，高防回源时复用了TCP连接，但未正确处理keep-alive，导致源站Nginx频繁报错upstream prematurely closed connection。
费用预算上,企业按年付费时一般会关注高防IP多少钱，但实际上一次性抓包排查的运维成本，可能比防护服务本身更值得投入，与其盲目听信防护厂商的“攻击拦截报告”，不如自己动手抓包看真实数据。
常见误区：哪些情况不是防护的问题
抓包对比能发现问题,但也容易制造冤案，以下这些情况经常被误判为清洗设备故障：
- 攻击结束后的一段时间内,回源侧仍能抓到零散的SYN包，这通常是网络中有僵尸主机还在重发攻击包，属于攻击链路的“残留流量”，并非清洗失效。
- 源站带宽被打满导致的丢包,抓包里看到大量TCP重传，但实际上是源站服务器的带宽瓶颈造成的，跟清洗设备无关，把抓包文件按时间轴摊开，如果重传现象是持续性的而不是清洗切换时才爆发，更可能是源站容量问题。
- 不同ISP线路的回源路径差异,北方用户和南方用户走的高防节点不同，回源线路质量也不同，抓包对比时看到延迟差异是正常的，如果你在成都高防机房和上海高防机房分别接入同一源站，抓包数据显示的RTT差异可能很大，这不是防护策略问题，而是物理距离决定的。
防护问题排查中，抓包对比的核心结论
清洗前后的抓包对比,核心价值在于把“防护效果”从一个抽象概念变成一组可见、可验证的报文数据，它能看到三类问题：策略命中准不准、源站暴露面大不大、业务连接稳不稳。
每次接入或调整高防服务后，做一次清洗前后的抓包对比，是成本最低但最有效的防护验收手段。 这一点值得写进每个站长的上线检查清单，抓包文件骗不了人，防护效果好不好，报文里写得很清楚。
清洗前后抓包对比能看出哪些防护问题的常见问答
问：清洗前后的抓包对比必须用同样的抓包工具吗？
不需要完全一致，但需要保证抓包位置和时长的可比性，建议都使用tcpdump命令，抓取至少10分钟以上的流量，并记录当时的业务并发量，如果清洗前后的业务量本身变化巨大，对比结果没有参考意义。
问：如果抓包显示清洗后正常流量也丢了，该怎么定位？
先看丢包发生在哪个TCP层，如果是三次握手阶段的SYN包丢失，优先排查清洗设备的并发连接数和连接跟踪表是否达到上限，如果是应用层请求发送后没有响应，检查回源地址的端口连通性和源站防火墙规则，将抓包结果与高防控制台的回源日志交叉比对，可以找到丢包的具体环节。
问：有没有更简单的方式判断清洗效果，而不必手动抓包？
部分高防服务商提供流量镜像功能，可以实时转发回源流量到自建的分析平台，或者在源站上使用nginx配合实时抓包工具，将流量摘要输出到访问日志，手动抓包依然是排查复杂问题时最可靠的方式，适合在攻击发生或业务异常时临时进行。