Originally published on proxymint.
Why proxies trigger captchas: the risk score behind each challenge, the inputs your proxy tier changes, and what a legitimate client can fix first.
TL;DR
- A captcha is a policy action on a risk score. reCAPTCHA v3 scores each request from 0.0 to 1.0 with 0.5 as a suggested starting threshold, and each site owner decides what happens below it.
- The proxy supplies the IP inputs. ASN class, the shared history of the address and how many requests it carries all come from the proxy tier.
- The client supplies the rest. Pace, cookies, the TLS stack, the browser checks and the locale belong to the client on every tier.
- Per-request rotation can raise the challenge rate. Each new address starts without the session history the last one built, so multi-page flows often do better on a sticky session.
- Some captchas mean stop. When a site challenges every automated request on logins, checkout or search, the answer is its API, a data licence or slower permitted access, not another pool.
Key takeaways
- Measure before switching tiers. Put reCAPTCHA v3 or Turnstile on a page on a domain you own, record 100 requests per tier at a fixed pace, then change one client input and repeat.
- Keep clearance cookies. Cloudflare's cf_clearance cookie lasts 30 minutes by default and Cloudflare recommends 15 to 45; a client that drops it meets the next challenge sooner.
- Use sticky sessions for multi-page flows. A 5 to 60 minute timer or a sticky session keeps the history that per-request rotation throws away.
- Ask for the market's language. Set Accept-Language to the market whose pages the job needs, so the site serves the right locale.
- Use mobile where the mobile origin matters. Carrier IPs are built for platforms that expect phone traffic; residential covers most other targets.
Read the full guide on proxymint, with the commands, tables and sources.
Top comments (0)