企业官网建设流程全解析

做安卓开发或者做接口联调的时候，抓包基本是每个人都躲不掉的硬需求。你可能会遇到这样的场景：Postman里调接口一切正常，一到App里就报错；或者说服务端明明返回了一堆数据，你就是看不到完整请求报文，只能靠猜。这时候，能用Burp Suite在安卓模拟器里把HTTPS流量完整地抓下来，就是解决问题的关键能力。

这篇内容就是一份全流程实操记录，主题很明确：用Burp Suite作为中间人代理，在安卓模拟器里完成HTTPS抓包。我会从为什么HTTPS抓包这么麻烦讲起，把证书信任的坑、系统证书和用户证书的区别、代理配置、证书安装这些环节全部拆开说清楚，并且附上我能想到的踩坑经验。不管是刚入门的测试新手，还是第一次在模拟器里配Burp的移动端开发，这篇文章都可以直接照着操作。

1. 为什么HTTPS抓包这么麻烦

每次讲到HTTPS抓包，很多人第一反应是“不就是在模拟器里设个代理吗”。真上手试一遍你会发现，HTTP流量随便抓，一到HTTPS就开始各种报错，不是证书无效就是白屏。要理解这些问题，绕不开HTTPS本身的工作机制。

1.1 TLS握手到底做了什么

HTTPS的本质是在HTTP之上叠加了一层TLS加密。浏览器或App和服务器建立连接时，会先走一次TLS握手，双方协商出对称加密密钥，之后所有HTTP内容都在这个加密隧道里传输。Wireshark那种直接抓网卡的方式，只能看到一堆密文，根本还原不出请求内容。

中间人代理的思路就出来了：让Burp Suite跑到客户端和服务器之间，冒充服务器跟客户端握手，再由Burp拿着真实请求去跟真正的服务器通信。这样Burp就能在中间解密流量、记录报文，然后把结果转发给客户端。

这里有个非常关键的前提：客户端必须信任Burp提供的那个伪造证书。如果客户端不信任它，TLS握手在第一个环节就会失败，你会看到常见的“证书无效”“未受信任的证书颁发机构”这类提示。这也是HTTPS抓包所有麻烦的根源。

1.2 中间人代理的核心逻辑

手机或者模拟器里的App请求发出后，如果系统配了HTTP代理，流量就会先到达代理地址。Burp在这个环节扮演两个角色：

• 对客户端来说，它是目标服务器，拿着自己的CA证书签发出站点证书参与握手；
• 对真实服务器来说，它又是客户端，替真正的客户端完成TLS握手。

只要客户端的证书信任列表里有Burp的CA根证书，这个双向扮演就能成立。抓包工具记录下解密后的明文请求和响应，展示在界面上，整个过程就是这么运作的。

所以可以总结成一句话：HTTPS抓包能不能成功，最终取决于Burp的CA证书有没有被目标环境信任，以及目标App有没有做额外的证书校验。

1.3 安卓证书体系的差异

安卓系统的证书信任机制在不同版本上差别很大，这是新手最容易踩坑的地方。

老版本的安卓（7.0以下）对用户安装的证书基本是来者不拒。你只要把证书文件放到存储卡里，然后在设置里点击安装，系统就会信任它。很多教程还停留在这一步，因为那个年代确实装完就能抓。

安卓7.0之后，官方收紧了这个策略：用户自行安装的CA证书，默认只对“用户信任区域”生效，而大多数App（尤其是使用系统网络库的请求）只信任“系统信任区域”里的证书。换句话说，你明明在设置里装好了证书，Burp也显示连接成功，但App里的HTTPS请求还是会被拒绝。

这就逼着我们在安卓7.0以上环境里，必须把Burp的证书想办法塞进系统信任区域，不能只停在用户证书层面。模拟器因为能拿到Root权限，实现这件事还算顺手，真机反而麻烦得多。

2. 工具选型与环境清单

动手之前先把环境说清楚，免得回头排查问题时不知道怪谁。抓包这种事，环境不统一会导致各种表现差异。

2.1 我用的这套环境

