OPay 与竞品（PalmPay、Moniepoint）真机性能与可用性对比测试报告

报告信息与综合结论

0.1 综合结论

在相同设备、相同网络、相同操作下，OPay 与竞品的差距集中在首帧之后的内容加载、转账页创建、弱网降级与网络链路可用性，冷启动首帧本身不落后。按 2.4 节判定规则：

• 页面速度：9 个核心页面场景中 OPay 有 7 项落后于 PalmPay，其中 4 项明显落后（流量页 1.6 倍、转银行页 1.6 倍、Betting 页 2.1 倍、消息页 2.9 倍）；1 项持平（选套餐 → 收银台）；交易列表领先（因账号数据量不同，仅作参考）。
• 冷启动：首帧持平（1.05 vs 1.09 秒）；首页内容出齐落后（6.40 vs 4.36 秒，1.47 倍），每次启动都受影响。
• 后台压力：三家在后台都会被系统回收；按各页面倍数中位数两家持平（OPay 1.42、PalmPay 1.33），但 OPay 的流量页（1.94 → 5.98 秒，3.1 倍）和收银台（1.58 倍）受影响明显大于 PalmPay。
• 可用性：交易记录间歇性打不开（4G 4/12 轮、3G 3/4 轮），原因是 3 个 Akamai CDN 节点 TLS 握手无回应，判定为严重；3G 同地同时段业务接口报错率 OPay 8%、PalmPay 1%。
• 弱网：接近断网时两家都进不了话费、流量收银台；PalmPay 用本地数据显示关键信息并提示重试，OPay 关键内容为空、无提示，降级处理落后。
• 收银台（第 9 章）：线上 AA、AC 收银台 57% 超过 3 秒，是慢 PV 最大来源；真机网络好时 OPay 与 PalmPay 接近（话费 1.50 vs 1.36 秒），但链路串行——下单 → 中转页 → 新建加密连接 → 广告 → 才取支付信息，条件变差时放大最多（后台压力下 1.58 倍）。改法见 P0-6 ①–⑥。
• 稳定性：723 个有效轮次中三家均未出现 ANR 和崩溃。
• 机型对照：换用 4GB 的 Infinix 后差距依旧（页面倍数中位 1.37，itel 为 1.25），说明差距主要来自 OPay 页面自身流程，而非低端机特有。

共记录问题 14 项（严重 1、一般 8、轻微 3、待确认 2，见第 5 章），改进建议按投入产出排序见第 6 章。

1 测试概述

1.1 测试目的

• 在可控、可复现的条件下，量化 OPay 与主要竞品在核心用户场景上的速度与可用性差距。
• 定位差距的根因（客户端流程、接口、网络链路、设备资源），为 Faster（页面速度）与 Available（稳定性、可用性）专项提供可排期的改进项。
• 建立可重复执行的对比基线，用于改进后的复测验收。

1.2 测试范围

1.3 被测对象与对照对象

1.4 测试环境

1.5 测试场景定义

1.6 测试方法

• 轮次：每个场景每家，4G 无压力 5 轮 × 2 批（合并计算），后台有压力 3 轮，冷启动无压力 4–6 轮、有压力 3 轮；另每场景每家 1–2 轮诊断轮（加抓包）。
• 顺序：按 App 分块、前后交替（Moniepoint → PalmPay → OPay → OPay → PalmPay → Moniepoint），抵消时段与网络波动；不在同一轮内交错，因为 Moniepoint 在后台约 1 分钟即锁屏。
• 起始状态：除冷启动外，每轮从已登录首页开始（App 在前台，首页已稳定 2 秒以上）。
• 后台有压力：每轮开测前依次打开 7 个常用 App（Chrome 加载新闻页、YouTube、谷歌地图、Facebook Lite、相机、YouTube Music、Gmail），每个停 5–10 秒，回到桌面后再打开被测 App。效果见 4.4 节。
• 网络条件：4G 为自然条件；EDGE 为 10-21 偶然掉网时段；固定 2G / 3G 为测试人员在系统设置中锁定首选网络。
• 诊断轮：在普通轮基础上开启 PCAPdroid 抓包，记录每个连接的域名、服务器 IP、TLS 握手和请求等待；诊断轮不计入耗时统计。

2 指标定义、统计口径与判定规则

本章说明报告中每一个数字是怎么测出来的、用的什么统计量、精度有多高，以及"落后 / 持平"等判定是怎么得出的。

