How to Choose a Proxy Provider: An Evaluation Checklist

What to verify during a trial, what to ask about sourcing and billing, the warning signs, and an honest list of the buyers node4 would not suit.

Proxy providers are unusually hard to evaluate, because almost everything on a proxy sales page is unverifiable from the outside. You cannot audit a pool. You cannot inspect sourcing. You cannot reproduce a performance figure measured on infrastructure you will never see, against a target you do not crawl. A provider can put more or less any claim on a landing page, and the industry's landing pages suggest many do.

What you can do is test. A trial, run with intent, reveals most of what the marketing conceals, but only if you measure the right things, and most trials measure nothing beyond "it connected."

This is the checklist we would use to buy proxies from anyone, ourselves included. It has three parts: what to verify hands-on during a trial, what to ask a human before money moves, and the warning signs that should end a conversation early. And because a checklist you only ever apply to competitors is just advertising wearing a lab coat, it ends with the cases where node4 is the wrong answer, written plainly, because a buyer who chooses us knowing the tradeoffs stays; one who discovers them after the first invoice does not.

Before any of it: define the workload

A provider is never right or wrong in the abstract, only for a workload. Before trialling anything, write down four facts: the actual sites or APIs you need to reach, the request volume you expect at steady state, the geographies that matter, and whether your flows need one identity held across many requests or a fresh exit every time. Every test below is parameterised by those four answers, and without them each evaluation collapses into comparing prices on products you have not established you need.

If the proxy-type half of that decision is still open (datacenter against residential, rotating against static), settle it first with choosing the right proxy type; the use cases page maps common workloads onto product categories. Bring the conclusion to the trial. You are not testing "the proxies." You are testing them for your job.

What to verify during the trial

The exit IPs are what the label says

Every exit address belongs to an ASN (an autonomous system) whose registration is public. A residential exit should trace back to a consumer internet provider; a datacenter exit to a hosting company. This is checkable in one pipeline:

# Fetch an exit through the proxy, then look up who the address belongs to
EXIT=$(curl -s -x http://USER:PASS@HOST:PORT https://api.ipify.org)
whois -h whois.cymru.com " -v $EXIT"

The Cymru lookup returns the ASN and its registered name. Run it a few dozen times against a rotating product and tally the results. What you are looking for is mislabelling: "residential" traffic that consistently emerges from hosting ASNs is relabelled datacenter space sold at residential prices, and it will be classified exactly as datacenter space by any target that checks, which is to say by every target that matters. A handful of ambiguous registrations proves little; a pattern is a verdict. Tally the country codes from the same output while you are there, since they feed the targeting check below.

The success rate on your target, not a generic one

A demo that fetches a friendly page proves connectivity and nothing else. Blocking is a bilateral relationship between a pool and a target: the same pool can be clean on one site and thoroughly burned on another, because previous customers of that pool crawled the same place you are about to. No provider can truthfully quote you a universal figure, and the ones who do are quoting fiction.

So generate your own. Run a few hundred requests against the pages you actually need, at something like your production concurrency, spread over at least a day so you sample different pool conditions. Score every response into one of three buckets: a usable page, an explicit block, and the sneaky third bucket: a clean status with a captcha, an interstitial, or an empty template where the data should be. That third bucket is found only by asserting on content, such as a selector that exists solely on the real page; a scorer that trusts status codes will grade a fully blocked crawl as a success.

Write the resulting number down. It is your comparison point across providers this week, and after you subscribe it becomes your baseline for detecting pool decay. A more rigorous protocol for this measurement, latency percentiles included, is in measuring proxy performance.

Targeting resolves where it claims

If geographic targeting is part of what you are paying for, verify it two ways, because they fail independently. The first is a geolocation lookup on the exit address. It is quick, but geolocation databases disagree with one another far more than any of them admits, and address blocks get reassigned across borders with the databases trailing behind. The second check is the one that actually matters: the behavior of the site you care about. Request an exit in a specific country and look at what the target does: the currency it quotes, the language it redirects to, the store inventory it shows. Your data pipeline lives downstream of the target's opinion, not the database's.

Then run the negative test, which almost nobody does: request a location the provider does not cover and watch what happens. A refusal is honesty. A silent fallback to "somewhere else" is a provider deciding that wrong data is better than no data. You want to learn that policy on a trial request, not months into a location-sensitive crawl. Ours refuses rather than redirecting; the full username grammar is in country and city targeting.

What to ask before you pay

Some properties cannot be measured from outside. For those, the tool is a direct question, and the speed and specificity of the answer is itself data.

Where does the residential pool come from? Residential exits are people's home connections. The legitimate route to them is consent: an SDK inside apps whose users agreed to share bandwidth, ideally compensated, always able to leave. Ask exactly how exits are sourced, what the consent flow shows the end user, and how a user opts out. A provider who cannot answer crisply may be routing your traffic through devices whose owners never agreed. That is an ethical problem first, and shortly afterwards an operational one, because consent-free pools are the ones that get shut down, seized, or blacklisted wholesale, taking your crawl with them.

Are the IPs owned or resold? A surprising share of proxy brands are the same one or two upstream aggregators wearing different pricing pages. Reselling is not automatically disqualifying, but it has two consequences you should price in. Overlap: the "fresh" pool you switch to after burning one may contain the very addresses you burned, because both brands drew from the same upstream. And powerlessness: a reseller cannot fix a routing problem or replace a bad range; they can only forward your ticket and wait alongside you. Ask which infrastructure the provider actually operates. If you suspect two brands share an upstream, compare the ASN tallies from your trials of each; matching distributions answer the question the sales teams will not. We have published that arithmetic against the two providers buyers most often put beside us, including the rows where they win: node4 against IPRoyal and node4 against Proxy-Cheap.

What happens when an IP is burned? Every pool degrades against every serious target, given enough traffic. Competence shows in the process around that fact. For rotating products: how are dead or blocked exits detected and rested, and by whom? For static products: when the specific addresses you hold go bad, is there a swap allowance, how fast does a replacement arrive, and does it cost extra? A provider with no articulate answer has no process, and a pool with no process is a lottery you re-enter every month.

What exactly is billable? Per-gigabyte, per-IP, and per-port models all exist, and none is wrong; each is merely wrong for somebody. Metered bandwidth favors light, structured payloads and punishes media-heavy crawls; per-IP pricing inverts that. The finer print matters more than the model: are failed requests metered? Retries? Protocol overhead (headers, TLS handshakes) measured at the proxy, which always exceeds the byte count your application logs? Ask where the meter physically sits and whether you can watch it in near-real time. A provider whose dashboard shows live usage can be reconciled against your own logs; one that reports monthly is asking to be trusted for thirty days at a stretch. How usage becomes a bill here is documented in understanding your invoice.

Who answers support, and when? Ask the hours, the channel, and who is actually on the other end: a first line reading from scripts, or someone who can see the routing. Then test it: send one genuinely technical question during the trial and judge the response by whether it engages your specifics. Check the answer about hours against your own operating pattern, and hold the answer to the same standard as the rest of the page: staffing has to be real to be useful, whatever the sales copy implies.

Warning signs

Certain phrases predict the relationship you will have with a provider. These are the ones that should make you slow down:

• Pool sizes nobody can verify. 10M+ residential IPs appears on an implausible number of otherwise unrelated websites, often in the same font over the same testimonial widget. No external audit of any proxy pool exists, so the figure is decoration, and identical decoration across brands is itself evidence of a shared upstream. The number that matters is how many exits are live for your targeting against your target, which is precisely what your trial measured.
• Latency promises. A page committing to <50ms responses is promising physics it does not control. Latency is a route: your machine to their infrastructure, infrastructure to exit, exit to your target. The provider controls one leg of three. Any single quoted number, without a stated route and measurement point, is marketing. Measure it yourself, from your servers, through their exits, to your target.
• Promises the terms of service take back. Read the ToS before paying; search for the availability, refund, and liability language, and put it next to the sales page. When a landing page offers guaranteed 100% uptime while the ToS disclaims all warranties and every service level, the ToS is the document that governs: the landing page was for you; the ToS is for their lawyer. An unlimited bandwidth badge sitting one click from a fair-use clause is the same contradiction compressed into a single screen. The honest shape is a stated target with terms that match it; our own materials give 99.9% as an uptime target, because that is what it is.
• Absolutes. undetectable, never gets blocked, 100% anonymous: each is disproved by somebody's first afternoon of real traffic. The claim itself is the signal: a provider willing to print an impossibility is showing you how they weigh accuracy against conversion, and that ratio will govern every support conversation you ever have with them.
• A trial pool that is not the production pool. Some operators route trial traffic through their cleanest ranges and paying traffic through the rest. Defend against it by asking outright whether trial and paid traffic share a pool (get it in writing) and by re-running your target test in the first week after paying. A gap between that number and your trial baseline is the answer, whatever the ticket queue says.
• Residential pricing below plausibility. Consented residential bandwidth costs real money to source, and that cost puts a floor under honest pricing. An offer dramatically beneath the market clears that floor by cutting a cost, and the costs available to cut are consent and pool hygiene. Cheap traffic through unconsenting devices is not a bargain; it is a liability with a checkout page.

Where node4 is the wrong choice

Our own checklist, applied to us. These are the buyers we would point elsewhere today:

You need a vendor with a long third-party record. node4 is a young provider. There is no multi-year review history, no analyst coverage, no thick file of independent write-ups for your procurement process to weigh. If your organization scores vendor longevity (and for critical infrastructure that is a reasonable thing to score), an established name clears a bar we cannot yet reach. What we offer instead is testability: everything in this article can be measured against us without payment. But "verify it yourself" substitutes for reputation only when you have the time and inclination to verify, and not every team does.

You need mobile exits. Mobile proxies are not sold here: not deprioritised, not waitlisted, not sold. Workloads that specifically require carrier-network reputation or traffic that presents as a handset need a provider that operates genuine mobile infrastructure, and that is not us.

You need the newer address family. The pool is IPv4, all of it. If your targets or your compliance requirements involve the successor protocol, nothing here serves that today.

You need static residential addresses. Our residential product is a gateway: rotating by default, session-pinned on request. There is no ISP-style product where you hold the same residential addresses for months on end. Long-lived logins and ad accounts that want one stable residential identity are better served by a provider selling exactly that, and several do.

You need someone answering at any hour. Technical support here is staffed around the clock. A ticket opened overnight is read in the morning, not at 3 a.m. If your operation cannot tolerate that window (revenue-critical scraping with no in-house on-call of your own), buy from a provider that staffs a night shift, and use your trial to confirm the night shift genuinely answers.

None of this is modesty deployed as a sales technique. A buyer who reads that list and signs up anyway arrives with accurate expectations, and accurate expectations are what a small provider's reputation is built from. The alternative, tradeoffs discovered after purchase, is how this industry earned the reputation it has.

Running the checklist on us

The free tier exists for a real slice of this purpose: 3 free shared proxies with 1 GB/month bandwidth and 10 concurrent threads, no card required. That is enough to score a few hundred requests against your real target through its shared datacenter proxies and see how we behave on the workload you actually run. The residential checks are the exception: the ASN tally and the coverage-refusal test exercise the residential gateway, which the free tier cannot reach, so those two need a residential plan (see pricing). If the very first request dies with a 407, that is almost always configuration rather than verdict; work through that before scoring anyone, us included. If the workload you are evaluating is a Scrapy crawl, wire the trial through the middleware setup you will actually run in production, because a trial of a setup you will not use measures nothing. Then put your numbers next to the pricing and decide with your own data on the table instead of anyone's marketing, ours included. The shorter questions a checklist does not cover, such as what a billing period is, what counts as metered traffic and how cancellation works, are answered on the FAQ.