Captcha proxies for hCaptcha solves.

A captcha solve is a conversation with hCaptcha, and it has to come from some IP address. You either lend the solver yours, through a proxy, or let the solver use its own. Which one fits depends on whether the site checks that the token comes back from the address that earned it. This guide covers why the address matters, both ways of solving on NoneCap, the proxy formats, and the errors you will see when a proxy is the problem.

Why a solve needs an IP address

To get a token, a solver loads the hCaptcha widget for the page’s sitekey, receives a challenge, answers it and collects the P1_ token. Every one of those requests leaves from an IP address, and hCaptcha reads it. Its own FAQ lists the IP address among the information it evaluates, and its Enterprise overview describes risk attributes “like VPN or proxy usage” and rules that restrict which countries can reach a feature. An address with a poor reputation gets harder challenges, more of them, or none at all (why hCaptcha challenges some visitors more).

The site sees an address too. When the form is posted, its server sends the token to hCaptcha’s siteverify endpoint, and hCaptcha’s docs list remoteip, “the user’s IP address”, as a recommended parameter that “helps improve verification accuracy”. So a token can carry two addresses: the one that solved the challenge, and the one that submitted the form. Whether they have to match is up to the site’s configuration.

Two ways to solve: your proxy or ours

NoneCap’s solve API takes an optional proxy field. Send it and the solve runs through your proxy; leave it out and the solve runs from NoneCap’s own pool, which is what “proxyless” means here.

Proxyless is the quickest start: no proxy to buy or configure, and a capped bill: per the pricing page, each solve is charged per round, but never above a fixed ceiling per solve, so a sitekey that keeps serving rounds cannot run up your bill.

curl "https://api.nonecap.com/v1/solves?wait=90" \
  -H "Authorization: Bearer $NONECAP_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "type":    "hcaptcha",
    "sitekey": "f5ab1c2d-7e8f-4a9b-b1c2-d3e4f5a6b7c8",
    "url":     "https://target.example/login"
  }'

Your own proxy is the setup for sites that compare the solving and submitting addresses. It can also cost fewer credits: per the pricing page, better proxies mean fewer rounds, and you pay per round.

curl "https://api.nonecap.com/v1/solves?wait=90" \
  -H "Authorization: Bearer $NONECAP_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "type":    "hcaptcha",
    "sitekey": "f5ab1c2d-7e8f-4a9b-b1c2-d3e4f5a6b7c8",
    "url":     "https://target.example/login",
    "proxy":   "http://user:pass@1.2.3.4:8080"
  }'

The proxy field

The API reference accepts the proxy as a URL string, scheme://user:pass@host:port, or as an object:

"proxy": {
  "scheme":   "socks5",
  "host":     "proxy.example.net",
  "port":     1080,
  "username": "user",
  "password": "pass"
}

• Schemes: http (the default), https, socks5, socks5h and socks4.
• Reachable from the internet. The solve runs on NoneCap’s servers, so the host must be a public hostname or IP. localhost, 127.0.0.1, 10.0.0.5 or a bare service name from your own network cannot be reached; the request is answered with 422 validation_error pointing at proxy, or the solve fails.
• No TLS interception. A proxy that rewrites TLS cannot reach hCaptcha; the solve fails with proxy_error.
• Bandwidth is reported. A finished solve carries proxy_bytes, the bytes that went through your proxy, so you can square it with your proxy provider’s meter.

Code written for another solver keeps its proxy settings: NoneCap’s createTask endpoint takes HCaptchaTask with either vendor’s proxy fields as well as HCaptchaTaskProxyless, and the 2Captcha-style endpoint takes proxy and proxytype.

One exit for the whole exchange

On sites that compare addresses, the proxy has to stay on one exit IP from the moment you load the page until the token is submitted. The API reference puts it plainly for enterprise sitekeys: many deployments reject a token submitted from a different address as invalid-response, so pass a proxy that stays on one exit for page load, solve and submit. Many rotating proxy services offer a sticky-session form of their login for exactly this; use one session per solve.

The solve also returns user_agent, the browser it presented while earning the token. Some sites refuse a token sent by a different browser version, so submit with that string as your User-Agent, through the same proxy:

import os, requests

PROXY = "http://user-session-7f3a:pass@gw.proxy.example:8000"
site = requests.Session()
site.proxies = {"http": PROXY, "https": PROXY}
site.get("https://target.example/login")

solve = requests.post(
    "https://api.nonecap.com/v1/solves?wait=90",
    headers={"Authorization": f"Bearer {os.environ['NONECAP_KEY']}"},
    json={"type": "hcaptcha", "proxy": PROXY,
          "sitekey": "f5ab1c2d-7e8f-4a9b-b1c2-d3e4f5a6b7c8",
          "url": "https://target.example/login"},
).json()

site.post("https://target.example/login",
          headers={"User-Agent": solve["user_agent"]},
          data={"email": "...", "h-captcha-response": solve["token"]})

Enterprise pages that issue an rqdata value need it in the solve as well; the rqdata guide covers reading it fresh for each solve.

When the proxy is the problem

NoneCap reports proxy trouble in the solve’s error or warnings, so you can tell a bad exit from a hard sitekey. None of these failures is charged.

• proxy_error: your proxy could not be used. It refused the connection (wrong credentials or source IP; the message quotes its reply), intercepts TLS, points at a private address, or hCaptcha refused its IP. Check the host and login, or switch exit.
• challenge_not_loaded through a proxy: hCaptcha did not serve a challenge, which usually means the exit IP has a poor reputation with hCaptcha. Retry on a different exit.
• token_not_granted: the challenge was answered but no token was issued. If it keeps happening, use a proxy whose IP hCaptcha trusts more.
• expired through a proxy: the proxy did not answer in time and the solve reached its deadline.
• 429 proxy_unavailable: nearly every recent solve through that proxy failed because it refused the connection, so new submits through it are paused. Fix it or switch exit and wait the Retry-After seconds.

Two warnings can arrive on a solve that still runs and is billed as usual. proxy_session_refused means the last tokens you reported as rejected came through this proxy session or exit IP, so move your next solves to a different exit; if your proxy changed its exit during the solve, it advises a sticky session instead. proxy_recommended means the page is much more likely to accept a token solved through the connection you submit from, and this solve did not run through yours. The full list is under Errors in the API reference.

How other solvers handle proxies

Proxy support works much the same across solving services. 2Captcha’s proxy docs say a proxy “allows to solve the captcha from the same IP address as you load the page”, that “using proxies is not obligatory in most cases”, and that some protections require IP matching. It accepts HTTP, HTTPS, SOCKS4 and SOCKS5 proxies in proxyType, proxyAddress, proxyPort, proxyLogin and proxyPassword fields. CapSolver’s proxy guide says “the IP address used to solve the challenge matters” and that a solution “might be rejected even if it is technically correct”; it describes proxy tasks as using the IP you provide and ProxyLess tasks as using its own infrastructure.

NoneCap solves hCaptcha only, so the choice above is the whole decision: proxyless for a quick, capped start, your own sticky proxy for sites that tie the token to an address. See pricing for what a solve costs, or the API reference for the full solve object.