服务器网络故障排查实战：tcpdump抓包分析与连通性诊断

服务器网络故障是运维工作中最高频的问题类型。从应用层超时到链路层丢包，故障定位往往需要跨多层协议栈分析。tcpdump作为Linux下最强大的网络抓包工具，配合连通性检测命令，能覆盖绝大多数网络故障的诊断场景。以下是从故障现象到根因定位的完整排查流程。

网络连通性分层检测方法

网络故障排查遵循OSI模型从下到上的顺序。物理层和链路层先确认网卡状态和ARP表，网络层检查路由和ICMP连通性，传输层用tcpdump验证TCP握手和数据传输，应用层检查端口监听和DNS解析。

基础连通性检测命令链：

# 1. 检查网卡状态与链路
ip link show eth0
ethtool eth0 | grep -i speed
ethtool eth0 | grep -i link

# 2. 检查IP地址与路由表
ip addr show eth0
ip route show
ip route get 8.8.8.8

# 3. ARP表检查（同子网通信）
arp -n
ip neigh show

# 4. ICMP连通性测试
ping -c 4 -W 2 8.8.8.8
ping -c 4 -s 1400 -M do 8.8.8.8  # MTU探测

# 5. 端口连通性测试
nc -zv target_host 443 -w 5
traceroute -T -p 443 target_host

# 6. DNS解析检查
dig +short example.com
dig +trace example.com
nslookup example.com 8.8.8.8

tcpdump抓包过滤与实操

tcpdump通过BPF（Berkeley Packet Filter）表达式过滤网络流量。掌握过滤器语法是高效抓包的关键。

常用过滤表达式：

# 按主机过滤
tcpdump -i eth0 host 192.168.1.100
tcpdump -i eth0 src 192.168.1.100
tcpdump -i eth0 dst 10.0.0.50

# 按端口过滤
tcpdump -i eth0 port 443
tcpdump -i eth0 src port 8080 and dst port 80

# 按协议过滤
tcpdump -i eth0 tcp
tcpdump -i eth0 icmp
tcpdump -i eth0 'tcp[tcpflags] & tcp-syn != 0'  # 只抓SYN包

# 组合过滤：抓取特定主机到特定端口的TCP流量
tcpdump -i eth0 -nn 'host 192.168.1.100 and port 443 and tcp'

# 排除SSH自身流量
tcpdump -i eth0 'not port 22'

抓包结果写入文件供Wireshark分析：

tcpdump -i eth0 -w /tmp/capture.pcap \
    'host 192.168.1.100 and port 443' \
    -c 1000 -s 0

参数说明：-w写入pcap文件，-c限制抓包数量，-s 0抓取完整数据包（默认只抓68字节）。

TCP连接异常抓包分析

以”连接超时”为例，通过tcpdump定位是 SYN被丢弃、SYN-ACK未返回、还是RST重置：

# 抓取与目标主机的所有TCP握手包
tcpdump -i eth0 -nn 'host 10.0.0.50 and tcp[tcpflags] & (tcp-syn|tcp-ack|tcp-rst) != 0'

正常TCP握手应看到三步：SYN → SYN-ACK → ACK。异常情况分析：

# 异常1：SYN发出但无SYN-ACK返回
# 可能原因：目标端口未开放、防火墙DROP、路由不可达
10.0.0.1.54321 > 10.0.0.50.443: Flags [S], seq 123456
# 等待超时后重传
10.0.0.1.54321 > 10.0.0.50.443: Flags [S], seq 123456
# 无任何响应 -> 防火墙DROP或路由问题

# 异常2：收到RST
10.0.0.1.54321 > 10.0.0.50.443: Flags [S], seq 123456
10.0.0.50.443 > 10.0.0.1.54321: Flags [R.], seq 0, ack 123457
# RST表示端口未监听或被REJECT

