Linux 网络故障定位：tcpdump 抓包分析、netstat/ss 工具运维精讲

面向初中级运维工程师 / 系统管理员 / DevOps 工程师。本文按”现象 → 命令 → 关键指标 → 根因 → 修复 → 验证 → 复盘”的路径，写清楚当一个服务出问题、网络出问题、连接出问题的时候，怎么用 tcpdump / netstat / ss 这一套工具链，从抓现象到定位原因到动手修复。

一、为什么把 netstat、ss、tcpdump 放一起讲

这三件套是 Linux 网络排查的”铁三角”，分工很明确：

• netstat：看当前系统所有 socket 的状态、连接数、监听端口、对端地址。属于”全量视图”，但在高连接数下偏慢。
• ss：netstat 的替代品，从内核 proc/net/tcp 等直接读，速度快十几倍到几十倍，输出更结构化。
• tcpdump：在数据链路层抓包，看真实”飞过去”的字节，是网络问题唯一不撒谎的证据。

它们各自解决不同问题，但常常组合用：先用 ss 看到异常，再用 tcpdump 抓现场，最后用 netstat / ss 对比修复前后的状态。

二、阅读这一篇你能解决什么

• 服务突然”连不上”，怎么判断是服务端没起、防火墙挡了、还是客户端没到。
• 连接数暴增 / TIME_WAIT 暴增 / CLOSE_WAIT 暴增，分别怎么定位。
• 怀疑 SYN Flood、DNS 污染、TLS 握手失败，如何抓包取证。
• 一台机器响应慢，定位到网卡软中断、TCP 重传、conntrack 满等常见瓶颈。
• 看懂 tcpdump 抓出来的内容，能写出实用的 BPF 过滤表达式。

三、本文约定

• 操作系统以 CentOS 7 / RHEL 7 / AlmaLinux 8 / Ubuntu 20.04/22.04 为主。
• 部分命令需要 root，建议在排查环境里 sudo -i。
• 抓包命令会带 -i any 表示抓所有网卡，避免漏流量；生产环境请确认业务合规。
• 抓包文件统一保存到 /tmp/cap/ 或 /var/tmp/cap/，文件名带时间戳、网卡、过滤条件，便于归档。

四、TCP 状态机速查

排查网络问题离不开 TCP 状态。下面这张表是后面所有案例的共同语言。

需要记住的几个数：

• 主动关闭方会进入 TIME_WAIT，时长 2MSL（Linux 默认 60s）。
• 被动关闭方会进入 CLOSE_WAIT，时长由应用决定（不 close 永远不会退出）。
• 服务端 SYN_RECV 数量超过 backlog 会丢弃连接并启用 syncookies。

五、netstat 实战

5.1 netstat 安装与版本

# RHEL 系列
yum install -y net-tools

# Debian/Ubuntu
apt-get install -y net-tools

# 查看版本
netstat -V 2>&1 | head -1

5.2 常用选项

5.3 经典组合

# 看所有 TCP 连接（不去反解，最快）
netstat -ant

# 加进程信息（需要 root）
netstat -antp

# 只看监听
netstat -lntp

# 按状态统计
netstat -ant | awk '{print $NF}' | sort | uniq -c | sort -rn

# 看某端口是谁在监听
netstat -lntp | grep ':80 '

# 看连接到 80 端口的客户端
netstat -ant | grep ':80 '

# 看路由表
netstat -rn

# 看网卡收发包
netstat -i

5.4 输出解读

Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      1234/nginx
tcp        0      0 10.0.0.5:80             10.0.1.100:54321        ESTABLISHED 1234/nginx

• Recv-Q：接收队列堆积字节数。LISTEN 状态下不为 0 表示 accept 队列满。
• Send-Q：发送队列堆积字节数。
• Local Address：本地地址:端口。
• Foreign Address：对端地址:端口。
• State：状态。

5.5 netstat 的局限

• 高并发连接（10 万+ ESTABLISHED）下 netstat -ant 会非常慢，因为它要遍历所有 socket 并尝试解析。
• 输出格式固定，无法定制。
• 不能展示拥塞窗口、重传、排序等 TCP 内部指标。

这些场景都更适合 ss。

六、ss 实战

6.1 安装

yum install -y iproute  # RHEL
apt-get install -y iproute2  # Debian/Ubuntu

6.2 常用选项

6.3 经典组合

# 全量统计摘要（常用作健康巡检）
ss -s

# TCP 摘要
ss -tan state established | wc -l

# 按状态分组计数
ss -tan | awk 'NR>1 {print $1}' | sort | uniq -c | sort -rn

# 看监听 + 进程
ss -lntp

# 看连接到 22 端口的客户端（注意冒号）
ss -tan '( dport = :22 or sport = :22 )'

# 看所有 80 端口的连接
ss -tan '( sport = :80 or dport = :80 )'

# 看某 IP 的所有连接
ss -tan dst 10.0.1.100

# 看某网段的连接
ss -tan dst 10.0.0.0/16

# 看 socket 内存占用
ss -tan -m | head

