Giving your traffic a fixed entry address when partners demand one

A customer messaged me on a Monday to say my line had broken his reporting. His words. The line had done exactly one thing that week: it rotated, at the hour he had configured back in September and then forgotten about.

The scraping half of his job had been fine for two months. What fell over was a small nightly script pulling numbers out of a partner dashboard, and that partner only answers requests arriving from an address they have written into a rule on their own side. He had given them a mobile address. It held for a while. Then it did what a mobile address does.

I sell those lines. Real SIM cards in modems on a shelf in Singapore, one port per modem, and a rotation endpoint anybody can call for a fresh exit. This collision reaches me often enough that I can name it from the first sentence of a message.

The shape never changes. One workflow, two halves, and the halves want opposite things from an address.

Two halves pulling in opposite directions

The scraping half wants an address that moves. That is most of the reason to buy a carrier line at all. You want to read like a phone, walk away from an address that has picked up friction, and hold one steady only as long as a task needs it.

The registered half wants the exact reverse. Somebody at another company has typed your address into a firewall rule or bound it to an api key, and the moment it changes you are locked out until a human over there updates the entry. Some partners action that within the hour. Plenty take a week and want the request to come from a named person on your account.

So people pick a side, and both sides cost real money. One group tries to freeze the mobile address: switch off rotation, hold the port, hope. The other group abandons the carrier exit entirely, moves the whole workload onto a cloud box with a static address, and then wonders why the scraping half started collecting blocks.

Why the mobile line will never be your fixed address

People put weeks into the freezing idea, so it deserves a proper burial.

A mobile line sits behind carrier translation. The public address in front of you belongs to the carrier and is shared with ordinary subscribers. The part that matters here is who holds the pen, and the carrier does. They move address blocks around on their own schedule for their own reasons. A modem that loses its bearer and reattaches comes back on whatever it is handed. A maintenance window on their side rearranges things without telling me, never mind you.

So I will happily sell you a sticky port that holds one exit for as long as a session runs, and that is a genuinely useful thing to have. What nobody in this market can honestly sell you is a promise that one specific address will still be yours a fortnight from now, because none of us own it.

Hold an address for a job. Do not register it with a third party and walk away.

Decide by destination instead

Stop hunting for the one address that satisfies both halves, and split the traffic by where it is going.

The registered destinations all leave through one small machine whose address does not move: the partner apis, the client dashboards, the payment console, the supplier portal, anything that has your address sitting in a rule on somebody else’s system.

Everything else leaves through carrier lines. The scraping, the account work, the geo checks, anything that benefits from reading like a person in Singapore.

That is the entire design. It looks obvious written down, and almost nobody arrives at it on their own, because the instinct when an address causes a problem is to go shopping for a better address.

What belongs on the fixed box

The box is small and boring on purpose: a cheap virtual machine at a host who will give you a dedicated address, in whatever region keeps the partner comfortable, doing as little as possible.

What goes on it is the traffic that has to arrive from a known place. The nightly reporting pull. The webhook receiver. The calls to an accounting or payment api. Anything where a human at another company had to add you to a list before it would work at all.

What must never go on it is anything touching a target you scrape. The moment you run that work from the box, its address starts accumulating a history, and the address you cannot change is the worst possible place to accumulate history. It is written into five partner systems. Walking away from it is an option you do not have.

I keep that split hard on my own infrastructure. The machines that talk to suppliers and payment processors never touch a target, and the messy machines never appear in anybody’s allowlist.

Making static actually static

Static means different things at different hosts, so check rather than assume. An address attached to your instance is usually stable for the life of that instance and vanishes the day you destroy it. That is the trap. You rebuild a box on a Friday, come back with a new address, and every partner rule you were relying on now points at some stranger’s machine.

What you want is an address allocated to your account rather than to the instance, so it can be moved onto a replacement. Most hosts have that concept under some name or other. Most people never enable it until the first rebuild teaches them why.

Then write down every place the address is registered. One flat file, one line per partner, a date on each entry. Nobody thinks they need that registry until the address changes. When it does, the file is the difference between an afternoon and a fortnight.

Ask the partner two questions first

Before you rent anything, send one message.

The first question is what form they accept. Some systems take a single address. Some take a small range, which is far easier to live with because you can rebuild without asking anyone. A few will accept a hostname and resolve it themselves, and if that option exists it is the best on the menu, because the address becomes yours to change.

The second question is how long a change takes on their side, and who is allowed to request it. That number sets your whole recovery plan. A partner who updates in an hour means an accidental address change is an annoying morning. A partner who takes eight working days means a fortnight of missing data, and you should design accordingly.

People skip both questions and learn the answers during an outage.

Keep the split where you can read it

There are two places to express this split, and one of them is much easier to live with.

The easy version lives in the client. Your reporting script points at the fixed box, your scraper points at the mobile line, and the whole decision is a config value in a code review, where anybody can see which path a job takes.

The hard version lives in the network: one machine, a routing table or a set of firewall marks, traffic to certain destinations forced down one interface and everything else down another. It works, I have run it, and it is genuinely miserable to debug at three in the morning when some rule is matching a destination you never considered.

If you can express the split as configuration, do that, and keep the network as dumb as you can. The middle case is a tool with exactly one proxy setting that has to reach both kinds of destination. That is where a chain in front of it earns its place, and chains carry costs that deserve their own piece.

The drift that eats your carrier lines

The failure I see most arrives after the split is built properly. The fixed box works. It is reliable and easy, and because moving something onto it is one line of config, more things quietly get moved onto it. Six weeks later the scraping is running through it too, the carrier lines are sitting idle, and the customer is asking me why his block rate went up.

Everything ended up on the machine whose entire purpose was to be predictable, and predictable is exactly what a target rewards you for avoiding.

Your byte counters catch this before your block rate does. If a carrier line’s usage drifts downward month over month and the job did not get smaller, something has migrated without anybody deciding.

Telling an address change apart from an outage

An address change and a partner outage produce almost identical noise inside a job: a failed request with an unhelpful body. Before you open a ticket, make one request from the fixed box to something that echoes the address it saw, and compare against your file.

If those two disagree, the problem is yours, and you know precisely what to ask for. If they agree, the problem is theirs, and you can say so with something behind it.

Ten seconds. It has saved me from several embarrassing emails.

The one I got wrong

I ran my own supplier reporting through a mobile line for about four months, for no better reason than that the line was already there, already configured, and working. Then a rotation fired on schedule, the supplier api started refusing me, and I spent the first hour of that morning completely certain they had changed something.

They had not. I had built the exact fault I now tell customers to design around, in my own house, with everything I needed to know already in my head.

The repair was twenty dollars a month of the dullest machine I could rent, plus one afternoon moving three scripts onto it. I should have done that on day one. I did it after it cost me a morning, which is how most infrastructure decisions actually get made.

A carrier line is for traffic that benefits from moving. A static box is for traffic somebody else has written down. Decide by destination, keep a list of everyone holding your fixed address, and push back on the drift toward the easy path.

If you want carrier lines in Singapore for the half of the work that needs them, real SIMs on Singtel, M1 and StarHub with sticky ports you can hold for a whole task and rotation you control, everything is at Singapore Mobile Proxy.

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