企业官网建设流程全解析

在 Charles 里看到 “unknown”，第一反应别慌，这不是软件坏了，也不是手机坏了。它只是告诉你一句话：Charles 已经把这条流量抓到了，但它认不出这是什么协议、也没法按 HTTP/HTTPS 那样把内容解析给你看。我在实际调试过程中，“有的包能抓到、有的显示 unknown” 是出现频率最高的一类问题，而且十次里有七次都是环境配置、证书信任、应用不走代理这几类原因，真正涉及高强度防护的反而是少数。

这篇文章把这套问题从原理到实操完整摊开。适合正在用 Charles 调试手机 App 接口的移动开发、客户端测试、接口逆向的兄弟们，也适合刚入门、对着满屏 unknown 一头雾水的新手。

1. 先搞清楚 Charles 的 “unknown” 到底在说什么

1.1 Charles 是怎么认出 HTTP、HTTPS 和 unknown 的

Charles 本质上是一个 HTTP 代理服务器，不是简单的网卡嗅探工具。手机把 Wi-Fi 代理指向电脑的 8888 端口后，App 发请求时会先把请求发给 Charles，Charles 再替你转发到真正的服务器。这就是为什么 Charles 能看到请求内容，靠的不是抓包，而是“中间人代理”。

对于普通 HTTP 流量，Charles 直接收到明文请求行和 Header，自然能解析出域名、路径、参数。对于 HTTPS，手机和服务器之间建立的是 TLS 加密隧道，Charles 能看到的只是一个CONNECT请求，格式大概是CONNECT example.com:443 HTTP/1.1。从这一刻起，除非 Charles 能成功解密这条隧道，否则它只能记录“和 example.com:443 建立了一条连接”，具体里面传了什么，一概不知。

当 Charles 既无法把某条流量识别成标准 HTTP 请求、又没法解密成可见内容时，列表里就会显示unknown。所以这个状态名其实很准确：它是 Charles 对协议识别、解密失败后的兜底呈现。

1.2 unknown 不等于没抓到，而是“看到了不会解析”

很多朋友一看 unknown 就以为抓包失败，实际上数据包已经躺在 Charles 的会话列表里了，只是它没有按照 HTTP 的格式展示给你。你可以点开这个 unknown 记录，切到 Contents 面板，看 Raw 视图，能看到原始字节流。如果是47 45 54 20开头这种 ASCII 码转出来是GET，说明它其实是明文 HTTP，只是端口不是 80，或者请求格式稍微特殊，Charles 没识别出来。如果开头是16 03开头的 TLS 握手，说明这只是一条没被解密的 HTTPS 连接。

换句话说，unknown 是“看到但没法解析”，和“完全看不到”是两回事。后面所有排查，都要围绕这个区别来做：先确认你手里拿到的 unknown 到底是什么协议的数据。

1.3 哪些流量天生就是 unknown

不是所有 unknown 都是配置问题，有些流量就算你把控制中心所有细节都搞定，它还是 unknown。

• HTTP/3（QUIC）：走的是 UDP 443，Charles 默认不支持 QUIC 解密，通常只能看到 UDP 层面，或者完全不显示。
• WebSocket 升级后的帧流量：握手阶段能看到101状态，之后双向传输的二进制帧会变成 unknown。
• 自定义 TCP 长连接：很多消息推送、IM 类 App 用的是私有二进制协议，直接拿 TCP 层发包，不走 HTTP 封装。
• TLS 双向认证、某些加密 DNS（DoT）流量：这些连 TLS 隧道都建立不成功或者专门加密，解析不出内容。

遇到这些情景，不需要纠结 Charles 为什么没识别，而是要先判断这个 unknown 是不是你关心的目标。如果你要查的是一个普通 HTTPS 接口，结果它显示 unknown，那才需要进入下面的排查流程。

2. 从头排查环境问题：证书、代理设置一个都不能少

2.1 手机流量必须走 Charles 代理，这一步错了全盘皆输

手机连接 Wi-Fi 后，进入「设置 → 无线局域网 → 当前 Wi-Fi 的高级设置 → 配置代理」，选手动代理，填电脑的局域网 IP 和端口 8888。如果这一步没设置，手机流量跟 Charles 半毛钱关系都没有，Charles 里只会静悄悄。

