Using Singapore mobile proxies with Telethon in 2026

Telegram’s fraud detection has grown substantially more aggressive since late 2024. If you run Telethon automation at any meaningful scale, you have seen the pattern: a script that works fine from your laptop starts accumulating FloodWaitError exceptions, silent message delivery failures, or outright account suspensions once it moves to a cloud server. The trigger is almost never your code. It is your IP. Datacenter ranges, rented VPN endpoints, and even some residential pools have built up enough automation history on Telegram’s side that new sessions from them get throttled before your first message sends. Adding a real mobile carrier IP from a well-regarded market like Singapore changes that signal entirely, and it is the fix a lot of operators reach for once they have ruled out everything else.

why Telethon hits walls without residential mobile IPs

Telegram’s core API infrastructure does not publish its rate-limiting or anti-abuse criteria, but operators who run Telethon at scale have mapped the failure modes well enough to work backwards. The three most common are flood waits on account creation or message sending, AuthKeyUnregisteredError or session invalidations triggered shortly after login, and soft throttling where calls succeed but messages are silently undelivered to recipients.

All three correlate heavily with IP reputation. Datacenter ASNs (AWS, GCP, Hetzner, OVH) carry years of bot-traffic history. A fresh session authenticated from an AS16509 range is not starting with a clean slate; it is inheriting the trust deficit of every spammer who used that CIDR before you. Telegram’s systems weight new session behavior heavily in the first few hours, so that inherited deficit hits precisely when your account is most fragile.

VPN IPs are in some ways worse. Consumer VPN providers rotate the same exit IPs among thousands of users, which means the IP has authenticated dozens of Telegram accounts per day across dozens of devices. Even if your own behavior is clean, the session metadata (IP, connection pattern, device fingerprint from TDLib headers) looks exactly like a shared VPN exit, which Telegram’s anomaly detection flags readily. Operators who have switched to per-account dedicated IPs report dramatically lower ban rates, a pattern consistent with how Telegram describes its anti-abuse approach in developer documentation. If you want background on how residential mobile IPs differ structurally from these alternatives, what is a mobile proxy covers the carrier-level distinctions in detail.

The specific Telethon workflows most exposed to this problem are account warmup scripts (sending initial messages to build account age), group scraping and member-export tasks, and broadcast automation where one session sends to a large list over a short window. Each of these triggers usage patterns that look like abuse from a datacenter IP even when they are entirely legitimate from an operational standpoint.

setting up SMP credentials in Telethon

Singapore Mobile Proxy delivers credentials in the standard ip:port:username:password format. You will get a host, a port, and a pair of credentials per endpoint from your dashboard. Telethon accepts proxies through its proxy parameter on the TelegramClient constructor, and the cleanest approach is SOCKS5 since it tunnels the full TCP connection including DNS, which matters for avoiding IP leaks through DNS resolution. If you want to understand the tradeoffs between the two protocols before committing, HTTP vs SOCKS5 mobile proxies breaks down when each is preferable.

Install pysocks if you have not already (pip install pysocks), then wire the proxy in at client construction time:

import socks
import asyncio
from telethon import TelegramClient
from telethon.sessions import StringSession

# SMP credential format: ip:port:username:password
# Fill these from your SMP dashboard endpoint
PROXY_HOST = "203.118.x.x"   # your assigned SMP IP
PROXY_PORT = 12345            # your assigned port
PROXY_USER = "smp_user"       # your SMP username
PROXY_PASS = "smp_pass"       # your SMP password

API_ID   = 12345678
API_HASH = "your_api_hash_here"

# Pass rdns=True so DNS resolves through the proxy, not locally
client = TelegramClient(
    StringSession(),
    API_ID,
    API_HASH,
    proxy=(socks.SOCKS5, PROXY_HOST, PROXY_PORT, True, PROXY_USER, PROXY_PASS),
)

async def main():
    await client.start(phone="+6591234567")
    me = await client.get_me()
    print(f"authenticated as: {me.first_name} (@{me.username})")
    await client.disconnect()

asyncio.run(main())

