VPN Troubleshooting Guide

01

Before you start: the main troubleshooting path and the tools you need

The quick start page solves the zero-to-connected problem, and its path is linear: sign up, grab the subscription, import it into the client, verify connectivity. Troubleshooting is not linear. The same “pages won't load” symptom could be a DNS failure, a routing rule sending the target back to direct, a system proxy that never actually took effect, or a problem on the route itself. Restarting from the install steps every time mostly wastes effort on parts that already work.

This handbook is organised by symptom. Each chapter maps to something you actually see. Inside a chapter you get a diagnosis flow first, so you can narrow the range to one or two likely causes before touching anything, then the specific self-checks and fixes. The nine chapters have no fixed order — jump straight to the one you need from the list above.

• 02Won't connect at allNo traffic in the client
• 03Connected but pages won't loadTunnel is up, pages spin
• 04Slow speeds and peak-hour lagVideo buffers, downloads crawl
• 05Frequent dropsConnects, then drops shortly after
• 06Subscription update failuresRoute list empty or won't load
• 07Apps not using the proxyBrowser works, app doesn't
• 08Mobile drops in backgroundConnection gone after lock screen
• 09What to include in a ticketSix essentials

How this differs from the quick start page

If you haven't installed a client yet or haven't imported a subscription, start with the quick start path: sign up, get the subscription, import it, verify. Come back here only if problems remain after that. Conversely, if everything works and only the occasional site fails, you don't need to redo the install — go straight to the matching symptom chapter.

The general troubleshooting path: identify the symptom, then the layer

Whatever the symptom, the order is always three steps. First, describe it precisely enough to reproduce. “Sometimes it's slow” is not a symptom; “between 8 and 10 pm one video site buffers while other sites are fine” is. Only a reproducible symptom can be pinned down.

Second, work out which layer the problem sits in. A cross-border path breaks down into roughly five layers: the app itself, the operating system's proxy settings, the client and its routing rules, the local network egress, and the international route. Each layer has its own way of being observed, and chapters three through eight are built around this split.

Third, change one variable at a time. Retest the same thing immediately after each change, and move on only once you've confirmed it worked. Change three settings at once and you won't know which one mattered — and you'll be just as stuck the next time.

Collect these before you start

• Client name and the version string shown in the interface
• The route name and route type currently in use
• The error text verbatim, not your own paraphrase
• OS version and network environment (home broadband, office network, public Wi-Fi, cellular)
• The specific app and the specific URL that fail
• When the problem started, and whether any settings changed beforehand

You'll use this list again in chapter nine. It's exactly what a ticket needs, and having it ready saves a round trip.

Three ground rules

First, don't reinstall the client over and over. Most connection problems have nothing to do with the installer, and a reinstall wipes your subscription and settings — adding a variable rather than removing one.

Second, don't switch protocol or port without writing down what you had. Switching is a legitimate troubleshooting move, but you need to remember the original to get back.

Third, don't experiment on a machine you depend on. Test changes on another device first, and only move them over once you're sure.

A few terms used in this handbook

Route type: IEPL dedicated, relay or direct — the difference is how data travels from the entry point to the exit. Chapter four has the full comparison table. Routing: the rule set the client uses to decide which traffic goes over the route and which goes direct. Exit: the location the destination site sees when you connect. Subscription: the route list and configuration tied to your account, which the client pulls and refreshes periodically — chapter six covers this. Session: the connection the client keeps alive with the route; if it drops, it has to be rebuilt.

Learn the terms once and the diagnosis flows in later chapters will keep referring back to them. If a word doesn't look familiar, come back to this section.

02

Won't connect at all: four layers from client to route

There are two kinds of “won't connect”: the client shows disconnected, or it shows connected but no traffic moves. Treat them separately — the first stalls before the tunnel is built, the second after.

Layer one: is the client actually running?

First confirm the process exists and the interface isn't stuck on a splash screen. On Windows, check whether the tray icon responds to a click; on macOS, the menu bar icon. If clicking it gives you a blank panel or a spinner, quit completely and start it once more rather than reinstalling.

