VPSKnow

网络包分析与故障排查完全指南

高级
60分钟

深入网络通信底层,学习使用 tcpdump、Wireshark、Tshark、nmap、ss 等工具捕获和分析数据包,精准定位复杂的网络连接问题和安全异常。这是从「会用」到「精通」VPS 的必经之路。

📡 什么是网络包分析

网络包分析(Packet Analysis),俗称"抓包",是指捕获、解码并分析在网络上传输的数据包。数据包是网络通信的基本单位,包含了所有传输的信息。通过分析这些原始数据,我们可以像侦探一样,看清网络通信的每一个细节,从而诊断出那些表面上难以发现的问题。

ping 不通、网站超时、速度缓慢等问题无法通过常规手段解决时,抓包分析就是我们的终极武器。

🏥 快速诊断工具箱:ss / netstat / ip

抓包是重型工具,很多时候先用这些轻量命令就能快速定位问题——不需要抓任何包,秒级得到结论:

ss

Socket Statistics,比 netstat 更快更现代,查看所有 TCP/UDP 连接和监听端口

ip

查看网络接口、IP 地址、路由表、ARP 邻居表,替代老旧的 ifconfig/route

netstat

老牌工具,部分系统默认安装,功能与 ss 类似但速度较慢

# ── ss(推荐,比 netstat 更快更现代)────────────────────────────────────────
# 查看所有监听中的 TCP 端口(-l 监听,-t TCP,-n 不解析,-p 显示进程)
ss -tlnp

# 查看所有已建立的 TCP 连接
ss -tnp state established

# 查看连接到某个端口的所有连接(如排查 80 端口连接数)
ss -tnp | grep ':80'

# 统计各状态的 TCP 连接数(TIME_WAIT 过多是常见问题)
ss -s

# 查看某个进程(如 nginx)的所有连接
ss -tnp | grep nginx

# ── ip 命令(查看网络接口和路由)────────────────────────────────────────────
# 查看所有网络接口和 IP 地址
ip addr show

# 查看路由表
ip route show

# 查看 ARP 表(局域网设备 MAC 地址映射)
ip neigh show

# ── netstat(老工具,仍然好用)───────────────────────────────────────────────
# 查看监听端口和对应进程
netstat -tlnp

# 统计 TCP 连接状态分布
netstat -an | awk '/^tcp/ {print $6}' | sort | uniq -c | sort -rn

🧰 神器:tcpdump 入门

tcpdump 是 Linux 下强大的命令行抓包工具,几乎所有 Linux 发行版都自带或可以轻松安装。

安装 tcpdump

# Debian/Ubuntu
sudo apt update && sudo apt install tcpdump -y

# CentOS/RHEL
sudo yum install tcpdump -y

常用参数解析

参数 说明
-i [interface] 指定要监听的网络接口,如 `eth0`。`any` 表示监听所有接口。
-n 不将 IP 地址解析为主机名,显示数字 IP。
-nn 不将 IP 地址和端口号解析为主机名和服务名。
-X 以十六进制和 ASCII 码形式显示数据包内容。
-w [file.pcap] 将抓取的数据包保存到文件,而不是在屏幕上显示。
-r [file.pcap] 从文件中读取数据包进行分析。
-c [count] 抓取指定数量的数据包后停止。
-A 以 ASCII 码形式打印数据包内容(非常适合直接看 HTTP 明文请求)。
-s [snaplen] 设置每个数据包的最大截取长度。默认 262144,0 表示完整截取。
-v / -vv / -vvv 增加输出详细程度,-vvv 可以看到完整的协议字段。

🔍 核心:流量过滤(BPF 语法)

在繁忙的服务器上,不加过滤地抓包会产生海量数据。学会使用 BPF(伯克利包过滤器)语法是 tcpdump 的精髓所在。

类型 命令示例 说明
按主机 tcpdump host 1.2.3.4 抓取所有与 IP 1.2.3.4 相关的数据包。
按端口 tcpdump port 80 抓取所有源端口或目的端口为 80 的数据包。
按协议 tcpdump icmp 只抓取 ICMP 协议的数据包(例如 ping)。
组合条件 tcpdump src 1.2.3.4 and tcp port 443 抓取从 IP 1.2.3.4 发出,且目标端口为 443 的 TCP 包。
排除端口 tcpdump not port 22 排除 SSH 流量,避免抓包时产生自我循环干扰。
按网段 tcpdump net 192.168.1.0/24 抓取整个 192.168.1.x 子网的所有流量。
SYN包 tcpdump 'tcp[tcpflags] & tcp-syn != 0' 只抓取 TCP SYN 包,排查连接建立问题或 SYN Flood 攻击。

可以使用 and(&&)、or(||)、not(!)来组合更复杂的过滤条件。

🎓 进阶:tcpdump 高阶技巧

