Why uploads behave differently on a mobile line

Almost every report of a broken line that reaches me about failing uploads arrives with a speed test screenshot attached as proof that the connection is healthy.

The screenshot is usually accurate. It is also a statement about the wrong direction. The large figure on a speed test result describes how fast the line pulls data down, and anybody posting media through a proxy is doing the opposite thing.

On a fixed connection that distinction is academic for most work. On a real carrier line it is the difference between a job that runs and a job that fails every evening for a week while you change everything except the thing that is actually wrong.

Where the asymmetry comes from

A cell tower is a large device with mains power behind it, a carefully mounted antenna and a serious amplifier. Its job is to talk to hundreds of devices at once. The modem answering back has a small internal antenna, a power budget it protects aggressively, and a transmit strength measured in fractions of a watt.

Those two directions are unequal before any spectrum gets allocated.

Then the spectrum gets allocated, and it makes the gap wider. On the newer bands the carrier divides time between the tower transmitting and the devices in the cell transmitting, and the division is deliberately weighted towards the tower. Most of the frame is downlink. Everything sending in the other direction shares what is left. On the older paired bands, the uplink carrier is frequently the narrower of the two to begin with.

The practical shape of this is a road down the hill with many lanes and a road up the hill with few. Which is entirely reasonable engineering, because the overwhelming majority of what people do on a phone is receive.

Radio conditions widen the gap again. A modem on a weaker signal responds by switching to a slower and more redundant encoding for what it sends. That is correct behaviour and it keeps the connection alive. It also means the same file takes noticeably longer to leave.

Congestion arrives on the uplink first

The downlink has enough capacity to absorb a crowd getting larger. The uplink has much less of it, so a filling cell runs out of upward capacity long before it runs out of downward capacity.

This produces the single most confusing symptom in the whole subject: a line that tests perfectly at eleven in the morning and fails every upload after dinner. Nothing changed on the hardware. Nothing changed on the SIM. A few thousand more people joined the cell, each holding a device that wants to send something.

From the rack, the two directions behave visibly differently under load. Evening download counters sag. Evening upload counters fall off a cliff. Same weather, two very different amounts of damage.

The clue in how the failure fails

There is a diagnostic in the timing that most people walk straight past.

A block fails immediately. If a platform has decided something about your account or your address, the refusal arrives fast, because a refusal is cheap.

A timeout fails after a consistent interval. If you time ten failed uploads and they all die at roughly sixty seconds, or roughly ninety, you are looking at a clock somewhere in the path rather than a decision about you. Timing the failures costs nothing and rules out an entire class of wrong theory.

The reason so few people do it is that the error message never says so. The platform returns something generic, the app shows a retry button, or the upload simply stops. Nothing in that response mentions the uplink, so the operator watching the screen concludes the account is in trouble and starts changing addresses.

The platform’s clock was set on a fixed line

Whoever wrote the upload handler on the receiving platform picked a timeout that felt generous from where they were sitting, which was almost certainly a fixed connection. A minute for the whole transfer. Sometimes two. Sometimes a shorter idle timeout that fires when no bytes arrive for thirty seconds.

On fibre you would have to try hard to hit any of those.

On a mobile uplink during peak hours they are tight. A clip that sends in forty seconds at lunchtime can take four times that in the evening, and four times forty seconds is past the limit that felt generous to a developer on a desk connection.

You cannot change their clock. You can move your work to an hour where you fit inside it.

One shot uploads charge you twice

Most upload endpoints still treat a transfer as a single request. You post the whole file in one body. When that request dies at ninety percent, the server is not holding ninety percent of your file waiting for you to come back. The connection is gone, the partial body is discarded, and the next attempt begins at the first byte.

On a metered carrier line that arithmetic matters more than it does anywhere else.

The bytes you already sent left the modem. The carrier counted them. Our meter counted them. They appear on your usage regardless of whether the platform kept a single one. A file that fails twice and succeeds on the third attempt has cost three times its size in real carrier data and produced one post.

Automated retry logic turns that into a genuine hole in the floor. A person gives up after a few attempts. A script sees a failed upload, classifies it as temporary, and restarts from zero indefinitely, into a cell that will not improve for another two hours.

Rotation during a transfer

If a line changes its address on a schedule and a change lands mid transfer, the transfer is over. The connection carrying it was bound to the previous address.

Worse, a client clever enough to reopen and continue now has the second half of an upload arriving from a different address than the first half. The best outcome there is a restart. The realistic outcome on a logged in account is a challenge.

A fifteen minute rotation window feels like generous cover, and it is generous for browsing. For a large upload on a congested evening it is thin, because the transfer that took forty seconds yesterday may take six minutes tonight and the rotation schedule has no visibility into what you are doing.

Which work needs to hold one address is a larger subject with its own rules. The narrow version that matters here: a transfer is one unit of work and it has to finish on the address it started on.

Why the rest of the line looks broken too

A saturated uplink does more than slow the upload down.

Every acknowledgement your downloads need to send back has to queue behind the upload data in the same small slice of radio. While a large transfer is in flight, the whole line feels sick. Pages crawl. API calls time out. A health check that normally answers instantly takes eight seconds and gets recorded as a failure by your own monitoring.

Operators see that pattern and conclude the line has died, when one transfer has filled the only lane going up. If your monitoring runs on the same line as your upload work, expect it to lie to you during transfers.

Test the direction you use

Before committing any workflow that posts media through a line, push a real file of a realistic size through it and time that. The download figure tells you nothing useful about whether this job will run.

Run the test at the hour the job will actually run. A lunchtime measurement applied to an evening schedule is a fiction that will hold up right until the first live batch.

Record the result. Uplink varies enough by hour and by cell that a single sample is a snapshot rather than a baseline, and you want to know what normal looks like before something breaks.

What actually changes the outcome

Move the heavy work off peak. Upload traffic is the most time sensitive thing you can put on a mobile line, and a residential cell in the small hours behaves like a different network. Where the posting can be scheduled, this is the largest improvement available and it costs nothing.

Use a resumable endpoint where the platform has one. Modern upload APIs let you declare the size up front, send in chunks and resume from the chunk that failed. That converts a failure from a full restart into one repeated chunk, which changes the data arithmetic completely. Some platforms keep this inside their official client library while the simple form post sits in the public documentation, so it is worth checking before assuming the one shot version is all there is.

Hold one address for the length of the transfer. Use a sticky port and hold it for longer than the job took last time rather than exactly as long. Rotate between transfers if you need to rotate at all.

Run one upload at a time per line. A single radio does not go faster because three transfers asked at once. They share the same narrow lane, each takes roughly three times as long, and all three become far more likely to hit the platform’s clock.

Set your own client timeouts to match the network you are on. A thirty second timeout on a mobile uplink throws away transfers that were going to finish.

The ceiling nobody can raise

The uplink limit belongs to the carrier and to the cell the modem sits in. No provider selling a genuine mobile address can raise it, and a fixed upload figure quoted with a guarantee attached is a lab measurement from an empty tower at three in the morning.

What a line can honestly give you is an uplink that behaves the way a real phone behaves, on a SIM that has not been sold to twenty other people who are all pushing video through it at the same time. That last detail decides more upload outcomes than any specification. On a shared line, someone else’s transfer is taking your lane and you have no way to discover it.

If you want Singapore lines where you are the only traffic on the radio and the upward direction belongs to you alone, that is what I run at singaporemobileproxy.com.

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