A website does not need to “break” a VPN or learn a user's original IP to infer that a connection may use a VPN, proxy server, or Tor. It can classify the current egress, then combine ASN, network type, recent traffic, WebRTC, DNS, IPv4 and IPv6, browser traits, automation, cookies, and account history.
Changing only the egress IP changes one field. The browser, device, account, and operating pattern can remain recognizable.
The short answer
- Sites use multiple signals, not only one blocklist.
- Tor exits are readily observed because they must connect to public sites.
- Commercial VPNs are often identified through known ranges, hosting ASNs, shared traffic, and provider observations.
- Residential proxies look like consumer access but can reveal temporal, device, and proxy-network patterns.
- Hosting, VPN, proxy, Tor, relay, and residential proxy are distinct classifications.
- WebRTC, DNS, and IPv4/IPv6 inconsistencies are supporting evidence, not proof by themselves.
- Browser fingerprint and automation data can show that a normal-looking IP is paired with an unusual client.
- Cookies, devices, and account history link activity across IP changes.
- Detecting anonymization does not necessarily reveal the original IP.
- Enterprise VPNs, roaming, CGNAT, and privacy services create false positives that require context.
Check VPN, proxy, Tor, and environment consistency
About the Caylet model (1.6.0): Caylet distinguishes confirmed findings, absence from an available source, and no data. The last two do not prove safety. Only valid Scamalytics and AbuseIPDB numbers enter the composite. IP2Location and Feodo Tracker remain separate, and IPinfo Lite supplies ASN context only.
How do VPNs, proxies, and Tor differ?
| Type | Basic role | What the site sees | Typical identification |
|---|---|---|---|
| VPN | Encrypts and tunnels traffic to an egress server | VPN egress IP | Known service ranges, hosting, sharing, observations |
| Proxy | Forwards selected application traffic | Proxy egress IP | Public lists, behavior, headers, service data |
| Tor | Routes through multiple relays and an exit | Tor exit IP | Publicly observable exit-relay set |
A VPN often covers system traffic; an application proxy may handle only specific requests; Tor uses onion routing across independently operated relays. None of these labels alone proves fraud.
Layer one: IP intelligence
Anonymous-IP databases can report VPN, proxy, public proxy, Tor exit, hosting, relay, residential proxy, service name, confidence, and first/last seen. Keeping them separate matters: hosting does not prove forwarding, and a residential proxy can simultaneously be residential by source and proxy by use.
How are commercial VPN ranges identified?
Providers can install and observe VPN products, collect configuration or endpoints, compare provider and registry data, watch service traffic, and receive feedback across customers. A range may be identified when it repeatedly behaves like a shared egress even before every address appears in a public list.
Why are ASN and hosting useful?
ASN reveals the routing network. A consumer sign-in from a cloud or hosting ASN is less typical than one from a home or mobile carrier, so it can contribute context. It is not decisive: companies run legitimate cloud egress, carriers reassign hosting space, and a VPN can use residential networks.
Learn how ASN, ISP, and organization names differ.
Why is Tor usually easier to identify?
Tor exits contact destination websites directly. Exit operation and policy are observable, so services can maintain current exit sets. A site can therefore say that its peer IP is a Tor exit without decrypting Tor or tracing the user through the network.
Platforms may treat Tor more cautiously because exits are shared, identity continuity is weak, abuse can affect the whole exit, and some regulated or sensitive flows require stronger location or device assurance. That is a risk-control choice, not proof that Tor traffic is malicious.
How are public proxies identified?
Public proxy lists can come from advertisements, scans, user submissions, provider telemetry, and observed forwarding. Proxy behavior may include many unrelated clients, unusual ports, rapid geographic variation, or headers added by poorly configured proxies.
Headers such as Forwarded, Via, or X-Forwarded-For can expose an intermediary in some deployments, but a user can forge them and well-configured proxies may omit them. A security system must not trust unverified forwarding headers as authoritative client identity.
Why are residential proxies harder?
Their exits genuinely belong to home or mobile ISPs, so ASN and connection type resemble ordinary users. Detection can still use direct service observation; first seen, last seen, and active periods; device and traffic distribution; associated provider data; and repeated behavior across customers.
A rotating residential proxy changes egress frequently, while a static residential proxy keeps one consumer-looking address longer. Neither should be confused with an ordinary household merely because the network is residential.
Learn the differences among residential, mobile, data center, and business IPs.
Layer two: sharing and behavior
Providers can examine connection velocity, many accounts or geographies behind one address, repetitive request patterns, automation, unusual active hours, short sessions, failed logins, scraping, and rapid identity changes.
Sharing alone is insufficient. Mobile CGNAT, offices, hotels, universities, and families legitimately share. One request cannot reveal the exact number of people behind NAT. The pattern must be compared with the network type and time window.
Layer three: IP, DNS, WebRTC, IPv4, and IPv6
WebRTC
ICE candidates may reveal local, server-reflexive, or relay addresses. Another public address on a different ASN or country can suggest an alternate path, incomplete VPN coverage, split tunneling, or a second interface. A private 192.168.x.x address is not the household's public IP.
No additional candidate means only that this browser/test did not observe one. Browser privacy handling, mDNS, policy, permissions, or test failure can limit evidence.
DNS
A DNS test often sees the recursive resolver, not the user's original IP. A resolver outside the expected VPN path can indicate a DNS leak, but public Anycast DNS, browser DNS over HTTPS, corporate security, and roaming can also explain a different network or country.
IPv4 and IPv6
A VPN may tunnel IPv4 while IPv6 remains direct, or the protocols may use different providers. Comparing both is more useful than assuming one lookup represents the whole connection.
Layer four: browser fingerprint and consistency
A site can compare time zone, languages, User-Agent and Client Hints, screen, CPU hints, WebGL/GPU strings, storage, fonts or rendering, and other privacy-limited traits. It may ask whether the claimed platform agrees with rendering, whether time zone makes sense for the route, and whether the current device resembles prior sessions.
Language mismatch is weak evidence. Travelers, immigrants, international teams, and multilingual users routinely use a language unrelated to their current IP country.
Layer five: automation and headless browsers
navigator.webdriver=true indicates browser automation in standard circumstances, but false does not prove a human. Sites can also test JavaScript behavior, event timing, rendering APIs, missing browser capabilities, request/header consistency, and behavior at scale.
Automated clients may declare a consumer browser while sending inconsistent headers or exhibiting impossible interaction patterns. Every individual test can have legitimate explanations, so combined evidence is more valuable.
Layer six: cookies, devices, and account history
Cookies and local storage associate sessions. Apps can use installation identifiers, device-bound keys, passkeys, and push tokens. Account history supplies normal countries, devices, hours, authentication, and action patterns. Behavior adds navigation, request velocity, typing or interaction timing, and post-login actions.
These records explain why changing an IP does not erase an established relationship.
Layer seven: first-party intelligence
A platform sees information that an external IP checker cannot: abuse and chargebacks on its service, account clusters, content and messaging patterns, payment instruments, recovery events, internal device trust, and past enforcement. Its VPN decision can therefore differ from a public database without either dataset being universally wrong.
What does not change when only the IP changes?
- cookies and signed-in accounts
- device or app identifiers
- browser and operating system traits
- time zone and language
- screen and hardware hints
- automation environment
- payment or recovery details
- account relationships
- interaction and request patterns
A new IP is a new route, not automatically a new person.
Does VPN detection reveal the real IP?
No. A site may classify the egress from known service data without knowing the upstream subscriber. It gains more only when another public path appears through IPv6 or WebRTC, a trusted prior session recorded a different IP, or first-party account/device data links the environments.
Why does one website detect what another misses?
They can use different intelligence providers, update times, browser permissions, first-party histories, risk tolerance, and targets. A bank, social network, and streaming or AI service solve different problems.
Common false positives
Enterprise VPNs, mobile CGNAT, hotel and airport Wi-Fi, Apple Private Relay and similar privacy relays, antivirus or secure web gateways, roaming eSIMs, and Anycast/public DNS can all resemble part of an anonymized pattern. The service should ask for proportionate verification rather than treating one label as proof of fraud.
Reducing false positives during normal use
- Use a stable, legitimate network when completing sensitive changes.
- Keep the browser, operating system, and official app updated.
- Complete ordinary strong authentication such as a passkey or MFA.
- Avoid rapid switching among unrelated egress countries during one session.
- Do not stack several unknown VPN, proxy, and extension products.
- If a corporate VPN is required, use the organization's supported setup.
- Review IPv4, IPv6, DNS, and split-tunnel behavior when troubleshooting.
- Do not falsify browser settings simply to match an IP country.
How should Caylet present detection?
First show raw network identity: IP, country, ASN, organization, and connection type. Then keep VPN, proxy, Tor, hosting, relay, and residential proxy as separate three-state fields. Next show WebRTC, IPv4/IPv6, DNS limitations, time zone, and browser evidence. Finally provide an explainable summary with sources, timestamps, conflicts, and missing data.
unknown must never become false. Caylet does not run a DNS leak test, so it must not claim a DNS leak conclusion from unavailable observations.
Use Caylet to check anonymization and browser context
Common misconceptions
- Detecting a VPN does not mean discovering the original IP.
- Proxies are not limited to data center ranges.
- Disabling WebRTC does not defeat all VPN detection.
- Listing a Tor exit does not mean Tor was broken.
- Missing a VPN database match does not prove no VPN.
VPN=truedoes not prove user fraud.- A residential address does not create a new identity.
Frequently asked questions
Can a site identify a VPN with 100% certainty?
Usually not from one signal. A known commercial exit can be identified with high confidence, while a new or private exit can evade a particular source.
Does detection reveal my real IP?
Not necessarily. Classification of the egress and discovery of an upstream address are different events.
Why is Tor easier to identify?
Its exit relays directly reach public websites and can be observed. That does not expose the user's source inside Tor.
Why can residential proxies be detected?
Service observation, timestamps, device activity, traffic distribution, and cross-customer patterns can reveal forwarding even on a consumer ASN.
Does disabling WebRTC solve it?
No. IP intelligence, DNS, protocol paths, browser signals, cookies, history, and behavior remain.
Why am I recognized after changing IP?
The account, device, cookies, browser, and behavior can remain linked.
Summary
Websites detect VPNs, proxies, and Tor by combining IP intelligence with network paths, browser consistency, automation, cookies, devices, accounts, and first-party behavior. No one signal is universally decisive, and detecting an anonymized egress does not necessarily reveal the original address.
Because changing IP modifies only one component, the rest of the environment can remain recognizable. Accurate systems preserve separate labels, missing-data states, and legitimate explanations rather than treating every VPN, corporate gateway, roaming path, or shared network as fraud.
Primary sources
- MaxMind, GeoIP Anonymous IP Databases and Anonymous Plus Databases
- MaxMind, GeoIP Residential Proxy Databases
- IPinfo, Privacy Detection Extended API
- Tor Project, Lifecycle of a Tor Exit and Exit Relay
- MDN Web Docs, Fingerprinting and Navigator.webdriver
- RFC Editor, RFC 8828 and RFC 8826
- Cloudflare, Bot Detection Engines and Bot Scores
This article provides general networking and security education. Detection coverage and classification change over time. A result is not an official decision by another platform and does not guarantee account or service availability.