# 看 TIME_WAIT 数量（排查连接池问题常用）
ss -tan state time-wait | wc -l

# 看 CLOSE_WAIT
ss -tan state close-wait | head

# 看 SYN_RECV（疑似 SYN Flood）
ss -tan state syn-recv | head

6.4 内部 TCP 信息（核心）

# 看每个 ESTABLISHED 连接的 RTT、cwnd、retrans
ss -tin

输出示例：

ESTAB  0  0  10.0.0.5:22  10.0.0.100:54321  users:(("sshd",pid=1234,fd=4))
     cubic wscale:7,7 rto:204 rtt:0.5/0.75 ato:40 mss:1448 cwnd:10 send 2.5Mbps rcv_rtt:0.5 rcv_space:29200

字段解释：

• cubic：拥塞控制算法（Cubic / Reno / BBR / H-TCP）。
• wscale：窗口缩放因子。
• rto：重传超时。
• rtt：往返时间，平均 / 方差。
• mss：最大段大小。
• cwnd：拥塞窗口。
• retrans：已重传次数（不同 ss 版本位置不同，可能在 retrans:0）。

6.5 ss 计时器

ss -to

显示每个 socket 的定时器，例如：

ESTAB 0 0 10.0.0.5:22 10.0.0.100:54321 timer:(keepalive,28sec,0)

常见计时器：

• keepalive：TCP keepalive 定时器。
• retrans：重传定时器。
• probe：零窗口探测。

6.6 关闭连接（紧急止血）

# 关闭某端口的所有连接（慎用！会让在线用户掉线）
ss -K 'dport = :80'

# 关闭某 IP 的所有连接
ss -K 'dst 10.0.1.100'

# 关闭某状态的连接
ss -K 'state time-wait'

风险提示：

• -K 会强制关闭连接，等同于应用层 close 但不等应用资源释放。
• 生产环境要写变更单、限定时间窗口、避开业务高峰。
• 关闭前用 ss -p 看进程归属，避免误杀其它业务。

七、tcpdump 实战

7.1 安装

yum install -y tcpdump
apt-get install -y tcpdump

7.2 基本用法

# 抓所有网卡所有包（生产慎用！数据量爆炸）
tcpdump -i any

# 抓指定网卡
tcpdump -i eth0

# 抓指定数量后退出
tcpdump -i eth0 -c 100

# 抓包并保存为 pcap
tcpdump -i eth0 -w /tmp/cap/cap.pcap

# 抓包并打印到屏幕
tcpdump -i eth0 -nn -vv

# 限制每包大小
tcpdump -i eth0 -s 0   # -s 0 表示抓完整包，默认 68 字节会丢 payload

7.3 BPF 过滤表达式

tcpdump 用 BPF 语法过滤，运维高频表达式如下。

# 按主机
tcpdump -i any host 10.0.1.100

# 按源 / 目的
tcpdump -i any src 10.0.1.100
tcpdump -i any dst 10.0.1.100

# 按网段
tcpdump -i any net 10.0.0.0/16

# 按端口
tcpdump -i any port 80
tcpdump -i any src port 80
tcpdump -i any dst port 80

# 按协议
tcpdump -i any tcp
tcpdump -i any udp
tcpdump -i any icmp

# 多条件组合
tcpdump -i any 'tcp and port 80 and host 10.0.1.100'

# 按 TCP 标志位
tcpdump -i any 'tcp[tcpflags] & tcp-syn != 0'# 所有 SYN
tcpdump -i any 'tcp[tcpflags] & tcp-syn != 0 and tcp[tcpflags] & tcp-ack == 0'# 仅 SYN
tcpdump -i any 'tcp[tcpflags] & tcp-rst != 0'# 所有 RST
tcpdump -i any 'tcp[tcpflags] & tcp-fin != 0'# FIN

# 按包大小
tcpdump -i any 'greater 1000'# 大于 1000 字节
tcpdump -i any 'less 64'# 小于 64 字节

# 抓特定负载内容（危险，可能误匹配）
tcpdump -i any -A 'tcp port 80 and (((ip[2:2] - ((ip[0]&0xf)<<2)) - ((tcp[12]&0xf0)>>2)) != 0)'

7.4 常用高级过滤

# 抓 HTTP 请求行
tcpdump -i any -A -s 0 'tcp port 80 and (((ip[2:2] - ((ip[0]&0xf)<<2)) - ((tcp[12]&0xf0)>>2)) != 0)' 2>/dev/null | grep -E '^(GET|POST|HTTP)'

# 抓 HTTP 响应码
tcpdump -i any -A -s 0 'tcp port 80 and (((ip[2:2] - ((ip[0]&0xf)<<2)) - ((tcp[12]&0xf0)>>2)) != 0)' 2>/dev/null | grep -E '^HTTP/1\.[01]'

# 抓 MySQL 客户端请求
tcpdump -i any -A 'tcp port 3306' 2>/dev/null | grep -E 'Query|SELECT'

# 抓 Redis 客户端命令
tcpdump -i any -A 'tcp port 6379' 2>/dev/null | grep -E '^\*'

风险提示：

