Anti-Bot Detection in 2026: Why Rotating IPs Is No Longer Enough

The defining change in bot detection is not that it got stricter. It is that it stopped depending on the IP address. Cloudflare's current bot management model classifies residential proxy traffic on a per-request basis — combining network latency signatures with behavioural features — precisely so it can avoid blocklisting IPs. That means a clean, never-flagged residential IP can still be identified as proxied, and rotating to another one does not help.

If your success rate has been falling while your proxy quality has not changed, this is why. Below is what actually happens now, sourced where possible to the people building the detection rather than the people selling proxies.

What changed: detection moved down the stack

Detection used to be a lookup. Is this IP in a datacenter range? Is it on a known proxy list? Has it made too many requests? All three are properties of the address, and all three are defeated by rotating addresses. That is what rotating proxies were invented for and they still work for that.

The problem is that the address is now one of the weaker signals.

In Cloudflare's own account of their v8 bot management model, the team describes analysing an average of over 46 million HTTP requests per second and building features in three categories:

• Global features — aggregates computed across their network for things like an entire ASN
• High-cardinality features — fine-grained aggregates for individual IP addresses
• Single-request features — properties derived from one request in isolation, such as the user agent

That third category is the important one. A single-request feature does not care how many addresses you have. It evaluates the request in front of it.

The latency signature

The most interesting detail in Cloudflare's write-up is also the most obvious in hindsight.

A proxied request has to traverse more hops than a direct one. Cloudflare found they could characterise residential proxy traffic "with a high true positive rate" on that basis alone — proxied requests are measurably slower than direct ones from the same network.

They did not ship it as a standalone rule, and the reason is instructive: regions that rely on satellite internet show high latency for most of their traffic, which produced false positives. So latency became one input to a model rather than a rule in itself.

The practical implication for anyone using proxies: the extra hop is physically detectable and you cannot remove it. You can reduce it — an exit geographically near the target shortens the added path — but the signal exists by construction. This is a genuine structural limit, and no provider can sell you around it.

Behavioural signals, and why blocklisting stopped

The second half of Cloudflare's approach looks at how IPs behave rather than where they are.

Residential proxy exit nodes are ephemeral. The node exists while the software hosting it is running, and leaves the network when the user closes the browser or app. That produces a distinctive pattern: bursts of activity during peak periods, separated by inactivity.

But Cloudflare explicitly rejected blocklisting on that basis, and the number they give is the most useful figure in the whole piece for legitimate proxy users:

Overall, we see that 4 out of 5 requests from these networks belong to direct and benign connections from residential devices.

Four in five requests from an IP showing proxy activity are just a real person browsing, because the proxy software is running on their machine alongside their own traffic. Blocking the address blocks the household. Cloudflare's stated design goal is to "block residential proxy traffic while allowing benign residential users to visit Cloudflare-protected websites from the same residential network."

So the direction of travel is per-request classification, not address reputation. For legitimate use that is partly good news — you are less likely to be collaterally banned for sharing a subnet with an abuser. It also means a pristine IP buys you less than it used to.

The scale they report: v8 classifies more than 17 million unique IPs per hour as participating in residential proxy attacks, across more than 45,000 ASNs in 237 countries and regions. The most requested endpoints are /login, /auth/login and /api/login — account takeover attempts. That is the traffic the models are trained against, and it is the company your requests are keeping.

Fingerprinting: the layer most scrapers fail

If the IP is not what is getting you blocked, this usually is.

TLS fingerprinting. Every TLS client announces which cipher suites it supports, which extensions it sends, and in what order. Those choices differ between implementations, so the handshake alone distinguishes a Chrome build from a Python library from a Go client. JA3 and its successor JA4 are the standard formats for encoding that fingerprint. The consequence is blunt: a request from a scripting library can be classified before a single header is inspected, because the handshake happens first.

TCP/IP fingerprinting. Initial window size, TTL, and TCP option ordering vary by operating system. A handshake claiming to be Safari on macOS from a stack that behaves like Linux is a contradiction.

HTTP/2 and HTTP/3 behaviour. Frame ordering, header compression choices, and stream priorities differ between real browsers and libraries. Real browsers increasingly negotiate QUIC by default, so a client that only ever speaks HTTP/1.1 over TCP looks progressively less like a browser as adoption rises. (UDP and QUIC support in residential proxies covers what that requires from a provider.)

Browser fingerprinting. Canvas, WebGL, fonts, screen metrics, timezone, language. Covered in more depth in browser fingerprinting trends.

Behavioural timing. Filling a form in 80 milliseconds, moving a cursor in a perfect straight line, or clicking with zero dwell time are all outside human range.

Consistency beats quality

Here is the shift that matters most in practice, and it is not about buying better IPs.

Detection increasingly evaluates whether your layers agree with each other. Consider two requests:

	Request A	Request B
Exit IP	Premium residential, Germany	Plain datacenter, Germany
Browser locale	en-US	de-DE
Timezone	America/New_York	Europe/Berlin
TLS fingerprint	Python requests	Real Chrome
Accept-Language	en-US	de-DE,de;q=0.9

Request A has the better IP and is the more obvious automation. Every layer contradicts every other layer. Request B is internally coherent.

Spending more on IP quality while leaving the rest inconsistent is the most common way to waste proxy budget. If you are getting blocked on premium residential IPs, the IP is probably not the problem.

