手机抓包这件事，坑过的人比想象中多。上周帮一个做客户端接口调试的朋友看问题，他的诉求很朴素：想看看自家 App 在低端机上加载慢，到底是哪个接口拖了后腿。结果折腾了一下午，卡在同一个地方——证书装是装上了，抓包工具里却全是CONNECT和Tunnel to，看不到一行明文。原因不复杂，他手上那台机器是 Android 13，设置 → 安全 → 加密与凭据 → 安装证书装进去的东西落在用户证书区，而现在的 App 默认只认系统证书区。想往系统区塞，传统做法就是 root 真机，可这台机器还在保修期，主卡还绑着一堆银行类应用，动一次 root 的成本谁都清楚。
这次重新整理的 VMOS 真机抓包方案，核心就一句话：把需要 root 的那一段操作，搬进一个跑在手机里的虚拟 Android 系统去做，真机本身保持原样，一条命令都不用碰。整套链路适合三类人：做客户端/接口联调的前后端和测试同学、需要分析自家 App 网络行为的运维与性能优化人员、以及做移动端安全学习的同学。如果你之前卡在证书信任、代理不生效、SSL Pinning 这几道关口上，下面的内容可以直接照着复现。需要提前说清楚的是，这套手段只用于你拥有或有明确授权的应用，用于接口调试、性能分析、兼容性验证；拿它去碰别人的应用和数据，既没意义也不合规。
1. 从"抓包必 root"这句话说起：证书信任链到底卡在哪
1.1 Android 7.0 之后，用户证书为什么突然不灵了
要理解 VMOS 方案的价值，得先把这个历史包袱讲透。Android 7.0（API 24）之前的版本，系统对用户自己安装的 CA 证书几乎是"全盘接受"的，你把抓包工具的根证书装进用户区，所有 App 的网络请求就会乖乖走中间人解密，那时候抓包确实很简单。
从 Android 7.0 开始，规则改了：只要 App 的targetSdkVersion大于等于 24，它的网络栈默认只信任系统预置的 CA，用户区那一堆证书一概不认。除非开发者在network_security_config.xml里显式声明信任用户证书，否则你装一百遍也没用。表现就是抓包工具里清一色的CONNECT隧道记录，看不到 URL、看不到请求体、看不到响应，整个抓包过程变成了"我知道它有流量，但我什么都看不见"。
更麻烦的是 Android 版本越往上，限制越严。高版本系统里想往系统证书目录写文件，常规路径基本被堵死，剩下的办法要么解锁 BootLoader 刷入自定义 Recovery 再改系统分区，要么用 Magisk 类方案挂载一个可写的 system 覆盖层。这两条路的共同点是：动真机的系统分区，代价高、不可逆、还可能触发某些 App 的环境检测。
1.2 VMOS 的破局点：把 root 挪进虚拟机
VMOS 本质是一个跑在 Android 上的 Android。它在你手机里以普通 App 的身份存在，权限跟一个聊天软件差不多，但它在自己内部启动了一整套完整的虚拟 Android 系统。关键点来了：这套虚拟系统内部默认带 root 权限开关，你能在里面任意挂载/system为可写、任意往/system/etc/security/cacerts/里丢文件，而在宿主机看来，这一切只是"某个 App 在自己的沙箱里写自己目录下的东西"。
这就把问题彻底拆成了两半。真机端：不 root、不解锁、不刷机，系统分区纹丝不动，保修、OTA 升级、金融类 App 的环境校验全都不受影响。虚拟机端：随便折腾，证书装错了、ROM 跑崩了、Xposed 模块冲突了，直接删掉重装一个 ROM 包，几分钟的事。我自己的习惯是常备两个 VMOS 实例，一个专门用来跑抓包和测试，另一个保持干净，避免测试环境互相污染。
顺带说一句 VMOS 的另一个隐性好处：它是可快照、可丢失的环境。有些应用会在本地留一堆缓存、设备指纹、登录态，测完想彻底清干净很费劲。虚拟机上直接删掉重建，等于每次都在一台全新设备上做验证，这对复现"首次启动慢"这类问题特别有用。
1.3 先讲清楚这套方案做不到的三件事
任何方案都有边界，先把话说在前面，省得你白折腾。
第一，它解决不了强 SSL Pinning。如果 App 在代码里硬编码了服务端证书的指纹，或者在 native 层用 BoringSSL 自己做了校验，那么证书装得再规范，TLS 握手一样会在校验环节断掉。Java 层的 Pinning 还能靠 Xposed 类模块绕一绕，native 层的通常只能上动态调试工具去 hook，成本陡增，很多时候不如直接找开发要一份测试环境的明文日志。
第二，它抓不到非 HTTP(S) 的流量。如果你的目标是分析自研 TCP 私有协议、游戏心跳包、或者 QUIC/HTTP3 的连接迁移行为，中间人代理这套完全用不上，得换思路，用 root + tcpdump 直接落原始数据包，再导到 Wireshark 里解析。好在 VMOS 有 root，这条路反而比真机顺畅。
第三，部分应用会检测虚拟化环境。有些 App 启动时会检查设备是否为虚拟机、是否有 Xposed、是否设置了代理，命中任意一条就直接拒绝服务。这类应用在 VMOS 里可能连首页都进不去，这个后面第 6 节会专门讲应对思路。
2. 动手之前：VMOS 版本、ROM 和真机环境的取舍
2.1 VMOS 与 VMOS Pro 的差别，以及 ROM 版本怎么选
VMOS 系产品线不算复杂，但版本差异对抓包成功率影响很大。核心选择在于装哪个 Android 版本的 ROM 包，这直接决定了证书目录路径、Xposed 可用性和目标 App 的兼容性。
| ROM 版本 | 证书系统目录 | root 开关 | Xposed 支持 | 抓包适配度 |
|---|---|---|---|---|
| Android 5.1 | /system/etc/security/cacerts | 自带 | 支持 | 兼容老 App，但新版 App 装不上 |
| Android 7.1 | 同上，规则标准 | 自带且稳定 | 支持较好 | 综合最优，推荐首选 |
| Android 9.0 及以上 | 同上 | 视 ROM 而定 | 支持有限 | 新 App 兼容好，模块生态偏弱 |
我实测下来的结论是：做抓包优先选 Android 7.1 的 ROM。它正好卡在那个"证书策略已经变严、但 root 环境还很好搞"的甜点区，cacerts目录结构标准，文件管理器加 root 就能写，Xposed 框架也成熟，常见的证书绕过模块都能装。Android 5.1 太老，很多现代 App 直接提示"系统版本过低"，装都装不上；9.0 之后的 ROM 兼容性确实好，但 root 稳定性在不同机型上参差不齐，有时候挂载/system会失败。
VMOS 和 VMOS Pro 的关系，简单理解成"基础版"和"增强版"。Pro 版多了多开、文件传输、ROM 切换、分辨率与机型信息调整这些功能，对抓包来说文件传输和机型信息调整这两项都很实用——前者方便把证书和抓包工具安装包导进去，后者在遇到环境检测时能做点伪装。如果只是偶尔抓一次包，基础版够用；如果这是你的日常工作流，直接上 Pro 版省事。
2.2 开机卡 99%、激活失败这些启动期问题的处理顺序
VMOS 的启动期问题是新手最容易翻车的地方，尤其是卡在开机进度 99% 这一步，看起来很吓人，实际上绝大多数是资源或权限问题。按下面这个顺序排查，命中率很高：
- 权限先给全。进真机的
设置 → 应用管理 → VMOS，把存储权限、后台弹窗、自启动、后台运行全部打开。国产系统对后台的限制特别激进，缺任何一项都可能在启动过程中被掐断。 - 电池优化白名单。在电池设置里把 VMOS 设为"不受限制"或加入白名单，别用"智能省电"。虚拟机启动过程需要长时间占用 CPU 和内存，省电策略一介入就会卡在某个进度上不动。
- 检查存储空间。一个 ROM 包加上运行时的镜像文件，动辄要占几个 GB。剩余空间不足的时候，解压过程会静默失败，表现就是卡进度。
- 清数据重装。上面三条都排除了还是卡，就进真机设置里清除 VMOS 的应用数据，重新下载 ROM 包。ROM 包下载不完整是很常见的诱因，尤其是网络波动的时候。
- 换 ROM 版本。如果 7.1 的包死活起不来，退回 5.1 或者升到 9.0 试试，同一台机器不同 ROM 的启动成功率确实有差异。
至于"电脑激活"这个流程，它主要是用来解锁 Pro 版的完整功能的，按官方给的步骤在同一个局域网下走一遍就行，注意电脑和手机要处在可以互相访问的网段，公司网络里那种客户端隔离的 Wi-Fi 是走不通的，这种情况直接用手机热点。
2.3 给 VMOS 留够资源的几个系统级设置
虚拟机是个吃资源的东西，宿主机本身的设置会直接影响它的稳定性。我自己会做这么几件事：在 VMOS 设置里把内存分配调到一个合理的值，别贪心拉满，真机本身还要跑系统和其他 App，给虚拟机留 2GB 到 3GB 通常够抓包用了；关掉真机上的"深度睡眠""应用智能清理"这类会主动杀后台的功能；如果真机支持，把 VMOS 加进"游戏加速"或"性能模式"的白名单，让它别被降频。
还有一个容易被忽略的点：别在 VMOS 运行期间用真机的清理类工具。这类工具扫后台的时候会把虚拟机进程当成"高内存占用"给干掉，抓到一半断线，你会以为是网络问题，其实是被清理了。
3. 在 VMOS 内部把代理链路接通
3.1 让虚拟机和 PC 处在同一个可互通的网络
抓包代理跑在电脑上，虚拟机要把流量送过去，第一件事就是网络能通。VMOS 虚拟系统里的"Wi-Fi"是它虚拟出来的，但底层走的还是真机的网络出口，所以只要真机和电脑连在同一个局域网，虚拟系统通常就能直接访问到电脑的内网 IP。
拿到电脑 IP 的方法很基础但很关键：Windows 下ipconfig，看当前活跃网卡的 IPv4 地址；macOS 或 Linux 下ifconfig或ip addr。注意别选成虚拟网卡（比如 VMware、Docker 建的那种192.168.56.x或172.17.x.x），要选真实物理网卡那一项，通常是192.168.x.x。
然后是电脑防火墙。这一步拦住的人最多。Windows 默认会阻断外部设备访问本机的监听端口，抓包工具监听 8888，虚拟机连过来直接被丢包。最省事的做法是第一次启动抓包工具时，在弹出的防火墙提示里勾选"专用网络"并允许访问；如果没弹提示，就手动在防火墙入站规则里给对应端口开一条允许规则。我一般只在测试期间开着，测完关掉，别长期敞着端口。
连通性验证用最简单的办法：在 VMOS 内部装一个终端类 App，直接ping电脑的 IP。能通说明链路没问题，不通就先解决网络层，不要急着去调抓包工具，那只会让你在错误的方向上浪费时间。
3.2 虚拟网络里手填代理的完整操作路径
链路通了之后，在 VMOS 内部设置 HTTP 代理。路径跟真机一样：进入虚拟系统的设置 → WLAN，长按当前已连接的那个虚拟网络名称，选择"修改网络"，勾上"显示高级选项"，把代理改成"手动"，然后填主机名（电脑的内网 IP）和端口（抓包工具里配置的监听端口，Fiddler 默认 8888，Charles 默认 8888，Burp 默认 8080）。
这里有个细节值得注意：VMOS 的虚拟网络配置偶尔会在重启后被重置。我遇到过好几次，明明设好了代理，重启虚拟机之后抓不到包了，一进设置发现代理被清空了。所以我的习惯是每次开始抓包前，先花十秒钟确认一下代理还在不在，这个检查成本极低，能省掉大量"为什么突然抓不到"的困惑。
另外，抓包工具那一侧要确认监听地址不是仅限本地回环。有些工具默认只绑定127.0.0.1，那样只有电脑自己能连上，虚拟机过来的请求全部被拒。开启"允许远程连接"或把监听地址改成0.0.0.0之类的全网卡监听，是必须的一步。
3.3 代理只对部分应用生效时的替代思路
系统级代理这东西有个天生的局限：它靠的是应用去读取系统的代理配置。用标准网络库（比如 OkHttp 走默认配置）的 App 会乖乖听话，但自研网络库、直接用 Socket 的应用、或者代码里硬编码了连接地址的应用，压根不看系统代理，你设了也是白设。
这时候有个很契合 VMOS 的方案：在虚拟系统里装一个基于 iptables 流量重定向的代理转发类工具（ProxyDroid 是典型代表）。它的原理是在 root 环境下用 iptables 把指定应用发出的 TCP 连接在本地 NAT 重定向到代理端口，绕过"应用是否读取系统代理"这一问题。因为 VMOS 内部本身就有 root，装这类工具不需要任何额外条件，勾选目标应用、填上电脑 IP 和端口、开启转发即可。
这个方案的副作用是它对流量做了本地转发，抓包工具看到的来源会统一，定位具体是哪个应用发的请求时要多留意一下。另外只勾选你要分析的那个应用，不要全选，否则整个虚拟系统的流量都会被拽进来，日志里全是系统服务的噪音。
4. 把 CA 证书塞进系统信任区：VMOS 上最省事的一条路
4.1 从抓包工具导出证书的正确格式
证书格式没搞对，后面全白干。常见工具导出的东西不太一样，整理成一张表方便对照：
| 抓包工具 | 导出入口 | 推荐格式 | 备注 |
|---|---|---|---|
| Fiddler | Tools → Options → HTTPS → Actions → Export Root Certificate | DER，后缀.cer | 也可手机浏览器访问http://电脑IP:8888直接下载 |
| Charles | Help → SSL Proxying → Save Charles Root Certificate | PEM，后缀.pem | 手机浏览器访问chls.pro/ssl更省事 |
| Reqable | 设置 → HTTPS 解密 → 导出证书 | PEM / CRT | 移动端扫码下载体验最好 |
| Burp Suite | Proxy → Settings → Import/Export CA Certificate | DER，后缀.cer | 默认只监听本地，先改监听地址 |
有个很多人踩过的坑：Burp 导出的如果是 PEM 格式再用.cer后缀，某些系统会识别失败。稳妥做法是按工具推荐的格式导出，不要自己乱改后缀。还有一点，导出的必须是根证书，不是某个站点的证书，导错了后面哈希算出来也是错的。
4.2 计算证书哈希并把文件重命名
Android 的系统证书目录对文件命名有硬性要求：文件名必须是证书的subject hash（旧版 OpenSSL 的 MD5 哈希，8 位十六进制），后缀统一为.0。系统加载证书时会用这个文件名去索引，名字不对就不认。
用 OpenSSL 算这个哈希，一条命令搞定：
# 老版本 Android（7.x ~ 12.x 主流机型）用这个 openssl x509 -inform PEM -subject_hash_old -in fiddler.pem | head -1 # 部分较新 ROM 改用 SHA-1 版本的 subject_hash openssl x509 -inform PEM -subject_hash -in fiddler.pem | head -1第一条命令的输出会是一串 8 位十六进制字符，假设它输出的是9a5ba575（这里只是举例，你算出来的肯定不一样），那就把证书文件重命名成：
mv fiddler.pem 9a5ba575.0如果证书是 DER 格式的，先转一下再算：
openssl x509 -inform DER -in fiddler.cer -out fiddler.pem提示：
-subject_hash_old和-subject_hash两个都算一遍，哪个能生效用哪个。这不是玄学，不同 ROM 版本对 OpenSSL 的编译选项确实有差异，被这个坑过的都知道多试一次的成本有多低。
4.3 用 root 权限写入系统目录并验证
证书准备好之后，把它弄进虚拟系统。最方便的办法是在 VMOS 内部用浏览器直接从电脑下载——把代理配好，手机浏览器访问http://电脑IP:8888（Fiddler）或工具提示的证书下载地址，证书会直接落到虚拟系统的下载目录里。这一步顺便验证了代理链路是通的，一举两得。
接下来是写系统目录，两条路可选。
图形化路线：装一个带 root 功能的文件管理器（MT 管理器、RE 管理器这类），授予 root 权限，把/system挂载为可读写，把重命名好的.0文件复制进/system/etc/security/cacerts/，然后把这个文件的权限改成644（所有者读写、其他人只读）。改权限这一步别省，权限不对系统同样不加载。
命令行路线：在虚拟系统里的终端 App 中执行：
su mount -o remount,rw /system cp /sdcard/Download/9a5ba575.0 /system/etc/security/cacerts/ chmod 644 /system/etc/security/cacerts/9a5ba575.0 ls -l /system/etc/security/cacerts/ | grep 9a5ba575 # 确认文件在位且权限正确 mount -o remount,ro /system执行完重启虚拟系统，然后去设置 → 安全 → 加密与凭据 → 信任的凭据，切到"系统"标签页，往下翻，应该能看到你刚装进去的那张证书。这一步是必做的验收动作，看不到就等于没装成功，后面的抓包必然失败，别抱侥幸心理往下走。
4.4 一次没成功时的几种补偿手段
证书装进系统区了，抓包还是不通，这时候按下面的顺序补：
第一，检查是否需要 Xposed 模块兜底。有些 App 即使系统区有证书，也会额外做一次自己的校验。在 7.1 的 ROM 里装 Xposed 框架，然后启用证书相关模块，能解决相当一部分 Java 层的场景。模块的作用是直接改掉应用侧信任所有证书，属于"从应用这一端绕过去"。
第二，检查 SELinux 上下文。少数 ROM 开了强制模式，文件光有权限位还不够，安全上下文不对照样加载不了。chcon可以调整，不过 VMOS 的 ROM 大多是宽松模式，这个问题不常见，遇到了再查。
第三，试试用专门的证书安装类 App。这类工具封装了哈希计算、重命名、复制、权限设置的全过程，成功率比手动操作高，尤其是刚上手的时候。等熟练了再回到命令行，效率更高也更可控。
第四，注意证书有效期。抓包工具的根证书是有有效期的，有些默认只签一年。过期之后会出现"昨天还能抓，今天全断了"的情况，删掉旧证书重新导出一份装上去就行。这个坑我自己踩过一次，排查了两个多小时才想起来看有效期。
5. 抓包工具侧的分工与配置细节
5.1 Fiddler、Charles、Reqable 的 HTTPS 解密开关
代理连上了、证书装好了，如果工具的 HTTPS 解密没打开，你看到的依然是一堆隧道记录。这三款工具的开关位置不太一样，但逻辑一致。
Fiddler 里，进Tools → Options → HTTPS，勾上Capture HTTPS CONNECTs和Decrypt HTTPS traffic，然后点Actions → Export Root Certificate to Desktop把证书导出来。Fiddler 有个优点是它自带一个非常直观的会话列表，找某个接口的耗时特别方便，我一般在做"哪个接口拖慢了首屏"这类分析时首选它。
Charles 里，进Proxy → SSL Proxying Settings，新增一条规则，主机填*、端口填443（保险起见可以再加一条*:80）。Charles 的强项是映射和重写，你可以把线上接口改写到本地服务，或者把某个字段批量替换掉，用来复现"服务端返回某个异常值时客户端会怎样"这类问题特别顺手。
Reqable 是近几年用得比较多的一款，界面现代、性能开销小，移动端也能直接跑。它的 HTTPS 解密选项在设置里有个总开关，打开之后再装证书。我比较喜欢它的一点是可以直接在手机端完成抓包，不需要电脑，适合在外面临时看一眼接口返回的场景。
5.2 Burp Suite 安卓抓包的监听配置
Burp 的配置逻辑跟前面几个不同，它有一步很容易被忽略：默认只监听 127.0.0.1。这意味着虚拟机根本连不上它，代理填得再对也没用。
正确做法是进Proxy → Settings → Proxy Listeners，确认监听地址是0.0.0.0（也就是所有网络接口），端口按需设置。如果现有条目绑定的是127.0.0.1，编辑成全网卡监听或者新增一条。证书导出走Import/Export CA Certificate，选 DER 格式，后续的重命名和写入流程跟前面完全一样。
Burp 的优势在它那套 Repeater 和 Intruder，把抓到的请求直接丢进 Repeater 改参数重放，是分析接口鉴权逻辑和边界值处理的标准动作。从 Fiddler 抓到包，再导到 Burp 里做重放，这个组合我用得挺多。
5.3 什么时候该放弃代理，改用 tcpdump + Wireshark
代理这套方案只对 HTTP/HTTPS 有效。一旦你的目标变成下面几类，就该换工具了：
- 分析 App 使用的私有 TCP 协议或长连接心跳
- 排查 TLS 握手阶段的失败（证书链、协议版本、加密套件协商）
- 观察 QUIC/HTTP3 的连接迁移和丢包行为
- 需要看 TCP 层面的重传、乱序、窗口变化
这时候用 VMOS 的 root 权限跑 tcpdump，直接把原始数据包落成 pcap 文件：
# 抓全部接口，单文件 20MB，保留 5 个文件循环覆盖，避免写满存储 tcpdump -i any -s 0 -w /sdcard/cap.pcap -C 20 -W 5-s 0表示抓完整包长，别用默认的 96 字节，否则包内容会被截断。-C和-W是环形缓冲参数，长时间抓包必须加，不然虚拟系统的存储会被写满，导致虚拟机卡死。抓到之后把 pcap 导到电脑上用 Wireshark 打开，常用的过滤器有：
http.request # 只看 HTTP 请求 tls.handshake.extensions_server_name # 从 TLS 握手里提取目标域名 tcp.analysis.retransmission # 只看重传，排查丢包 eapol # 企业级 Wi-Fi 认证过程中的认证帧如果抓包量很大，人工翻效率太低，可以用 Python 批量解析。这里给个思路，用 pyshark 遍历 pcap 提取请求信息：
import pyshark cap = pyshark.FileCapture('cap.pcap', display_filter='http.request') for pkt in cap: try: print(pkt.http.request_method, pkt.http.host, pkt.http.request_uri) except AttributeError: continue cap.close()提示：用 pyshark 前先确认本机的 Wireshark 版本和 pyshark 版本匹配，版本不兼容时会报找不到 tshark 相关的错误。另外大文件别一次性全载入内存，用
FileCapture的逐条迭代方式处理更稳。
6. 实测中最容易被忽略的几类坑
6.1 抓到的全是 CONNECT，一行明文都没有
这是出现频率最高的问题，成因基本就三种，按排查成本从低到高走：
第一种，证书装到了用户区而不是系统区。回想一下你是用"设置里安装证书"的方式装的，还是手动写进cacerts目录的。前者一定不生效，回去按第 4 节的流程重做一遍，然后在"信任的凭据 → 系统"标签页里确认能看到。
第二种，抓包工具的 HTTPS 解密没开。工具只做转发不做解密时，日志里就是一个接一个的隧道记录。回去把解密总开关打开。
第三种，文件名或权限不对。文件名必须是哈希值，权限必须是644，两者缺一不可。用ls -l看一眼，比反复猜要快得多。
6.2 应用检测到代理或虚拟环境后直接罢工
这类问题的表现很有辨识度：App 一启动就闪退、提示"当前网络环境异常"、或者所有请求都超时但其他应用正常。原因通常是应用做了代理检测（读取系统代理配置）或设备检测（判断是否运行在虚拟机、是否装了 Xposed）。
应对手段按代价排序：先在 VMOS 的机型信息里调整设备参数，尽量贴近主流真机型号；再看虚拟系统里是不是装了太多明显带插件特征的模块，无关的关掉；然后试着关闭抓包工具里那种会往响应里注入额外内容的功能，某些注入行为会改变响应特征，触发应用的校验逻辑。
如果这些都不行，我的建议是把 VMOS 当成一次性环境用完就删。它本身的价值就在于隔离，而不是伪装成一个完美的真机。遇到强检测的应用，把测试放在编译期用测试环境开关打日志，比硬碰环境检测划算得多。
6.3 SSL Pinning：抓不到真的不是你的配置问题
如果代理通了、证书在系统区、工具解密也开了，某个特定 App 依然抓不到，其他 App 却正常，那八九不离十是 Pinning。它的原理是应用在代码里保存了一份服务端证书的指纹（或者公钥指纹），TLS 握手时自己再校验一遍，跟系统信任谁没关系。
Java 层实现的 Pinning，靠 Xposed 类模块能绕过；用了 OkHttp 的CertificatePinner的场景，模块一般也能处理。但如果是 native 层自己做的校验，模块通常无能为力，需要动态调试手段去 hook 对应的校验函数，工作量和门槛都上一个台阶。
这里给个实用的判断方法：先用一个功能简单、无安全校验的自研小应用做对照测试。如果它能正常抓到明文，说明你的整条链路没问题，问题出在目标应用本身；如果它也抓不到，那就老老实实回去查链路。这个对照测试能帮你快速区分"环境问题"和"应用问题"，省下大量无意义的反复配置。
6.4 长时间抓包把虚拟系统写爆
前面提过 tcpdump 的环形缓冲参数，这里再说个更隐蔽的场景：用代理工具抓包时开着日志持久化。Fiddler 和 Charles 都能把会话写成文件持续记录，如果目标应用有高频的轮询请求，半小时下来日志就是几个 GB，虚拟系统的磁盘分分钟满。
对策很简单：抓包时把工具的日志持久化关掉，只在内存里留最近若干条；如果必须留存，设置一个尺寸上限。另外 VMOS 里定期清理一下下载目录和临时文件，虚拟机的存储紧张时会表现得很奇怪，比如突然卡顿、应用闪退，很容易误判成应用本身的问题。
整理一张速查表，出问题的时候对着看：
| 现象 | 大概率原因 | 优先动作 |
|---|---|---|
| 全是 CONNECT 无明文 | 证书在用户区 / 解密未开 | 检查证书所在区，打开 HTTPS 解密 |
| 代理设了但设备连不上 | 电脑防火墙拦截 / 监听仅本地 | 放行端口，监听改全网卡 |
| 重启虚拟机后抓不到 | 虚拟网络代理被重置 | 每次开始前确认代理配置 |
| 部分应用不走路由 | 应用不读系统代理 | 用 iptables 重定向类工具转发 |
| 单应用抓不到，其他正常 | SSL Pinning | 对照测试确认，评估绕过成本 |
| 虚拟机突然卡死 | 磁盘写满或后台被杀 | 清理存储，加后台白名单 |
7. 我自己的取舍：什么时候用 VMOS，什么时候插数据线
用这套方案大概有一年多，我的实际判断标准挺简单：目标是"看接口"就用 VMOS，目标是"看协议"就插数据线。
看接口的场景占了日常工作的大头——查某个接口的返回结构、比对两个版本的请求参数差异、定位某个耗时异常的调用。这些需求用 VMOS 加代理工具就能全搞定，不用动真机，一台主力机可以同时挂着银行类和办公类应用，心里踏实。证书装一次能用很久，中间只要不换 ROM，基本不需要重配。我现在甚至把常用的几个测试应用和抓包工具预先装在虚拟机里，打成一个快照，需要的时候直接恢复，两分钟进入工作状态。
插数据线配合真机的场景，主要是需要 tcpdump 抓原始包、或者目标应用在虚拟机里明确跑不起来的时候。真机 root 的问题在于不可逆，所以我会用一台退役的旧机器专门做这件事，主力机永远不碰。这个"一台主力机保持干净 + 一台旧机器随便折腾 + 一个虚拟机环境做日常抓包"的组合，是我试过成本最低的配置。
最后分享一个小技巧：把证书的哈希值和文件名记在备忘录里。同一个抓包工具的根证书，只要不重新生成，哈希值是固定的，下次换 ROM 或者重建虚拟机时直接改名复制，省掉重新算哈希那一步。我备忘录里躺着一排xxxxx.0的文件名，用的时候直接抄，比每次敲 openssl 命令快得多。证书到了有效期记得重新导一份，顺手更新一下备忘录里对应的记录，这种小事提前做好，能省掉将来某一天"明明什么都没改怎么突然抓不到了"的两个小时。