我的日常工作环境大致是这样一套：

如果你用的是别的模拟器，操作逻辑是一样的：拿到Root权限、能用adb命令、能修改系统分区，这三个条件只要成立，后面的流程就能走通。

为什么我不建议一开始就在真机上搞？真机需要解锁Bootloader，不同品牌安装系统证书的方式又不一样，稍不注意就把手机的系统分区搞出问题。模拟器随时可以新建快照，搞坏了直接重置，容错率高很多。

2.2 模拟器版本为什么很关键

我建议优先选Android 7.1.x，而不是更高的版本，原因很简单：

• Android 7.0以上的策略已经包含了“用户证书不被App信任”的问题，练手时可以完整走一遍系统证书转换流程；
• Android 7.1的模拟器镜像普遍能顺利拿Root、remount系统分区；
• 到Android 9、10之后，不少模拟器镜像要么不能Root，要么系统分区使用动态分区，push证书麻烦不少。

当然，如果你想顺便验证一下老版本环境，Android 6的镜像也能用，证书直接装用户区域就能看到效果。两者对比着玩一轮，你会更清楚不同版本之间证书信任模型的区别。

2.3 首次准备：启动Burp并配置监听器

Burp默认的代理监听地址是127.0.0.1:8080。如果界面上的代理监听被关掉了，需要手动添加一个。

1. 打开Burp，进入Proxy标签页，切到Proxy Settings；
2. 在Proxy Listeners区域查看是否有正在监听的条目；
3. 如果没有，点击Add，Bind to port填8080，Bind to address选127.0.0.1，勾选HTTP协议；
4. Running状态确认打勾，监听器就生效了。

这里的地址最好固定用127.0.0.1。模拟器在NAT网络模式下，内部的回环地址会映射到宿主机的回环接口，所以模拟器里填127.0.0.1:8080，流量就能送到Burp。这个细节很多人不知道，以为要填电脑的局域网IP，结果绕了一圈反而失败。

Burp启动后，可以先用电脑浏览器配合代理访问一个HTTPS网站，确认Burp能正常拦截到电脑端的请求。这一步验证了Burp本身没问题，后面排查范围就可以缩小到模拟器侧。

3. HTTPS抓包全流程实操

现在进入正题。整个流程可以拆成几个阶段：导出CA证书、配置模拟器代理、安装用户证书、转换系统证书、验证抓包效果。每一个环节我都会写清具体操作和背后的注意事项。

3.1 把Burp的CA证书导出来

Burp自带一个CA根证书，它给每个站点签发证书时使用的就是这把根证书签出来的。我们需要把这个根证书导出，然后安装进安卓系统里。

导出步骤：

1. 在Burp的Proxy Settings页面，往下拉到Proxy Listeners下方，找到Import / Export CA certificate按钮；
2. 选择Export，导出格式默认是DER（二进制格式），文件名通常叫cacert.der；
3. 选好保存路径，点Next完成导出。

文件导出后，别急着往模拟器里塞。DER格式的证书在安卓上可以直接安装，但后面转换成系统证书时需要PEM格式，所以这里顺手转换一下会更顺。我用OpenSSL做转换：

openssl x509 -inform DER -in cacert.der -out cacert.pem

转换完成后，你会得到一个纯文本格式的Base64编码证书文件，后面的系统证书流程需要用到它。

3.2 给模拟器配置代理

证书准备好后，把模拟器里的流量导向Burp。这个操作在安卓的WiFi设置里完成：

1. 打开模拟器的设置，进入Wi-Fi；
2. 找到当前已连接的网络，长按或者点击右侧的修改按钮；
3. 在弹出的网络详情界面里，把代理方式从“无”改成“手动”；
4. 主机名填127.0.0.1，端口填8080；
5. 保存设置。

有几个模拟器需要注意的地方。

有的模拟器有“网络类型”选项，选NAT模式或者默认模式就行，不要选桥接。桥接模式下，模拟器里的127.0.0.1会变成模拟器自身，而不是宿主机，代理会直接失效。

