Connection Troubleshooting Guide

01 · Locate

First work out which layer is failing

Connection failures rarely have a single cause. Splitting the likely culprits into three layers makes troubleshooting much faster: the first is the device itself — client configuration, system time, firewall, power-saving policies; the second is the local network egress — home broadband, office networks and public Wi-Fi restrictions on protocols and ports; the third is the route and the account — congestion, an expired subscription, exhausted data. Each layer needs a completely different fix, so identify the layer before discussing solutions.

Order matters more than effort. Many people reinstall the client the moment a connection fails, and lose the one message on screen that actually explained the problem. Reinstalling only helps when the config file is genuinely corrupted; otherwise it just resets your troubleshooting clock to zero.

One more thing worth saying: the three layers affect each other. An underpowered device makes a route look slow, and a wrong local DNS setting produces “won't connect” and “connected but no pages” at the same time. That is why each chapter ends with “when to go back a layer” — you do not have to fight it out inside one chapter.

Three 30-second checks

No tools needed — three checks narrow the problem down by more than half.

1. Close the client and open an ordinary web page. If it won't load, your local network is already down; fix the network first instead of hunting for a cause inside the client.
2. Keep the same device and network, switch to another route and reconnect. If it connects, that single route is the problem — pick a backup route in the same region with a different type from Nodes & Routes.
3. Try another device, or move the same device to another network. If it connects on another device, the original device's local configuration is at fault; if it connects on another network, the original network's egress policy is at fault.

Write the symptoms down instead of rushing to reinstall

The most valuable information in a ticket is not the words “it won't connect” — it is the items below. Note them down in advance and you save a round of back-and-forth even if you end up asking for help.

• When the problem started, including the time zone, and whether it clusters in a particular window
• Platform and OS version (Windows / macOS / iOS / Android / Linux)
• The exact wording of the client's message — screenshot it or copy it verbatim
• The route name and route type selected at the time
• Whether it runs on a router, and how many devices sit behind that router
• What changed before the problem appeared: a new DNS, security software installed, a different routing mode

When you can jump straight to the last chapter

Two situations don't need chapter-by-chapter checks: first, the panel shows the subscription expired or the data used up — that is an account issue, so go straight to “Account & tickets”; second, the exact same symptom appears on several devices on the same account at once and neither a different network nor a different route helps — that is usually a session state problem on the account side, and a ticket is faster than more testing. For everything else, work through the chapters in order, because many symptoms are different faces of the same cause.

02 · Connection setup

Won't connect at all

The client spins forever after you hit connect, throws an error, or drops seconds after connecting — all of that belongs here. First work out which of the four message types you are seeing; each one takes a completely different path.

Tell the four kinds of “won't connect” apart

Account and data

Log in to the user panel and confirm two things: whether the subscription is still valid, and whether any data remains. Monthly subscription data resets every month on the activation date, not on the calendar month; data packs last until used up and never expire, so the remaining balance does not vanish when the month changes. The panel shows the remaining amount for both kinds of quota — trust what the panel says.

If the panel shows a valid subscription and plenty of data but the client reports authentication failure, log out and log back in so the client pulls the account information again. If it still fails, open a ticket. For how to combine data packs and monthly plans most economically, data packs vs monthly plans works through the estimate by usage.

System time

Encrypted connections rely on certificate validation, and the first gate in that validation is time. If the system clock is more than a few minutes off, the handshake fails, and the message often looks a lot like “no network”, which is easy to misread. Windows, macOS, iOS and Android all offer an automatic time setting — turn it on, then sync once manually.

# Linux: check the time, time zone and sync status
timedatectl status

# Turn on automatic time sync and sync once right away
sudo timedatectl set-ntp true

Local network egress

Office networks, campus networks, some hotels and public Wi-Fi restrict UDP and uncommon ports. The test is simple: move the same device to another network and connect again. If it fails on the original network and works on the other, the original network's egress policy is the problem. In that case try switching the transport in the client from a UDP-based protocol to a TCP-based one, or use a more common port.

