企业官网建设流程全解析

桌面上一口气装着Charles、Fiddler、Wireshark、Proxyman、TraceEagle五个抓包工具，大概是很多人的常态。装这么多不是因为闲，而是每次打开它们的时候，心里都清楚：这次该干的事，未必是上次那个工具能干好的。这篇东西不打算把官方文档复述一遍，只讲我实际使用中怎么选、怎么配、怎么排障。

先说清楚一个基本事实：这五个工具虽然都被叫“抓包工具”，但“抓包”两个字在不同人嘴里完全是两码事。前端说的抓包是看接口请求参数，测试说的抓包是做弱网和Mock，网络工程师说的抓包是看TCP握手、看协议栈异常。这篇文章会把这几个维度拆开讲，把五个工具的主战场、上手步骤、常见坑都过一遍。适合刚入门想选工具的人，也适合已经用着某个工具但经常被问题卡住的开发者。

1. 先想清楚：这五个工具根本不是同一个物种

1.1 应用层代理与链路层分析：别把螺丝刀当电钻

Charles、Fiddler、Proxyman、TraceEagle是一类，Wireshark是另一类，这是理解整个选型问题的第一道门槛。

前面四个工具本质上是HTTP/HTTPS代理服务器。它们的工作方式是在你的客户端和目标服务器之间插一脚：手机或者浏览器把请求发给这个代理，代理再转发给真正的服务器，响应回来的时候同样经过它。因为流量都从它身上过，它自然能把你发出的请求、收到的响应完整摊开给你看。这也是为什么“代理”这个词会频繁出现在这些工具的配置里。这里说的代理是本地调试代理，纯粹为了解决“流量从哪走、能不能被看到”的问题。

Wireshark不一样。它不代理任何流量，而是靠网卡的混杂模式去复制链路上经过的数据帧。说得生动一点，前面那四个工具是“进饭店后厨帮你看看菜是怎么做的”，Wireshark是“坐在饭店门口，看所有进出的人手里提了什么”。它能看到的东西更多、更底层，但它不会替你把菜端上桌，也不会参与你的请求过程。

这个区别直接决定了你的使用场景。你在联调接口时发现参数不对，打开Wireshark一顿找，是能找着，但效率极低；反过来，网络丢包、TCP重传、DNS解析失败这类问题，你用Charles去看只会一头雾水，因为代理工具根本不展示网络层信息。

1.2 一张表看清五个工具的主战场

做工具对比最怕的就是列一堆参数，看完更懵。我用一句话加一个场景的方式，把五个工具的主战场先摆出来：

这不是什么严格参数表，而是我日常使用之后的经验划分。你会发现这五个工具里没有一个是“全都能打”的，真正的差别是你手里的流量从哪条路走，以及你想看到第几层的信息。

1.3 从使用场景反推工具，而不是从名气挑工具

我给团队新人做工具推荐时，从来不说“你用Charles吧，大家都用”这种话，而是先问他要解决什么问题：

• 在调App接口，想看请求参数、响应体、错误码：选Charles或Proxyman。
• 在Windows上调试桌面程序，或者想用脚本批量改请求：选Fiddler。
• 某个接口偶尔超时，怀疑是网络问题：开Wireshark抓TCP，别在代理工具里瞎猜。
• 只是临时想确认一个请求返回了什么东西，不想开重型工具：TraceEagle这种轻量方案能帮上忙。
• 在参加比赛或者分析一份pcap流量包：Wireshark是唯一能打的。

选工具的逻辑就一句话：你先搞清楚流量是从哪条路走的，再决定打开哪个软件。

2. Charles：老牌代理抓包工具的高频用法和我踩过的坑

2.1 代理原理弄不明白，后面全是玄学

Charles默认监听本地的8888端口。启动之后，它会主动把自己设置为系统代理，所以你打开浏览器访问网页，请求会先到Charles，再由它转出去。这也是为什么Charles没关、系统代理还开着的时候，浏览器可能直接没网。

明白这个原理，再看两个最常见的现象就不会慌：