Next, permissions. On macOS the first run asks you to allow a VPN configuration; if you decline, the client looks perfectly normal but the connect button does nothing. Check the Network section of System Settings for the configuration entry. On Windows, make sure you allowed the virtual network adapter driver during install — if security software blocked it, the client opens but can't build a tunnel. Problems at this layer share one trait: every route and every protocol gives the same result.

Layer two: can the local network reach the internet?

Disconnect the client and open a local site the ordinary way. If it won't load, the problem is your local network, not the route, and the later layers don't matter.

Public Wi-Fi has two common traps: a web sign-in page that the client has taken over, or a network that only allows common ports. For the first, turn the client off, complete the sign-in, then connect. For the second, test on a different network.

Office and campus networks may restrict non-standard ports. If the client supports port switching, try 443 — it has the highest success rate.

Layer three: did the subscription and route list load?

Open the client's route list. If it's empty, the problem is the subscription, not the routes. Typical causes: an expired subscription URL, exhausted account data, or a client that has never successfully pulled a configuration.

Subscription troubleshooting is in chapter six. Here you only need to confirm one thing: are there routes in the list? Routes present but none connect — go on to layer four. Empty list — go to chapter six first.

Layer four: routes and protocols

Switch to a route in a different region, switch route type (relay to IEPL dedicated, for example), then switch protocol. If any one of those three attempts works, the problem is a single route or a single protocol rather than your account or network — note which one failed and report it.

If every route and every protocol fails, go back to layer two and re-confirm the local network, and check that the system clock is accurate. A large time offset makes the encrypted handshake fail outright, while the interface usually just says “connection failed” with no real cause.

If all four layers check out and it still won't connect, record the symptoms in the chapter nine format and open a ticket. Write down what you saw at each layer, not just “it won't connect”.

03

Connected but pages won't load: DNS, routing and the system proxy

The client showing connected only means the tunnel was built. Whether data reaches the destination still depends on three things: name resolution, routing decisions, and the system proxy forwarding traffic. Break any one and the symptom is “connected but nothing loads”.

What “connected” actually means

A tunnel means the client and the route can talk. That only covers the segment from you to the route. The segment from the route to the destination, and the way your device hands requests to the client, are separate. So follow the request path segment by segment instead of staring at the status light.

Three faces of a DNS problem

First: no site loads, but the client shows traffic moving. Usually the lookup isn't going over the route and the local network is returning a bad answer.

Second: some sites load and some don't, and the ones that fail are exactly the overseas ones. This is the classic signature of tampered lookup results.

Third: sites load but slowly, with a ten-second-plus wait every time. That's a lookup timing out and falling back to a secondary server.

How to check: query the same domain from the command line against a public resolver and compare the two answers.

nslookup example.com 1.1.1.1
nslookup example.com

If the two commands return completely different addresses, the default resolver isn't giving you the real answer. On macOS and Linux you can use dig for cleaner output:

dig @1.1.1.1 example.com +short
dig example.com +short

The fix is to send lookups over the route in the client, or to specify a trusted resolver manually. After changing it you must fully quit and restart the client — resolution settings don't apply to connections that are already established.

A routing rule sent the target back to direct

Routing rules decide which domains go over the route and which go direct. An outdated rule set, the wrong rule mode, or a hand-added direct rule can all push a site back to direct.

The test is simple: switch the client to global mode and open the same site. If it loads, routing is the problem; if not, it isn't. Once confirmed, update the rule set first, then look through your custom rules for a matching entry. Global mode is a diagnostic tool only — for day-to-day use, stay in rule mode, otherwise local sites take the long way round and you add latency for nothing.

System proxy and browser proxy disagree

Once the client takes over the system proxy, a browser proxy extension will override those settings. The symptom: the client says connected, but the browser still uses the local network.

How to check: open a page in the browser that shows your current exit location and compare it with the route region shown in the client. A mismatch means the proxy isn't really in effect. Another common culprit is an auto-config script whose logic wrongly excludes the target domain. Switch to a global proxy temporarily to confirm.

Diagnosis flow

04

Slow speeds and peak-hour lag: route type, congestion and local bottlenecks

“Slow” is the easiest symptom to misjudge, because it has at least three completely different causes with three completely different fixes.

First, tell the three kinds of “slow” apart

Slow handshake: you click connect and wait a long time before it shows connected. That's tunnel setup being slow, unrelated to bandwidth — usually a response problem at the route entry.

