Telegram Flood Restriction vs Shadowban vs Ban (2026)

the short definition

A telegram flood restriction is a temporary rate-limit enforced server-side when a Telegram client exceeds request thresholds, triggering a FLOOD_WAIT_X error that blocks further API calls for X seconds. A shadowban is a silent suppression state where your account keeps working from your side but becomes invisible or restricted to everyone else, with no error and no notification. A ban is full account termination, irreversible without a successful appeal, and immediately visible to anyone who tries to contact the number.

the longer explanation

The telegram flood restriction mechanism is documented inside the MTProto protocol’s error specification. When your client exceeds a server-defined request threshold for a given method, the server returns error code 420 with the description FLOOD_WAIT_X, where X is a count of seconds. Your client must wait exactly that long before retrying. The threshold is not published anywhere. It shifts based on account age, trust score, the specific API method being called, and the IP reputation of the session. An account with six months of clean history on a mobile carrier IP can send far more messages before hitting a flood limit than a fresh number registered yesterday from a datacenter.

Before around 2019, flood errors were mostly a developer nuisance. You’d hit them building bots, iterating through contact lists, or auto-posting to channels, slow your loop, and move on. Annoying but trivial. After Telegram crossed 300 million active users and became the primary organizing layer in Belarus, Hong Kong, Iran, and Myanmar during those years’ respective unrest periods, the platform’s tolerance for bot-shaped behavior tightened considerably. By 2022, Telegram reported 700 million monthly active users, and by that point flood thresholds had gotten significantly more aggressive for new accounts. Flood detection stopped being a pure rate-limiting tool. It became a first-layer signal feeding into broader trust scoring. Enough flood events on a single number, especially from a suspect IP, and the account’s tolerance across other behavioral checks narrowed accordingly.

Shadowban is the messier state to explain because Telegram does not use that word in any official documentation. What they actually implement is a “spam block,” visible in the API as an account-level restrictions field. When this engages, your messages in large public groups and channels may appear only to you, rendered as delivered in your own client while being invisible to everyone else. Your username becomes unsearchable. Invites to channels drop silently. Your ability to tag or be tagged disappears. The asymmetry is the defining feature: you keep using the app, you think you’re operating, but you’re broadcasting into a void. No error. No notification. The only way to verify is to check from a completely separate account, on a separate device, with no session relationship to the flagged number.

Full bans are different in kind, not just degree. The account is deactivated. Anyone messaging the number sees “this account has been banned for spam and other violations.” The phone number itself may be flagged in Telegram’s internal records, making re-registration harder. Appeals go to Telegram’s account recovery portal, and success rates are low but not zero. Accounts caught in automated sweeps rather than individual reviews have a somewhat better chance. Accounts with long clean IP history, especially mobile carrier IP history, do better in those reviews than accounts that arrive with a trail of datacenter session associations. Even at termination, the IP signal matters.

why it matters for telegram operators

Confusing these three states costs you weeks, sometimes months, and occasionally the account itself. I’ve watched it happen repeatedly: a customer contacts us convinced their account was banned because messages stopped getting replies. We check the session logs and find a 24-hour telegram flood restriction triggered by a script that sent the same greeting message to 300 new contacts over 20 minutes. No ban. No shadowban. A bot-shaped burst the server noticed and penalized with a temporary lockout. The correct response is to wait exactly the stated interval and resume at a lower rate. The wrong response, which happens all the time, is to panic-appeal to Telegram support. That surfaces the account to human reviewers who might not have looked at it otherwise.

The stakes get higher when you’re operating across jurisdictions where Telegram is critical infrastructure. In Iran, Russia, Pakistan, and much of Central Asia, Telegram is not optional. Losing an account there means losing access to customers, suppliers, community members, or information sources with no backup channel. Recovery from a flood restriction is mechanical: wait, slow down, move on. Recovery from a shadowban requires identifying the behavioral pattern that triggered it, correcting it, and waiting out the restriction period while operating from an IP that carries enough trust signal to demonstrate good-faith activity. Recovery from a full ban is an appeal process with uncertain outcomes. Getting the diagnosis wrong, and responding to one state as if it were another, compounds the original problem.

