Detection & trust · glossary

Browser fingerprinting

Browser fingerprinting identifies a client from the combination of attributes it exposes: user agent, screen size, fonts, canvas and WebGL rendering, time zone, language, installed features, and at the transport level the exact way its TLS and HTTP/2 stacks negotiate. The combination is often unique, so a website can recognise the same automation across many IP addresses. Proxies change the IP; they do not change the fingerprint.

2 min read Also called device fingerprinting, TLS fingerprinting Updated

Two families#

  • Browser-side: what JavaScript can read. Headless browsers and automation frameworks leak characteristic values unless configured otherwise.
  • Network-side: the TLS ClientHello (cipher order, extensions) and HTTP/2 settings identify the client library. A Python script does not look like Chrome, whatever user agent it sends.

Consistency with the exit#

Detection systems cross-check fingerprint and IP: a Berlin residential exit with an American time zone and English locale contradicts itself. Align language, time zone and, for browsers, the profile with the country you target.

One fingerprint, one session#

The same fingerprint from a hundred rotating IPs within a minute is a stronger bot signal than one IP would be. Pair rotation with fingerprint variety, or pin a sticky session to one profile.

How it works at ProxShift#

ProxShift is deliberately neutral here: the gateway relays your TLS and HTTP exactly as sent and never terminates TLS, so what the target sees is your client's own fingerprint behind a residential, ISP, datacenter or mobile address.

Ready when you are

See it on a real request.

Create an account, top up $20 and run the quickstart against your own target. Traffic you buy never expires.