Slow first byte: the connection comes up quickly, but a page spins for ages before content appears, then loads fast. That's latency and resolution, not bandwidth.

Sustained low throughput: pages open, but video buffers constantly and downloads crawl. This is the real bandwidth problem.

The three have completely different causes. Identify which one you have before touching anything and you'll skip a lot of wasted effort.

Route types and where they fit

IEPL dedicated: the entry-to-exit path runs on a private channel with no contention from other users and stable latency — suited to real-time meetings, remote desktop and API calls, where jitter matters.

Relay: traffic enters a relay node before heading overseas, so the path is shorter than direct and usually holds up better at peak times — good for video and everyday browsing.

Direct: a straight connection from your location to an overseas node, the longest path and the most exposed to international egress congestion — fine for large downloads where latency doesn't matter.

Why peak hours stutter

Between 8 and 11 pm international egress is at its most congested. Direct routes get noticeably jittery in that window, while relay and dedicated routes hold steadier. If it's only slow in that window and fine the rest of the time, it's egress congestion, not your network or your device.

Three ways to respond: move to a relay or dedicated route, push heavy transfers outside the peak window, or try a different protocol in the client. None of them require changing account settings, and none affect the data allowance on the plan you bought. With 120+ countries and 180+ routes, the same region usually has several routes to choose from — switching is often faster than fighting one route.

Checking for local bottlenecks

Start with Wi-Fi. Test the same device over an Ethernet cable to the router; a clear gap means Wi-Fi is the problem. The 2.4 GHz band gets crowded by neighbours' routers in the evening, and 5 GHz has short reach — one wall can cost you speed.

Then the router. Older routers have limited forwarding capacity; with a dozen devices attached, forwarding becomes the bottleneck before bandwidth does.

Finally, background traffic. System updates, cloud drive sync and backups can saturate your uplink without you noticing. When the uplink is full, downloads look slower too, because the acknowledgement packets for every request can't get out.

When you can rule out the route

Three signals: speed is unchanged on another device, unchanged on another network, and unchanged outside peak hours. If all three hold, the problem is more likely the destination site or your own device than the route.

Conversely, if only one device is slow, only one network is slow, or only peak hours are slow, work through the sections above before changing routes. Get the direction right and the fix usually takes minutes.

05

Frequent drops: session keepalive, network switching and power saving

Drops are more annoying than a flat failure because they come and go and are hard to reproduce. But the shape of the drop carries information — classify it first and you've halved the search space.

Three drop patterns

Instant drop: it disconnects within seconds of connecting. Usually the protocol or port is being identified and reset by an intermediary device.

Periodic drop: it disconnects every few minutes at a fairly fixed interval. Usually a heartbeat timeout, or the session between client and route failing to stay alive.

Late drop: it survives tens of minutes to hours before dropping. Usually network switching, system sleep, or session reclamation on the route side.

Session keepalive and heartbeats

The client has to send heartbeat packets to the route periodically to keep the session alive. Set the interval too long and intermediary devices reclaim the session first; set it too short and it gets flagged as anomalous traffic. Most clients ship with a sensible default — don't change it casually.

If the client exposes heartbeat settings, restore the defaults first and watch whether drops continue. Restoring defaults is itself a valid variable control: put back what you changed, and whatever remains is the real problem.

Reconnects caused by network switching

Walk a laptop from the living room to the bedroom, the Wi-Fi hands off from one access point to another, and the tunnel is rebuilt. Every connection breaks during the rebuild, which looks like “it dropped for a second and came back”.

On a network with a single SSID for both bands, devices bounce between 2.4 GHz and 5 GHz, and frequent handoffs mean frequent drops. Split the bands into separate network names and pin the device to one — the improvement is usually obvious.

A phone moving from indoors to outdoors, or from Wi-Fi to cellular, hits the same class of problem. That isn't a fault: the network environment changed, and the client reconnecting is normal behaviour.

Power saving and background restrictions

This is most common on mobile and chapter eight covers it in detail. Desktops have a similar mechanism: the network adapter loses power when the system sleeps, and the tunnel has to be rebuilt on wake. If the client doesn't handle the wake event properly, it shows connected while nothing actually works. Disconnect and reconnect once to recover.

Telling a deliberate disconnect from a forced one

