VPN Privacy Test: Check Visible IP, DNS, WebRTC and IPv6 Signals

By Katia Belokon

Run the matching VPN checks

Best next step: use the VPN Leak Test first, then compare focused results with the DNS Leak Test, WebRTC Leak Test, and IPv6 Leak Test.

Read the limits: MyIPScan reviews visible browser/session signals. It does not audit the VPN provider, every app, every device, or account-level privacy.

Quick Answer

A VPN privacy test should compare the browser-session signals before and after connection: public IP, DNS resolver route, WebRTC candidates, IPv6 visibility, and browser-visible traits.

A clean-looking result may reduce obvious exposure in this session, but it does not certify provider privacy, account safety, every app, every device, or every future connection.

What a VPN Privacy Test Actually Measures

When you run a vpn privacy test, you are checking whether your visible network signals match the VPN connection you expect. The test does not measure what every website, app, or service knows about you—it measures the technical signals your device sends during a connection.

Public IP Address

The public IP address is the most visible signal. Before you connect to a VPN, your device uses an IP address assigned by your internet service provider. After you connect, the VPN should replace that address with one from its own network. You can verify this by visiting MyIPScan before and after connecting, then comparing the address, network name, and approximate location.

A successful change means websites see the VPN’s IP address instead of your ISP’s. But this does not automatically hide account logins, payment history, browser cookies, or app telemetry. The IP address is one layer, not a complete identity reset.

DNS Resolver Behavior

DNS lookups translate domain names into IP addresses. When you type a website address, your device asks a DNS resolver to find the corresponding IP address. If your VPN routes all traffic but your browser or operating system still uses your ISP’s DNS resolver, that mismatch can reveal which websites you visit.

A DNS leak test checks whether your DNS queries go through the VPN or bypass it. This matters because DNS behavior is separate from the IP address path. A browser can use secure DNS, an operating system can override VPN DNS settings, and mobile apps can use hard-coded resolvers. For more background, see our guide on what is a DNS leak.

WebRTC and Browser Leaks

WebRTC is a browser feature that enables real-time communication. In some configurations, WebRTC can expose your local IP address or your ISP’s IP address even when a VPN is active. This happens because WebRTC tries to establish direct peer connections, and those attempts can bypass the VPN tunnel.

A WebRTC leak test checks whether your browser reveals IP addresses outside the VPN path. Not every WebRTC result is a critical leak—local network addresses are often harmless—but if your ISP’s public IP appears in a WebRTC check while your main IP test shows the VPN address, that split deserves attention.

Signals That Remain Visible

A vpn privacy test focuses on network-level signals, but many identity signals operate above the network layer. Changing your IP address does not erase these signals.

Account and Cookie Signals

When you sign into an account, the service links your session to that account regardless of your IP address. Cookies, local storage, and session tokens persist across network changes. If you log into the same email, social media, or payment account before and after connecting to a VPN, the service can still connect those sessions.

This is not a VPN failure—it is how account-based identity works. A VPN changes the network path, but it does not log you out or erase browser storage. For high-privacy scenarios, use a clean browser profile, avoid signing into personal accounts, and clear cookies between sessions.

Device and Browser Fingerprints

Browser configuration creates recognizable patterns. Time zone, language, screen resolution, installed fonts, enabled extensions, and canvas fingerprints can identify your device even when the IP address changes. These signals are separate from the network layer, so a successful IP change does not remove them.

Advanced tracking combines IP address, browser fingerprint, and behavioral patterns. A VPN addresses the first layer, but the other layers require additional controls: disabling unnecessary extensions, using privacy-focused browser settings, and avoiding unique configurations that make your device stand out.

App and Operating System Telemetry

Mobile apps and desktop software can send telemetry, crash reports, and usage data outside the browser. Some apps use hard-coded servers, bypass VPN tunnels through split routing, or send device identifiers that persist across network changes. A browser-based IP test will not catch these signals.

If privacy matters for a specific app, check whether the app respects system-wide VPN settings, review its privacy policy, and test network behavior with a packet capture tool or firewall log. A clean browser test does not guarantee that every app on the device routes traffic through the VPN.

How to Run a VPN Privacy Test

A reliable vpn privacy test follows a structured before and-after process. The goal is to isolate one change at a time and compare results across multiple checks.

Step 1: Establish a Baseline

Before you connect to a VPN, record your current network state. Visit MyIPScan and note your public IP address, ISP name, and approximate location. Run a DNS leak test and check which DNS resolvers appear. If you want to test WebRTC, use a WebRTC leak checker and record any IP addresses it reveals.

Save these results. The baseline shows what websites and services see before you make any changes. Without a baseline, you cannot measure whether the VPN actually changes your visible signals.

Step 2: Connect to the VPN

Connect to your VPN and wait for the connection to stabilize. Most VPN clients show a connected status, but that status does not guarantee that all traffic routes through the tunnel. Some systems use split tunneling, some browsers use independent DNS settings, and some apps bypass VPN routes entirely.