• 为什么手机抓包要先在WiFi里填电脑的IP和8888端口？因为你要把手机的流量也引到Charles这个代理上来。
• 为什么有些App装了Charles的证书还是看不到HTTPS内容？因为那个App可能设置了SSL Pinning，也就是只信任自己内置的服务器证书，系统里的根证书对它是无效的。这一点要靠逆向或者框架绕过，不在工具配置范围。

代理抓包的前提是流量愿意从它这里走，这句话我每次排障都会默念一遍。

2.2 手机抓包三件套：代理、证书、SSL Proxying

手机抓包是Charles最高频的使用场景。完整走一遍通常是这样的：

1. 电脑和手机连到同一个局域网。
2. 电脑上执行ipconfig（Windows）或ifconfig（macOS/Linux），确认局域网IP。
3. 手机WiFi设置里找到“HTTP代理”或者“代理”，选择手动，填上电脑IP和端口8888。
4. 手机浏览器访问chls.pro/ssl，下载并安装Charles的根证书。
5. 在Charles菜单里打开Proxy -> SSL Proxying Settings，勾选Enable SSL Proxying，Location里填*:*，表示所有域名和端口都解密。
6. iPhone用户注意，装完证书之后还要到“设置 -> 通用 -> 关于本机 -> 证书信任设置”里，把Charles的证书开关打开。不做这一步，你看到的依然是密密麻麻的CONNECT请求，点进去全是黑洞。

这一步最坑的地方是顺序。很多人先配了代理、再装证书，结果发现只要Charles一开手机就上不了网，或者开了代理之后App一直转圈。这种情况九成是证书没装好或者没信任，先退回去看证书状态。

Android 7.0以上还有另一个大坑：默认情况下App不信任用户证书。你明明装了证书，Charles里却看不到解密内容。普通解决方案是让开发在networkSecurityConfig里允许用户证书，或者用已root设备把证书装进系统证书目录。这个属于Android安全机制，不是Charles的问题，但排查时要能想到。

2.3 弱网模拟和Mock数据是Charles的日常价值

很多人把Charles当成“看请求”的工具，其实它的强项是模拟一个不那么友好的网络环境。

弱网测试在Proxy -> Throttle Settings里，勾选Enable Throttling之后，可以设置带宽、往返延迟（RTT）和丢包率。我调App的超时逻辑时，经常把延迟调到500ms以上，带宽压到256kbps，然后盯着页面看loading状态、超时提示、重试机制是否按预期工作。这会暴露很多在办公室WiFi下根本发现不了的问题。

Mock数据这件事，Charles提供了Map Local、Map Remote、Rewrite三套能力：

• Map Local：把某个URL的请求直接映射到本地文件。联调时后端接口还没写好，我就在本地放一个JSON文件，先让前端把页面流程跑通。
• Map Remote：把线上环境请求重定向到测试环境，多用于切域名调试。
• Rewrite：允许你直接改请求头、响应头、请求体里的某些字段，不需要改代码。

举一个实际例子：有一次后端接口偶发返回500，前端要复现异常页面的样式但一直等不到。我用Map Local把那个接口指到本地一个固定返回500的JSON，页面样式直接复现。这里的思路是：工具不是用来解决所有问题的，而是帮你把不可控的外部依赖变成可控的输入。

2.4 注册码、汉化和合规这个话题

热词里有“charles注册码”“charles汉化”，这块我表达一下个人态度：商业软件该买还是买，注册码相关的东西我不展开，也不建议用不明的破解包。Charles的免费试用版虽然会时不时弹窗，但大部分开发调试场景都能撑住。如果公司预算确实卡得紧，开源方案如mitmproxy、whistle也能做代理抓包，只是配置和界面没那么省心。

汉化包也是一样，第三方汉化版本最好确认来源可靠，来历不明的包里夹带私货的例子不少。做开发调试的人，对装进电脑的未知程序应该有点敏感。

3. Fiddler：Windows生态里的全能选手，但代理残留这个大坑必须会排

3.1 Classic与Everywhere：先把版本选对

