HTTPS 抓包乱码这件事，通常不是编码问题那么简单

第一次遇到 HTTPS 抓包乱码，大多数人的反应都很直接：是不是字符集不对？是不是 gzip？是不是工具显示有问题？

我以前也是这么想的。但在真正排查过几次之后，会发现“乱码”只是结果，背后原因往往并不在显示层，而是在你到底抓到了什么。

一次看似普通的乱码场景

事情起因很简单：
一个 iOS App 在真机环境下抓包，HTTPS 请求能看到，但 body 全是不可读的内容。Header 看起来正常，状态码也是 200，但响应体像是随机字节。

同样的接口，在测试环境、模拟器、甚至服务端日志里都是正常 JSON。

这个时候，如果直接下结论说“抓包工具不行”，往往会走偏。

先确认：抓到的是不是“解密后的 HTTPS”

HTTPS 抓包乱码，最常见的情况其实是：
你看到的内容并不是解密后的数据，而是 TLS 层之上的加密结果。

代理抓包工具在这一步非常有价值。
它们的优势不在于“万能”，而在于能快速验证一件事：

这个请求，在理想条件下能不能被正确解密？

在可控网络环境下，如果代理抓包能看到清晰的请求和响应，说明接口本身没有额外加密，乱码问题更可能出现在真机或安全机制上。

HTTPS Pinning 出现时，乱码就变成了信号

回到这个案例，代理抓包在模拟器里一切正常，真机却全部是乱码。
这时基本可以确定：不是编码问题，而是 HTTPS 校验策略在起作用。

很多 App 在真机环境下启用了 HTTPS pinning，甚至是双向校验。这种情况下，代理工具往往只能看到连接存在，却无法完成真正的解密，于是就留下了一堆“看起来像乱码”的数据。

这里的关键不是“怎么显示”，而是你有没有权限看到明文。

设备侧抓包，才能确认“真实通信内容”

在需要确认真实 HTTPS 内容时，我后来改用了抓包大师（Sniff Master）这类从设备侧抓取数据的工具。

它在这个流程里的作用很明确：
不是替代代理工具，而是验证一个假设——

这个 App 在真机上，到底发了什么、收了什么？

由于不依赖系统代理，也不需要改 App 或越狱，它更接近用户真实环境。
在同一个接口上，用 Sniff Master 抓到的数据已经是可读的结构化内容，这一步基本就可以确认：之前看到的“乱码”，并不是数据本身的问题。

并不是所有“可读内容”都是业务数据

不过事情并没有到此结束。

在进一步分析时发现，某些响应虽然不再是乱码，但内容依然不像业务 JSON。
这时就需要再往下看一层：是不是应用层又做了一次加密？

这一点很容易被忽略。
HTTPS 解决的是传输安全，不等于业务一定是明文。有些 SDK 会在 HTTPS 之上再包一层自定义加密，这时候即便 HTTPS 解密成功，内容依然“看不懂”。

数据流视角，帮忙判断“是不是二次加密”

判断是否存在二次加密，单看 HTTP 视图并不够。
我后来抓了一段 TCP 数据流，对比请求和响应长度、结构变化，发现数据具有明显的固定头和校验特征。

这类分析更偏数据流层，而不是接口层。
抓包大师支持直接抓 TCP / UDP 数据流，并导出给 Wireshark 做进一步分析，这一步的意义在于确认：

• 这是不是一个稳定结构的数据包
• 是否存在明显的协议格式
• 是否需要再用业务逻辑去解码

一旦确认是二次加密，乱码就不再是“问题”，而只是“正常现象”。

乱码排查中，拦截和修改也有价值

在某些情况下，我会直接修改响应内容，观察客户端行为。
比如返回空数据、非法格式，或者替换部分字段，看看 App 是否能正常处理。

这类操作不一定是为了“破解”，而是为了确认客户端对数据的依赖程度。
抓包大师支持通过拦截器和脚本修改请求和响应，这在验证假设时很方便。

HTTPS 抓包乱码，本质是视角问题

回头看这类问题，真正有用的不是“某个工具多强”，而是你是否清楚自己现在站在哪一层：

• 代理抓包：验证接口逻辑
• 设备抓包：还原真实 HTTPS 内容
• 数据流抓包：判断是否存在额外协议或加密
• 拦截修改：验证客户端处理逻辑

乱码只是一个表象，它提醒你：现在看到的，很可能还不是你真正要看的东西。