Why proxies trigger captchas, and what reduces them

Why proxies trigger captchas comes down to a risk score. A captcha is the action a site takes when a request’s risk score falls below its threshold. The proxy supplies the IP inputs to that score: the ASN class, the shared history of the address and how many requests it carries. The client supplies the rest: pace, cookies, the TLS stack, the browser checks and the locale.

That split explains why proxies trigger captchas on one setup and not on another with the same pool. The ticket reads “too many captchas, the proxy is bad”, and the next step is another pool. Most pages that rank for this problem end in a solver. This post covers no solving and no way around a challenge. It separates the inputs, so a legitimate client can fix its own before it looks at a different tier.

Why proxies trigger captchas

A captcha is a policy action taken on a score, and each site writes its own policy.

How the challenge decision works

The score. Google’s reCAPTCHA v3 documentation (updated July 2024) returns a score for every request, where 1.0 is very likely a good interaction and 0.0 is very likely a bot, and suggests 0.5 as a starting threshold. The same page says reCAPTCHA learns from the real traffic on each site, so staging and production score differently. The site owner decides what happens under the threshold: a checkbox, a second factor or a block.

The challenge. Cloudflare’s Turnstile documentation (updated August 2026) lists what runs behind its widget: proof-of-work, proof-of-space, probing for web APIs, and checks for browser quirks and human behaviour. In managed mode Turnstile picks between a non-interactive check and a checkbox based on the visitor’s risk. So a visible challenge means the invisible checks did not settle the question.

The threshold is local. Every site sets its own threshold and its own action. No honest “requests before a captcha” figure exists across sites, and a page that prints one is describing one target on one day.

The IP-side signals

Three inputs to the score are tied to the address, so they change with the proxy, the same IP layer covered in how websites detect proxies. A fourth depends on whether the proxy announces itself.

Shared history. A proxy IP has been used before, by someone else, for something else. Google’s unusual traffic help page (checked September 2026) says the message can appear when a network seems to be sending automated traffic, and it names shared networks, VPNs and other customers of the same internet provider among the causes. Every proxy pool is a shared network in that sense.

ASN class. Hosting ranges read as servers. Consumer ISP ranges read as homes. Carrier ranges read as phones, usually behind carrier-grade NAT, where hundreds of subscribers can share one of those addresses.

Concentration. Many requests from one address in a short window look like one machine. That holds on every tier.

Forwarding headers. A proxy that adds Via, X-Forwarded-For or Forwarded tells the site it is a proxy before any score runs. We checked our own per-GB gateway on 28 September 2026: over CONNECT it added no Via or Forwarded header. To an https:// site a CONNECT proxy only relays encrypted bytes, so it cannot add any header to the request. Headers the client itself sends still pass through, so a script that sets X-Forwarded-For announces the proxy on its own.

Proxy inputs vs client inputs

The table maps each input to who controls it.

The proxy tier owns the first two rows and shares two more. The TLS fingerprint, the cookies and the browser checks belong to the client on any IP. A CONNECT tunnel relays the TLS bytes as they are, so the handshake the site reads is the client’s, whichever exit carries it.

Read the challenge you got

The kind of challenge is a clue to which row fired.

• A block page with no challenge, such as an HTTP 403, an access denied page or a proxy detected error, usually means a rule rather than a score: an IP range, a country or an ASN the site refuses. A block page is the site saying no to that traffic. Stop, and check its terms, its API, or ask for access.
• A check that clears on its own means the score was borderline and the browser passed the in-page tests. Nothing is broken; the setup sits near the threshold.
• A checkbox or puzzle on every page means the client is not keeping what the last pass earned, or its score drops again after each pass. Look at cookies and pace before the pool.
• A challenge only after a run of pages is behavioural. The session crossed a rate the site treats as automated, whatever the IP.

The widget itself says which system is scoring:

• reCAPTCHA v2 shows the “I’m not a robot” checkbox and, when the risk looks higher, an image grid to click through.
• reCAPTCHA v3 shows no challenge, only a small badge. It hands the site a score, and the site decides what to do with it.
• hCaptcha works like the v2 checkbox, with image challenges when the risk looks higher.
• Turnstile usually passes without any interaction and falls back to a checkbox when the risk looks higher.

What each proxy tier changes

Tier choice is the part of the problem a proxy can change, and only that part. Each tier moves the first rows of the table differently, and none of them rescues a client that fails the rest.

Datacenter. Datacenter proxies exit from hosting ASNs. On sites with a challenge provider in front of forms, search or checkout, that alone often decides the score, so challenges arrive early. On lenient targets with no provider in front, datacenter works and is usually the fastest tier; datacenter vs residential proxies covers testing a target before choosing.

Rotating residential. Rotating residential proxies exit from consumer ISP ranges, which removes the hosting signal. The shared history stays: the address may have carried someone else’s traffic an hour ago. That, plus the rotation cost covered below, is the usual story behind a residential proxy captcha.

Static ISP. Static ISP proxies hold one ISP-registered address for the whole billing term. That suits logged-in flows on accounts you own, where a stable history helps. But a fixed set of addresses concentrates volume, so a job that hammers a few IPs builds its own bad history; keep each address at a pace a real user could produce. Check a new static IP against the target at low volume before loading it.

