企业官网建设流程全解析

我日常工作里经常干一件事：打开抓包工具，让某个“打死不承认是自己问题”的接口现出原形。项目一多，手上这台电脑里就同时躺着Charles、TraceEagle、Wireshark、Fiddler、Proxyman五个抓包工具。有人问，装这么多不累吗？答案是：没有哪个抓包工具能通吃所有场景。HTTP 接口调试、手机 App 抓包、底层网络协议分析、弱网模拟、数据 Mock，每个场景都有自己最顺手的工具。

这篇博客就把这几个工具掰开揉碎讲清楚：它们分别擅长什么、核心操作怎么做、遇到抓不到包应该从哪排查，以及我实际使用中踩过的坑和总结的选型思路。内容主要面向客户端开发、前后端联调、测试工程师和刚入门的网络协议学习者，有基础的也可以直接跳到第 5、6 部分看实操和排错。

1. 你以为的抓包，和实际要解决的抓包问题不是一回事

先说一个很常见的误解。很多人觉得抓包就是“装个 Fiddler、点一下开始，然后看列表”，实际上抓包工具做的事情差异非常大，有的工具抓的是应用层的数据，有的工具抓的是网络接口层的数据，两者根本不冲突，但很多人没搞清楚，导致拿着 A 工具去干 B 工具的活，最后得出“这工具不行”的结论。

1.1 五个工具的江湖地位：谁在替谁干活

这五个工具按底层原理大致可以分成两派：

• 代理型抓包工具：Charles、Fiddler、Proxyman。它们的工作原理是把自己伪装成一个 HTTP/HTTPS 代理服务器，客户端（浏览器、App、小程序）把请求发到工具监听的本地端口，工具再把请求转发给真实服务器。因为是中间人，所以能看到请求头、请求体、响应体，能断点修改、能 Mock 数据。但这一切的前提是：流量必须走它的代理。如果你抓的是 TCP/UDP 流量、非 HTTP 协议的流量，或者某个程序根本不走系统代理，它什么都看不见。

• 网卡型抓包工具：Wireshark、TraceEagle。它们直接通过底层驱动抓取网卡上流经的所有数据包，不管是什么协议、什么端口、哪个进程发出的流量，只要经过这块网卡就都能抓到。所以它能分析 TCP 三次握手、TLS 握手细节、DNS 查询、ICMP、VLAN 标签这些底层信息。但代价是，它看到的是海量的原始数据包，而且默认看不到解密后的 HTTPS 明文内容。

顺带说一句 TraceEagle。这款工具跟 Wireshark 走的是同一条技术路线，主打协议解析和可视化，在中文环境和上手友好度上有自己的优势，安装包更小、操作界面更贴近国内用户习惯，部分协议分析场景下能省不少事。不过在国内社区，它的知名度和教程数量确实还比不上 Wireshark。

1.2 先分清你要抓的“包”是哪一层的东西

这里打个比方。代理型工具像是快递中转站，你让它帮你收发快递，它就能拆开包裹检查内容、甚至往里面塞点东西再封上。网卡型工具像是安装在快递运输车上的监控摄像头，所有经过的车辆它都拍下来，能看到车里装的什么箱子，但看不到每个箱子里的详细物品清单（除非你有解密钥匙）。

所以当你决定用哪个工具之前，先问自己三个问题：

1. 要抓的内容是不是 HTTP/HTTPS 流量？是，用 Charles/Fiddler/Proxyman；不是（比如是数据库连接、SSH、自定义 TCP 协议），用 Wireshark/TraceEagle。
2. 我要不要修改请求或响应？要，优先考虑代理型工具，因为可以断点编辑；网卡型工具基本只能看不能改。
3. 我要分析的是不是协议交互细节？比如 TCP 重传、握手时间、DNS 解析过程、SSL 证书协商，这种底层层面的事情只有网卡型工具能胜任。

把这些问题想清楚，工具选型就解决了一大半。

2. HTTP/HTTPS 调试首选：Charles、Fiddler、Proxyman，三家之争

如果日常工作是前后端接口联调、小程序开发、App 接口调试，那几乎每天都在跟这三款代理型工具打交道。它们的基本逻辑一致，但在不同平台、不同场景下的体验差异很明显。

