企业官网建设流程全解析

干过几年开发和测试的朋友，基本都绕不开抓包这件事。不管你是排查接口报错、分析App流量、调试小程序，还是研究某个协议怎么交互，手机上的抓包需求永远是刚需。但你有没有发现，每次搜“手机抓包工具”，搜索结果特别乱：有人让你在电脑上装Fiddler、Charles，有人让你直接在手机上装个App，还有人甩给你一堆“XX抓包大师”的APK。新手很容易看懵，然后随便挑一个装上，结果要么抓不到包，要么抓了一堆看不懂的东西，最后不了了之。

实际上，这些乱象背后就两件事：装手机上的抓包工具，和抓手机的抓包工具，看起来都是“抓手机包”，但技术路线完全不同，解决的问题也不一样。这篇文章我就把这条线彻底捋清楚，从原理到实操，从工具选型到故障排查，一次讲透。无论你是刚入门的小白，还是想补全自己知识盲区的老手，这篇都能给你省下不少瞎折腾的时间。

1. 先搞清楚：你遇到的“抓包”到底属于哪条路

很多人第一步就搞错了，以为抓包就是装个软件就行。实际上，手机抓包涉及一个关键问题：数据包根本不经由你的软件，你怎么看到它？这就要引入“中间人”的概念。

1.1 两条路的本质区别：谁来当中间人

第一条路，抓手机的包：电脑端代理工具。

代表工具是Fiddler、Charles、mitmproxy、Burp Suite。原理是：手机和电脑连同一个局域网，手机把网络代理指向电脑的某个端口，那么手机发出的所有HTTP/HTTPS请求都会先经过电脑上的这个工具。工具在这里承担“中间人”的角色，把请求转发的过程中复制一份，或者直接解密查看。这种模式的优点是能在电脑大屏幕上操作，能联动其他调试工具，解密HTTPS能力强。缺点是需要额外配置手机和电脑的连接关系，步骤稍微多一点。

第二条路，装手机上的工具：手机本地抓包。

代表工具是HttpCanary、ReQable（手机端）、Packet Capture之类。原理是在手机内部创建一个本地代理或虚拟网卡，所有App的流量都经由这个本地组件转发，工具直接在手机本地记录数据。优点是便携、不需要电脑，适合临时看两眼；缺点是屏幕小操作受限，很多工具受限于手机系统权限，HTTPS解密能力不如电脑端方案，高级功能往往需要root或特殊权限。

这两条路不是谁替代谁的关系，而是适用场景完全不同。你如果是在工位上开发调接口，用电脑端代理最顺手；你如果在外面出差，想快速看一眼某个App请求了什么接口，手机本地工具更合适。所以“手机软件抓包有哪些”这个问题，答案天然就分成两个阵营。

1.2 为什么大家容易搞混这两条路

因为从使用者的视角看，它们都叫“手机抓包”，而且热门搜索词经常混在一起，比如“Fiddler手机抓包”和“手机抓包软件”会同时出现在搜索结果里。另外还有一类“抓包工具”本身挺模糊的：有些工具既有电脑客户端，又有手机App，比如ReQable，它在电脑上有客户端、手机上也有App，很多人就搞不清到底算哪一路。

我个人的习惯是这么区分的：如果核心操作发生在电脑上，手机只是“被引导的客户端”，那就算抓手机的方案；如果核心操作全在手机上完成，就算装手机上的方案。记住这个判断标准，后面选型就不会乱。

2. 抓手机的路：电脑端代理抓包全景拆解

这条路的本质是“电脑做网关，手机走代理”，逻辑上是一个代理服务器模型。下面从工具选型、配置环节、失败原因三个维度展开。

2.1 四款主流电脑端工具怎么选

这个领域的工具有很多，但真正经过市场检验、文档齐全、社区活跃的就那么几个。

说几个实际选型的心得。

Fiddler是Windows下我用得最多的，免费、功能全、文档多。它最厉害的一点是FiddlerScript可以写规则，比如对某个接口自动修改响应、自动打断点，这在调试特定场景时特别好用。缺点是界面风格比较老派，开多个Tab时信息密度大，新手容易慌。

Charles在macOS开发圈子里几乎是人手一份，界面干净，而且它对HTTPS证书的处理向导很人性化，一步步点下来就行，iOS开发调试体验极佳。缺点是需要付费授权才能长期用，虽然30天试用期也够学一遍，但商业环境下大家心里都懂。

mitmproxy是命令行工具，没有图形界面，但它有Python API，你可以写脚本对流量做自动化断言、自动保存。我一般用它做回归测试，比如批量验证几十个接口的返回状态，或者把抓到的请求回放。这条链路一旦跑起来，效率比鼠标点来点去高很多。