2.1 性能指标

图 2-1视觉完成怎么判定（OPay 流量页，itel A50，4G，无后台压力；取 10 轮中与中位数最接近的一轮，1.96 秒）点击图片放大

时间从点击注入完成算起。橙框为按下首页 Data 入口；0.06 秒的按压反馈即算"画面开始变化"；0.50 秒为页面转场；绿框为视觉完成，此后画面与最终画面的差异小于 0.5%。最右为同一轮的循环动画区：红色是观察窗口内变化 ≥4 次的像素（三重礼倒计时、轮播 Banner 以及加载时多次位移的区域），不参与判定，所以倒计时、轮播不会把视觉完成无限推后。系统首帧（0.24 秒）是系统日志记录的新页面第一帧时刻，此时录屏仍是首页，转场动画随后开始。手机号、用户名、交易提示已打码。

图 2-2冷启动"首页内容出齐"怎么判定（OPay，itel A50，4G，已登录；取 5 轮中位数那一轮，6.40 秒）点击图片放大

蓝框为系统首帧 1.03 秒，画面还是启动页；3.20 秒首页框架和入口出来，余额仍在转圈；6.10 秒余额仍未出；绿框 6.40 秒内容出齐。最右红框为排除区：右下"Click for Security"悬浮按钮出现后会自动收起，不算首页内容变化。用户名、交易提示已打码。

2.2 可用性与网络指标

2.3 统计口径

• 统计量：耗时一律取中位数，括号内为最小–最大值；表中 n 为有效样本数。样本量为 3–10，P90 不稳定，故不报告耗时 P90。
• 合并规则：10-21 的两批 4G 测试合并计算；后台有压力、2G、3G 各自单独统计，不与 4G 合并。
• 网络分档：每轮开始前、结束后各探测一次，取较差的一次定档：无网 > 2G（EDGE / GPRS）> 3G（HSPA 等）> 4G。10-21 13:16–15:50 那批没有逐轮探测，按当时抽查记为 4G。因部分 PalmPay、Moniepoint 轮次落在 EDGE 时段，它们的 4G 样本为 7 轮，OPay 为 10 轮。
• 倍数：OPay ÷ PalmPay（同条件中位数之比）；"加压倍数"为同一 App 有压力 ÷ 无压力。"各页面倍数中位数"为各页面倍数的中位数。
• 作废与失败：作废轮次（测试条件被破坏，如账号在其他设备登录被挤下线、测试人员在录屏窗口内操作）整轮剔除；失败轮次计入失败率，但不计入耗时统计。

2.4 判定规则

2.5 测量方法验证

• 时钟差校正：点击时刻由电脑记录，录屏与系统日志使用手机时钟。逐轮在开测时写一条标记日志、读回手机时间，与电脑时间求差后校正。实测时钟差在 itel 上两天内从约 0 漂移到约 0.5 秒，Infinix 约 0.5 秒；V4 及以前未校正，视觉完成整体偏小 0.2–0.5 秒，V5 起已全部重算。
• 起点偏差：校正后各批次"起点 → 画面首次变化"的中位数为 0.09–0.12 秒，两台手机、不同时段一致，三家同口径。
• 逐帧核对：对异常值逐帧检查录屏。例如 itel 冷启动中，余额在启动后 6.4 秒出现，算法结果 6.44 秒；后台有压力的一轮内容 5.9 秒出齐，算法结果 5.88 秒，均与人工判读一致。
• 精度限制：Moniepoint 多数页面在 0.3 秒内完成，零点几秒的差异处于测量精度附近；Flutter 应用没有系统首帧和卡顿数据。

3 测试执行情况

3.1 批次与轮次

3.2 与计划的偏差

3.3 阻碍因素与处理

• 冷启动后的营销弹窗偶发遮挡首页（OPay "EARN MORE"理财弹窗、PalmPay "Free Cash"弹窗），导致 B5 中 2 轮"首页就绪"超时；已在脚本中加入自动关闭弹窗（找不到关闭按钮时按一次返回），2026-10-23 验证通过。
• Infinix 上 uiautomator2 报告的前台应用不准确，已改为读取系统窗口焦点。
• 电脑走代理网络，所有网络相关测量只在手机上进行。

图 3-1执行中遇到的两类阻碍（Infinix X6531B，10-22，均为失败轮次的录屏原样画面）点击图片放大