2.1 Charles：老牌跨平台选手，手机抓包的标准答案

Charles 在 macOS 和 Windows 上都有，国内用的最多。我最早用 Charles 是给一个 iOS App 抓包，那时候最大的感受是：在手机抓包这件事上，Charles 的流程最省心。装好证书以后，手机 Wi-Fi 代理指向电脑，请求就出现在列表里了，界面左边是域名结构树，右边是请求详情，非常直观。

Charles 的几个高频操作值得背下来：

• SSL Proxying Settings：要抓 HTTPS，必须先在这里添加需要解密的域名和端口，比如*:443。很多新手的坑就是没开启 SSL 代理，结果 HTTPS 请求只显示 CONNECT 一条，响应体全是乱码。
• Map Local：把指定请求映射到本地文件，这是 Mock 数据最常用的功能。比如服务端某个接口挂了，我可以直接让请求返回一个本地 JSON 文件，不依赖后端也能继续开发。
• Breakpoints：断点功能，可以拦截请求或响应，在发送前/返回前手动修改内容。调试签名逻辑、模拟异常响应的时候非常有用。
• Throttle Settings：限速模拟，可以模拟 3G、4G 网络的延迟和带宽，做基本的弱网验证。

2.2 Fiddler：Windows 调试老臣，弱网模拟与脚本能力是加分项

Fiddler 是老牌 Windows 工具，经典版 Fiddler Classic 至今免费，而新版 Fiddler Everywhere 则跨平台且收费。在很多国内团队里，Fiddler Classic 仍然是 Windows 环境下的默认选择。

Fiddler 相比 Charles 有几个差异化亮点：

• AutoResponder：跟 Map Local 差不多，可以针对 URL 规则直接返回本地文件或者自定义响应，支持正则匹配，非常适合批量 Mock 接口。
• FiddlerScript：用脚本自定义抓包逻辑。比如我想让所有.png图片请求返回 404，或者给某个请求自动附加一个 Header，用脚本几行就搞定，不用像 Charles 那样手动一个个配置。
• 弱网模拟：Fiddler 内置了Simulate Modem Speeds选项，打开就能模拟调制解调器级别的慢速网络。更精细的延迟、丢包模拟可以写 FiddlerScript，我用它做过 200ms 固定延迟的弱网测试。

有个很经典的坑：Fiddler 卸载后浏览器上不了网。原因很简单，Fiddler 在运行时改了系统代理设置（Windows 的 WinINET 代理），正常退出时它会恢复，但如果直接结束进程、系统崩溃或者卸载时没走正常流程，系统代理就卡在127.0.0.1:8888上，而 Fiddler 的监听端口已经没了，自然上不了网。解决办法是去 Windows 的“Internet 选项 → 连接 → 局域网设置”里，把“为 LAN 使用代理服务器”关掉。这个事我见过不止一次，每次都有人慌着重装系统，其实就这么简单。

2.3 Proxyman：给苹果生态开发者的现代化替代品

Proxyman 是最近几年在 macOS/iOS 开发者圈子里流行起来的工具，界面用 SwiftUI 写的，颜值和交互手感明显更现代。如果你主要在 Mac 上开发、又经常抓 iPhone 的包，Proxyman 是个非常好的 Charles 替代品。

Proxyman 的亮点：

• 原生支持 macOS 系统代理，启动后一键开启，不用去系统设置里手动配代理。
• iOS 抓包流程做得非常顺，通过 WiFi 连接后，直接扫码安装描述文件证书即可，不需要像 Charles 那样手动去“设置 → 通用 → 关于本机 → 证书信任设置”里多点一步……等等，这个步骤还是需要点的，但 Proxyman 的提示做得比较明确，不会让你干找。
• 分屏对比、脚本、Mock 功能都有，而且支持 GraphQL 的专用视图，处理 GraphQL 请求比 Charles 更直观。

不过要提醒一句：Proxyman 基本是苹果生态专属工具，Windows 上没有，跨平台团队要想统一工具，得权衡一下。

3. 协议分析利器：Wireshark 与 TraceEagle，把每一帧都看穿