Mobile. Carrier IPs sit behind CGNAT, where many real subscribers share one public address, so a hard block on it hits real customers. Sites read the class from IP databases, and our mobile per-GB exits are classified as cellular by MaxMind. That is why challenges tend to be rarer on platforms that expect phone traffic. The rate is not zero: Google names other customers of the same internet provider as one cause of its unusual traffic message, and a carrier address is exactly that.

None of the four tiers touches the client rows of the first table.

What the client controls

This is the half no proxy upgrade touches, and the half where a legitimate client has the most room to cut its challenge rate.

Session consistency and clearance cookies

Cloudflare’s Challenge Passage documentation (updated May 2026) says a solved challenge sets a cf_clearance cookie, and the visitor does not face repeat challenges while it is valid. The default lifetime is 30 minutes, Cloudflare recommends 15 to 45, and the site owner sets the value, so 30 minutes is only the default.

A client that discards cookies throws that pass away and meets the next challenge on the next request. Rotation does the same at the IP layer. A session that hops addresses mid-flow loses the history it built, and consistency is part of what the score reads.

Pacing and locale

Pace. Set a request rate per session that the target’s own users could produce. Spreading requests across many IPs does not hide a per-session rate that no person reaches.

Locale. Pick the exit country, region or city for the market the job is about, and set Accept-Language to the market whose pages the job needs, so the site serves the right locale.

TLS stack and browser checks

The TLS fingerprint. A script library behind a browser User-Agent is a mismatch on every tier, because the handshake passes through the proxy tunnel unchanged. Send an honest User-Agent that matches the library, or run a real browser.

The browser. Turnstile’s checks run JavaScript and probe web APIs. A client without a real JavaScript engine fails them by design, whatever the IP. Where a job needs pages behind those checks, a real browser engine is the honest client.

Captchas everywhere, even without a proxy

Plenty of people who ask why they are suddenly getting captchas on every site have no proxy in the path at all. Google’s unusual traffic help page (checked September 2026) lists the usual causes: malware on the machine sending automated requests, a shared network such as a school or office, a VPN, an IPv6 tunnel service, other customers of the same internet provider, and tools such as rank checkers and scrapers.

The same list explains Google’s “unusual traffic from your computer network” message. In Google’s own words, “search scrapers” and rank-checking software count as the automated traffic behind it, so a better proxy does not make scraping Google acceptable. It only changes where the traffic comes from.

The fixes involve no proxy upgrade. Scan the machine for malware. Switch off the VPN and reload. On a shared network, ask the network admin; on a home line, ask the ISP whether the address is shared. If the challenges stop, the cause was the machine or the network.

When a captcha means stop

Some challenges are a score that a better client clears. Others are the site saying no to automated access. Logins, checkout limits and search pages often sit in the second group, and a site that challenges every automated request there is stating a policy about automated access.

The answer there is the site’s official API, a data licence, or slower access that the site’s terms allow. Getting around a challenge usually breaks those terms, and depending on the country and the target it can create legal exposure too.

Fix it in order, simplest first

Measure first, with a test any reader can run in an afternoon, then work down the list.

Measure your captcha rate first

1. Use a page you control. Put reCAPTCHA v3 or Turnstile on a test page on a domain you own. reCAPTCHA v3 returns a score for every request, which gives a number rather than a pass or fail, and the test stays on a site you own instead of someone else’s.
2. Fix everything but the tier. Same browser client (headless is fine), same headers, same pace, for example one request every few seconds per IP. reCAPTCHA v3 and Turnstile only return a token when the page’s JavaScript runs, so a client that runs no JavaScript records “no token”, not a score.
3. Run 100 requests per tier. Record the score distribution, or the number of interactive challenges per 100 requests.
4. Then change one client input. In the same browser, keep cookies between requests where the first run dropped them, and run the best tier again.

If the counts barely move between tiers but move a lot when the client changes, the problem is the client. A fresh test domain will not score like a busy production site, because reCAPTCHA learns per site, so read the results as relative movement, not absolutes.

Then work down the list

1. Rule out the client. A client that meets challenges from an office or home connection with no proxy needs fixing first: pace, cookies, User-Agent, a real browser. A proxy change will not fix this.
2. Check the ASN. Challenges that start only through a datacenter exit mean the ASN is deciding, and datacenter does not fit that target. Rotating residential fits public catalogue and listing pages whose terms allow automated access.
3. Hold the session. Challenges that rise with per-request rotation call for a sticky session or a 5 to 60 minute timer, with the cookies kept; rotating vs sticky proxies covers which mode fits which flow.
4. Hold one address. A logged-in flow that keeps getting challenged on changing IPs needs one address, held on a static ISP proxy.
5. Match the origin. Where the platform expects phone traffic, use mobile proxies. They are built for the targets where the mobile origin matters.
6. Stop. When the site challenges every automated request whatever the setup, stop and use its API, or ask.

A different tier changes only the IP rows of the score; the client rows stay with whoever writes the client.