Firewall and security software

Desktop security suites, the built-in firewall and some “network optimiser” tools intercept the virtual adapter. The symptom is a client that says connected while no new virtual adapter appears in the system, or a connection that is cut the moment it forms. The fix: whitelist the client so it can create a virtual adapter and change DNS settings; while troubleshooting you can temporarily disable third-party security software for a comparison test, then turn it straight back on.

Routers and multiple devices

When you configure it on a router the client is not involved, so the problem usually lies in the router firmware, time sync, or compatibility of the rule files. Check in order: the router itself has internet access, the router's time is synced, the subscription pulled the rules successfully, and the rule format matches the firmware. If all four pass and it still won't connect, note the router model and firmware type and include them in your ticket.

03 · Resolution and routing

Connected but pages won't load

The client says connected and the egress region has switched, yet the browser spins, or only some sites open. What these cases share: the tunnel is up, and what is stuck is name resolution and routing on top of it.

Tell the three patterns apart

DNS leaks vs DNS failures

A DNS leak means lookups bypass the tunnel and expose your local DNS; a DNS failure means lookups return nothing at all. Both look like “pages won't load”, but the fixes differ: a leak calls for changing the client's DNS capture settings, a failure calls for checking whether the system DNS is reachable at all.

# Windows: check the DNS configuration and flush the cache
ipconfig /all
ipconfig /flushdns

# macOS: flush the DNS cache
sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder

# Linux (systemd-resolved): check status and flush the cache
resolvectl status
sudo resolvectl flush-caches

# Generic: look up which address a domain resolves to
nslookup example.com

If nslookup returns your local ISP's or router's address while the client is set to send DNS through the tunnel, the system is bypassing the lookup. The fix: set DNS in the client so the tunnel handles it, or specify a working public resolver such as 1.1.1.1 or 8.8.8.8, then flush the system cache once.

Routing modes and rules

In rule mode the client decides between proxy and direct connection from a domain list. If the target site is not on the list, or the list is out of date, traffic goes direct. The test: switch temporarily to global mode. If it opens in global but not in rule mode, the rules are the problem. Fix by updating the rules or adding the domain to your custom rules.

There is another easily missed edge in routing rules: the same domain can match both the direct list and the proxy list, and the outcome depends on the client's priority order. More rules does not mean better rules — conflicting entries make troubleshooting much harder. Keep rules lean and add only what you actually need.

MTU and dropped large packets

The tunnel adds another header, so the usable maximum transmission unit is smaller than on the physical link. With the MTU set too high, small requests get through while large responses are dropped: the page skeleton appears but images and styles never load, or login-type actions spin forever. Lowering the MTU by one step is the cheapest way to test this.

04 · Throughput

Slow speeds

Slow is the hardest category to quantify. Establish a baseline first: how fast is the local network without the proxy, and how much does it drop with it on. Without a baseline, “slow” is just a feeling, and switching ten routes may change nothing.

Measure the baseline before optimising

With the client off, measure your local bandwidth once on the same device in the same spot and write it down. Then connect the proxy and measure again the same way. The gap between the two is what the proxy path costs you. If the local connection is already slow, changing routes won't help much — the bottleneck is not the route.

Speed tests themselves need care. The location of the test server skews the result: if the test node is local and the proxy egress is abroad, the number reflects local-to-local, not real cross-border speed. A closer match to everyday experience is to open the sites you actually use and watch three things: time to first screen, image loading, and how quickly video starts.

Single-thread vs multi-thread

A single-threaded download reflects the quality of one connection; a multi-threaded download reflects total bandwidth. Slow single-thread with normal multi-thread means the route throttles individual connections — fine for parallel tasks, poor for large single-threaded downloads. If multi-thread is slow too, the bottleneck is total link bandwidth or the local egress. Use the same file in the same time window for both tests, or the comparison means nothing.

