TroubleshootingGuide

Baseline before you troubleshoot: record first, then change things

Cross-border route problems rarely have a single cause. The same can't-connect symptom can come from the client losing its system permission, a local DNS failure, or the route you picked being adjusted. If you change routes, switch clients and reinstall the system all at once, you won't know which step actually fixed it, and next time you'll be back at square one.

First, a note on how this page and the tutorial page (tutorial.html) divide the work: the tutorial covers the main path from zero to working, from signing up and choosing a plan to getting your subscription, importing it into a client and verifying the connection. This page is a reference manual organised by symptom, for when you hit a specific error. If you haven't finished your first setup, start with the tutorial; if things already work but break in one scenario, jump straight to the matching chapter.

Record four baseline facts first

Before you start troubleshooting, write these four down. They are both the basis for your own checks and the information support needs most if you open a ticket:

1. Platform and client name. The steps differ a lot across Windows, macOS, iOS, Android and Linux, and the same error often has different causes on each. Say exactly which platform and which client you are on.
2. When the subscription last updated successfully. Your client shows the subscription update time. If it was a week ago, update it before troubleshooting, because many cases of missing routes are just a stale subscription rather than a route failure.
3. The name and type of your current route. For example Hong Kong · IEPL dedicated or Tokyo · Relay. Note down which one you switch to, otherwise you can't compare the two.
4. The exact error text and the app where it happens. Is it a pop-up in the client, a page that won't load in the browser, or a network error inside one app? Copy the wording exactly instead of summarising it as just can't connect.

Three general checks: change one variable at a time

Whatever the symptom, run these three steps first, in this order:

1. Switch routes. In the same client, move to another region, preferably a different route type (Direct to Relay, Relay to IEPL dedicated). If that fixes it, the problem was that one route: note its name and keep using another.
2. Switch networks. Move the device from Wi-Fi to mobile data, or try a different Wi-Fi. If that fixes it, the problem is in the original local network: the router, your ISP's uplink or DNS.
3. Switch devices. Import the subscription on another device with the same account and try again. If that fixes it, the problem is in the original device's client or system settings.

After these three steps the problem usually lands on one of three things: a specific route, a specific network or a specific device. If it doesn't, move on to the chapter for your symptom and dig deeper.

Troubleshooting order: near to far, one layer at a time

Break the chain into four layers and rule them out in order, without skipping a layer:

• Client layer: permissions, subscription status, routing rules, the client itself.
• Local network layer: router, ISP uplink, DNS, public networks that require sign-in.
• Route layer: whether the region and route type you picked are available, and whether they are congested at peak times.
• Destination layer: whether the target service itself is reachable and whether it has extra requirements for the exit region.

Working near to far means every layer gives you a definite answer; once you've been through all four, the problem is sitting in one of them instead of turning into a random try-everything session. The classic waste of time is the other way round: blaming the route first and only later finding that a browser extension was blocking the request.

Have two verification tools ready

Two questions need answering during any troubleshooting session: is traffic actually going through the route, and is DNS resolution actually working? For the first, use the site's My IP page (myip.html) to see your current exit IP and its location, and check it before and after connecting; if the IP and region change, traffic is going through the route. For the second, query DNS with the command-line tools built into your system: nslookup on Windows, dig or nslookup on macOS and Linux. The details are in the pages won't load chapter.

Won't connect: work from the client to the route, layer by layer

Total connection failure means the client can't establish a connection, or it shows connected but no traffic gets through. This chapter moves through the client layer, the local network layer and the route layer, and each step lists what you can actually observe, so you know which layer you have reached.

Four checks at the client layer

1. Is the permission still there? On iOS and Android, the VPN permission can be revoked after a system update, a client reinstall or a manual cleanup. The symptom is a toggle that won't turn on, or one that switches itself off straight away. Fix it by allowing the client to establish a VPN connection again in system settings, then reconnect from the client.
2. Is the subscription valid? An empty route list, or one with only a default entry left, usually means the subscription never imported. Update it once; if the update fails, follow the subscription update fails chapter on this page.
3. Is the system clock accurate? Connection setup is time-sensitive, and a large clock offset makes the handshake fail outright. Set the clock to sync automatically and try again.
4. Is security software blocking it? Some security suites take over the system's network layer and block the client's connection requests. Quit the security software temporarily and try again; if that fixes it, add the client to its allow list.

