Skip to content
bytetourist

Anti-bot & TLS fingerprints

Getting a 200 is not the same as getting the page. Many sites inspect the shape of a connection, not just its contents, and misclassify ordinary automated clients as bots. bytetourist makes your requests look like the real browser traffic they stand in for, so legitimate collection isn’t blocked by accident.

What sites inspect

Section titled “What sites inspect”
  1. TLS fingerprinting (JA3/JA4): servers fingerprint your TLS ClientHello. A default Go or Python client looks nothing like Chrome, which is enough to get flagged on its own.
  2. HTTP header analysis: header ordering and consistency with the User-Agent are checked.
  3. JavaScript-rendered content: some pages only assemble their content after running JavaScript, so a plain fetch returns an empty shell.

What bytetourist does

Section titled “What bytetourist does”
  • Browser-grade TLS fingerprints. The node originates TLS with a real browser JA3/JA4 profile rather than the default client stack, so the connection presents as a mainstream browser instead of a generic library.
  • Consistent headers. Requests are shaped so header order and defaults match the browser profile being presented.
  • JavaScript rendering for crawls. A crawl created with JavaScript rendering (or screenshots) loads each page in a headless Chromium that bytetourist runs centrally; every request the browser makes still leaves through an edge, and the rendered page is what gets stored. Rendering isn’t available on individual proxy requests.

bytetourist also tracks, for each site, how each edge IP is being answered: an IP the site keeps refusing (403, 429, 451) is moved behind the site’s other eligible edges, and routing strategies like freshest_ip spread traffic across the fleet’s IPs.

On the roadmap

Section titled “On the roadmap”

A managed “auto” mode (which detects a challenge and automatically escalates the rendering path, then retries) is planned. See the Scrape API preview.