Public Wi-Fi is useful when you are working in a café, waiting at an airport, or checking in at a hotel, but the network is shared with people and devices you do not control. A VPN can protect traffic between your device and the VPN server, reducing what the local hotspot can read or alter in transit. It does not make every website trustworthy, remove malware, prevent account phishing, or guarantee that an app sends all of its traffic through the encrypted tunnel.

The safest approach is to treat a VPN as one layer in a broader routine. Confirm that the connection is active, understand what the Kill Switch does on your particular client, use HTTPS, keep your device updated, and avoid entering sensitive information when something about the network or login page seems wrong. The checks below apply to café, airport, hotel, and other shared Wi-Fi networks, although the exact settings differ among Windows, macOS, iOS, Android, and Linux.

What public Wi-Fi can expose

Connecting to a public hotspot places your device on a network shared with other users. Depending on the network design and the services you use, the hotspot operator may be able to observe connection details such as the domains or IP addresses your device contacts, connection times, and the amount of data exchanged. Other users on the same network may also try to discover exposed devices or exploit weak local-network settings. Modern HTTPS limits what a network observer can read from a properly secured website, but it does not hide every connection detail or protect you from a fraudulent site.

Some risks are not caused by the Wi-Fi encryption method at all. A fake hotspot can imitate the name of a legitimate café or airport network. A captive portal may ask you to sign in before granting access, and a malicious page may imitate that portal to collect credentials. A lookalike login page, unexpected certificate warning, or message asking you to install a configuration profile can create a risk even if your VPN is connected.

It helps to distinguish the layers involved. Wi-Fi security protects the radio connection between your device and the access point. A VPN creates an encrypted tunnel from your device to a VPN server. HTTPS protects a web session between your browser and a particular website. These protections address different parts of the route; one does not replace the others.

Layer or threat What it can affect Practical response
Shared local network Discovery of exposed devices or local services Disable unnecessary sharing and keep the firewall enabled
Untrusted hotspot Connection metadata, redirection attempts, or captive-portal deception Verify the network name with staff and inspect login requests carefully
Unencrypted application traffic Information sent without suitable end-to-end protection Prefer HTTPS websites and updated apps; do not ignore security warnings
Phishing or account takeover Passwords, payment details, and account access Use a password manager and multifactor authentication where available
Compromised device Files, keystrokes, sessions, or app activity Keep software updated and install apps only from trusted sources
Bottom line: Public Wi-Fi creates a shared-network risk, but many serious incidents begin with a fake login, unsafe device setting, or compromised account—not with someone simply reading an encrypted VPN tunnel.

What a VPN encrypts—and what it does not

When a VPN is connected and routing traffic as intended, data travels through an encrypted tunnel from your device to the VPN server. This helps prevent the local Wi-Fi operator and other users on the hotspot from casually inspecting the contents of that traffic. It can also make it harder for the local network to modify or redirect traffic inside the tunnel. The protection depends on the client being connected, the device routing the relevant traffic through it, and the VPN implementation working correctly.

The tunnel normally ends at the VPN server, not at the final website or service. From there, HTTPS provides the separate encrypted connection between your browser or app and the destination. If a service uses plain-text communication, a VPN does not automatically turn that service into an end-to-end encrypted one. If you enter a password into a convincing but fraudulent website, the tunnel can carry that password securely to the wrong destination. A VPN also cannot tell whether a message, file, or payment request is legitimate.

Other limits matter in everyday use. Split tunneling may deliberately send selected apps or destinations outside the VPN. Some system services can use separate network paths, and behavior varies by operating system and client. DNS settings, IPv6 handling, app permissions, and reconnection behavior can also affect what uses the tunnel. These are not reasons to avoid a VPN; they are reasons to check the client’s routing options instead of assuming that one “connected” indicator covers every possible network request.

  • Usually protected by the tunnel: traffic that the client actually routes through the VPN, while the tunnel is established.
  • Still dependent on HTTPS or app security: protection between the VPN server and the service you are accessing.
  • Not solved by a VPN: phishing, weak or reused passwords, malicious downloads, unsafe browser extensions, and vulnerabilities in an outdated device.
  • May need a separate check: split-tunneled apps, DNS behavior, local-network access, and traffic during a disconnect or reconnect.

A VPN also changes which network intermediary handles some of your traffic. The hotspot sees less of the traffic carried inside the tunnel, while the VPN provider becomes the network endpoint for that tunnel. Choose a service whose policies and operating practices you understand, protect your account credentials, and avoid treating a provider’s privacy claims as a substitute for reviewing its terms and technical details.

Connect and verify before signing in

Before using a public hotspot for anything important, establish the network connection deliberately. Ask the venue for the correct Wi-Fi name instead of choosing the first familiar-looking entry in the network list. Watch for names with extra characters or small spelling changes. If the venue uses a captive portal, confirm that the page appears as part of the expected access process. Do not install a certificate, app, or device profile merely because a pop-up says it is required for free Wi-Fi.

Once the device is online, connect the VPN using the official client or a compatible client configured with a trusted subscription. Wait until the client reports an active connection, then check that it has selected the expected mode and that no pause, bypass, or split-tunnel setting is excluding the app you plan to use. A client showing an error, an endless reconnect, or a disconnected state should be treated as an unprotected connection until the problem is resolved.

Use the client’s own diagnostics where available. Some clients report connection state, the selected route, and DNS or leak-test results. A browser-based IP or DNS test can provide an additional check, but results should be interpreted carefully: a test page can show the public address or resolver visible to that page, not prove that every app on the device follows the same route. If you need to verify a specific app, check its routing rules and repeat the test while the app is active.

  • ✅ Confirm the hotspot name with the venue before connecting.
  • ✅ Connect the VPN and wait for a clear, active status before opening sensitive apps.
  • ✅ Check split tunneling, app bypass, and routing mode if a particular app matters.
  • ✅ Keep HTTPS certificate warnings visible; do not click through a warning just to load a page.
  • ❌ Do not treat a VPN icon or a successful Wi-Fi connection alone as proof that all traffic is protected.
  • ❌ Do not enter VPN credentials into an unfamiliar portal or a page reached through an unexpected redirect.