一个小细节：电脑记得关掉防火墙对 Java/Charles 进程的拦截，否则手机能连上 Wi-Fi，但请求到不了 8888 端口，你会看到 Charles 完全没有流量，或者只在 Access Control 里看到连接又立刻断开。

2.2 SSL Proxying 没开全，HTTPS 只能看到连接

客户端走代理后，Charles 默认只信任根证书，并不会主动解密每一个 HTTPS 域名。如果你不配置 SSL Proxying，绝大多数 HTTPS 请求在 Charles 里就是一条CONNECT记录，点开后往往是 unknown，内容完全不可见。

操作路径：「Proxy → SSL Proxying Settings → 勾选 Enable SSL Proxying → 在 Location 里添加一个规则」。不想一个个填域名的话，最省事的就是添加两个规则：*:443和*，让 Charles 对全部 HTTPS 和全部端口都尝试解密。这里注意，规则粒度越粗，Charles 消耗的资源越大，正式调试时建议精确到你要看的域名，避免大量无关流量干扰判断。

2.3 证书没装对，解密直接失败

这是“有的包正常、有的 unknown”最常见的原因。iOS 和 Android 对用户安装的根证书信任策略不一样，坑点也完全不同。

iOS 装完证书后，必须去「设置 → 通用 → 关于本机 → 证书信任设置」里，把 Charles 的证书开关打开为“完全信任”。只下载描述文件、不打开信任开关，浏览器访问 HTTPS 时会报错，App 走的 TLS 握手也就失败，Charles 里就会看到 unknown 或者握手失败。

Android 的坑更大。Android 7（API 24）开始，App 默认只信任系统级 CA 证书，不再信任用户级 CA 证书。也就是说，你把 Charles 证书装进“用户凭据”里，浏览器可能能用，但大部分第三方 App 根本不认这个证书，结果同样是 TLS 握手失败、unknown。想彻底解决，需要把 Charles 证书以系统证书的方式装进去，常见做法是 root 后用 Magisk 模块，或者直接改系统镜像把证书塞进/system/etc/security/cacerts，生成对应重命名的.0文件并设置权限。这步操作比一般装证书繁琐，但效果最稳定。

2.4 快速自检流程：先让浏览器过一遍

每次换设备、换网络环境，我建议先别急着开 App，直接跑一个 30 秒的自检：

1. 手机 Wi-Fi 手动代理指向电脑的 8888 端口。
2. 打开 Charles，确认手机已经在访问控制列表里。
3. 手机浏览器访问一个纯 HTTP 地址（比如你电脑的局域网地址），看 Charles 里是否出现GET /开头的请求。能出现，说明代理链路正常。
4. 手机浏览器访问常见 HTTPS 站点，看内容是否能明文显示。能显示，说明证书安装和信任链路正常。
5. 随便打开一个不常访问的 HTTPS 站，确认没有弹证书错误。没弹，说明系统信任没问题。

这套流程跑完，如果全程正常，再打开目标 App 测试。如果 App 里的请求还是 unknown，那就能跳出环境问题，往应用层协议、SSL Pinning、不走代理这些方向去想。很多朋友一上来就直接开 App，结果满屏 unknown，然后排查半天才发现是证书没信任，白白浪费一小时。

3. 高频场景逐个击破：HTTPS 解密失败与协议识别异常

3.1 场景 A：证书已装，但某个域名仍然 unknown

先别急着怀疑高级防护。检查一下是不是手机系统时间不对。TLS 握手时证书有效期校验依赖本机时间，时间偏差太大会直接导致证书链校验失败，Charles 无法继续解密，就会显示 unknown。这个问题出现频率极高，尤其是二手测试机或长期断电重启的设备。

排完时间，再确认 Charles 的 SSL Proxying 规则里是否包含该域名。你只加了*:443理论上是全覆盖的，但如果你用的是精确域名规则，新域名自然不在列表里。这里有个判断技巧：点击 unknown 记录，切到 Raw 看握手包，如果握手到Server Hello之后，Charles 弹了证书错误，要么是证书链不信任，要么是客户端校验了证书。

