ShieldLabs Blog

10 browser fingerprinting techniques explained

Yahor Papou — Wed, 16 Sep 2026 20:55:13 GMT

Browser fingerprinting is the foundation of device intelligence: the way a site recognizes the same visitor without a cookie. Browser fingerprinting techniques are the individual methods a site uses to read attributes of a browser, each one probing a different surface, and combine them into an identifier that recognizes the same visitor again. No single attribute is unique; the power is in the combination. A landmark study by the Electronic Frontier Foundation, published in the 2010 Privacy Enhancing Technologies Symposium proceedings, found that a browser fingerprint carried enough distinguishing detail to single out roughly 84 percent of browsers in its sample.

The toolkit has grown from a handful of HTTP headers to a layered read across the graphics stack, the audio engine, and the network itself. The consistent pattern is that the attributes a browser can fake in JavaScript are the weak ones, and the techniques that reach down to the real hardware and the connection are the ones that hold up under a tool built to defeat them. This guide walks through the main techniques behind browser fingerprinting, what each one reads, and how stable each is.

Key takeaways

A browser fingerprint is built from many techniques at once. Each reads one attribute, and combined they carry enough distinguishing detail to recognize a returning visitor without a cookie.
The strongest techniques read what the browser cannot easily hide: how the device renders graphics (canvas, WebGL), processes audio, and negotiates a connection (TLS, network).
Declared attributes like the user agent are easy to spoof, so they add little on their own. The render-and-hardware techniques are what make a fingerprint stable.
Anti-detect browsers fake these attributes per profile, but faking many layers consistently is hard, so the contradictions between them are their own detection signal.

What are browser fingerprinting techniques?

Browser fingerprinting techniques are the individual methods a website uses to read attributes of a visitor's browser, with each method probing a different surface such as graphics rendering, audio processing, installed fonts, or the network connection. No single attribute is unique on its own, but together they carry enough distinguishing detail to recognize the same browser, and the device behind it, again without a cookie. These are the methods behind browser fingerprinting.

How browser fingerprinting works

Browser fingerprinting works by collecting attributes that vary from one device to the next, then combining them into a single identifier. Each attribute on its own is shared by many people; together they narrow the field until the combination is, in most cases, unique. The detail that makes it work is that much of this data is exposed automatically through standard browser APIs, so a script can read it in milliseconds without any permission prompt.

The techniques split into two families. Declared attributes are values the browser simply reports, like the user agent or the language, and they are trivial to change. Derived attributes are produced by asking the browser or device to do something, render an image, process an audio signal, negotiate a connection, and reading the result. Derived attributes are what give a fingerprint its staying power, because they reflect the real hardware and software underneath rather than a string the user can edit.

The main browser fingerprinting techniques

The techniques below are listed roughly from the most stable to the most easily changed. A real fingerprint reads many of them at once. Most of them run inside the browser, canvas, WebGL, audio, fonts, and the declared attributes, while TLS and WebRTC read the layer underneath, the connection and the network, which is why they are harder to fake and pull double duty for anonymity detection. In practice a detection system reads across all of these together.

Technique	What it reads	How stable
Canvas fingerprinting	A hash of how the device renders text and graphics to a hidden canvas	High
WebGL fingerprinting	The GPU and graphics driver, read from a rendered 3D scene	High
Audio fingerprinting	Tiny differences in how the device's audio stack processes a generated signal	High
TLS fingerprinting (JA3/JA4)	The exact shape of the TLS handshake the browser sends	High
WebRTC	A local or real IP address the browser can expose, even behind a VPN	Medium
Font fingerprinting	Which fonts are installed and how they render	Medium
Hardware attributes	CPU cores, device memory, touch points, sensors	Medium
Media device fingerprinting	How many media devices are connected and of what kind (full labels need camera or mic permission)	Low
Screen, timezone, language	Resolution, color depth, timezone offset, locale	Medium
User agent and client hints	The declared browser, version, and operating system	Low

Canvas fingerprinting

Canvas fingerprinting asks the browser to draw text and shapes to an off-screen HTML canvas, then reads the pixel data back and hashes it. Because the result depends on the GPU, the graphics driver, the operating system's font rendering, and anti-aliasing, two devices almost never produce the same hash. It is one of the most reliable techniques because the user cannot easily change how their hardware renders, which is why canvas fingerprinting carries so much weight in a combined read.