保存代理设置后，先在模拟器自带的浏览器里访问一个HTTP网站验证一下。比如访问一个国内常见的HTTP站点，如果Burp界面里出现了请求记录，说明代理链路已经通了。这时候再访问HTTPS站点，大概率会看到证书错误提示，因为证书还没装进去，这是完全正常的。

3.3 安装用户证书（Android 7以下）

如果你用的是Android 6或者更老的镜像，这一步做完基本就能抓HTTPS了。

把导出的cacert.der文件放到模拟器的共享文件夹或者直接adb推送到/sdcard/下：

adb push cacert.der /sdcard/

然后在模拟器里打开设置，找到“安全”或者“安全与锁定”，选择“从存储设备安装证书”。系统会弹出一个证书安装向导，找到刚才放进去的cacert.der，给它起一个方便识别的名字，确认安装。

安装完成后，可以到“信任的凭据”列表里确认一下，证书会出现在“用户”标签页下。这时候模拟器浏览器访问HTTPS站点应该就不报错了。

3.4 Android 7+把证书装进系统分区

到了Android 7.1.2，就轮到本篇的重头戏了。只装用户证书的情况下，模拟器自带的浏览器可能还能正常抓包，但是绝大多数App都会无视用户证书，请求直接失败。把证书转成系统证书就能解决这个问题。

转换过程分为两步：算出证书的hash文件名，然后把文件推送到系统证书目录。

先计算hash：

openssl x509 -inform PEM -subject_hash_old -in cacert.pem

执行后，终端会输出一串十六进制数字，类似9a5ba575。记住这个值，待会要用。然后执行下面这条命令：

openssl x509 -inform PEM -subject_hash_old -in cacert.pem -noout

前后输出其实是一致的，只取第一行那个哈希值就够了。需要重新生成一个以.0结尾的文件：

cp cacert.pem 9a5ba575.0

9a5ba575替换成你实际得到的哈希值。文件名必须是“哈希值.0”的格式，安卓系统在启动时扫描/system/etc/security/cacerts/目录，按PEM文件名加载到系统证书列表里。文件名不对，证书就白放了。

接下来把文件推送到系统目录。前提是模拟器已经开启了Root：

adb root adb remount adb push 9a5ba575.0 /system/etc/security/cacerts/ adb shell chmod 644 /system/etc/security/cacerts/9a5ba575.0

这四条命令分别做了四件事：让adb以Root身份运行；把系统分区挂载为可写；复制证书进系统证书目录；把权限改成644，保证系统可以正常读取。

注意：如果你运行adb remount之后提示失败，可以先在模拟器设置里打开“Root权限”开关，或者在模拟器的启动参数里带上可写系统镜像的参数。具体开关位置不同模拟器不一样，但思路是一致的。

重启模拟器后，去“信任的凭据”里看，证书应该出现在“系统”标签页了。看到它的那一刻，Android 7+环境的HTTPS抓包就算成功了一半。

3.5 用HTTP访问验证与HTTPS验证

证书进了系统区域，接下来验证两件事：代理还在不在，证书有没有生效。

先在Burp里切到HTTP history，然后在模拟器浏览器里访问一个HTTPS网站。正常情况下，Burp日志里会出现新的HTTPS请求记录，双击可以看到完整的请求头、响应头和响应体。模拟器浏览器如果出现连接不受信任的警告，说明证书加载还有问题，优先检查系统证书文件名和权限。

接着做一次更严格的验证：访问一个会返回账号密码或者Token的测试接口，观察Burp的请求包。这时候应该能在请求体里直接看到明文参数，比如用户名、密码字段。这就是HTTPS抓包想要达到的效果。

3.6 真实App测试：证书与代理日志查看

模拟器浏览器成功了，真正要抓的其实是App。测试时最好用一个自己开发的Demo应用，或者一个已知没有做证书校验的App。打开App，触发几个接口请求，然后回到Burp看HTTP history。

你可能看到的情况有两种。

如果App用的是系统网络库，而且没有开SSL Pinning，那系统证书区域里有Burp的CA，握手就能顺利通过，请求正常进入Burp日志。这是最理想的情况。