• -A 是 ASCII 输出，包多的时候打爆屏幕；建议先写 pcap 再用 Wireshark 看。
• 在高 QPS（>10k）服务器上抓包可能丢包；可以加 -B 4096 调大缓冲区，或者 -i eth0 单独抓一块网卡。

7.5 抓包实战

7.5.1 抓 DNS 解析

tcpdump -i any -nn -s 0 -w /tmp/cap/dns.pcap port 53

抓完后用 tcpdump -nn -r /tmp/cap/dns.pcap 看，或者 Wireshark 分析。

7.5.2 抓 HTTPS 握手（不解密）

tcpdump -i any -nn -s 0 -w /tmp/cap/tls.pcap 'tcp port 443'

要解密 HTTPS 需要服务端 SSLKEYLOGFILE（openssl / nginx 都支持），把 keylog 导入 Wireshark 才能看到明文。

7.5.3 抓 SYN Flood

tcpdump -i any -nn -s 0 'tcp[tcpflags] & tcp-syn != 0 and tcp[tcpflags] & tcp-ack == 0' -c 1000 -w /tmp/cap/syn.pcap

抓到 1000 个 SYN 后退出，分析 SYN 是不是都来自同一 IP 段。

7.5.4 抓 TCP 重传

# tcpdump 不能直接报"重传"，但能看到同一 SEQ 的多次包
tcpdump -i any -nn -vv -tttt 'tcp port 80' 2>&1 | grep -E 'retrans|duplicate' | head

更好的办法是用 Wireshark 打开 pcap，里面会自动标 “TCP Retransmission”。

7.6 tcpdump 输出格式

10:23:45.123456 IP 10.0.1.100.54321 > 10.0.0.5.80: Flags [S], seq 123456, win 64240, options [mss 1460], length 0

字段解释：

• 10:23:45.123456：时间戳。
• IP：协议。
• 10.0.1.100.54321 > 10.0.0.5.80：源端 > 目的端。
• Flags [S]：TCP 标志位。
• seq 123456：序列号。
• win 64240：窗口大小。
• length 0：payload 长度。

常用 flags：

• S：SYN
• S.：SYN+ACK
• .：ACK
• F：FIN
• R：RST
• P：PSH
• U：URG

八、/proc 视角的内核态连接

在系统连接特别多、ss/netstat 都慢的时候，可以直接读内核的 proc 文件。

8.1 关键文件

8.2 直接读 /proc/net/tcp

cat /proc/net/tcp

输出：

  sl  local_address rem_address   st tx_queue rx_queue tr tm->when retrnsmt   uid  timeout inode
   0: 0100007F:0050 00000000:0000 0A 00000000:00000000 0:0 00000000     0        0 12345 1 ffff8800b6f0c000
   1: 0500000A:0050 6401000A:C8C5 01 00000000:00000000 0:0 00000000  1000        0 23456 1 ffff8800b6f0c100

字段解读：

• sl：序号。
• local_address：本地 IP:端口（hex，IP 是网络字节序小端）。
• rem_address：对端 IP:端口。
• st：状态（hex）。
  • 01 = ESTABLISHED
  • 02 = SYN_SENT
  • 03 = SYN_RECV
  • 04 = FIN_WAIT_1
  • 05 = FIN_WAIT_2
  • 06 = TIME_WAIT
  • 07 = CLOSE
  • 08 = CLOSE_WAIT
  • 09 = LAST_ACK
  • 0A = LISTEN
  • 0B = CLOSING
• tx_queue / rx_queue：发送 / 接收队列。

转换示例：把 hex IP 转回点分十进制：

# 0100007F = 127.0.0.1 (倒序读字节: 7F 00 00 01)
# 0050 = 80

一个小脚本：

cat /proc/net/tcp | awk 'NR>1 {
  split($2, l, ":")
  split($3, r, ":")
  printf "%s:%d -> %s:%d st=%s\n",
    l[1], strtonum("0x" l[2]),
    r[1], strtonum("0x" r[2]),
    $4
}'

strtonum 是 gawk 的扩展，把十六进制字符串转成数字。

九、常用辅助工具

9.1 lsof

# 看进程打开了哪些 socket
lsof -i

# 看某端口
lsof -i :80

# 看某进程
lsof -p 1234 | grep -i socket

# 看某用户
lsof -i -u mysql

9.2 iftop / nethogs / iptraf-ng

# 按连接看实时流量
iftop -i eth0

# 按进程看实时流量
nethogs eth0

# 文本模式图形化统计
iptraf-ng

9.3 sar -n 系列

# 网卡收发统计
sar -n DEV 1

# 网卡错误
sar -n EDEV 1

# TCP 统计
sar -n TCP 1

# 套接字统计
sar -n SOCK 1

%ifutil 接近 100% 表示网卡打满。

9.4 nstat / ip -s

# 看 TCP 重传统计（内核计数器）
nstat -az | grep -E 'TcpRetrans|TcpOutRsts|TcpActiveOpens'

# 看网卡统计
ip -s link show eth0

TcpRetransSegs 持续增长 = 网络丢包或对端 RTO。

9.5 conntrack

