PAYATHON 2026

Cloudflare 代理下 Telegram Android Mini App 为何一直加载？

数据小陈

结论

现有现象显示，故障与请求经过 Cloudflare 代理时，Android 版 Telegram 内置 WebView 无法正常建立或保持连接有关。关闭 Cloudflare 代理后恢复，或保留代理、关闭 TLS 1.3 后恢复，都是有用的对照结果。不过，这些结果还不能证明根因是 TLS 1.3 的某个具体缺陷，也无法确定故障发生在 TLS 握手、协议协商还是其他连接阶段。

问题中提到，Android 设备上没有观察到页面请求。这不一定表示客户端没有尝试连接。如果连接在发出 HTTP 请求前就失败，通常也不会留下页面请求记录。

Full 和 Full (strict) 为什么没有解决

Cloudflare 的 SSL/TLS 加密模式主要规定 Cloudflare 与 Railway 源站之间的连接要求。TLS 1.3 开关影响的则是访客客户端与 Cloudflare 边缘节点之间的连接。它们作用于不同链路。因此，调整 Full 或 Full (strict) 后问题仍然存在，不能排除 Android Telegram WebView 与 Cloudflare 边缘节点之间的兼容性问题。

启用 Cloudflare 代理后，向客户端提供证书的是 Cloudflare。只有确认故障与证书链验证有关，“需要完整证书链”的提示才适用于这个案例；目前的信息不足以判断证书链就是原因。可以检查客户端实际收到的证书链，但要区分 Railway 源站证书链和 Cloudflare 提供给访客的证书链。

建议的排查步骤

  1. 固定变量，重复对照测试。 使用同一台 Android 设备、同一网络和同一 Telegram 版本，分别测试 Cloudflare 代理和 TLS 1.3 均开启、代理开启但 TLS 1.3 关闭，以及 DNS only。每次改动后确认 Cloudflare 设置已经生效，并记录测试时间和结果。

  2. 确认失败发生在哪一段。 对照 Cloudflare 的请求或安全事件记录、Railway 日志和 Android WebView 调试信息。如果 Cloudflare 和 Railway 都没有对应的 HTTP 请求，问题更可能发生在请求到达 HTTP 阶段之前；如果 Cloudflare 有请求而 Railway 没有，则检查 Cloudflare 到源站的连接。

  3. 核对客户端收到的 TLS 信息。 使用可用的 Android WebView 调试工具或其他 TLS 检测方式，查看证书链、协商的 TLS 版本和 ALPN。也可以在终端分别探测 TLS 1.2 和 TLS 1.3，例如：

    openssl s_client -connect example.com:443 -servername example.com -tls1_2
openssl s_client -connect example.com:443 -servername example.com -tls1_3

    将 example.com 替换为实际域名。这些命令只能验证运行命令的客户端到边缘节点的连接，不能替代在 Android Telegram WebView 中复现问题。

  4. 检查 Cloudflare 边缘侧设置。 如果关闭 TLS 1.3 后问题稳定消失，可以暂时保留这一设置，并确认代理、边缘证书和相关 TLS 配置均已生效。要查明具体触发条件，需要能记录客户端握手或边缘连接失败详情的工具。仅凭“没有页面请求”无法定位到某个 TLS 参数。

  5. 比较不同客户端。 如果 Android Chrome 正常而 Telegram 内置 WebView 失败，两个客户端的连接路径或运行环境可能不同。应以 Telegram 内置 WebView 的实际连接记录为准，不能只凭 Chrome 能打开页面就排除客户端兼容性问题。

临时处理与注意事项

目前已验证的绕行办法是保留 Cloudflare 代理并关闭 TLS 1.3。可以暂时采用这一设置，并观察 Telegram Android WebView 是否能稳定加载。关闭 TLS 1.3 后故障条件发生了变化，但这还不能说明具体缺陷来自 Telegram、Android、Cloudflare，还是它们之间的协商过程。

如果后续获得握手日志、边缘错误记录或证书链信息，可以根据失败阶段进一步缩小排查范围。缺少这些记录时，不宜将问题归因于证书链、Railway 配置或某个特定 TLS 参数。

备注：内容仅供参考。