How route type matters

Direct routes take the shortest path but cross many public nodes and are easily hit by international egress congestion at peak times; relay routes add a hop in the middle and are more controllable; IEPL dedicated lines run on a private channel with steadier latency and jitter, at a higher cost. The same region may offer all three types with very different performance, so it is worth trying them one by one. The Nodes & Routes page lists the type of every route by region for comparison.

Devices and Wi-Fi

Encryption and decryption cost CPU. Old devices, laptops in low-power mode and machines with everything running in the background all push real throughput below what the route can deliver. The test: compare the same route on a faster device. On Wi-Fi, the 2.4GHz band delivers far less real throughput than 5GHz and drops further through walls; a wired connection is the most stable reference.

Only certain sites are slow

If one site is slow and everything else is fine, the route is probably not the problem. CDN scheduling assigns nodes based on your egress IP, so a distant egress region gets a distant CDN node. Switching the egress region to one closer to the target service's region is often more effective than changing routes. With 100+ countries and 220+ routes, most target services have a geographically closer egress available.

05 · Timing

Peak-hour lag

If the problem only appears at fixed times — fine by day, laggy at night — it is not a random fault but a regular congestion pattern. Home broadband and international egress carry the most traffic from evening into the night, latency and packet loss rise on cross-border links, and direct routes feel it most.

Why peak hours hit harder

Cross-border links pass through international egress, and egress bandwidth is shared. At peak hours the most home broadband users are online at once, queueing delay at the egress rises and so does packet loss. Loss compounds: one dropped packet triggers a retransmission and shrinks the congestion window, so real throughput falls by far more than the loss percentage suggests. That is why “a little lag” at peak hours feels like “the video spins forever”.

Confirm the time pattern first

Log the same route in the same time window for several days in a row: does it connect, how many seconds to open a page, how often video buffers. Three days is enough to see a pattern. If the lag has nothing to do with time, go back to the “Slow speeds” chapter; if it only happens on one route, the route itself is the problem and switching fixes it.

Choosing a route type

Peak-hour behaviour depends heavily on route type. Direct routes cross the public internet and jitter noticeably under congestion; relay routes converge traffic at an intermediate node and hold up better; IEPL dedicated lines run on a private channel and are least affected by public congestion. If budget allows, switching to a dedicated-line route during peak hours is the most direct improvement.

Choosing an egress region

The same site responds very differently from different egress regions. Asian routes usually have lower latency at peak hours than trans-Pacific ones. If the target service has nodes in several regions, prefer the geographically closer egress; if it only has nodes in one region, you can only pick a route type within that region.

Adjusting your habits

• Schedule large downloads and system updates outside peak hours
• Set video quality to a fixed tier instead of auto, so bitrate switching doesn't cause repeated buffering
• The more devices watching at once, the less bandwidth each gets — unlimited devices doesn't mean unlimited total bandwidth
• For games, watch latency and jitter rather than peak bandwidth

Live streams and match days

Live sports are more sensitive to latency and concurrency. The ten minutes before kick-off are the peak for connection setup, so connect early and open the player early — steadier than switching routes after the match starts. For route selection during events, route comparison for live sports has a more detailed breakdown.

06 · Stability

Frequent drops and mobile background disconnects

Drops come in two kinds: the connection is actively torn down, and the connection stays up but no traffic flows at the application layer. The first shows as a disconnect and reconnect in the client; the second looks connected and passes nothing. The fixes are completely different.

Drops at fixed intervals

A drop every fixed interval usually relates to heartbeat or idle timeouts. Intermediary devices clear session entries that carry no traffic for a while: the client thinks the connection is alive, while the device has already forgotten the session. The fix: enable or shorten the heartbeat interval in the client, or keep a little light background traffic flowing.

Random drops

