Why IP checkers flag residential proxies, and what the score actually means

A ticket arrives with a screenshot. Someone has run their proxy IP through a reputation checker, the dial is in the red, the word “proxy” is ticked, and the message says some version of: these IPs are burned, can you give me clean ones?

It is a fair thing to worry about. It is also, almost always, a measurement of the wrong thing. Those services exist to detect proxy and VPN usage. A proxy address registering on a proxy detector is the tool working correctly — on every network there is, including ours. The score tells you what a third-party database believes about an address. It does not tell you whether the site you actually care about will serve you a page.

Here is what those numbers are built from, why three of them disagree about the same address on the same afternoon, and the one measurement that replaces all of it.

What a reputation score is actually made of

Vendors weight things differently, but the raw material falls into four buckets — and only one of them is a direct observation of anything.

Network classification. Which organisation owns the address range, what kind of network it is registered as, what the reverse DNS says. Hosting and cloud ranges are catalogued exhaustively and score badly on principle. Ranges registered to consumer internet providers score better. This is a lookup, not evidence about you.

Prior reports. Abuse feeds, honeypot hits, spam traps, blocklist submissions. This is the closest thing to observed behaviour, but it is historical, and on any shared network the behaviour it records was not yours.

Usage signals. Concurrency patterns, whether the address has been seen presenting itself in ways that suggest tunnelled traffic, whether it turns up in a proxy or VPN inventory the vendor maintains. Some of that is measured. A lot of it is pattern-matching against heuristics nobody publishes.

Association. The address sits in a range where other addresses scored badly, or its ownership record resembles one that does. Guilt by neighbourhood.

Add those up, get a percentage. What you do not get is any statement about whether a request from that address succeeded anywhere today.

Most of it is inferred, not observed

A reputation vendor cannot see your traffic. They see registration data, historical reports, and whatever their own integrations happened to log, and from that they infer a probability.

Inference ages badly. Residential addresses are reassigned constantly, so an address catalogued as a proxy exit six weeks ago may be an ordinary household connection now — and the reverse is equally true. Reports attach to addresses and stay attached long after the behaviour that earned them stopped. Range-level classifications get applied wholesale, so one address can inherit a verdict a neighbour earned.

Two honest consequences follow. Ours: any address routed through a proxy can pick up a proxy classification, and we are not going to pretend otherwise or sell you a guarantee of unflagged IPs. Nobody can honestly sell that. Theirs: a score assembled mostly from lookups and history is a hypothesis about an address, not a report on it.

One case where the classification is simply correct — IPv6 is a datacenter product, not a residential one. Run those addresses through a checker and “hosting” comes back, because that is genuinely what they are. Not a flag to investigate; just the plan you bought, and perfectly fine for targets that do not weigh network type.

Why three checkers disagree about the same IP

Run one address through three services within the same hour and you can get low risk, medium, and “high risk — proxy detected.” People find this unsettling. It should be clarifying instead.

The services do not share data, do not weight the same inputs, and do not refresh on the same schedule. One leans hard on range classification. Another leans on abuse reports and holds a grudge for months. A third leans on its own detection inventory, which is only as current as its last sweep.

If they cannot agree on what an address is, none of them can be treated as a verdict on what a website will do. Disagreement across checkers is not a puzzle to resolve. It is the error bars becoming visible.

A high score does not predict the block

The practical version cuts both ways.

A high score does not mean your target will refuse you. Most websites do not buy third-party IP reputation data at all, and those that do use it as one input among many. As covered in the honest version of getting past anti-bot defenses, modern defences run a scorecard, and IP reputation is a single line on it. Addresses that a checker rates as high risk fetch customers’ targets thousands of times a day without ever seeing a challenge.

A low score does not buy you access either. Plenty of pristine-looking addresses get challenged on the first request, because the refusal came from the request rate, the header order, the TLS handshake, or the fact that one session hit forty product pages in ninety seconds. Change nothing about your client, swap only the address, and a target that fingerprints you refuses you at the same rate as before.

The score and the outcome are correlated loosely at best. Optimising the score is optimising a stand-in for the thing you want rather than the thing itself.

The thirty-second test

Stop asking a database and ask your target. One command, and it checks for the failure a status code hides:

curl -x "http://user123:[email protected]:10000" \
  -s -o /tmp/resp.html \
  -w "status=%{http_code} bytes=%{size_download}\n" \
  "https://example.com/the-page-you-actually-want"

grep -ciE "captcha|verify you are (a )?human|are you a robot|access denied|unusual traffic|enable javascript" /tmp/resp.html

Swap in your own credentials, endpoint, port and URL, then read both lines together:

• status 200, a realistic byte count, grep prints 0 — you are through. Whatever a checker says about that address is not affecting this target.
• status 200, small byte count, grep prints anything above 0 — a soft block. This is the one people miss entirely, because their pipeline logs it as a success and the fraud-score theory survives another week. You were served a challenge or an interstitial with a 200 stapled to it.
• status 200, plausible size, but the fields you need are empty — also a soft block. Some sites return a stripped page rather than a challenge, so grep for a selector you know should be present, not only for the word captcha.
• 403, 429, or a challenge status — a real block, and the fixes for it live in pacing and fingerprint long before they live in addresses.

Run it twenty times and count the outcomes. That gives you a number about your job, which is the same discipline as measuring success rate against the right denominator: score the target you came for, not a proxy metric standing in for it. If the test never gets far enough to return a body, the problem is connectivity rather than reputation, and why a proxy connection gets reset covers those causes in order.

When the score genuinely does matter

There is a real exception, and it deserves naming rather than dismissing the tools wholesale.

If your target is a payment flow, a signup or login path, an account-verification step, or anything else with an anti-fraud vendor in the decision path, then third-party IP reputation data is genuinely part of the decision. Those systems buy exactly this data and act on it. There the score is not a distraction — it is one of the inputs you are being judged against, and a flagged address can be the difference between a completed action and a review queue.

For that kind of work the answer is not a better score on a shared rotating pool. It is a network whose type matches what the flow expects, and a request whose parts agree with each other. Mobile routes through real 4G and 5G carrier addresses, which trust-sensitive flows tend to treat most generously. Platinum residential gives you country, state, city and ASN targeting, so the address you present is consistent with the rest of your story — a domestic card and address paired with an exit in the wrong country is a mismatch that needed no reputation score to catch. If the flow spans several steps and must not change address halfway, rotating versus sticky sessions covers that decision, and targeting by country, city or ASN covers getting the location right in the first place.

What to do with the screenshot

Keep it, but demote it. A reputation score is a weak prior about an address, assembled largely from lookups and history, disagreed on by every vendor that sells one. Act on it when a fraud engine is demonstrably in your path. Do not act on it because a dial went red.

The measurement that survives scrutiny is dull: request your real endpoint through the proxy, read the body and not just the status line, count how often you got the data you came for. If that number is healthy, the score was noise. If it is not, you have a failure you can reproduce — a far better starting point than a percentage from a database that has never seen your traffic. The troubleshooting guide covers the common causes, and if you have run the test above and the result still does not make sense, send us the command and the output and we will look at it with you.