WebGL fingerprinting

WebGL fingerprinting is the 3D cousin of canvas. A script renders a scene through the WebGL API and reads back both the rendered output and the reported GPU vendor and renderer strings. By exposing the graphics hardware directly, WebGL fingerprinting stays stable per device and is hard to spoof convincingly.

Audio fingerprinting

Audio fingerprinting uses the Web Audio API to generate a sound signal, process it through the device's audio stack, and measure the output. The tiny variations introduced by the hardware and the audio processing produce a stable value that differs between devices, even when nothing is actually played out loud. This kind of audio fingerprinting is a different thing from the music recognition that shares the name.

TLS fingerprinting (JA3/JA4)

TLS fingerprinting reads the connection itself rather than anything in the page. When a browser opens an encrypted connection, the order and contents of the TLS handshake it sends are characteristic of the client software. Methods like JA3 and the newer JA4 summarize that handshake into a value, which is powerful because it is sent over the network and a page script cannot rewrite it. It is the technique that most often catches a browser lying about what it is, and the JA4 fingerprint is how that handshake becomes a value you can compare.

To see how far that goes, run browsers configured to spoof their identity through a combined read, and the TLS handshake is the layer that gives them away most reliably. A profile can rewrite its user agent in seconds, but the handshake it actually negotiates still matches the client software underneath, so the declared browser and the connection stop agreeing. JA4, released in 2023, made that handshake easier to reduce to a single comparable value, which is why a contradiction between it and the declared user agent is such a dependable tell.

WebRTC

WebRTC is a browser feature for real-time audio and video, and while setting up a connection it can reveal a local network address, and sometimes the real public one, even when the visitor sits behind a VPN or proxy. That makes it less a source of device distinguishing detail and more a way to notice a connection that is hiding its origin. It is why WebRTC matters more for anonymity detection, surfacing a real address that contradicts the declared one, than for telling two ordinary devices apart.

Font fingerprinting

Font fingerprinting detects which fonts are installed by measuring how sample text renders, since a missing font falls back to a default with different dimensions. The set of installed fonts reflects the operating system and the software a person has added, which makes it a useful medium-stability signal.

Hardware and device attributes

A browser also exposes hardware hints: the number of logical CPU cores, an approximate amount of device memory, the maximum number of simultaneous touch points, and, with permission, motion and orientation sensors. The set of supported browser features and APIs adds a few more bits the same way. Older techniques read the battery level and charging state too, though browsers have since restricted that one specifically because it was being used to track people. None is unique alone, but together they add distinguishing detail and tend to stay constant for a given device.

Media device fingerprinting

Media device fingerprinting reads the list of media inputs and outputs the browser reports through the media devices API: the microphones, cameras, and audio outputs attached to the machine. It captures nothing from them, only how many are connected and of what kind. The full list, with each device's label and ID, is only exposed once the visitor has granted camera or microphone access, so on its own this technique is a weak, supporting signal rather than a primary one. Where it does apply, the set of devices stays fairly consistent for a given machine and is awkward to fake convincingly across a fleet of fake profiles.

Screen, timezone, and language

Screen resolution and color depth, the timezone offset, and the language and locale are all read directly. They are moderately stable and useful mostly as corroboration, and a mismatch between them, a timezone that disagrees with the declared locale, is itself a tell.

User agent and client hints

The user agent string and the newer client hints report the browser, its version, and the operating system. They are the easiest attributes to spoof, so on their own they add almost no distinguishing detail, but when they disagree with what the render and TLS techniques reveal, that disagreement is a detection signal.

How unique and stable is a fingerprint?

A fingerprint's strength comes from distinguishing detail: how much each attribute narrows the field of possible devices. The EFF's early research found most browsers were unique within its sample. In 2018, a study of around two million fingerprints, published in the Web Conference proceedings, found only about 33 percent were unique, because common phone models share very similar fingerprints. The practical reality sits in between: on desktop, a full fingerprint is usually distinctive; on mobile, it is weaker on its own and leans more on the network and behavioral layers.

Stability is the other half. Fingerprints drift as browsers update, drivers change, and fonts are added, so a resilient system does not expect an exact match every time. It scores how much of the fingerprint agrees and tolerates small changes, which is also what separates a returning real user from an assembled profile that is too clean or internally contradictory.

