How an IP address earns and loses reputation with anti-bot systems

Three weeks ago a Playwright fleet we run started getting reCAPTCHA challenges on a login flow that had been clean for months. Nothing in the code changed. The proxy provider hadn’t changed. What changed was upstream and invisible: the /24 our exit IPs sat in had picked up a run of bad traffic from someone else entirely, and Google’s risk engine folded that into our score before we ever saw a checkbox.

This is the part people miss when they talk about anti-bot systems. An IP address has no reputation of its own, the way a person has no credit score until a bureau starts tracking them. Reputation is assigned, separately, by each vendor watching the traffic, from a mix of who else has used that address, what network it sits in, and how the traffic behaves once it arrives. Cloudflare has one view of your IP. Akamai has another. Your own risk engine, if you run one, has a third. None of them talk to each other, and none of them forget quickly.

This piece is about the mechanism, not about getting around it. If you’re running browser or phone agents against your own properties or with the site’s terms in mind, understanding how the scoring actually works is the difference between building something that survives contact with production and something that burns through a proxy budget in a week. We cover a lot of the adjacent ground across the blog; this is the deep dive on just the IP side of it.

background and prior art

IP reputation didn’t start with bot management. It started with email. Real-time blackhole lists in the late 1990s tracked which mail servers sent spam, and receiving servers queried those lists before accepting a connection. The web version of the same idea showed up once CDNs sat in front of enough traffic to spot patterns across their whole customer base instead of one site’s logs. Cloudflare, Akamai, and later DataDome and HUMAN (formerly PerimeterX) built the same trick into HTTP: a single client hitting one site looks normal in isolation, but a CDN with line of sight into millions of sites can see that the same source IP misbehaved somewhere else five minutes ago.

The modern version is public enough to study without an NDA. Cloudflare documents a bot score from 1 to 99, generated per request from machine-learning models, known bot signatures, and heuristics. AWS ships an IP reputation managed rule group inside WAF that leans on Amazon’s own threat intelligence feed. Neither vendor claims the IP address alone tells the whole story, and that’s the important bit. Reputation has always been a composite, IP plus network plus behavior, going back to when a mail server’s history was already standing in for the humans sending through it.

the core mechanism

Break an IP’s standing down into the signals a vendor actually has available, because that’s what determines what you can and can’t influence.

Network layer comes first: what ASN does this address belong to, and does that ASN map to a hosting provider, a mobile carrier, a residential ISP, or a known VPN or proxy network. This part is close to binary in a lot of systems. AWS, Google Cloud, Azure, and every other hosting provider publish their own CIDR ranges. AWS’s lives at ip-ranges.json and updates continuously. Any site operator can pull that file, tag every address inside it as datacenter, and apply default friction, a CAPTCHA, a JS proof-of-work, a slower rate limit, before a single request from you has landed. You don’t need machine learning to block EC2 by default. You need one JSON file and a cron job:

curl -s https://ip-ranges.amazonaws.com/ip-ranges.json \
  | jq '.prefixes[] | select(.ip_prefix=="203.0.113.0/24")'

If that query returns a match, you’re inside a documented AWS range, and a meaningful share of anti-bot vendors will treat you as datacenter traffic by default, independent of behavior.

Mobile and carrier-grade NAT sit on the opposite end. A single carrier gateway address is shared by hundreds or thousands of subscribers at once, a documented consequence of address conservation described in RFC 6598, which reserved the 100.64.0.0/10 block specifically for carrier-grade NAT so ISPs could keep NATing IPv4 space internally without colliding with private ranges. The practical effect on reputation: a mobile ASN’s traffic is inherently noisy by design, many different people showing up from the same handful of exit addresses within minutes of each other, and a system that penalized that pattern the way it penalizes a datacenter would end up blocking a large share of the mobile internet. So serious anti-bot vendors weight mobile and carrier traffic differently. MaxMind’s minFraud documentation treats network type as one input among several rather than an instant disqualifier, precisely because “many behavioral fingerprints, one exit IP” is baseline behavior on mobile, not an anomaly.