Do not assume the connection works as expected. The next step is to verify.

Step 3: Repeat the Same Checks

Visit the same tools you used in step one. Check your public IP address, DNS resolvers, and WebRTC behavior. Compare the new results to your baseline. A successful VPN connection should show a different public IP address, DNS resolvers that match the VPN provider, and no WebRTC leaks that expose your ISP’s IP.

If only one signal changes while others remain the same, investigate the mismatch. A changed IP address with unchanged DNS suggests a DNS leak. A changed IP with a WebRTC leak suggests browser configuration issues. A changed IP with the same account login means the service still knows who you are.

Step 4: Test Across Multiple Tools

No single tool covers every signal. Use at least two independent checkers to confirm your results. If one tool shows a clean result and another shows a leak, investigate the difference. Tools can check different signals, use different detection methods, or rely on different databases.

Cross checking reduces the risk of false confidence. A single clean result is not proof of privacy. Consistent results across multiple tools are more reliable.

Common Mistakes When Interpreting Results

Reading Location Too Precisely

IP-based location is approximate. Geolocation databases map IP addresses to cities, regions, or data centers, but these mappings are not always accurate. An IP address can appear in a neighboring city, a different region, or even a different country if the VPN provider uses shared infrastructure or if the database is outdated.

Do not treat location as a precise physical address. The useful question is whether the location matches the VPN server you selected and whether the result is consistent across repeated checks. A surprising location is not automatically a leak—it may reflect how the VPN provider routes traffic or how the geolocation database labels that network.

Ignoring Split Traffic

Some VPN configurations route only part of your traffic through the tunnel. Split tunneling allows specific apps or websites to bypass the VPN, which can be useful for local network access or performance reasons. But split tunneling also means that a browser-based IP test may show the VPN address while other apps still use your ISP’s connection.

If your IP test looks clean but DNS or app behavior looks different, check your VPN settings for split tunneling, app exclusions, or kill switch configuration. A partial result is not necessarily a failure—it may be the intended behavior.

Confusing Network Signals with Account Identity

A clean IP test does not mean you are anonymous. If you sign into an account, the service knows who you are regardless of your IP address. If you use the same browser profile, cookies and local storage persist. If you use the same payment method, transaction history links your sessions.

Network-level privacy and account-level privacy are separate layers. A VPN addresses the first layer. The second layer requires additional controls: separate accounts, clean browser profiles, and careful management of cookies and storage.

Signal Checklist

Signal	What It Reveals	How to Check
Public IP Address	Visible network endpoint and approximate location	Compare before and after using MyIPScan
DNS Resolver	Where domain lookups are resolved	Run a DNS leak test
WebRTC Leaks	Local or ISP IP addresses exposed by browser	Use a WebRTC leak checker
Account Session	Whether a service links the session to a known account	Test in a clean browser profile without signing in
Browser Fingerprint	Time zone, language, extensions, screen size, fonts	Compare across browser profiles or privacy tools
App Telemetry	Data sent by apps outside the browser	Review firewall logs or use packet capture tools

When a Clean Result Still Leaves Gaps

A successful vpn privacy test shows that your VPN routes traffic as expected, but it does not prove total privacy. Privacy depends on multiple layers, and a clean network test addresses only one layer.

Shared VPN IP Addresses

Many VPN providers use shared IP addresses, where multiple users connect through the same public IP. This can improve privacy by making it harder to link activity to a specific user, but it does not prevent account-based tracking, browser fingerprinting, or app telemetry.

Shared IPs reduce the uniqueness of the network signal, but they do not erase the other signals your device sends. If privacy matters, combine a VPN with other controls: clean browser profiles, minimal extensions, and careful account management.

HTTPS and End-to-End Encryption

A VPN encrypts traffic between your device and the VPN server, but it does not encrypt traffic between the VPN server and the destination website. If you visit an HTTPS website, the connection is encrypted end-to-end. If you visit an HTTP website, the VPN provider and any network observer between the VPN server and the website can see the content.

Always prefer HTTPS. A VPN protects the first leg of the connection, but HTTPS protects the entire path. A clean IP test does not guarantee that every website you visit uses secure connections.

VPN Provider Logging

A VPN shifts trust from your ISP to the VPN provider. If the provider logs connection times, IP addresses, or traffic metadata, those logs can link your activity to your account. A clean IP test does not reveal what the provider logs or how they handle data requests.

Review the provider’s privacy policy, look for independent audits, and understand the jurisdiction where the provider operates. A successful IP test shows that the VPN routes traffic, but it does not prove that the provider respects your privacy.

How to Interpret Mismatches

Location Mismatch

If the IP address location does not match the VPN server you selected, check whether the provider uses virtual locations, shared infrastructure, or routing through third-party networks. Some providers label servers by the country where the IP is registered, not where the physical server is located.