Can browser fingerprinting be blocked?

Browser fingerprinting can be resisted but not fully blocked, and the trade-offs are real. Privacy browsers and extensions add noise to canvas and audio readings, block known scripts, or make a device look like many others, and an anti-detect browser goes further by spoofing a full set of attributes per profile. Each of these changes some surfaces, but covering every technique consistently is hard, and the act of covering them, a too-uniform fingerprint, an injected-noise canvas that changes on every read, or a TLS handshake that disagrees with the declared browser, becomes its own signal. That cat-and-mouse plays out in full when a session runs an anti-detect browser.

How browser fingerprinting works without a cookie

Browser fingerprinting works without a cookie, and that is the point. A cookie is a value the site writes into the browser, so the visitor can clear it, switch to a private window, or move to a fresh browser and the link is gone. A browser fingerprint is not written anywhere; it is derived on the fly from the attributes the techniques above read, so the same browser produces the same identifier on the next visit even after cookies are cleared. That is why it survives the resets a fresh email and a private window are meant to provide.

Fingerprinting does not replace cookies so much as complement them. A first-party cookie is a fast, reliable way to recognize a returning visitor who has not cleared anything, and the fingerprint is the layer underneath that still holds when the cookie is gone. Reading both together gives a steadier recognition than either one alone. That complement matters even though the third-party cookie did not disappear on the timeline many expected: in April 2025, Google confirmed it would not phase out third-party cookies in Chrome after all, keeping its existing cookie-choice approach, so cookieless recognition is a resilient companion to cookies rather than a scramble to replace them.

How browser fingerprinting helps detect fraud

Browser fingerprinting helps detect fraud because most online abuse depends on one person looking like many different people. Multi-accounting, free-trial farming, fake signups, and account takeover all rely on creating a fresh-looking visitor for each attempt, usually by clearing cookies, switching browsers, or rotating IPs. A browser fingerprint cuts through that, because the same device keeps producing the same identifier no matter how many fresh emails and new IPs sit on top of it. Linking those attempts back to one device is what turns a wall of separate-looking accounts into a recognizable pattern.

The combination of techniques is also a fraud signal in its own right. A real browser produces attributes that agree with each other: the declared user agent matches what the render and TLS techniques reveal, the timezone fits the locale, the network looks like a residential connection. A tool built to fake a visitor has to keep all of those layers consistent at once, and the moment they can contradict each other, a TLS handshake that disagrees with the declared browser, a risk signal that surfaces a real address behind a VPN, that disagreement is the tell. So fingerprinting helps detect fraud two ways at once: it links repeat attempts to one device, and it flags the inconsistencies that mark an assembled identity.

Recognizing returning visitors with ShieldLabs

ShieldLabs turns device and browser signals into a stable device identifier through one JavaScript snippet that recognizes a returning visitor even after cleared cookies and a rotated IP. The identifier is derived from the combination of signals, which is what makes it survive the resets a fresh email and a new IP are meant to provide, so your team can link repeat fraud and abuse attempts back to one device.

Around that identifier, each visit returns a risk score from 0 to 100 with the named signals behind it, including the risk signals, a VPN, anonymous proxy, datacenter connection, or anti-detect browser, that surface when what a visitor presents and the underlying signals contradict each other. The API and webhooks deliver the risk score and named risk signals, while four High-Risk Events, multi-accounting, account sharing, impossible travel and account takeover, are detected directly in the analytics dashboard, API and webhooks. Because the read happens in the background from data the browser already exposes, it adds no friction for a real visitor, and ShieldLabs helps block fraudulent and abusive traffic.

Sources

Eckersley, Peter (Electronic Frontier Foundation): How Unique Is Your Web Browser? (PETS, 2010)
Wikipedia: Device fingerprint
MDN Web Docs: Canvas API
Gómez-Boix, Laperdrix, Baudry: Hiding in the Crowd: An Analysis of the Effectiveness of Browser Fingerprinting at Large Scale (WWW, 2018)
Google: The Privacy Sandbox: Next steps (2025)

How to detect anti-detect browsers in 2026

Yahor Papou — Tue, 15 Sep 2026 13:35:51 GMT