Fiddler的版本问题是新手最容易迷糊的地方。现在传的教程里，大部分老截图都是Fiddler Classic：免费、Windows专属、功能齐全，但微软收购后基本处于维护状态。Fiddler Everywhere是后来重写的跨平台商业产品，支持macOS和Linux，界面现代化了很多，但很多经典插件和脚本模型和Classic不通用。

我的建议很简单：如果你人在Windows、想尽快上手、预算也不多，直接用Fiddler Classic，老教程多，插件多，够用；如果你需要跨平台同步规则，或者看重界面体验，再考虑Everywhere。不用纠结“哪个更好”，你面对的问题比版本差异实际得多。

3.2 卸载后上不了网：代理残留的完整自救流程

这是Fiddler相关热词里最有价值的一个问题，值得认真说。

现象很典型：卸载Fiddler之后，浏览器突然打不开任何网页，有些程序报“代理服务器出现问题”，但微信、QQ这类自带网络逻辑的应用可能还正常。

原因说穿了就一句话：Fiddler在退出或卸载时，没能把系统代理设置恢复原样。它正常运行的时候，会把Windows的WinINET代理指向127.0.0.1:8888。如果你强杀进程、系统崩溃，或者卸载过程中途被打断，注册表里ProxyEnable和ProxyServer的值就留在了那里。系统此后依然把所有HTTP流量往一个已经不存在或已改代码的本地代理上送，自然上不了网。

自救流程按顺序来：

1. 打开“Internet选项”（Win+R输入inetcpl.cpl），切到“连接”标签，点“局域网设置”，取消勾选“为LAN使用代理服务器”。
2. 打开Windows设置 -> 网络和Internet -> 代理，把“使用代理服务器”关掉。
3. 管理员权限打开命令行，执行netsh winhttp reset proxy，重置WinHTTP代理配置。
4. 如果还不放心，打开注册表，定位到HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings，确认ProxyEnable的值是0，ProxyServer可以清空。

这里有个小经验：每次用完Fiddler，正常从菜单退出，别直接杀进程。很多代理残留问题根本不是卸载导致的，而是日常使用中强杀进程积累出来的。

3.3 弱网测试与脚本扩展：Fiddler不只是抓包

Fiddler的弱网模拟入口很好记：菜单Rules -> Performance -> Simulate Modem Speeds。这个选项直接模拟当年拨号上网的速度，效果非常猛，用之前做好心理准备。

更精细的做法是写FiddlerScript。打开FiddlerScript标签，找到OnBeforeRequest方法，插入类似这种逻辑：

if (oSession.URIContains("/api/order")) { oSession["request-trickle-delay"] = "2000"; }

意思是当请求URL里包含/api/order时，给这个请求加2秒的延迟。这种做法比全局模拟更贴近真实场景——只针对特定接口做弱网，其他接口保持正常，方便定位是哪个接口拖慢了整页加载。

AutoResponder是Fiddler做Mock的明星功能。使用方式很直观：把一个响应直接拖到右侧面板，勾选Enable Rules，写URL匹配规则，再勾选Unmatched requests passthrough。这样命中的请求会返回你拖进去的那个响应，未命中的请求正常放行。我在测试环境挂掉的时候，经常靠这个功能把关键接口指到本地保存的响应文件，让测试流程不被环境阻塞。

3.4 HTTPS解密失败的常见原因

Fiddler开启Decrypt HTTPS traffic之后，如果列表里依然看不到明文，按这几个方向查：

• 根证书没有安装到“受信任的根证书颁发机构”存储区。
• 客户端做了证书校验（SSL Pinning），这个无解，只能配合调试框架绕过。
• 系统时间不对。证书有有效期校验，系统时间差太多会让证书立刻失效。
• TLS版本兼容问题。旧版本Fiddler对新TLS加密套件支持不完整，升级到最新版能解决大部分情况。

我遇到过最蠢的一次，是电脑时间被手动调快了几天，结果所有HTTPS解密全部报证书无效，排查了半天才反应过来。

4. Proxyman：macOS/iOS开发者绕不开的新世代选择

4.1 为什么我说它是“给macOS开发者准备的Charles”

