企业官网建设流程全解析

做客户端这些年，我电脑里长年躺着至少四款抓包工具：Charles、Fiddler、Wireshark、Proxyman，最近又因为团队协作需要，把 TraceEagle 也拉进来做了几轮实测。五款工具我都在真实项目里跑过，不带“云评测”那种，而是拿真实流量、真实证书、真实弱网环境一点点验出来的。今天这篇就把它们放在同一张桌上，从定位、原理到实操区别完整讲一遍，顺便把“最新网络热词”里那些高频问题都扫进去，比如 Charles 手机抓包、Wireshark TLS 解密、Fiddler 弱网测试、Proxyman 抓 iPhone 之类的。

先给结论：没有哪款工具能包打天下。选抓包工具，本质上是选你想看哪一层的网络数据。有人只关心 App 调了哪些接口、返回值对不对，这类需求用 Charles、Fiddler 这类代理调试工具最顺手；但如果你怀疑是底层丢包、TCP 重传、DNS 异常，那 Wireshark 才是正经答案。Proxyman 在 macOS/iOS 开发者群体里口碑很好，TraceEagle 最近讨论度也明显上来了，可它们在原理层面和 Charles 是同一类东西，只是交互和定位各有侧重。

1. 五款抓包工具的定位与适用场景

1.1 一张表看懂五款工具的基本盘

这里要额外说一句版本问题。Fiddler 家族现在分成 Fiddler Classic 和 Fiddler Everywhere，前者是 Windows 上的经典免费版，后者是跨平台商业版，网上搜“Fiddler 安装教程”时先分清是哪个版本，否则很多菜单对不上。Charles 官方只有英文界面，网上流传的“Charles 中文版”“汉化包”基本都是老版本，我建议别折腾，英文菜单用几天就熟了，反而省掉很多版本坑。

1.2 按需求选型：你抓的是哪一层？

我给新人做培训时经常打一个比方：网络数据就像一栋楼，代理型抓包工具站在一楼大堂检查进出的人，能看到每个人的工牌、目的地和随身物品；Wireshark 则蹲在大楼门口的摄像头旁边，把每一帧经过的画面都录下来，包括车辆轮胎压过的痕迹。

这个比喻对应到实际场景就是：你用 Charles 打开一个 App 的接口，能看到 URL、Header、请求体、响应体、耗时，这是“业务层”；但你看不到 TCP 握手是几次、有没有重传、ACK 是否延迟。Wireshark 能清楚看到三次握手、乱序、重传，可默认情况下它看 HTTPS 报文是一堆密文，除非你额外配置会话密钥导出。两者并不矛盾，而是同一段网络流量在不同层切开的照片。

TraceEagle 我试用下来的感受是，它更想把“抓包”这件事变成团队协作流程：抓到的请求可以整理成报告分享，历史记录管理做得比 Charles 直观，界面也在往现代化方向靠。不过它的生态和资料目前远不如 Charles 和 Fiddler，遇到冷门问题基本只能自己摸索。如果个人用，我暂时不会拿它当主力；如果是团队需要统一工具、共享抓包结果，它可以作为一个备选。

2. 抓包原理差异：为什么同样的流量在不同工具里长得不一样

2.1 代理型工具：中间人解密是怎么发生的

Charles、Fiddler、Proxyman、TraceEagle 都属于代理型工具。你把手机或浏览器的网络代理指向电脑上对应端口后，所有 HTTP 请求会先经过抓包工具，再由工具转发到服务器。这一步很多人会忽略，觉得“我只是配了个代理而已”，但实际上工具在中间做了一个关键动作：对 HTTPS 来说，它既要和客户端完成一次 TLS 握手，也要和服务器完成另一次 TLS 握手，客户端实际上连的是抓包工具，而不是真正的服务器。

为了让客户端信任这个“中间人”，就必须提前把抓包工具生成的根证书安装到系统或手机里。客户端验证证书通过后，工具才能解密请求和响应。这就是为什么所有教程都反复强调“要装证书、要信任证书”。如果你只设置了代理却没装证书，看到的通常只有 CONNECT 记录和 TLS 握手报错，没有任何 HTTP 明文内容。

Charles 默认代理端口是 8888，Fiddler Classic 默认也是 8888，Proxyman 默认是 9090。这几个端口号建议刻在脑子里，配手机代理时最常用的就是它们。Charles 还支持一键开启 macOS 或 Windows 系统代理，浏览器抓包基本不用手动改系统设置，打开 Proxy > macOS Proxy 或 Windows Proxy 就能直接接管浏览器流量。

2.2 Wireshark 的旁路捕获模型

