ERROR 之前，先看错误发生在哪一层
网页只显示 ERROR，不能直接判定为 Telegram RPC 限流。 排查需要先确认是浏览器请求、开发者门户页面、客户端 RPC 调用，还是本站任务处理。不同层可以使用相同数字或相似文字。
本篇是官方错误文档的简明解读和 GetTGAPI 排查方法，不是完整错误码字典。门户申请问题可先看 my.telegram.org ERROR。
官方 RPC 文档怎么读
官方错误说明区分数字 code 与可选的字符串 type。常见分类包括 303 数据中心迁移、400 输入错误、401 未授权、403 隐私或权限限制、420 频率限制、500 内部错误。FLOOD_WAIT_X 的 X 是等待秒数。完整方法对应错误应查询原文及官方错误数据库，不要把这些数值当作网页 HTTP 状态的一一映射。
GetTGAPI 建议的诊断顺序
下面是本站的工程排查建议，与上面的官方分类说明分开阅读。
- 定位页面和动作：记录是发确认码、提交验证码，还是创建应用；不要只记录一个“失败”。
- 确认是否有明确回应：页面提示、HTTP 响应和管理日志应分别查看。超时代表结果尚不明确，不能直接写成官方拒绝。
- 先核对结果再决定重试：有可能创建已完成，但结果页面读取失败。先查看应用是否存在，避免再次执行创建操作。
- 保留原始诊断和用户提示两层：管理员看到经过脱敏的具体信息；客户看到原因范围与可执行动作，不暴露内部网络配置或秘密。
一个可复用的记录模板
这是用于组织证据的示例结构，不是 Telegram 返回格式，也不是一个真实客户日志：
{
"stage": "read_application_result",
"source": "portal_parser",
"upstream_error_type": null,
"outcome": "needs_result_check",
"next_action": "verify_existing_application"
}
没有明确的官方错误类型时，保留 null；不要根据一个模糊 ERROR 自动填入限流标签。保留请求时间与重试次数用于排查，但不要记录验证码、API Hash、Cookie 或会话文件。
结果解析失败，也可能看起来像排队
GetTGAPI 在维护中处理过一种页面兼容问题：页面显示被遮盖的 Hash，程序没有读到实际值，因而反复核对结果。这个现象说明应用创建、结果解析、任务排队应分别验证。单看“正在处理中”，不足以推断上游不给创建或队列堵塞。
这是一条本站维护经验，不代表所有长时间处理都是同一个原因。若有明确的官方等待时间，应按实际回应处理；若没有，先核实证据，不编造等待秒数。
怎样向客服描述问题
提供出错页面、操作步骤、时间和不含秘密的提示即可。gettgapi.com/help#contact 的客服可协助排查 API ID / Hash 申请；如果是自己软件调用 API 后报错，请先阅读 API_ID_INVALID 或 FLOOD_WAIT，并区分应用配置与门户申请问题。