Telegram 声称拥有 5 个数据中心（DC），在 Telegram 的代码和文档中称为 DC1~5。其中，DC1 和 DC3 位于美国迈阿密；DC2 和 DC4 位于荷兰阿姆斯特丹；而 DC5 位于新加坡。每个账户在注册时会关联一个 DC，并且不会因用户的电话号码或地理位置而改变。用户不能自由选择一个 DC——如果连接到错误的 DC，服务器将返回错误消息，要求客户端连接到与账户关联的正确 DC。 在 5 个 DC 中，DC5 在中国 Telegram 社区中格外知名——并不是因为它暗中为大量中国用户服务，而是因为它频繁宕机。当 DC5 宕机时，DC5 的用户无法使用 Telegram，Telegram 社区中的话题经常变成“为什么 DC5 又宕机了？”DC5 的用户只能等待他们不断“重连”的客户端恢复，然后与来自其他 DC 的用户一起加入群聊来批评 DC5。 关于 DC2 和 DC3 的谜团 为满足群成员的好奇心，有人创建了一个机器人来查询用户所在的 DC。因此，群成员开始检查他们的 DC：使用 +86 电话号码注册的用户发现自己在 DC5（新加坡），正准备经历下一次宕机。使用 +1 电话号码注册的用户在 DC1（美国迈阿密），享受连接速度和稳定性。使用欧洲电话号码注册的用户发现自己在 DC4（荷兰阿姆斯特丹），成为中国 Telegram 社区中最稀有的用户。什么？等等……Telegram 不声称有 5 个 DC 吗？DC2 和 DC3 怎么回事？通过搜索机器人的消息，发现 DC1 有 360 用户，DC4 有 50 用户，DC5 有 390 用户。DC2 和 DC3 的用户数量为 0。通过对机器人的消息进行“大数据查询”，似乎确实没有来自 DC2 或 DC3 的用户。因此，有人推测 DC2 和 DC3 没有用户，而另一些人则分析推测 DC2 和 DC3 分别是 DC1 和 DC4 的从属 DC，在其母 DC 繁忙时接受用户注册。真的是这样吗？ Telegram DC 分配规则（2022-05） TL;DR：DC1、DC2、DC4 和 DC5 根据注册时提供的电话号码国家代码进行分配。这 4 个 DC 随时接受新用户注册，并有大量现有用户。DC3 曾经有用户，但在 2020 年左右，DC3 的现有用户可能已转移至 DC1。目前 DC3 可能没有用户，也不再接受新注册。换句话说，DC2 实际上有大量用户，和其他 DC 一样，只要注册时的电话号码国家代码在 DC2 的范围内（例如 +49 德国），用户肯定会分配到 DC2。同时，虽然 DC3 仍在运行，但可能没有关联的用户。既然 DC2 上有许多用户，为什么上述机器人从未检测到 DC2 用户？这是因为机器人的 DC 检索方法存在缺陷。 我实际上在哪个 DC？ 目前有 3 种常见方法来确定一个 DC。下面，我们将注册一个新的 DC2 账户并尝试这 3 种方法。 方法 1（登录方法） 使用一个将分配到 DC2 的电话号码，我们通过 Telegram 的 MTProto 协议（与官方客户端使用的相同协议）连接到 DC1，调用 auth.sendCode 接口，尝试发送验证码以注册账户。此时，服务器返回 PHONE_MIGRATE_2 错误，表明客户端应连接到 DC2（如果在连接 DC2 后执行相同操作，则验证码将直接发送）。这样，我们就知道这个账户是一个 DC2 账户。此方法也适用于已经注册的账户，但需要知道用户的电话号码，使得查询群成员的 DC 变得困难。 方法 2（个人资料图片/文件方法） 在注册 DC2 账户后（下面称为新账户），我们使用一个可以显示用户 DC 的第三方客户端（如 Plus Messenger），用另一个账户登录，并检查新账户的 DC。然而，该客户端在我们为新账户上传个人资料图片之前无法显示 DC，上传后会显示新账户在 DC2。这是因为第三方客户端在下载用户的个人资料图片时，会根据 MTProto 协议中 userProfilePhoto 结构中的 dc_id 字段来检索用户的 DC。此方法根据用户上传文件存储的 DC 确定用户的 DC。如果你用新账户登录第三方客户端检查自己的 DC，可能会使用方法 1 来确定 DC，因为客户端知道其连接到哪个服务器。 方法 3（Web CDN 方法） 最后，我们使用之前提到的机器人查询新账户的 DC。机器人说该账户在数据中心 DC4（荷兰阿姆斯特丹）。嗯？这个新账户不是在 DC2 吗？为什么机器人说是 DC4？原来机器人通过 Telegram 的 Web CDN 来确定用户的 DC。如果我们打开 https://t.me/dctest