What happens when the SIM behind your proxy runs out of data
The port answered. The tunnel was up. A ping through it came back in forty milliseconds, and the IP check page loaded showing the right carrier and the right city.
Every actual request timed out.
The customer was convinced he’d been blocked, and he spent most of a day rotating things and changing headers to get around a block that didn’t exist. The SIM behind that line had run out of data at around two in the morning.
Why the line still looks alive
This is the part that makes the failure so confusing, so it’s worth being precise about it.
The connection between your machine and the proxy has nothing to do with the carrier’s opinion of your data balance. That tunnel terminates on our hardware, and our hardware sits on a wired connection that’s perfectly happy.
The modem also stays attached. It has a live data session with the network, it holds an address, and from every angle you can check, it looks exactly like a working line.
What’s changed is what the carrier does with packets once they leave the modem. That’s a decision made deep inside their core, and it’s not something either side of the connection can observe directly. So everything you’d normally check says healthy, because everything you’d normally check is on the wrong side of the thing that broke.
Three different versions of running out
They behave completely differently, and telling them apart saves you the day the customer above lost.
The first is a hard stop with a redirect. The data session stays up, but everything you send gets pulled aside into the carrier’s top-up portal. A plain HTTP request returns their page instead of the site you asked for, with a normal-looking 200 status, and any code that only checks the status code carries on happily processing a page about buying more data.
The second is a throttle. The plan continues, just at a speed that makes it useless. The connection establishes, the first byte arrives at a normal time, and then throughput collapses to something in the low hundreds of kilobits.
The third is deprioritisation, which is the subtle one. You’re past your allowance, so the tower serves you last whenever it’s busy. At three in the morning the line is fine. At eight in the evening it’s unusable. Nothing has failed, and nothing will show up in any test you run at the wrong hour.
How each one presents
The redirect version has one enormous tell, and it’s worth knowing because it identifies the problem in about five seconds.
Plain HTTP gets you the portal page. HTTPS to the same host either fails outright or produces a certificate that doesn’t match what you asked for, because the carrier can’t transparently intercept a TLS connection without producing a certificate error. So a line where HTTP returns pages and HTTPS fails everywhere is a line in a captive state, and that combination means nothing else.
The throttle version shows up as a split between latency and throughput. Time to first byte looks normal, so your monitoring says fine, and anything with a body larger than a few kilobytes takes minutes. Downloads that never finish, uploads that stall at the same percentage, and a browser session that feels like dial-up.
The deprioritised version only shows up as a pattern over time. If you plot anything by hour and see a clean daily shape, you’re looking at congestion behaviour rather than a fault, and the fix is a plan question rather than a hardware one.
Why your monitoring said everything was fine
Three reasons, and all of them are worth fixing in your own probes.
The first is that a lot of health checks ping the proxy rather than going through it. That tests our box and tells you nothing about the carrier path.
The second is that many checks fetch a tiny page. A few hundred bytes get through a throttled line perfectly well, so the check passes on a line that can’t carry real work.
The third is the nastiest. Some carriers zero-rate their own properties, meaning their portal and their app stay reachable when everything else is cut off. A probe that happens to hit something the carrier doesn’t charge for will succeed on a line with no data left at all.
The balance number is not the ground truth
I want to be blunt about this because it’s cost me real money.
The balance a carrier reports, whether through a portal, an app, or a code you dial from the modem, is frequently wrong or stale. It lags actual usage, it sometimes reports zero on a line that’s still passing traffic normally, and it sometimes reports a healthy figure on a line that’s been cut off for hours.
Treat it as a hint. The only reliable way to know whether a line can carry work is to make it carry some work.
In practice that means a probe that pulls a known quantity of data from a neutral host, through the line, and times it. A couple of megabytes is enough. You get three useful numbers from one request: whether it completed, how long it took, and whether the bytes you received match the bytes you asked for.
That single check catches all three failure modes. The redirect fails the content match. The throttle fails the timing. And running it at a couple of different hours catches the deprioritisation pattern the other two would miss.
What happens on a pooled plan
If several lines sit on one shared allowance, which is a common way to buy them, the failure changes shape and gets harder to attribute.
One heavy job on one line drains the pool, and then every line on that account degrades at the same moment. From the outside that looks like an outage, because six things broke simultaneously and infrastructure failures are the usual reason for that.
The tell is the same one that shows up whenever a connection breaks for reasons that aren’t hardware: independent SIMs on independent attachments don’t fail together. When they do, the shared thing is the cause, and on a mobile fleet the shared thing is usually either the account’s allowance or the upstream connection, and those two are easy to separate.
It’s also the argument for per-port accounting. Without a number for each line, you know the pool emptied and you have no idea which line emptied it, and that conversation goes nowhere useful.
Telling a data cap apart from an actual block
If you’re a customer and you don’t administer the line, here’s the order I’d work through.
First, does plain HTTP return something unexpected while HTTPS fails. If so, stop, it’s the data cap, and no amount of rotation will help.
Second, is the failure specific to one destination or universal. A block is nearly always about one platform. A data cap takes out everything at once, including sites that have never heard of you.
Third, is it slow rather than refused. Blocks refuse. Caps and throttles are slow, or silent, or return the wrong content.
Fourth, what does the same request look like from an ordinary connection at the same moment. That separates a problem on the target’s side from a problem on the path.
Then talk to whoever runs the line, because from your seat the two situations look identical, and from ours they’re trivially distinguishable.
What a top-up actually buys you
There’s a detail here that catches people running their own lines, and I learned it the annoying way.
On most prepaid arrangements, adding money to the account and adding data to the plan are separate events. A top-up puts credit on the line. It doesn’t automatically restore your data allowance, and on some plans nothing happens until a renewal cycle comes round or somebody explicitly buys the bundle again.
So a line can sit there with a healthy balance and no usable data, and the dashboard showing money in the account tells you the payment went through and nothing else.
The operational version of this is to check the thing that matters, which is whether traffic flows, rather than the thing that’s easy to check, which is whether the payment cleared.
What happens if the cap hits mid-job
If the cap lands while something is running, the behaviour depends on which of the three you hit.
On a hard stop, existing connections die and new ones get the portal, so a long download stops partway and a scraper starts collecting the same page repeatedly. That repeated identical page is a good thing to alert on, incidentally, because it has almost no other cause.
On a throttle, everything continues and slows to a crawl, so a job that was going to take an hour is now going to take a week, and nothing in it will error.
Either way, the job carries on believing it’s working, which is why failing closed matters more than failing loudly. A scraper that stops when the path looks wrong loses you an hour. One that carries on writing rubbish into your dataset loses you the dataset.
Alerting on this before it happens
The instinct is to alert when the remaining allowance drops below some figure, and that’s the weaker of the two things you can do.
The better signal is the rate. A line that normally burns two gigabytes a day and is suddenly burning twelve is going to run out in a few hours, and you want to know that now rather than at the threshold. A rate alarm gives you most of a day of warning. A threshold alarm gives you minutes.
The rate is also the one that catches the other problem, which is a job that’s gone wrong and is downloading the same thing repeatedly. That shows up as consumption long before it shows up as a wrong result in your data.
And set a headroom figure you’re honest about. A line running at ninety-five percent of its allowance every cycle has no room for a busy week, and the cost of the next tier up is almost always smaller than the cost of a day of everything being mysteriously slow.
What we do about it
We probe through the lines rather than at them, on a schedule, with real byte counts. A line that returns the wrong content or the wrong throughput gets flagged before a customer meets it.
We also don’t treat a carrier-reported balance as authoritative, for exactly the reasons above, and we top lines up against actual measured usage rather than against a number a portal showed us.
When a line does hit a cap, the useful thing is to say so plainly rather than letting somebody spend a day chasing a block that was never there. The two failures need completely different responses, and a provider who can’t tell you which one you’re in isn’t much use to you.
The honest limit
There’s no clever configuration that makes a line carry data it’s run out of. This is a plan and a top-up problem, and it always will be.
What’s fixable is the diagnosis time. The difference between finding out in thirty seconds and finding out after a day of rotating user agents is entirely down to whether your checks go through the line, carry enough bytes to matter, and verify what came back rather than just that something did.
Build the probe that pulls two megabytes and compares the content. It’s twenty minutes of work, and it’ll save you that day at least twice.
If you want Singapore lines where somebody is actually probing the path with real byte counts instead of reading a balance page and hoping, that’s what we run. Find out more at Singapore Mobile Proxy.
Get new guides and videos first — join the Telegram channel.