How Websites Recognize You After an IP Change: Browser Fingerprinting and Anti-Fraud

You switch IP addresses through a VPN, connect a mobile proxy, remove cookies and open a website in a new window. It may feel as if the server must now consider you a new visitor. Yet your network connection, browser and interaction patterns still expose numerous signals.

A browser fingerprint is not a magical hardware serial number or just a Canvas hash. It is a set of observations that websites may use to probabilistically link sessions, protect accounts, analyze traffic or track visitors.

This guide follows the process from network connection to fraud decision: IP, ASN, TLS/JA4, HTTP Client Hints, Canvas, WebGL, WebGPU, WebAssembly, WebRTC, cookies and behavioral signals. We then run a safe thought experiment and build a practical privacy model.

Vektor T13's material on CPU/GPU Canvas, WebAssembly and network fingerprints informed the topics. The explanation here is original and qualified against documentation from MDN, Cloudflare, Tor Project, EFF and academic research. Experimental approaches are labeled accordingly.

Consider a laptop running Chrome. It visits a website directly, then via a home VPN, and then through a cellular proxy. Each connection can expose a different IP and provider. Yet its installed fonts, rendering characteristics, supported APIs and many browser settings may stay similar.

If the visitor signs into the same account, linking is straightforward: the site already has an account identifier. Without a login, linking becomes statistical: how similar are the observations and is the evidence strong enough for a decision?

Changing an IP replaces one signal, not the entire digital identity. Conversely, a similar collection of signals does not prove a website knows the person. Millions of browsers can share common configurations.

An identifier is an assigned value: account ID, session cookie or application token. It can link activity within the relevant system while that value remains valid.

A fingerprint is a set of observed environmental properties. It may be rare or common, fairly stable or volatile. A hash is simply a convenient representation of those observations, not proof of a uniquely identified person.

A risk score estimates the likelihood of an outcome, such as automated traffic. A bot-likelihood score does not prove fraud and certainly does not prove someone's identity.

This distinction matters: one system may use fingerprints for correlation, another for anomaly detection, and a third only as one supporting feature.

A simplified flow has four layers. Network: a server or CDN observes a connection and network characteristics. TLS and HTTP: it examines handshake and request properties. Browser: once the page loads, permitted JavaScript may read web-platform features. Application: the backend combines this with logins, request history and interaction signals.

This is not necessarily one linear process. Some signals exist before JavaScript, others arise after user interaction, and many may not be collected at all. A site using a CDN and a self-hosted application can see different levels of detail.

The same technologies can support compatibility analytics, bot prevention or covert cross-site tracking. The privacy impact depends on collection purpose, data combination and retention.

An IP address indicates a network exit. An ASN identifies the autonomous system advertising that address: mobile carrier, residential ISP, data center or VPN infrastructure. IP geolocation is an estimate and can be wrong, especially for cellular networks and tunnels.

Residential IPs can change, many mobile subscribers can share an external IP through carrier-grade NAT, and a server proxy may serve multiple customers. Thus one IP is not one person, and one person does not always have one IP.

Fraud prevention may consider network category, prior abuse and abrupt route changes. A data-center IP does not automatically prove automation, nor does a mobile IP prove a real human. These are contextual signals.

During TLS setup, the client normally sends a ClientHello listing supported versions, ciphers, extensions and other parameters. Those choices can be summarized as a fingerprint of the client implementation.

JA3 and JA4 are ways to represent portions of this handshake. JA4 normalizes certain variable details, including extension order, to group similar clients more consistently. Cloudflare documents JA3/JA4 as Bot Management signals.

Crucially, this is not a unique hardware ID. Thousands of installations of the same browser version may share a fingerprint. It depends on TLS implementation, configuration and the vantage point observing the handshake. A proxy that terminates TLS on behalf of a client may change what the destination observes.

Changing IP need not change JA4. A matching JA4 does not, by itself, identify a particular device.

Beyond TLS lie more implementation details: protocol negotiation, message ordering and settings, HTTP/2 behavior and QUIC characteristics. These signals may help classify client stacks and intermediaries.

Vektor T13 has discussed M1D/M1D1 approaches to TCP, UDP and QUIC network fingerprinting. These are interesting research and implementation topics, but specific proprietary or experimental labels must not be treated as universally validated open standards.

The observer's location is crucial. A website behind a VPN exit does not necessarily see the original device's TCP socket characteristics. HTTP proxying, SOCKS, TCP tunnels and terminating TLS proxies change observable properties in different ways.

Fraud systems can only analyze signals actually available at their observation points, not every aspect of a remote computer's network stack.

A valid session cookie can identify a returning browser without Canvas, WebGL or TLS analysis. LocalStorage and other web storage can also hold identifiers within their security boundaries.

Logging into the same account changes the problem entirely: the service knows the account even across different devices, IP addresses and browsers. A fingerprint may help assess whether the login environment is familiar, but it is not needed to link the account.

Deleting cookies can remove one persistent identifier without resetting all other signals. Conversely, matching fingerprints do not imply matching cookies or people.