Irregular disconnects are usually link jitter. The test: check the client state the moment it drops. “Connected but no traffic” points to the link; “disconnected” points to the local network or the virtual adapter. Weak Wi-Fi, a heavily loaded router and ISP line jitter all cause this.

Sleep and wake on desktop

After a laptop wakes from sleep, the virtual adapter may not take over traffic again: the client says connected while nothing passes. Disconnecting and reconnecting once restores it. If you have to reconnect manually after every wake, check the client's launch-at-startup and reconnect-on-network-change options.

Session tables behind a router

A router maintains a NAT session table; when it fills up, new connections cannot be created, which shows as “the network is up but new pages won't open”. Low-end routers have small tables, and with many devices and high concurrency they hit the ceiling easily. A reboot relieves it temporarily; the long-term fix is fewer simultaneous devices, or a router with more memory.

Mobile background disconnects

iOS and Android both limit background network activity. After a while in the background the system may reclaim the VPN configuration or suspend the client process, and returning to the foreground shows it reconnecting. That is system policy, not a route fault.

• iOS: make sure On Demand is enabled in the VPN configuration; remove the client from Low Power Mode restrictions; allow Background App Refresh.
• Android: set the client to unrestricted under battery optimisation; stop the vendor's power-saving policy from cleaning it up; allow background activity.
• General: don't close the client by “clearing background apps” — many systems stop the VPN configuration along with it.

07 · Config retrieval

Subscription update fails

A subscription update is the client pulling a configuration file from the server. Failures cluster around three points: the fetch did not go through the proxy, the subscription URL is no longer valid, or the client cached an old configuration. Check in that order and most cases are located in one pass.

Confirm the fetch path first

Many clients don't use the proxy when updating a subscription and fetch directly. If the subscription URL is not reachable on the current network, the update fails. The fix: switch the client to global mode first, or route the update request through the established tunnel, then hit update. Switch back to rule mode once it succeeds.

Subscription URL and credentials

The subscription URL carries identity information and is equivalent to a password. Once the URL is reset or expires, updates return an error. Get a fresh subscription URL from the user panel and replace the old one in the client.

# Example: the shape of a subscription URL (sample value, not a real address)
https://example.com/sub?token=YOUR_TOKEN

The address above only illustrates the format. Get your real subscription URL from the user panel — don't copy examples circulating online, and don't post your own URL in public.

Client cache

If the update succeeds but the route list doesn't change, the client is usually serving a cache. Clearing the cache or deleting the subscription and importing it again forces a refresh. Some clients only re-pull rules when you hit “Update all”; updating nodes alone doesn't update routing rules.

Updating on a router

On a router, update failures usually come from three causes: unsynced router time breaking certificate validation, DNS failing to resolve the subscription domain, and insufficient storage causing the write to fail. Rule them out one by one: sync the time, then change DNS, then check storage.

Subscription format and client compatibility

The same subscription URL may need different formats in different clients. When the format doesn't match, the client either reports a parse failure or imports successfully with an empty route list. In that case check the format options in the panel first, then pick the matching import method in the client. If you can't tell the formats apart, use the one the client recommends by default.

08 · Traffic capture

One app won't use the proxy

If the browser works and one app doesn't, the tunnel itself is fine: that app's traffic is not being captured, or it is captured and resolution fails.

Run the global-mode comparison first

Switch the client to global mode and open the same app. If it works in global mode, the rules don't cover that app's domains; if it fails in global mode too, the app is not using the virtual adapter, or it has its own network stack.

System proxy vs virtual adapter

A system proxy only affects apps that read the system proxy settings. Many apps — games, some desktop clients, command-line tools — ignore it and only use the virtual adapter. The client needs TUN mode or virtual adapter mode enabled to capture that traffic.

Apps with their own network stack