Checks at the local network layer

First confirm the device can get online without the route: open a well-known website, and if it loads, the local network is fine. Then check in order:

• Try another network. Switch from Wi-Fi to mobile data. If it connects on mobile data, the problem is in the original Wi-Fi or router, not the route.
• Does the network need sign-in? Hotel, airport and corporate networks often require you to complete a captive portal in the browser first; until you do, the gateway simply drops other kinds of traffic.
• Is internet protection enabled on the router? Some routers' parental controls or internet protection block connections by app type, so turn it off temporarily and try again.
• Restart the router. When a long-running router's connection table fills up, new connections fail; a restart is the quickest way to confirm it.

Checks at the route layer

Once the client layer and the local network layer are ruled out, verify by switching routes:

1. Change region. Pick one you haven't tried from Hong Kong, Singapore, Tokyo, Los Angeles, Paris or Milan, and stop reconnecting to the same route over and over.
2. Change type. Try all three: Direct, Relay and IEPL dedicated. If all three fail, the problem is more likely on the client or account side; if only one type fails, that route type is the issue.
3. Change protocol. If your client offers several protocol options, try another one to rule out a compatibility problem with a single protocol.

Connected but no traffic

One case is easy to misread: the client says connected, but every page times out. Check your exit IP on the My IP page first. If neither the IP nor the region has changed, traffic isn't going through the route and the connection only exists locally, which is a client-layer problem. If the exit IP has changed to the route's region but pages still won't load, that belongs to the next chapter, connected but pages won't load, and the fix is completely different.

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

The client says connected and the exit IP has changed, but pages won't load, or only some of them won't. Problems like this almost always come from one of three places: the proxy mode and routing rules, DNS resolution, or the destination site itself. Work through them in the order below instead of changing all three at once.

Three typical symptoms, three directions to check

• No site loads, not even a search engine. Check DNS and the proxy mode first.
• Common sites load, but some won't open or spin forever. Check the routing rules and the destination site first.
• The browser works but one app doesn't. That's the one app won't use the proxy chapter, so jump straight to it.

How to tell if DNS is the problem

DNS turns domain names into IP addresses. When resolution breaks, the classic symptom is a browser that spins and finally times out, while connecting by IP may still work. To check, run a lookup with the tools built into your system:

# Windows
nslookup example.com

# macOS / Linux
dig example.com +short

Read the answer: normally you get a set of IP addresses; if you get NXDOMAIN, a timeout, or an address that clearly doesn't belong to that domain, resolution is broken. The three common cases and what to do about them:

• Lookup times out. The local DNS server is unreachable. Switch to a public DNS and try again.
• Wrong answer. The returned address doesn't match expectations, usually because something on the path rewrote the DNS request. Let the route side handle resolution.
• Some domains fail to resolve. The routing rules sent those domains down the wrong resolution path, so only that subset is affected.

Order of fixes: first turn on the remote DNS or resolve via route option in your client (the name varies between clients) so domain resolution happens on the route side. If your client doesn't have that option, change the system DNS to a public resolver and reconnect. Then re-run the lookup above to confirm the answers are normal.

Routing rules and rule sets

In rule mode the client uses its rule set to decide which traffic goes through the route and which goes direct. A stale rule set causes two opposite problems: domains that should use the route are treated as direct and won't load, while traffic that should go direct is pushed through the route and slows down. The fix is simple: update the rule set in your client (usually the same place you update the subscription), then fully restart the client rather than just backgrounding it.

Fix order