In a March 2026 analysis, Stripe found that 7.4 percent of sign-ups at AI companies were implicated in suspected multi-account abuse. Behind most of that sits one quiet tool: the anti-detect browser. It lets a single person run dozens of "different" users from one laptop, each looking like a fresh device. That's the engine of multi-accounting, bonus farming, and ban evasion. The good news for teams trying to stop fraudsters: faking a browser cleanly is harder than the marketing claims, and the act of faking leaves its own trail.

Key takeaways

An anti-detect browser rewrites a browser's fingerprint signals per profile, so one machine can present as dozens of separate users, each looking like its own browser on its own device. It's the core tool behind multi-accounting.
It can be detected. Faking signals leaves contradictions, so detection scores how consistently a session's signals describe one real device instead of relying on any single check.
Using one is usually a terms-of-service violation, not a crime. It crosses into fraud when it's the means to take something under false pretenses.
The most resilient detection combines many independent signals at once (fingerprint consistency, browser-API integrity, the network layer) because no single check is enough.

What is an anti-detect browser?

An anti-detect browser is a specialized browser that rewrites a browser's fingerprint signals on a per-profile basis, so each profile looks like a separate device even when dozens run on the same machine. It rewrites the browser fingerprint, user agent, canvas, fonts, and screen, so each profile reads as its own browser on its own device. Where a normal browser reports one consistent identity, each profile gets its own synthetic set of signals:

user agent and operating system
screen resolution and timezone
language and installed fonts
canvas, WebGL, and audio fingerprint

To the site, every profile reads as a brand-new device. Under the hood, the browser works by intercepting and modifying the data a normal browser would otherwise share with a site through JavaScript and other browser APIs.

The selling point is isolation. One user opens profile 1, profile 2, profile 3, and to a site relying on cookies or a single fingerprint, each looks like an unrelated visitor. That's what makes the tool attractive to anyone who needs to look like many people at once.

A useful distinction up front, because the two are easy to confuse. Browser fingerprinting asks one question: have I seen this browser before? Anti-detect browser detection asks a different one: is this browser deliberately faking its signals? The first matches identities; the second flags the tool built to defeat that matching. Both rest on the same device fingerprint the browser is trying to rewrite, and they run together, not instead of each other.

Why do people use anti-detect browsers?

Because looking like many independent users unlocks whatever a platform hands out once per person. The same tool shows up across a familiar set of abuse cases:

Multi-accounting and account farms. One person operating many accounts to multiply whatever a single account earns, the product-world version of what online communities call sockpuppetry.
Bonus, promo, and free-trial abuse. Cycling through fresh profiles to claim a welcome credit, referral payout, or trial again and again.
Ban evasion. Returning after a block or suspension under a profile that reads as brand new.
Paid-traffic and affiliate fraud. Inflating campaign metrics with sessions that were never real customers.
Sybil farming. Multiplying wallet addresses and identities to farm crypto airdrops and reward campaigns.

Not every anti-detect browser session is abuse. QA testers, security researchers, and privacy-conscious users run them too. That's real, but in most business contexts it's the exception. The point of detection isn't to punish the tool. It's to give your team the context to tell a one-off legitimate session apart from coordinated Multi-accounting across accounts.

Is using an anti-detect browser illegal?

Using an anti-detect browser is usually a terms-of-service violation, not a crime. The tools are sold and bought openly, and running one is not itself unlawful, but most platforms prohibit operating multiple accounts or evading bans, so using one for that breaks their rules and can get accounts closed.

It crosses into fraud when the spoofing is the means to take something: claiming payouts under false pretenses, laundering stolen credentials, or covering tracks during account takeover. On its own, anti-detect browser use is typically a platform-policy problem your team enforces, which is exactly why detection (the data) and response (the action) are worth keeping separate.

Can anti-detect browsers be detected?

Anti-detect browsers can be detected, because they sell isolation, not invisibility. To make each profile look like a separate device, they have to fake signals, and faking is a different act from being a real device: a genuine browser's signals all describe one real machine, while an assembled profile's signals can contradict each other.

So the question isn't "can you see the device." It's "can you tell this device is lying about itself." That's the part anti-detect browsers struggle with, and it's where detection lives.

How do websites detect anti-detect browsers?

