How to Choose a Proxy Provider: A 12-Point Evaluation Checklist

Most proxy purchases come down to whoever printed the lowest number next to "per GB". That figure predicts your bill under an assumption that never holds, which is that every gigabyte you buy turns into data you wanted. Providers vary enormously in how much of your traffic converts, and the variance shows up nowhere on the pricing page.

The twelve checks below are the ones that change a decision. Each states what to look at, how to test it during a trial rather than take it on trust, and what answer should make you stop the conversation. Run them against your own targets. A pool can be flawless against a neutral echo endpoint and useless against the site paying your salary.

Write down the job before you shortlist anyone

Half of bad proxy purchases are specification failures rather than vendor failures. Before you sign up for a single trial, get these five facts onto one page, because every check afterwards is measured against them.

• Targets. The specific domains you will hit, and which anti-bot vendor sits in front of each. This list is your test corpus.
• Volume. Gigabytes per month at your current page weight, not request counts. Measure a sample of real pages rather than guessing.
• Geography. The countries you need, ranked, with the share of traffic each represents. Add cities or ASNs only if the job genuinely requires them.
• Session shape. Whether each request is independent or whether state has to survive across a sequence of requests.
• Tolerance. The failure rate and the p95 latency at which your pipeline stops meeting its deadline.

Checks 1 to 4: does the pool work on your targets

1. Measured success rate on your own target list

The number that matters is the share of requests that return the content you asked for, per domain, measured over at least twenty-four hours. Separate transport failures from target-side rejections. A connection reset, a 407 from the gateway or a proxy timeout is the provider's problem. A 403, a 429, a CAPTCHA interstitial or a 200 carrying a soft-block page is the pool's reputation showing. You pay for both.

Test it by classifying responses with a content assertion rather than a status code, because soft blocks return 200 constantly. A bad answer is a quoted figure with no target named, or a support reply explaining that success rate is measured against the vendor's own endpoint. Definitions and measurement traps are in proxy success rate explained.

2. Latency at p50, p95 and p99 under load

A crawler with a hundred workers is paced by its slowest responses, so an average response time tells you almost nothing. Log time to first byte separately from total transfer time: the first isolates gateway handling and exit selection, the second mixes in the household's upstream link, which you cannot influence.

Measure at the concurrency you will actually run, because gateway queueing only appears under load, and at the hours you actually run, because residential pools change size with the local day. A bad answer is a published average with no percentile attached, or a latency figure that quietly improves when you reduce concurrency. Procedure is in how to test proxy speed, and our own long-run distributions are plotted on the performance graphs.

3. IP reputation and clean rate

Two exits with identical latency can behave completely differently in front of a commercial anti-bot service, because one address has a history and the other does not. Sample a few thousand distinct exits and score each one, then look at the shape of the distribution rather than the mean.

Shape matters more than average here. A pool that is ninety percent pristine and ten percent blacklisted performs worse than a uniformly mediocre pool if you have no cheap way to detect the bad decile before spending bandwidth on it. A bad answer is "all our IPs are clean", which no operator of a peer-to-peer network can honestly say. Background is in proxy fraud score explained.

4. Pool composition in the countries you need

Headline pool figures are cumulative counts of every address seen anywhere over months. Ask instead for distinct exits observed in the last twenty-four hours in each of your top three countries, and how many you can hold concurrently.

Test it by firing a fixed number of rotating requests in one country and counting distinct addresses. Plot the discovery curve. When new addresses stop appearing, you have found the practical ceiling for that country at that hour, and repeating at three times of day tells you how much the pool breathes. A bad answer is any figure quoted only as a global total, or a refusal to break it down by country. The counting problem is unpacked in proxy pool size explained.

Checks 5 to 7: can you control it

5. Rotation modes and session control

You need per-request rotation, sticky sessions with a duration you set, and a documented answer to what happens when a pinned exit drops offline mid-session. Silent replacement is the default in many networks and it will corrupt any workflow that carries state.

Test it by pinning a session, calling an IP echo endpoint every five seconds for the full advertised lifetime, and recording every change. Do that a hundred times and plot the survival curve. A bad answer is "sticky up to thirty minutes" with nothing about failure behaviour. The decision tree for which mode fits which job is in rotating vs sticky proxy sessions.

6. Geotargeting granularity that survives contact with reality

Country targeting is universal. State, city and ASN targeting vary wildly, and the behaviour that matters is what the gateway does when a filter cannot be satisfied.

Test it in two steps. Send a nonsense city and see whether you get an error or a random exit, which tells you whether the gateway validates anything at all. Then request your real city several hundred times and measure the match rate against two independent geolocation databases. A bad answer is silent fallback to the national pool, or a coverage page listing cities with no live counts behind them. The full mechanism is in the proxy geotargeting guide.