If the VPN will not connect, avoid entering passwords or payment details while troubleshooting. Try disconnecting and reconnecting through the official client, check whether the captive portal must be completed first, and confirm that the device’s date and network settings are reasonable. If the problem persists, switch to a trusted mobile connection or wait until you can use a network you control. Do not disable security features or install unknown software just to force a connection.

Use the Kill Switch and handle disconnections

A Kill Switch is intended to block some or all network traffic if the VPN tunnel drops, helping prevent the device from silently continuing over the ordinary hotspot connection. Its exact behavior is client- and platform-dependent. Some implementations block internet access until the tunnel returns; others apply only while the app is running, only to selected traffic, or only under particular settings. Read the client’s description and test the behavior with non-sensitive browsing before relying on it.

Look for related controls as well as the Kill Switch label. A client may offer always-on VPN, block connections without VPN, auto-reconnect, or startup connection options. Operating systems may provide their own VPN controls, but names and capabilities differ. Enabling an option in one place does not necessarily mean another app’s excluded traffic is covered. If you use split tunneling, confirm whether the Kill Switch also blocks the apps excluded from the tunnel.

You can perform a cautious check without exposing account data. Connect to the VPN, open an ordinary non-sensitive page, then briefly interrupt the tunnel using the client’s normal disconnect control. Observe whether traffic is blocked, the page reloads over the regular connection, or the client reconnects. Restore the connection and verify its active state before using the device normally. Avoid testing by joining unknown networks or by changing low-level system settings you do not understand.

A Kill Switch is a fail-closed aid, not a complete security system. It cannot prevent a user from approving a phishing prompt, protect an app that intentionally uses another route, or repair a compromised device. It can also interrupt connectivity when the VPN server or local network changes. If a work application, local printer, or captive portal stops working, understand which traffic is being blocked before adding exceptions; broad bypass rules can weaken the protection you intended to use.

Protect accounts, payments, and private sessions

For email, banking, shopping, and work accounts, use the official app or enter the service address yourself rather than following a link from a public sign-in page, unsolicited message, or Wi-Fi portal. Check the domain before submitting credentials. A padlock or HTTPS indicator means the browser has an encrypted connection to the displayed site; it does not prove that the site is the organization you intended to visit.

Use unique passwords and a password manager that can identify the correct site before filling in credentials. Enable multifactor authentication where the service supports it. These measures help limit damage if a password is exposed elsewhere, but they do not make it safe to approve an unexpected login request. Review prompts carefully and deny requests you did not initiate. Never share a one-time code with someone who contacts you claiming to be technical support.

Payment activity should follow the same checks. Confirm that the checkout belongs to the expected merchant, avoid saving payment information on a shared or unfamiliar device, and do not continue if a page unexpectedly requests your full account credentials or asks you to install software. A VPN can protect the local portion of a connection, but it cannot validate the merchant, reverse a fraudulent payment, or guarantee that a compromised browser is safe.

When using a work account, follow your organization’s device and network policies. Some workplaces require a specific VPN, endpoint protection, or managed device configuration. A personal VPN may conflict with those controls or route traffic in a way the organization does not permit. For confidential work, ask the organization which connection method to use rather than assuming a consumer VPN is an approved substitute.

Device settings and a practical routine

Before travelling, update the operating system, browser, and VPN client through their normal trusted update channels. Keep the device firewall enabled and turn off file, printer, or media sharing when you do not need it. Set the public-network profile to a more restrictive mode where the operating system offers that choice. Disable automatic joining of open networks, and remove saved hotspots you no longer trust so the device does not reconnect unexpectedly.

Use a screen lock and avoid leaving a device unattended. Locking the screen does not protect traffic by itself, but it reduces the chance that someone nearby can use an already unlocked session. Close accounts on shared computers rather than assuming the browser will erase the session automatically. Avoid saving passwords or payment details on public devices, and do not connect personal storage devices to machines you do not control.

For phones and tablets, check whether the VPN app is allowed to reconnect after a network change and whether battery-saving settings might pause it. The setting names differ across platforms and manufacturers. If you move from Wi-Fi to mobile data, wait for the VPN to re-establish before resuming a sensitive task. If a captive portal requires temporary access before the VPN can connect, complete only the expected portal step, then start the VPN and verify the tunnel before opening other services.

  • ✅ Forget untrusted networks after use and disable automatic connection to open hotspots.
  • ✅ Keep the firewall, operating-system updates, and browser protections enabled.
  • ✅ Turn off file and printer sharing when using networks you do not control.
  • ✅ Recheck VPN status after moving between Wi-Fi and mobile data or waking the device.
  • ❌ Do not install unknown certificates, profiles, browser extensions, or “security” apps offered by a hotspot.
  • ❌ Do not assume private browsing mode hides traffic from the network or encrypts a connection.

If the network behaves strangely—unexpected redirects, repeated login prompts, certificate warnings, or unexplained VPN failures—stop using it for sensitive tasks. Forget the network, turn off Wi-Fi, and use mobile data or another trusted connection. If you already entered a password on a suspicious page, change it through the official service on a trusted connection, revoke unfamiliar sessions if the service allows it, and review recent account activity.

Practical conclusion: Use public Wi-Fi only with a deliberate connection routine: verify the hotspot, connect and check the VPN, keep HTTPS and device protections in place, and pause sensitive activity whenever the tunnel or destination cannot be trusted.