Wireshark 的原理和代理型工具完全不同。它直接调用网卡驱动抓取经过网卡的数据包，本身不参与连接，不修改流量，也不做转发。在 Windows 上，这个动作依赖 Npcap 或 WinPcap 驱动，所以安装 Wireshark 时通常会提示你同时安装 Npcap。如果安装失败，多数情况是没用管理员权限，或者系统里残留了旧版本的抓包驱动。

由于是旁路捕获，Wireshark 能看到所有经过网卡的数据包，包括广播、组播，以及不是发给本机的流量。这也是它能做 TCP 重传分析、DNS 排查、VLAN 标签解析的基础。它默认看到的是“线缆上的原始数据”，所以对协议的刻画最完整，你甚至可以逐字段展开 Ethernet、IP、TCP、HTTP 每一层的头部。

Wireshark 的“可视化”也很值得提一句。很多人只会看报文列表，但其实 Statistics 菜单里有一堆好东西：IO Graph 可以看流量速率变化，Flow Graph 可以看连接建立和断开顺序，TCP Stream Graph 可以看窗口变化和往返时延。做网络性能问题定位时，这些图比截图几十条报文有用得多。

2.3 原理差异带来的能力边界

代理型工具和 Wireshark 的能力边界非常清晰，我用一张清单来区分：

• 代理型工具能改流量：可以断点修改请求、响应，可以做 Mock 数据、重定向、弱网模拟；Wireshark 默认只能看，不改。
• 代理型工具看到的多是 HTTP 明文：Wireshark 更擅长看 TCP/IP、DNS、TLS 握手细节，底层的任何异常都逃不过。
• 代理型工具对 UDP、TLS 密文的细节基本无能为力：Wireshark 可以通过密钥日志还原 HTTPS 明文，也能直接分析 DNS over UDP。
• 代理型工具受代理协议限制，某些 App 不走系统代理就抓不到；Wireshark 只要数据包经过网卡就能捕获，不依赖 App 是否配合。

明白了这层边界，就不会再出现“我拿 Charles 调了半天还是看不到 TCP 重传”这种问法了。工具选型的目标，是根据问题去找最顺手的那把尺子。

3. 高频实操：手机 HTTPS 抓包、TLS 解密和弱网模拟

3.1 iPhone 和 Android 手机抓包的标准流程

手机抓包是搜索热度最高的场景，尤其“charles 手机抓包”“fiddler 抓包手机app”“proxyman 抓包 iphone”这类问题。标准流程其实都差不多，以 Charles 为例：

1. 电脑和手机连到同一个 Wi-Fi，确保能互相访问。
2. 打开 Charles 的 SSL Proxying，进入 Proxy > SSL Proxying Settings，至少添加一条*:443的规则，让它对 HTTPS 流量做解密。
3. 在手机 Wi-Fi 设置里把 HTTP 代理改为手动，服务器地址填电脑的局域网 IP，端口填 8888。
4. 手机浏览器打开 chls.pro/ssl，下载安装 Charles 根证书。
5. iPhone 还要多一步：去“设置 > 通用 > 关于本机 > 证书信任设置”，把 Charles 证书的完全信任开关打开。
6. Android 上，Android 7.0 之后 App 默认只信任系统 CA，不信任用户添加的 CA，所以很多 App 抓不到，这个下面细说。

Fiddler 抓手机 App 的步骤类似，但要在 Tools > Fiddler Options > Connections 里勾选 Allow remote computers to connect，然后重启 Fiddler，否则手机连不上代理端口。Proxyman 对 iOS 真机有专门的安装证书引导，对 iOS Simulator 更是可以直接开启代理，不需要手动填，体验确实省心，但真机测试仍然要走到证书信任那一步。

Android 是很多人踩坑的重灾区。你可能会发现浏览器能被正常解密，但打开 App 就显示证书校验失败，或者直接连接超时。根本原因是 Android 7.0 之后，应用默认不信任用户证书。想继续抓，通常需要把证书装进系统证书目录，或者目标 App 本身提供了允许自定义 CA 的调试开关；不少 App 还加了证书绑定（SSL Pinning），这时候普通抓包基本拦不住。做测试的同学至少要能解释清楚：抓不到不一定是工具没配好，很可能是对端应用的信任策略把路堵死了。

3.2 Charles、Proxyman 做 HTTPS 解密时的细节差异

Charles 第一次做手机抓包时，最容易漏掉的是 SSL Proxying 里的域名白名单。你只在 Location 里加了*:443，浏览器能正常解，但有些 App 的请求还是会显示为ssl或者直接乱码，原因往往是白名单没覆盖到目标域名。更稳妥的调试方法是先用*:443跑通全流量，确认目标域名后，再把白名单收紧到具体域名，避免无关流量干扰。

