Reselling proxy lines to your own clients

A fair share of the people renting lines from my rack never touch them. They rent them on. Agencies do it, and so do small proxy shops with a landing page and a Telegram channel, and every so often it is one person with three clients and a spreadsheet. I sit at the supplier end of all of those arrangements, so when something breaks for the client of a client, the escalation eventually lands in my inbox, usually late and usually missing everything I would need to act on it.

The message that finally made me write this arrived at twenty past midnight. A reseller’s client was locked out, could I please restart the line. Which line, I asked. He could not tell me. He had six ports under a single username and password, and he had handed that same credential to every client he had. The only thing I could check was whether any of the six ports had a fault, and none did. All six were up and passing traffic a few metres from my desk. The actual problem lived in a browser on a laptop in a country I have never visited, and nothing connected that laptop to anything I could see. Two hours later we gave up for the night. With one piece of bookkeeping in place, it would have taken four minutes.

The margin is a support margin

The gap between what you pay for a line and what you charge for it looks like the whole product. The bandwidth, though, turns up whether you exist or not. What a client actually pays a reseller for is a person who answers, and who can say which line his problem is sitting on. A reseller who cannot do that second part is a message relay with a markup attached, and the first bad week makes that obvious to everyone involved.

What a useful escalation contains

Consider what your supplier needs before he can be useful. The port name. A rough window, meaning a day and an hour rather than last week sometime. A description of the failure as the client saw it, because a timeout, an authentication error and a challenge page point at different halves of the system. And whatever you already ruled out.

What usually arrives instead is a single sentence: it is not working. So the supplier asks his questions, the reseller relays them to his client, the client has gone to bed, and a full day disappears into a relay race. The answers, when they finally come back, are secondhand and half remembered.

All of that delay comes out of a missing record, and the record can only live with you, because you are the only person in the chain who knows which client is which.

Some answers need hands on hardware

There is a second half to this that resellers tend to find uncomfortable. Part of every diagnosis needs physical access, and you have none. Whether the modem behind a port is running hot. Whether the sim in it has crossed its allowance and dropped into a throttle. Whether the port was quietly reprovisioned onto a different device last week, or a whole shelf lost power for ninety seconds at three in the morning. None of that is visible from a laptop, the client’s or yours. You can see that a line is slow. The why is out of reach.

So the skill you are building is asking the question in a form that gets an answer on the first message: port name, day and hour, what the client saw, what has already been ruled out. Sent like that, it usually earns a specific reply the same evening. And be prepared for the reply to be that the line is healthy, because most of the time it is. The fault usually sits in a config on the client’s machine, and learning that quickly is worth as much as a hardware fix.

One credential per client

Before you take a single client, split the credentials. One per client, scoped to exactly what that client pays for. A single credential covering the whole account is how my midnight story happens, and per line credentials shared around still leave you unable to cut one person loose without disturbing the rest.

The setup costs an afternoon. What it buys lasts the whole relationship. Usage becomes attributable, so when the bill has a shape you did not expect, you can point at the client who made it. A leaked credential means rotating one login while every other client carries on untouched. And when someone reports a broken line, you already know which port to look at before you type a word to your supplier.

Put the client in the port name

Every port I hand out carries a name, because the name is how anything gets found later. I learned to put my customer in it. A reseller should put his own client in it, in whatever form means something to him. A rack of ports called port one through port twelve is a filing system that fails somewhere around the fifth port.

Keep your own usage records

Your supplier will show you a dashboard, and it will be adequate right up until the day you need to argue with it. That page is built around the supplier’s account, and it aggregates however the supplier finds convenient. What you need is per client, over time, in something you control. A small scheduled pull into a file works. So does a spreadsheet updated weekly. It does not have to be clever.

The reason is dull, and it is the whole reason. A client will one day insist his number is wrong, and at that moment you either have your own series to put beside the claim, or you have a supplier’s aggregate telling one of you that the other is mistaken. There is a quieter benefit as well. Your own series is where you notice a client whose usage stepped up three weeks ago and stayed there, which usually means something retrying in a loop, and that is a conversation far better opened than received.

Agree the replacement path before you need it

Lines die. Modems cook themselves, sims go bad, a hub browns out and takes a group of ports down together. The day one conversation with your supplier is about what happens next. How fast is a swap. Does the swap land on the same network. And the question everyone forgets to ask: does the replacement arrive with a new address. It does, almost always, because the address belongs to the carrier and the carrier hands it to whichever device attaches.

That answer belongs in writing, in front of your client, before money moves. A hardware failure will change the address his accounts are seen from. Some clients shrug. Some care enormously, and the time to find out which kind you have is before you are standing between a dead port and an angry message. Be equally plain about lead times. On some networks here a new sim takes days to activate, and urgency does not compress that. Promise same day expansion and you are promising something you do not control.

The list of things you will not promise

Write the list down, and hold to it while somebody is waving money at you.

An address with no history cannot be promised by anyone. It comes out of a shared carrier pool, and it has carried real subscribers, and possibly other people’s automation, for as long as it has existed. Account survival cannot be promised either, because the platform decides that on device, payment, behaviour and half a dozen signals that have nothing to do with which address a login came from. Uptime you do not control belongs on the list too. What is genuinely yours to offer is a response time and a replacement path, so promise those.

A client who heard the truth and then had a bad month tends to stay. A client who was told his line was untouchable and then watched an account go down leaves, and explains why to other people.

The arithmetic that decides whether this is a business

You are billed for every line you hold on the day the bill falls, occupied or idle. Your real margin is the headline margin multiplied by the fraction of your inventory that is earning, and that fraction never reaches one. It cannot, because you need spare capacity for the day something dies. A client who waits three days for a replacement is a client with a reason to shop around, and the spare line that prevents it costs the same as the earning ones while returning nothing.

Price for that. Plenty of small resellers price against the cheapest listing they can find, discover they are funding idle lines and support hours out of a sliver, and a few months later they quietly stop answering messages. Count the support time honestly as well. An hour of your evening spent on a diagnosis is a real cost even though nothing invoices you for it.

Make leaving boring

Clients leave. It is a rented product and people move on. The good version of a departure is dull: one credential revoked, one port reassigned or dropped, one allowlist entry removed, and a record of which line he was on in case something surfaces afterwards. The bad version is discovering that his credential also opens four other clients’ lines, and now everyone’s config breaks on a tuesday while you rotate logins and write apologies. Which version you get was settled months earlier, on the day you set up credentials.

The part I got wrong

For a long time I made this worse from my end. When a reseller asked for six lines, I put six ports under one login, because it was fewer objects for me to manage and nobody had asked for more. It felt like a favour. What I had actually done was strip his ability to answer any question about his own customers. No per client usage, no way to revoke one person, no way to tell me which port to look at. That midnight conversation was a thing I helped build.

I changed how ports get named and split after that, and I now ask anyone reselling how he wants the lines separated before I provision anything. Five minutes at the start removes most of the two hour conversations later. The lesson also cost me a customer I deserved to lose. He hit exactly this problem, concluded the lines were unreliable, and left. The lines were fine. The bookkeeping around them, part of it mine, was not.

So if you are reselling, take the boring version: one credential per client, named ports, your own usage numbers, a replacement path agreed in advance, and a short list of refusals. It is an afternoon of setup, and it is the difference between a margin and a second job. If you want lines from a supplier who will help you split them properly before you rent them on, that is what I run at singaporemobileproxy.com.

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