页面请求明明成功了Wireshark里却搜不到HTTP换了几个过滤条件最后只剩下零星ACK。很多人会继续折腾表达式但真正的问题经常发生在过滤之前数据包根本没有经过当前抓包点或者经过了却已经不是你以为的明文HTTP。抓包排错最好先回答三个问题在哪里抓、抓到了什么协议、过滤发生在哪个阶段。先确认流量是否经过这块网卡一台机器可能同时有有线网卡、无线网卡、VPN虚拟接口、容器网桥和回环接口。浏览器访问127.0.0.1时流量通常走回环接口连接公司VPN后目标网段可能走隧道Docker容器之间通信也未必经过宿主机的物理网卡。在开始捕获前可以先确认目标地址和路由ip route get 目标IPmacOS或Windows上也应查看当前路由表和活动接口。不要根据网卡名称猜测先确认系统实际选择的出口。如果不确定在多个相关接口上短时间捕获并用一个容易识别的动作制造流量例如刷新一次页面或执行一次DNS查询。找到正确接口后再缩小范围避免一次抓取产生几百万个无关数据包。捕获过滤器和显示过滤器不是同一种语法Wireshark有两层过滤捕获过滤器在数据包进入文件前执行使用BPF风格语法例如host 192.0.2.10 and port 443。显示过滤器只隐藏已经捕获的数据包例如ip.addr 192.0.2.10 tcp.port 443。捕获过滤器写得过窄丢掉的数据无法在事后恢复。初次定位时可以不设捕获过滤器或者只限定主机确认协议和端口后再用显示过滤器分析。把显示过滤器语法填进捕获过滤器输入框也是“什么都抓不到”的常见原因。端口是443不代表能看到HTTP正文HTTPS会加密HTTP头和正文。未配置会话密钥时Wireshark通常只能看到TCP或TLS层的信息比如握手、证书、记录长度和连接关闭过程。先用这些显示过滤器确认连接确实存在tcp.port 443 tls.handshake.type 1能看到TLS ClientHello却看不到http.request并不说明请求消失了而是应用数据处于加密记录中。只有在你拥有合法调试权限并正确配置客户端导出的TLS会话密钥时才可能解密部分会话。生产环境的私钥并不等于可以解密所有TLS 1.3流量现代前向保密套件不会因为拿到服务器证书私钥就自动还原会话内容。现代浏览器可能根本没使用TCPHTTP/3通常运行在QUIC之上而QUIC使用UDP。只过滤tcp.port 443会把整条HTTP/3连接排除掉。可以先检查udp.port 443 quicHTTP/2虽然仍常运行在TLS/TCP上但多条请求会复用同一连接。你不能再简单地认为“一次请求对应一条TCP连接”。分析时应先找连接再结合流编号和时间关系判断业务行为。只看到ACK可能是捕获从中途开始如果捕获启动得太晚连接已经建立Wireshark自然看不到SYN和TLS握手。浏览器还会复用已有连接所以即使刷新页面也可能只产生新的加密应用数据和ACK。一个实用动作是开始捕获后关闭对应页面连接或使用新的无痕窗口再重新访问。测试环境中也可以用命令行客户端建立一条全新的连接。不要在未经允许的生产系统上为了抓包随意中断用户会话。校验和错误不一定来自网络在发送端抓包时Wireshark偶尔会标记TCP校验和错误。这可能是网卡校验和卸载导致的操作系统把数据交给网卡前抓包程序已经复制了尚未由硬件补全校验和的数据。若同一流量在接收端正常应用也没有重传异常就不能仅凭发送端这一条提示认定链路损坏。判断时应结合抓包位置、重传、接收端结果和接口卸载设置而不是看到红色提示就下结论。一套更稳的抓包顺序我的习惯是先不寻找“业务字段”而是逐层确认路由决定流量走哪个接口DNS是否解析到预期地址目标使用TCP还是UDP握手是否完成上层是TLS、HTTP/2还是QUIC是否具备合法的解密条件最后才按会话、流或字段过滤。例如排查DNS时先用dns排查某条TCP连接时可右键会话并跟踪流或者在确定编号后使用tcp.stream eq N。这里的N必须来自当前捕获文件不能从别人的教程里照抄。抓包工具的价值不在于“看到很多包”而在于用一个正确的观察点回答一个明确问题。把接口、过滤阶段和加密边界弄清楚通常就能解释大多数“请求去哪了”。想继续系统练习网络协议、流量分析和安全排错可以把本文的七步顺序带进隔离实验环境逐项验证。对应的网络安全课程学习入口可在这里查看。