How You Get Identified: Proxy Verdicts, TLS Fingerprints and Bot Scores

"Are you a proxy" was never a yes-or-no question; it is a chain of evidence. The outer layer is the network: who announces the address, whether it is hosting or consumer, whether it appears on the public Tor exit list. One layer in is transport: the shape of your ClientHello says whether a browser or a script library made the connection, and changing IP does not change it. Innermost is behaviour and scoring: bot score, request pacing, session length. Each layer only yields a probability, and stacking them is barely enough — which is why false positives cluster on the same people.

Not all "hidden" traffic looks the same. A commercial VPN, a datacenter proxy and a Tor exit node leave different fingerprints at the network edge. This article walks through the signals a modern IP-intelligence stack actually uses.

1. The ASN is the first tell

Every IP belongs to an Autonomous System (ASN). Consumer ISPs, mobile carriers and hosting providers occupy very different ASNs. When an address is announced by a cloud or hosting ASN — AWS, DigitalOcean, Hetzner and so on — it is almost never a home connection. The ASN alone flags a large share of proxy and VPN traffic.

2. Datacenter vs residential

Residential proxies are harder: they rent real consumer IPs, so the ASN looks domestic. Providers counter this with reputation data, connection-type databases and behavioural signals — many accounts from one IP, unusual ports, short session lifetimes.

3. Tor exit nodes are public

Tor publishes its exit-node list. Any IP on that list can be classified instantly. A request from a Tor exit is not "maybe anonymized" — it is a known relay, and it is often blocked outright on sensitive endpoints.

4. VPN detection is probabilistic

Commercial VPNs are a moving target: they rotate IPs, buy residential ranges and use obfuscation. No single signal is conclusive, so providers combine ASN, reputation, TLS fingerprints (JA3) and request behaviour into a score.

5. What this means for you

• If you run a service, treat a high fraud score as a reason to add friction — CAPTCHA, email verification — not an automatic ban.
• If you value privacy, remember that a VPN changes your IP, not your browser fingerprint.
• Test your own connection with a transparent tool before you trust it.

6. The cost of a false positive

Calling a real user a proxy costs more than one visit: that person usually does not come back. Corporate gateways, campus networks, everyone behind one carrier-grade NAT, developers running privacy extensions — their signals overlap heavily with proxy traffic. A mature system therefore does not answer yes or no. It returns a score with reasons attached and lets a human decide where to add friction, which is also why good detection is almost invisible while bad detection locks everyone out.

Changing your IP is easy. Changing how your TLS handshake looks is not — and that handshake is sent in the clear before any HTTP request exists.

7. The ClientHello is a fingerprint

Every TLS connection opens with a ClientHello that lists supported cipher suites, extensions, elliptic curves, signature algorithms and more, in a particular order. The exact combination depends on the browser, its version, the OS and the TLS library. Hash those fields and you get a stable identifier.

8. What JA3 is

JA3 is a widely used scheme for that hash: it concatenates the numeric fields of the ClientHello and produces an MD5 digest. JA4 is a newer, more granular evolution of the same idea. Two connections with the same JA3 almost certainly come from the same software stack — even if the IP, the user agent and the cookies differ.

9. Why it matters for privacy

• A VPN hides your IP but leaves the fingerprint untouched — you remain linkable across sessions.
• An unusual JA3 is itself a signal: automation frameworks and scrapers have signatures that rarely match a real browser.
• Anti-bot systems combine the fingerprint with ASN, timing and behaviour; no single signal decides, the score does.

10. What you can actually see about yourself

On Cloudflare, JA3 and JA4 are only exposed to Enterprise plans with Bot Management enabled. Without it, the honest signals available to any site are transport metadata — TLS version, cipher suite, HTTP protocol version — plus the client hints your browser volunteers, such as the operating system platform and mobile flag.

11. What to suspect when the fingerprint does not match

If your fingerprint consistently disagrees with the browser version you claim, do not assume you are being blocked. The three usual causes are an enterprise proxy or antivirus terminating TLS and re-originating the connection with its own stack, an extension rewriting headers, or a client that really is automated. The first two matter for more than looking odd: TLS interception means the middlebox can see plaintext in principle, which is a bigger concern than the fingerprint itself.

A form starts getting hammered, someone adds a captcha, signups drop by a third and the abuse continues at a lower volume. The captcha did what it was asked to do — it added friction to everyone, including the people you wanted. Bot detection is a different problem: identify the automated traffic, and spend friction only where it is needed.

12. The edge looks at the connection before it looks at behaviour

Long before any JavaScript runs, the request already carries a lot: the source ASN and its reputation, TLS version and cipher, the shape of the ClientHello, the HTTP/2 settings frame, header order and casing, and whether the stated User-Agent is consistent with the rest of the stack. A request claiming to be Chrome 130 with the TLS profile of a Python library is not a subtle find.

Cloudflare compresses these signals into a bot score from 1 to 99. Low means it looks automated, high means it looks human; the platform treats 1-29 as likely automated and 30-99 as likely human, with managed rules acting on the extremes. The score is only exposed on plans with Bot Management, which is why a self-hosted diagnostics page often has to say "unavailable" instead of printing a number — and saying so is the correct behaviour.

13. A score is not a verdict

Plenty of legitimate traffic scores low: monitoring checks, link previewers, RSS readers, accessibility tools, curl in a CI job, and any user whose browser extension rewrites headers. Equally, a headless browser driven by a competent operator can score high. Treat the score as one input and keep a human-readable reason next to any action you take.

14. Turnstile is not a captcha

Turnstile shows an interactive puzzle only when it is unsure. Most visitors pass without doing anything, which is the point: it trades a visual test for a set of browser and connection signals. The part teams get wrong is the server side.

• Validate every token on your server against siteverify. A client-side "success" flag is a suggestion, not proof.
• Tokens are single use and short-lived — roughly five minutes. Store the validation result, not the token.
• Bind the token to an action and check the hostname it was issued for; otherwise a token farm can solve on one site and replay on yours.
• Fail closed on a missing or invalid token for sensitive actions, and fail open with a challenge for the rest — a checkout that hard-fails on a siteverify timeout loses money.

15. What the browser can and cannot prove

JavaScript execution, event timing, pointer movement and WebGL output all cost an attacker more effort than a plain HTTP request, and all of them are trivially defeated by a real browser under automation if the operator is patient. Header order and TLS fingerprints are harder to forge, because they come from the TLS library rather than the code that calls it — but on Cloudflare those fingerprints require an Enterprise plan, so a smaller site usually has to work with JS signals, rate limits and reputation instead.

16. Where friction belongs

Put the challenge where the cost of a false positive is lowest and the value to an attacker is highest: account creation, password reset, checkout, and anything that sends a message. Leave reads alone. Then add velocity rules — same IP creating more than a few accounts a day, one device across dozens of sessions, a burst from a single ASN — because those catch the traffic a challenge would have let through anyway.

ipbox.one lays these three layers out as far as it can see them: the ASN and network class of the address, the TLS details the edge observed for this request, and the bot score where the deployment exposes one. The values it cannot obtain are labelled as unavailable rather than guessed — which is itself a result.