# 异常3：握手完成但数据传输时RST
10.0.0.1.54321 > 10.0.0.50.443: Flags [S.], seq 123
10.0.0.50.443 > 10.0.0.1.54321: Flags [S.], seq 456, ack 124
10.0.0.1.54321 > 10.0.0.50.443: Flags [.], ack 457
10.0.0.50.443 > 10.0.0.1.54321: Flags [R.], seq 457
# 可能原因：中间设备超时丢弃、应用层异常关闭

丢包与重传分析

网络丢包会导致TCP重传，严重时引发应用超时。通过tcpdump统计重传率：

# 抓取所有重传包
tcpdump -i eth0 -nn 'tcp[tcpflags] & tcp-ack != 0 and tcp[tcpflags] & tcp-push != 0' -w /tmp/retransmit.pcap

# 使用capinfos或tshark分析重传统计
tshark -r /tmp/retransmit.pcap -Y "tcp.analysis.retransmission" -T fields \
    -e ip.src -e ip.dst -e tcp.seq -e frame.time_relative

重传率超过1%通常意味着网络质量问题。常见根因：网卡队列溢出、交换机缓冲区不足、MTU不匹配导致分片丢包。

检查网卡丢包统计：

# 查看网卡丢包计数
ip -s link show eth0
ifconfig eth0 | grep -i "drop\|error\|overrun"

# 查看网卡队列丢弃
ethtool -S eth0 | grep -i "drop\|discard"

# 检查软中断处理速率
cat /proc/net/softnet_stat
# 第一列：处理的数据包总数
# 第二列：丢弃的数据包数
# 第三列：因非NAPI导致的丢包

DNS解析故障排查

DNS解析失败会导致域名无法访问但IP直连正常。排查步骤：

# 1. 检查resolv.conf配置
cat /etc/resolv.conf
# 确认nameserver指向有效DNS服务器

# 2. 测试DNS解析延迟
dig example.com | grep "Query time"
# 正常应<50ms，超过500ms需排查

# 3. 对比不同DNS服务器
dig @8.8.8.8 example.com +short
dig @114.114.114.114 example.com +short
dig @127.0.0.1 example.com +short

# 4. 抓取DNS报文分析
tcpdump -i eth0 -nn 'port 53' -c 20

# 5. 检查nscd缓存是否导致脏数据
nscd -g  # 查看缓存统计
nscd -i hosts  # 清除hosts缓存

conntrack表满导致连接异常

高并发服务器常见conntrack表满会导致新连接被丢弃，表现为间歇性连接超时：

# 查看conntrack使用量
cat /proc/sys/net/netfilter/nf_conntrack_count
cat /proc/sys/net/netfilter/nf_conntrack_max

# 计算使用率
current=$(cat /proc/sys/net/netfilter/nf_conntrack_count)
max=$(cat /proc/sys/net/netfilter/nf_conntrack_max)
echo "conntrack usage: $((current * 100 / max))%"

# 如果使用率超过80%，需要调大max值
echo 262144 > /proc/sys/net/netfilter/nf_conntrack_max
# 永久生效
echo "net.netfilter.nf_conntrack_max = 262144" >> /etc/sysctl.conf
sysctl -p

conntrack表满的典型特征：dmesg中出现"nf_conntrack: table full, dropping packet"日志，且应用层出现随机连接超时。调整max值后需同步调整hashsize（建议max/hashsize = 4）：

echo 65536 > /sys/module/nf_conntrack/parameters/hashsize

排查流程总结

服务器网络故障的排查遵循"分层定位、逐层排除"的原则。物理层看网卡状态和错误计数，链路层看ARP和MAC地址表，网络层看路由和ICMP，传输层用tcpdump抓包分析TCP状态机，应用层检查端口监听和DNS。80%的网络故障可通过ping、traceroute、tcpdump三个工具定位到具体环节。关键是在排查前明确故障影响范围——是单机还是批量、是单向还是双向、是间歇还是持续，这决定了排查的起点和方向。