企业官网建设流程全解析

页面请求明明成功了，Wireshark里却搜不到HTTP；换了几个过滤条件，最后只剩下零星ACK。很多人会继续折腾表达式，但真正的问题经常发生在过滤之前：数据包根本没有经过当前抓包点，或者经过了，却已经不是你以为的明文HTTP。

抓包排错最好先回答三个问题：在哪里抓、抓到了什么协议、过滤发生在哪个阶段。

先确认流量是否经过这块网卡

一台机器可能同时有有线网卡、无线网卡、VPN虚拟接口、容器网桥和回环接口。浏览器访问127.0.0.1时，流量通常走回环接口；连接公司VPN后，目标网段可能走隧道；Docker容器之间通信，也未必经过宿主机的物理网卡。

在开始捕获前，可以先确认目标地址和路由：

ip route get 目标IP

macOS或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流量，现代前向保密套件不会因为拿到服务器证书私钥就自动还原会话内容。

现代浏览器可能根本没使用TCP

HTTP/3通常运行在QUIC之上，而QUIC使用UDP。只过滤tcp.port == 443会把整条HTTP/3连接排除掉。可以先检查：

udp.port == 443 quic

HTTP/2虽然仍常运行在TLS/TCP上，但多条请求会复用同一连接。你不能再简单地认为“一次请求对应一条TCP连接”。分析时应先找连接，再结合流编号和时间关系判断业务行为。

只看到ACK，可能是捕获从中途开始

如果捕获启动得太晚，连接已经建立，Wireshark自然看不到SYN和TLS握手。浏览器还会复用已有连接，所以即使刷新页面，也可能只产生新的加密应用数据和ACK。

一个实用动作是：开始捕获后，关闭对应页面连接或使用新的无痕窗口，再重新访问。测试环境中也可以用命令行客户端建立一条全新的连接。不要在未经允许的生产系统上为了抓包随意中断用户会话。

校验和错误不一定来自网络

在发送端抓包时，Wireshark偶尔会标记TCP校验和错误。这可能是网卡校验和卸载导致的：操作系统把数据交给网卡前，抓包程序已经复制了尚未由硬件补全校验和的数据。若同一流量在接收端正常，应用也没有重传异常，就不能仅凭发送端这一条提示认定链路损坏。

判断时应结合抓包位置、重传、接收端结果和接口卸载设置，而不是看到红色提示就下结论。

一套更稳的抓包顺序

我的习惯是先不寻找“业务字段”，而是逐层确认：

1. 路由决定流量走哪个接口；
2. DNS是否解析到预期地址；
3. 目标使用TCP还是UDP；
4. 握手是否完成；
5. 上层是TLS、HTTP/2还是QUIC；
6. 是否具备合法的解密条件；
7. 最后才按会话、流或字段过滤。

例如排查DNS时先用dns，排查某条TCP连接时可右键会话并跟踪流，或者在确定编号后使用tcp.stream eq N。这里的N必须来自当前捕获文件，不能从别人的教程里照抄。

抓包工具的价值不在于“看到很多包”，而在于用一个正确的观察点回答一个明确问题。把接口、过滤阶段和加密边界弄清楚，通常就能解释大多数“请求去哪了”。

想继续系统练习网络协议、流量分析和安全排错，可以把本文的七步顺序带进隔离实验环境逐项验证。对应的网络安全课程学习入口可在这里查看。