Transport & data centres
Telegram runs on five geographically separate data centres. Every account lives on one of them. The client picks the right one for you, but it helps to know how the routing works.
What is a data centre
A Telegram DC is the physical home of an account or a piece of media. When you log in, your identity is bound to a single DC; when you upload a file, the file is stored on a single DC (sometimes a different one from your home). The DC id is just a small integer from 1 to 5.
You almost never need to think about this. The client asks help.getConfig on startup, learns the current DC list, and routes every request to the right place. Auth-key migration when you log into a non-default DC is transparent.
The five data centres
| DC | Location | Hostname |
|---|---|---|
| 1 | Miami, US | pluto.web.telegram.org |
| 2 | Amsterdam, NL | venus.web.telegram.org |
| 3 | Miami, US | aurora.web.telegram.org |
| 4 | Amsterdam, NL | vesta.web.telegram.org |
| 5 | Singapore, SG | flora.web.telegram.org |
The names are mythological — pluto, venus, aurora, vesta, flora — and that is what the wss://*.web.telegram.orgcertificates expect. There are also media DCs that share the home DC's number but serve files from a different IP; the client routes those automatically.
Transport modes
gogram supports two underlying transports and four MTProto framings on top of them.
TCP (default)
The fastest option. Raw TCP on port 443, MTProto obfuscation2 over the top. This is what you want everywhere except the browser.
WebSocket / WSS
Same MTProto, but wrapped in a WebSocket so it goes through any HTTP-aware proxy and works inside the browser. Slightly more overhead per request; in practice the difference is invisible.
client, _ := telegram.NewClient(telegram.ClientConfig{
AppID: 12345,
AppHash: "...",
Session: "session.dat",
UseWebSocket: true,
UseWebSocketTLS: true,
})client, _ := telegram.NewClient(telegram.ClientConfig{
AppID: 12345,
AppHash: "...",
Session: "session.dat",
UseWebSocket: true,
UseWebSocketTLS: true,
})Framings
On top of the chosen transport, MTProto messages are framed in one of four ways: Abridged (1-4 byte length prefix, smallest overhead), Intermediate (4-byte length, easier for intermediaries to parse), PaddedIntermediate (intermediate + 4-15 bytes of random padding so packet sizes leak less), Full (full sequence numbers + CRC, useful for proxies). Default is Abridged; you only change this when working through an MTProxy that requires otherwise.
Running in the browser
gogram compiles to js/wasm with no source changes. The browser has no raw TCP socket so you must set UseWebSocketTLS: true. The library's session storage backend in the WASM build skips file I/O entirely; use a StringSession and save it to localStorage yourself.
DC migration
When the client talks to the wrong DC, the server replies with a PHONE_MIGRATE_X, USER_MIGRATE_X, NETWORK_MIGRATE_X, or FILE_MIGRATE_X error where Xis the right DC number. The library intercepts these, does a fresh handshake on the right DC (or reuses an exported sender if you already have one for that DC), and retries the call. From your code's point of view the call just succeeds, slower the first time.
File downloads from non-home DCs are common. The first chunk pays the migration cost; withCacheSenders: true (the default) the per-DC sender stays warm and subsequent downloads reuse the connection.
