Direct answer: what usually goes wrong on public Wi‑Fi, and what to verify

When you use a VPN on public Wi‑Fi, the most common problems are connection drops, inability to reach certain sites, slow or unstable speeds, and confusion about whether traffic is actually going through the VPN. The key verification goal is simple: confirm that the VPN client is connected and that your browsing traffic is routed as expected (including DNS-related behavior). At the same time, remember an important limitation: a VPN does not guarantee anonymity, safety, or guaranteed access on any network.

How VPNs work on public networks (and where expectations break)

A VPN typically creates an encrypted tunnel between your device and a VPN server. After that, your device sends traffic to the tunnel rather than directly over the public network. This can reduce the visibility of your traffic to anyone watching the local network, but it does not automatically solve every issue related to public Wi‑Fi.

Public Wi‑Fi environments often have extra constraints that a VPN cannot override reliably:

  • Captive portals may redirect browser traffic to a login page. Even if the VPN is “connected,” your browser may still be sent elsewhere until the portal is cleared.
  • Some networks restrict certain traffic types or apply firewall rules that interfere with VPN protocols.
  • DNS resolution may behave differently when systems use their own DNS settings versus those provided through the tunnel.
  • Performance varies because the public Wi‑Fi itself may be congested, the wireless signal may be weak, and the VPN path adds latency.

Because of these variables, two people on the same Wi‑Fi can have different outcomes depending on device, OS networking settings, VPN client settings, and timing.

Practical context: which problems are distinct, and what they mean

Treat “VPN not working” as several separate issues. Organising them helps you verify the right thing instead of repeatedly toggling random settings.

  1. VPN won’t connect This can indicate that the public Wi‑Fi blocks the VPN protocol, the device cannot establish the required network route, or the VPN client needs additional permission (for example, changes to networking permissions). Verification here focuses on connection state and error messages.

  2. VPN connects, but websites don’t open This often points to captive portal behavior, DNS problems, or network blocks that prevent reaching certain destinations. Verification here focuses on browsing behavior, DNS resolution, and whether traffic is actually routed through the tunnel.

  3. VPN connects, but speed drops or is unstable Public Wi‑Fi congestion and weak signal are major contributors. VPNs also add overhead and reroute traffic, so performance may change in both directions. Verification should include timing-based tests (e.g., a quick short check of loading and responsiveness) rather than assuming a single measurement is representative.

  4. You’re unsure whether traffic is leaving through the VPN This is the verification need that most directly maps to user trust. Even with a connected VPN client, incorrect routing or DNS configuration can lead to a mixture of tunnelled and non-tunnelled traffic. Verification should focus on routing and DNS behavior.

Limitations and uncertainties to keep in mind

A VPN is not the same as a guarantee. Even when it is configured correctly, it cannot promise complete anonymity, universal safety, or guaranteed access. Some issues are also inherently situational: results depend on the public network’s rules, your device’s OS behavior, and the VPN service’s current availability and routing.

Additionally, claims about specific technical behaviors (such as whether DNS leaks occur, or which protocol modes are currently supported) require up-to-date information from authoritative documentation. Since no product-specific documentation is provided here, this article limits itself to general verification concepts and highlights uncertainty where appropriate.

Verification steps: check connection state, traffic routing, and DNS behavior

Use a short sequence of checks so you can identify what’s failing.

  1. Confirm the VPN client is truly connected Start with the VPN app/client status indicator. If it shows a connected state, then verify that it remains connected while you test.

  2. Clear the captive portal and re-test If you see redirect behavior in the browser (login/terms pages) or repeated “waiting room” style pages, handle the captive portal first. After you complete it, test again with VPN enabled. If sites begin working only after portal acceptance, the “problem” was network access rather than VPN encryption.

  3. Verify that DNS resolution matches your expectation If websites fail to load while other apps or basic connectivity works, focus on DNS. A common pattern is: the tunnel is connected, but DNS queries are not using the expected path. Look for settings that control DNS behavior (for example, “use VPN DNS,” “block DNS outside tunnel,” or similar options) and ensure they are enabled when your goal is to route name resolution through the VPN.

  4. Check for obvious routing mismatches If your browser indicates traffic is not behaving consistently (for instance, unusual geolocation-related redirects, mixed content availability, or repeated failures to reach otherwise reachable sites), it may be a sign that traffic is not consistently routed through the VPN tunnel.

  5. Test with controlled comparisons To reduce uncertainty, do two quick checks:

  • Test with VPN on, then off (or with a different network) and compare whether the issue changes.
  • If you can, test on another public Wi‑Fi to see whether the failure tracks the network or your device setup.
  1. Record the failure type, not just the outcome Note whether the problem is “can’t connect,” “connect but no websites,” “slow performance,” or “not sure about routing.” This helps you choose the next verification step rather than restarting everything.

Which mistakes to avoid while diagnosing and verifying

  1. Assuming “connected” means “everything is protected and routed correctly.” A connected VPN app is necessary, but verification is still about routing and DNS behavior.
  2. Ignoring captive portals. Portal redirects can look like VPN failures.
  3. Running only one performance test. Public Wi‑Fi variability makes single measurements unreliable.
  4. Changing multiple settings at once. That makes it difficult to determine which change actually helped.
  5. Treating uncertain claims as facts. If you do not have current, authoritative documentation for a specific technical capability, focus on observable behavior and general verification principles.