Websites detect anti-detect browsers by collecting many independent signals and scoring how consistently they describe one real, untampered device. No single check is decisive, so resilient detection correlates several at once. The techniques that do the work:

Fingerprint-consistency and lie-detection: cross-check attributes that must agree, like the user agent versus the platform the browser reports separately, the WebGL renderer versus the claimed OS, and timezone versus locale, plus a platform signal sent over the connection itself that page scripts can't rewrite.
Graphics, audio, and font fingerprinting: re-sample canvas, WebGL, and audio output, since a real device returns identical output every time while the noise these tools inject to defeat fingerprinting returns something different on each read.
Browser-API integrity and tool signatures: patched browser APIs stop behaving like the originals, a built-in automation flag gives away tools like Selenium or Puppeteer, and vendors match the signatures of known anti-detect tools.
Local port and control-interface probing: anti-detect, automation, and remote-access tools open known ports on the visitor's own machine, which a page can surface by timing how quickly those local ports respond.
Network and transport fingerprinting: passive TCP/IP fingerprinting infers the real OS, and the TLS handshake catches a faked browser stack when it doesn't match the browser the visitor claims.
IP and connection intelligence: reputation lists, datacenter-versus-residential classification, ASN, reverse DNS, geolocation, and latency separate hosted or masked connections from real ones.
Connection-origin and leak checks: a WebRTC STUN request can expose the real IP behind a proxy, while a blocked UDP path or an unusual MTU (maximum transmission unit, the smaller-than-normal packet size that tunneling leaves behind) hints at a VPN tunnel.
Behavioral signals: some stacks add mouse and keyboard dynamics, navigation timing, and velocity, like one device "traveling" across countries in minutes.
Cross-signal correlation: each tell is weak alone, so they're weighed into one score, and an environment that is too clean or self-contradictory is its own anomaly.

When we ran the same canvas and audio reads twice inside one session, the results were clean: a genuine device returned byte-identical output both times, while a profile using a noise injector to look unique returned a different value on each read. That difference is the tell. The user-agent line became weaker evidence in 2022, when Chrome began reducing it and moving real device detail into structured client hints, which is why detection weighs it against a platform value sent over the connection that a spoofed profile cannot rewrite as easily.

The common thread across all of them: detection is about correlation, not any single check. A determined, well-configured profile on a residential proxy raises the difficulty, but the more it spoofs, the more surfaces it has to keep perfectly consistent. Consistency at scale is exactly what gives it away.

What an anti-detect browser looks like to a detection layer

An anti-detect session doesn't show up as a single "bad" flag. It surfaces as a profile whose pieces don't fit, scored across several independent reads. Here's what a detection layer compares:

What's read	A real visitor	An anti-detect session
Fingerprint consistency	signals describe one coherent device	layers contradict each other
Browser-API integrity	native APIs return native values	patched APIs leave traces
Network vs declared browser	network matches the declared OS/browser	network layer disagrees
Local control ports	no anti-detect or automation port answering	a known control or debug port answers on localhost
Environment realism	normal quirks and distinguishing detail	too clean or internally contradictory

No single row is proof on its own. Together they answer the question that actually matters: is this one honest device, or a profile assembled to look like many?

Detecting anti-detect browsers with ShieldLabs

ShieldLabs runs this detection for you, so your team skips the homegrown scripts that go stale every time an anti-detect tool ships an update. One JavaScript snippet scores every visitor in about five minutes from install to first risk signal.

Each visit returns a dedicated anti-detect browser signal and a risk score that reflects how consistently the session's signals describe one real device and rises when the visitor is using an anti-detect browser. All of it happens in the background, with no friction for the visitor. That signal travels with a full set of risk signals, including anonymous proxy detection, VPN, and others.

A stable identifier ties a "fresh" visit back to a returning device even after cleared cookies and rotated IPs, surfacing the cross-session behavior behind multi-accounting. ShieldLabs surfaces multi-accounting and account sharing in the analytics dashboard, whether that is many accounts on one device or one account signing in across many devices. The analytics dashboard also breaks your traffic down by quality, so your team can gauge how much of it is trusted versus routed through anonymizing tools and watch anonymous traffic as a trend, not just one visit at a time.

The risk score and named risk signals are available through an API and webhooks, so your team acts in its own flow and your rules decide the outcome to prevent abuse and fraud.