The traditional User-Agent reports browser family and version, platform and some OS information. Modern browsers reduce details in UA strings because verbose strings can support fingerprinting.

In Chromium, some information is exposed through User-Agent Client Hints, such as Sec-CH-UA, Sec-CH-UA-Platform and other fields that a website may request. Availability depends on browser implementation, permissions policies and context.

Changing a UA string is easy but does not make the rest of the environment match its claim. A service may compare UA with supported web features. Inconsistency can be a signal, but not proof of malicious behavior on its own.

Canvas lets websites draw text, lines and shapes. Scripts can read pixels and hash the result. Output may depend on the rendering engine, fonts, graphics library, scaling, OS and rendering path.

A useful nuance from Vektor T13's Canvas work: Canvas does not always mean GPU. Some operations may use CPU-based rasterization or rendering libraries while others use GPU acceleration. Switching acceleration or environments may change output, but need not always do so.

A Canvas hash is not a graphics-card serial number. Multiple devices may produce the same hash, and one device may change hashes after updates or settings changes. Its usefulness depends on population distribution and stability over time.

WebGL exposes information about available graphics capabilities. In some browsers, the WEBGL_debug_renderer_info extension may expose vendor and renderer strings. Privacy settings can limit that access.

WebGPU provides a different API surface, including GPU computation and adapter details through GPUAdapterInfo where supported. Browsers can reduce detail or return empty and generalized fields. WebGPU support varies across platforms.

Execution characteristics can be measured, but results depend on drivers, load, temperature, power state and implementation. This is not direct access to a hardware serial number. GPU-related signals may help group environments in some studies, yet accuracy requires controlled validation.

A website can infer the availability of some fonts indirectly by comparing rendered text dimensions with fallback fonts. CSS, ClientRects, window geometry, devicePixelRatio, language and timezone contribute additional observations.

However, websites do not automatically receive a complete system font inventory or all OS details. Browser restrictions vary and different techniques measure different information.

Rare combinations can single out a session more strongly than one unusual field. Yet features are correlated: certain operating systems tend to ship with certain fonts and APIs. You cannot simply add the theoretical entropy of all features and declare the total a unique identity.

AudioContext can generate and process synthetic audio, whose numerical output may be measured. WebAssembly allows code to execute with performance characteristics different from ordinary JavaScript. That creates additional opportunities to measure environmental variation.

These methods have limits. CPU load, power management, browser updates, OS scheduling and browser privacy policies add noise. Matching results do not guarantee a single device, and differing results do not guarantee different devices.

Research into WebAssembly fingerprinting is interesting, including Vektor T13 demonstrations, but ordinary WASM running on a webpage does not automatically gain access to MAC addresses, disk serial numbers or hardware UUIDs. Browser sandbox permissions still apply.

WebRTC uses connectivity discovery mechanisms such as ICE candidates. Depending on browser, permissions and network setup, these may expose local or public network addresses. Modern browsers apply safeguards, including mDNS-based local address obfuscation.

Distinguish a real IP leak, local addressing and ordinary browser fingerprinting. They are different information classes. WebRTC is not a universal API for reading a network card's MAC address.

Likewise, DNS requests can bypass an intended routing policy, but a DNS leak is not a unique personal identifier. Test browser proxies and host VPNs separately at their relevant network layers.

Imagine an online store. It sees network requests, session history, possible automation signals and account state. It may run custom rules, a bot-defense provider or several systems together.

Cloudflare documents Bot Score as an estimate of automated-request likelihood, not a verdict about who someone is. Depending on policy it may support allowing, challenging or blocking a request. Larger systems combine heuristics, browser checks and machine learning.

Payment fraud and bot prevention overlap but are not identical. Payment risk involves transaction context and abuse indicators; it cannot be reduced to a browser hash.

A professional system must account for false positives: VPN users, assistive technologies, corporate proxies and unusual hardware can look atypical without being malicious.

Within a service, navigation history, timing between requests, URL reuse, action sequences and session dynamics may contribute to risk assessment. Every feature has limitations, and predictable behavior should not be equated with personal identity.

A website sees activity within its own application. A third party sees events only where it actually has access to scripts, logs or data sharing. The claim that any anti-fraud provider can see every user across all websites is unsound.

For privacy, data-sharing boundaries, third-party scripts and cross-site identifiers matter. For site operators, explainability, retention and false-positive remediation matter.

An anti-detect browser can separate profiles, manage cookies and some exposed API values, and assign proxies per profile. This can support legitimate work context separation where services permit it.

But it is not full OS isolation. Profiles may share a kernel, disk, system libraries and network services. Spoofed browser properties may create inconsistencies or unusual combinations that ordinary devices do not exhibit.

A common mistake is testing only whether a Canvas hash changed. Changing one value does not prove the entire observable environment changed. Conversely, a matching value does not guarantee detection.

For stronger protection, separate tasks across VMs or devices. For private browsing, evaluate fingerprint-resistance measures such as Tor Browser rather than trusting promises of an "invisible profile".

A mobile proxy can route a connection through 4G/5G infrastructure. Carriers may use CGNAT and public addresses may rotate. Your copy of Chrome still runs on the same laptop with the same web-platform APIs.