A location mismatch is not always a leak. It may reflect how the provider manages its network. The useful check is whether the IP address belongs to the VPN provider and whether the result is consistent across repeated tests.

DNS Mismatch

If your IP address shows the VPN but your DNS resolvers show your ISP, you have a DNS leak. This can happen when the operating system or browser uses independent DNS settings, when the VPN does not configure DNS correctly, or when secure DNS features override the VPN’s DNS.

To fix a DNS leak, check your VPN settings for DNS configuration options, disable secure DNS in your browser, and verify that the operating system uses the VPN’s DNS servers. Repeat the DNS leak test after each change to confirm the fix.

WebRTC Mismatch

If a WebRTC test reveals your ISP’s IP address while your main IP test shows the VPN, your browser is leaking IP information through WebRTC. This happens because WebRTC tries to establish direct connections, and those attempts can bypass the VPN tunnel.

To fix a WebRTC leak, disable WebRTC in your browser, use a browser extension that blocks WebRTC, or switch to a browser with built-in WebRTC protection. Test again after making the change to confirm the leak is resolved.

Practical Privacy Layers Beyond the VPN Test

A vpn privacy test is one diagnostic step, not a complete privacy solution. Effective privacy combines multiple layers.

Use Clean Browser Profiles

Create a separate browser profile for high-privacy tasks. Do not sign into personal accounts, do not sync browser data, and clear cookies and storage after each session. A clean profile reduces the risk that browser-based signals link your activity across sessions.

Review Browser Extensions

Extensions can access browsing data, inject scripts, and create unique fingerprints. Disable unnecessary extensions, review permissions for the extensions you keep, and test whether extensions change your IP test results. Some extensions interfere with VPN routing or DNS behavior.

Keep Software Updated

Security vulnerabilities can expose traffic outside the VPN tunnel. Keep your operating system, browser, and VPN client updated. Enable automatic updates when possible, and review release notes for security fixes.

Test After Configuration Changes

Any time you change VPN settings, browser configuration, or network setup, repeat your privacy tests. A setting that worked yesterday may break after an update, and a clean result can turn into a leak after a configuration change. Regular testing catches problems before they expose sensitive activity.

Decision Points for High-Risk Scenarios

If you face serious privacy risks—such as surveillance, censorship, or targeted threats—a basic VPN test is not enough. Consider these additional controls:

• Use a dedicated device for high-risk activity, with no personal accounts or identifying data.
• Combine a VPN with Tor for additional routing layers, but understand the performance and usability trade-offs.
• Avoid signing into any account that links to your real identity.
• Use end-to-end encrypted communication tools that do not rely on the VPN for security.
• Test your setup from multiple networks and multiple tools to confirm consistent results.
• Review the VPN provider’s jurisdiction, logging policy, and history of responding to data requests.

High-risk scenarios require threat modeling, not just technical tests. Understand who you are protecting against, what they can observe, and which layers of your setup are most vulnerable.

FAQ

What does a VPN privacy test actually prove?

A VPN privacy test shows whether your VPN changes your visible network signals—specifically your public IP address, DNS resolver, and WebRTC behavior. It does not prove that you are anonymous, that every app routes through the VPN, or that the VPN provider respects your privacy. The test measures technical signals, not total privacy.

Why does my IP location look wrong after connecting to a VPN?

IP-based location is approximate and depends on geolocation databases that may be outdated or inaccurate. VPN providers sometimes use virtual locations, shared infrastructure, or routing through third-party networks. A surprising location is not automatically a leak—check whether the IP address belongs to the VPN provider and whether the result is consistent across repeated tests.

What is a DNS leak and how do I fix it?

A DNS leak happens when your DNS queries bypass the VPN and go directly to your ISP’s DNS servers. This can reveal which websites you visit even when your IP address is hidden. To fix a DNS leak, check your VPN settings for DNS configuration options, disable secure DNS in your browser, and verify that your operating system uses the VPN’s DNS servers. Run a DNS leak test after each change to confirm the fix.

Can a VPN hide my activity from websites I sign into?

No. When you sign into an account, the service knows who you are regardless of your IP address. A VPN changes the network path, but it does not hide account-based identity. If you log into the same email, social media, or payment account before and after connecting to a VPN, the service can still link those sessions. For account-level privacy, use separate accounts and clean browser profiles.

How often should I run a VPN privacy test?

Run a test whenever you change VPN settings, update your software, or switch to a new network. A configuration that worked yesterday may break after an update, and a clean result on one network may not hold on another. Regular testing catches problems before they expose sensitive activity. At a minimum, test after initial setup and after any major configuration change.

What should I do if my VPN test shows a leak?

First, identify which signal is leaking—IP address, DNS, or WebRTC. Then make one change at a time: adjust VPN settings, disable browser features, or switch DNS configuration. Repeat the test after each change to see whether the leak is resolved. If the leak persists, contact your VPN provider’s support or consider switching to a provider with better leak protection. Do not assume a single fix solves every leak—test all signals after making changes.