# 当前连接跟踪表大小
cat /proc/sys/net/netfilter/nf_conntrack_max
sysctl net.netfilter.nf_conntrack_count

# 看当前 conntrack
conntrack -L

# 看某 conn 详细信息
conntrack -L -d 10.0.1.100

如果 nf_conntrack_count 接近 nf_conntrack_max，就会丢包，表现为 curl / ssh 超时。

9.6 strace 跟 connect / send / recv

# 跟进程的系统调用
strace -f -p 1234 -e trace=network,write,read

# 看进程 connect 到哪里失败
strace -f -p 1234 -e trace=connect 2>&1 | grep -E 'sin_addr|EINPROGRESS|ETIMEDOUT|ECONNREFUSED'

9.7 ethtool

# 网卡驱动 / 速率
ethtool eth0

# 网卡详细统计（不同驱动字段不同）
ethtool -S eth0 | grep -E 'err|drop|carrier|crc'

# 看网卡队列与中断
ethtool -l eth0
ethtool -x eth0

十、案例 1：TIME_WAIT 暴增，连接池打满

10.1 现象

某服务（Java + Tomcat）告警”无法获取连接”，监控显示 ESTABLISHED 接近 6 万，TIME_WAIT 接近 4 万，业务开始 5xx。

10.2 初步判断

主动关闭方在 TIME_WAIT，意味着客户端或服务端某一方主动断开连接且频繁。常见原因：

• HTTP 调用短连接，每次请求开新连接。
• 连接池配置过小，频繁建立 / 销毁。
• 服务端主动 keep-alive 超时关连接。
• 中间件（LB / NAT）改了会话超时。

10.3 命令检查

# 1) 看 TIME_WAIT 数量
ss -tan state time-wait | wc -l

# 2) 看哪些对端最多
ss -tan state time-wait | awk 'NR>1 {print $5}' | cut -d: -f1 | sort | uniq -c | sort -rn | head

# 3) 看本地端口分布
ss -tan state time-wait | awk 'NR>1 {print $4}' | cut -d: -f2 | sort | uniq -c | sort -rn | head

# 4) 看哪些进程
ss -tanp state time-wait | head

# 5) 内核全局统计
nstat -az | grep -E 'TcpActiveOpens|TcpPassiveOpens|TcpTW'

10.4 关键指标

• TcpTW：累计进入 TIME_WAIT 的次数，突增即异常。
• ss -tan state time-wait | wc -l：当前 TIME_WAIT 的瞬时数量。
• local port 集中 → 多半是同一类服务（如反向代理 → 上游）。
• foreign addr 集中 → 多半是对端 IP 集中（如调用一个 API 网关）。

10.5 根因定位

观察到 local port 集中在 8080 附近，foreign addr 集中在 LB 入口 IP。判定为：上游 LB 在 keep-alive 超时后主动断开，导致下游侧产生大量 TIME_WAIT。

证据：

• nstat -az | grep TcpTW 增长曲线与 LB 主动断开节奏吻合。
• 在 LB 上抓包确认 FIN 由 LB 发出。

10.6 修复方案

短期：

# 开启 TIME_WAIT 复用（Linux 默认就是允许的，但可以确认）
sysctl -w net.ipv4.tcp_tw_reuse=1

# 适当缩短 TIME_WAIT 持续时间（默认 60s）
sysctl -w net.ipv4.tcp_fin_timeout=15

注意：tcp_tw_recycle 在 NAT 环境下会”误杀”正常连接，已经在 Linux 4.12 后移除，禁止开启。

长期：

• 客户端使用长连接 + 连接池。
• 服务端调高 keepalive_timeout（Nginx）。
• 评估是否真的需要 keep-alive，部分 API 改成长轮询或 SSE。

10.7 验证

# 5 分钟后
ss -tan state time-wait | wc -l   # 应大幅下降
ss -s                            # 摘要里 TIME_WAIT 应回落到合理水位

# 业务验证
curl -sSI https://api.example.com/health

10.8 复盘

• 监于内核 sysctl 在重启后会丢失，必须写进 /etc/sysctl.d/。
• TIME_WAIT 不是 bug，是 TCP 设计的可靠性保证；重点不是”消除”而是”控制在水位之下”。
• 排查时把 TIME_WAIT 数量与 ESTABLISHED 数量做比值，超过 0.5 就要警觉。

十一、案例 2：SYN_RECV 堆积，疑似 SYN Flood

11.1 现象

反向代理服务器 SYN_RECV 数量从 0 涨到 8000+，新连接无法建立，老连接延迟升高。

11.2 初步判断

SYN_RECV 数量持续增长且明显高于正常，说明服务端发出 SYN+ACK 但没收到客户端 ACK。可能的原因：

• 客户端故意不发 ACK（SYN Flood）。
• 客户端 RST / 掉线 / 防火墙把 ACK 丢了。
• 链路 NAT 状态被淘汰。
• 后端应用很慢，TCP 握手队列被填满。

11.3 命令检查

# 1) SYN_RECV 数量
ss -tan state syn-recv | wc -l