The public IP, network category, approximate geography and latency might change. Cookies, font availability, rendering and some TLS behavior can remain unless an intermediary alters them.

Takeaway: proxies control connection routes. Browser compartmentalization controls application state. Virtual machines provide stronger environment boundaries. These layers are not interchangeable.

Imagine two users produce the same Canvas hash. That can be an ordinary collision among common configurations. Matching WebGL, UA and language may strengthen similarity, but several of these properties are dependent.

Researchers evaluate distinguishing information using entropy and empirical distributions. Simply adding entropy estimates can substantially overstate identifiability. The 2024 study *Assessing Web Fingerprinting Risk* explicitly models dependencies among APIs.

Two errors matter: falsely linking different visitors and failing to recognize the same browser after changes. A credible model evaluates rarity, stability, population size and error rates.

A public checker reveals what that particular test can observe. It cannot prove what every other website collects.

You can run this experiment on your own device, without bypassing a third party's fraud controls or uploading someone else's information.

Session A. In a standard browser, open EFF Cover Your Tracks and a diagnostic page you control. Record the visible IP, browser version, whether cookies are present, reported feature fields and test time.

Session B. Keep the browser and profile unchanged and connect through an authorized VPN or proxy. Compare your own data: which network attributes changed and which browser signals remained.

Session C. Use a clean browser profile or a different browser without personal account logins. Repeat the observations. If appropriate, test an unmodified Tor Browser as well.

The goal is not to "beat anti-fraud". It is to distinguish network-, profile- and browser-dependent observations. Avoid publishing a full fingerprint alongside personal identifiers and review the testing service's data handling.

For routine privacy, keep browsers current, limit third-party trackers, clear unneeded site data and avoid linking contexts to the same account without a reason. Separate personal and work activity into profiles or environments.

Tor Browser deliberately reduces distinguishability through letterboxing, font information controls, UA normalization and other anti-fingerprinting measures. Random extensions and ad-hoc spoofing can undermine the intended benefits.

When one session must not access another's data, use VMs or separate devices. Use VPNs with sound DNS/IPv6 policies to protect the network path, but do not confuse this with making browsers unrecognizable.

A good configuration is one with a defined adversary and verifiable properties.

If you operate a service, distinguish abuse prevention from unrestricted user tracking. Collect only necessary features, apply bounded retention, restrict telemetry access and define how each risk score may affect an account.

Rather than automatically penalizing a "suspicious fingerprint", consider graduated controls: contextual verification, step-up authentication when justified, request limits and manual review procedures for disputes.

Fraud models inevitably make mistakes. Adaptive systems change over time, so monitor false positives and the impact of rules on real users. Legal requirements for tracking and notices vary by jurisdiction.

The clearer the purpose of each signal and the shorter its lifetime, the easier it is to protect both users and infrastructure.

"A new IP makes me a new person." No; accounts and browser traits may persist.

"Every Canvas hash is unique." No; collisions and changes occur.

"JA4 reads my laptop serial number." No; it summarizes TLS-client characteristics.

"WebAssembly can read all hardware." No; browser sandboxing remains, and measurements are probabilistic.

"Mobile IP addresses cannot be classified." No; network category is one input.

"An anti-detect profile equals a virtual machine." No; their isolation boundaries differ.

"Anti-fraud always knows someone's identity from a fingerprint." No; risk estimation and reliable identification are different.

Treat privacy architecture as four areas of responsibility.

Network: IP, DNS, TLS, proxies, VPNs and routing. Browser: cookies, web APIs, cross-site trackers and fingerprint defenses. Environment: OS, VMs, separate devices and file transfers. Behavior: accounts, reused identifiers, disclosed information and operational habits.

Some characteristics must remain observable for the web to function. The goal is not to spoof everything, but to reduce unnecessary observability and prevent separate contexts from merging.

A website need not know you through one feature. It may draw conclusions from many weak signals. Privacy therefore needs coordinated boundaries, not a single "change IP" button.

Before judging a browser's privacy, ask: Does the site already know your account or session cookie? Did only the IP change, or did the whole environment change? Which fields can JavaScript read? Who observes TLS and transport? Are third-party analytics involved? How long are identifiers retained? What changes when you switch profile, browser or device?

Run the three safe comparisons in section 19 and explain each observation without making claims of "invisibility". That teaches more than attempting to create a uniquely random fingerprint.

For further reading, Signal's mobile proxy and privacy architecture guides cover network routes and compartmentalization that complement this article.

Cloudflare - JA3/JA4 fingerprint
Cloudflare - Bot Score
Cloudflare - Bot detection engines
MDN - User-Agent Client Hints
MDN - WEBGL_debug_renderer_info
MDN - GPUAdapterInfo
MDN - WebRTC ICE candidate address
Tor Project - Fingerprinting protections
EFF - Cover Your Tracks
Research - Assessing Web Fingerprinting Risk (2024)
Vektor T13 - CPU vs GPU Canvas webinar
Vektor T13 - WebAssembly fingerprinting
Vektor T13 - M1D/M1D1 network fingerprints