我们如何发现数千台安卓设备上的 TLS 1.3 隐性故障

作者：Ilya Rusalowski，iProxy.online 首席技术官

如果你运营移动代理，你一定懂这种痛苦：某些东西坏了，却没有人能告诉你原因。设备在另一个国家，用户只说"用不了"，没有日志，没有报错信息，没有堆栈追踪。只有沉默。

这正是我们遇到的情况——只不过我们在大多数用户察觉之前就发现了。原因如下。

需要私人且快速的移动代理吗？
立即创建移动代理！
开始免费48小时试用

iProxy 在每台设备上持续运行网络诊断

我们的安卓应用不只是转发流量。它运行一整套网络健康探测程序，持续检查连通性、延迟、DNS 解析、HTTP 和 HTTPS 可达性等指标。这些探测针对受控服务器持续运行，因此我们随时掌握每台设备的网络状态。

正是通过这种方式，我们发现了异常：一小部分设备的 HTTPS 检查开始失败，而 HTTP 却运行正常。故障发生在 TLS 握手阶段。没有报错，没有超时提示——连接就这样静默地石沉大海。

如果没有内置诊断，这个问题将完全不可见。用户会看到断断续续的代理故障，找不到规律，也得不到解释。我们只能靠猜。

究竟发生了什么

故障与 TLS 1.3 直接相关。同一台设备、同一台服务器、同一时间的 TLS 1.2 连接——完全正常。TLS 1.3 则不然。

根本原因是两个因素叠加的结果：

现代 TLS 客户端发送的握手消息比以前大得多。 Go 1.23+ 和 Chrome 124+ 现在默认包含后量子密码学密钥共享（ML-KEM）。这使得 TLS 连接的第一条消息——ClientHello——大到超过单个 TCP 数据包的限制。TLS 1.3 中服务器的响应也作为一个大数据块一次性发送（包含完整的证书链），对于 Google 或 Cloudflare 等网站，这可能达到 4-6 KB。

内存紧张的安卓设备难以缓冲这些较大的消息。 我们的应用作为 TCP 代理运行——从一个套接字读取字节并写入另一个套接字。当设备 RAM 不足时，这种缓冲可能静默失败。握手数据要么无法转发，要么响应无法返回。没有报错，没有崩溃，什么都没有。

TLS 1.2 完全避免了这个问题：它的握手分散在多个较小的往返消息中，没有任何单条消息大到足以引发问题。

这对代理质量意味着什么

这类问题正是可靠代理服务与令人沮丧的代理服务之间的分水岭。

如果没有主动诊断，服务商只会看到用户抱怨随机的 HTTPS 故障。客服会说"重启应用"或"检查网络连接"。问题时有时无，没有人会把它与 TLS 版本或设备内存联系起来。

在 iProxy，我们自动检测到了这一规律。我们的诊断系统识别出：在特定设备、特定时间，TLS 1.3 失败而 TLS 1.2 正常——这精确地告诉了我们该从哪里入手。

我们采取的措施

在理解问题之后，我们发布了两项修复：

智能 TLS 回退。 当我们的诊断系统检测到设备上的 TLS 1.3 故障模式时，会自动进行调整。流量持续传输，用户无需做任何操作。

自动恢复。 如果设备进入降级状态，我们可以触发远程应用重启，以释放内存压力并恢复完整功能。诊断系统检测到需要时会自动处理，无需用户介入。

我们还排查并修复了应用中导致该问题的内存泄漏。改进效果在监控面板上立竿见影——整个设备群中 TLS 1.3 故障率显著下降。

这才是"托管代理基础设施"的真正含义

任何人都能写一个转发 TCP 数据包的应用。难的是：知道它什么时候停止工作、为什么停止工作，并在用户提交支持工单之前就将其修复。

iProxy 实时监控每台设备的网络健康状况。我们不等用户报告问题——我们主动检测、诊断，并在许多情况下自动修复。这就是代理应用与代理基础设施之间的区别。

我们的工程团队发布了对此次调查的完整技术深度剖析。如果你对细节感兴趣——数据包捕获、Go 与 curl 的差异、后量子密码学的角度——可以在这里阅读：当 TLS 1.3 在你的安卓代理内部静默消亡。

---

iProxy.online 在 100 多个国家、600 多家运营商提供移动代理基础设施。我们的安卓应用可将手机变成可靠的代理服务器，内置网络诊断、自动健康监控和远程管理功能。