Proxy vs proxyless captcha solving - which task type do you need?
Scarnox offers PopularCaptcha in two flavours: proxyless, where Scarnox solves the captcha over its own network, and a proxy variant, where you send the proxy your bot uses. Both return a token in the same response shape, and both are free when a solve fails. The only difference in the request is the proxy.
Proxyless is the right starting point for most sites. Send your own proxy only when the site ties the token to an IP address.
The two task types
| Task type | What you send |
|---|---|
PopularCaptchaTaskProxyless | sitekey and page URL |
PopularCaptchaTask (proxy variant) | sitekey, page URL and your proxy |
Both are PopularCaptcha tasks. The rest of the request, the response and the token handling are the same.
Start with proxyless
Proxyless solves run on Scarnox's own network. The integration is the simplest one you can write, and for most sites the token works no matter which IP later submits it. If you are not sure which one you need, start here:
{
"captcha_type": "PopularCaptchaTaskProxyless",
"site_key": "10000000-ffff-ffff-ffff-000000000001",
"site_url": "https://example.com/signup"
}Send a proxy when the token is tied to an IP
Some sites check that the IP which solved the captcha is the same IP that submits the form. The symptom is clear: tokens come back without errors, but the site rejects them every time. The fix is to solve through the same proxy your bot uses for the rest of the session:
{
"captcha_type": "PopularCaptchaTask",
"site_key": "10000000-ffff-ffff-ffff-000000000001",
"site_url": "https://example.com/signup",
"proxy": "http://user:pass@203.0.113.10:8080"
}The proxy format is http://user:pass@host:port. Use the same proxy for the solve and for the submit, and keep it sticky for the whole session. Rotating the proxy between the solve and the submit brings the IP mismatch back.
How to decide
Work through these questions in order:
- Does the token work when you submit it from a different machine? If yes, use proxyless.
- Does the site reject tokens only when the submitting IP differs from the solving IP? If yes, send the proxy.
- Does the site use a session cookie or device check that is tied to one IP? If yes, send the proxy and keep the same IP for the whole session.
Test both on the free trial before you commit. Create an account and start with free trial credit, no card needed, then run the same flow once per type.
If your proxy is dead
A failed solve is free. If the proxy is dead or blocked by the target, the solve fails and you are not charged for it. Test the proxy yourself before the run, check its format, and make sure the target does not block its address range. A proxy that works for a browser but fails the solve is usually a format problem.
Keep proxy credentials out of logs
A proxy address with a password is a secret. Store it in an environment variable or a secret manager. Do not print it in logs, do not commit it, and do not paste it into bug reports. If you log the solve request for debugging, strip the proxy field first.
Choosing a proxy for the variant
The solve works with whatever proxy you send, but the token is only useful if the same IP submits the form. Use a residential or static address that you control for the whole session, not a pool that rotates on every request. Sites that bind tokens to IPs usually also bind the session, so a rotating pool breaks the flow twice.
What about speed?
Both variants return a token from one blocking request, with no polling loop. The timeout is the same: about 185 seconds. Choose the variant by the IP question, not by speed.
Sessions and proxies in practice
Use the same proxy from the first request of a session to the last. A typical flow loads the sign-up page, solves the captcha and submits the form. If the page load goes through one address and the solve goes through another, an IP-bound site may reject the token even though everything else looks right.
Keep a single proxy setting in your code and pass it to every step that touches the site. If other parts of the job rotate proxies for scraping, give the captcha flow its own sticky proxy. Mixing the two is one of the most common reasons a token that worked in testing fails in production.
Set the proxy field only on the variant that uses one. Sending a proxy with the proxyless task type does not improve the solve, and it makes it harder to tell which mode a run used when you read the logs.
Reading the logs for the right answer
If you are unsure which mode a site needs, run both on the same page and compare. Log whether each token was accepted, along with the task type and whether a proxy was sent. A site that accepts proxyless tokens consistently does not need the proxy variant. A site that rejects them only from certain runs points to an IP check. Let the logs decide, not a guess.
Next steps
- How to solve a PopularCaptcha in Python
- Solving invisible captchas
- Retries and error handling that survive production
- Free captcha solver trial
Start with free trial credit, no card needed: create an account and try both task types on one page.