Client logs usually record the reason. A deliberate disconnect leaves a clear action in the log; a forced one shows up as a timeout, a reset, or nothing at all. If the same timeout keeps appearing, you can be fairly sure it's session keepalive rather than local network jitter. This step turns a vague “the network is bad” into a concrete direction.

Log the times of each drop

Keep a piece of paper or a notes file and record the time of each drop, what you were doing, and which route you were on. Three days of that and the pattern shows itself: fixed intervals point to heartbeats, changes that follow your location point to network switching, changes that follow the clock point to route congestion.

That record is extremely useful in a ticket — far more useful than the words “it keeps dropping”. It's also the best evidence you have that a problem has actually been fixed.

06

Subscription updates failing: links, time and client cache

A failed subscription update shows up two ways: the route list goes empty, or the routes are still there but none of them connect. Both point to the same thing — the list in the client isn't current.

What a subscription update does

A subscription is a route list generated from your account details. The client requests that URL periodically and receives the latest node list, routing rules and configuration parameters. A failed update means the client is still on the old list, and routes on the old list may already have been changed.

Expired links and permissions

The subscription URL contains a credential tied to your account. Reset your password, regenerate the subscription in the panel, or change account status, and the old URL stops working.

How to check: paste the subscription URL into a browser. Content returned means the URL is valid; an error page means the URL itself is the problem. Note that the subscription URL is equivalent to an account credential — don't post it in a group chat, don't put it in a screenshot, don't commit it to a public repository. Every URL in the examples is a dummy value, such as https://example.com/sub?token=YOUR_TOKEN; the real one belongs only on your own devices.

Network conditions during the update

The update itself needs a working network. If the client is in “everything over the route” mode and the route is down, the update fails — a loop: you need to update because you can't connect, and you can't connect because you need to update.

The right move is to switch the client to direct or turn it off entirely, complete one update over the local network, then connect the route.

Client cache and import method

Some clients keep the old configuration when an import fails, with nothing visibly wrong in the interface. In that case, delete the existing configuration and import again rather than hitting update on top of the old one.

The import method matters too: use “import from URL” for a subscription address, not manual copying of node details one by one. Manually added nodes don't follow subscription updates and will all stop working sooner or later.

System clock out of sync

Subscription requests carry a timestamp. If the system clock is off by more than a few minutes, the server rejects the request. A laptop left running for weeks, or a wrong time zone, can both cause this. Set the clock to sync automatically, restart the client and try again.

The security boundary of a subscription link

If the subscription URL leaks, someone else can use your data. When you see unexpected consumption, the first thing to do is regenerate the subscription URL in the panel — the old one stops working immediately.

Also, don't keep the subscription URL in browser bookmarks that sync across devices, and don't send it to yourself over a chat app's file transfer. Those habits feel convenient but copy the credential into more places. Signing up needs only a username and password, no email address, so credential hygiene is entirely in your hands — treat it accordingly.

07

One app won't use the proxy: per-app mode and rule priority

The browser loads pages but one app reports a network error — the most common kind of partial failure. It's almost always a rule or a proxy-capture problem, not a route problem.

Global mode versus rule mode

In global mode all traffic goes over the route; in rule mode the rule set decides. A single app failing to use the proxy mostly happens in rule mode, because the rule set has no entry for that app's domain, or it matches a direct rule.

Two ways per-app proxying is implemented

One is inside the client: it lists installed apps and you tick which go over the route and which go direct. This needs strong client permissions and works best on Windows and Android.

The other is at the system level: a virtual adapter and routing table capture everything by default, and individual apps are excluded by rules. macOS and iOS work this way. The upside of system-level capture is that apps don't need to know about the proxy; the downside is that you can't see which app took which path when troubleshooting.

Rule priority and common misjudgements

Rule sets usually match in order and stop at the first hit. Put a direct rule at the top and every later rule sending the same domain over the route becomes dead weight.

Three common mistakes: a domain suffix so broad it sends an entire TLD back to direct; an IP range rule conflicting with a domain rule; a rule set so old that the destination site changed domains and the rules never caught up.

How to check: find the request that app made in the client's connection log and see which rule it matched. The log usually names the matched rule, so you can trace it back through the rule set.

An app's own network check