如果说上面三款工具是“应用层调试器”，那 Wireshark 和 TraceEagle 就是名副其实的“网络显微镜”。它们能看到的不是“某个请求的返回值”，而是“网卡上每一个比特的流向”。

3.1 Wireshark：网卡级抓包的事实标准

Wireshark 的前身是 Ethereal，二十多年历史，是全球使用最广泛的开源网络协议分析工具。它的核心能力是协议解析，支持上千种协议的解码，从 HTTP、DNS、TCP、UDP 到各种工控协议、物联网协议，基本都能解析出字段含义。

我第一次用 Wireshark 是在学 TCP 协议的时候，看三次握手的过程。用 Charles 只能看到CONNECT和响应状态码，但 Wireshark 能让你看到 SYN、SYN-ACK、ACK 三个数据包的完整时序，以及 SEQ/ACK 号的变化，对理解 TCP 重传、滑动窗口这些概念帮助特别大。

新手必会的两个过滤器：

• 捕获过滤器（Capture Filter）：在开始抓包之前设置，直接决定哪些包会被抓到，语法基于 BPF，例如只抓 80 端口：tcp port 80，只抓某个主机的流量：host 192.168.1.100。
• 显示过滤器（Display Filter）：抓包时默认抓所有包，再通过显示过滤器筛选，这个是 Wireshark 最常用的操作。经典例子：http只看 HTTP 流量，tcp.port == 443只看 443 端口流量，ip.src == 192.168.1.1只看某个来源 IP 的流量，多个条件用and/or组合。

这两个过滤器的区别在于执行时机不同。捕获过滤器在抓包时就过滤掉的包，之后就再也看不到了；显示过滤器只是把界面上“藏起来”一部分包，数据其实还在。

追踪 TCP 流也是 Wireshark 里的高频操作。选中任意一个 TCP 包，右键选择“追踪流 → TCP Stream”，Wireshark 会把这次 TCP 连接中的所有应用层数据按顺序拼接起来，直接还原出完整的 HTTP 请求和响应，不用在几百个包里一个个翻。这对分析协议交互、从头到尾看一次完整请求非常方便。

3.2 TraceEagle：想追上前辈的新锐选手

TraceEagle 是相对新一些的抓包工具，同样走网卡抓包路线。我接触到它是因为有段时间 Wireshark 在 Linux 环境下老遇到权限问题，顺手试了下 TraceEagle，发现它把很多常用功能做成了可视化按钮，比如快速过滤出 HTTP 请求、一键定位 TCP 重传、按客户端 IP 聚合统计请求量，这些在 Wireshark 里需要写过滤器或者加统计图表的功能，TraceEagle 直接点按钮就能看到结果，对新人友好不少。

TraceEagle 目前比较适合的场景是：课堂学习、初学者入门、日常单机调试。如果你之前没接触过抓包，直接上 Wireshark 可能会被密密麻麻的包列表劝退，TraceEagle 的可视化和中文引导能帮你更快建立“包”的概念。

不过也要客观说一句，Wireshark 拥有庞大的插件生态和全网海量教程，遇到冷门协议、复杂抓包分析场景，还是 Wireshark 更有保障。TraceEagle 更适合做“启蒙工具”和轻量分析，两个工具并不完全是替代关系。

3.3 为什么有的包用 Charles 抓不到，Wireshark 却能抓到

因为代理型工具和网卡型工具的运行位置完全不同。

Charles/Fiddler/Proxyman 是应用层代理，只有在“流量明确经过工具监听的代理端口”时才能看到内容。有些 App 不走系统代理，或者直接在代码里忽略代理设置——比如 Android 里用了NO_PROXY，iOS 里实现了URLSession的connectionProxyDictionary但配置不正确，或者 Chromium 系浏览器开了“关闭代理”的命令行参数——那么流量就绕过 Charles，Charles 抓了个寂寞。

Wireshark 不一样，它工作在网卡驱动层，只要数据包从网卡过，它就一定能捕获到。这里面有个常见误区：Wireshark 默认抓的是本机的流量，不是局域网所有流量。想抓局域网其他设备的流量，需要在交换机上做端口镜像（Port Mirroring），或者在目标设备上配置 ARP 欺骗，后者在真实项目中已经不推荐使用了，只在实验室环境里见过。所以“Wireshark 能抓所有流量”这个说法要打折，准确说法是“Wireshark 能抓流经本机网卡的所有流量”。