# 2) 看 SYN_RECV 来源分布
ss -tan state syn-recv | awk 'NR>1 {print $5}' | cut -d: -f1 | sort | uniq -c | sort -rn | head

# 3) 抓包确认
tcpdump -i eth0 -nn -c 1000 'tcp[tcpflags] & tcp-syn != 0 and tcp[tcpflags] & tcp-ack == 0' -w /tmp/cap/syn.pcap

# 4) 看 syncookies 是否生效
cat /proc/sys/net/ipv4/tcp_syncookies

# 5) 看半连接队列上限
cat /proc/sys/net/ipv4/tcp_max_syn_backlog
cat /proc/sys/net/core/somaxconn

11.4 关键指标

• SYN_RECV 数量 > backlog 阈值就触发 syncookies。
• syncookies = 1 表示内核开始使用 syncookies 应答（折损服务端资源但能抵御攻击）。
• backlog 越小越容易丢；调高 somaxconn 与 tcp_max_syn_backlog 可缓解。

11.5 根因定位

抓包显示 SYN 来自 200 多个肉鸡 IP，每个 IP 平均 30+ SYN/秒，分布随机。判定为 SYN Flood。

11.6 修复方案

应急：

# 开启 syncookies
sysctl -w net.ipv4.tcp_syncookies=1

# 调大半连接队列
sysctl -w net.ipv4/tcp_max_syn_backlog=4096
sysctl -w net.core.somaxconn=4096

# 临时用 iptables 限速单个源 IP 的 SYN
iptables -I INPUT -p tcp --syn -m limit --limit 10/s --limit-burst 20 -j ACCEPT
iptables -A INPUT -p tcp --syn -j DROP

长期：

• 上云 WAF / 高防 IP。
• Nginx 调高 listen 的 backlog。
• 客户端 IP 黑名单（与威胁情报对齐）。

11.7 验证

# 5 分钟后
ss -tan state syn-recv | wc -l   # 应回归正常
nstat -az | grep -E 'TcpExtTCPBacklogDrop|TcpSyncookiesSent'

11.8 复盘

• SYN_RECV 暴增不一定是 SYN Flood，要结合来源 IP 分布与业务影响判断。
• syncookies 是兜底机制，开启会降低部分性能，但比被攻击拖垮要好。
• iptables 限速能救急，但容易被 ACK Flood / UDP Flood 绕过；长期方案必须是 WAF。

十二、案例 3：CLOSE_WAIT 持续增长

12.1 现象

服务端进程 CLOSE_WAIT 数量持续增长，几小时后突破 5 万，新连接无法建立。

12.2 初步判断

CLOSE_WAIT 是被动关闭方收到对端 FIN 后等待应用 close 的状态。如果长时间不退出，说明应用层没调用 close。常见原因：

• 代码逻辑：异常分支未关闭 socket。
• 连接泄漏：异常路径上 close 没被执行。
• 第三方库：HTTP 客户端 / 数据库连接池没正确释放。
• JVM GC 停顿：连接对象被 GC 但还没 close。

12.3 命令检查

# 1) CLOSE_WAIT 数量
ss -tan state close-wait | wc -l

# 2) 看本地端口分布（哪个服务）
ss -tan state close-wait | awk 'NR>1 {print $4}' | cut -d: -f2 | sort | uniq -c | sort -rn | head

# 3) 看进程归属
ss -tanp state close-wait | head

# 4) 看 inode 数量
ls /proc/$PID/fd | wc -l

# 5) Java 应用：jstack 看线程栈
jstack $PID | grep -A 30 BLOCKED

12.4 关键指标

• CLOSE_WAIT 数量趋势（递增即异常）。
• 单进程 fd 数量（ls /proc/$PID/fd | wc -l）。
• jstack 长时间 BLOCKED 的线程。
• 数据库连接池活跃数（如果用 Druid / HikariCP，看监控）。

12.5 根因定位

本例为 Java 应用，jstack 显示大量线程卡在 HttpClient.readResponse，确认是 HTTP 客户端在异常路径上没释放连接。

12.6 修复方案

# 临时缓解：重启服务（要先拉出流量）
systemctl restart myservice

# 代码层：确保 finally 里 close，或用 try-with-resources

代码示例（正确写法）：

try (CloseableHttpResponse resp = httpClient.execute(request)) {
    // 处理
}

12.7 验证

ss -tan state close-wait | wc -l   # 重启后归零
ss -s                              # 摘要中 close-wait 为 0

12.8 复盘

• CLOSE_WAIT 增多的根因不在网络层而在应用层。
• 监控加 state close-wait 计数告警，提前发现。
• 服务启动时设置 ulimit -n 上限，避免 fd 撑爆整机。

十三、案例 4：跨机延迟高，定位网卡软中断不均

13.1 现象

同机房两台机器 ping 平均 1ms，业务调用 P99 200ms+，明显异常。

13.2 命令检查

# 1) 看网卡统计
sar -n DEV 1 5
# 重点看 %ifutil、rx/s tx/s

# 2) 看丢包
netstat -i
ip -s link show eth0 | grep -E 'drop|err|fifo'

