Linux网络连接异常排查：从网卡到应用层的全链路诊断

服务器网络故障是运维工作中最高频的问题类型之一。一个HTTP请求从客户端发出到服务端响应，中间经过DNS解析、TCP握手、数据传输、应用处理等多个环节，任何一个环节出错都会导致连接异常。系统化的排查方法能快速定位故障点，缩短服务恢复时间。

网卡与物理链路层排查

排查网络问题的第一步是确认物理链路状态。网线松动、交换机端口故障、网卡驱动异常都会导致链路层不通。通过ethtool命令可以快速查看网卡的工作状态、速率和双工模式。

# 查看网卡链路状态
ethtool eth0

# 输出示例
# Settings for eth0:
#     Speed: 10000Mb/s
#     Duplex: Full
#     Link detected: yes

# 查看网卡详细统计信息（错误包、丢包等）
ethtool -S eth0 | grep -E "rx_|tx_"

# 关键指标
# rx_crc_errors: CRC校验错误，通常由网线质量问题导致
# rx_dropped: 接收丢包，可能由内核缓冲区溢出引起
# tx_dropped: 发送丢包，可能由发送队列拥塞导致

如果Link detected为no，说明物理链路未连通，需要检查网线、交换机端口和网卡状态灯。如果链路已连通但存在大量rx_crc_errors，更换网线或检查交换机端口配置。rx_dropped持续增长时，需要调大网卡接收环形缓冲区。

# 查看当前环形缓冲区大小
ethtool -g eth0

# 调大环形缓冲区（需先确认硬件支持的最大值）
ethtool -G eth0 rx 4096 tx 4096

# 确认修改生效
ethtool -g eth0

TCP连接状态分析

应用层网络故障的排查核心在于TCP连接状态。通过ss命令（替代已弃用的netstat）可以查看当前所有TCP连接的状态分布，快速发现异常连接堆积。

# 统计各状态TCP连接数量
ss -s

# 查看所有ESTABLISHED连接
ss -tnp state established | head -20

# 查看TIME_WAIT连接数量（过多会导致端口耗尽）
ss -tn state time-wait | wc -l

# 查看特定端口的连接情况
ss -tnp sport = :8080 | wc -l

# 查看连接队列溢出情况
ss -lnt | grep 8080
# Recv-Q: 接收队列中等待处理的连接数
# Send-Q: 发送队列中等待发送的数据量

TIME_WAIT过多是常见问题。每个TIME_WAIT状态的连接会占用一个本地端口，默认端口范围32768-60999约2.8万个。高并发短连接场景下，TIME_WAIT快速堆积导致端口耗尽，新连接无法建立。

# 查看当前端口范围
cat /proc/sys/net/ipv4/ip_local_port_range
# 32768   60999

# 扩大端口范围
echo "10000 65535" > /proc/sys/net/ipv4/ip_local_port_range

# 启用TIME_WAIT快速回收（需谨慎，NAT环境下可能导致连接异常）
echo 1 > /proc/sys/net/ipv4/tcp_tw_reuse

# 减小FIN_WAIT2超时时间
echo 30 > /proc/sys/net/ipv4/tcp_fin_timeout

# 永久生效需写入sysctl.conf
cat >> /etc/sysctl.conf << 'EOF'
net.ipv4.ip_local_port_range = 10000 65535
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_fin_timeout = 30
EOF
sysctl -p

抓包分析定位应用层问题

当连接已建立但数据传输异常时，抓包是定位问题的终极手段。tcpdump配合Wireshark可以还原完整的请求-响应过程，精准定位重传、RST、慢响应等问题。

# 抓取8080端口的完整TCP流，写入文件用Wireshark分析
tcpdump -i eth0 port 8080 -w /tmp/capture.pcap -s 0

# 实时查看HTTP请求头（快速排查）
tcpdump -i eth0 port 8080 -A -s 0 | grep -E "GET|POST|HTTP|Host"

# 抓取特定IP的通信
tcpdump -i eth0 host 192.168.1.100 and port 8080 -nn -X

# 抓取TCP RST包（连接被重置）
tcpdump -i eth0 "tcp[tcpflags] & (tcp-rst) != 0" -nn

# 统计重传情况
tcpdump -i eth0 port 8080 -w /tmp/retransmit.pcap
# 用tcptrace分析重传
tcptrace -l /tmp/retransmit.pcap | grep -i retrans

RST包是排查连接异常的关键线索。收到RST意味着对端主动重置了连接，常见原因包括：防火墙规则拦截、应用进程崩溃、连接超时被服务端主动关闭。通过抓包确认RST的发送方和触发时机，可以快速锁定责任组件。

DNS解析问题排查

DNS解析慢或解析失败是导致"连接慢"的隐蔽原因。一个HTTP请求在DNS解析阶段耗费数秒的情况并不罕见，尤其是在依赖远程DNS服务器的场景下。

# 测量DNS解析耗时
dig +trace www.example.com

# 查看DNS解析详细耗时
dig www.example.com +stats | grep "Query time"

# 检查/etc/resolv.conf配置
cat /etc/resolv.conf
# 确认nameserver指向可达的DNS服务器
# 添加options timeout:1 attempts:2减少超时等待

# 使用本地DNS缓存加速解析
apt install -y nscd
systemctl enable nscd && systemctl start nscd

# 或使用systemd-resolved
systemctl enable systemd-resolved
systemctl start systemd-resolved
# 修改/etc/resolv.conf为127.0.0.53

网络性能基准测试

排查网络性能问题时，需要区分是网络链路带宽瓶颈还是应用层处理瓶颈。iperf3可以测试纯网络吞吐量，排除应用层干扰。

# 服务端启动iperf3
iperf3 -s -p 5201

# 客户端测试TCP吞吐量
iperf3 -c 192.168.1.100 -p 5201 -t 30 -P 4
# -P 4: 4路并发，测试多连接性能
# -t 30: 测试30秒

# 测试UDP吞吐量和丢包率
iperf3 -c 192.168.1.100 -p 5201 -u -b 1G -t 30
# -u: UDP模式
# -b 1G: 目标带宽1Gbps

# 持续监控网络带宽
iftop -i eth0 -n -P
# 按连接维度实时显示带宽使用情况

如果iperf3测试的带宽明显低于网卡标称速率，问题在网络链路层——检查交换机配置、网线规格、MTU设置。如果iperf3带宽正常但应用层传输慢，问题在应用层——检查应用连接池配置、序列化开销、线程模型。服务器安全加固场景下，防火墙规则误拦截也是网络不通的常见原因，排查时需要同步检查iptables或nftables规则是否放行了对应端口。