How many simultaneous connections can one mobile line actually hold?

Every week someone asks us the same question in a different shape: “how many threads can I run on one line?” or “can I scrape with 50 parallel connections through this proxy?” There’s no single number we can hand back, and anyone who gives you one without knowing your carrier, your modem, and what you’re actually doing with it is guessing. What we can do is walk through what actually sets the ceiling, because once you understand the mechanism you can figure out the right number for your own setup instead of trusting a spec sheet that doesn’t exist.

What “concurrent connections” actually means here

When people say concurrent connections, they usually mean the number of TCP sockets open at the same time, all going out through the same mobile IP. Ten browser tabs each holding a session open, or a scraper firing 30 requests in parallel, or an automation stack running multiple account sessions side by side. Every one of those is a distinct flow that needs to be tracked and translated somewhere between your machine and the target server. That tracking is where the limits live.

There are three separate layers doing that tracking, and each one can be the bottleneck depending on your setup. Understanding which layer is actually constraining you matters more than any single “max connections” number.

Layer one: the carrier’s CGNAT

Singapore’s telcos, like SingTel, M1, and StarHub, don’t hand every SIM its own public IPv4 address anymore. IPv4 space is scarce, so they run carrier-grade NAT (CGNAT), which shares a smaller pool of public IPs across a large number of subscribers. Your phone or modem gets a private address on the carrier’s internal network, and CGNAT translates your outbound traffic to a shared public IP, tracking which port on that shared IP maps back to which subscriber and which internal flow.

That translation table has a size, and telcos limit how many simultaneous sessions any one subscriber can hold open in it. This isn’t published anywhere. Carriers treat it as an operational detail, not a spec, and it can differ across SingTel, M1, and StarHub, and even shift over time as they retune their NAT gateways for load. What we can say from running SIMs across all three networks is that the limit is real and you will hit it if you push hard enough. When you do, new connection attempts get reset or silently dropped rather than failing with a clear error, which is exactly why this trips people up. It looks like your proxy broke when it’s actually the carrier’s NAT table telling you no.

Layer two: your own modem or router

Before traffic ever reaches the carrier’s CGNAT, it passes through the NAT table on whatever device is holding the SIM: a USB modem, a router, or a phone in modem mode. That device is also keeping a session table in RAM, mapping your local connections to the single upstream interface. Cheap consumer routers and phones running as hotspots have small, unoptimized NAT tables and limited CPU for managing them. Push too many parallel flows and the device itself starts dropping or delaying sessions before the request ever leaves the building.

This is the layer people overlook. They assume any wall they hit is the carrier being strict, when it’s actually the $40 router struggling to track five hundred open sockets. If you’re running a serious concurrent load, the hardware doing the NAT translation on your end needs to be built for it, not a stock home router pressed into service.

Layer three: your proxy software’s own limits

If you’re running a proxy server on top of the modem (something like 3proxy or Squid, which is how most mobile proxy setups actually work), that software has its own configuration for max connections, worker processes, and file descriptor limits. These are limits you set and control directly, which is the good news: unlike the carrier’s CGNAT ceiling, you can see this one and tune it. The bad news is that a proxy server configured to accept more connections than the modem or the carrier can actually sustain doesn’t help you. It just queues you up for a reset further down the chain.

Why maxing out one line is the wrong instinct anyway

Even if you found the exact number where a given line starts dropping sessions, and pushed right up to it, that’s usually the wrong move for scraping or multi-account work. The target site on the other end doesn’t see your connection count. It sees one IP address, and thirty simultaneous sessions from one residential-looking mobile IP doesn’t look like a person, it looks like automation, regardless of whether the carrier’s NAT table technically allowed it.

This is the core reason mobile proxy work is built around having multiple physical lines rather than pushing hard on one. A single SIM behaves like a single real device on a real mobile network, because that’s what it is. If your use case needs real concurrency, real parallel scraping threads or real parallel account sessions, the answer is more SIMs each carrying a modest, human-plausible load, not one SIM carrying all of it. That’s the actual architecture behind a mobile proxy farm: it’s not one connection stretched thin, it’s many independent lines each doing a believable amount of work.

What a sane concurrency budget looks like per use case

For scraping, short-lived HTTP requests that open, fetch, and close quickly put much less pressure on any of the three layers than long-held connections, because the session table entries churn instead of accumulating. You can usually run a higher request rate than you’d expect as long as requests complete fast and don’t pile up.

For browser automation and multi-account work, the opposite is true. Each logged-in session tends to hold a persistent connection, websockets for live features, keep-alive HTTP for the app itself, sometimes background polling. A handful of these can occupy meaningfully more of the session table than dozens of quick scraper requests. If you’re running multiple accounts through the same line, expect each one to cost more “concurrency budget” than a single scrape request would.

For anything bursty, like checking out on a site or hitting an API window, the risk isn’t sustained load, it’s a sudden spike of new connections all at once, which is exactly the pattern CGNAT tables are tuned to notice and rate-limit.

How to actually find your ceiling

Because none of this is published, the only honest way to know your real number is to test it on the specific line you’re using, gradually. Ramp connections up in small steps and watch for connection resets or increased latency rather than assuming a number from a forum post or a vendor’s marketing page applies to your SIM, your carrier, and your modem. What holds on a SingTel line on a weekday afternoon isn’t guaranteed to hold on an M1 line at night, because the carriers manage their own NAT infrastructure independently and neither one tells you where the line is.

If you’re building anything that depends on predictable concurrency, treat that ceiling as a moving target you monitor, not a constant you configure once and forget.

If you want to talk through concurrency for a specific scraping or automation workload, or see how we structure multiple lines for real parallel throughput, come find us at Singapore Mobile Proxy.

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