Some apps run a connectivity check at startup and refuse to go online if it fails, even when the system proxy is working. Those apps usually need to be allowed explicitly, or set to use the route in the per-app list.

Another case is an app that uses its own resolver or a hard-coded address and bypasses the system proxy. Only the client's global mode or system-level virtual adapter capture will cover it.

Why the browser works and the app doesn't

Browsers use the system proxy; apps may not. Some apps talk to the network stack directly and never read system proxy settings. Those only go over the route when a virtual adapter captures all traffic.

The test is simple: switch the client to global mode. If the app recovers, it doesn't read the system proxy; if it still fails, it isn't even using the virtual adapter, and you need to look at the app's own network settings.

Diagnosis flow

08

Mobile background drops and device limits

Drops on a phone are almost never a route problem — they're the system restricting background processes. The two platforms behave differently and need different fixes.

iOS background restrictions

iOS is strict about background processes. When you switch away, the system takes over the connection, but other apps' background activity is limited. The symptom is a few seconds of no connectivity after unlocking the screen.

In system settings, the VPN configuration needs “Connect On Demand” enabled, otherwise the system drops it when idle. The other common factor is Low Power Mode: it defers background refresh, so reconnection is slower, though it usually doesn't kill the connection outright.

Android battery optimisation and autostart

Android vendors differ widely. Default battery optimisation restricts background networking once the screen is off, and a restricted client service shows up as a drop.

You need to whitelist the client from battery optimisation in system settings and allow autostart and background activity. Some vendors add their own power-saving switches that have to be turned off separately.

Another easily missed switch is “disconnect mobile data when sleeping”. With that on, the network drops entirely after the screen has been off for a while, and the connection goes with it. Check that first.

Reconnects when switching between cellular and Wi-Fi

A phone on the move hands off between cell towers and Wi-Fi networks constantly, and the tunnel is rebuilt each time. Turning off networks you aren't using (cellular data at home, for example) reduces the number of handoffs, and with them the number of drops.

Why “device limit exceeded” doesn't apply here

Users arriving from other services often suspect a device limit when they can't connect. This service places no cap on simultaneous devices per subscription — using one account on several devices at once is allowed, and you won't be kicked off for having too many. Windows / macOS / iOS / Android / Linux can all be online at the same time.

So if connecting one device knocks another offline, the cause isn't a device limit. It's one of the following.

What the real cause usually is

First: the same subscription is connected from two devices with identical identifiers, and the server reclaims the older session. The fix is a separate client instance per device — don't copy the same configuration with a device identifier in it.

Second: the local network only allows one tunnel. Some routers and public networks cap the number of simultaneous tunnels, so the later connection displaces the earlier one.

Third: an account status problem. This is visible directly in the user panel, no guessing required. Exhausted data and expired plans both show a clear message, and neither has anything to do with device count.

09

When to contact support: what to put in a ticket

The previous eight chapters cover the vast majority of problems you can solve yourself. For the small remainder, a ticket is the right move — but the quality of the ticket decides how fast it gets resolved.

What to solve yourself and what to escalate

The six things every ticket needs

How to describe a symptom

Good: “After 8 pm, watching HD video over a relay route in one region buffers every two minutes; a relay route in another region is fine; the same route on my phone at the same time is also fine.”

Bad: “It's laggy, fix it.”

The first pins down the route and the time window. The second only makes support ask everything from the start, and each round trip costs a day or two.

Three things to do before opening a ticket

First, restart the client and the device to rule out a transient state. Second, retest on another route to see whether it's one route or all of them. Third, confirm the account is in good standing — data not exhausted, plan not expired.

Those three take under five minutes and filter out a fair share of tickets.

Three things not to do when opening a ticket

Don't paste the subscription URL into the ticket — support needs symptoms and results, not credentials. Don't cram three unrelated problems into one ticket; separate tickets get handled faster. Don't keep changing settings while you wait for a reply: the symptoms change and everything you collected becomes useless.

After you submit

The ticket form is inside the user panel; sign in and submit. Don't submit the same issue twice — duplicate tickets scramble the queue.

If you need a refund, this service offers a 7-day no-questions-asked refund; the terms page has the details. Prices and plans are listed in full on the plans page, and route coverage is on the network page — the numbers there match the ones here.