校验和 incorrect 解读
抓到的包里 TCP 校验和显示 incorrect，绝大多数情况并不是真的出错，而是网卡校验和卸载造成的：抓包动作发生在硬件计算校验和之前，Wireshark 拿到的还是一个尚未填写或已被占位的值。虚拟化环境中几乎必然会看到这种现象，先查 offload 状态再谈故障，能省下大量时间。
基本信息
| 适用平台 | Linux 上的 ethtool 与 Wireshark，虚拟化与半虚拟化网卡尤甚 |
|---|---|
| 常见成因 | 发送端或接收端校验和卸载 |
| 核对命令 | ethtool -k <网卡> | grep -i checksum |
| 判断依据 | 真实错误通常伴随大量重传与设备丢弃计数 |
典型使用场景
- 避免误判：先确认网卡是否开启 offload，再决定要不要继续查
- 定位真错：关掉卸载后复抓，校验和仍然错才说明报文确实损坏
- 容器与虚机排障：虚拟网卡上的错误校验和是高发场景
- 上报材料准备：把 offload 状态一并写进报告，省掉来回确认
- 交叉验证：结合重传、丢包计数与设备日志共同判断
核验方法
核验方法
ethtool -k eth0 | grep -i checksum # 查看网卡校验和卸载开关
ethtool -K eth0 tx off rx off # 临时关闭后复抓验证，会影响吞吐
# 只看校验和异常的包
tshark -r a.pcap -Y 'tcp.checksum.status == "Bad"' | head判断对照
| 现象 | 更可能的原因 | 处理方向 |
|---|---|---|
| 几乎每个包都标错误 | 网卡校验和卸载 | 确认 offload 状态即可，无需处理 |
| 只有部分包错误 | 可能存在真实损坏 | 关卸载后复抓确认 |
| 错误伴随大量重传 | 真实丢包或乱序 | 查看重传与设备计数 |
| 虚拟网卡上普遍错误 | 半虚拟化实现的行为 | 按已知行为忽略 |
判断真伪最直接的办法是临时关闭网卡的发送与接收校验和卸载再抓一次；但关闭卸载会明显影响吞吐，只应在定位阶段使用，拿到结论后立即恢复。
抓包点位于虚拟交换机或容器桥接网络时，校验和常由软件补齐，出现错误提示的概率更高。这种情况应结合两端抓包对比，而不是拿单点数据下结论。
这个现象与 TCP 本身无关，UDP 报文同样会出现类似的校验和提示，处理思路完全一致：先排除卸载因素。