The IP address your session uses is a hidden variable in all three states. Telegram’s server-side trust scoring weights heavily on ASN type and geographic origin. A session from a Singapore mobile carrier IP (SingTel AS9506, M1 AS38753, StarHub AS4657) carries a fundamentally different prior than one from a Frankfurt datacenter. Mobile carrier IPs signal human presence, physical SIM ownership, and carrier-grade NAT pools shared by real subscribers. Datacenter IPs signal automation by default. This affects how quickly a telegram flood restriction triggers, how long the cooldown lasts, and whether marginal spam-like behavior tips into a shadowban versus just a temporary slowdown. Dedicated vs shared mobile IPs explains in detail why the ASN type distinction shapes everything downstream.

common misconceptions

The most common one is treating a flood error as the opening move of a ban. It is not. A telegram flood restriction is a protocol-level rate signal, explicitly documented, explicitly temporary. The server tells you exactly how long to wait. When you get FLOOD_WAIT_86400, that is 24 hours of lockout, not a termination notice. Accounts that file support requests during this window, or that start rotating IPs in a panic, often create problems that did not exist before. Wait exactly the stated interval. Resume with a reduced request rate. The flood counter does not permanently record against your account the way a ban review does. A single flood event on an otherwise clean account leaves no lasting mark.

Another widespread mistake is assuming that if messages appear as sent in your own client, they were received. This is exactly wrong for the shadowban state. Telegram’s spam detection renders your messages invisible to group members while your own client shows them as delivered. The checkmarks appear. The timestamp appears. Nothing looks wrong from where you’re sitting. I’ve seen operators spend two weeks adjusting their messaging approach, running A/B tests on content, changing posting times, all while being completely invisible to their audience. The only reliable verification is an out-of-band check: log into a completely separate Telegram account, one with no historical relationship to the flagged number, join the same group or channel, and look for the messages. If they’re not there, you have your answer.

People also assume bans are permanent and shadowbans are temporary. The reality tends to run the other way on both counts. Full account bans do get reversed through the recovery portal, particularly when the account was swept up in an automated enforcement action rather than individually reviewed. EFF’s research on automated content moderation documents how automated systems at scale produce both over-enforcement and under-enforcement, and Telegram is no exception. A well-constructed appeal with a clean IP history to point to has a real chance. Shadowbans, by contrast, can persist for weeks or permanently. If the behavior that triggered the restriction continues, or if the account keeps operating from a low-trust IP while restricted, the shadowban can quietly harden into a state that looks increasingly like a permanent soft ban. It doesn’t announce its own escalation.

Finally, many operators believe that switching to a VPN resolves any of this. It usually makes it worse. A commercial VPN routes your Telegram session through a datacenter IP that Telegram classifies by ASN in milliseconds. NordVPN, ExpressVPN, and their peers run exit infrastructure in datacenter ASNs because rack space in a cloud or colo facility is how you build a VPN business at scale. When you move a session already carrying flood history or a soft restriction onto a datacenter IP, you combine two negative signals: prior behavioral flags and a low-trust IP type. Higher-trust IPs give you more tolerance headroom. Lower-trust IPs shrink it. Why Singapore mobile IPs covers the trust hierarchy in detail if you want to understand the full mechanics.

a quick worked example

Say you’re managing a Telegram distribution channel from a cloud server in Amsterdam. Your script sends 200 messages over 12 minutes. Responses stop coming in. You check your own client and everything looks normal. Before deciding whether you’re dealing with a flood restriction, a shadowban, or something else entirely, start with the IP.

# Identify the ASN and IP type your active Telegram session is using
MYIP=$(curl -s ifconfig.me)