左：OPay 冷启动后"EARN MORE"理财弹窗挡住首页入口，脚本找不到入口，该轮记为失败（非 App 故障）。右：数据网络瞬断约 1.8 秒时 PalmPay 弹出"No Network Connection"，网络恢复后仍不消失，同样挡住入口。用户名、账号已打码。

4 测试结果

4.1 结果判定总表

4.2 页面速度（4G，无后台压力）

分析：话费、流量、收银台、交易列表的首帧两家相近，OPay 的差距出现在首帧之后（等接口与营销模块）；转账页的首帧本身就是 PalmPay 的 3–4 倍，说明转账页的创建和布局本身较重，问题不只在接口。

以下截图取每家与中位数最接近的一轮，同一时刻并排对比，绿框为该轮视觉完成；用户名、账号、手机号、收款人已打码。

图 4-1流量页：三家同一时刻的画面（itel A50，4G，无后台压力）点击图片放大

OPay 1.5 秒时只有号码行，三重礼、优惠券、套餐与返现到 1.96 秒才出齐；PalmPay 1.0 秒出框架、1.33 秒完成。Moniepoint 这一轮进入流量页即弹出通讯录权限说明框，视觉完成测的是带弹框的画面，仅作参考。

图 4-2Betting 页：三家同一时刻的画面（itel A50，4G，无后台压力）点击图片放大

OPay 1.0 秒页面只有输入框，1.5 秒出平台与金额，2.19 秒推荐活动等营销模块出齐；PalmPay 1.0 秒基本完整（1.21 秒完成）；Moniepoint 为平台列表页，0.25 秒完成。

图 4-3消息页：OPay 与 PalmPay 同一时刻的画面（itel A50，4G，无后台压力）点击图片放大

OPay 消息页为 RN 页面，1.0、1.5 秒只有标题和分类标签，1.94 秒消息列表才出现；PalmPay 0.5 秒列表已出（0.62 秒完成）。Moniepoint 无此入口。

图 4-4本平台转账页：首帧差距（itel A50，4G，无后台压力）点击图片放大

OPay 系统首帧 0.74 秒，录屏中 0.8 秒仍是首页、1.0 秒新页面才出现；PalmPay 系统首帧 0.16 秒，0.6 秒页面已出。两家视觉完成接近（1.24 vs 1.23 秒），差距主要在页面创建（见 F-05）。OPay 最近收款人（姓名、账号）已打码。

4.3 已登录冷启动

过程观察：OPay 冷启动依次出现空白页加顶部转圈 → 入口区 → 用户名与余额卡（余额先转圈）。首页右下角"Click for Security"悬浮按钮在内容出齐后约 2–5 秒自动收起，属动效，不计入（V4 的 9.7 秒即被它拉长）。生产包冷启动抓包（5 轮）显示，首页业务接口 api.opayweb.com 要到启动后 3.2–4.5 秒才发出，此前已先发出 26–41 个请求（Facebook SDK 7、首页配置 5–9、AB 测试 4–6、埋点 3–4、AppsFlyer 2–3、设备安全配置 2–3）。同一次运行中 Application.onCreate 耗时 OPay 791ms、PalmPay 约 285ms、Moniepoint 228ms。

4.4 后台有压力

4.5 网络条件

4.5.1 偶发 EDGE（10-21，延迟正常、带宽低；仅 PalmPay、Moniepoint）

4.5.2 固定 2G（10-22，接近断网；OPay、PalmPay）

测试人员锁定首选网络为 2G，两家同时段交替测试（每场景 5 轮 + 1 轮诊断）。网络记录：开头约 7 分钟 ping 往返 0.27–3.3 秒、丢包 33%，之后 ping 基本全丢，中间数次完全断网。两家条件相同，本节只比较"能否使用、如何降级"，不比较耗时。

图 4-5固定 2G：话费页（itel A50，10-22；OPay 为失败轮次）点击图片放大

OPay 页面能打开，但 15 秒内本机号码（只显示 0XX XXXX XXXX 占位）、运营商和金额档位都不出，只剩手动输入框并一直转圈；PalmPay 号码和金额档位 1 秒内即显示（本地缓存兜底）。PalmPay 手机号已打码。

4.5.3 固定 3G（10-22，同地同时段复测）