# 3) 看软中断分布
cat /proc/interrupts | grep eth0
mpstat -P ALL 1

# 4) 看 RPS/RFS 是否开启
cat /proc/sys/net/core/rps_sock_flow_entries
ls /sys/class/net/eth0/queues/

# 5) tcpdump 看重传
tcpdump -i eth0 -nn -c 1000 'tcp port 80' -w /tmp/cap/cap.pcap

13.3 关键指标

• %ifutil 接近 100%。
• drop 计数快速增长。
• 单个 CPU 软中断占比 80%+。
• tcpdump 显示大量 TCP retransmission。

13.4 根因定位

单队列网卡在多核机器上，所有流量集中到一个核处理，导致软中断瓶颈。开启 RPS（Receive Packet Steering）后问题缓解。

13.5 修复方案

# 临时开启 RPS
echo ffff > /sys/class/net/eth0/queues/rx-0/rps_cpus

# 持久化（写进 /etc/rc.local 或 udev 规则）

或者使用多队列网卡 + 调优：

# 网卡多队列调优
ethtool -L eth0 combined 8

13.6 验证

sar -n DEV 1
# %ifutil 下降
mpstat -P ALL 1
# 软中断分布到多核

十四、案例 5：HTTPS 握手失败

14.1 现象

调用方报告 HTTPS 调用间歇失败，错误 SSL handshake failed 或 connection reset。

14.2 命令检查

# 1) 抓 TLS 握手
tcpdump -i eth0 -nn -s 0 -w /tmp/cap/tls.pcap 'tcp port 443'

# 2) 用 openssl 主动测握手
openssl s_client -connect api.example.com:443 -servername api.example.com -msg -debug 2>&1 | head -50

# 3) 服务端证书信息
openssl x509 -in /etc/nginx/ssl/server.crt -text -noout

# 4) 看 curl 详细握手
curl -v --tlsv1.2 https://api.example.com 2>&1 | grep -E 'TLS|SSL|cipher'

14.3 关键指标

• 是否 ClientHello / ServerHello 完整出现。
• 是否出现 Alert（21 ~ 70 是不同级别）。
• RST 出现的位置：握手过程中 RST 多半是证书或协议不匹配。

14.4 根因定位

本例抓包看到 ServerHello 后立刻 RST，openssl s_client 显示：

SSL alert number 42

42 是 bad_certificate，服务端认为客户端证书不合法。检查客户端证书链补全情况，发现 CA bundle 缺失中间证书。

14.5 修复方案

• 客户端补全 CA bundle。
• 服务端启用 SSL Stapling（ssl_stapling on;）。

14.6 验证

openssl s_client -connect api.example.com:443 -CAfile /etc/pki/tls/certs/ca-bundle.crt
# Verify return code: 0 (ok)

十五、内核参数调优速查

网络排查常常涉及到 sysctl 调参，下面列出运维高频参数与风险。

15.1 常见参数

15.2 修改流程

# 1. 备份
cp -a /etc/sysctl.d/99-sysctl.conf /tmp/sysctl.conf.bak

# 2. 编辑
cat >> /etc/sysctl.d/99-network-tuning.conf <<'EOF'
net.core.somaxconn = 4096
net.ipv4.tcp_max_syn_backlog = 4096
net.ipv4.tcp_synack_retries = 2
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_fin_timeout = 15
EOF

# 3. 应用
sysctl -p /etc/sysctl.d/99-network-tuning.conf

# 4. 验证
sysctl net.core.somaxconn

风险提示：

• 修改前确认业务是否依赖默认值。
• 灰度发布：先在测试集群、再生产灰度、再全量。
• 不要在生产时间窗口改内核参数，避开业务高峰。

15.3 持久化与回滚

# 持久化
echo "net.ipv4.tcp_tw_reuse = 1" >> /etc/sysctl.d/99-network-tuning.conf
sysctl -p

# 回滚
mv /etc/sysctl.d/99-network-tuning.conf /etc/sysctl.d/99-network-tuning.conf.disabled
sysctl -p

十六、抓包分析实战

16.1 TCP 三次握手典型包序列

10:00:00.000 IP 10.0.0.100.54321 > 10.0.0.5.80: Flags [S], seq 100, length 0
10:00:00.001 IP 10.0.0.5.80     > 10.0.0.100.54321: Flags [S.], seq 200, ack 101, length 0
10:00:00.001 IP 10.0.0.100.54321 > 10.0.0.5.80: Flags [.], ack 201, length 0

含义：SYN → SYN+ACK → ACK，连接建立。

16.2 TCP 四次挥手典型包序列

10:00:05.000 IP client > server: Flags [F.], seq 1000, length 0
10:00:05.001 IP server > client: Flags [.], ack 1001, length 0
10:00:10.000 IP server > client: Flags [F.], seq 2000, length 0
10:00:10.001 IP client > server: Flags [.], ack 2001, length 0

16.3 TCP 重传

10:00:00.000 IP server > client: Flags [.], seq 1000, ack 500, length 1000
10:00:00.500 IP server > client: Flags [.], seq 1000, ack 500, length 1000   # 重传
10:00:01.500 IP server > client: Flags [.], seq 1000, ack 500, length 1000   # 重传