Behavioral and session signals sit on top of network identity, and this is what actually decides most borderline cases. TLS fingerprint (the JA3/JA4 hash of the handshake), HTTP/2 header ordering, cookie continuity, timing between requests. Network identity alone produces too many false positives, blocking every mobile user, and too many false negatives, since any residential IP looks clean by network type alone. A session that keeps the same TLS fingerprint, the same cookie jar, and a request cadence that isn’t perfectly uniform reads as one continuous human or agent doing one continuous task. A session where the IP is stable but the TLS fingerprint changes mid-flow, or the cookie resets every few requests, reads as a pool of workers behind a load balancer pretending to be one visitor. We’ve written more on the wider set of causes behind why AI browser agents get blocked that go beyond the network layer entirely.

Reputation also inherits, which is the part that surprises people who’ve only read the marketing pages. If your IP, or your /24, or your ASN, recently sent bad traffic to any customer on a shared vendor’s network, not just yours, that history follows the address to your property too. It’s the same mechanism as an email blackhole list: the receiving server doesn’t need to have seen your spam personally, it just needs another server on the same list to have seen it first. This is why a cheap shared datacenter proxy can arrive pre-burned, someone else ran a credential-stuffing job through the same /24 last week, and you inherit the tail end of that history the moment you route through it.

None of this is permanent.

Every vendor that publishes anything on the topic describes reputation as continuously recalculated rather than a one-time verdict. Cloudflare’s bot score is generated fresh per request, not cached against a static list. AWS’s managed reputation lists refresh on Amazon’s own intelligence cadence rather than a fixed schedule, so an address that goes quiet and clean for a while does climb back. The catch is that nobody publishes the actual half-life. I’ve watched addresses recover in under a day and I’ve watched others sit under friction for weeks with identical clean behavior, and the honest answer is I don’t have a clean model for why, and neither, as far as I can tell, does anyone selling proxies.

worked examples

Take a team running synthetic uptime checks against their own production checkout flow, a Playwright agent hitting their own site every few minutes from a fleet of EC2 instances, entirely first-party monitoring. If that same team has AWS’s managed IP reputation rule group turned on in front of their own WAF, a common default in a lot of AWS reference architectures, the checks start failing not because the checkout flow broke, but because the WAF is tagging its own monitoring traffic as datacenter-sourced and challenging it before request behavior is even evaluated. Nothing about the monitor’s behavior mattered. The network layer decided the outcome before behavior was measured at all. Moving the monitor onto a non-hosting-provider network doesn’t make the traffic any more legitimate than it already was, it just removes an instant network-layer penalty that had nothing to do with legitimacy in the first place.

Second example: an agent completing a multi-step signup flow on your own product, one that’s gated behind SMS verification for Singapore numbers only, running from a Singapore mobile IP. The network layer isn’t the problem here, mobile ASNs get more behavioral latitude than datacenter ones for the RFC 6598 reason above. The failure mode is almost always session-level: an agent that grabs a new mobile IP every few requests inside one task looks like several different customers picking up and abandoning the same session mid-flow, which is closer to the fraud pattern, credential stuffing, card testing, that mobile-aware risk engines are actually tuned to catch. Holding one sticky IP for the length of a task, then rotating between tasks, matches how an actual phone behaves on an actual network far better than rotating on every request. This is the specific problem a service like Singapore Mobile Proxy is built around: real Singapore mobile carrier IPs with sessions that stay sticky for the length of a task instead of hopping on every request. It only helps if Singapore is the geography your task actually needs, since both the IPs and the sticky sessions are SG-only, so it’s not a general fix for session churn, just the specific case where the exit network is already the right one.

Third example, and this one is about the site’s own history rather than the visiting IP’s. A domain that has previously served a lot of automated traffic can start scoring incoming agents lower by default, independent of which IP shows up. Cloudflare’s documentation on the bot score describes it as generated fresh per request from models trained partly on that property’s own traffic history. If a domain has previously been a scraping target, or previously hosted a checkout-abuse campaign, the threshold for what counts as suspicious enough to challenge can sit lower there than on a domain with a quiet history. Two identical agent requests, same IP, same headers, same timing, can get different treatment depending purely on which domain they land on. I’ve seen this most clearly running the same script against a client’s staging environment, quiet history, sailed through, and their production domain, a magnet for scraper traffic for years, challenged on page two.