• Apps with built-in DNS: they bypass system DNS and query a fixed address, so routing rules may judge them wrongly.
• Apps with hard-coded IPs: no domain lookup happens, so domain-based rules never match.
• Apps using QUIC: it runs over UDP, some networks restrict it, and the result is a connection that forms but never loads.
• Clients with their own protocol: they need a proxy configured separately, or must be forced through the virtual adapter.

Per-app proxying

Some clients support per-app routing: you specify which apps use the proxy and which go direct. Get the rules backwards and you get “the ones that should proxy don't, the ones that should go direct don't”. Check whether the target app is on the proxy side, then restart the app and test again.

Command-line tools and environment variables

Command-line tools usually only honour environment variables and ignore the system proxy. Set them once in the terminal, then run the command that needs the network.

# Use the port the client is actually listening on
export https_proxy=http://127.0.0.1:7890
export http_proxy=http://127.0.0.1:7890

# Verify the egress: the result should match the current route's egress region
curl -s https://example.com/ip

Verify traffic really goes through the proxy

Open a page in the app that reports your egress address and see whether the returned address matches the route's egress. That confirms whether the traffic is captured at all. A fuller self-check is in how to verify the connection works.

09 · Account and support

Account, devices and tickets

The previous eight chapters cover technical faults. This one covers account-level issues, and what to do when human help is genuinely needed.

What “unlimited devices” means

Plans on this site don't limit the number of devices and aren't billed per device. One account can be installed on Windows, macOS, iOS, Android and Linux at the same time — no second purchase for a second device. Unlimited refers to device count, not total bandwidth: the more devices online at once, the less bandwidth each one gets.

Routers and sharing

When configured on a router, the router counts as one device and everything behind it shares that connection. At home this is the least fuss, but watch the router's performance: low-end routers have limited encrypted throughput and become the bottleneck as devices multiply. The test is simple: install the client directly on a computer and compare — if the direct install is clearly faster, the router is the bottleneck.

How to read device-limit messages

This service doesn't limit device count, so under normal circumstances you won't be refused because of it. If a client pops up a message about device count, log out and log back in so it pulls the account information again; if the message persists, screenshot it and open a ticket, noting which client showed it and when.

Data and expiry

Monthly subscription data resets every month on the activation date, not on the calendar month; if you upgrade mid-cycle, the price difference is converted into the remaining days. Data packs last until used up and never expire, unaffected by month changes. The panel shows both quotas separately — before renewing, check which one runs out first.

Keeping account credentials safe

An account only needs a username and password, with no email address, so those two items are your credentials. That also means there is no email for a recovery flow — keep the password safe yourself and don't leave it in a public place alongside your subscription URL. For how plan tiers map to data packs, see Pricing; payment supports Alipay / WeChat / USDT.

Refunds

30-day no-questions-asked refund. The request form and required details are on the Refund Policy page; include the order time and plan name to speed up the check.

When to contact support

• You have tried at least three routes in different regions, changed networks and switched protocols, and still cannot connect at all
• The panel shows a valid subscription with plenty of data, but the client keeps reporting authentication failure
• Subscription updates fail on several different networks
• A route has been unusable at fixed times for several days running
• Account-related billing, refund or plan-change questions

What to include in a ticket

A ticket with complete information usually gets the problem located in one round. Include:

• When the problem occurred, with time zone
• Platform and OS version
• The exact client message, as a screenshot or text
• The route name and route type selected at the time
• The checks you have already run and their results
• Whether it runs on a router, and how many devices are behind it

Symptom: after connecting, the browser won't load pages while the client shows connected
Time: 2026-10-20 21:30 (UTC+8)
Platform: Windows / current client version
Current route: Japan · Tokyo (relay)
Checked: global mode made no difference; changing DNS still failed;
        the Singapore route loads pages normally
Note: three devices behind the router

Don't attach your full subscription URL, password or other credentials. To identify the account, the username is enough.

Search once before you submit

Many questions already have answers in the Help Center, especially billing and plan questions. Checking first makes your ticket more precise and keeps the same question from queueing twice.