说实话，Charles到现在依然是功能非常能打的老工具，但它的Java界面在Retina屏和M系列芯片上越来越有种“上个时代”的感觉。Proxyman是原生macOS应用，启动快、内存占用低，界面风格也更贴近Xcode和系统工具的审美。

更关键的是它对模拟器的支持。用Charles抓iOS模拟器的包，你得手动给模拟器设置代理，有时候还得关心localhost到底是Mac还是模拟器自身。Proxyman可以直接检测到本机运行的模拟器，把流量拉进来，省去配置环节。这个“省事”看起来很轻，实际用起来能省掉很多烦躁。

Proxyman的免费版提供了基础抓包和视图对比，高级功能走订阅制。如果你只是偶尔看一下接口，免费版够用；如果是团队长期做移动端调试，买License省心。

4.2 iPhone抓包全流程：从配对到证书信任

Proxyman和iPhone配合的走法，和大部分代理工具类似，但它提供了一套相对完整的“连接引导”：

1. 打开Proxyman，确保代理已开启，记下端口。
2. iPhone连到和Mac同一个WiFi，在WiFi设置里把HTTP代理指向Mac的局域网IP和Proxyman端口。
3. Safari访问proxyman.io/ssl，下载根证书，按提示安装。
4. 安装完成后，一定记得去“设置 -> 通用 -> 关于本机 -> 证书信任设置”，把证书的信任开关打开。
5. 回到Proxyman，在设备列表里能看到iPhone已经连上，之后的所有HTTP/HTTPS流量就会显示在主窗口。

我特别喜欢的一点是Proxyman的对流对比视图：想对比同一个接口在不同环境下的返回，可以直接选中两条请求，右边就会出现字段差异，不用再手动人肉比对。这对于联调时排查“测试环境正常、生产环境异常”这类问题非常高效。

4.3 迁移成本和两个不迁移的理由

如果你已经在Charles里配置了一堆Map Local、Rewrite规则，换到Proxyman确实有迁移成本，规则没法一键导入，需要重新配。

但有两个情况我不建议换：

• 团队协作里规则文件都是基于Charles导出的，新人入职也按Charles培训，这时候强行换工具会增加沟通成本。
• 你根本不碰iOS和macOS生态，Proxyman的优势对你来说体现不出来。

如果不是这两种情况，新开一个项目时优先试试Proxyman，没毛病。

5. Wireshark：回到链路层，才看得懂真正的“包”

5.1 装了之后别急着抓包：先选对网卡

Wireshark安装时通常会让选装Npcap或WinPcap，这个别跳，没有底层驱动，抓包性能会差很多。打开Wireshark之后，第一个界面是密密麻麻的网卡接口。很多新手在这里就懵了：怎么这么多网卡？

有VMware、VirtualBox、WSL等虚拟网卡在，接口列表会非常乱。经验是先看“上行/下行”的实时波形，或者在命令行用ipconfig（Windows）和ifconfig（Linux/macOS）确认你自己在用的物理网卡的IP，再回到Wireshark选对应名字的接口。

抓本机回环流量有两个注意点：Linux上直接选any或者lo接口；Windows上要确认Npcap安装时勾选了对回环流量的支持，否则本地进程之间的通信抓不到。

还要说句大实话：在普通家用WiFi环境里，你是抓不到别人手机流量的。现在的AP普遍隔离客户端，交换机和网卡也不会把别人的数据包转发给你。拿Wireshark去“看邻居在干嘛”是错误预期，它是个网络诊断工具，不是万能监听器，前提是流量确实经过你的网卡。

5.2 两种过滤器别搞混，顺便解决你搜过的“VLAN tag”

Wireshark里有两个过滤器概念，看起来都叫过滤，但作用时机完全不同：

• 捕获过滤器：在开始抓包之前设置，基于BPF语法，只保留匹配的包。比如host 192.168.1.1 and tcp port 443。它的价值是减少抓包文件体积，尤其在高流量环境。
• 显示过滤器：抓完包之后再用，只影响“显示”，不影响已抓到的数据。比如ip.addr == 192.168.1.1 && tcp.port == 443。