4. 选型决策：五个工具到底怎么选，我给出的核心判断标准

工具从来不是越多越好，关键是知道什么场景下用什么工具。我把选型逻辑总结成一套自己的判断标准，从实践角度讲一讲。

4.1 按使用场景快速选型

4.2 我实际使用中五款工具的优缺点速查

这部分不带滤镜，基本是我在真实项目里用出来的体感：

• Charles：优点是多端一致、稳定、文档多、社区资料丰富，手机抓包流程被验证过无数次；缺点是商业授权价格偏高，即使付费后功能相比免费时代也没多太多，有不少人因此流向 Proxyman。
• Fiddler Classic：Windows 下免费且功能扎实，脚本自由度最高；缺点是老界面，现代感差，跨平台不行，而且新版 Fiddler Everywhere 收费后，功能边界从 Classic 到 Everywhere 有点让人困惑。
• Proxyman：现代 UI、苹果生态体验一流、GraphQL 支持好；缺点是仅限苹果平台，团队协作时如果同事是 Windows，选型会受限。
• Wireshark：协议解析之王，没有之一；缺点是有学习成本，默认抓包数据噪音大，新手容易迷失在海量包里。另外在 Windows 上安装时会提示安装 Npcap/WinPcap 驱动，有些企业电脑权限受限装不上。
• TraceEagle：初学友好、可视化做得好、中文环境轻量；缺点是生态和资料还不多，遇到非主流协议可能解析不了，专业场景下还是依赖 Wireshark。

说实话，我见过不少开发机里装了四个抓包工具，但实际每天都在用的可能就一个。这东西不求多，选“最匹配你当前项目平台和场景”的那个就够了。如果是新手，我建议先从一个代理型工具加一个网卡型工具入手，顺着我下面这份实操速成走一遍，比看十篇教程都管用。

5. 实操速成：从安装到解决一个真实问题

选型聊再多，最后都要落到一次能跑通的抓包上。下面给三个场景的完整实操流程，全部是我实际验证过的路径。

5.1 用 Charles 抓手机 HTTPS 请求：三步走（含证书安装与 Android 7.0 坑）

这是被问得最多的需求：手机连上电脑代理，但 Charles 里看不到包，或者能看到请求却显示乱码。标准操作如下。

准备阶段：电脑和手机连同一个 Wi-Fi

这一步最基础，但最容易翻车。公司网络里如果开了 AP 隔离，手机和电脑虽然都连了同一个 Wi-Fi，但彼此不能通信，代理就根本无法建立。

第 1 步：电脑启动 Charles，开启 SSL Proxying

菜单栏选择Proxy → SSL Proxying Settings，勾选 Enable SSL Proxying，在 Location 里添加*（代表所有域名和端口）或*:443。不开启的话，HTTPS 请求到了 Charles 这里只能看到一个 CONNECT，看不见具体内容。

第 2 步：设置手机 Wi-Fi 代理

手机连接同一个 Wi-Fi，进入 Wi-Fi 设置，把 HTTP 代理改为手动，服务器填电脑的局域网 IP，端口填 Charles 默认的 8888。Charles 里能看到Proxy → Proxy Settings确认端口。

这里有个排查技巧：如果手机设完代理后完全没有请求进来，先在电脑上ping一下手机的 IP，通了再检查代理设置。很多问题是公司网络隔离导致的，跟工具本身没关系。

第 3 步：安装并信任证书

手机浏览器访问chls.pro/ssl，下载 Charles 证书并安装。这里分系统：

• iOS：安装描述文件后，还要去“设置 → 通用 → 关于本机 → 证书信任设置”里把 Charles 的完全信任开关打开。漏掉这一步，HTTPS 请求会报证书错误。
• Android 7.0 以上：默认情况下 App 不信任用户安装的证书，所以即使装了证书，很多 App 的 HTTPS 流量还是抓不到——这是 Android 的安全策略，叫“Network Security Config”。调试时可以让开发在 App 的network_security_config.xml里加上调试用的信任配置，或者用系统证书安装方案，但后者对手机有 root 要求，不适合普通用户。

