The CAPTCHA problem is usually your IP, not your solver

The most useful thing I learned about solving CAPTCHAs had nothing to do with solving. It was that most of my failures were decided before the challenge was even drawn.

The same code, two different success rates

I ran the same pipeline from two places. Same language, same flow, same challenge handling. One ran at roughly 90 percent. The other sat near 30. Nothing in the code differed. The only variable was where the requests came from.

That gap is not a tuning problem. It is the site deciding, from signals you did not choose, how much work to give you.

What actually differs between two requests

A request is not just a URL and a body. It carries a lot of context, and challenge systems read all of it:

• Where the IP comes from. Datacenter ranges behave differently from residential ones. A range that many people hammer behaves differently again.
• How the IP has behaved before. A single IP asking for a hundred challenges in an hour is a story the site can read.
• TLS and header shape. The client fingerprint has to be consistent with itself. Mixed signals get scored as automation even when the request is legitimate.
• Session continuity. Cookies and storage tell the site whether this is a fresh visitor or the tenth attempt from something that has already failed nine times.

You can control some of these. You cannot control all of them, and that asymmetry is why two identical deployments scored differently.

The counter-intuitive part: more retries made it worse

When the success rate dropped, my first instinct was to retry harder. That was backwards.

A failed attempt is itself a signal. Retrying from the same identity turns a single low-confidence request into a pattern of them, and the site responds by making the next challenge harder or by refusing outright. I was feeding the thing that was already hurting me.

What helped was the opposite: fewer attempts per identity, and more identities.

A checklist that fixed most of it

None of this is clever, which is the point:

1. Treat the IP as part of the pipeline, not as plumbing. If you would not reuse the same one for hundreds of requests on a normal site, do not do it here either.
2. Stagger rather than burst. A steady rate survives longer than a spike, even at the same total volume.
3. Retry from a fresh challenge, and after 2 failures, change identity. Grinding on the same session is the expensive path.
4. Make the client consistent. If the headers claim one browser, the TLS fingerprint should not disagree.
5. Measure per identity, not just overall. An overall success rate hides the fact that a few identities are doing all the work while the rest are dead weight.

Keep the solve step boring

I stopped trying to build the solving part myself. What I want from a hcaptcha bypass step is that it returns something with a predictable shape and a stated lifetime, so the rest of the pipeline can be written as ordinary error handling. If the answer format changes every time the vendor has a clever idea, every retry path you wrote becomes guesswork.

The part worth owning is everything around it: identity management, retry budget, and logging that separates a site refusing you from a solver that missed. Those three explain almost every bad day I have had with this.