Our position, stated openly: we are Geonode and we sell proxies, so "clean" is a word we could easily use loosely. We are not going to, because no provider can guarantee it and any provider claiming to is telling you something they cannot know. Whether an address works on your target depends on that target's own systems, which the provider cannot see, cannot query and does not control. What a provider can honestly offer is a pool sourced properly, monitored for the signals that are observable, and testable by you before you commit. The tests are below, they take about an hour, and you should run them on us as readily as on anyone else.
"Clean" Is Not One Property
When people say clean, they usually mean one of five different things:
Not on public blocklists. Absent from DNSBLs and abuse databases. Not previously abused. No history of spam, fraud or attack traffic. Not identifiable as a proxy. Not on a commercial proxy or VPN detection list. Not shared. Not currently being used by many other people. Working on my target. The one that actually matters.
These are largely independent. An address can be absent from every public blocklist and still be instantly blocked by the site you care about. Another can appear on several lists and work perfectly for your use case. Treating them as one property is how people end up buying on the wrong criterion.
The fifth is the only one with commercial consequences, and it is the one no list can tell you.
Blocklists: Being on One Is Normal
This is the fact that reframes the whole topic, and it surprises almost everyone.
Spamhaus publishes several blocklists used at different stages of email filtering. The SBL, XBL and PBL are queried at connection time; the DBL operates at content-filtering stage; ZEN is described as "PBL, SBL & XBL combined".
The Policy Blocklist is the interesting one. It is "a dataset containing end-user IP address ranges from which email should never be sent directly to the final destination", and it "detects end-user IP address ranges which should not be attempting to directly deliver unauthenticated SMTP email to any Internet mail server". It lists residential and consumer broadband ranges, dynamic addresses, static addresses deemed inappropriate for direct mail delivery, and ranges with high concentrations of compromised devices.
And its scale is the headline: the PBL covers "more than 1.4 billion IPv4s, corresponding to almost 40% of the routable IPv4 space".
Read that again with proxies in mind. Essentially every residential IP address in the world is on a Spamhaus blocklist, by design, because residential connections should not be sending mail directly. That is not a mark against them; it is a correct classification for the purpose the list exists to serve.
So "not on any blocklist" is a meaningless standard for residential proxies. If you check a residential address against ZEN and find a PBL listing, you have learned that it is a residential address. Which you already knew, and paid extra for.
The listings that would actually concern you are the SBL, which relates to spam sources, and the XBL, which relates to exploited machines. Those carry information. A PBL listing does not.
The broader lesson: blocklists are built for specific purposes, and a listing only means something in the context of that purpose. A mail-focused list tells you about mail. It tells you close to nothing about whether a web scraper will get a 403.
What Actually Makes an Address Work or Fail
Here is what the target site is really considering, roughly in order of weight.
Address type. Whether the address belongs to a hosting provider or a consumer ISP is public registry information. This is the strongest single signal, and it is why datacentre addresses are blocked wholesale by sites that care, and residential ones are not.
Autonomous system reputation. Sites frequently block at the operator level rather than the address level. An address inherits its network's reputation, and a whole hosting provider can be excluded with one rule.
Subnet reputation. Blocking happens at /24 granularity as often as at address granularity, so neighbours matter. Fifty addresses in one block behave like one address when that block is blocked.
Recent behaviour from that address. Rate, patterns, what was requested. This is the fastest-moving factor and largely under your control.
Everything that is not the address at all. TLS fingerprint, header composition and ordering, browser behavioural signals, session history, and account state. On any site with modern bot protection, these carry more weight than the address does — which is the honest reason we tell people that changing addresses is not a general solution.
The practical implication is uncomfortable for a proxy vendor and true anyway: an address that is "clean" by every observable measure will still be blocked if your client looks automated on the other signals.
How Addresses Get Dirty
Understanding the mechanisms tells you which problems are yours to fix.
Shared use. In any shared pool, other customers use the same addresses. One user hammering a site can get an address flagged for everyone on it. This is the single most common cause of "the proxy stopped working" and it involves nothing you did.
Previous life. Residential addresses are reassigned by ISPs. The previous holder's behaviour is attached to the address until reputation decays.
Your own rate. Requesting too fast is the most avoidable cause, and the one people most often blame on the provider.
Pattern. Perfectly regular timing, identical headers across requests, sequential URL access. These read as automated regardless of address quality.
Compromise. For residential pools built on consumer devices, some of those devices are also infected with something else. The XBL exists for exactly this.
Association. Being in a subnet with bad neighbours, or on a network that hosts a lot of abuse, affects you without any action on your part.
Only two of those six are yours: rate and pattern. They are also the two with the biggest effect on your day-to-day success rate, which is worth knowing before you go shopping for cleaner addresses.
Datacentre, Residential, ISP and Mobile: Different Cleanliness Profiles
The four address types are not points on one scale. They are distinct profiles, each clean and dirty in different ways.
Datacentre. Trivially identifiable as non-consumer from public registry data, and frequently blocked as a category by sites that care. But within that constraint they can be genuinely well behaved: allocations are stable, you often get dedicated addresses whose reputation is yours alone, and there is no previous residential occupant. For a target that does not discriminate on address type — most APIs, most public data sources, most documentation sites — a datacentre address is as clean as anything and costs a fraction as much.
Residential. Blends with ordinary consumer traffic, which is the whole point, and carries three specific liabilities. It is on mail blocklists by design. It was used by somebody before you and will be used by somebody after. And in a shared pool it is being used by other customers right now. You are buying camouflage, not exclusivity.
ISP or static residential. Registered to a consumer ISP but hosted in a datacentre. It looks consumer in a WHOIS lookup while behaving like infrastructure: stable, dedicated, and with a reputation history you build yourself rather than inherit. This is the cleanest profile available for anything long-running, and the reason it is priced per address rather than per gigabyte.
Mobile. Carrier-grade NAT means one address is shared among a large number of real subscribers simultaneously. That makes blocking it expensive for a site — they would be blocking genuine customers — which is a real advantage. It also means the address has extensive history from all those subscribers, and you have no influence over any of it.
The choice that follows is less about which type is cleanest and more about which liability you can tolerate. If exclusivity matters, ISP. If blending matters, residential or mobile. If cost matters and the target does not discriminate, datacentre — and the most common way to overspend in this market is paying residential rates for pages a datacentre address fetches without complaint.
Test that assumption rather than inheriting it. Run a sample of your real workload through the cheapest option first and escalate only where it demonstrably fails. That single habit saves more money than any negotiation over per-gigabyte rates.
How to Test Cleanliness for Your Target
The tests that matter, in order of usefulness. Run them during a trial.
1. Success rate on your actual target. Nothing else predicts anything. Take a sample of a few hundred requests, spread over several days rather than several minutes, and measure completion — not just status 200, but whether the content is what you expected. Segment by target and by region, because an aggregate figure hides one collapsed target entirely.
2. Content integrity, not just status. Soft blocks return 200 with stripped or altered content. Check for a known-stable marker on the page and assert an expected item count. This is the failure mode that hides longest, as we covered in why testing proxies matters.
3. Subnet spread. Count distinct /24 blocks in a sample of exit addresses:
for i in $(seq 1 200); do curl -s -x "$PROXY" https://api.ipify.org; echo; done \
| sort -u > ips.txt
wc -l < ips.txt
cut -d. -f1-3 ips.txt | sort -u | wc -l
A high ratio of blocks to addresses means the pool degrades gracefully rather than in chunks.
4. WHOIS classification. Confirm the addresses look like what you paid for — consumer ISPs for a residential pool, not hosting companies.
5. Blocklist checks, interpreted properly. Worth doing, worth reading correctly. A PBL listing on a residential address is expected. An SBL or XBL listing is worth asking about.
6. Proxy detection services. Several commercial services classify addresses as proxy, VPN or hosting. If your target uses one, this is directly predictive. If it does not, it tells you little.
Do all of this per country. Aggregate results hide local concentration, and the location you need is the location that matters.
What Providers Can and Cannot Guarantee
Being explicit, since this is where the marketing lives.
What a provider can honestly claim: how the pool is sourced and whether participants consented; what monitoring is in place; how addresses are rotated out when they degrade; what the subnet distribution looks like; and that you can test before committing.
What no provider can honestly guarantee:
That an address works on a specific site. They cannot see that site's systems. Any promise here is a guess dressed as a commitment.
That an address is unused by others. In a shared pool it is used by others by definition. Only dedicated addresses avoid this, and they are a different product at a different price.
That an address will stay clean. Reputation is perishable. An address that is fine this morning may be flagged this afternoon through no action of yours.
Undetectability. Nobody can promise this. Residential addresses raise fewer flags than datacentre ones; that is the honest claim and it is not the same thing.
What "clean" reasonably means from a vendor: sourced with consent, monitored for the observable signals, distributed across many subnets, and rotated out when they stop performing. That is a real offering. It is also considerably less exciting than "100% clean private proxies", which is why the honest version is rarer in advertising.
If a price is far below the market — residential bandwidth runs roughly $0.79 to $7.00 per gigabyte — the underlying cost has to have come from somewhere, and sourcing is usually the answer. The enforcement action Google's threat intelligence team announced in January 2026 against a group of interlinked resellers made the consequences of that concrete for their customers.
Keeping Addresses Clean Once You Have Them
The half that is genuinely within your control, and the half people neglect.
Rate-limit yourself below the ceiling. Find where a target starts limiting you and stay comfortably under it. Most reputation damage is self-inflicted through volume.
Vary your timing. Requests at exactly regular intervals are a signature no human produces. A little randomness costs nothing.
Use sessions where sessions make sense. A multi-step sequence arriving from four countries is not a pattern a real user creates. Hold one address for the sequence.
Honour what the site tells you. Retry-After on a 429 is a specific instruction. Following it is both correct and the fastest route back to working. Ignoring it converts a temporary limit into a longer one.
Rotate on failure, not on schedule. Burning through addresses because a timer fired wastes pool capacity. Rotate when a specific address stops working.
Do not retry into a block. Repeated requests after a 403 confirm to the target that you are automated. Back off.
Identify yourself where you legitimately can. An honest user agent with a contact URL gets blocked far less readily than anonymous automation, and it costs nothing.
Fix the non-address signals. If your TLS fingerprint says Python while your user agent says Chrome, no address is clean enough to compensate.
People Also Ask
What is a clean proxy?
There is no standard definition. In practice it means an address that works on the site you care about — which depends on that site's systems, not on any property you can measure in advance. The closest useful definition is: sourced properly, distributed across many subnets, monitored, and demonstrably working on your target during a trial.
How do I check if a proxy is clean?
Test it on your actual target and measure the success rate over days rather than minutes, checking content integrity rather than just status codes. Then check subnet spread, confirm WHOIS classification matches what you bought, and check blocklists — while interpreting the results correctly.
Are residential proxies always on blocklists?
Effectively yes, and it is expected. Spamhaus's Policy Blocklist covers residential and dynamic ranges from which mail should not be sent directly, and it spans more than 1.4 billion IPv4 addresses — almost 40% of the routable IPv4 space. A PBL listing on a residential address tells you it is residential, not that it is bad.
Why did my clean proxy stop working?
Most often shared use — someone else on the same address triggered a block. Sometimes your own request rate. Sometimes the address was reassigned or the subnet's reputation shifted. Reputation is perishable and largely outside your control, which is why success rate has to be monitored rather than assumed.
Can a provider guarantee clean proxies?
No, and a provider claiming to is claiming knowledge of your target's systems that they do not have. What they can honestly offer is proper sourcing, monitoring, subnet diversity, rotation of degraded addresses, and a trial large enough for you to verify.
What is the difference between clean and private proxies?
Private means not shared with other customers, which removes one common cause of reputation damage. Clean is about how the address is currently regarded by your target. A private address can be blocked and a shared one can work perfectly; they measure different things.
Do blocklists matter for web scraping?
Much less than for email. Lists such as Spamhaus's are built for mail filtering, and most web targets do not consult them. What matters for web access is address type, autonomous system reputation, subnet reputation and — usually more than any of these — TLS fingerprint, headers and behaviour.
How can I keep my proxies clean?
Stay below the rate limit, vary your timing, use sticky sessions for multi-step flows, honour Retry-After, back off after a block rather than retrying into it, and fix the non-address signals such as TLS fingerprint and header consistency. Rate and pattern are the two factors genuinely under your control.
Wrapping Up
"Clean proxy" is a phrase that sounds like a specification and behaves like an adjective. The useful move is to replace it with a question: does this address work on my target, right now, at my volume.
That question has an empirical answer and no list can provide it. Public blocklists are built for email, and the largest of them classifies almost 40% of the routable IPv4 space as residential — so checking a residential proxy against it tells you what you already paid for rather than anything you needed to know.
What predicts success is the boring set: success rate on your real target measured over days, content integrity rather than status codes, subnet spread rather than pool size, and per-country rather than aggregate figures. Run those during a trial and you will know more than any provider's marketing can tell you — including ours.
And then the half you control. Rate and pattern damage more reputation than sourcing repairs, and a TLS fingerprint that contradicts your user agent will get you blocked from the cleanest address in the world.