网络排障实战：用Wireshark抓包分析定位故障全流程

很多人第一次接触网络排障的时候面前最让人头疼的东西就是那一排排从网卡上实时滚过去的数据包。完全看不懂也没有头绪只知道感觉网络卡但说不清卡在哪。而真正的网络排查高手大多是靠抓包工具把问题一帧一帧拆开用事实说话。这次就从一个空标题说起直接聊聊我在实际工作中最常用、也最有效的抓包分析方法把 Wireshark 从打开到定位故障的全流程都拆开讲清楚希望能给正在被网络问题折磨的朋友一点参考。我大概从 2016 年开始系统地用数据包分析来做网络排障。之前更多是凭着 ping、telnet、nslookup 这些命令瞎猜遇到“时好时坏”的灵异故障就完全没辙。后来真正静下心把 Wireshark 用熟练之后最大的感受是网络世界里没有玄学所有你感知到的问题最后都能在数据包里找到对应的证据链。这篇文章不打算讲那些枯燥的协议理论而是按照我平时排查的实际流程来走一遍从抓包姿势、过滤语法、协议拆解到几个高频故障的完整排查记录尽量做到你照着操作就能上手。1. 为什么一遇故障就要看包1.1 网络故障的三层定位思路很多人排障有一个误区一卡就重启路由器一慢就怪带宽一断就投诉运营商。其实网络路径上一共有三层最容易出问题的地方按排查先后顺序分别是链路层、网络层、传输层与应用层。链路层问题常见的是网线松动、交换机端口协商失败、Wi-Fi 信号干扰网络层问题集中在 IP 地址冲突、路由黑洞、MTU 分片异常传输层和应用层问题则表现为 TCP 重传、窗口为零、HTTP 超时、TLS 握手失败等。工具层面能覆盖这三层排查的抓包是最直接的。像 ping 和 tracert 只能帮你验证“通不通”但没法告诉你“为什么卡”“卡在哪个环节”。数据包分析则可以精确到具体是哪一台设备、哪一个端口、哪一次握手失败。我自己常用的一句话是先看包再动配置。没有数据包的支撑很多网络调整都像蒙着眼睛修车。特别是跨部门协作的时候给运维同事发一张 tcpdump 抓下来的 pcap 截图比描述十句“我这边很卡”都管用。1.2 抓包数据包里到底藏着什么一个标准的数据包拆开会包含这几层关键信息帧头Frame包含网卡的 MAC 地址、帧类型以及抓包工具加上去的时间戳信息。IP 层源 IP、目的 IP、TTL、协议类型、校验和。TCP/UDP 层源端口、目的端口、序号、确认号、窗口大小、标志位。应用层根据具体协议不同可能是 HTTP 请求行、TLS 证书信息、DNS 查询记录等。Wireshark 的图形界面把每一层都给你列在中间的 Packet Details 面板里。我们定位故障时重点看的是时间列、源/目的地址列、协议列以及 Info 列里显示的 TCP 标志位和重传提示。这几个字段配合过滤表达式能快速筛出问题包。1.3 抓包之外要有组合工具光有 Wireshark 还不够我在实战里通常还会备上这几个命令行工具配合使用工具用途常用场景tcpdump在服务器上做实时抓包服务器出网异常、内网延迟排查tsharkWireshark 的命令行版本批量分析 pcap 文件、提取统计信息netstat / ss查看连接状态和端口监听定位端口不通、连接数打满dig / nslookupDNS 解析排查域名解析失败、解析延迟比如在 Linux 服务器上排查问题一般先用 tcpdump 抓几十秒的包存成文件再拉到本地用 Wireshark 的图形界面分析。这样既不影响线上性能又能利用 Wireshark 丰富的分析手段。2. Wireshark 配置与抓包的正确姿势2.1 装好之后第一件事不是点开始Wireshark 的安装过程比较简单这里不展开了。但有一点要提醒在 Windows 上安装的时候需要注意是否勾选了 Npcap/WinPcap 驱动组件它是底层抓包的基础。如果没装抓到的是空包反复出现提示“No interfaces found”一般也是驱动问题。装好之后打开 Wireshark 会看到网卡列表。这时候不要急着双击先想清楚这几件事抓服务器的包还是客户端的包抓入方向还是出方向需要抓全部流量还是只要某个端口确定好之后再双击对应的网卡开始抓包。值得注意的是如果机器上有多个网卡比如有线和无线同时启用可能会抓到完全不相干的广播报文污染分析范围。我一般会在抓包前把不相关的网卡禁用或者用捕获过滤器从源头做限制。2.2 捕获过滤器与显示过滤器先搞混就废了这是新手最容易翻车的地方。Wireshark 里有两类过滤器作用时机完全不同类型作用时机语法示例场景捕获过滤器Capture Filter抓包前生效只抓符合条件的包tcp port 443只抓 443 端口流量减小文件体积显示过滤器Display Filter抓包后生效从已抓包中筛选显示tcp.port 443从抓包里筛出 443 端口流量捕获过滤器的语法是 BPFBerkeley Packet Filter风格比较简洁。显示过滤器则是 Wireshark 自定义的表达式功能更强支持字段级别的判断。两者的等号、端口写法完全不同混用的话要么抓不到包要么过滤无效。实践中我一般是这样配合的抓包阶段用捕获过滤器限定范围比如只抓 80 和 443 端口分析阶段再用显示过滤器做细分比如看 TCP 重传、看特定 IP 的流量。2.3 抓多长时间的包才算够判断网络故障需要多长的抓包时间没有固定答案更多取决于问题出现的频率。如果是复现性较强的问题比如每次下载到一半断开抓 30 秒到 1 分钟就能抓到证据。如果是概率性出现的“灵异故障”我建议在服务器上用 tcpdump 结合环形缓冲来抓tcpdump -i eth0 -w /tmp/capture.pcap -G 300 -W 12 tcp port 80这条命令的意思是每 300 秒生成一个新文件最多保留 12 个文件。这样相当于记录了最近一小时的流量一旦故障复现可以从环形缓冲的文件里找到故障时刻的数据。这个技巧在半夜出故障时特别好用省得一直守着现场。抓包文件的时间同步也很关键。Wireshark 左上角显示的是抓包机器的本地时间如果需要和多台设备的日志做比对最好在抓包前用 NTP 统一一下设备时间否则对不上时间线会很痛苦。3. 协议栈的实战解析3.1 TCP 三次握手不是只看 SYN 和 ACK很多人在看 TCP 握手的时候只盯着 SYN、SYN-ACK、ACK 这三个包的顺序有没有出现。但真正排障的时候我还会额外关注几个细节握手的 RTT从 SYN 发出到收到 SYN-ACK 的时间差代表了客户端到服务器一个来回的延迟。正常内网应该在 1ms 以下跨公网几十毫秒可以接受如果超过几百毫秒基本可以断定链路有问题。Window 字段SYN-ACK 里的 Window 值代表接收端公告的接收窗口。如果这个值很小说明服务器端接收缓冲区可能已经吃紧。MSS 值TCP 握手时会协商最大报文段大小MSS。如果两端 MSS 不一致可能引发分片或 PMTU 黑洞问题。在 Wireshark 中看到一个握手包 Info 列显示[SYN] Seq0 Win64240 Len0 MSS1460就可以双击展开看 TCP 层的 Options 字段检查 MSS、Window Scale、SACK 等参数的协商结果。排查“建连慢”问题时我会用 Wireshark 的统计功能Statistics - TCP Stream Graph - Round Trip Time Graph直接看握手 RTT 的分布比肉眼一个个点包快得多。3.2 HTTP/HTTPS 的延迟点定位HTTP 请求慢很多人第一反应是服务器处理慢。但通过抓包拆解你会发现慢的地方往往在几个不同的阶段DNS 解析阶段客户端发出 DNS 查询到收到响应的时间如果超过 100ms说明 DNS 服务器响应质量堪忧。TCP 建连阶段三次握手的时间。TLS 握手阶段ClientHello 发出到 ServerHello 返回的时间这个阶段涉及证书验证和密钥交换最容易出问题。HTTP 请求发送与响应阶段客户端发出请求到收到首字节的时间即 TTFBTime To First Byte。内容传输阶段收到首字节到接收完所有数据的时间受带宽和 TCP 拥塞控制影响。在 Wireshark 里可以给 HTTP 请求添加时间标记方式是在显示过滤器中定位到对应的 HTTP 请求包然后右键 - Follow - HTTP Stream把整个会话的交互脉络拉出来。我通常还会打开 Statistics - Service Response Time查看每个 HTTP 请求对应的服务器响应耗时分布。对于 HTTPS 流量默认是密文状态看不到 HTTP 层的内容。这时候有两种解法一种是在服务器端抓原始流量之前配置 SSLKEYLOGFILE 环境变量导出会话密钥再导入 Wireshark 解密另一种是在代理层终止 TLS 后明文抓取。前者在排障时更常见因为能还原出完整链路。3.3 实战示例从 TCP 重传到 HTTP 503有一次线上用户反馈某个下载服务经常中断登录服务器查了 Nginx 日志发现大量 503 错误。光看日志只能知道“服务不可用”但没法判断是应用崩溃、连接超时还是后端资源耗尽。我在前端服务器上抓了 60 秒的包过滤出 80 端口的流量。很快发现问题TCP 流中存在大量重传包然后是客户端反复发起 SYN 建连服务器一直不回 SYN-ACK。顺着时间线往下翻发现服务器在某个时间点之后对外部连接的响应突然断了。进一步检查系统发现是 conntrack 连接跟踪表满了cat /proc/sys/net/netfilter/nf_conntrack_max默认值通常是 65536而当时系统里堆积了大量 TIME_WAIT 状态的连接记录。抓到的包和 conntrack 数据两相结合很快就定位到了根因。这个案例让我印象很深如果只看 Nginx 日志可能还得折腾好一阵子有了数据包分析直接从传输层证据就能倒推回应用层问题。4. 几个常见故障的排查记录与避坑清单4.1 故障实录一连接被重置原因在 MSS 协商一次内部系统对接客户端请求总是间歇性失败重启服务后能撑一阵过会儿又不行。抓包后看到的现象是三次握手正常但在传输数据阶段客户端发了几个包之后服务器立刻回了一个 TCP RST把连接断开了。排查时我注意到客户端通告的 MSS 是 1400而服务器通告的是 1460。这说明客户端所在网络环境的 MTU 可能被限制在了 1440 左右。中间路由器如果不支持 ICMP 差错消息回传就会形成 PMTU 黑洞导致大包发不过去。这个问题的解决方案有两种一是把客户端网卡的 MTU 调低到和网络路径匹配二是在服务器端把 MSS Clamping 打开在 TCP SYN-ACK 里把 MSS 改写为更小的值。一般在路由器或防火墙上做 MSS Clamping 最省事iptables -t mangle -A POSTROUTING -p tcp --tcp-flags SYN,RST SYN -o eth0 -j TCPMSS --clamp-mss-to-pmtu4.2 故障实录二响应慢问题却在 DNS还有一次用户反馈“打开页面要转圈十几秒”。我以为是后端 API 响应慢抓包一看HTTP 请求在很短时间内就发出去了但浏览器等待响应的时间很长。继续追 DNS 流量发现客户端对某个内部域名发起了多次 DNS 查询每次都超时。原因出在客户端的 DNS 配置上主 DNS 指向了一个已经下线很久的服务器操作系统默认要先等主 DNS 超时才会切换到备用 DNS。这个等待时间就是用户感受到的“转圈”。解决办法很简单把客户端网卡的 DNS 改成可用的服务器或者调整 DNS 超时时间。但这类问题的普遍教训是在排查 Web 访问慢的时候最好先从抓包结果确认 DNS 阶段是否已经花了大量时间再往下看 TCP 和 HTTP 层。Wireshark 里可以用显示过滤器dns.time 0.1快速筛出耗时的 DNS 响应。4.3 整理一份高频问题的排查速查表现象关键线索常见根因连接超时只有 SYN没有 SYN-ACK防火墙拦截、服务器 backlog 满、路由不通连接被重置传输阶段出现 RSTMSS 协商问题、应用层主动断开、NAT 超时响应慢TTFB 长后端应用耗时、DNS 解析慢、代理转发慢丢包重传大量 TCP Dup ACK / Retransmission带宽瓶颈、网卡故障、链路质量问题间歇断流窗口突然变 0接收端缓冲区耗尽、应用层不消费数据明文流量异常HTTP 状态码大面积 5xx上游超时、限流、后端实例挂掉这张表是长期排障经验的浓缩。看包的时候先用一两个关键字把异常流量筛出来再结合表格里对应的线索继续深挖效率会高很多。4.4 我踩过的几个坑你们别再踩抓包排障虽然强大但实际操作中有不少细节坑任何一个都能让你白忙一晚上。抓错了网卡服务器上多块网卡抓包默认选中第一块但流量实际走的是另一块。抓完半天什么包都没有。正确做法是先确认路由ip route get 目标地址看出口是哪个接口。显示过滤器语法写错比如把tcp.port 80写成tcp.port 80结果过滤出来一堆无关包。Wireshark 对语法错误的字段会用红色背景提示需要留意状态栏的变化。时间戳混淆抓包机本地时间和服务器不一致导致分析时间线错乱。尤其是跨地域排障必须确认时间基准。抓包文件太大打不开默认 Wireshark 打开大文件会卡死。解决方式是切分文件或者只抓需要关注的端口降低数据量。忘了解密 HTTPS抓了一堆加密流量啥也看不到。记得设置 SSLKEYLOGFILE或者在服务器端临时用明文协议复现。这些坑单看都不算大但叠加在一起足以让一次排障变得异常漫长。每次踩完坑我基本都会更新一下自己的排障清单确保下次不会再犯。5. 进阶让抓包变成自动化能力5.1 用 tshark 批量分析 pcap 文件图形界面适合交互式排查但要处理多个 pcap 文件或者做定时统计命令行工具 tshark 就派上用场了。以下这个是提取每个 TCP 流统计信息的命令tshark -r capture.pcap -q -z conv,tcp执行后会有类似下面的输出TCP Conversations Filter: tcp | Frames Bytes | Duration | 192.168.1.10:52034 - 10.20.30.40:443 | 120 45 KB | 03.4521s | 192.168.1.11:51021 - 10.20.30.41:80 | 89 12 KB | 01.2032s |通过这个输出能快速看出哪条连接传输了多少数据、持续了多久从整体视角判断有没有异常的“大头”流量。5.2 用 Python 读取 pcap 做统计当 pcap 文件大到几百 MB且需要做更精细的统计时我会借助 Python 的 dpkt 或 scapy 库。以 dpkt 为例以下脚本可以统计某个时间段内的 TCP SYN 包数量import dpkt import datetime with open(capture.pcap, rb) as f: pcap dpkt.pcap.Reader(f) syn_count 0 for ts, buf in pcap: eth dpkt.ethernet.Ethernet(buf) if isinstance(eth.data, dpkt.ip.IP): ip eth.data if isinstance(ip.data, dpkt.tcp.TCP): tcp ip.data if tcp.flags dpkt.tcp.TH_SYN: syn_count 1 t datetime.datetime.utcfromtimestamp(ts) # 这里可以做更细的时间窗口统计 print(fTotal SYN packets: {syn_count})通过类似脚本可以结合业务日志和服务端监控做多维分析。特别是当你需要从数据包层面验证限流策略、连接数峰值时脚本比手动操作高效得多。5.3 数据包分析如何与监控体系衔接单纯的抓包分析是一种“事后排查”手段而更好的方式是将数据包特征转化为长期监控指标。比如我重点关注的几类指标有TCP 重传率通过抓包统计重传包占比超过阈值即告警。建连失败率SYN 发出后没有 SYN-ACK 的比例。TLS 握手耗时从 ClientHello 到 Finished 的平均耗时。连接重置率RST 包占总数据包的比例。这些指标可以接入 Prometheus配合 Grafana 做可视化。实际落地时通常在关键节点部署流量镜像把流量复制一份到分析服务器再做实时统计。这样出了问题第一时间有告警而不是等用户来投诉。6. 最后再给新手一个长期演进建议如果你刚开始学抓包分析我建议不要贪多求快。先把 tcpdump 基本用法练熟再配合 Wireshark 去分析本机访问网页的完整流程。等你能把一次 HTTPS 页面的加载过程从 DNS 解析到 TLS 握手再到 HTTP 数据传输完整复述出来网络基础这块就算基本过关了。我个人实际操作下来的体会是抓包分析真正难的不是工具本身而是建立“分层思维”。每一层有每一层的问题每种问题都有对应的字段特征。当你看着一屏数据包不再发怵而是能快速判断该看哪一列、该过滤哪些字段、该找哪一段时序的时候排障效率就能翻倍了。这篇文章里提到的每一类问题都是我在真实环境里反复撞过墙才总结出来的。如果你照着这些方法去抓包大概率能少走很多弯路。当然网络世界很大总会有更冷门的故障等着你但只要你手里握着数据包这件武器就没有什么问题是不能聊的。