What this means for how you work

Six things follow, in rough order of impact.

1. Match the stack to the exit. Locale, timezone, Accept-Language and currency should agree with the country you are exiting from. This is free and it is the highest-leverage change most teams have not made.

2. Use a real browser for hard targets. Raw HTTP libraries lose on TLS fingerprint before anything else is evaluated. A real browser engine produces a real handshake. See Playwright and Puppeteer configuration.

3. Pace requests, do not just distribute them. Rotation spreads load across addresses; it does not reduce the load the target sees. Five hundred requests per second across a thousand IPs is still five hundred requests per second arriving. Proxy rotation strategies covers the distinction.

4. Shorten the network path. You cannot remove the proxy hop, but you can make it shorter by exiting near the target rather than near yourself. How to choose the fastest residential proxies covers what determines this.

5. Hold sessions where state exists. Rotating mid-session is itself a signal — it looks like session hijacking. Sticky sessions exist for this.

6. Detect challenge pages, do not just check status codes. A CAPTCHA served with HTTP 200 is a successful request containing no data. Pipelines that check only status codes silently ingest challenge pages, and anything downstream — especially an AI agent — will treat them as content.

The sourcing question

One detail in Cloudflare's post deserves separating out, because it is uncomfortable and relevant.

Describing how these networks are built, they write that IPs are "most commonly sourced by partnering with free VPN providers, as well as including the proxy SDKs into popular browser extensions and mobile applications," and that this "allows residential proxy providers to gain a foothold on victims' devices."

The word "victims" is theirs, and the criticism lands. A network assembled that way is built on connections whose owners did not meaningfully consent, and it also carries more abusive traffic — which is what trains the models that then classify your requests.

So sourcing is both an ethical question and a practical one. When evaluating any provider, including this one, ask directly: where do the IPs come from, what were the node operators told, and were they compensated? A provider that cannot answer clearly is telling you something. This is a question buyers should put to vendors rather than take on trust from a vendor's own blog — including this post.

What has not changed

Detection is adversarial, and it is worth being accurate about the limits rather than alarmist:

• Residential IPs still outperform datacenter IPs on protected targets. The gap narrowed; it did not close.
• Most of the web does not run sophisticated detection. These techniques are concentrated behind major edge platforms. A great deal of legitimate collection still works with plain rotation.
• Rotation still defeats what it always defeated — IP rate limiting and IP reputation. Those mechanisms did not disappear.
• Per-request classification cuts both ways. Because blanket IP blocking creates false positives, providers of detection are actively avoiding it, which reduces collateral damage to legitimate users on shared residential ranges.

The accurate summary is that the IP layer became table stakes rather than the deciding factor. You still need good IPs. You now also need everything behind them to be consistent, paced and shaped like a real client — and no proxy purchase substitutes for that.

For the provider-side requirements this implies — protocol support, geographic granularity, session control — see how to choose a proxy provider, and anti-bot technology trends for the longer arc of how these systems developed.

Frequently asked questions

How do websites detect residential proxies?

Not primarily by IP reputation any more. Cloudflare's published approach combines network latency signals — proxied requests traverse extra hops, so they are measurably slower — with behavioural features computed per IP and per request, then classifies each individual request rather than blocklisting the address. That shift matters because it means a clean, never-flagged residential IP can still be identified as proxied.

Why do websites not just block residential proxy IPs?

Because most traffic from those addresses is legitimate. Cloudflare reports that roughly four out of five requests from IPs showing residential proxy activity are ordinary direct connections from real residential devices, since the proxy software usually runs on a consumer's machine alongside their normal browsing. Blocklisting the address would block the household.

Does rotating IPs still work against anti-bot systems?

Rotation defeats IP-based rate limiting and IP reputation, which is what it was always for. It does not defeat per-request classification, TLS fingerprinting, or behavioural analysis, because those signals travel with every request regardless of which address it comes from. Rotation is necessary and no longer sufficient.

What is TLS fingerprinting?

A method of identifying a client from the structure of its TLS handshake — the cipher suites it offers, the extensions it sends, and the order they appear in. Different HTTP libraries and browsers produce distinctly different handshakes, so a request can be classified as coming from a scripting library rather than a browser before any header or page content is examined. JA3 and its successor JA4 are the common fingerprint formats.

Why does my scraper get blocked even with good residential proxies?

Because the IP is one signal among several and probably not the one failing. Common culprits are a TLS fingerprint that identifies your HTTP library, a browser fingerprint inconsistent with the exit country, request timing no human could produce, and request rates that stay aggressive across a rotating pool. The proxy fixes the address; it cannot fix the other layers.

What does consistency mean in anti-bot terms?

That every layer of your request agrees with every other. A German exit IP paired with a US English browser locale, a New York timezone, and a TLS fingerprint belonging to a Python library is a set of contradictions. A plain datacenter IP with a coherent browser profile behind it frequently performs better than a premium residential IP with a contradictory one.

How should I evaluate a proxy provider's IP sourcing?

Ask directly how the IPs are obtained and whether the people whose connections are used gave informed consent. Cloudflare notes that proxy networks are commonly built by bundling proxy SDKs into browser extensions and mobile apps, which gains a foothold on a device without meaningful consent. Sourcing is both an ethical question and a practical one, because networks built that way carry more abusive traffic and therefore attract more detection.