7. Protocol and integration support

Look for HTTP CONNECT and SOCKS5 together, remote DNS resolution at the exit, IPv6 if your targets need it, TLS on the connection to the gateway so credentials and target hostnames are not in cleartext on your local network, and IP allowlisting as an alternative to username authentication with a sensible number of entries.

Test it by wiring the proxy into your real stack for an afternoon: your language's standard HTTP client, your headless browser, and whatever framework runs in production. A bad answer is a mandatory SDK, a browser-only integration, or a gateway that only speaks one protocol. The trade-offs are in http vs socks5 proxies.

Checks 8 to 10: does it scale and what does it cost

8. Concurrency limits, published and real

Networks throttle by open connections, by requests per second, by country, or by some combination nobody documents. Some reject excess load with a clear error. Others queue it silently, which looks identical to high latency and sends you debugging the wrong system.

Test it by ramping concurrency in steps and recording success rate and p95 at each step. The knee in that curve is your real limit whatever the plan page says. A bad answer is "unlimited concurrency". Everything has a limit, and a vendor who will not name theirs has not measured it.

9. Pricing structure and bandwidth expiry

Get the price per gigabyte at your committed volume, the minimum commitment, the overage rate, whether unused bandwidth rolls over or expires each month, whether failed requests and tunnel overhead are billed, and whether narrow geo or ASN targeting carries a premium. Expiry terms quietly convert a discount into a penalty for anyone with seasonal volume.

Test it by buying the smallest plan, transferring a payload of known size, and comparing the dashboard against your own byte counter. A few percent of difference is normal accounting. Tens of percent needs an explanation. A bad answer is thirty-day expiry on an annual commitment, or a refusal to state the overage rate in writing. Tier structures are broken down in residential proxy pricing explained, the waste is addressed in reduce proxy bandwidth costs, and we normalise every vendor to a price per 100GB comparison.

10. Trial and refund terms

A useful trial gives you enough bandwidth to run a real job, against your own targets, without a sales call. A few gigabytes is enough to answer most of the checks above. Anything smaller only proves the gateway accepts your password.

Test the refund clause by reading it before you pay and asking support to confirm the window in writing. A bad answer is a hundred-megabyte allowance, a demo restricted to the vendor's own test URLs, or refunds granted "at our discretion".

Checks 11 and 12: can you trust the company

11. Sourcing transparency and compliance posture

Ask where the addresses come from, at what point in the user journey bandwidth sharing is disclosed, whether participants are compensated and can opt out, what know-your-customer checks the vendor runs on its own buyers, and whether a data processing agreement is available. A network that sells to anyone with a card ends up with a dirtier pool, and you inherit that reputation.

Test it by sending five specific questions in writing and timing the reply. Specific answers arriving in two days is a good sign. A bad answer is the phrase "ethically sourced" with no mechanism behind it, or a refusal to put sourcing representations into the contract. The legal and procurement consequences are set out in are residential proxies legal.

12. Support responsiveness during an incident

The metric is time to a useful reply at three in the morning on a Sunday, and whether that reply comes from someone who can read a gateway log. A chat widget on the marketing site tells you nothing about either.

Test it during the trial by opening a genuinely technical ticket outside business hours. Ask what the exit selection behaviour is when a sticky node drops mid-session, which is a question a script cannot answer. Time the response and judge the content. A bad answer is a support channel that only exists on a messaging app, a reseller with no escalation path, or a status page with no incident history.

Score the shortlist

Copy this table, score each provider from 1 to 5 in the last column during the trial, multiply by the weight and total it. Adjust the weights to your job. A latency-sensitive pipeline should push check 2 higher; a compliance-constrained team should push check 11 higher.

Finish on effective cost, not the headline rate

Once the trial data is in, convert everything into one number: what a usable gigabyte costs you. Divide the committed price per gigabyte by your measured success rate, then add the bandwidth burned by retries and the engineering time the integration consumed.

Work it through with your own figures and the ranking usually shifts. A pool at four dollars per gigabyte converting ninety-two percent of requests costs about $4.35 per usable gigabyte. A pool at two dollars fifty converting fifty-five percent costs about $4.55, before you count the retries, the extra concurrency needed to hit the same throughput, and the on-call time spent working out why yesterday's job did not finish. The cheaper line item was the more expensive purchase.

We run these measurements continuously against every provider we track, from US and EU infrastructure, and publish the raw output on the live benchmark table with the scoring described in our methodology. Put two candidates head to head in the provider comparison tool, and if you would rather reproduce the whole thing yourself, the harness design is documented in how to benchmark proxy providers.