1. Check the exit IP first to confirm traffic really uses the route. If it doesn't, fix the connection problem first and skip the rest.
2. Run a DNS lookup to rule out resolution problems. The commands and how to read them are in the previous section.
3. Update the rule set and restart the client. This fixes most cases of some sites not loading.
4. Switch the proxy mode to global temporarily and test the same site. If it loads in global mode but not in rule mode, the rule set is the problem.
5. If all of the above is fine, suspect the destination site. Visit the same site from a different network; if it still won't load, the problem is on the site's side, not the route.

Slow speeds and peak-hour lag

Slow is a vague description. Before troubleshooting, split it into three observable symptoms: not enough bandwidth, high latency and packet loss. They look different, have different causes and need different fixes; treating them as one problem just means switching routes back and forth.

Tell the three kinds of slow apart first

• Not enough bandwidth: large downloads crawl, but pages open and video starts normally, showing up as a steady low speed.
• High latency: every click takes a second or two to respond, while download speed may be fine, showing up as laggy rather than slow.
• Packet loss: choppy audio in video calls, pages that stall halfway and need refreshing, showing up as instability rather than slowness.

Telling them apart is straightforward: open a page and watch how long the first byte takes (latency), download a large file and see whether the speed holds steady (bandwidth), join a call or watch a live stream and see whether it stutters (packet loss). Only bandwidth is roughly captured by a speed test number; the other two show up in real use.

Route types and peak hours

Peak hours usually means 20:00 to 24:00, when international uplinks are most congested. That's when the three route types differ most:

This isn't an absolute rule, because actual performance depends on your city, your ISP and how the uplinks are doing that day. But the logic for picking a route holds: for stability-sensitive work (calls, remote desktop) prefer IEPL dedicated; for bandwidth-hungry work (4K video, large files) go by the actual speed of the route you're on rather than the region name alone. The full route list with type labels is on the routes page.

Self-check steps

1. Test each route type. Within the same time window, test Direct, Relay and IEPL once each and record the results. Comparing across different times of day tells you nothing.
2. Check local bandwidth use. See whether other devices on the same network are downloading, backing up or streaming. A single large file sync that saturates the uplink can slow the whole network down.
3. Check the Wi-Fi. Move closer to the router, prefer the 5GHz band and test again. Wi-Fi jitter is often mistaken for a route problem.
4. Confirm traffic takes the route you chose. Use the My IP page to check that the exit region matches the route you selected. If you picked Hong Kong but exit somewhere else, the routing rules are at fault, so handle that with the previous chapter first.
5. Compare on another device. Run a speed test on the same route from a second device to rule out a bottleneck on one machine.

Bandwidth reference by use case

The numbers in this table are general reference values, not speeds this service guarantees. Actual speed depends on your location, your local ISP, the route's load at the time and how responsive the destination site is.

How AI tools and streaming behave differently

Chat-style AI tools care more about latency than bandwidth: a slow first token is usually a latency problem, and switching to a lower-latency route helps more than switching to a bigger one. Streaming cares about bandwidth: 4K that won't start or keeps dropping resolution is usually a bandwidth problem. In both cases, don't go by speed test numbers alone, because watching how it actually behaves is more accurate.

Frequent dropouts and mobile background disconnects

Dropouts come in two kinds: one where the connection cuts out and you have to reconnect manually, and one where the connection still shows as up but stops passing data once the device goes to the background or the screen locks. The first usually comes from the network or the route; the second is almost always the system's battery and background policy. Work out which one you have first, because the fixes are completely different.

Desktop: look at the pattern of dropouts

• Drops at a fixed interval. Usually the client's keep-alive setting or a system power option. Check whether the client has an auto-reconnect toggle, and whether the system has a power-saving option that puts the network adapter to sleep.
• Drops when the network changes. Dropping when you move from Wi-Fi to Ethernet, or between Wi-Fi networks, is normal, and the client usually reconnects within seconds.
• Random drops. Usually route instability or local network quality. Note the times they happen and compare with peak hours, which quickly separates route congestion from a local problem.

Mobile: settings that stop background disconnects

Both iOS and Android restrict background apps, and a VPN client that gets suspended in the background loses its connection. Check these settings on your platform:

The exact path varies between OS versions, but the keywords are always the same: battery optimisation, background activity, autostart, Background App Refresh. If you can't find them, search those terms in your system settings search box.

Dropouts caused by network switching

When a mobile device moves between Wi-Fi and cellular, its IP address changes and the existing connection has to break. Most clients reconnect within seconds; if it doesn't, toggle the connection off and on once. Frequent switching on the subway, in lifts or when moving between buildings is normal, not a fault.

Checklist

1. Note when the dropouts happen and see whether they cluster at peak hours.
2. Check that auto-reconnect is enabled in your client.
3. Apply the background and battery allow-list settings for your platform, then restart the client once.
4. Switch to a different route type and see whether it still drops.
5. If it still drops often, open a ticket as described in the last chapter and include the dropout times and the route name at the time.

Failed subscription updates: six causes and fixes

The subscription is the only way your client gets its route list. A failed update shows up in three ways: the route list goes empty, the list stays on an old version, or the client reports an update timeout. The causes overlap, so check them in this order.

What a subscription link contains

A subscription link is an address with parameters, in this format:

https://example.com/sub?token=YOUR_TOKEN

That's a format example, not a real address. Your real link is generated in the user panel; copy it and paste it straight into your client. The token part is tied to your account and works like a credential: anyone who gets the link can fetch your route list and use it within your data allowance. Don't post the link in public channels and don't leave it in screenshots.

Six common causes

1. No network access. The device can't reach the server hosting the subscription address. Paste the link into your browser's address bar once; if it returns content, the network is fine.
2. The link was altered. Extra characters got added when you copied it, or security software's link scanning intercepted it. Copy it again from the panel instead of fixing it by hand.
3. The client's clock is wrong. The connection to the subscription server fails. Turn on automatic time sync.
4. The client is out of date. Older versions may not support the current subscription format. Update the client and try again.
5. Account status changed. Once a plan expires or the data runs out, the subscription may stop updating. Check the plan status on the account overview page in the panel.
6. The local network blocks the subscription domain. Update once on another network (mobile data); if it works, the original network was the problem.

Manual updates and re-importing

1. Find the subscription manager in your client and tap update rather than re-import, to try an incremental update first.
2. If the update fails, delete the subscription, copy the link again from the panel and import it.
3. If the route list is still empty after importing, check whether the end of the link got cut off, because long links often wrap onto two lines in chat apps.
4. If it's still empty, paste the link into your browser. It should return a block of text; an error page means the link itself is broken, so generate a new address in the panel.

The update succeeds but the routes don't change

Some clients cache the route list and only pick up changes after a full restart, so backgrounding isn't enough. Also, subscription routes and manually favourited routes are two separate lists, and updating the subscription doesn't overwrite your favourites. If a region is still there after an update, check whether you favourited it by hand.

When one app can't use the proxy: routing rules and exceptions

The browser works but one app reports a network error, which is the most common routing-rule problem. Check in this order: the proxy mode first, then whether the rules exclude that app's traffic, and only then suspect the route.

The three proxy modes compared

Use global mode as a control: if the app works in global mode, the rule set was excluding it; if it still doesn't work, routing isn't the problem and you should keep going.

Four common cases

1. The rule set treats the app as direct. Update the rule set; if that doesn't help, add the app's domain or process to the proxy list in the client's custom rules.
2. The app uses its own network stack. Some apps do their own DNS or connect over UDP directly, without going through the system proxy. Check whether your client has the option that takes over all traffic enabled (the name varies; TUN mode or enhanced mode are common).
3. The app checks the exit region. Some services restrict access by the region of your exit IP, so try a route in another region.
4. The app cached an old network state. Quit the app completely (not just background it) and reopen it so it builds a fresh connection.

Per-app proxy and exception lists

If your client offers per-app proxy, make sure the app in question is ticked to use the route. Watch both directions: an app that needs the route but isn't ticked won't work, and an app that should go direct but is ticked will slow down local services or break them. Banking apps, screen-mirroring apps and LAN device managers are usually best left direct.

