How to test a proxy before you pay for it

I sell mobile proxy lines. Sim cards on Singapore carriers, modems on a shelf in my flat, roughly $10 a month in carrier data per line and another $1.50 in modem depreciation. Read everything below with that in mind.

It is also why I want you running a real test. A buyer who evaluated properly stays. A buyer who clicked an address checker for three days and paid anyway cancels in week six and posts about it. I would rather lose the sale during the trial.

Here is the sequence I would hand somebody evaluating me.

Run the cheap checks before the expensive ones

The order is the point. Each check costs more than the one above it, in time and in how much of your own code you have to wire up. If check one fails, nothing below it matters.

One: does the registration match what you were sold

Every address block on the internet is registered to an organisation, and that registration is public. One lookup returns the holder and the network number it sits in.

Do it for every address in the trial, not a sample. A pool is only as good as its worst entry, and the worst entry is the one your job lands on at 3am.

Good: a mobile carrier if you bought mobile, a consumer ISP if you bought residential, one consistent holder across a pool sold to you as one pool.

Bad: a hosting provider sitting behind something labelled residential. It is not always deliberate, and it is always worth an email before money moves.

Also bad: registration that scatters across five unrelated holders in four countries. That is a reseller buying from resellers. Nobody in the chain can tell you what you have, including the person taking your card.

Two: whose history are you inheriting

Reputation services keep lists of addresses, and a large share of sites do nothing cleverer than ask one of those services for a score. Take a trial address and you take its past along with it.

Push each one through two or three lookups. Free tiers are enough for this.

Good: nothing listed at all, or a single listing from a service that flags every mobile address in existence for the crime of being mobile.

Bad: an address already sitting on a spam blocklist, or one returned as a known open proxy. You have been handed something that was burned before you arrived.

I have had a pool address turn up already refused by my target on the first request I ever sent. That was somebody else’s month and I paid for it. I take the baseline on day one now, so when something degrades in week three I can show it degraded.

Three: speed, measured from the machine that will do the work

This is where the browser test does the most harm.

A speed test loaded on your laptop, through an address on another continent, measures your laptop, your home line, your browser, and the distance. Your scraper runs on none of those.

Test from the box the job runs on. Measure two separate things: time to first byte on a small request, and sustained throughput on a payload big enough to stream for a few seconds.

Good: a first byte figure you can live with, holding roughly steady across ten repeats.

Bad: a healthy median with a tail at eight seconds on one request in twenty. Tail latency is what breaks a crawl. A run of 100,000 requests meets that one in twenty about 5,000 times, and your worker pool spends its life sitting in a wait state.

Record the worst run rather than the mean. The mean is the number a seller quotes. The tail is the number you operate.

Four: can a session outlive a task

Take the longest single unit of work your job performs. A login followed by eleven pages. A cart flow. A paginated crawl that holds one address for four minutes.

Hold a session that long and compare the exit address at both ends.

Good: the same address at the start and the finish, with no reconnect you did not ask for.

Bad: a silent rotation mid task. On plenty of pools this is default behaviour and not a fault. Your session dies, the error surfaces on the target’s side, and you spend two days debugging the wrong system.

Ask for the sticky session duration in writing, then verify it under load instead of at rest. I have watched a documented ten minutes behave like ninety seconds once the pool got busy.

Five: rotation on demand

The inverse test. Ask for a new address and confirm you actually get one.

Good: a fresh address inside a few seconds, every time you ask, with the previous one not reappearing on the very next request.

Bad: forty second rotations. Or the same address handed straight back. Or an API that quietly rate limits after the fifth call in a minute and documents that nowhere.

Time it and write the number down. Rotation latency and rotations per hour both become hard constraints inside your scheduler, and finding them afterwards is the expensive way round.

Six: a slice of the real job against the real target

Everything above is synthetic, and every synthetic test is a weak substitute for the only question that matters.

Send two hundred requests of the exact shape your scraper sends. Your headers, your concurrency, your pacing, your parser reading the body.

Good: your parser pulling the fields it expects out of most of those responses.

Bad: responses that look healthy to an HTTP client and arrive empty at the parser. That failure mode costs people weeks, because the status line says 200 and the body says nothing.

Assert on content. Count rows, not responses. A test that counts 200s will happily pass on a page that has quietly turned into a soft block notice.

Why a generic IP checker tells you nothing

An address checker answers one question: can this address load a page that is willing to be loaded by anybody at all.

Your target is a different page, with its own rules, its own record of your address, and its own tolerance for the pattern your requests make. The checker has no motive to refuse you. It exists to display an address back at you.

The browser you loaded it in is not your scraper either. Different fingerprint, different header order, different TLS handshake.

The one thing a checker earns its place for is confirming that traffic leaves through the address you believe it does. That is one line of a trial.

Test at the hour your job actually runs

Contention runs on a clock.

A shared pool at 4am local is a different product from the same pool at 8pm, when everybody on it is awake and pulling. A mobile line is worse for this, because it sits behind a carrier tower, and a tower at rush hour is congested for the same reason your phone crawls on a packed train.

If the job runs at 2am, test at 2am. If it runs during business hours in the target’s country, test then. A trial run at a quiet hour flatters every supplier equally, which makes it useless for choosing between two of them.

What to ask before the trial opens

How many other customers are on this address right now. A seller who says one, meaning you, is selling dedicated. A seller who cannot answer is selling shared and would rather not name a figure. Both are fine to buy. Only one should carry dedicated pricing.

What happens when a line dies at 3am. Is there a swap procedure, is any part of it automatic, does it need a person awake in the right time zone.

Can I have a replacement without an argument. I swap a dead line and note it in the ticket afterwards. Some suppliers want proof first, and you find out which kind you bought in month two.

None of those has a technical answer. All of them describe what the next twelve months feel like.

What I got wrong

I once evaluated a supplier by testing their addresses for two days and their company for zero.

The addresses were fine. Clean registration, sensible latency, real work coming back with the rows in it. I bought a block of them.

Then something broke on a Saturday, and I learned their support was one person on another continent who worked weekdays. Eleven hours of dead capacity each time, four times in two months.

I had tested the product and skipped the company. Those are two separate purchases and I only paid attention to one.

Now I open a ticket during every trial. Something small and slightly stupid, on purpose. What comes back, and how long it takes, is information no benchmark gives you.

A trial is a sample

Three days on a hundred addresses tells you about three days and a hundred addresses.

It will not tell you what happens when that pool gets resold to somebody running something loud on your subnet. It will not tell you whether the lines you were handed had been quietly picked out for you, which sellers do and which is not dishonest.

Buy one month. Not six, and never a year up front. Run the same six checks on a schedule through that month and keep the numbers in a file you can put side by side.

The figure worth watching sits in month two. Month one only shows you how a seller behaves while they know you are still deciding.

And I cannot promise you a clean run either. Nobody selling addresses can. What a working supplier can promise is that a bad line gets replaced quickly and without a fight, which is close to the only guarantee anyone here can keep.

The lookups, the numbers worth recording at each step, and the rest of what I run are here.

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