CaptchaAI
Same Token, Different IP, Different Answer.
Some targets score the address a challenge is solved from. Fetch the token from a datacentre range and it fails; fetch the same token through the network your session already uses and it passes. CaptchaAI accepts `proxy` and `proxytype` per task, so the solve can share your request's context — and this page is equally about when that is a waste of latency.
Deciding whether you need it
Four checks, in the order worth doing them.
First, confirm the IP is actually the variable
Change one thing at a time. If the same task succeeds from one network and fails from another with everything else identical, address reputation is in play. If it fails everywhere, the problem is the challenge type or your parameters, and a proxy will only add latency.
Match the type to the sensitivity
Score-based challenges — reCAPTCHA v3, Turnstile, Cloudflare Challenge — weigh context most heavily. A plain image or grid CAPTCHA is a recognition task and is far less interested in where the answer came from.
Pass it per task, not globally
`proxy` and `proxytype` are task parameters, so you can route only the tasks that need it. Everything else takes the default path and stays fast.
Budget the added latency
A proxied solve adds a hop. Against a published band of under 4 seconds for reCAPTCHA v3 or up to 60 seconds for v2, that matters differently — set the timeout from the band for the type you are actually solving.
A challenge is not only judging the answer
Score-based challenges weigh signals around the request as well as the response: address reputation, whether the range is residential or datacentre, and whether the context is consistent. A token minted from somewhere unrelated to the rest of your session is a mismatch the target can see.
- Address reputation is a scored signal, not a gate
- Datacentre ranges carry different weight from residential
- Consistency across the session is itself a signal
- Applies mainly to score-based types, not simple image solving
Using proxies responsibly
The technique is neutral; what it is pointed at is not.
Only against systems you own or may test
Routing a solve through a different address does not create permission. This page assumes your own application, or a system you are authorised to test.
Respect robots.txt, rate limits and terms
A proxy changes where load appears to come from, not whether it is welcome. Published limits stay the constraint.
Not a route around authentication
A CAPTCHA is a bot check, not an auth check. Nothing here helps with credentials, payment authorisation or account access, and should not be used to try.
Consistency beats volume
Rotating aggressively through unrelated addresses usually reads as less trustworthy, not more. Matching the session's real context is the point.
Per-task
Set proxy and proxytype on the individual task
No surcharge
Published plans add no fee by type or option
Same codes
Documented error semantics are unchanged
Published bands
Latency figures per type to budget against
Three things that fix this more often than proxies do
Address reputation gets blamed for failures it did not cause. These are cheaper, faster and more often the real answer.
- Wrong or stale sitekey / pageurl parameters
- Polling faster than the documented ~5 second cadence
- Treating CAPCHA_NOT_READY as a failure and resubmitting
- A timeout set below the published band for that type
Why this way
The practical case, in four lines.
Selective, not architectural
A task parameter means you can route the few tasks that need it without redesigning anything.
No pricing consequence
Thread-based plans carry no surcharge by type or option, so this does not change the bill.
Diagnosis before machinery
The page tells you how to confirm the IP is the variable before you add a hop you may not need.
Unchanged error semantics
The documented codes behave the same, so your existing retry logic still applies.
Common questions
- Do I always need a proxy?
- No, and most workloads do not. It matters when the target scores the address the solve comes from — mainly score-based challenges. Confirm that is your problem first.
- How do I pass one?
- As task parameters: `proxy` and `proxytype` on the submission to in.php, alongside the type-specific fields.
- Does it cost extra?
- The published plans state no surcharges by type, and thread-based pricing carries no per-CAPTCHA fee, so it runs on the plan you already have.
- Will it slow things down?
- It adds a hop, so yes, somewhat. Budget it against the published latency band for the type you are solving rather than a single global timeout.
- Is rotating lots of addresses better?
- Usually not. Consistency with the rest of your session tends to read as more trustworthy than rapid rotation through unrelated ranges.
Not sure whether the IP is your problem?
Route the tasks that need it
Per-task proxy support on the same endpoint, the same error codes and the same plan.