Telegram 号称有 5 个数据中心（DC, Data Center）
，在 Telegram 代码与文档中被称作 DC 1~5。其中 DC1 与 DC3 位于美国的迈阿密（Miami, USA）；DC2 与 DC4 位于荷兰的阿姆斯特丹（Amsterdam, NL）；DC5 位于新加坡（Singapore）。
从日常宕机的 DC5 说起
在 5 个 DC 中，DC5 在 Telegram 中文圈格外知名——并不是因为它默默无闻服务了大量的中文用户，而是因为它经常宕机。
当 DC5 宕机时，身处 DC5 的用户无法使用 Telegram，此时的 Telegram 圈内的话题往往会变成 「DC5 怎么又挂啦」。DC5 用户只能等待自己不断「重连中」的客户端恢复后，再与其他 DC 的群友们一起批判 DC5。
DC2 与 DC3 之谜
为了满足群友们的好奇心，有人写了个 bot（机器人），可以查询用户所处的 DC。于是群友们开始查起了自己的 DC：
用 +86 手机号注册的用户发现自己在 DC5（新加坡），即将体验下一次宕机。
用 +1 手机号注册的用户则会在 DC1（美国迈阿密），可以兼顾连接速度与稳定性。
用欧洲手机号注册的用户会发现自己在 DC4（荷兰阿姆斯特丹），成为了中文圈中最稀有的存在。
咦？等等… Telegram 不是号称有 5 个 DC 吗？那 DC2 与 DC3 呢？
通过搜索 bot 的消息，用户位于 DC1 的有 360 条，DC4 有 50 条，DC5 有 390 条。DC2 与 DC3 有 0 条。
通过搜索 bot 消息的「大数据查询」，我们发现似乎真的没有来自 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 ，为何上文的 bot 从未发现过来自 DC2 的用户呢？
这是因为 bot 获取 DC 的方式出了问题。
我到底在哪个 DC？
方法 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 法）
最后我们通过上文提到的 bot 查询这个新号的 DC。
bot 说，该帐号所在的数据中心为 DC4（阿姆斯特丹，荷兰）
咦？这个新号不是位于 DC2 吗，为什么 bot 会说是 DC4 呢？
其实它是通过 Telegram Web CDN 来获取用户的 DC 的。我们打开 https://t.me/dctest** 查看源码，会发现新号的头像域名是以 cdn4 开头的，导致被 bot 判断为了 DC4。
由于 DC2 与 DC3 会「借用」同地点的 DC4 与 DC1 域名来提供 Web CDN 服务，因此 bot 无法找到任何 DC2 用户——他们都被判断成了 DC4 用户。
还有另一种 bot，要求用户给 bot 发送一个图片/文件来判断其 DC。这类似方法 2，可以较为准确的判断用户 DC。
DC3 的消失
通过方法 2 正确获取用户 DC 后，我们可以发现在全球范围内（尤其是海外群组内），DC2 的用户并不算少，但 DC3 用户却屈指可数。多方查找后，我们发现了两名位于 DC3 的用户：@urie** 与 @flowinglig**。
然而，如果进一步分析，就会发现他们可能并不是真的在 DC3。例如，调用 photos.GetUserPhotos 查看头像列表，可以看到 @urie** 上传过 7 张头像，其中只有两张位于 DC3，新上传的头像都已在 DC1。
同样的，查看两位用户发言历史中的图片，也只有寥寥几张老图片是存于 DC3 的，新图片都是存在 DC1。而查看其它 DC 的用户，则发现他们发送的图片都存在各自所在的 DC 中。
此外，@urie** 也在 2021 年发送过文件给 DC 识别机器人（文件法）进行测试，返回的结果同样是 DC1。
遗憾的是，由于无法获知他们的手机号，所以并不能通过方法 1（登录法）准确测试，这里只能通过方法 2（头像/文件法）推测他们从 DC3 被转移到了 DC1。
为了进一步证实 DC3 已经不再接受新用户，我们生成了万余个全球各个地区的号码，通过方法 1（登录法）测试 Telegram 的 DC 分配规则，结果如下：
在测试过程中，我们尽可能让每个号码都连接到错误的 DC 上——这是为了通过返回的
PHONE_MIGRATE_X错误了解号码对应的实际 DC，也是为了避免产生大量垃圾短信，造成骚扰及 Pavel Durov 因短信费破产。在完成测试后，我们剔除了确定位于 DC4 的号码，再将剩余号码连接至 DC4 再次判断，以确保不会遗漏被分配至 DC3 的号码。
结合以上分析，我们可以认为 DC3 确实已不再接受新用户，而老用户也可能已经全部被转移至 DC1 了。
尽管我们没能找到消失的 DC3，但如果你想要成为指定 DC 的用户，回避 DC5 的宕机风险，或是测试一下测试机器人是否靠谱，现在只需参考上一张图，使用特定国家代码的号码注册即可。
由于 Telegram 服务端和部分运作机制并不开源，本文许多结论是通过推测得出。如有发现文中的错误，或有其他线索，欢迎评论提出。
本文撰写过程中参考了以下项目及内容，在此表示感谢：
Telegram DC 分析报告 by Hertz
我的 Telegram 账号在哪个 DC ？（Web CDN 法） by oott123
Plus Messenger（头像法）
@WooMaiBot（Web CDN 法）
@where_is_my_dc_bot（文件法）
本文摘自dev.moe