为什么会出现“证书明明装了，但还是抓不到”？绝大多数情况是漏了 iOS 的额外信任开关，或者 Android App 默认不信任用户证书。这两个坑占了此类问题的八到九成。

5.2 用 Fiddler 做弱网测试：不用写代码的两种方式

弱网测试是客户端测试里绕不开的环节，Fiddler 在这件事上做得很顺手，支持的方式有多种。

方式一：一键模拟慢速网络

打开 Fiddler，菜单栏Rules → Performance → Simulate Modem Speeds，勾选后所有请求都会被延迟。这种方式最简单，但只能模拟固定速度，没办法自定义延迟和丢包比例，适合快速冒烟测试。

方式二：用 FiddlerScript 自定义延迟

给OnBeforeRequest函数里加一段自定义延时：

if (oSession.HostnameIs("api.example.com")) { System.Threading.Thread.Sleep(2000); }

这段脚本的意思是：所有发给api.example.com的请求，在发出去之前先强制等待 2000 毫秒。只要会改这个函数，延迟时间、针对的域名、延迟规则都可以自定义，比菜单自带的选项灵活很多。

要注意的是，弱网测试不只是“加延迟”，还应该考虑丢包和带宽限制。FiddlerScript 里做丢包模拟相对麻烦，如果要做严谨的弱网场景，建议还是用网络层工具（比如 Linux 下的tc命令）或者在路由器层做流控，Fiddler 更多是快速验证。

5.3 用 Wireshark 抓取并分析网页请求：过滤器的正确写法

很多人问“Wireshark 怎么抓网站的数据包”，这里用一个最简单的场景演示：访问一个网站，抓取它的 HTTP 请求全过程。

打开 Wireshark，选择网卡开始抓包

笔记本通常有多个网卡，选择正在上网的那个——Wi-Fi 就选 WLAN，插网线就选以太网。双击网卡即可开始实时抓包。

访问目标网站，找到对应流量

访问网站会产生大量流量，如果只关心 HTTP 明文流量，在显示过滤器中输入：

http

如果目标站点是 HTTPS，HTTP 过滤看不到明文，需要输入目标 IP 过滤。先ping出网站 IP，然后在 Wireshark 里输入：

ip.addr == 网站IP

追踪流看完整请求

选中任意一条 TCP 包，右键 → 追踪流 → TCP Stream。Wireshark 会弹出一个窗口，里面按时间顺序显示了这个 TCP 连接上的所有请求和响应内容。这是分析请求头、请求体、响应体最快捷的方式。

分析耗时在哪一段

如果只关心请求的耗时，可以用统计功能：Statistics → Flow Graph可以看到连接时序图，Statistics → TCP Stream Graph → Time-Sequence Graph可以看 TCP 时序表现，用来判断是网络延迟还是服务端响应慢，非常直观。

6. 高频问题排查实录：这些坑我基本都踩过

这部分是把我在工作群里被问过 N+1 遍的问题整理成一个速查列表，每个问题背后都对应一个真实的“翻车现场”。

6.1 Charles / Fiddler 下手机代理配置后抓不到包

现象：手机设了代理，Charles 里毫无动静。

排查步骤：

1. 确认手机和电脑在同一子网，且没有 AP 隔离。
2. 确认电脑防火墙没有拦截 8888 端口。Windows 上第一次跑 Fiddler 或者 Charles，系统弹窗问是否允许联网，点取消的话后续就连不上，这个很常见。
3. 检查代理端口是否被占用或改动过。Charles 默认 8888，Fiddler 默认 8888，如果本机装了多款代理工具，端口会冲突。
4. 手机端检查代理服务器 IP 是否填错，这里容易把 IPv6 地址填进去，部分 App 对 IPv6 代理支持不好。建议电脑用 IPv4 地址。
5. 如果以上都正常，用手机浏览器访问http://www.gstatic.com/generate_204测试代理是否通，浏览器能打开说明代理链路没问题，问题可能出在目标 App 不走代理或证书没信任。

6.2 Fiddler 卸载后浏览器上不了网

现象：卸载 Fiddler 后，电脑浏览器打开任何网页都提示无法连接。