3.2 场景 B：应用完全不经过代理，Charles 里干脆没有记录

这种情况在中文互联网 App 里很常见，App 内部实现不走系统代理。比如底层网络库用了 OkHttp 但显式调用了.proxy(Proxy.NO_PROXY)，或者自己实现了套接字连接直接连服务器 IP。表现就是：Charles 里完全看不到这个 App 的任何请求，你切到其它需要代理的 App 又一切正常。

怎么确认？最容易的办法是开一个终端抓包类的工具，比如在电脑上跑tcpdump看手机 IP 是否在往非 8888 端口发包；或者利用 Charles 的一个辅助功能：手机装好 HTTP 代理后用 Charles 的 SOCKS 功能做二次兜底。注意，这种方法只能让“愿意走代理”的流量走代理，碰到直接写死直连的套接字，还是拦不住。

更彻底的思路是在 root 设备上用 iptables 做全局重定向：把手机流量按目标端口重定向到 Charles 监听的端口。这类工具很多，原理就是防火墙层面的透明代理，让应用以为自己直连了服务器，实际数据流经过了 Charles。当然，这种做法只是在自有测试机上验证，和生产环境无关，别拿别人的设备乱试。

3.3 场景 C：SSL Pinning 让中间人握手失败

如果你的 unknown 记录点开之后，能看到 TLS 相关日志，但 Charles 直接报SSLHandshake: Received fatal alert: certificate_unknown，或者Client requested a client certificate，大概率是遇到了 SSL Pinning。

SSL Pinning 的意思是客户端在正常校验证书链之外，还额外校验服务器证书的指纹、公钥，或者锁定固定的证书。Charles 拿自己的中间证书去冒充，客户端比对后发现不是原始证书，直接掐断握手。表现形式五花八门，有的是 unknown，有的是请求超时，有的是直接闪退。

常规解决办法是在自有测试设备上做 Hook 绕过校验。Android 端可以借助 Frida 运行常见的ssl pinning bypass脚本，运行时把客户端里校验证书指纹的方法替换掉，让 Charles 顺利中间人。iOS 也有对应的工具可以做。这里必须强调一句：这些操作只适用于你拥有合法权限的测试设备、且目标应用是你负责调试或已获授权的应用。至于怎么判断是否 pinning，有个简单经验：同一台手机，同一网络，Chrome 浏览器能正常访问该域名的内容，而目标 App 显示 unknown，那十有八九就是客户端额外做了校验。

3.4 场景 D：双向认证、HTTP/2、QUIC 等非常规情况

双向认证是另一个被忽略的 unknown 来源。常规 HTTPS 只要求客户端验证服务器证书，双向认证则是服务器也要求客户端出示证书。所以你会看到完整的 TLS 握手记录，但最后一步卡在CertificateRequest。无解时看不到任何明文内容。

HTTP/2 本身 Charles 支持得不错，但如果你关掉了 SSL Proxying，或者某个域名走了默认的非标准端口，可能会看到 unknown 或二进制帧的乱码。需要确认请求走的是 443 且 SSL Proxying 规则包含该端口。

至于 QUIC 和 HTTP/3，识别特征比较明显：Charles 的会话列表里会出现 UDP 相关的流量，或者压根不出现，因为 Charles 默认不解 QUIC。调试时如果目标 App 恰好走了 HTTP/3，你能看到的可能就是一堆 unknown。想继续分析有两个思路：一是让服务端降级到 HTTP/2，二是直接用支持 QUIC 解析的抓包工具，Charles 不是干这个的最佳选择。

4. 一次真实场景的完整排查记录

4.1 现场状况

我这里复现一个很典型的案例。某公司内部一个测试 App，接入的是统一认证网关，我准备用 Charles 抓它的登录接口和首页接口。连接代理后，首页接口正常显示，但登录接口和几个行为上报接口全部显示 unknown，而且 unknown 记录里看不到 URL，只能看到 IP 和端口 443。

第一眼确实容易懵，因为同一个 App 里，有的 HTTPS 请求能解密，有的不能，规律还不明显。

4.2 排查第一轮：先排除环境问题