edge cases and failure modes

Rotating IP mid-session is the one I see most often. Grabbing a new proxy IP on every single request inside one logical task breaks cookie-to-IP continuity and TLS session resumption, and to a risk engine that’s not stealthier, it’s the single clearest signature of a distributed credential-stuffing pool. Rotate at task boundaries, not mid-flow.

Buying a proxy pool without checking its provenance is the second. Cheap shared datacenter and “residential” pools get resold constantly, and a meaningful share of that inventory is pre-burned before you ever route through it, because someone before you already ran abusive traffic through the same addresses. Check what you’re buying against a reputation lookup service like Spur or IPQualityScore before committing real budget, not after your first run gets challenged.

Trusting the word “residential” without asking how the network was built. Some residential proxy networks are built from consumer SDKs bundled into free apps, where the person whose phone became an exit node never meaningfully agreed to resell their bandwidth. The 2015 Hola VPN affair, where a free browser extension quietly turned installs into paid exit nodes, is still the case most people in this space reference. Aside from the ethics, that kind of sourcing is also operationally unstable, since the address behind your request can vanish the moment that consumer closes their laptop. If a seller can’t or won’t explain in plain terms where the IPs come from, that’s the answer.

Matching browser fingerprint to network identity, but not both to behavior, is a subtler one. Swap the browser binary your fleet runs, see our comparison of Chrome for Testing and open-source Chromium for what actually changes under the hood, without also matching timing and interaction patterns to whatever that binary implies about the client, and you’ve fixed one mismatch while leaving another. A residential IP paired with a stock automation-flavored TLS fingerprint is still a mismatch, just a quieter one than a datacenter IP with the same fingerprint.

Treating a brand-new IP as safe because it’s unflagged is the last one, and it’s the easiest to get wrong. Clean and trusted aren’t the same thing. An address with zero history isn’t on anyone’s blocklist, but it also hasn’t earned the latitude a long-lived, low-incident address gets, so new IPs commonly face default friction purely for being unknown. Warming an IP up with a period of low-volume, human-paced traffic before ramping a real workload through it tends to help more than starting at full throughput on day one, though nobody publishes exactly how long “warmed up” takes.

what we learned in production

I’ll say the unpopular thing first: chasing IP diversity is usually the wrong first fix. Most flagged fleets we’ve looked at had a session-consistency bug, not a network problem, and people reach for more proxies because it’s the easiest thing to buy, not because it’s the actual fix. The single biggest lever we’ve found running agent fleets day to day is session hygiene, one identity (IP, TLS fingerprint, cookie jar) held steady for the length of one task, rotated cleanly between tasks, logged well enough that when something gets flagged you can tell whether it was the network, the session, or the target site’s own history. If you’re running this at any scale, wiring up basic observability, traces and replays on what your agents actually sent and when they got challenged, catches this faster than staring at aggregate dashboards. The browser agent production checklist covers the header and session side of this in more depth; this piece is the network-reputation half of the same problem.

What I still don’t have a good answer for is decay timing. I can tell you an IP recovered. I can’t reliably tell you why it took four hours in one case and three weeks in another, and I’m suspicious of anyone who claims they can, since none of the vendors publish that number either.

references and further reading

• Cloudflare’s bot score docs explain how a per-request score from 1 to 99 gets generated, about as close as anyone gets to a public spec of a modern anti-bot signal blend: https://developers.cloudflare.com/bots/concepts/bot-score/
• AWS’s IP address ranges documentation is the actual source anti-bot systems and site operators pull from to tag datacenter traffic instantly: https://docs.aws.amazon.com/vpc/latest/userguide/aws-ip-ranges.html
• RFC 6598 is the protocol document behind carrier-grade NAT, worth reading if you want to understand why mobile ASNs behave the way they do: https://www.rfc-editor.org/rfc/rfc6598
• MaxMind’s minFraud documentation shows how network type gets folded into a broader risk score instead of used as a standalone signal: https://dev.maxmind.com/minfraud

Written by Xavier Fok

disclosure: this article may contain affiliate links. if you buy through them we may earn a commission at no extra cost to you. verdicts are independent of payouts. last reviewed by Xavier Fok on 2026-09-15.