Burp Suite则是安全测试圈的标配，它在拦截、重放、爆破、扫描方面非常强，抓包只是它的基本功。如果你做的是接口安全测试、漏洞排查，直接用Burp，别纠结Charles还是Fiddler。

2.2 关键环节：手机和电脑如何建立信任

电脑端工具选好后，想让手机流量“自愿”从电脑这边走，核心是解决两件事：流量怎么过来和数据怎么解谜。

流量怎么过来的问题，靠的是HTTP代理。手机在Wi-Fi设置里手动配置代理IP为电脑的局域网IP，端口填工具监听的端口（比如Fiddler默认8888，Charles默认8888，mitmproxy默认8080）。设置好后，手机发起的HTTP请求就不是直连服务器，而是先发给电脑。这一步是“引路”。

数据怎么解谜的问题，靠的是CA证书。现在几乎所有App的接口都是HTTPS加密的，如果电脑端工具不进行中间人解密，你只能看到一串加密乱码。要解密，电脑上这个工具会生成一个自己的根证书，你需要先在电脑端导出这个证书，然后安装到手机上，并在手机系统设置里信任这个证书。之后，工具拿着这个证书就能伪装成服务器与手机“对话”，加密流量在电脑上被解开，然后再由电脑去和真正的服务器建立另一条加密通道。这就是经典的中间人代理解密流程。

这里有两个非常容易踩的坑。

第一个坑是Android 7.0及以上版本的“用户证书信任”限制。从Android 7.0开始，系统默认App不信任用户安装的CA证书，只有系统证书才会被信任。所以你明明把证书装到手机里了，但很多App仍然报证书错误或直接断网。解决方案要么是用旧版本手机，要么是root后把证书移动到系统证书目录，要么用Frida之类的框架做SSL Unpinning，要么用部分支持豁免的测试机型。这也是为什么网上总有人问“Fiddler抓不到手机App的包”。

第二个坑是iOS的证书信任开关。iOS装完证书后，还要到“设置-通用-关于本机-证书信任设置”里把对应证书的完全信任开关打开，否则Safari能访问网页，但App请求照样出错。这个步骤很容易漏。

2.3 抓不到包时的三类原因，一次讲清

电脑端方案出问题，绝大多数跳不出三类原因：代理没生效、证书没配好、App做了防代理/防抓包。

代理没生效的表现是手机流量完全没到电脑上，工具界面一片空白。检查方向：确认手机和电脑在同一个局域网；确认代理IP填的是电脑的局域网IP而不是127.0.0.1（这个错特别常见）；确认电脑防火墙放行了对应端口；确认工具确实处于监听状态。

证书没配好的表现是工具能看到请求，但响应内容是乱码，或者App直接提示“SSL握手失败”。检查方向：确认手机装的证书是不是电脑工具生成的那一份；确认Android 7+的特殊限制；确认iOS的完全信任开关；确认App有没有用客户端证书双向验证。

App做防抓包的表现是，你设置了代理后，App要么拒绝联网，要么把请求打回本地，甚至干脆启动崩溃。这不是你配置错了，而是对方App做了“代理检测”或“SSL Pinning”。这种情况通常需要配合Xposed、Frida等框架处理，回到“高级玩法”范畴。

3. 装手机上的路：本地抓包与免电脑方案

电脑端方案虽然强大，但总有场景你不想开电脑，或者手边根本没电脑。这时候手机本地工具就派上用场了。

3.1 主流手机本地抓包App及其真实水平

装手机上的工具，我按“是否root”分成两类，你的手机情况直接决定你能用到哪个档位。

无root也能用的方案：

• ReQable（手机端）：这是一个后起之秀，跨平台支持Android和iOS，界面现代，支持HTTP/HTTPS/WebSocket等多种协议，自带一个简单的规则引擎，可以在手机上直接改包重放。我实测过它在Android 12、13上的稳定性不错，对新手很友好。
• Packet Capture：原理是在手机本地建立虚拟网卡转发流量，无需root，安装后自动配置，基本是零门槛。但它的定位更偏“看一眼”，功能比较简单，适合快速验证，不适合复杂调试。
• Stream（早已停更）：历史上有段时间很多人用，现在已经凉了，就不推荐了，但遇到老帖子提到它别走弯路。

需要root或特殊权限的方案：