锁定首选网络为 3G（HSPA+）。实测 ping 中位 42ms、P90 46ms，160 次探测仅 1 次丢包，与 10-21 的 4G（中位 38ms）相当，并非慢网；两家 3G 与 4G 的耗时基本相同（各页面倍数中位 OPay 0.98、PalmPay 1.06）。本节价值在于两家在完全相同地点、时段下的对比。

4.6 可用性与网络报错

图 4-6交易记录打不开（OPay，itel A50，4G，10-21 17:55；交易域名被分到问题 CDN 节点）点击图片放大

进入后一直转圈，30 秒仍无列表，30.8 秒才出现错误页（插画 + Retry），不显示上次缓存的列表。4G 下失败的 4 轮，错误页都在 30.4–30.8 秒出现。

根因：3 个 CDN 节点 TLS 握手无回应。把 4G、3G 全部 OPay 诊断轮按"域名 × 服务器节点"汇总，30 次 TLS 握手无回应全部落在 3 个 Akamai 节点上；同样的域名分到其他 23 个节点（Akamai 19、Cloudflare 4）时 95 次握手全部成功。问题在节点本身，而非某个域名的证书或配置。

4.7 接口、流量与资源

4.8 流畅度

4.9 登录前与重新登录

4.10 机型对照：Infinix X6531B（4GB）

• 差距不是低端机特有的：Infinix 上 OPay 各页面中位仍是 PalmPay 的 1.37 倍；流量 1.5、转银行 1.7、Betting 2.1 倍与 itel 基本一致。
• Infinix 上 OPay 冷启动首帧也落后：1.28 vs 0.66 秒（itel 上持平）。PalmPay 在更好的手机上首帧缩短约 40%，OPay 没有改善，与 OPay 启动阶段同步工作较多（4.3 节）一致。
• 转账页首帧差 3 倍，两台手机一致，与机型无关。
• 消息页差距缩小到 1.3 倍：消息页为 RN 页面，初始化主要消耗 CPU，设备越好越不明显。
• 附带观察：数据网络瞬断约 1.8 秒时，PalmPay 弹出"No Network Connection"弹窗，网络恢复后不会自动消失。

5 问题清单

严重程度定义：严重——核心功能在可复现条件下不可用；一般——明显落后基准（> 1.5 倍）、影响每次启动，或在后台压力、弱网等条件下明显劣化；轻微——小幅落后（1.1–1.5 倍）或体验瑕疵；待确认——现象存在，影响需后端或线上数据确认。

6 改进建议（按投入产出排序）

排序原则：影响面（每次启动 / 核心交易链路 > 二级页 > 低频页）× 与基准的差距 ÷ 实施成本。P0 建议本版本落地，P1 下个版本，P2 需产品或风控评审。预计收益为估计值，以改后复测为准。

保持的优势：登录前内存最省（PSS 114 MB，竞品 151–169 MB）；第三方域名最少；交易列表打开不慢于竞品；测试期间无 ANR 和崩溃。

7 残余风险与测试局限

残余风险：在 P0-1 修复前，被 DNS 分配到问题节点的线上用户会连续约 30 分钟（DNS 结果有效期）打不开交易记录，影响面需靠客户端失败上报量化。

8 结论与后续计划

本轮测试达到测试目的：在可复现条件下量化了 OPay 与竞品在 12 类场景上的差距，定位了主要根因，并建立了可重复执行的对比基线。OPay 在页面速度上整体落后于 PalmPay（页面倍数中位 1.25–1.37），在可用性上存在 1 项严重问题（交易记录因 CDN 节点间歇性打不开），弱网降级处理落后；冷启动首帧、内存占用和稳定性不落后。

• 后续计划 1：运维用北京时间 10-21 14:20–14:37、17:52–17:55、10-22 14:09–14:16 及上述 3 个 IP 查 Akamai 日志，确认节点问题并确认 DNS 两个别名的分配比例。
• 后续计划 2：客户端网络请求失败时上报域名、连到的 IP、失败阶段（DNS / 建连 / TLS 握手 / 等响应）与耗时，用线上数据量化受影响用户。
• 后续计划 3：后端按 App 版本统计设备安全配置接口的调用量与 403 比例。
• 后续计划 4：P0 改完后，用同一台手机、同一套脚本复测，按第 6 章验收标准验收。
• 后续计划 5：寻找信号弱但可连通的地点，三家同地同时段补测"慢但能用"的网络；如需高端机对照，可用 Mi 10 跑一批。
• 后续计划 6：后端按日志确认流量页、Betting 页约 235 / 135 KB 回包对应的接口，以及生产包传输时未压缩的原因（F-14）；改后用同一脚本冷缓存抓包复测。