How to verify

1. Open the My IP page (myip.html) and note your current exit IP and region.
2. Open the app that's failing and do something that makes a network request.
3. Go back to the My IP page and refresh. If the IP and region haven't changed, that app's traffic isn't using the route, so the problem is in the routing rules, not the route.
4. Repeat it in global mode to confirm. If the IP changes in global mode but not in rule mode, the rule set is the problem.

Accounts, devices and subscription credentials

This chapter covers account-side symptoms: sign-in state, subscription credentials, plan and data status. First, a rule that's often misread: this service allows unlimited simultaneous devices, so one account can be used on Windows, macOS, iOS, Android and Linux at the same time, with no extra charge for device count and no plans tiered by number of devices.

Where a device limit warning comes from

If you see a warning like that, work out where it comes from first:

• It appears in a third-party client. Some clients keep their own device list; the warning has nothing to do with your account, so switch to the official client or ignore it.
• It appears in the browser. It may be a browser extension or security software flagging the page, not your account.
• It's related to signing in. Check whether your session expired, sign in again and see.

Plans on this service differ only in data allowance and price; there are no device-count tiers. The only real effect of having more devices is faster data use, because several devices streaming at once will use up the monthly allowance sooner.

Your subscription link is a credential

The token in your subscription link is tied to your account. Anyone who gets the link can fetch your route list and use it within your data allowance. So:

• Don't post your subscription link in public groups or forums, or leave it in screenshots.
• Don't hand the link to an unknown subscription converter.
• If you suspect the link has leaked, regenerate the subscription address in the panel, which makes the old one stop working immediately, then re-import it in the client on each device.

Sessions and passwords

Your session is stored locally in the browser, so clearing browser data, switching devices or going a long time without signing in will require you to sign in again. Use a long, unique passphrase for your password rather than reusing one from another site. Changing your password doesn't affect subscriptions already imported on your devices, but you'll need to sign in to the panel again. Signing up needs only a username and password, with no email address.

Data and plan status

Monthly plan data resets on the day you started: sign up on the 9th and it resets on the 9th of each month. Upgrading mid-cycle converts the price difference into remaining days. Data packs last until you use them up and never expire, which suits irregular usage. The account overview page in the panel shows your current plan, data used and expiry date. Plan tiers and prices are on the pricing page.

When to contact support: what to include in a ticket

The previous eight chapters cover almost everything you can fix yourself. This one covers two things: when to stop troubleshooting, and how to give support everything at once so the problem is solved in a single round.

Three cases where you can stop troubleshooting

• The same account can't connect on several devices and several networks, and switching between routes doesn't help.
• Several devices still can't update the subscription after you regenerate the address in the panel.
• The client reports an account status error, or the plan status doesn't match what the panel shows.

Six items every ticket should include

1. Your account username. The username only, never your password.
2. The platform and client where it happens. For example Android client or Windows client.
3. The current route name and type. For example Tokyo · Relay.
4. The exact error text or an accurate description of the symptom. Whether it won't load, is slow or drops, don't mix the three together.
5. The checks you've already run and their results. For example: tried Tokyo relay and Hong Kong IEPL, both failed at the same time.
6. When the problem started and how often it happens. For example, "ongoing since 21:30 on 9/18".

Ticket examples: complete vs. thin

A complete ticket looks like this:

A ticket with too little information looks like this:

The two get very different results: the first can be traced straight to a route or a specific step, while the second takes three or four rounds of back-and-forth and stretches the resolution time several times over.

Where to open a ticket and how to follow up

The ticket form is in the user panel: sign in and go to theticket page to submit one. After that you can view replies and status on the same page. When you have more to add, reply to the original ticket rather than opening a new one, because a single ticket keeps the whole troubleshooting history together, while a new one throws away everything before it.

Questions about plans and refunds can go through the same channel. Both monthly subscriptions and data packs come with a 30-day no-questions-asked refund; full terms are on the Refund Policy page. If you haven't started yet, browse the Pricing page to compare tiers, or just Start Free.