如果App做了SSL Pinning，比如校验服务端证书的公钥或指纹，那就不是单纯装证书能解决的了。这一点我在后面的排查部分会专门讲。

不管哪种情况，遇到问题先看Burp底部的日志面板，那里会显示TLS握手失败的原因，比如Certificate unknown或者handshake_error。日志里的错误信息比App界面上显示的友好得多。

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

流程看起来不长，但实战中大概率会在某些环节卡住。我把经常遇到的几个问题整理成一张表，每个都对应解决思路。

4.1 最恼人的几个报错

先说CONNECT请求的问题。很多新手看到Burp日志里一堆CONNECT记录就懵了，以为抓包失败。其实CONNECT只是客户端发起的隧道建立请求，真实的HTTP请求藏在它后面。展开同一个会话，就能看到GET/POST请求。

再说证书无效问题。如果你确认系统证书区域里已经能看到Burp的CA，但浏览器仍然报证书错误，大概率是模拟器的系统时间不对。TLS证书校验会检查有效期，模拟器时间一旦偏差过大，证书会被判定为过期或者尚未生效。恢复自动时间和时区，基本都能解决。

最后一个高发问题是adb remount失败。不同模拟器的系统分区挂载策略不一样，有的需要先关闭“只读挂载”再remount。如果remount一直失败，可以试着重启一次模拟器并重新执行adb root。

4.2 从Burp日志反推问题

遇到复杂的抓包异常，我一般会先看Burp的Event Log和Alerts面板。TLS握手失败时，Burp会给出具体错误链，常见的有这样几种：

• Certificate unknown：客户端不信任Burp的CA证书，检查系统证书是否正确安装；
• Received fatal alert: certificate_unknown：服务端校验了客户端证书，或者App做了Pinning；
• Connection timed out：代理链路不通，检查模拟器网络模式和代理配置；
• No such file or directory：push证书时路径不对，确认系统目录确实存在。

日志里的错误往往能直接指向问题层级。网络层不通就看代理，证书层失败就看信任，应用层失败就看Pinning，一层一层剥下去，比瞎猜效率高得多。

4.3 关于SSL Pinning的客观说明

正式环境中的商业App，很多都会做SSL Pinning，也就是在客户端代码里写死服务端证书的公钥或者摘要。这种情况下，就算Burp的CA被安卓系统信任，App也会在TLS握手时发现证书对不上，直接断开连接。

对于自己开发的App，处理思路很明确：开发版本里不要把Pinning逻辑做得太死，可以针对测试环境放行调试证书，或者提供一个关闭Pinning的开关。这样在测试阶段可以正常抓包，线上版本继续启用完整校验。

这里我要特别强调一下边界：本文讨论的对象是自己开发的App、模拟器里的调试环境、经授权的测试过程。抓包工具是用来做开发调试和接口联调的，不是用来探测或绕过任何未授权系统的。

5. 实操之后的一点建议

整套流程跑下来，我最想说的一个体会是：证书问题的核心不是“怎么安装”，而是“安装在哪个信任区域”。记住这句话，大部分HTTPS抓包异常都能快速定位方向。

另一个经验是，把转换好的系统证书文件（那个9a5ba575.0）备份一份。模拟器重置、新建镜像之后，直接push进去就行，不用重新走一遍从Burp导出再转换的流程，能省不少时间。

还有一个细节：如果模拟器里出现“应用”可以正常上网、但某些自带功能全部白屏的情况，先检查是不是代理把没有走代理的流量也拦截了。Burp默认监听127.0.0.1:8080，如果模拟器内所有流量都走这个代理，某些不遵循系统代理设置的程序可能表现异常。建议抓包时只对着目标应用测，不要长时间把所有流量都挂着代理。

说到底，安卓模拟器HTTPS抓包不是什么高深技术，它考核的就是你对代理机制的理解和对证书信任模型的熟悉程度。把这篇流程在你自己的机器上完整走一遍，再结合自己的项目反复调试几轮，你会发现后面再遇到类似问题，基本就是看一眼日志就知道故障在哪了。