9 收银台专题：链路拆解与改法

范围：话费、流量、本平台转账（AA）、转银行（AC）四个入口，从点击到收银台出现；不输入 PIN、不付款，支付提交与结果页不在范围内。数据：生产包真机录屏、系统页面事件与诊断轮抓包（itel、Infinix，10-21～10-23），测试包接口日志（itel，10-21），线上 Faster 埋点（9/16、8/22）。

9.1 线上：收银台是慢 PV 最大的来源

• Android 是 iOS 的 2.4–2.6 倍：同一套接口、同一个后端，差在 Android 端，与机型性能、后台回收后重新冷启动有关 推断，9.4 有真机实测。
• 体量最大：AA、AC 收银台是转账必经页面，PV 大、占比高，慢 PV 绝对量最大；改这一处的收益在所有页面里最高。

9.2 真机：网络好、手机空闲时与 PalmPay 差距不大

图 9-1话费：选金额 → 收银台，OPay 与 PalmPay 同一时刻的画面（itel，4G，无后台压力；各取与中位数最接近的一轮）点击图片放大

橙框为点 ₦100 档位。OPay 0.3–1.0 秒一直停在话费页、号码行上转圈，1.60 秒收银台整块弹出；PalmPay 在话费页显示加载图标，1.36 秒弹出支付底板。两家都是"原页面等待 → 整块弹出"，网络好时 OPay 只晚约 0.2 秒。手机号、余额、返现余额已打码。

图 9-2本平台转账（AA）、转银行（AC）：核对窗口 Continue → 收银台（OPay，itel，4G）点击图片放大

点 Continue 后回到金额页并转圈，AA 1.08 秒、AC 1.01 秒收银台弹出。转账的下单接口在上一步（金额页 Confirm）已调用，所以这一段比话费短。收款人姓名、账号、余额已打码。

9.3 一次打开收银台，发生了什么

9.3.1 生产包：页面事件（itel，4G，各 10 轮中位数，从点击算起）

9.3.2 测试包：接口时序（可看到接口名；测试包整体偏慢，只看先后顺序）

9.3.3 生产包抓包：进收银台时要先新建加密连接

图 9-3OPay 话费收银台逐帧（与图 9-1 同一轮）与收银台上的动画区点击图片放大

0.30–1.20 秒画面几乎不变，只有号码行上转圈：这段时间依次在下单、启动中转页和收银台页、新建连接、拉广告、取支付信息；1.60 秒支付信息到了，收银台才整块弹出，此前没有任何骨架。最右是同一轮收银台出现 3 秒后的动画区：支付方式一栏仍有转圈（红色），与测试包"收银台常驻动画、97% 的帧超过 16 毫秒"一致。手机号、余额已打码。

9.4 为什么线上慢得多：放大因素

• 串行越长，网络越慢放大越多 估算：收银台关键路径上至少有 3 次排队的请求（下单 → 广告 → 支付信息）和 1 次新建连接（TCP 1 次往返 + TLS 1 次往返），合计约 5 次网络往返。真机诊断轮建连实测往返 60–230 ms；线上移动网络往返更高时，每多 100 ms 往返，收银台约慢 0.5 秒。PalmPay 在原页面等待后直接弹出底板，链路短得多 推断（PalmPay 部分请求走 QUIC，抓包看不清请求边界）。
• 手机越忙放大越多 实测：后台有压力时 OPay 收银台慢 1.58 倍，PalmPay 只慢 1.16 倍；Android 线上占比是 iOS 的 2.4–2.6 倍，与此一致。
• 真机是"最好情况"：App 在前台、4G 信号好、连接刚建好，线上用户的条件只会更差。

9.5 收银台根因清单

9.6 改法、预期收益与验收

下表是第 6 章 P0-6（收银台预取） 的细化，编号与《Faster 核心场景提速方案》统一；⑥ 与 P0-2（接口压缩）一起做。预期收益为估算，以改后同一套脚本复测为准。

9.7 收银台部分的局限

