导 读
一次典型的“网站打不开”报修，运维工程师如果只查应用日志和Ping延迟，很可能在错误方向上浪费数小时。Wireshark的价值在于：它把DNS解析、TCP握手、TLS协商、HTTP响应这些抽象过程，变成逐包可见的时序证据链。
本文不讨论“抓包有没有用”这类空泛问题。我们直接进入一个可复现的示例场景，拆解从抓包到定位根因的完整路径，并给出你本周就能落地的检查清单。
目 录
01为什么“能Ping通”不等于“业务正常”
02抓包前的三个关键决策
03从DNS到TCP：逐层拆解示例故障
04三个可执行的检查命令与指标
05风险与适用边界
06本周可执行的检查清单
配图：为什么“能Ping通”不等于“业务正常”
Ping基于ICMP，只验证网络层可达性。而用户访问一个网站，背后至少涉及：DNS解析、TCP三次握手、TLS握手（HTTPS场景）、HTTP请求与响应。任何一环异常，Ping都可能是通的。
示例场景：某内部系统域名解析正常，Ping延迟稳定在2ms以内，但浏览器打开页面持续转圈，最终超时。应用日志无报错，负载均衡器健康检查显示后端“正常”。
此时如果继续在应用层和负载层排查，方向就偏了。正确动作是：在客户端与网关同时抓包，对比两端看到的流量差异。
三点抓包才能形成闭环。单点抓包容易陷入“我这边看没问题”的扯皮。
抓包时不做过滤，事后分析会被噪声淹没。推荐在捕获阶段就使用BPF过滤器：
# 只抓目标IP和端口 tcp port 443 and host 10.10.10.50 # 只抓DNS udp port 53 # 抓特定网段与HTTP tcp port 80 and net 192.168.1.0/24不要等“复现了再停”。建议设置捕获时长或包数上限，避免文件过大：
# 抓1000个包后自动停止 -c 1000 # 按文件大小轮转，每10MB一个文件 -b filesize:10240
配图：从DNS到TCP：逐层拆解示例故障
在Wireshark过滤栏输入 dns，观察：
常见坑：DNS响应返回了多个A记录，客户端选了其中一个不可达的IP。此时Ping其他IP是通的，但业务恰好走了坏IP。
过滤 tcp.flags.syn==1 or tcp.flags.ack==1，观察三次握手：
如果只看到SYN重传，没有SYN-ACK，说明请求未到达服务端或被中间设备丢弃。如果SYN-ACK的源IP与预期不符，可能存在负载均衡或NAT改写。
过滤 tls.handshake 或 http，观察：
示例根因：TLS握手阶段，服务端返回了证书链不完整的响应，客户端等待超时。Ping通、TCP通，但业务就是打不开。
在Wireshark中，Statistics → Service Response Time → DNS 可查看DNS查询与响应的时延。超过200ms需关注，超过1s基本可判定为解析瓶颈。
过滤 tcp.analysis.retransmission，统计重传包数量。重传率超过1%即说明链路质量存在问题，需结合 tcp.analysis.ack_rtt 查看往返时延。
过滤 tls.handshake.type==1（Client Hello）和 tls.handshake.type==2（Server Hello），计算两者时间差。超过500ms需排查证书链、加密套件协商或中间设备拦截。
抓包分析并非万能。以下场景需注意：
避坑指南：不要在故障未复现时盲目抓包。先明确“抓什么、在哪抓、抓多久”，否则抓到的文件既大又无用。
配图：本周可执行的检查清单
tcp port 443 and host <目标IP> 过滤，对比两端SYN包数量是否一致Statistics → Service Response Time → DNS，记录超过200ms的域名tcp.analysis.retransmission，计算重传包占总包比例