原因：Fiddler 非正常退出或卸载流程没有还原系统代理设置，Windows 的局域网代理还指向127.0.0.1:8888，但监听端口已经不存在了。

解决办法：打开“控制面板 → Internet 选项 → 连接 → 局域网设置”，把“为 LAN 使用代理服务器”勾选去掉，确定保存即可。实在找不到入口，可以在命令提示符执行：

netsh winhttp reset proxy

这个命令会重置系统级 WinHTTP 代理，一般能解决问题。建议卸载 Fiddler 前，先在 Fiddler 里正常退出程序，让它有机会还原代理设置。

6.3 Wireshark 里看不到 WLAN 或抓不到 VLAN 包

现象：Wireshark 网卡列表里没有 WLAN 选项，或者抓到的包没有 VLAN 信息。

原因排查：WLAN 网卡如果在 Windows 上抓不到包，通常是没装 Npcap 驱动，或者 Windows 的无线网卡在“混杂模式”下不支持。Npcap 是 Wireshark 在 Windows 上必需的抓包驱动，安装时一定要勾选“Support raw 802.11 traffic”之类的选项。

VLAN 的问题通常出在抓包网卡是普通访问口（Access Port），VLAN 标签在交换机入口就被剥离了，只有接 Trunk 口或者在虚拟交换机上配置了 VLAN 识别才能看到 802.1Q 标签。如果想抓带 VLAN 的包，抓包点必须放在 Trunk 链路或者镜像口上。

6.4 学习 / 练习场景中的典型疑问

“教材里的 pcap 文件打不开怎么办？”很多网络教材（比如《计算机网络：自顶向下方法》）配套的实验文件是.pcap格式，用 Wireshark 直接打开即可。如果打不开，先确认文件是否下载完整，再确认文件是不是用老版本格式，尝试用 Wireshark 的“导入”功能。实际做 TCP 实验时，重点观察 SEQ/ACK 号变化、窗口大小、重传标志，这些是考试和作业的常客。

“局域网里抓不到其他设备的流量是怎么回事？”Wireshark 默认只能抓本机网卡上的流量。想抓其他设备流量，需要交换机端口镜像或者物理层分光器，普通家庭交换机一般不具备端口镜像功能，所以抓不到是正常的，不是配置错了。

“HTTPS 流量在 Wireshark 里全是乱码怎么办？”这是 TLS 加密的正常现象。想要解密，需要拿到会话密钥或者服务器的私钥。在 Firefox 和 Chrome 里可以设置SSLKEYLOGFILE环境变量，把 TLS 会话密钥导出到文件，再在 Wireshark 的Preferences → Protocols → TLS里指定这个文件，就能看到解密后的 HTTP 明文。这个技巧在分析前端加密参数的时候特别实用。

“有些 App 的流量既能用 Charles 抓到又能用 Wireshark 看到，但内容对不上？”这大概率是 TLS 会话复用的差异。Charles 在做中间人解密时，它会自己跟服务器建立一条 TLS 连接，所以你看到的“内容”是 Charles 解密后的数据；而 Wireshark 看到的是原始流量，如果没配置密钥导出，就看不到明文。两个工具看到的数据在这层意义上不是“同一份”数据，自然会有差异。

这里再补一个小技巧：如果你的电脑上已经装了 Charles/Fiddler，又想在同一台机器上用 Wireshark 抓包，建议不要同时开启两个代理型工具，因为它们的默认端口都是 8888 或者互相冲突，容易导致代理设置错乱。我一般是在 Wireshark 分析底层问题时关掉 Charles，反之用 Charles 调试接口时关掉 Fiddler。

最后说说我的个人体会。抓包工具看起来是一款软件，实际上是一种“用证据说话”的工作方式。跟后端争执接口参数格式不对、跟网络同事说延迟高、跟测试说这问题只在特定网络环境出现，与其翻聊天记录和日志，不如直接抓一份包出来，把证据摆到桌面上。我身边很多开发从“遇到问题先问别人”变成“遇到问题先抓包”，往往就是在熟练使用其中一两个工具之后发生的。从哪个工具开始并不重要，重要的是先跑通一次完整的“抓包 → 分析 → 定位”流程，跑通之后，工具之间的差异你自然就能分清了。