We Tested Fingerprint Spoofing, Engine Architecture, and Timezone Matching. None of Them Beat Cloudflare Alone.

We've now run three separate tests trying to find the lever that beats a real anti-bot deployment. Fingerprint spoofing didn't do it. Browser architecture didn't do it. Even IP-timezone matching — a specific, well-known "best practice" — didn't do it when we isolated it. That's not one clean story. It's an honest one, and it's worth writing down before drawing the wrong conclusion from any single piece of it.

What we already know doesn't work alone

The first two posts in this series established, with real numbers, that the two things "stealth browser" marketing usually sells you don't move a real target's decision:

Signal tested	How many engines/configs	Result against g2.com
Fingerprint spoofing method (native C++/Blink vs. JS-patched vs. patched Firefox)	3 engines	All 3 hard-403'd, identical block page
Browser architecture (spawn-per-request HTTP service vs. persistent CDP session)	4 engines	All 4 hard-403'd, identical block page
Datacenter proxy pool, no timezone coherence	1 engine, 6 attempts	4/6 hard 403, 1/6 ambiguous, 1/6 connection failure

Three different axes, one consistent answer: none of them, alone, is what a real Bot Management deployment is checking.

The one axis we haven't isolated cleanly — timezone coherence

There's a well-known piece of scraping folklore: if your proxy exits in Amsterdam, your browser's clock and locale should say Amsterdam too, or the mismatch is a tell. We actually tested this directly, in an earlier internal bench (2026-06-22, before this series started): a dedicated instance with timezone="auto" — resolving the proxy's egress IP to its real IANA timezone and matching the browser's clock to it — run against the same class of hard Cloudflare target, through the same kind of datacenter proxy pool this series has used throughout.

Timezone coherence changed nothing. The pass rate was the same with it as without it.

This result needs a caveat the fingerprint and architecture tests didn't: we can't cleanly separate "timezone coherence doesn't matter" from "the datacenter proxy's IP reputation was already bad enough that nothing downstream of it could help." A well-known anti-bot vendor doesn't only check whether your clock agrees with your IP — it also checks whether that IP has ever hosted a data center. If the answer to the second question is yes, the first question may never get evaluated. This is exactly the kind of test that needs a clean residential IP to be conclusive, and we haven't run that version yet.

Where coherence actually did matter — a different part of our stack

It's worth being precise about where "coherence" has genuinely paid off for us, because it's not the browser fleet — it's the network layer underneath it. Our outbound HTTP client controls the TLS handshake (JA3/JA4 fingerprint) and HTTP/2 SETTINGS frame (Akamai fingerprint) to match a real Chrome browser, independent of which browser engine is or isn't involved. At one point, our public HTTP-only scraping tier announced a JA4 fingerprint for Chrome 133 while sending the literal user agent string req/v3 — every individual signal was internally fine, but the two didn't agree with each other. That's a coherence failure in the strict sense: not a missing spoof, a mismatched one. We found it, fixed it, and deployed it — a real, shippable improvement.

That's a genuinely different question from "does this beat Cloudflare," and we're not claiming it does on its own — we haven't tested it against a Bot Management target in isolation the way we tested engine and architecture. What it does show is that the general principle — a detector doesn't need one missing signal, it can catch one that disagrees with another — has held up in a part of our system we could actually verify end-to-end, which is more than we can currently say for full IP+timezone+behavior coherence against a hard browser target.

What we'd need to actually settle this

Being honest about what three tests have NOT proven: we haven't yet run a browser-fleet request through a residential IP with every coherence signal — geo, timezone, TLS/JA4, locale, and a realistic navigation pattern instead of a single cold request — matched at once. Every proxy pool in this series has been datacenter or cloud-hosted (DigitalOcean, Oracle, Hetzner, Alibaba, AEZA, Cogento in June; a Netherlands hosting ASN and Scaleway in August). That's the gap between "we've ruled out several things that don't work alone" and "we know what does."

The bottom line

Across engine choice, architecture, and one specific coherence signal tested in isolation, nothing we've measured beats a real anti-bot deployment on its own. That's not the same as "nothing works" — it's evidence that the vendors we've tested against are scoring something more aggregate than any single trick, and that the honest next step isn't a better browser, it's a better IP. We haven't run that test yet. When we do, it'll be the fourth post in this series, not a rewrite of the first three.

Caveats

This post reports one result (the timezone test) that predates this series and wasn't re-run fresh for it — flagged explicitly above, with the confound (datacenter IP reputation as a possible full explanation) stated rather than glossed over.

The TLS/JA4 coherence fix is real and shipped, but untested against the specific hard target (g2.com) this series uses. We're citing it as evidence for the general principle, not as a fourth data point in the same table as the others.

"Nothing works alone" is a claim about the signals we've isolated, not an exhaustive list. Behavioral signals (mouse movement, timing between actions, scroll patterns) haven't been tested in this series at all.

Skip isolating the signals yourself

Crawlora's fleet combines engine, proxy, and fingerprint coherence behind one API, so you're not testing one variable at a time. 2,000 free credits a month, no card required.

See the Web Scraping APISee pricing