Two things to call out here. First, the rdns=True flag (the fourth positional argument in the tuple) routes DNS lookups through the SOCKS5 tunnel rather than resolving them locally. Without it, your server’s DNS resolver handles lookups even though TCP goes through the proxy, which can leak your actual infrastructure location in some environments. Second, if you are managing multiple Telethon sessions concurrently, each session should get its own client instance constructed with its own proxy credentials. Sharing a single proxy connection across multiple sessions collapses the per-session isolation that makes mobile IPs valuable in the first place.

rotating IPs per request or per session

SMP provides two endpoint types: sticky sessions that hold the same IP for a configured duration, and rotating endpoints that assign a fresh IP on each new connection. Choosing between them is a matter of matching the endpoint type to what Telegram’s session model actually tracks.

Telegram’s session authentication binds a session_id and auth_key to the connecting IP over time. It is tolerant of gradual IP drift (the same way a mobile phone moves between towers) but suspicious of instantaneous jumps between geographically distant or ASN-disparate IPs within a single session. Rotating endpoints are the right fit when you are creating new sessions, running reconnaissance tasks that do not require authentication (checking invite link validity, for example), or managing a pool where each session gets a fresh IP assignment at startup and then stays on it. Sticky sessions belong on account warmup, sustained conversations, and any workflow where you are resuming a session across multiple script runs.

import socks
import asyncio
from telethon import TelegramClient
from telethon.sessions import StringSession

API_ID   = 12345678
API_HASH = "your_api_hash_here"

def make_client(session_str: str, host: str, port: int, user: str, pwd: str) -> TelegramClient:
    """Construct a Telethon client bound to a specific SMP endpoint."""
    return TelegramClient(
        StringSession(session_str),
        API_ID,
        API_HASH,
        proxy=(socks.SOCKS5, host, port, True, user, pwd),
    )

async def run_with_sticky(session_str: str, sticky_creds: dict):
    """Use for warmup or sustained tasks -- same IP throughout."""
    client = make_client(session_str, **sticky_creds)
    async with client:
        # your task here
        await client.send_message("me", "ping")

async def run_with_rotating(sticky_session_str: str, rotating_creds: dict):
    """Use for new-session creation or stateless lookups."""
    client = make_client("", **rotating_creds)  # fresh StringSession
    async with client:
        await client.start(phone="+6591234567")
        new_session = client.session.save()
    return new_session  # store this and use sticky endpoint going forward

SMP exposes its rotation mechanism through distinct endpoint addresses in your dashboard rather than through a URL parameter you append. The sticky and rotating endpoints are separate hosts or port assignments, so you swap between them by swapping the PROXY_HOST and PROXY_PORT values in your credentials, not by calling a rotation API. This is simpler to manage in a multi-account pool: each account’s credential dict holds an endpoint type, and your task router selects based on the task type.

three real workflows where this combo wins

account warmup for new SG numbers

Registering new Telegram accounts on Singapore numbers and warming them up to the point where they can send messages without hitting PeerFloodError requires the account to accumulate normal-looking activity over several days. If that activity originates from a cloud server IP during warmup, Telegram’s systems note the inconsistency between the SG phone number’s expected carrier and the connection’s IP geolocation and ASN. Warming up a +65 number through a SingTel or StarHub mobile IP eliminates that discrepancy entirely. The session looks like a normal SG resident using their phone on mobile data, because that is effectively what the IP represents. Operators running contact outreach tools in Singapore report significantly shorter warmup windows when the proxy IP matches the number’s carrier country.

group member scraping without flood waits

client.get_participants() is one of the most rate-limited calls in the Telegram flood control system. The limits are per-session and per-IP, which means distributing a scraping job across multiple sessions and multiple IPs multiplies effective throughput. Mobile IPs have a structural advantage here: they are less likely to be in a pre-throttled state when you start a new session on them. Using a pool of SMP endpoints, one IP per scraping session, produces substantially cleaner results than the same setup on datacenter IPs where half the IPs may already carry a throttle state from previous tenants.

sending to SG-resident contact lists

