How much bandwidth a Telegram proxy uses

Anyone planning to run a Telegram proxy asks the same two questions. How much bandwidth does it actually use, and how many people can one server carry before it falls over? The honest answer surprises most people, because the part everyone worries about, the endless stream of messages, is the cheapest part by far. The parts nobody thinks about are the ones that really size the box.

Get this wrong in one direction and you pay every month for a server ten times bigger than you need. Get it wrong in the other and your proxy chokes at the exact moment people are relying on it. I run managed Telegram hosting on dedicated hardware in Singapore, so provisioning isn’t a thought experiment for me, it’s the job. Here’s where the bytes really go, what actually limits a proxy, and how to size one on evidence instead of fear.

What Telegram traffic is actually made of

Start with what the traffic is actually made of, because that’s where the intuition goes wrong. A plain text message on Telegram is tiny, a few kilobytes at most, often less. You could send thousands of them in a day and barely move the needle on a modern connection.

The heavy traffic is everything that isn’t text: photos, videos, voice notes, documents, and the media that flows through busy channels. That’s where the megabytes live, and a single forwarded video can outweigh a month of someone’s typing. So the moment you start sizing a proxy by “number of messages,” you’re measuring the wrong thing entirely.

What a single user costs in a day

Think about one ordinary user across a normal day. If they mostly type, send the odd photo, and read a few channels, they might move only a few tens of megabytes in total. That’s nothing.

The users who actually cost you are the media-heavy ones:

• The person downloading large files through the connection.
• The account sitting in busy channels pulling down video all day.
• The one backing up a huge chat history.

Your average is set by a small number of heavy users, not by the quiet majority. Ten quiet users can be lighter than one person who lives on video calls, so never size on the typical person alone.

Why voice and video calls are the real spike

Calls are the behavior that dominates a bandwidth picture. A voice call moves a steady stream of audio the whole time it’s connected, and a video call moves far more, continuously, for every minute it runs. One long video call can shift more data than a whole day of messaging.

So if your users make a lot of calls through the connection, that single behavior can outweigh everything else combined. It’s the number you have to plan around, not the message count you were worried about.

A rough per-user figure

Put that together into a working estimate:

• A light user, mostly text and a little media, might cost somewhere in the low tens of megabytes a day.
• A heavy user, lots of media and regular video calls, can easily run into hundreds of megabytes a day, sometimes more.

That’s a wide range on purpose, because the mix matters far more than the head count. Any sizing that ignores the difference between a light and a heavy user will be wrong.

Why bandwidth is rarely the first wall you hit

Here’s the twist that changes how you size everything. On a normal server with a normal connection, raw bandwidth is almost never the first wall you hit. A cheap modern box already has more throughput than a few dozen chatty users will ever saturate.

What actually gives out first is quieter: the number of connections held open at once, the little bit of processor work each of those connections costs, and above all the health of the IP they all sit behind. Bandwidth is the thing people measure and rarely the thing that breaks.

Concurrent connections

Every device using your proxy holds a live connection open the whole time it’s online, whether or not anything is being sent. An MTProto proxy handles many of these at once, but there’s always a ceiling, set by memory and by the operating system’s limits on open sockets.

So the number that matters isn’t how many users you have registered, it’s how many are connected at the same moment, at your busy peak. Size for the peak of simultaneous connections, because that’s what fills the box.

Processor cost

An MTProto proxy wraps every byte in an obfuscation layer, the very thing that makes the traffic hard to detect and block, and that wrapping costs a small amount of CPU for each byte that passes. On a tiny server carrying tens of users, this is nothing you’ll notice. It only starts to matter at hundreds of active users pushing media at once, when the constant wrapping and unwrapping adds up.

Running a proxy is not the same as hosting an account

Most sizing guides miss this completely. A proxy and a hosted account are two entirely different jobs with entirely different costs.

An MTProto proxy only relays traffic. It never logs into anyone’s account, it just passes obfuscated bytes back and forth, so its cost is mostly connections and throughput. Hosting a full account is heavier, because something has to actually be logged in and running: a real client on a real device or handset, keeping a session alive around the clock. A box that comfortably relays for a hundred people may only host a handful of live accounts.

And idle isn’t free. Even an account doing absolutely nothing still holds its connection open and sends a small heartbeat to stay online and receive messages. A stack of quiet accounts isn’t weightless, each one costs a socket and a little memory just to stay reachable. When you plan for many hosted accounts, you’re planning for that always-on baseline long before anyone sends a single message.

The genuinely scarce resource is the IP

Here’s the resource that’s actually scarce, and it isn’t bandwidth, processor, or memory. It’s the IP itself.

One clean address can only sit under so many accounts before the density starts to look like a farm rather than a person, and that pattern is exactly what gets an IP distrusted. Bandwidth is cheap and you can always buy more. A clean, trusted IP that many accounts can quietly live behind without drawing suspicion is the hard part, and it’s the real limit on how much you can safely pack onto one connection.

How to plan: measure, don’t guess

The reliable way to size a Telegram setup is to measure, not guess. Start with a modest box, put your real users or accounts on it, and watch it for a week under genuine use. Look at:

• The peak number of connections open at once.
• The peak throughput.
• How the processor and memory behave when everyone is active together.

Real numbers from your own traffic beat any rule of thumb, because your mix of light and heavy users is unique. And it’s the peak, not the gentle average, that decides whether the setup holds.

Then size for that peak with generous headroom on top. Run comfortably below the ceiling even at your busiest, so that half your capacity is still spare when everything is flat out. That sounds wasteful right up until the day something spikes, a big event, a flood of media, everyone piling onto calls at once, and the box that was already maxed simply falls over. Headroom isn’t waste, it’s the margin that keeps the proxy standing on the one day it actually matters.

Knowing when you’ve outgrown a box

Learn to recognize the signs before a server collapses:

• Latency creeping up when the server is busy.
• Calls that turn choppy or drop at peak times.
• Media that stalls partway through a download.
• Connections that reset when load is high.

None of those are random glitches. They’re a server telling you it’s running out of room, and the answer isn’t to keep cramming more onto the same address and hope.

Scaling a Telegram setup is horizontal, not vertical. More users doesn’t mean one giant pipe on one heroic server, it means more clean IPs and spreading your accounts across them so that no single address ever carries a suspicious density. You grow by adding clean connections and balancing load over them, not by stacking everyone behind one overworked IP.

A note on scope: this is about sizing an honest setup, a proxy or a set of hosted accounts, so that real people get a stable, reliable connection. It isn’t about seeing how many throwaway accounts you can cram behind a single address, which is precisely the dense, machine-like pattern that gets an IP flagged and everyone behind it punished together.

The part that keeps mattering

Measuring real load, sizing boxes to the peak, keeping headroom for the bad day, spreading accounts across clean IPs so none of them looks like a farm, and keeping every one of those connections stable and online, is steady, fiddly, ongoing work. It only gets harder the more accounts you keep alive.

That unglamorous provisioning is the part that decides whether your setup stays fast and trusted or slowly falls apart, and it’s exactly what managed hosting is built to carry. telegramvault.org runs managed Telegram hosting on dedicated Singapore hardware, real handsets on real carrier SIMs from SingTel, M1, StarHub, and Vivifi. Your accounts sit on clean, stable mobile IPs with real room to breathe, sized and provisioned properly and kept continuously online, instead of crammed onto one overloaded connection that falls over at the worst moment. Onboarding starts with a real conversation about your setup, not a checkout page, and the code TGYT gets you a discount when you start.

Get new guides and videos first — join the Telegram channel.