看到同样的 SEQ + LEN 多次出现，就是 TCP retransmission。

16.4 客户端收到 RST

10:00:00.000 IP client > server: Flags [S], seq 100
10:00:00.001 IP server > client: Flags [S.], seq 200, ack 101
10:00:00.002 IP server > client: Flags [R], seq 201, length 0

服务端 RST，连接失败。常见原因：SYN Cookie 校验失败、应用层拒绝、内核安全策略。

十七、容器化场景下的网络排查

17.1 Pod 内抓包

容器默认不自带 tcpdump，需要：

# 方法 1：手动安装（不推荐，改动镜像）
kubectl exec -it mypod -- apt-get update && apt-get install -y tcpdump

# 方法 2：用 nsenter（宿主机工具）
PID=$(kubectl get pod mypod -o jsonpath='{.status.containerStatuses[0].containerID}' | sed 's/.*\///')
nsenter -n -t $PID tcpdump -i any -nn 'port 80'

17.2 CNI 网络问题

Cilium / Calico / Flannel 三类 CNI 各有特点：

• Calico：基于 BGP 或 VXLAN，问题常在路由层面。
• Cilium：eBPF 数据面，问题常在 bpf map 状态。
• Flannel：简单 VXLAN，性能一般但稳定。

排查思路：

# 看 Pod IP 与 Node IP 关系
kubectl get pod -o wide

# 看 CNI 日志（以 Calico 为例）
kubectl logs -n kube-system -l k8s-app=calico-node

# 看 iptables 规则（kube-proxy 生成）
iptables-save | head -50

17.3 Service / Ingress 问题

# Service 是否有 endpoints
kubectl get endpoints myservice

# 端点是否存在
kubectl describe svc myservice

# Ingress 状态
kubectl describe ingress myingress

常见问题：

• Endpoints: <none>：selector 不匹配、Pod 没 Ready。
• 503：Ingress Controller 转发失败，多半是上游不通。

十八、生产抓包注意事项

1. 磁盘空间：抓 10GB 流量到磁盘，需要预留 20-30GB 临时空间。
2. 抓包速率：1Gbps 网卡满速时，tcpdump 可能丢包（默认 kernel ring buffer 有限）。可以用 tcpdump -B 4096 -i eth0 ... 调大。
3. 业务影响：抓包本身对 CPU 占用有 5-15%，生产环境避免在业务高峰抓包。
4. 合规性：抓包涉及用户数据，特别是 HTTP 明文 / API 调用，遵守数据合规。
5. 数据安全：抓到的 pcap 文件含敏感数据，加密保存，定期清理。
6. 变更流程：抓包前要写变更单，时间窗口避开业务高峰。
7. 事后归档：抓包 + 分析结果要进知识库，便于团队复用。

十九、iptables / nftables 与连接追踪

19.1 看 conntrack

conntrack -L | head
conntrack -S | head

19.2 看 nf_conntrack 满载

sysctl net.netfilter.nf_conntrack_count
sysctl net.netfilter.nf_conntrack_max

count 接近 max 就会丢包。

19.3 临时调大

sysctl -w net.netfilter.nf_conntrack_max=524288
sysctl -w net.netfilter.nf_conntrack_tcp_timeout_established=3600

19.4 iptables 关键规则

# 看 SYN 限速
iptables -L -n -v | grep -E 'SYN|conn'

# 看每条规则的命中数
iptables -L -n -v

pkts 和 bytes 持续增长说明规则有效；为 0 多半规则没匹配。

二十、监控与告警建议

20.1 必备指标

| 指标 | 含义 | 告警阈值 | | — | — | | node_netstat_Tcp_CurrEstab | 当前 ESTABLISHED 数 | 视业务 | | node_netstat_Tcp_ActiveOpens | 累计主动打开 | 突增告警 | | node_netstat_Tcp_PassiveOpens | 累计被动打开 | 突增告警 | | node_netstat_Tcp_RetransSegs | 累计重传段 | 增长速率告警 | | node_netstat_Tcp_CurrEstab | 当前 ESTABLISHED | 接近 ulimit 告警 | | node_netstat_Tcp_InErrs | 错误入包 | 增长告警 | | node_netstat_Tcp_OutRsts | RST 出包 | 突增告警 | | node_conntrack_count | conntrack 表项数 | 接近 max 告警 | | node_sockstat_TCP_alloc | 已分配 TCP socket | 突增告警 |

20.2 Prometheus 抓取脚本

scrape_configs:
  - job_name: 'node'
    static_configs:
      - targets: ['10.0.0.5:9100']

node_exporter 自带 netstat 指标。

20.3 自定义告警规则示例

groups:
  - name: network
    rules:
      - alert: HighTcpRetrans
        expr: rate(node_netstat_Tcp_RetransSegs[5m]) > 100
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "TCP 重传统计过高"
          description: "{{ $labels.instance }} 重传速率 {{ $value }}/s"

二十一、常见问答