Sources

Stripe: Analyzing first-party fraud trends: account, free-trial and refund abuse (2025)
Wikipedia: Device fingerprint
Wikipedia: Canvas fingerprinting
W3C: WebDriver specification

FAQ

Can JavaScript alone detect an anti-detect browser?

JavaScript catches some tells, like an inconsistent canvas reading or a screen size that contradicts the declared device, but the strongest evidence sits at the network and transport layer that page scripts can't reach. Reliable detection pairs the browser-side read with server-side signals, then scores how well the whole picture agrees: partly, not on its own.

Is anti-detect browser detection the same as bot detection?

Anti-detect browser detection and bot detection overlap but are not the same. Bot detection flags automation, like headless browsers or scripted input; anti-detect browser detection flags a human user running many disguised profiles to look like separate people. A session can pass a bot check and still be a disguised one, so the two work best together.

Does an anti-detect browser always mean fraud?

An anti-detect browser does not always mean fraud. QA testers, security researchers, and privacy-conscious users run them too, so an anti-detect signal is one risk input to weigh with the rest. The value is context: telling a one-off legitimate session apart from a coordinated pattern across accounts, then letting your own rules decide what to do.

Originally published on the ShieldLabs blog.

How to detect VPNs in 2026

Yahor Papou — Tue, 15 Sep 2026 13:32:36 GMT

In a nationally representative 2025 survey of U.S. adults, 32 percent said they currently use a VPN. At that scale, masked traffic is no longer an edge case you can wave away. It is a meaningful slice of every signup list, login flow, and checkout. Most of it is ordinary privacy behavior. A smaller share rides the same masking infrastructure to hide origin, fake a location, and scale abuse, from fake account creation to regional pricing fraud. The job in 2026 is no longer "is this a VPN, yes or no." It is telling normal privacy use apart from masked sessions that carry real risk.

Key takeaways

VPN detection is not a single IP lookup. What matters is whether the full session is masked, how consistent its signals are, and whether it overlaps with abuse.
An IP database check is a useful first pass, never a verdict. A clean IP can front a risky session, and a flagged IP can front a harmless one.
No single method is reliable alone. Strong detection combines database checks, network-path analysis, leak detection, header evidence, and cross-layer consistency.
Proxy detection is broader than VPN detection, but both are best handled as one masked-traffic model that ends in a risk decision, not a blanket block.

How do websites detect VPNs?

Websites detect VPNs by reading several independent signals from a session and scoring how consistently they describe one ordinary, direct connection. No single test is decisive. A database check classifies the IP, but the stronger evidence comes from comparing layers: does the network path look direct or routed, does the browser time zone match the IP location, do WebRTC or DNS reads leak a different origin than the visible request. When those layers disagree, the session is probably masked.

That is the whole shift. Old VPN detection asked a yes/no question about one IP. Modern detection asks whether the full picture holds together, then expresses the answer as a risk level rather than a hard label.

What is a VPN and how does it work?

A VPN (virtual private network) routes a user's traffic through a remote server, so the destination site sees the IP address of the exit server instead of the user's real IP. In most cases the connection between the device and the VPN endpoint is also encrypted. Relay-based privacy services work on similar logic: the real IP is hidden and exact geography is deliberately blurred. Apple's iCloud Private Relay, for example, maps a user to their general region through anonymous IPs without revealing exact location.

In practice, a VPN does three things:

Hides the real source IP and replaces it with the exit server's address.
Adds an intermediate network hop between the user and the site.
Lets the user pick an exit location, often in a different country or region.

That is why one tool serves privacy, security, and geo-dependent access all at once. A user in France can choose a Polish exit server, and a site relying only on IP geolocation will record the visit as traffic from Poland even though the real origin is elsewhere.

Why is VPN detection harder in 2026?

VPN detection is harder in 2026 because masking infrastructure is far more varied than it used to be. Classic VPN endpoints now sit alongside proxy routing, HTTP tunnels, relay-based privacy services, and Tor exits, and the line between them blurs in real traffic. Several trends pull in the same direction:

Relays reduce precision instead of faking a country. iCloud Private Relay maps the visitor to a broad region through shared anonymous IPs, so a plausible-looking geolocation no longer guarantees a trustworthy origin.
Residential and mobile proxies look like real users. Traffic exits through real consumer IPs and carrier-grade NAT ranges, so a flat "datacenter IP" rule misses it.
Masking layers stack. An anti-detect browser on a residential proxy can pass a naive IP check while still leaving cross-layer contradictions.

The result: a session can present a nominally clean, local-looking IP and still be masked. Detection has to read past the IP.

What methods are used to detect VPNs?

The methods used to detect VPNs fall into four groups: IP and connection intelligence, network and transport fingerprinting, connection-leak checks, and cross-layer consistency. The strongest detection blends all four and weighs them into one risk score, because no single method is decisive. Each method below is weak alone and resilient in combination.

IP and connection intelligence: match the address against VPN, proxy, Tor, relay, hosting, and datacenter ranges, then layer in reputation, ASN, reverse DNS, WHOIS ownership, geolocation, and datacenter-versus-residential classification, since most real visitors arrive on residential or mobile ranges.
Network and transport fingerprinting: passive TCP/IP fingerprinting infers the real operating system, the TLS handshake exposes a tunneling stack that differs from the declared browser, and an unusual path MTU, round-trip latency, or open proxy and VPN ports point to an encapsulating tunnel rather than a direct home connection.
Connection-leak checks: a WebRTC ICE candidate or a DNS query that bypasses the tunnel can surface a real-origin clue the visible IP hides, and forwarded headers sometimes carry traces of intermediary routing.
Cross-layer consistency: the browser-reported timezone and language are checked against the IP location, Tor exits are treated as their own category, and every tell is weighed into one score, so a session whose layers can contradict each other becomes its own anomaly.

The common thread across all of them: detection is about correlation, not any single check. A residential proxy or a relay that maps to a plausible local region raises the difficulty, but the more a session masks, the more layers it has to keep perfectly consistent. Consistency at scale is exactly what gives masked traffic away.

We weighed each group in turn: we tested masked sessions across these four groups, and the single IP check was consistently the weakest input and the cross-layer read was the strongest. A residential proxy could front a clean, local-looking IP, yet the timezone, a WebRTC leak, or the TLS handshake would still disagree with it somewhere in the session. Apple shipped iCloud Private Relay in 2021, and after that even a plausible geolocation stopped guaranteeing a trustworthy origin, which is why we weigh the layers together rather than trust any one of them and return the result as a risk score for your rules to act on.

Why does an IP-only check fail?

An IP-only check answers one narrow question: does this address resemble known masking infrastructure. It cannot tell you who is behind the visit, whether the environment is internally consistent, whether the same visitor appeared earlier under a different IP, or whether the session repeats behavior seen in earlier visits. That is why a single lookup almost always returns an incomplete answer.

Consider two signups from different IPs. The first is flagged as VPN traffic, the second is not. Look only at the IP and you treat them as unrelated. But device signals, time zone behavior, and a repeated account-creation flow can point to the same actor working both. The IP flag is an input. The decision needs device, browser, OS, network, and visitor-history context around it.

How is VPN detection different from proxy detection?

VPN detection and proxy detection overlap but are not the same. VPN detection is the narrower task, focused on encrypted tunneling services. Proxy detection is broader: it covers forward proxies, proxy tunnels, web proxies, and other intermediary routing methods, including HTTP tunnels where the proxy layer hides part of the original network path.

	VPN detection	Proxy detection
Scope	Encrypted tunneling services	Any intermediary routing layer
Typical infrastructure	Commercial VPN endpoints	Forward/web proxies, tunnels, residential proxies
Detection overlap	IP reputation, leaks, path analysis	Same signals, wider IP and routing coverage

For most businesses the more useful question is not "is this specifically a VPN" but "is this traffic masked, and does that masking raise the risk of evasion, abuse, or policy bypass." That framing covers both and points toward a risk decision instead of a label.

How do fraudsters misuse VPNs?

Fraudsters do not use VPNs because a VPN magically tricks a system. They use them because masking makes evasion cheaper: it hides real geography, rotates IPs, weakens IP-based rate limits, and lets the same user blend in with ordinary privacy traffic. So masked sessions show up across a familiar set of abuse cases:

Multi-accounting and fake account creation: one user running many "separate" users.
Bonus, promo, and free-trial abuse: cycling fresh sessions to claim a one-per-person reward again and again.
Regional pricing fraud: choosing an exit in a lower-priced country to buy a plan meant for a different purchasing-power segment.
Restriction and ban evasion: appearing to come from an allowed jurisdiction, or returning after a block under a fresh-looking session.

VPN use on its own is context, not a verdict. The risk climbs when masked traffic overlaps with environment inconsistencies, repeated account creation, linked devices, or behavior that repeats across visits. A corporate VPN login from an airport is masked and harmless; a masked session opening its tenth trial account this week is not. The difference is in the surrounding signals, which is exactly why detection has to look past the IP.

Detecting VPN and masked traffic with ShieldLabs

A VPN provider rotates its exit ranges constantly, so the IP list you blocked last month is already out of date. ShieldLabs keeps that read current for you instead. Drop in one JavaScript snippet and every visitor is scored in about five minutes, from install to first risk signal, with no friction for the person on the page.

The output is two things working together. A dedicated VPN signal flags when a visitor is masking their connection through a VPN, and a risk score weighs that against the rest of the session inconsistencies. The signal arrives inside a full set of risk signals, including anonymous proxy detection, Tor exit and datacenter flags, and others, so a masked session is never read on its IP alone. The VPN read sits inside the same proxy and VPN detection layer, since a connection hiding behind a VPN often hides behind a proxy too.

Because masking is most dangerous when it repeats, a stable identifier ties a "fresh" visit back to a returning device even after cleared cookies and rotated IPs. That is how ShieldLabs surfaces multi-accounting and account sharing: many accounts tied to one device, or one account signed in across many devices. The analytics dashboard rolls the same data up by traffic quality, so your team can tell anonymous traffic apart from trusted traffic at a glance and watch it as a trend over time rather than one visit at a time.

All of it, the risk score and the named risk signals, is available through an API and webhooks, so your team acts in its own flow and your rules decide the outcome to prevent abuse and fraud.

Sources

Security.org: 2025 VPN Trends, Statistics, and Consumer Opinions (nationally representative survey of 1,009 U.S. adults, 2025)
Apple: About iCloud Private Relay
IETF: RFC 1191: Path MTU Discovery
MDN Web Docs: RTCIceCandidate (WebRTC)
The Tor Project: Tor exit list service
Wikipedia: Virtual private network

FAQ

What is a VPN detector?

A VPN detector is a tool or detection system that determines whether traffic is routed through a VPN, proxy, Tor exit, iCloud Private Relay, or other masking infrastructure. In practice, a strong VPN detector goes well beyond a simple IP lookup and evaluates the broader session context: network-path behavior, time-zone and OS consistency, and leak checks.

How can I check if an IP is a VPN?

The first step is to match the IP against anonymizer, relay, Tor, proxy, and hosting datasets, which classify known masking ranges. That is a useful first-pass signal but not a production verdict on its own, because a clean-looking IP can still front a masked or risky session. Pair the IP check with session-level context before acting.

Does WebRTC help detect masked traffic?

WebRTC helps detect masked traffic because its ICE candidates can expose routing-related information that is compared against the visible request path. When the main request looks masked but the WebRTC data reveals a different network clue, that contradiction is a strong sign of incomplete masking.

How reliable is VPN detection against residential proxies?

Residential proxies are the hardest case, because traffic exits through a real consumer IP that no datacenter rule will catch. A reputation lookup alone often misses them. Detection holds up by reading past the IP: the network path, leak checks, time-zone and OS consistency, and whether the session repeats behavior seen in earlier visits. No method is perfect against a well-configured residential exit, but the more the session masks, the more layers it has to keep consistent, and that is where it slips.

Should companies block all VPN traffic?

Usually not. Most VPN use is ordinary privacy behavior, so blanket blocking creates false positives and friction for legitimate users. Risk scoring and proportionate action, such as extra verification only on high-risk masked sessions, work better than blocking everyone behind a VPN.

Is Tor the same as a VPN?

Tor is not the same as a VPN. Tor is a separate anonymity category with its own multi-relay and exit-node model, and exit nodes are published in a public list. A VPN routes through a single chosen exit server, while Tor bounces traffic through several relays, so the two are classified and weighted differently in detection.

Originally published on the ShieldLabs blog.