Anti-bot & TLS fingerprints

Getting a 200 is not the same as getting the page. Modern targets stack several detection layers; bytetourist addresses them at the egress.

The detection layers

IP reputation — datacenter ranges are widely blocked (success can fall to 40–60%); residential/mobile IPs pass far more often (95–99%).
TLS fingerprinting (JA3/JA4) — servers fingerprint your TLS ClientHello. A Go or Python client looks nothing like Chrome.
HTTP header analysis — header ordering and consistency with the User-Agent are checked.
JavaScript fingerprinting — canvas, WebGL, fonts, navigator — used to detect headless browsers.
Behavioural analysis — mouse, scroll, timing.
CAPTCHAs — Turnstile, reCAPTCHA, hCaptcha.
Honeypots — hidden links/fields that flag bots.

What bytetourist does today

Browser-grade TLS fingerprints. The node originates TLS with a real browser JA3/JA4 profile (via tls-client/uTLS), not the default Go stack — so layer 2 sees “Chrome,” not “bot.”
Headless-Chrome fallback. For JS-heavy or strict targets, the node can run a real headless Chromium (go-rod) to execute the page.
IP-class escalation. Start cheap on datacenter; move to residential or mobile for targets that block datacenter ranges:
Terminal window
```
-U "YOUR_API_KEY-iptype-residential:"
```

A practical escalation pattern

Try datacenter with browser fingerprints (cheapest).
On block/challenge, retry the same request on residential.
For the hardest targets, use mobile and/or the headless-browser path.

You can drive this from your client, or rely on bytetourist’s circuit breaker to route around nodes that a target is actively blocking.

On the roadmap

CAPTCHA solving, header-order normalisation, and a managed “auto” mode that escalates IP class automatically on a detected block are planned — see the Scrape API preview.