新手最容易犯的错是把两种语法混用。在显示过滤栏里写host == 1.2.3.4，Wireshark会直接报错，因为host不是显示过滤器语法。

几个我常用的显示过滤器：

• http.request.method == "POST"：只看HTTP POST请求。
• tcp.analysis.retransmission：只看TCP重传包，网络质量排查必备。
• dns.flags.response == 0：只看DNS查询，不看响应。
• tls.handshake.type == 1：只看TLS握手里的ClientHello。

再说热搜里的“wireshark vlan”。如果你在交换机trunk口上抓包，通常能看到带802.1Q标签的帧。想过滤某个VLAN，显示过滤器写vlan.id == 100。但如果你在物理网卡上抓，却看不到任何VLAN标签，先别怀疑过滤条件，很可能是网卡驱动已经帮你把VLAN tag剥掉了，或者你插的口是access口而不是trunk口。这类问题属于链路环境，不换口子只看过滤器是解决不了的。

5.3 教材实验和CTF流量分析：Follow TCP Stream到底在看什么

热词里冒出来的“密码比赛中的wireshark的writeup”，以及“自顶向下第9版TCP实验”，其实是同一类技能：给你一个pcap文件，让你从里面还原出事件过程。

Wireshark里最常用的一招是右键 -> Follow -> TCP Stream。它会把一个TCP连接里双向的所有报文按顺序拼接成一段连续的流量。HTTP协议没加密时，你直接在弹出窗口里就能看到完整的请求行、请求头、请求体和响应体。比赛里抓到一个登录请求，过滤http.request.method == "POST"，Follow流，密码就躺在Body里等你urldecode。

不只HTTP，FTP的USER、PASS命令，SMTP的MAIL FROM、RCPT TO，Telnet的每一字节，都能用Follow TCP Stream还原，因为这些都是明文协议。

至于“自顶向下”那组TCP实验数据包，拿到手之后建议按这个顺序分析：

1. 过滤tcp.flags.syn == 1，找到三次握手的SYN、SYN-ACK、ACK。
2. 看序列号：SYN包占一个序列号，数据包序列号如何增长能反映出每个报文段携带了多少字节。
3. 看确认号：客户端发多少字节，服务端回应Ack到哪个位置，能推导出缓冲窗口。
4. 用tcp.analysis.ack_rtt字段看每个确认的RTT。
5. 打开Statistics -> TCP Stream Graph -> Time-Sequence (Stevens)，看序列号随时间的曲线，斜率就是发送速率。

这套流程做完，不仅作业能写完，对TCP滑动窗口和重传机制的理解也会比看教材文字深刻很多。

5.4 关于Wireshark解密HTTPS，我说点实话

很多人拿Wireshark抓了一堆443端口的包，发现全是TLS密文，问怎么解密。Wireshark的设计初衷就不是“装了根证书就能看明文”的代理工具。它解密HTTPS主要靠两种途径：

• 浏览器SSLKEYLOGFILE：Chrome、Firefox支持通过环境变量导出会话密钥。
• 服务器RSA私钥：你有服务器私钥时，可以在Preferences -> Protocols -> TLS里配置。实际场景里基本拿不到服务器私钥，所以这条路很窄。

常用的是第一种。具体操作：

1. 在系统里设置环境变量SSLKEYLOGFILE=/path/to/keys.log。
2. 从这个环境变量启动Chrome或Firefox，然后正常访问目标页面。
3. 打开Wireshark的Edit -> Preferences -> Protocols -> TLS，在(Pre)-Master-Secret log filename一栏填上同一个路径。
4. 抓包后，HTTPS流量里的数据就能在Follow TLS Stream里看到明文。

注意这里的“能解密”有一个前提：ClientHello里用的密码套件，密钥交换不能是前向保密的。但现在主流网站基本都是ECDHE这类前向保密套件，Wireshark之所以还能解，靠的是浏览器主动导出了会话密钥。这是“浏览器配合你”，不是Wireshark神奇。

另外，HTTP/3（QUIC协议）的流量这套办法目前搞不定，需要看这类流量的话别在HTTPS解密上死磕。

6. TraceEagle：冷门但值得一看的轻量方案