Proxyman 默认对 HTTPS 解密更主动，首次连接时会弹证书信任引导，整体流程对新手更友好。它还有一个很实用的功能，可以把某个请求直接存成集合，后续团队协作或自己复现问题都很方便。不过要注意，模拟器里的网络行为和真机还是有差异，模拟器通过宿主网络，代理配置虽然简单，但测弱网、测局域网延迟时，它模拟出的结果不一定等同于真机。

不管是 Charles 还是 Proxyman，都要注意“App 不走系统代理”的情况。很多即时通讯、音视频类 App 使用自研网络库，Socket 直连或者自定义 UDP 传输，这种流量代理型工具根本看不到。遇到这类问题别硬磕，该上 Wireshark 就上 Wireshark，配合抓包网卡或者镜像口才能拿到完整报文。

3.3 Wireshark 解密 TLS 的惯用套路

Wireshark 解密 HTTPS 的核心是拿到 TLS 会话密钥。现代浏览器和 curl 都支持通过环境变量导出密钥，设置方法如下：

Windows 上可以先在命令行执行set SSLKEYLOGFILE=C:\sslkey.log，然后从同一个命令行窗口启动 Chrome。macOS/Linux 则是先export SSLKEYLOGFILE=~/sslkey.log，再用命令启动浏览器。比如 macOS 可以写export SSLKEYLOGFILE=~/sslkey.log && open -a "Google Chrome"。

密钥写入文件后，在 Wireshark 里打开 Edit > Preferences > Protocols > TLS，在 Pre-Master Secret log 那一栏填上这个日志文件的路径，重新开始抓包，Wireshark 就能把 HTTPS 流量解成明文，能看到 HTTP/2、HTTP/3 的请求和响应内容。

这里有个非常常见的坑：环境变量只对设置它的那个 shell 以及从这里启动的进程生效。很多人设置完之后直接双击桌面图标打开浏览器，结果日志文件根本没生成，Wireshark 里当然也解不出明文。记住，一定要用命令行启动浏览器。另外，TLS 1.3 已经把密钥交换算法换掉了，以前抓 HTTPS 常用的“导入 RSA 私钥解密”方式基本失效，现在主流就是 SSLKEYLOGFILE，这个方向别走偏。

3.4 Fiddler 弱网测试的配置方法

Fiddler 做弱网测试是很多测试同学的第一反应，因为 Fiddler Classic 自带一个“弱网开关”：Rules > Performance > Simulate Modem Speeds，勾上之后就会模拟调制解调器级别的慢速网络。但这个开关比较粗糙，它只是固定延迟和固定带宽，真正做弱网用例时不够用。

更可控的办法是改 FiddlerScript。在 Fiddler Classic 里进入 FiddlerScript 选项卡，找到OnBeforeRequest函数，在里面加两行：

if (m_SimulateModem) { oSession["request-trickle-delay"] = "300"; oSession["response-trickle-delay"] = "300"; }

这样能模拟上下行都有 300 毫秒延迟的效果。想要细分不同场景，可以再叠加带宽限制，或者配合外部的网络工具做丢包。Charles 的 Throttle Settings 里有 3G、4G、5G 预设，也能自定义上下行带宽和延迟；Proxyman 的 Network Condition 同样支持这类模拟。

我个人习惯把弱网测试分成两种：第一种是验证接口超时和重试逻辑，用代理工具限制带宽、增加延迟就够了，操作简单，结果也好复现；第二种是要验证断线重连、弱信号切换，这种情况下光靠代理工具是不够的，最好用 Wireshark 抓包确认真正断点，再配合能丢包、能断流的网络损伤设备或软件。工具只能还原部分网络问题，想模拟全部真实网络环境是不现实的。

4. 常见问题与排查技巧实录

4.1 Charles/Fiddler 抓不到手机包的排查顺序

我见过最多的“为什么抓不到手机上的包”，问题基本出在代理、证书、端口这三件事上。这里给一套排查顺序，按顺序走完基本能解决 90% 的问题：

1. 先确认手机能访问电脑。在手机上打开浏览器访问电脑 IP 加端口，比如http://192.168.1.10:8888，能打开证书下载页面，说明网络通、端口通。
2. 检查电脑防火墙。Windows 上常有防火墙拦截 8888 端口，需要放行对应程序或端口。
3. 手机 Wi-Fi 里填的 IP 一定不能是 127.0.0.1。那是手机自己，不是电脑。
4. 确认代理端口和工具里监听的端口一致。Charles 默认 8888，Proxyman 默认 9090，Fiddler 需要勾选 Allow remote computers to connect 并重启。
5. 确认系统代理没被别的软件抢占。如果电脑上同时开着其他代理类软件，端口冲突会导致抓包工具收不到流量。
6. 证书下载、安装之后，iPhone 还要在“证书信任设置”里打开完全信任，否则 HTTPS 还是解不开。
7. 如果目标 App 开了 SSL Pinning，或者根本不走系统代理，那工具怎么配都可能抓不到，这时候要换思路，用 Wireshark 抓底层，或者从开发侧获取调试开关。