掌握这些技巧可以让抓包更高效、更安全,避免文件撑爆磁盘或手动下载文件的麻烦:

# ── 环形缓冲写入(防止抓包文件撑爆磁盘)────────────────────────────────────
# 每个文件最大 100MB,最多保留 5 个文件(循环覆盖),总占用 ≤500MB
tcpdump -i any -w /tmp/capture-%Y%m%d-%H%M%S.pcap -G 3600 -C 100 -W 5

# ── 实时管道给 Wireshark(无需保存文件,本地直接分析)────────────────────────
# 前提:本地已安装 Wireshark,SSH 连通 VPS
ssh user@VPS_IP "tcpdump -i any -U -w - not port 22" | wireshark -k -i -
# -U 表示不缓冲直接发送,-w - 输出到 stdout;本地 Wireshark 实时显示

# ── 抓包同时在终端预览(调试时很有用)───────────────────────────────────────
tcpdump -i any -n port 80 -A 2>/dev/null | grep -E "GET|POST|Host:|HTTP/"

# ── 按文件大小自动切割(长时间抓包)──────────────────────────────────────────
# 每 50MB 切一个新文件
tcpdump -i any -w /tmp/cap.pcap -C 50

# ── 指定抓包时长(自动停止)──────────────────────────────────────────────────
timeout 60 tcpdump -i any -w /tmp/60s-capture.pcap port 443

💻 进阶:终端里的 Wireshark(Tshark)

tcpdump 虽然抓包强大,但在终端里直接分析高层协议(如 HTTP、DNS)非常吃力。Tshark(Wireshark 的命令行版本)可以直接在终端解析协议字段,无需导出文件。

# 安装 tshark(Debian/Ubuntu)
sudo apt update && sudo apt install tshark -y

# 实时监听并提取 HTTP 请求的 Host 和 URI(就像 Nginx 访问日志一样直观)
tshark -i any -Y "http.request" -T fields -e http.host -e http.request.uri

# 提取 DNS 查询的域名(实时监控设备在查询什么域名)
tshark -i any -Y "dns.qry.type == 1" -T fields -e dns.qry.name

# 统计每个 IP 的流量占比
tshark -i any -z conv,ip -q

🎨 图形化分析:Wireshark

虽然 tcpdump 负责在服务器上抓包,但最强大的分析工具是图形化的 Wireshark。标准流程是:服务器抓包,本地分析

1

在 VPS 上抓包并保存为文件

tcpdump -i eth0 -w capture.pcap host 8.8.8.8 and icmp
2

将文件下载到本地

scp user@your_vps_ip:~/capture.pcap .
3

使用 Wireshark 打开分析

在本地电脑安装 Wireshark,打开 capture.pcap,可以看到按协议分层的清晰界面,轻松追踪会话、查看数据内容。

Wireshark 高效使用技巧

# ── Wireshark 高效使用技巧 ──────────────────────────────────────────────────

# 追踪 TCP 会话(最常用!)
# 右键某条 TCP 包 → Follow → TCP Stream
# → 弹出窗口显示完整的请求/响应对话,HTTP 明文一览无遗

# 统计功能(Statistics 菜单)
# Statistics → Protocol Hierarchy → 各协议流量占比分布图
# Statistics → Conversations → 按 IP 对统计流量/包数
# Statistics → IO Graph → 流量随时间变化的折线图
# Statistics → Response Time → HTTP/DNS 响应时间分析

# 导出特定数据
# File → Export Objects → HTTP → 导出所有 HTTP 传输的文件(图片/JS/CSS)

# 颜色规则说明(Wireshark 默认配色)
# 黑底红字 → TCP 重传(丢包!)
# 红底白字 → TCP RST(连接被拒绝)
# 黄底黑字 → TCP 问题(乱序/重复ACK)
# 蓝底白字 → SMB/CIFS 流量

🎯 进阶:Wireshark 显示过滤

注意:tcpdump 的"捕获过滤"(BPF 语法)和 Wireshark 顶部的"显示过滤"(Display Filter)语法完全不同!显示过滤发生在抓包之后,语法更加面向对象和协议层,功能更强大。

// 仅显示源 IP 为 192.168.1.100 且目标端口为 80 的流量
ip.src == 192.168.1.100 and tcp.dstport == 80

// 仅显示 HTTP 响应码为 400 或 500 系列的报错包
http.response.code >= 400

// 仅显示包含 "admin" 字符串的 HTTP 请求
http.request.uri contains "admin"

// 仅显示 TCP 握手阶段的 SYN 包
tcp.flags.syn == 1 and tcp.flags.ack == 0

// 显示 TCP 重传(排查丢包/网速慢)
tcp.analysis.retransmission

// 显示 TCP RST(排查连接被拒绝)
tcp.flags.reset == 1

