How a VPN works (and what “works” really means)

A VPN (Virtual Private Network) typically creates an encrypted tunnel between your device and a VPN server. Your internet traffic is then routed through that tunnel, so websites see the VPN server’s public IP address rather than your home or mobile network’s public IP.

When people say “my VPN works,” they usually mean several things at once:

  • Connectivity: the VPN client shows you are connected.
  • Routing: internet traffic is actually going through the VPN tunnel.
  • Identity signals: your public IP appears consistent with the VPN server.
  • Name resolution: DNS lookups are not exposing your original network identity.

Because the exact implementation differs by provider and device, no single test can prove every aspect with absolute certainty. The goal is to reduce uncertainty with practical checks.

Core checks to confirm VPN routing and identity

Start with checks that are meaningful regardless of brand, operating system, or VPN protocol.

1) Verify you are connected (not just “enabled”)

After turning on your VPN, confirm the client shows an active connection to a server. Then open a website or use a network tool that reflects your current network identity.

What you’re looking for: the VPN status should be “connected,” and your next tests should behave as if the connection is live.

2) Compare your public IP before and after connecting

To test routing, check your public IP address both:

  • without the VPN
  • with the VPN connected

If the VPN is working for routing at a basic level, the public IP you see should change to something associated with the VPN server. If it does not change, traffic may not be routed through the VPN.

3) Check DNS behavior

Many VPN problems are not visible by IP checks alone. DNS can reveal which network is doing name resolution.

Practical approach:

  • Use a DNS test website (or a DNS lookup tool) and observe whether DNS results remain consistent with VPN usage.
  • If your VPN settings are “DNS over VPN” or similar, the expectation is that DNS lookups are handled through the VPN tunnel rather than your local network.

Uncertainty note: the exact DNS path and how much DNS can be observed from the outside varies by platform, browser behavior, and local caching.

4) Confirm in multiple contexts (browser vs. device)

A common failure mode is that only browser traffic is protected (or only some apps go through the tunnel). To reduce false confidence:

  • Test using a browser
  • Then test another app (e.g., a different web-capable app or a system feature that accesses the internet)

If results differ, your VPN may be limited to specific apps or subject to routing rules.

Differences and limitations that can change the outcome

Split tunneling and selective routing

Some configurations use split tunneling, where only certain traffic goes through the VPN while other traffic goes out normally. In that case:

  • Your public IP might change for some sites, but not for others
  • Mobile data or specific app categories may bypass the VPN

If you enable or disable split tunneling, repeat your IP and DNS checks to see what actually changes.

Kill switch behavior

A kill switch is designed to cut internet access if the VPN connection drops. However, implementation details vary, and some devices or apps may still show temporary behavior during reconnects.

What to consider:

  • After intentionally disconnecting (or if it drops), verify whether traffic stops or continues.
  • If traffic continues, the “protection” window may be thinner than you expect.

IPv6 versus IPv4

Some networks and VPN setups handle IPv6 differently than IPv4. If your IP check tool reports only one address family, you might miss exposure in the other.

Practical mitigation:

  • Use tools that display both IPv4 and IPv6 when possible.
  • If IPv6 remains unchanged while IPv4 changes, that may indicate partial routing.

Browser caching and session effects

Your browser may cache DNS responses or remember network state within a session. That can make results look stable even when changes occur.

To improve signal quality:

  • Test in a fresh browser session
  • Clear relevant DNS-related cache only if you know what you’re doing
  • Re-check after reconnects

Practical step-by-step testing workflow

Use this sequence to get reliable, repeatable results.

  1. Record baseline (without VPN): note your public IP (and, if available, DNS-related observations).
  2. Connect the VPN: wait until the client confirms the connection is active.
  3. Re-check your public IP: confirm it changes compared to the baseline.
  4. Run a DNS check: observe whether name resolution behavior looks consistent with VPN usage.
  5. Test another context: try a different browser session or a different app.
  6. Repeat after changes: after switching networks (Wi‑Fi to mobile), after reconnecting, or after changing VPN settings, redo the same checks.

If you see inconsistent outcomes, treat it as an indicator to inspect your VPN routing rules (app selection, split tunneling, DNS options, and IPv6 handling). Because you may not be able to prove everything externally, focus on trends across repeated tests.

Troubleshooting checklist for common problems

If your VPN results look wrong, consider these possibilities:

  • VPN not actually routing: public IP doesn’t change after connecting.
  • Selective routing: only some apps or browsers show VPN behavior.
  • DNS mismatch: IP changes but DNS observations still resemble your local network.
  • IPv6 path differs: IPv4 changes but IPv6 stays the same.
  • Timing during reconnects: behavior differs right after a disconnect/reconnect.

Then narrow down what changed:

  • Did you switch networks?
  • Did you change any VPN settings related to DNS or app routing?
  • Did you restart the browser or device?

Final guidance: what you can conclude from testing

With practical checks (IP change, DNS behavior, and testing across contexts), you can usually determine whether your VPN is doing what you expect at a functional level. But complete certainty is rarely possible from outside observations alone, especially with caching, IPv6 differences, and platform-specific networking.

The most useful mindset is: measure repeatedly, compare before/after, and interpret inconsistencies as clues to your configuration and network path—rather than as proof that the VPN is either fully safe or fully broken.