本地及生产服务器可curl目标站点，测试服务器不行，求解析tcpdump结果

看起来你遇到的是测试服务器只能访问部分站点的问题——本地和生产环境都能正常curl目标站，但测试机不行，不过它访问其他站点又没问题。结合你给出的tcpdump抓包结果，我来帮你梳理下核心问题和排查步骤：

先看抓包里的关键线索 #

你提供的SYN包记录里，最扎眼的就是TCP校验和错误：cksum 0xa9d1 (incorrect -> 0x11ef)。这意味着测试服务器发出去的TCP握手包校验和是错的，目标服务器收到后会直接丢弃，根本不会回复SYN-ACK，自然就建立不了连接，curl也就失败了。

具体排查方向 #

1. 先查网卡的TCP校验和卸载功能

现在的服务器网卡基本都支持硬件校验和卸载——让网卡硬件来计算TCP/UDP校验和，减轻CPU压力。但这个功能偶尔会抽风，导致发送的包校验和出错。

• 先看看你的网卡有没有开这个功能（以eth0为例，换成你实际的网卡名）：

  ethtool -k eth0 | grep checksum
  

• 如果看到tx-checksum-ipv4: on这类启用状态，先临时关掉试试：

  ethtool -K eth0 tx-checksum-ipv4 off
  

  关完之后再curl目标站点，同时重新抓包看看校验和是不是正常了。如果问题解决，要么是网卡驱动有bug，要么是这个功能和你的网络环境不兼容，可以考虑更新驱动或者把这个设置永久关掉。

2. 对比路由路径是否有差异

虽然测试机能访问其他站点，但目标站点可能走了不同的路由——比如专用VPN、代理，或者不同的网关。

• 对比测试机和生产/本地的路由表，看看目标站点的路由是否一致：

  # 查看目标IP的路由
  ip route get 192.175.110.124
  

• 如果路由不一样，检查是不是测试机的路由配置错了，或者中间的防火墙/路由器对测试机IP做了限制。

3. 确认目标站点的安全规则

也有可能目标站点的防火墙/安全组把测试机的IP（10.11.112.108）拉黑了，虽然抓包显示校验和错，但也不能完全排除这个可能。

• 先在测试机上用telnet试试目标端口，看有没有响应：

  telnet 192.175.110.124 443
  

• 如果telnet也没反应，联系目标站点的运维，确认测试机IP是不是在允许访问的列表里。

4. 检查系统内核或网络栈

有时候系统内核的bug、未更新的补丁也会导致TCP数据包异常。

• 对比测试机和生产机的内核版本：

  uname -r
  

• 如果版本差得比较多，试试更新最新的内核补丁，或者重启下网络服务：

  # Ubuntu/Debian
  systemctl restart networking
  # CentOS/RHEL
  systemctl restart network
  

优先级建议 #

最优先查的是校验和卸载，因为抓包已经实锤了校验和错误，这是TCP握手失败的典型原因。先把这个排查了，大概率能解决问题。

内容的提问来源于stack exchange，提问作者user6568792