Why am I getting hCaptcha challenges.

hCaptcha scores every request before it decides what to show you. A low score passes silently, a high score gets a puzzle, and the worst scores get several rounds of harder ones. The score comes from four places: the reputation of your IP, what your browser session looks like, how the site owner configured the widget, and how fast you are hitting the site. Here is what each signal does and what you can realistically change.

Every request is scored before you see anything

The widget runs a passive risk check the moment it loads, before any puzzle appears. If the check comes back clean you get a token without doing anything; that silent pass is the entire premise of invisible hCaptcha. If it does not, you get a challenge sized to how suspicious you look. Every version of “why am I getting hCaptcha” has the same answer: one of these four signals is raising your score.

IP reputation carries the most weight

Nothing moves the score like the address you arrive from. hCaptcha keeps reputation per IP and per range, and several kinds of address start out in a hole:

• Datacenter ranges. Traffic from AWS, Hetzner, OVH, and every other hosting provider is challenged almost by default. Real people rarely browse from a datacenter, so the ranges are assumed to be bots until proven otherwise.
• VPN exits. You share one exit IP with thousands of strangers. If any of them ran abusive traffic through it recently, you inherit their score. This is why the same person sees constant captchas with the VPN on and almost none with it off.
• Shared and residential proxies. The “residential” label promises a clean address; the pool behind it is often anything but. Heavily resold pools get flagged the same way VPN ranges do.
• Abuse history on your own address. Mobile carriers put thousands of customers behind one CGNAT address, dynamic home IPs carry whatever the previous holder did, and an infected device on your network can poison the address for everyone in the house.

Browser and session signals

The second bucket is what the request itself looks like. Automation leaves marks: the navigator.webdriver flag, headless build strings, header sets that do not match the claimed browser. A brand-new profile with no cookies and no history reads colder than a lived-in one, which is why a freshly launched headless browser scores worse than your daily driver. Two things surprise people here: a system clock that is minutes off breaks token timing checks, and aggressive privacy extensions that strip headers or block storage can make a human look like a script.

Sometimes the site challenges everyone

Site owners choose where the widget runs and how strict it is. Plenty of them force a challenge on every signup, login, or checkout regardless of risk score, because those are the endpoints attackers hit. Others run the invisible widget on every form submit and crank the threshold whenever they are under attack. If one specific site challenges you on every single visit while the rest of the web leaves you alone, that is almost certainly a deliberate setting on their side. There is nothing to fix on yours.

Velocity compounds everything

The last input is rate. Many requests from one address in a short window, the same form submitted over and over, retry loops that hammer a sitekey: all of it pushes the score up, and it compounds within a session. Your third signup attempt in a minute scores worse than your first. This is also why refresh-spamming a captcha backfires; each attempt makes the next one longer.

Why the challenges keep getting harder

hCaptcha’s response to risk is graded, in two directions at once. First, rounds: a clean visitor usually clears in one round, while a risky one gets a second or third before the token is issued. Second, type: low scores get simple image grids, high scores get the drag puzzles and area selections that are slow for humans and brutal for bots. The full ladder is in hCaptcha challenge types. If your challenges have been getting longer and stranger, that is not bad luck. Your score got worse.

If you are a regular user: what actually helps

Five changes account for most of the difference, and all of them are legitimate:

• Turn off the VPN for sites that keep challenging you. This fixes more cases than everything else combined.
• Set your system clock to sync automatically. A skewed clock fails timing checks you never see.
• Disable extensions that rewrite headers, spoof your user agent, or block all storage. Privacy tools are fine; tools that make your browser lie are what trips the check.
• Let cookies persist. Wiping them on every close makes each visit look like first contact.
• Slow down. Stop refreshing the challenge and stop resubmitting the form.

An honest caveat: if you are behind carrier CGNAT or your ISP’s range has abuse history, you can do all five and still get challenged. The score is attached to an address you cannot change, and your options shrink to switching networks or living with it.

If you are automating: the avoidance trap

Engineers usually arrive at this page from the other direction: a scraper or test suite that suddenly meets hCaptcha on every run. The instinct is to make the challenge stop appearing. Stealth tooling like selenium-stealth, undetected-chromedriver, and puppeteer-extra’s stealth plugin patches the browser-side signals, and it does work for a while. Then a detection update lands and the whole pipeline fails at once, silently, on every request.

No setup reliably prevents challenges on a site you do not control. You do not control the heaviest input (your IP’s reputation), and you do not control the site’s configuration, which can force a challenge on everyone. Good infrastructure lowers the challenge rate; nothing pins it to zero. A pipeline that assumes zero is one threshold change away from a total outage. A pipeline that can solve whatever appears does not care.

That is the framing shift. Treat the challenge as a step in the flow, like a redirect or a login wall, and the brittleness disappears: detect the widget, read the sitekey, fetch a token, inject it, submit. The full pattern, including session handling, is in hCaptcha solving for web scraping.

Solving the challenge instead of dodging it

The token-fetch step is one API call. Send NoneCap the sitekey and page url, block on the result with ?wait, and get back a real P1_ token:

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"
  }'

{
  "id":              "solve_01HQF7K3JKWZX",
  "object":          "solve",
  "type":            "hcaptcha",
  "status":          "solved",
  "token":           "P1_eyJ0eXAi...UV8w",
  "credits_charged": 1
}

Submit the token as the form’s h-captcha-response. It is single use and valid for about 120 seconds, so fetch it right before you need it. NoneCap returns tokens that regular, invisible, and enterprise (rqdata) sitekeys accept; billing starts at one credit per challenge round, charged on success only, at $0.25 to $0.50 per 1,000 credits. Riskier targets sometimes take two or three rounds, which is exactly the ramp described above. New accounts get 100 free credits; details are on the pricing page and in the API reference.