curl -s "https://ipinfo.io/${MYIP}/json" \
  | python3 -c "
import sys, json
d = json.load(sys.stdin)
org = d.get('org', 'unknown')
print(f'IP:      {d.get(\"ip\")}')
print(f'Org/ASN: {org}')
print(f'Country: {d.get(\"country\")}')
print()
cloud_keywords = ['amazon', 'digitalocean', 'linode', 'vultr', 'hetzner', 'ovh',
                  'google', 'microsoft', 'cloudflare', 'choopa', 'datacamp']
if any(k in org.lower() for k in cloud_keywords):
    print('RESULT: datacenter ASN. Telegram flood thresholds are tighter here.')
    print('        Flood events on this IP type escalate faster toward soft restrictions.')
else:
    print('RESULT: ISP or mobile ASN. IP type is favorable for Telegram session trust.')
"

If the output shows a cloud provider ASN, you have your first structural answer. The scenario you’re in is almost certainly a telegram flood restriction caused by the burst rate, made worse by the IP type carrying reduced tolerance headroom. The fix is not an appeal and not an IP rotation. Move the session to a genuine mobile carrier IP and drop message rate to a pace a human could plausibly sustain. If the output shows a mobile carrier ASN and messages are still not appearing to others, that pattern points toward the shadowban state, and you need the out-of-band account check described in the section above.

how telegramvault relates

Telegram flood restriction events are among the most common situations we see in the first weeks of a new customer session. When someone brings a number to us that has been running on a datacenter VPN or shared residential proxy, it often arrives with prior flood history and, occasionally, a soft restriction already in place. Placing that number on a dedicated SingTel or M1 SIM in our Singapore farm, with a static carrier IP carrying no shared abuse history, does not instantly reset the account’s internal trust score. Trust accumulates over time. What we consistently observe is that flood thresholds relax over days and weeks when the subsequent behavioral pattern is human-paced and the IP is carrier-grade Singapore mobile. Shadowban states resolve faster from a clean mobile IP than from a datacenter one, because the recovery period involves Telegram re-evaluating the session’s signal quality, and mobile carrier signals are categorically more favorable. The BYO number Telegram hosting model matters here specifically because we never touch the OTP or session credentials. The account’s identity continuity carries through the transition, and that continuity is part of what allows the trust score to rebuild rather than reset.

further reading

Understanding flood restrictions requires understanding why Telegram enforces at all. The flood detection system feeds into Telegram’s broader risk scoring, and enough flood events from the same number can contribute to the escalation path toward harder restrictions. Why Telegram bans accounts covers the documented and inferred criteria Telegram uses when deciding whether to restrict or terminate.

The IP trust question underlies everything here. Whether your session lives on a dedicated mobile IP or a shared pool changes your flood threshold, your shadowban recovery timeline, and your chances in a ban appeal. Dedicated vs shared mobile IPs maps out the practical tradeoff. The distinction is not just technical. It maps directly onto how Telegram’s infrastructure categorizes the session origin and how much margin it grants on borderline behaviors.

For a network-level view of how Telegram traffic and enforcement behave across different countries and carrier environments, OONI’s measurement reports are the most rigorous public source available. Their methodology involves instrumented clients in-country logging actual protocol responses, so country-level interference patterns that look from inside the app like a shadowban or an unreachable server often show up clearly in their datasets.

If you want to understand the infrastructure layer under telegramvault, Cloudf.one cloud phones and Singapore Mobile Proxy plans show the stack this product runs on. The waitlist for the telegramvault concierge pilot is live at telegramvault.org.

final word

Three different states, three different causes, three different fixes. A telegram flood restriction is a temporary rate signal with a countdown attached, not a verdict. A shadowban is a silence you can only detect from outside your own session, often invisible until you know to look. A ban is the actual verdict, and even then the recovery portal is worth trying if the account has clean IP history to point to. Know which state you are in before you act, because the wrong response to each one makes the next state more likely.