• HttpCanary（抓包精灵）：Android平台的老牌抓包App，界面上能看到请求头和响应体，还可以打断点并修改请求内容。不root也能用于HTTP流量抓取，但要解密HTTPS、安装系统证书、做到别人做不到的深度，必须有root权限。它的插件机制在root环境下很强，可以执行SSL Unpinning，很多普通工具抓不到包的场景它能顶上去。
• tcpdump：严格说这不是“App”，是一个命令行抓包程序。在root过的Android设备上运行tcpdump，可以把原始网络数据包保存为.pcap文件，再用Wireshark打开分析。它抓的是底层TCP/UDP包，不关心应用层协议，适合分析网络层问题。

3.2 特殊场景的本地抓包：蓝牙、USB、Wi-Fi

除了常规的HTTP/HTTPS流量，还有几个热词经常出现在抓包讨论里，这里一并说清楚。

蓝牙抓包，比如有人搜“红米K50怎么进行蓝牙抓包”。蓝牙抓包和手机App抓包不是一回事，它抓的是BLE/蓝牙协议层的数据包，不是HTTP请求。工具层面常用nRF Connect、Wireshark配合蓝牙嗅探器（如Nordic的Sniffer硬件），手机端只需要开启蓝牙调试日志模式。这类需求通常出现在IoT设备调试、蓝牙外设逆向场景里。

USB抓包，这个“抓包”指的是抓USB总线上的数据包，常见场景是调试USB外设驱动、分析手机USB通信。工具一般用USBPcap（Windows）、Wireshark的USB捕获或Linux下的usbmon，和手机网络抓包完全是两个领域。所以搜“USB抓包工具哪个最好用”时，别指望它和你手机App调试有什么关系，先确认你要抓的是哪个层面的数据。

Wi-Fi抓包，比如热词里的“AX210抓包”。AX210是Intel的一块无线网卡，因为它支持monitor mode（监控模式），配合Wireshark可以抓取无线空中的数据帧，用来分析Wi-Fi信号、握手过程、信道占用等。这也是无线网络分析方向的需求，和你手机上App的HTTP流量抓包是两个圈子。

3.3 两条路的取舍：什么时候必须上电脑端

手机本地工具用起来方便，但它有两个先天短板：算力有限，不方便做复杂分析；受手机系统权限限制，解密能力弱。

实际工作中我的判断标准很简单：如果只是看一两个请求，用手机端App够了；如果需要批量分析、修改请求重放、关联多个接口做链路追踪，或者目标App做了SSL Pinning，那手机端工具基本不够用，必须上电脑端方案，必要时还要配合Frida、Xposed这类框架。

另外，小程序抓包这个词最近特别火——微信小程序、支付宝小程序的请求走的是微信/支付宝宿主App的框架，普通手机端工具抓起来很别扭，但电脑端工具配合代理设置，能相对容易地捕获小程序流量。这又是一个“电脑端方案更适合”的典型场景。

4. 实操实录：用电脑抓手机App的完整流程

空谈原理没意思，我拿最经典的Fiddler为例，走一遍“电脑抓手机App”的完整流程。这套流程我已经跑过上百次，跟着做基本一次成功。

4.1 工具安装与基础配置

第一步，在电脑上安装Fiddler。装好后打开菜单“Tools > Options”，切到“Connections”标签页，勾选“Allow remote computers to connect”，确认监听端口是8888，然后点OK。这一步是让Fiddler允许来自局域网内其他设备的连接。这一步不做，手机代理过来说话会被直接拒绝。

第二步，在“HTTPS”标签页勾选“Capture HTTPS CONNECTs”和“Decrypt HTTPS traffic”，弹出的证书信任提示选“是”。首次启用时会生成一个Fiddler根证书，后续要用它给手机装。

第三步，查看电脑的局域网IP。命令行输入ipconfig（Windows）或者ifconfig（macOS），找到当前Wi-Fi/以太网卡对应的IPv4地址，记下来。比如常见形态是192.168.x.x。

4.2 手机端代理与证书安装

手机和电脑连同一个Wi-Fi，在手机的Wi-Fi设置中，找到当前网络的代理设置（不同手机菜单位置不同，一般在“修改网络->高级选项->代理”），选择“手动”，主机名填电脑的局域网IP，端口填8888，保存。

这时打开手机浏览器访问http://电脑IP:8888，页面会提供一个“FiddlerRoot certificate”的下载链接，下载并安装证书。Android安装证书时，选择“CA证书”类型（某些机型叫“凭据”）。

装完后注意：Android 7+需要额外处理，前面提过，这里再强调一遍——先把证书装到手机上，再通过adb或其他方式把证书转移到系统信任区，否则很多App不认。具体命令如下（需要在root设备上操作）：

