What to check first on public Wi‑Fi

Before you rely on a VPN on public Wi‑Fi, treat it like a network-dependent setup you must confirm. A VPN can change how your device routes traffic, but it does not guarantee anonymity, safety, or uninterrupted access. Performance and availability can vary by the Wi‑Fi network, device, location, provider, and time.

Use the checklist below as a “problem + verification” routine: you validate that (1) the VPN is actually connected, (2) traffic appears to go through the expected tunnel, and (3) common failure modes (captive portals, DNS issues, and routing leaks) are not breaking your plan.

How a VPN behaves on public Wi‑Fi (and why problems happen)

A VPN creates an encrypted tunnel between your device and a VPN endpoint. On public Wi‑Fi, failures usually come from one of these practical areas:

  • Wi‑Fi access problems: the network may use a captive portal (a login page) that interferes with “always-on” assumptions.
  • Routing and DNS mismatch: even when a VPN app shows “connected,” some traffic may still use the local network settings if DNS or routing is misconfigured.
  • App vs system VPN behavior: some devices route only specific apps through the VPN, while other traffic can still follow the default network path.
  • Blocking and throttling: public networks or hotspots may restrict VPN protocols or throttle encrypted traffic.
  • Address or IP expectations: the “what is my IP” page might not match your expectation due to region changes, caching, or because different services show different identifiers.

Stable knowledge to keep in mind: VPNs generally improve privacy against passive observers on the same Wi‑Fi network by encrypting traffic, but the exact protections and reliability depend on configuration and the services you use.

Practical context: a complete pre-check routine (digital nomad ready)

Run this routine before you do anything sensitive on public Wi‑Fi. Aim for consistency: use the same device, browser, and time window when comparing results.

  1. Confirm you’re on the same Wi‑Fi network

    • If the Wi‑Fi reconnects or changes bands (or you roam between access points), you can accidentally compare different network states.

  2. Check the VPN connection state in the VPN app

    • Verify it says it is connected, and note whether it is “full device” or “select apps.”

  3. Set your expectations for what should change

    • Your visible IP/address on web services should typically change after VPN connection.
    • DNS behavior should align with the VPN’s intended routing (though the precise mechanism varies by device).

  4. Avoid captive portal confusion

    • If you see a captive portal prompt, complete it first. Then reconnect the VPN (or restart your VPN session) so you can verify the final routing.

  5. Do a quick before–after test

    • Before connecting the VPN, open a non-sensitive “what is my IP” style page and note what it reports.
    • After connecting the VPN, reload and compare. If nothing changes at all, treat it as a sign to investigate.

  6. Verify at least two different indicators

    • Don’t rely on only one page or one identifier. Use two indicators such as IP/address visibility and DNS/traffic consistency.

  7. Check for browser-level and OS-level settings

    • Confirm the device isn’t using special “private DNS” settings or browser overrides that might bypass expected behavior.
    • If available, ensure “VPN kill switch” or “network lockdown” features are enabled—because they help you avoid accidental fallback when the tunnel drops. (Exact availability and behavior vary by OS and VPN app.)

Limitations and red flags (what this checklist can’t fully prevent)

Use these as “don’t be fooled” signals:

  • No guaranteed anonymity or safety: public networks can still expose you through device fingerprinting, logins, cookies, and account-linked activity.
  • Performance changes are normal: latency and speed can drop due to encryption overhead, distance to the VPN endpoint, or limited network capacity.
  • Service availability can change: some websites and streaming services may block or challenge traffic that looks like it comes from VPN endpoints.
  • False reassurance: a VPN “connected” indicator does not automatically prove there are no routing or DNS issues.
  • Inconsistent results across time: network-side filtering can vary during the day, and mobile roaming behavior can affect what you observe.

If you repeatedly see the same problem (for example, the VPN appears connected but your IP/address stays the same after reconnection), pause and troubleshoot rather than continuing with sensitive tasks.

Verification steps: a reliable “proof” workflow

This section is meant to help you verify claims and catch problems without assuming perfection.

  1. Confirm device-to-VPN connectivity

    • Look for the VPN’s connected status and any “tunnel established” indicator.
    • If the VPN app provides logs, skim for errors around connection start, DNS, or route changes.

  2. Compare before/after indicators on the same device

    • Repeat the same test page after connecting.
    • If your visible IP/address changes, that’s an encouraging sign—but still not full proof.

  3. Validate DNS consistency

    • Confirm your DNS behavior matches what you expect while the VPN is on.
    • If your device uses local DNS when you expected VPN-routed DNS, that mismatch can undermine the practical privacy goal.

  4. Check for app-scoped VPN limitations

    • If the VPN is configured for selected apps, test traffic from the exact app you care about (browser, email client, cloud apps).
    • If only some apps show the expected changes, you may need to expand “all traffic” scope or adjust configuration.

  5. Test reconnection and tunnel drops

    • Temporarily disable and re-enable the VPN and watch what happens.
    • If traffic briefly leaks or resumes without encryption, treat it as a risk and adjust protective settings (where your OS/VPN supports them).

  6. Validate access resilience

    • If a site fails only on VPN, try a different VPN server/region setting within your app (if available).
    • If access breaks on only certain networks, note the pattern. This helps you decide when to switch networks rather than assume the VPN is broken.