Direct answer

If your VPN “doesn’t work” while travelling, treat it as a verification problem: first confirm the VPN client is actually connected and applied to your traffic, then test whether the expected network behavior changes (for example, IP/location and DNS handling), and finally isolate what changed—network type, device settings, captive portals, firewalls, or app configuration. Avoid assuming anonymity, safety, or guaranteed access; instead, verify step by step with repeatable checks.

How it works (what should be true)

A VPN creates an encrypted tunnel between your device and the VPN service. For it to help while travelling, three things generally need to line up:

  • The VPN client establishes a connection successfully (no error state, no “disconnected” background mode).
  • The client routes your traffic through the VPN (not only the app you’re using, unless you intentionally configured split tunnelling).
  • Name resolution and connectivity behave consistently (DNS queries should go through the VPN if your client is configured that way).

When you travel, operating conditions shift. The network might be cellular data, airport Wi‑Fi, hotel Wi‑Fi, or a corporate network with additional restrictions. Some networks block or rate-limit VPN protocols; some require captive-portal logins that can interfere with connectivity until completed.

Practical context and what to check first

Use this checklist in order. Stop when the issue is resolved; don’t change everything at once.

1) Confirm connection state and scope

  • In the VPN app, verify the status says “connected” and note the connected protocol/endpoint if it’s shown.
  • Check whether you are using split tunnelling. If split tunnelling is enabled, only selected apps or destinations may use the VPN.
  • Ensure “VPN always-on” or “auto-connect” settings match what you’re trying to achieve, especially after roaming between networks.

2) Complete captive portals before judging VPN behavior

If you’re on public Wi‑Fi, open a browser and finish any login page or terms acceptance. Then re-test VPN connectivity. Many “VPN issues” on travel networks are actually not fully connected internet access.

3) Reboot the minimum necessary

  • Toggle the VPN off, wait briefly, then toggle on.
  • If it still fails, restart the device’s network connection (Wi‑Fi off/on, or switch between Wi‑Fi and cellular to compare).
  • As a last step, restart the device, then reconnect the VPN.

4) Test with consistent targets

Use the same set of checks each time:

  • One or two websites/services you know should load through the VPN.
  • One check for your perceived IP address/location (any public “what is my IP” style check).
  • Optionally, a DNS check if your client provides logs or diagnostics.

If only some services fail, the issue is likely service-specific (for example, the service blocks the VPN’s exit IP range), rather than a total VPN connection failure.

Limitations to keep in mind

  • A VPN does not guarantee anonymity, safety, or access. Outcomes depend on how the service and websites handle traffic and identifiers.
  • Performance and availability vary by network, device, location, provider and time.
  • Some VPN protocols may be restricted on certain travel networks. If one protocol fails, switching can help, but you should do so cautiously and only based on what the client supports.

Verification steps (a repeatable way to be sure)

After each change, verify using observable signals. Here’s a practical “prove it” flow:

Step A: Verify the VPN is actually routing traffic

  • With the VPN connected, run your IP/location check and record what it shows.
  • Disconnect the VPN and re-run the same check.
  • A successful outcome often involves a change while connected and a revert after disconnecting. If nothing changes, your traffic may not be routed as expected (for example, split tunnelling, DNS leaks, or a misapplied profile).

Step B: Verify DNS and connectivity patterns

  • If websites load inconsistently, suspect DNS handling.
  • In the VPN client, look for any DNS options (for example, “use VPN for DNS”). Then repeat the same website tests.
  • If your VPN client provides diagnostics/logs, note errors and timestamps.

Step C: Compare network environments

To isolate where the problem comes from:

  • Try the same VPN setup on cellular data versus the current Wi‑Fi.
  • If it works on cellular but not on a particular Wi‑Fi network, the Wi‑Fi network is likely restricting VPN traffic or blocking protocol/ports.

Step D: Confirm the travel-time variable

Repeat your checks later or after a short time if the issue appears intermittent. Some networks and middleboxes behave differently after roaming, after idle periods, or after reconnecting to Wi‑Fi.

When is the verification complete?

Your verification is “complete enough” when you can answer these three questions:

  1. Is the VPN app consistently connected without errors?
  2. Do your observable checks (IP/location, website access) behave differently in a way that matches your expectations when you toggle the VPN?
  3. Have you ruled out the most common external causes (captive portal not completed, network restrictions, split tunnelling scope)?

If the answer is no to any of these, keep narrowing scope rather than making broad changes.

When to stop troubleshooting (red flags)

Stop and reassess if:

  • The VPN cannot maintain a connection on any network type (suggests an account/app/profile or broader device issue).
  • The VPN connects but no services work reliably across multiple networks (suggests service-specific blocks or persistent routing problems).
  • You repeatedly see the same errors immediately after connecting (suggests a protocol or configuration incompatibility with that network).

Optional: useful internal notes to speed up later

Keep a simple log for each test:

  • Date/time
  • Network type (hotel Wi‑Fi, airport Wi‑Fi, cellular)
  • VPN connected/disconnected outcome
  • Any error messages
  • What changed (protocol, endpoint, DNS option, split tunnelling on/off)

These notes make it easier to identify patterns, and they prevent “random” retry loops.

If you want, tell me your device type (Android/iOS/Windows/macOS), the VPN app behavior you see (connected/disconnected/errors), and what exactly fails (IP check, one website, or all traffic).