# 将用户证书从用户区复制到系统区 # 证书文件名是证书的subject hash，可用openssl计算 openssl x509 -inform PEM -subject_hash_old -in FiddlerRoot.pem | head -1 # 假设输出是 a1b2c3d4 adb root adb remount adb push FiddlerRoot.pem /system/etc/security/cacerts/a1b2c3d4.0 adb shell chmod 644 /system/etc/security/cacerts/a1b2c3d4.0 adb reboot

iOS端则是在设置里安装证书描述文件后，去“设置->通用->关于本机->证书信任设置”打开开关，步骤比Android简单直观。

4.3 验证抓包与常见操作

证书配好后，打开任意一个App随便刷几下，再回到Fiddler界面，就能看到一条条密密麻麻的请求记录。点击任意一条记录，右侧“Inspectors”面板会显示完整的请求头、请求体、响应头、响应体。这就是最基本也最常用的“看包”操作。

如果你想对某个接口做断点调试，在命令行输入bpu 关键字，比如只中断包含“login”的请求，然后App再发请求时，Fiddler会在请求发出前停住，允许你修改请求体再放行。这是排查业务逻辑问题非常好用的功能。

如果你想修改响应，右键选中某条记录，选择“Break on Response”，等响应返回时修改响应体再放行。模拟错误返回、异常数据，靠这个功能搞定。

4.4 命令行方案：用mitmproxy实现自动化抓包

图形界面的Fiddler适合人肉操作，但如果你想自动化抓包，推荐走mitmproxy。它提供三个命令：mitmproxy（交互式界面）、mitmdump（纯命令行输出）、mitmweb（网页界面）。我通常用mitmdump跑脚本。

最简单的自动化场景是保存所有请求到文件：

mitmdump -w output.flow

或者写一个Python脚本，对每个请求打印URL状态码：

from mitmproxy import http def response(flow: http.HTTPFlow) -> None: print(flow.request.url, flow.response.status_code)

运行：

mitmdump -s myscript.py

手机设置代理到电脑的8080端口，装好mitmproxy的证书，脚本就能实时处理手机上每个请求。这在接口回归、压力测试前的数据采集阶段特别省事。我试过用这个方式跑一整晚，自动收集了上千条真实请求，直接存成结构化数据用于后续分析。

5. 高频问题排查与避坑笔记

最后把这些年遇到的经典问题整理成一个速查表，不管你是用哪种工具，对号入座就行。

这里有几个从实操里总结出来的额外心得，写出来供参考。

经验一：抓包前先确认目标App走的是什么协议。HTTP/HTTPS的用Fiddler、Charles都行；DNS、TCP等底层协议的用tcpdump配合Wireshark；USB、蓝牙、Wi-Fi空口这种完全不同的协议栈，先查清楚再选工具，别在错误的路上浪费时间。

经验二：证书是最大的坑，没有之一。前几年我在一个项目里抓某大厂App的包，配置完全正确，但就是抓不到，后来用Frida脚本把SSL Pinning绕过去才解决。从Android 7.0之后，证书信任问题就已经不是“装证书”这么简单了，它是抓包成败的分水岭。网上关于“app抓包失败”的提问里，十有八九都是栽在证书上。

经验三：优先用能导出.pcap的工具备份数据。Wireshark、tcpdump导出的pcap文件是通用格式，抓的时候直接存一份，后续想怎么分析怎么分析。用Fiddler虽然方便，但导出格式是.saz，还得转一次。养成好习惯，抓包不只为了“看”，还要考虑“留数据”和“再分析”。

经验四：新工具ReQable值得一试。它同时覆盖了电脑端和手机端，还支持Windows/macOS/Linux/Android/iOS，协议支持HTTP/HTTPS/WebSocket/TCP/UDP，界面也现代。如果你刚开始学抓包，不想在Fiddler的老旧UI上花时间适应，可以直接从ReQable上手。

经验五：抓包不是越多越好。很多时候打开App刷两下，Fiddler里就蹦出几十条请求。不要一条条看，先看请求时间线和域名分布，锁定业务相关的域名和接口，再去深入分析。信我，这样可以剩下一大半心力。

我个人在实际操作中的习惯是：日常工作用ReQable和Charles走图形界面，回归测试用mitmproxy跑脚本，排查网络底层问题用tcpdump加Wireshark。工具之间各有侧重，也各有不可替代的场景。手机抓包这条路一旦走通了，你对App背后每次点击发生了什么、每个数据是怎么流转的，都会有比以前清晰得多的认识。这个能力，值得花一个下午好好练一遍。