If your Telethon automation contacts users who are primarily on SG mobile numbers, the message delivery path passes through Telegram infrastructure that scores sender legitimacy partly based on sender-receiver geographic coherence. A sender authenticating from a SingTel IP and messaging recipients on SG numbers presents a consistent geographic pattern. The same message from a Frankfurt datacenter IP to a list of SG numbers is a weaker signal and more likely to trigger secondary review. For legitimate outreach tools targeting SG audiences, including community management bots and notification systems for SG-based services, the IP match reinforces legitimacy rather than just avoiding detection.

common pitfalls

not setting rdns=True: Telethon’s SOCKS5 implementation will use local DNS by default. Your server’s resolver leaks your infrastructure location in certain environments, and some Telegram endpoints will see your real server country in connection metadata even though the TCP payload routes through SG.
sharing one proxy connection across multiple TelegramClient instances: each client should bind to its own proxy. Multiplexing sessions through a single proxy collapses the per-IP session isolation and causes all clients to inherit each other’s rate-limit state.
using rotating endpoints for session resumption: if you save a session string authenticated on a rotating IP and then resume it after the IP has rotated, Telegram sees an abrupt IP change on an existing auth_key. This triggers re-verification or session invalidation depending on the account’s history. Save the session string and switch to a sticky endpoint before you start using the account.
ignoring FloodWaitError duration: Telethon raises FloodWaitError with a seconds attribute. Operators often catch the exception and retry with a fixed sleep, missing cases where Telegram issues a 12-hour or 24-hour wait. Read the actual wait time and respect it.
proxy timeouts set too low: mobile connections have higher latency variance than datacenter connections. If your TelegramClient is initialized with tight connection timeout settings, you will see spurious disconnects that look like proxy failures but are actually timeout races. Set connection_retries and timeout generously for mobile endpoints.
testing authentication on the rotating endpoint and then deploying on a different sticky endpoint: the IP that completed the SMS or auth flow is recorded by Telegram. Starting subsequent requests from a materially different IP immediately after auth increases verification friction. Do your initial auth on the endpoint you intend to stay on.

when Singapore IPs specifically matter

A generic residential proxy pool from a US or European provider solves the datacenter IP problem but introduces a different mismatch for operators working in Southeast Asia. Telegram usage in Singapore, Malaysia, Indonesia, and other SEA markets is concentrated on mobile data connections from regional carriers. A Telegram session authenticating from a US residential IP to interact with SG-resident groups or channels presents an unusual geographic pattern even if the IP itself is “clean.”

Real SG carrier IPs (SingTel, StarHub, M1, Vivifi) appear in Telegram’s IP-to-carrier mapping as exactly what they are: mobile data from the SG market. For workflows that target SG-specific public groups, interact with SG business accounts, or operate in the context of SG-facing services, this geographic and carrier-level authenticity is not a minor detail. It is the difference between a session that looks native and one that looks like a foreign proxy user. Operators building tools for SG fintech platforms, property portals, or community management in the SG market have found that the carrier match reduces friction across the board, not just with Telegram’s own anti-abuse systems but with downstream services that the bot might interact with. For broader context on why carrier-level authenticity matters in this region, cloudf.one Singapore cloud Android phones covers the carrier-level details well if your stack also involves Android-based automation alongside Telethon.

The SEA angle also matters for latency. SMP endpoints are physically located in Singapore, which means the round-trip to Telegram’s Singapore-region infrastructure is minimal. Latency-sensitive Telethon workflows (real-time message monitoring, rapid-response bots) perform measurably better through a geographically local proxy than through a US or EU residential pool with 200ms+ round trips.

getting started

If you are ready to wire up your first Telethon client through a SG mobile IP, credential setup is straightforward from the Singapore Mobile Proxy plans. Pick the plan that matches your session volume, copy the endpoint credentials from the dashboard in ip:port:username:password format, and drop them into the constructor pattern shown above. If you are building a larger pipeline where Telethon is one of several automation layers alongside cloud Android devices, the tooling at Data Research Tools may also be relevant to your stack. For operators who want to understand the responsible use boundaries before deploying at scale, ethical mobile proxy use is worth reading before you go to production.