我先是确认了时间同步、证书信任、SSL Proxying 规则，全部正常。浏览器访问那个认证网关域名，打开任意 HTTPS 网页都正常。这说明 Charles 的中间人能力是好的，问题出在目标 App 对某些请求的处理上。

接着我注意到一个细节：正常的首页接口域名是常见的api.xxx.com这种，而登录接口的 unknown 记录里，IP 反查到的域名很冷门，甚至可能是 CDN 的节点域名。这就引发了一个猜测：App 在登录流程里可能连的是另一个服务端，或者这个服务端配置了额外的证书校验。

4.3 排查第二轮：定位 unknown 归属

我用 Charles 的 Filter 功能把所有 unknown 按时间排序，再对应 App 操作，发现只要触发登录，就新增一条 unknown。然后切到 Contents 的 Raw 视图看数据包，能看到完整 TLS 握手过程，最后 Server 发送了一个CertificateRequest，要求客户端提供证书。

到这里，问题基本浮出水面：这不是 SSL Pinning，而是双向 TLS 认证。客户端手里本来就有内置的客户端证书，Charles 作为中间人，没法提供合法客户端证书，握手只能中断。

4.4 排查第三轮：用工具确认 pinning 与协议类型

为了确认是不是还有 pinning 叠加，我启动 Frida 挂了一个通用的 pinning bypass 脚本，重新跑登录流程，发现请求依然卡在双向认证的CertificateRequest阶段，说明这个网关强制要求客户端证书，绕过证书指纹校验没用。

最终和当事人沟通确认：登录接口所在的网关配置了双向 TLS，正常情况下 App 内部通过安全存储加载客户端证书，Charles 要抓到明文，需要把客户端证书导出，并配置到 Charles 的 SSL Proxying 的客户端证书选项里。这一步拿到材料后，在「Proxy → SSL Proxying Settings → Client Certificate」里添加对应证书，登录接口立刻变为可读的 HTTPS 请求。

整个过程给我的感受是：当“有的包能抓到、有的显示 unknown”时，先别急着上防检测教程，把 unknown 的原始字节流看清楚，往往能直接定位到具体原因。Raw 视图就是干这个用的。

5. 常见问题速查表与避坑心得

5.1 问题对照速查表

为了方便大家快速判断，我把实战中遇到的 unknown 类型整理成一张速查表，可以先对照再排查。

5.2 从踩坑里总结的几条经验

第一，Charles 的 Session 列表不适合长时间不清理。抓包前先清空会话，能大幅降低排查 unknown 时的干扰项，不然你会在一堆无关的长连接、推送通道里反复迷路。

第二，发现问题先从最简单的可能性开始：时间对不对、证书装没装、代理有没有生效。我见过太多同事把 SSL Pinning 的锅扣在 App 头上，结果只是测试机时间慢了两小时。

第三，Android 7 以上的设备直接用 root + 系统证书方案最省心。如果你每次调试都要面对新设备，可以把 Charles 证书做成 Magisk 模块，装进系统证书目录，一劳永逸，免得每台机器重新折腾一遍信任策略。

第四，不要盲目开启对*:443的全量 SSL 解密。规则越宽，垃圾流量越多，你反而更难发现目标请求。建议平时只解密正在调试的域名，等确认未命中时再逐步扩大范围。

第五，遇到 unknown 先点开 Raw，用十六进制和 ASCII 对照看前几个字节。GET、POST开头说明是 HTTP 但端口非常规，16 03开头说明是 TLS 握手，其它自定义字节说明是二进制协议。这一步能让你的排查方向立刻明确。

第六，所有 Hook 绕过类操作只应在自有测试机、已取得授权的设备上使用。调试没问题，但别把测试工具用在非授权场合，这不是技术问题，是边界问题。调试完最好恢复原状，避免测试机被强行绑定调试环境导致后续功能验证失真。

我个人这几年的习惯是：把 unknown 当作一种线索而不是故障。Charles 在满屏可读的 HTTPS 里突然给你一个 unknown，往往说明这条路流量里藏着特殊逻辑，反而是需要重点观察的部分。掌握上面这些排查方法后，下一次再遇到 unknown，你大概能花几分钟就定位到根因。