Q1：netstat 和 ss 该选谁？

优先 ss。netstat 在 10 万连接以上基本不可用。ss 直接读内核 hash 表，速度快，输出格式更适合脚本化。

Q2：tcpdump 抓不到包的可能原因？

• 网卡混杂模式未启用（一般不需要）。
• BPF 表达式写错：先写简单表达式，再加约束。
• 抓包位置错：流量没经过该网卡。例如两个 Pod 在同一节点上通信，物理网卡看不到。

Q3：怎么看 TCP 内部参数（RTT、cwnd）？

ss -tin

或者用 tcpprobe / perf 内核追踪。

Q4：抓 HTTPS 内容怎么做？

需要服务端 SSLKEYLOGFILE + Wireshark 解密。或者直接用 openssl / curl 主动测握手，绕开生产抓包。

Q5：TIME_WAIT 真的有害吗？

TIME_WAIT 是 TCP 协议设计的可靠性保证，避免最后一个 ACK 丢失后服务端无法正常关闭。短连接多 → TIME_WAIT 多。优化方向是减少短连接（长连接 + 连接池），不是消除 TIME_WAIT。

Q6：CLOSE_WAIT 太多怎么快速止血？

# 找到进程，重启它（要拉出流量！）
kill -TERM $PID

但根本修复在代码层（finally / try-with-resources）。

Q7：RST 多是什么原因？

• 服务端端口未开。
• 内核安全策略（SYN Cookie / iptables reject）。
• 应用程序主动关闭未完成的 socket。
• 大量 keep-alive 探测失败。

Q8：conntrack 满载怎么应急？

sysctl -w net.netfilter.nf_conntrack_max=1048576

但要先查清为什么满——可能是扫描器攻击、DNS 解析缓存失效、UDP 流量过大。

二十二、命令速查

# 连接总览
ss -s

# 按状态计数
ss -tan | awk 'NR>1 {print $1}' | sort | uniq -c

# 看某个状态的全部连接
ss -tan state time-wait
ss -tan state close-wait
ss -tan state syn-recv

# 看某 IP / 网段
ss -tan dst 10.0.1.100
ss -tan dst 10.0.0.0/16

# 关闭连接（紧急止血）
ss -K 'dport = :80'
ss -K 'dst 10.0.1.100'

# 内部 TCP 信息
ss -tin

# 抓包
tcpdump -i eth0 -nn -s 0 -w /tmp/cap/cap.pcap port 80
tcpdump -i any 'tcp and port 80 and host 10.0.1.100'

# BPF 过滤
tcpdump 'tcp[tcpflags] & tcp-syn != 0'# 所有 SYN
tcpdump 'greater 1000'# 大于 1000 字节
tcpdump 'less 64'# 小于 64 字节

# 网卡 / 软中断
sar -n DEV 1
mpstat -P ALL 1
cat /proc/interrupts | grep eth0

# conntrack
sysctl net.netfilter.nf_conntrack_count
sysctl net.netfilter.nf_conntrack_max
conntrack -L | head

# 内核参数
sysctl -a | grep net.ipv4.tcp
sysctl -p /etc/sysctl.d/99-network-tuning.conf

# 内核 TCP 统计
nstat -az | grep -E 'TcpRetrans|TcpActiveOpens|TcpPassiveOpens|TcpOutRsts'

二十三、总结与最佳实践

1. 先 ss 后 tcpdump：ss 是”宏观体检”，tcpdump 是”活检取样”。能用 ss 看出来的不要抓包。
2. 抓包先小后大：先用 -c 1000 抓 1000 包看下，再决定要不要全量。
3. 状态机常记常新：把 TCP 状态机背熟，看到 CLOSE_WAIT 立刻知道是应用层问题。
4. 抓包要带 BPF：永远用 BPF 缩小范围，否则数据无法落盘。
5. sysctl 修改要灰度：先在测试集群，再生产灰度，并保留回滚命令。
6. 生产抓包要变更：写变更单、避开高峰、备份数据、归档分析结果。
7. 多指标交叉验证：ESTABLISHED 上升 + TIME_WAIT 下降 + nstat 上 TcpTW 增长，三者一起看才有结论。
8. 拥抱 BBR：对高带宽长肥网络，BBR 比 CUBIC 显著提升吞吐。
9. conntrack 必须监控：很多”莫名超时”都是 conntrack 满载引起的。
10. 维护团队知识库：把每次排查的 ss / tcpdump 输出、入参、判断逻辑归档，下次复用。
11. 把日常巡检脚本化：写一个 healthcheck.sh，每天跑一次，把异常指标记到日志。
12. 不迷信单一指标：ESTABLISHED 多未必坏、TIME_WAIT 多未必坏，结合业务 P99、错误率综合判断。

排查网络问题的最高境界不是工具用得多花，是”用最少的命令拿到最直接的证据”。这一篇里给出的所有命令组合，都是为了这一个目标。

转自：马哥Linux运维

版权申明：内容来源网络，版权归原创者所有，如有侵权请联系删除

想了解更多干货，可通过下方扫码关注

可扫码添加上智启元官方客服微信👇