// 过滤特定会话的所有包(右键某条记录 → Follow → TCP Stream 更方便)
tcp.stream eq 0

🗺️ 进阶:nmap 端口扫描与服务识别

nmap 是网络侦察的利器。与 tcpdump 的被动监听不同,nmap 主动探测目标端口的开放情况和运行的服务版本。在排查"端口为什么连不上"或"确认自己的 VPS 暴露了哪些端口"时极其有用。

# ── 安装 nmap ────────────────────────────────────────────────────────────────
apt install nmap -y

# ── 基础端口扫描 ──────────────────────────────────────────────────────────────
# 扫描目标常用端口(前 1000 个端口,最常用)
nmap 目标IP

# 扫描全部 65535 个端口
nmap -p- 目标IP

# 扫描指定端口范围
nmap -p 80,443,8080-9090 目标IP

# ── 服务版本识别(运维诊断神器)─────────────────────────────────────────────
# 检测开放端口上运行的服务和版本
nmap -sV 目标IP

# 同时检测操作系统类型
nmap -O 目标IP

# 最全面的扫描(含脚本检测,较慢)
nmap -A 目标IP

# ── 自查 VPS 暴露情况(重要!)───────────────────────────────────────────────
# 从外部视角扫描自己的 VPS,确认没有意外开放的端口
nmap -sV 你的VPS公网IP

# ── 常见用途:排查 frp/代理服务端口是否正常开放 ──────────────────────────────
nmap -p 7000,6022,15000 你的VPS公网IP

⚠️ 注意:只扫描你自己管理的服务器,扫描他人服务器在很多地区属于违法行为。建议定期用 nmap 扫描自己的 VPS,确认没有意外开放的端口或暴露的服务版本。

🔎 实战:6 大协议分析案例

理论结合实践,来看最常见的故障场景如何通过抓包精准定位。

案例一:连接失败排查(TCP 三次握手)

