What to do before you cancel a proxy line

The request I get most often after a cancellation is for the address back. Not a refund, not an argument about the bill. The specific IP the line used to hand out, because something the customer forgot about is still expecting it.

Twice a month, roughly. The answer has never once been yes.

I run the farm the lines come from, so cancellations arrive in my inbox and so does everything that turns up two weeks later. This is a piece written against my own invoice, which is the reason it is worth reading. A provider who tells you nothing about cancelling is not protecting you from a decision. He is hoping you make it badly enough to blame yourself.

Nobody is holding that address for you

A line here is a SIM card in a modem on a shelf. Stop paying and that card does not sit idle in case you change your mind. It goes back into stock, gets a fresh port name, and goes out to whoever asks for that carrier next.

There is no reservation attached to your name. Paying was the reservation.

Even if the modem did happen to sit unused for a month, the address behind it belongs to the carrier and gets reissued on every reattach. I have written elsewhere that the lifetime of a mobile IP is the network’s decision rather than the seller’s. That is mildly annoying while you hold the line and expensive the week after you let it go.

So treat the cancellation as a door that only swings one way. If any part of your plan involves getting that exact address back later, there is no plan.

An allowlist entry outlives the line it was written for

This is the failure that does actual damage, and the one people least expect.

If you authenticate to anything by IP, you have registered that line’s exit address somewhere as trusted. A database that only accepts known sources. An internal admin panel. A partner API that asked for a fixed address during onboarding and never brought it up again. The appeal is that there is no password sitting in a config file. The address is the credential.

Cancel the line and the credential is no longer yours. It goes to the next customer, who has no idea what he has been handed.

Two things break out of that, on different timescales. Your own tooling stops connecting, which you find within a day because something visibly fails. The rules you left behind elsewhere keep working, pointed at somebody else, and you never find those at all.

I have seen an entry survive four months past the line it referred to. It lived on a client’s firewall, added by somebody who had since left, and neither side kept a list.

While the line is alive, removing an entry takes ninety seconds. After it is gone, it is archaeology.

The accounts notice the day, not the move

Every platform you sign into keeps a running history of the account: what it did, on what device, arriving from where. An account that has only ever been seen from one Singapore carrier address has a stable line in that history, and stability was most of what you were renting.

The day the line dies, the next login arrives from wherever you go next. A home connection, an office, a cheap VPS with a datacenter range on it.

On its own that is survivable. People move house and change providers and platforms see it constantly.

Volume is what turns it into a problem. Cancel six lines at the end of a billing month and forty accounts can land on one home connection the same evening, from an address that has never seen any of them before. That does not read as somebody moving house. It reads as forty things that were deliberately kept apart, suddenly not being kept apart.

The symptom is usually friction rather than a ban. More verification than you used to get. A phone check on an account that never asked for one. A listing held for review. It arrives slowly enough that most people never connect it to the cancellation at all.

Make the list before you touch the button

Here is the order. The first step decides how the other two go.

Write down everything that depends on that line.

Most people cannot, and I think that is the real reason cancellations go badly. The cancelling is trivial. The inventory is the hard part, and nobody does it while the line is still working because there is no deadline forcing them to.

Start with the machines, because the port’s own traffic will tell you. Read a week of destinations and you will find services attached to that line you had forgotten about. Memory is worse than the log every time.

Then the people. Who else has the host and port. A contractor from last year. Whoever administers a client’s firewall. A vendor who wanted a fixed source address during setup.

Then the accounts, which is the list nobody writes honestly. Every login that has only ever been used through this line, including the ones you are not sure about.

If that takes you more than a few minutes to produce, you have learned something more useful than anything on your billing page. You have been running work through a connection you could not account for, and that is worth a week’s delay on its own.

Overlap, then cut

If the work is continuing somewhere else, pay for both lines at once for a while.

An overlap costs one month of one line. On the other side of that decision sit accounts you spent months building and a set of allowlist entries you have not finished finding. The arithmetic is not close.

So do not switch the old line off on the day the new one starts. That single habit turns more clean migrations into bad weeks than anything else in this piece.

The overlap is not really about the move itself. What it buys you is a search window: whatever you missed while making the list surfaces during it, while the old line is still answering and the fix is a config change instead of a rebuild.

How you actually move accounts across without the move becoming its own incident is a separate subject and has its own piece. The rule here is smaller: a week of overlap if the whole setup lives on machines you own, a month if anyone outside your company is holding that address.

Wrong line, or finished work

These get treated as one decision. They are two, and they lead to opposite actions.

If the line is the problem, cancelling is the wrong tool. Wrong carrier for the platform you are working against. Speed that does not hold up. A modem that keeps dropping and nobody has looked at it properly. All of that is a swap, and any provider who owns the hardware can move you within the same carrier without losing the shape of your setup. People cancel and go buy the same product from a competitor when one message would have fixed it.

If the work is finished, cancel. The project ended, the client left, the accounts are sold or dead. Nothing left to protect.

Then the case nobody names: you do not know which of those two you are in, because nobody has looked at that line in three months. That is a reporting problem sitting in front of a billing decision, and reading what a line’s usage actually tells you comes first.

When cancelling is obviously right

A line you are not using is money you should stop spending. If a port has moved under a gigabyte in two months and you cannot name the job it is doing, cancel it today and skip the rest of this.

I would rather have four lines a customer uses than nine he feels vaguely guilty about. The nine version ends the same way every time. Somebody adds it up in January, feels stupid, and cancels the lot in one bad mood.

Do not hold a line just in case, either. Holding spare capacity is my job and I already pay for it, with unrented cards on every carrier I sell sitting there earning nothing.

The position that gets argued with is warmth. Keep one line alive, the theory goes, so the accounts stay warm on it. Mostly that is a story told at renewal time. If those accounts need activity to stay healthy, an idle line supplies none of it, because nothing is signing in.

Ask these before you press it

Ask what happens to the card when you cancel. Straight back into stock, or held for a few days. That changes how much time you have.

Ask whether cancelling mid month ends the line immediately or lets it run out the period you paid for. You paid for the month.

Ask what a pause costs, and be suspicious of a free one. On real hardware, somebody is still paying the carrier around ten dollars a month for that SIM while it earns nothing.

What I changed, and what I still cannot do

I used to release cancelled cards the same day because it was tidy and it put hardware back to work by the afternoon. It caught four or five people out before I took the hint. Now a cancelled card sits out of stock for a few days first. It costs me the monthly on it for that window and it has saved several people from their own timing.

It is not on the site as a guarantee, because if I am short on that carrier the card goes back the same afternoon.

The limit I cannot engineer around is bigger than that. I can see how much a port moved and roughly where it went. I cannot see which of your logins would care about arriving from a new address on Thursday, which means the list in the middle of this piece is yours to write and there is no version where I write it for you.

If you want lines from an operator who will tell you when to cancel one, there is a free trial of Singapore Mobile Proxy: real SG carrier IPs on my own hardware, sticky and rotating ports, and DNS that routes through the tunnel. Code YT30 takes thirty percent off the first month.

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