HTTPS 抓包乱码这件事，通常不是编码问题那么简单-抓包大师使用教程

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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