• 只测到收银台出现，不输入 PIN、不付款；支付提交、结果页（含支付结果页广告）未测。
• 竞品只测到转账页，转账收银台无法对比；Moniepoint 确认单禁止录屏，仅作参考。
• 生产包没有接口日志，接口名与先后顺序来自测试包；生产包只能看到域名、字节和时间（抓包不解密）。
• 诊断轮开着抓包，耗时比普通轮长约 1 秒，只用于看先后顺序。

附录

A 术语

B 数据与复现

python compare.py --device itel                                   # 三方对比（按 App 分块，含诊断轮）
python compare.py --device itel --blocks opay:L,palmpay:L,moniepoint:L,startup_loaded --attended   # 后台有压力
python compare_report.py runs/compare_*.json                     # 单批报告
python cross_env.py runs/compare_A.json runs/compare_B.json      # 按实际网络类型量化
python cross_device.py runs/compare_itel_*.json runs/compare_infinix_*.json   # 机型对照
python net_errors.py runs/compare_A.json runs/compare_B.json     # 网络报错统计

C 广告图片明细与实际下载方式（测试包日志 + 生产包实测）

证据等级：实测 客户端日志、抓包字节或画面直接观测；推断 由实测数据推出、未逐张观测；待核实 尚无客户端证据。2026-10-23 更正：此前版本用后台原图计算大小，写成"原图直出、未压缩、下载量与设备无关、重复下载约 135 KB"，与客户端实际行为不符，本附录已按下述实测改写。

图 C-1流量页顶部轮播（Infinix 生产包 8.18.2.498，10-23 冷缓存实测）点击图片放大

顶部为 5 张轮播，画面中是 4304（"Claim 8 Discounts…"）；控件宽 608 px，按 608 宽 WebP 下载（见上表）。手机号已打码。

完整字段见 runs/广告素材清单_itel_20261021_053436.csv（后台原图）与 runs/广告素材实际加载_20261023.csv（实际请求、下载量与证据等级）。第 4 章诊断轮中广告图片已在 App 本地缓存、未出现图片下载，耗时不含图片下载。

C.1 广告后台核对（2026-10-23，同日按实际下载更正）

在营销后台"广告素材管理"中按广告 ID（后台字段 adInfoId）逐个查询上表 24 个广告（另 2 项为营销任务与 kBox 的内容素材，不在广告后台），只读查询，未做任何修改。核对内容与结论：

C.2 第一次加工 vs 已缓存：手机实测（2026-10-23）

C.3 大接口回包与页面完成时间（生产包诊断轮，逐帧核对）

图 C-2大接口回包前后的画面（生产包诊断轮，逐帧）点击图片放大

上：Infinix 10-22 流量页，2.03 秒套餐列表已出但没有返现，回包 4.53 秒收完后每个套餐出现"₦0.50 Cashback"等返现；下：itel 10-22 Betting 页，1.20 秒金额格子已出但没有折后价，回包 1.74 秒收完后出现"Pay ₦90"等折后价与推荐活动。手机号已打码。

另见 F-14：同一次核实中发现，流量页、Betting 页每次打开都有一个约 235 KB / 135 KB 的接口回包（生产包 5/5 轮），测试包同类接口 gzip 后只有 12.7 / 6.1 KB；这两页单轮流量偏大的主因是它，而不是广告图片。

D CDN 与 DNS 分配机制

受影响域名在 OPay 的 DNS 中各配置两个别名：*.edgesuite.net（Akamai）和 *.cdn.cloudflare.net（Cloudflare）。手机每次解析域名时，DNS 从两个别名中选一个返回。10-21 两批诊断轮中可看出分配结果的解析共 24 次：wallet-ws 分到 Akamai 9 次、Cloudflare 7 次；wallet-transaction 各 4 次。

• 分配接近随机，约各占一半，几分钟内即会切换，看不出按地区或用户固定分配；具体比例可在 opayweb.com 的 DNS 后台查看。
• 对单个用户在一段时间内固定：DNS 结果有效期约 30 分钟，被分到问题节点的用户会连续约半小时打不开交易记录，之后可能恢复，这是"时好时坏、难以复现"的原因。
• 只有少数 Akamai 节点有问题：23.32.248.206、23.32.248.213、184.27.140.86，以及 10-23 在 wallet-living 上新发现的 2.20.13.133；分到其他 Akamai 节点（如 23.32.248.215）时正常。
• 判断方式：IP 为 23.32.x.x、184.27.x.x 的是 Akamai，104.16.x.x、104.17.x.x 的是 Cloudflare。

E 修订记录