Telegram Infrastructure Analysis Reveals DC3 Inactivity and DC5 Reliability Issues
A detailed breakdown of Telegram’s server allocation shows DC3 no longer accepts new registrations, while DC5 in Singapore suffers from frequent outages that disrupt service for its user base.
An analysis of Telegram’s infrastructure, originally reported by Coxxs, indicates the platform operates five data centres designated as DC1 through DC5. The facilities are geographically distributed, with DC1 and DC3 located in Miami, USA; DC2 and DC4 in Amsterdam, Netherlands; and DC5 in Singapore. The investigation confirms that user accounts are permanently assigned to a specific data centre upon registration based on phone number country codes. This allocation is static and does not migrate with the user’s physical location.
Technical testing involving over 10,000 global phone numbers has established that DC3 no longer accepts new user registrations. Existing accounts previously held on DC3 appear to have migrated to DC1. Evidence from specific user accounts, such as @urie and @flowinglig, shows that while older files remain on DC3, recent activity and new file storage are directed to DC1, suggesting a completed migration process for legacy users.
DC2 in Amsterdam remains operational and hosts a significant user base, particularly for regions such as Germany. However, automated bots frequently misidentify DC2 users as being on DC4. This error occurs because DC2 and DC3 utilise the Web Content Delivery Network (CDN) domains of DC4 and DC1 respectively. Consequently, bots relying on profile picture domain prefixes, such as cdn4, incorrectly classify DC2 accounts.
Reliability concerns are centred on DC5 in Singapore, which is noted for frequent outages. When DC5 experiences downtime, users on that server face service disruptions and must wait for client reconnections. This instability has generated significant discussion within user communities, with some users migrating to other data centres to avoid the risk of service interruption.
The study outlines three methods for determining a user’s data centre allocation. The first involves triggering a PHONE_MIGRATE error via the MTProto protocol, which is accurate but requires the user’s phone number. The second method checks the dc_id field in the userProfilePhoto structure or file storage locations, which is reliable for users who have uploaded content. The third method, relying on CDN domains, is prone to error for DC2 users due to the domain borrowing arrangement described above.