6.1 一个看起来很“小”但定位很清晰的工具

TraceEagle在五个工具里存在感最低，社区讨论也不多。我最初是在调一个Android WebView页面时接触到的。当时不想为一个临时排查去开配置繁重的工具，试了下发现它最大的优点就是轻：安装包小、启动快、界面干净。

它的核心能力和Charles、Fiddler一样，仍然是HTTP/HTTPS代理抓包。所以它的抓包原理没有新鲜花样：电脑上起一个代理端口，把客户端流量指过去，再通过安装根证书解密HTTPS。它的价值不在“有什么独家技术”，而在“把常用功能做到开箱即用”。对于只想知道“这个请求到底发了什么、返回了什么”的人，这种轻量方案反而比大而全的工具更顺手。

6.2 典型使用流程和几个容易踩的点

TraceEagle的典型使用流程大概是这样的：

1. 下载安装后启动，确认默认监听的代理端口。
2. 在目标设备或浏览器设置里，把HTTP代理指向电脑IP和这个端口；如果只抓本机请求，通常有“系统代理”开关可以直接打开。
3. 访问目标网址或启动App，请求列表会按时间显示出来。
4. 如果看HTTPS内容是密文，去证书设置面板安装根证书，安装方式和前面几个工具没有本质区别。
5. 基础的搜索、筛选、请求重放，以及简单的弱网模拟，通常也都有。

实际使用中要注意的几点：

• 别和Charles/Fiddler同时开着。它们都抢系统代理端口，代理端口一旦冲突，表现就是“工具里的请求断断续续，甚至一个都进不来”。
• 网上教程少，版本差异大。遇到界面和我描述的对不上，别死磕按钮位置，按照功能名称去找入口，按版本更新日志确认新功能。
• 轻量工具往往意味着规则能力弱。你想做复杂的Map Local、Rewrite，或者需要精细的弱网参数，TraceEagle这类工具可能比较勉强。

6.3 值不值得投入时间

如果只是偶尔抓包、临时确认一个接口返回，或者想在U盘里放一个免安装的“备用工具”，TraceEagle值得一试。如果是一个团队长期依赖抓包工具、需要沉淀规则和协作，我建议还是把主工具放在Charles、Fiddler、Proxyman这些成熟方案上。

选工具最怕“因为下载了所以必须使用”的心态，也怕“每个工具都用一点、每个都用不深”。更合理的做法是主备搭配：一个日常主力，一个应急备用。你开着主力工具的时候，记得把备用代理端口改掉或者直接退出。

7. 选型思路与现场排查速查

7.1 按角色选组合，比按排行榜选更实在

工具没有绝对的优劣，只有适不适合你正在做的事。我按常见角色给一套参考组合：

这只是一个起点。等你自己摸索出习惯之后，完全可以反过来，比如后端开发把Wireshark当主力。关键是别五个同时装一堆，然后每次都在想“我到底该开哪个”。

7.2 高频问题排查速查

把前面零散讲的几个高频问题集中放一个表，方便现场照做：

7.3 几条值得记住的实操经验

最后分享几个我摸了多年抓包工具后的真实体会。

第一，抓包前先想清楚流量走向。你问“怎么抓不到包”之前，先在脑子里过一遍：我的流量到底经过了这台电脑吗？如果App走的是自己的长连接、不走系统代理，那Charles装得再对也看不到。

第二，遇到“抓不到”先恢复原状再排查。把代理关掉，看原本的网络是否正常。正常说明是代理链路的问题，不正常说明系统设置已经被改坏了。这种二分法能把问题迅速缩小到“你改了什么”这个范围内。

第三，别过度依赖破解和汉化。工具出问题的时候，你连“是软件被改坏了”还是“自己配置错了”都分不清楚，那是最浪费时间的。

第四，抓包工具是调试手段，不是调试目的。很多问题其实不需要抓包就能推理出来，但抓包能帮你快速排除变量。工具再多，最终还是看你有没有把一层一层的流量逻辑梳理清楚。梳理久了，你拿到任何一个新工具的都只要十分钟上手，因为它们解决的是同一类问题。