这里有个很容易被忽略的低级坑：手机和电脑连接的是同一个 Wi-Fi，但有些企业网络开了“AP 隔离”，设备之间互相访问不了。现象就是手机浏览器打不开证书下载地址，请求超时。遇到这种环境，先连手机热点或者交换设备再试，别浪费时间。

4.2 Wireshark 为什么只能看到 520 字节而不是 2090 字节？

“Wireshark 为何只能显示 520 字节数据，怎么显示 2090 个字节数据”是近期很热门的问题，常见于实验和协议分析场景。碰到这问题先别慌，通常不是数据丢了，而是把“单个包的捕获长度”当成了“上层业务数据长度”。

520 是某个分片或单个 TCP 段的长度，而 2090 很可能是整个 IP 报文或者 TCP 流重组后的上层数据长度。以太网 MTU 一般是 1500，一个大包会被网络层拆成多个分片，Wireshark 默认把这些分片分别显示。想看完整上层数据，可以做两件事：

• 菜单栏 Edit > Preferences > Protocols > IPv4，勾选 Reassemble fragmented IPv4 datagrams。
• 再到 TCP 协议设置里勾选 Allow subdissector to reassemble TCP streams。

打开重组之后，原来分散的几个包会拼成完整应用层数据，显示的字节数就会变大。如果还不行，再看看 Wireshark 当前显示的是哪一列。列表里的 Len 列只是当前帧长度，真正的 IP 包总长度要看 IPv4 头里的 Total Length 字段。另外，如果抓的是 802.1Q VLAN 报文，Wireshark 默认能解析 VLAN ID 和优先级，如果显示异常，可以在 IPv4 报文上右键 Decode As，强制按 VLAN 解析一次，一般就能看清。

4.3 系统代理残留导致的“Fiddler 卸载后上不了网”

这个坑我实在见过太多次，值得单独写一节。Fiddler 在 Windows 上运行时会修改系统代理设置，也就是 IE 的局域网代理设置。正常情况下，退出 Fiddler 会把系统代理恢复原状；但如果进程被强杀、系统异常关机、或者卸载流程没走干净，系统代理会一直指向127.0.0.1:8888，而抓包工具已经没了，流量转发不出去，自然“上不了网”。

遇到这种情况，先别急着重装系统。打开“控制面板 > Internet 选项 > 连接 > 局域网设置”，把“为 LAN 使用代理服务器”勾选去掉即可。如果想用命令处理，管理员权限打开 CMD，执行netsh winhttp reset proxy，这个命令会把 WinHTTP 代理设置重置为空。

更彻底一点，可以检查注册表：HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings，主要看ProxyEnable和ProxyServer。正常上网状态ProxyEnable应该是 0，ProxyServer应该为空或指向有效代理。改成 0 之后重启系统，基本就能恢复。这个问题本质上是工具对系统的副作用，Charles 和 Proxyman 同样会改系统代理，只是退出时处理得更干净。以后用完抓包工具，最好在菜单里关掉系统代理再退出，养成习惯能少踩特别多坑。

5. 综合对比与选型建议

5.1 核心能力对比矩阵

把五款工具放到业务能力维度上对比，会更直观：

光看功能列表，Wireshark 的底层协议分析能力是绝对碾压级的，但它不能替代代理型工具做接口调试和 Mock。反过来，Charles 在业务调试上非常顺手，但指望它判断“是不是 TCP 重传导致接口超时”就不现实了。所以我的态度始终是：把工具当工具，别把某一个工具当信仰。

5.2 我的个人选择建议

如果只能留一个，我会分场景给答案。Windows 上做接口和 App 测试，Fiddler Classic 的 AutoResponder 非常方便，免费也够用；macOS/iOS 开发者，Proxyman 的体验会更现代，键盘操作和界面都舒服；团队里需要大家统一抓包、分享明细，Charles 依然是通用性最高的选择，生态和教程最全；只要涉及网络底层排障，Wireshark 是必装项，没有替代品；TraceEagle 更适合想试试新工具、或者对结果协作有刚需的团队。

最后再分享一个我自己的使用习惯：遇到线上网络问题，我经常开着 Wireshark 和 Charles 两个工具一起跑，Wireshark 抓底层，Charles 看业务，各看各的，互不干扰。刚开始可能会觉得信息量太大，但只要明确这次的目标是“排查 TCP 层”还是“定位接口返回”，两个视图反而能让问题更快水落石出。抓包工具永远是为定位问题服务的，思路比工具本身更值钱。