场景:无法访问 VPS 上部署的网站(http://your_vps_ip:80)。

# 在服务器上抓取 80 端口的包
tcpdump -i any -n tcp port 80

分析思路:

  • 正常:SYNSYN,ACKACK(完整三次握手)。
  • 只看到 SYN:请求到达,但服务器未响应。可能是防火墙拦截或服务未监听(用 ss -tlnp 确认)。
  • 有 SYN,ACK 但无后续:服务器回应了但客户端未收到。可能是中间网络问题(如被墙)。
  • 看到 RST:服务器直接拒绝连接,通常是端口上没有服务在运行。

案例二:网络缓慢排查(TCP 重传)

场景:网站加载非常慢,或者文件下载速度远低于预期。

分析思路:

在 Wireshark 中输入显示过滤器 tcp.analysis.retransmission。如果看到大量黑色背景、红色字体的条目,说明网络存在严重丢包,TCP 不断重发数据,这是速度慢的根源。建议结合 mtr(第22篇)进一步定位丢包节点。

案例三:DNS 解析排查

场景:网站无法访问,但 ping IP 地址是通的。

# 在服务器上抓取 DNS 查询包
tcpdump -i any -n udp port 53

分析思路:

执行 curl google.com,正常应看到发往上游 DNS 的查询请求(Query)响应(Response)。如果只有请求无响应,说明 DNS 流量被拦截或上游服务器故障。

案例四:排查恶意 CC/DDoS 攻击

场景:服务器负载突然飙升,带宽被占满,怀疑被恶意攻击。

# 抓取 1000 个 SYN 包并统计来源 IP 的连接数(排查 SYN Flood)
tcpdump -i any -n -c 1000 'tcp[tcpflags] & (tcp-syn) != 0' \
  | awk '{print $3}' | cut -d. -f1-4 | sort | uniq -c | sort -nr | head -n 10

# 扩展版:持续监控 + 自动封禁超过阈值的 IP(需要 root)
tcpdump -i any -n 'tcp[tcpflags] & (tcp-syn) != 0' 2>/dev/null \
  | awk '{print $3}' | cut -d. -f1-4 | sort | uniq -c | sort -nr \
  | awk '$1 > 100 {print $2}' \
  | xargs -I{} ufw deny from {} to any

分析思路:

这个单行脚本会抓取包含 SYN 标志的连接请求,并自动统计出请求次数最多的前 10 个源 IP。如果某个单 IP 短时间内发出海量 SYN 请求,说明遇到了典型的 SYN Flood 攻击

案例五:HTTPS 证书问题排查

场景:浏览器报"证书无效"或 curl 报 SSL 错误,或 Let's Encrypt 证书续签后仍出问题。

# ── 案例五:HTTPS 证书问题排查 ─────────────────────────────────────────────

# 1. 用 openssl 检查证书详情(最直接的方式)
openssl s_client -connect yourdomain.com:443 -servername yourdomain.com 2>/dev/null \
  | openssl x509 -noout -text \
  | grep -E "Subject:|Issuer:|Not After|DNS:"

# 2. 检查证书有效期(快速查看是否过期)
echo | openssl s_client -connect yourdomain.com:443 2>/dev/null \
  | openssl x509 -noout -dates

# 3. 用 tcpdump 分析 TLS 握手(排查 SSL 协商失败)
tcpdump -i any -nn -w /tmp/tls.pcap port 443
# 抓包后用 Wireshark 过滤:ssl.alert_message 查看 TLS 告警

# 4. curl 详细 SSL 错误信息
curl -v https://yourdomain.com 2>&1 | grep -E "SSL|TLS|certificate|error"

# 5. 检查 Nginx 当前加载的证书
nginx -T 2>/dev/null | grep -E "ssl_certificate |ssl_certificate_key"

分析思路:

openssl s_client 是排查 HTTPS 问题最直接的工具。常见错误:证书过期、中间证书链不完整(应使用 fullchain.pem 而非 cert.pem)、域名不匹配。

案例六:SSH 超时排查

场景:SSH 连接超时或一直卡在密码/密钥认证,无法登录服务器。

# ── 案例六:SSH 连接超时排查 ────────────────────────────────────────────────

# 1. 首先确认基本连通性(区分"网络不通"和"SSH 服务问题")
ping -c 4 VPS_IP            # ICMP 通不通
telnet VPS_IP 22             # 22 端口通不通(比 SSH 更底层)
nc -zv VPS_IP 22             # 同上,更简洁

# 2. SSH 详细调试模式(-v/-vv/-vvv 逐级详细)
ssh -vvv user@VPS_IP
# 重点看日志中卡在哪一步:
#    "Connection established" → 网络通,SSH 服务在运行
#    "Authentications can continue: publickey,password" → 到了认证阶段
#    长时间无响应 → 通常是 iptables 封了或 SSH 配置问题

# 3. 用 tcpdump 在 VPS 上确认连接是否到达
tcpdump -i any -n port 22
# 如果有 SYN 包但没有 SYN-ACK → sshd 未运行或被防火墙封
# 如果有完整握手但断开 → 认证配置问题(/etc/ssh/sshd_config)

# 4. 检查 sshd 是否在运行及监听情况
systemctl status sshd
ss -tlnp | grep :22

# 5. 检查防火墙规则
ufw status
iptables -L -n | grep 22

# 6. 查看 sshd 认证日志
tail -50 /var/log/auth.log | grep sshd

分析思路:

先用 ping 确认 IP 可达,再用 telnet IP 22 确认 SSH 端口可达,再用 ssh -vvv 看卡在哪个认证步骤。如果连 VPS 控制台(VNC)都进不去,说明防火墙把所有流量封了。

🛡️ 安全与最佳实践

🔒 保护隐私

数据包中可能包含未加密的密码、Cookie 等敏感信息。不要在公共场合分析抓包文件,并确保妥善保管 .pcap 文件,用完即删。

🎯 精准过滤

抓包前先思考清楚要排查的问题,使用最精确的过滤规则抓取最小的必要数据集,这会极大提高分析效率。

⏱️ 短时抓取

除非必要,不要长时间持续抓包——会消耗 CPU 和磁盘 I/O,并产生巨大文件。使用 -c 限制包数或 timeout 限制时长。

常见问题解答

tcpdump 抓包时会影响服务器性能吗? +

会有影响,主要取决于流量大小。建议始终加过滤表达式,并将抓包文件直接写到 /tmp 下的内存文件系统。

tcpdump 看不到 HTTPS 的内容? +

HTTPS 是端到端加密的。可通过 SSLKEYLOGFILE 导入 Wireshark 解密,或直接查看服务器侧的应用日志。

如何找出哪个进程在占用网络带宽? +

使用 ss -tnp、nethogs 或 bandwhich 工具。

Wireshark 显示过滤和 tcpdump 的 BPF 过滤语法为什么不一样? +

BPF 运行在内核态(高性能过滤原始包),显示过滤运行在用户态(协议深度解析),两者语法完全不同。

为什么 tcpdump 抓不到 127.0.0.1 的包? +

需指定 -i lo 接口。

TIME_WAIT 连接多正常吗? +

少量正常。大量说明短连接过多,需调优内核参数。

nmap 扫描不到端口? +

可能被防火墙拦截,或者是在扫描 CF IP 而非源站。

抓包文件太大怎么处理? +

使用 -C 参数按大小分割文件,或实时管道输出给 Wireshark。

数据包重传严重怎么修? +

通常是物理线路质量问题,检查 mtr 报告确认丢包节点。

学会抓包下一步做什么? +

结合 SSL 证书管理与全球路由原理,完成全系列 30 篇的学习。