Connection Troubleshooting Guide

1. Preparation and diagnostic order before you start

Most "won't connect" cases are not a broken route at all — something local is blocking the traffic. To avoid wasted effort, split the whole chain into three layers: device and local network (your computer, router, broadband line, the Wi-Fi you are on), client and configuration (whether the client is signed in, whether the subscription is imported, proxy mode and protocol settings), and route and service (whether the outbound route itself is reachable). Only the third layer is on the service side; the first two are in your hands, and they are also where problems cluster.

The recommended order is bottom-up: first confirm the local network itself works, then look at the client's state and configuration, and only then suspect the route. Doing it the other way round — switching routes over and over the moment a page fails to load — usually just bounces you between outbound routes that are all fine, wasting time and often overwriting the real clue.

Have three pieces of information ready first

Before you start, note down three things: the exact error message (screenshot it or copy it word for word — don't just write "it errored"), the exact time the problem happened (to the minute, plus your time zone), and the platform and network type you are on (which of Windows / macOS / iOS / Android / Linux, and whether you are on home broadband, a corporate network, public Wi-Fi or mobile data). These three decide whether the issue can be pinned down in one pass, and they are required fields when you open a ticket.

Sort by symptom first

The same phrase "it won't connect" can come from completely different layers. The table below maps the most common symptoms straight to the chapter that covers them — classify first, then act, and you skip most of the trial and error.

There is one more prerequisite that gets overlooked: the client must be signed in. Signing up here only needs a username and password — no email address — and the credentials are stored locally. If the client says you are signed out or the credentials have expired, the subscription will not refresh properly, and the symptom looks almost identical to a broken route. Whenever anything is off, glance at the account status in the top-right corner of the client; it takes two seconds.

2. Won't connect at all: five checks from your device to the outbound route

"Won't connect at all" means that after you click Connect the client neither establishes a tunnel nor sends any traffic out. These cases have a clear order to work through, and following it usually narrows things down within five steps.

Step 1: Confirm the local network itself works

First disconnect the accelerator and open a local website that does not need it. If it loads normally, broadband, Wi-Fi, router and DNS are fine, and you can move to step 2. If even local sites won't load, the problem is your local network and has nothing to do with the acceleration service — restart the router, reconnect to Wi-Fi, or switch to a different network (from a corporate network to a mobile hotspot, for example) and try again. Plenty of "won't connect" tickets end up tracing back to a corporate intranet or campus network egress policy.

Step 2: See which state the client is stuck in

Distinguish three behaviours carefully: clicking Connect does nothing at all (the button never enters the connecting state) — usually a client process problem or you are not signed in; quit and reopen the client and check the account status. It spins and then times out — the client is already trying to handshake but the outbound route is unreachable, which is a route problem, so go to step 3. An error pops up immediately — write down the exact message; these usually name the cause directly, such as an incorrect system time, a configuration parse failure, or being unable to create the virtual network adapter.

Step 3: Switch to a route in a different region

Don't keep clicking the same route in the same region. Switch to an outbound route that is different in both location and route type — from Japan to Singapore, for example, or from a relay route to a direct route. If three or more routes in different regions all fail completely, the problem is almost certainly not a single route; go back to steps 2 and 4 and check your own device.

Step 4: Check the system time and security software

Encrypted handshakes depend on an accurate system time; a large clock offset will get the connection rejected outright. Set the system time to sync automatically, then restart the client. Also check whether local security software, a firewall or a corporate management tool is blocking the virtual network adapter — these tools often reset their rules after a system update. Turn network protection off temporarily and connect again; if it works, it was being blocked, so add the client to the allowlist. You don't need to leave protection off long term.

Step 5: Clear the old configuration and import again

If everything above checks out, stale configuration from an older version may be left on your device. Delete the current subscription in the client, quit the app, sign in again and re-import the subscription. Typical signs of leftover configuration: region names that are no longer offered show up in the route list, or connecting reports that a configuration item cannot be found.

One common misunderstanding worth clearing up: a failed connection does not mean your account is broken. The client still shows a route list when signed out, because the list comes from the last successful sync cache. To judge whether the account is valid, look at the subscription status in the dashboard, not at whether the client can display route names. If the dashboard shows the subscription is active and the data allowance is not used up, the problem is definitely in the local environment or route reachability.

3. Connected but pages won't load: DNS and routing rules

This category looks like this: the client shows connected, but the browser spins forever, or only some sites fail to load. It is a different problem from the "won't connect at all" cases in chapter 2 — the tunnel is up, and traffic is getting stuck on name resolution or on how traffic is routed.

First tell three patterns apart

No site loads at all: the tunnel is up but traffic is not actually going out, usually because routing rules or the virtual network adapter are not in effect. Only some sites fail: a classic name resolution problem, where the domain resolves to an unreachable address. The browser fails but chat apps work: the browser's own encrypted DNS setting or an extension is hijacking resolution, and the tunnel is not involved.

Check whether the outbound address changed

The most direct test is to look up your current outbound address once before connecting and once after. If both results are identical, traffic is not going through the route at all, and the problem is in the client's proxy mode or at the system level, not DNS. This immediately separates "a resolution problem" from "traffic never went through the route" and saves you from wasting time on DNS. For the full method, see how to confirm your acceleration service is really working.

Clear the local resolution cache

Old resolution results stay cached in the system for a while, so after switching routes you can still hit the old record — one of the most common causes of "connected but pages won't load". Clear the cache once and try again:

# Windows (Command Prompt)
ipconfig /flushdns

# macOS (Terminal)
sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder

# Linux（systemd-resolved）
sudo resolvectl flush-caches

Check the browser's built-in encrypted DNS

Some browsers enable "secure DNS / DNS over HTTPS" by default, which resolves domains on its own and bypasses system settings. When the resolver it picks is unreachable on your current network, you get the classic "chat apps work, the browser doesn't" pattern. Turning the browser's secure DNS off, or setting it to follow the system, usually fixes it immediately. In the same way, ad-blocking or proxy extensions installed in the browser can take over requests — test with a clean browser profile first.

If you have cleared the cache, turned off the browser's encrypted DNS and tried global mode, and only some domains still fail to resolve, note down the exact domains that fail and the error message at the time, and open a ticket. Domain-level resolution failures need to be checked on the service side; continuing to experiment on your own usually produces nothing new.

4. Slow speeds and peak-hour lag: is it always slow, or only at certain hours?

With speed problems, the worst thing you can do is say vaguely that it is "slow". Answer one question first: is it slow all day, or only during a certain evening window? The two have completely different causes and need different fixes.

Always slow: the bottleneck is usually local

If it is slow at any time on any route, suspect your local segment first. Check in order: the actual downstream capacity of your broadband plan; whether you are on the 2.4GHz band (2.4GHz suffers badly from interference in dense residential areas, and moving to 5GHz is usually an instant improvement); whether the router has gone a long time without a restart; and whether other devices on the same network are downloading or streaming HD video. Test again with an Ethernet cable straight into the router — if speeds clearly recover, the problem is in the wireless link, not the outbound route.

Slow at peak hours: congestion on international routes

Cross-border traffic concentrates in the evening, and congestion on shared outbound routes is a fact of life. There are two ways to ease it: change the route type, moving from a standard direct route to a dedicated line or relay route, where bandwidth is reserved relatively independently; and change the region, avoiding the most popular outbound regions at that hour and picking a less crowded node that is still physically close. Doing both together usually works far better than reconnecting to the same route over and over.

How the protocol and transport affect speed

On the same device and the same route, different transport protocols perform differently. UDP-based transports recover faster on lossy links and suit latency-sensitive work; TCP-based transports establish connections more easily on restricted networks but lose speed more sharply when packets are dropped. Most clients let you switch, so test each one in the same time window and keep whichever performs better.

Background traffic getting in the way

System updates, cloud drive sync, file-hosting clients and game launcher downloads all consume bandwidth continuously, and they usually don't tell you. Before testing, open the system's network usage panel, pause the unnecessary high-traffic processes, and measure again. This step often explains seemingly random problems like "it got slow last night and was fine today".

If you have changed route types, changed regions and confirmed nothing local is using much bandwidth, and speeds are still consistently below what you expect, include in your ticket: your region, the hours you usually use, the route type you are on, and screenshots of three speed tests. That is enough to tell whether it is a route capacity issue or a local link issue. For more on choosing route types, the route list page goes into more detail.

5. Frequent disconnects: work backwards from the timing pattern

The disconnect itself is not the clue — the timing pattern is. Watch for twenty minutes and note whether it is "drops at a fixed interval", "drops randomly" or "drops when switching networks", then follow the matching branch below.

Drops at a fixed interval

If it disconnects at roughly the same time every time (every five minutes, say, or every thirty minutes), that points to a timer: the system's power-saving policy freezing the client in the background, the router's address lease expiring, or a scheduled task resetting the network interface. The fix is to lift background restrictions on the client — add it to the unrestricted list in the system's battery or power-saving settings and turn off any "smart power saving" options that target it. The router-side lease issue can be verified by restarting the router; if the interval changes noticeably after a restart, lengthen the lease in the router settings.

Random drops

Irregular disconnects are usually about the wireless signal: the device roaming between access points, signal strength flapping around a threshold, or the 2.4GHz band being crowded by neighbours' routers. Pin the device to the 5GHz band, move closer to the router, or switch to an Ethernet cable — if the drops stop, the wireless link was the cause. In offices and public places, switching between access points is normal; in that case, compare against a mobile data connection.

Drops when switching networks

A phone walking out of Wi-Fi range onto mobile data, or a laptop moving from wired to wireless, changes the network interface and invalidates the established tunnel. Most clients reconnect automatically after an interface change; if yours does not, check whether auto-reconnect is enabled in the client. If it still does not recover, disconnect and connect again manually. This is not a fault — it is normal behaviour when the network environment changes.

How to read the client log

Most clients provide a log viewer. You don't need to read every line — look for two kinds: timestamps (to confirm the exact moment a drop happened and whether it matches what you saw) and lines containing words like disconnect, timeout or reset (these usually state the cause directly). Screenshot both kinds together with their timestamps; that is the most valuable information you can put in a ticket, far more useful than saying "it keeps dropping".

One more note on long-lived connections: instant messaging, remote desktop and online games are extremely sensitive to drops — even a two-second break can show up as "messages arrive very late" or "the game kicked me out". If those are your main use cases, prefer an IEPL dedicated line and stay on the same route as much as possible, to cut the reconnect overhead that switching brings.

6. Subscription update failures: check the link, the account state and resolution

The subscription is the channel that syncs your account entitlements to the client. When it fails to update, the route list in the client stays on the old state, which shows up as "new routes exist but I can't see them" or "it connects but says the configuration is invalid".

Check three things first

More than half of update failures are account-state issues rather than technical ones: whether you are signed in (an expired session cannot pull the subscription), whether the plan is still within its term (a monthly subscription stops updating once it expires), and whether the data allowance is used up (the allowance resets monthly on your activation date; once it is used up you either wait for the reset or upgrade). All three are visible at a glance in the dashboard, so confirm them before troubleshooting. If you upgrade mid-term, the price difference is converted into remaining days, and the subscription contents change with the new plan.

Then check the link and resolution

Once the account state is fine, check whether the subscription link was copied in full — these links are long, and copying from a chat window or a screenshot easily drops trailing characters. Update manually once: choose update in the client's subscription management and read the message. If it reports a network error, the client cannot establish a connection while pulling; first check whether you are already connected to a route, or turn the proxy off temporarily and update again.

# The subscription URL looks like this (the example is a placeholder — use the address actually generated in your dashboard)
https://example.com/sub?token=YOUR_TOKEN

# When an update fails, run a connectivity check first (replace the address with the real one from your dashboard)
curl -I "https://example.com/sub?token=YOUR_TOKEN"

A system clock offset can also cause update failures: pulling a subscription requires validation, and a wrong time gets rejected. Set the system time to sync automatically, restart the client and update again.

If it still fails

Delete the old subscription in the client, quit the app, sign in again and re-import. Deleting the old subscription matters — keeping several subscriptions pointing at the same account in one client leads to them overwriting each other and duplicated route lists. If the route list comes back and connections work after re-importing, you are done.

If re-importing still fails, include in your ticket: the exact error message, when it happened, the platform you are on, and the plan status shown in the dashboard. Do not paste the full subscription link into the ticket — just say the subscription update is failing, and support can look up the status from your account.

7. One app won't go through the proxy: mode, protocol and permissions

"Everything else works, only this one doesn't" is the classic per-app proxy problem. The cause is usually not the route but how traffic is being captured.

First confirm the client's proxy mode

Clients generally offer three modes: global (all traffic goes through the route), rule (a rule set decides), and direct (nothing goes through). If one app is not working, switch to global mode and try once: if it works in global but not in rule mode, the rule set does not cover that app, which is a configuration issue; if it still fails in global mode, the app's traffic is not being captured by the client at all.

Virtual adapter capture vs. system proxy

Virtual-adapter capture works at the network layer and covers the vast majority of apps, including programs that never read system proxy settings. The system proxy approach only affects apps that actively read proxy settings — browsers are usually fine, but some desktop clients, games and command-line tools ignore it entirely. If your target app is one of those, enable virtual adapter capture in the client.

Limitations in the app itself

A few apps pin down their own network behaviour: some have a separate built-in proxy setting (which you must fill in or turn off), some validate certificates and refuse to be intercepted in the middle, and some use UDP transport while your current route or mode only handles TCP. These usually show up as "I can sign in but nothing loads" or "the connection stays in connecting". Try switching the transport protocol in the client, or use global mode temporarily to see whether routing rules are involved. For latency and packet loss in games, the game accelerator picks article goes into more detail.

If the client is definitely in virtual adapter mode and the app still doesn't work in global mode, write in your ticket: the app name, the platform, and whether it only fails during a specific action (a voice call or a file upload, for example). That quickly separates a capture problem from the app's own network policy.

8. Mobile background drops and device-limit messages

Disconnects on phones and tablets are almost never a route problem — the system's background management policy is doing it. To save power, mobile systems restrict an app's network activity once it goes to the background, which shows up as "I switched away for a moment and the connection was already gone".

Mobile background policies

The fix is to release the client from power-saving restrictions: find it in the system's battery settings and set it to unrestricted; turn off "smart power saving" and "background restriction" options that target it; and in the system's connection settings, confirm it is enabled as a network configuration. iOS and Android use different names for these screens, but the direction is the same — let the system know this app needs to keep network activity in the background.

About "device limit reached"

This site does not limit the number of devices — one account can be used on Windows / macOS / iOS / Android / Linux at the same time, and there is no per-device pricing or restriction. So if you see a message like "device limit reached", it is almost never an account-level limit. There are three common sources: leftover configurations on the same device (an old subscription was never deleted and the client treats it as several connection instances); old configuration profiles left in the system's network settings (especially on iOS, where installing a profile several times can leave several copies); and multiple sessions that were never signed out in the dashboard, which some clients merge and display together.

Order of steps

First delete the extra subscriptions in the client and keep only one; then check the system settings for several network configurations with the same name, keep the newest and delete the rest; then restart the device. If the message still appears, sign in to the dashboard, look at the current sessions, sign out the devices you no longer use, and sign in again. After these three steps the message usually stops appearing.

One more thing worth noting: on a weak mobile signal, the device hands off between towers constantly, so the tunnel is rebuilt far more often than on Wi-Fi. If you use it while commuting, an occasional reconnect is normal and you don't need to restart the client over and over. What really deserves attention is a reliably reproducible case — "every time I switch to the background and come back I have to reconnect manually" — because that is the background policy failing to let it through.

9. When to contact support, and what to put in a ticket

The previous eight chapters cover the vast majority of problems you can solve yourself. The rest need to be checked on the service side, and opening a ticket is more efficient than trying again and again. The key is knowing what to report, what not to report, and what to include.

Cases that don't need a ticket

A single route won't connect (switch to another one), one website won't load (clear the cache and turn off the browser's encrypted DNS as in chapter 3), speeds drop at peak hours (change the route type as in chapter 4), the phone drops when it goes to the background (adjust the power-saving settings as in chapter 8). These are all configuration or environment issues, and the answer support gives you will be the same as working through this manual yourself.

Cases that should have a ticket

You have tried three or more outbound routes in different regions and of different route types and still cannot connect at all; the same failure appears on several devices and several networks; subscription updates fail repeatedly while the dashboard shows the account is fine; the log repeatedly shows timeouts pointing at the service side; a device-limit message appears even though you only use one device; and anything involving account security or unfamiliar sign-in records. These need the account state and route reachability checked from the service side — continuing to test on your own won't produce anything new.

Information a ticket must include

Accurate information gets it pinned down in one round; vague information means several rounds just establishing the basics. Fill in the checklist below item by item:

• Your account username (username only, never the password);
• The platform you are on: which of Windows / macOS / iOS / Android / Linux, plus the device model;
• The exact error message: copy it word for word or screenshot it, don't summarise it as "it errored";
• When it happened: to the minute, with your time zone;
• Your network environment: home broadband, corporate network, public Wi-Fi or mobile data;
• Steps you have already tried: which steps from this manual you did and what each one showed;
• Whether the problem reproduces reliably: every time, or only occasionally.

Three other routes besides a ticket

First, the Guides section covers the main flow from signing up to verifying connectivity — if you hit a problem during your first install, start there. Second, the Help Center organises common questions into four groups: account and subscription, connection and troubleshooting, speed and routes, and billing and refunds — many detailed questions are answered there directly. Third, for refund and billing questions, the pricing page and the refund policy spell out the rules — a full, no-questions-asked refund can be requested within 30 days of your first payment. Refund requests also go through the ticket form; just include the order time.

Finally, a note on how the service side handles tickets: they are processed in the order received, and a ticket with complete information usually gets a conclusion in one pass, while incomplete ones are sent back for details first. So rather than rushing to submit "it won't connect, what do I do", spend two minutes filling in all seven items above. That is the one idea this whole manual is trying to get across — describe the symptom clearly, and the problem is already half solved.