VPN Troubleshooting Guide

Before You Troubleshoot: Three Layers, Three Swaps

Bottom line first: most "can't connect" cases aren't a route failure — they come from one of three places: your local network, the client configuration, or the destination service. Locate the layer first, then change something. Reinstalling the client and cycling through routes straight away only stirs the variables together, until you can't say which step made the difference.

Break the problem into three layers

The first layer is your local network: the broadband uplink, router policies, and access controls inside the LAN. The test is simple — turn the accelerator off and see whether sites in mainland China still load; then move the device to another network (mobile hotspot, a different Wi-Fi) and see whether it recovers. If it does, the problem is in this layer, and you can leave the other two alone for now.

The second layer is the client and the account: whether the subscription is current, whether the account is still within its term, and whether the data allowance is used up. Monthly plans reset on the day you subscribed each month, not on the calendar month — confirm this first, so you don't mistake "just ran out" for a route failure. Whether the same account works on another device is the other test for this layer.

The third layer is the route and the destination service: does switching route type (IEPL dedicated / relay / direct) bring it back? If only one site fails while everything else is fine, it's most likely the destination service itself, and changing routes won't help. The differences between route types and where each fits are laid out in full on the Routes page.

The three-swap method: change one variable at a time

Swap the network: move the device from its current Wi-Fi to a mobile hotspot. If it recovers, the problem is in the original network uplink or router, not the account or the route.

Swap the device: connect with the same account on another device. If it recovers, the account and the route are both fine, and the problem is in the original device's client or system configuration.

Swap the route: on the same device, switch the route type from dedicated to relay or direct. If it recovers, something is wrong on the original route; note down its name and region — you'll want them when you open a ticket.

The value of the three-swap method is that it creates no new variables: change one thing at a time and the result actually points somewhere. If you've swapped all three and the problem is still there, go straight to the ticket process in the last chapter of this page — there's no point trying more parameter combinations in the client.

Three checks you can finish in 30 seconds

Account and data: sign in to the user panel and look at the account status and this month's remaining data. The numbers in the panel are the only source of truth — go by them, not by memory.

Subscription and client: copy the subscription again from the panel, then run "Update subscription" once manually in the client. Note that this is an update, not a reinstall — a reinstall throws away your split-tunnel settings and adds another variable.

System time: turn on automatic time sync. A clock offset directly affects the encrypted handshake, and the symptom is "it just won't connect" — yet this is the item people skip most often when self-checking. The routes run over military-grade encrypted tunnels, so a handshake that's sensitive to time is by design.

Below are the four fixed service figures; every chapter that follows is judged against them:

Can't Connect at All: Read the Error Signal, Then Pick One of Three Paths

Bottom line first: "can't connect at all" isn't one problem, it's three. A client that throws an error, a spinner that never resolves, and a connection that shows connected then drops straight back — these three signals point to almost non-overlapping causes, and handling them separately is far faster than trying parameters one by one.

Start with the signal the client gives you

Error message: the client shows a clear error. This usually points to configuration, the account, or system time. For this one, go back to the three must-checks in the previous chapter first, and only consider changing routes once those are confirmed.

Stuck spinning: the client sits at "connecting" with no error and no success. This usually points to local network policy — an uplink restriction on the network you're on, access controls on the router, or another acceleration app on the same machine grabbing the system routes.

Connects then drops: it briefly shows connected, then falls back to disconnected. This usually points to the protocol and port being reset by an intermediary device, or two proxy stacks both taking over the system network and knocking each other out.

Local network self-checks: do them in order, one minute each

1. Close any other acceleration, proxy, or packet-capture software on the same device. Two TUN interfaces or two proxy stacks running at once fight over routes — this is the most common cause of "can't connect at all", and it's completely invisible in the client UI.
2. Change the uplink: move from Wi-Fi to a mobile hotspot. If it recovers, the original network uplink is restricted, and the account and route are not involved.
3. Check the router: parental controls, internet access schedules, forced IPv6, and custom DNS settings can all block the connection. Turn them off one at a time and retry.
4. Restart the client process, not the whole computer. The former clears the client's connection state; the latter introduces too many variables and makes the result harder to read.

Client and account fixes

Step one is to fetch the subscription again: sign in to the user panel, copy the latest subscription from the download area, and update it in the client. Step two is to change route type — try IEPL dedicated, relay, and direct in that order, and wait 30 seconds after each connection before judging the result rather than switching away immediately.

Step three is to verify that system time is set to sync automatically. Step four is to confirm account status and remaining data: an expired account or an exhausted allowance looks exactly like "can't connect", but the client may not report it accurately, so this step has to be checked in the panel.

Connected but Pages Won't Load: DNS and Split-Tunnel Checks in Order

Bottom line first: in this category, DNS resolution failures and split-tunnel rules that don't match account for most cases, with the destination service itself failing a distant third. The order of checks is — first establish whether nothing loads or only some things don't, then decide whether to look at DNS or at split tunneling.

Three symptoms, three directions

Domain resolution failure: the browser says the server can't be found or the domain can't be resolved, but the client shows connected. The direction is DNS — run the three commands below.

Some sites work, some don't: sites in mainland China are fine but a particular overseas site won't load, or the reverse. The direction is split-tunnel rules — see the "One app won't use the proxy" chapter later on this page.

Nothing loads: no site loads at all. The direction is an uplink or DNS problem across the board — work through the previous chapter first, then come back here.

DNS Self-Check: Three Commands

Run the commands below in your system terminal, replacing example.com with the domain that actually won't load. The three commands answer three questions: whether the domain resolves, whether the result comes from the same DNS the machine is using, and whether the handshake to the destination is healthy. On Windows, nslookup and curl work in the built-in command line; dig needs to be installed separately on some systems — if it isn't there, use nslookup instead.

# 1. Check whether the domain resolves to an IP
nslookup example.com

# 2. Keep only the resolution result, so two lookups can be compared
dig example.com +short

# 3. Test connectivity and handshake time to the destination
curl -I --max-time 10 https://example.com

If the first command returns an IP address, the resolution path is working; a timeout or "server not found" means the DNS request got no response. Run the second command once with the accelerator on and once with it off — different results mean the two DNS setups resolve along different paths, which is normal in itself, but it tells you which one you're currently using. The third returns an HTTP status code and timing, which separates "can't connect" from "connected but the other side isn't responding" — two very different situations.

The fix: switch your system DNS to a public resolver (1.1.1.1 or 8.8.8.8, for example), or turn on the built-in DNS handling option in the client. Note that the client setting is what counts — system DNS and client DNS can differ, so you have to change both for the change to be complete; changing only one often shows no difference at all.

Rule out a problem with the destination service itself

There's only one test: switch to another network, or turn the accelerator off and connect directly, and see whether the same site recovers. If it works on a direct connection but not through the accelerator, the problem is in the acceleration path; if it fails both ways, the problem is the destination site itself, or the path from your local uplink to it, and has nothing to do with this service.

There's another case that's easy to misread: the site is under maintenance, or it restricts the region your exit is in. Here, changing route type or region usually brings it back with no configuration changes at all. Streaming sites vary far more by region — check the regional notes on the Streaming page to confirm whether that region is in the optimised range.

Slow Speeds and Peak-Hour Lag: Measure Which Segment Is Slow First

Bottom line first: "slow" happens in at least three places — your local uplink, the path to the acceleration node, and the node-to-destination path. Changing routes without knowing which one is slow is mostly wasted effort. Measure all three segments first, then decide what to change.

Split the path into three segments and measure

Segment one, the local uplink: turn the accelerator off and download a large file to see whether the rate is stable. If your local connection is slow to begin with, or other devices at home are running downloads, cloud sync, or system updates at the same time, then no accelerator can beat the uplink — this segment has nothing to do with the service.

Segment two, the path to the acceleration node: turn the accelerator on, connect to a geographically nearby region, and watch the rate fluctuate over several minutes. Small fluctuations mean this segment is stable; big swings mean packets are being dropped or queued between your network and the node, and changing route type usually helps.

Segment three, node to destination: open the target video or page and watch how it buffers. If the first two segments are fine and only this one is slow, the direction is the cross-border link itself, and the fix is to change route type, not to reinstall the client.

How to choose a route type

The three route types don't differ in "fast or slow" — they differ in how traffic travels and what each is suited to. Picking the wrong type and then complaining about speed is the most common misjudgement.

The full route list and regional groups are on the Routes page, where every route is listed by country and city with its type and streaming support — just pick the one matching your destination's region.

Peak-hour lag: why it happens and what to do

Peak-hour slowdowns happen because the public internet uplink queues up at certain times of day — nobody is stealing your bandwidth. Order of handling: switch to an IEPL dedicated route first; if dedicated isn't ideal either, change region; move bulk downloads and system updates to off-peak hours.

IEPL dedicated routes travel over a dedicated channel and don't pass through the public internet uplink, so peak-hour fluctuation is noticeably smaller than on direct routes — which is why they're the first choice for video and meetings. To tell whether a problem is peak-hour related, just compare the same route in the morning and in the evening; no extra tools needed.

Three client-side tweaks

Leave the protocol on the default automatic selection; only specify a protocol manually when the default genuinely won't connect or is clearly slow, and change one setting at a time. Use split-tunnel rules so only the traffic that needs it goes through the accelerator, cutting needless load; cloud sync, live streams, and system updates on the same device eat a lot of bandwidth, so confirm they aren't running before you run a speed test.

Frequent Drops and Mobile Background Disconnects: Four Common Causes

Bottom line first: frequent drops usually aren't on the service side — they come from four places: network switching, system sleep, conflicting acceleration apps, and router session ageing. On mobile there's an extra layer: battery-saving policies freeze background processes.

Four common causes on desktop

Network switching: a laptop moving back and forth between Wi-Fi and Ethernet, or roaming between Wi-Fi networks, rebuilds the connection every time — which shows up as "it drops after a while". The test is whether a network change accompanies each drop; if so, there's no need to look at the client.

System sleep: closing the lid, sleeping, or turning the display off suspends the system, and by the time it wakes the old connection is already dead. The fix is to relax the sleep policy, or simply reconnect manually after waking — no reinstall of anything.

Conflicting acceleration apps: two clients taking over the system network at once knock each other out on a cycle. The signature is that drops happen at very regular intervals, and the two clients' statuses alternate.

Router session ageing: connections left idle for a long time get reclaimed by the router, which shows up as "it drops after sitting unused for a while". This kind of drop usually recovers on reconnect, is normal behaviour, and needs no action.

Mobile background disconnects

Mobile operating systems freeze apps in the background under battery-saving policies, and that includes acceleration clients. On Android you need to add the client to the battery optimisation allowlist and permit background activity; on iOS you need to allow background refresh. Step-by-step paths for each system are in the Android from Scratch article — just follow it through.

Switching mobile networks also triggers a reconnect: walking out of Wi-Fi range onto mobile data, or moving between network generations, rebuilds the connection. This is normal network behaviour, not a drop, and it doesn't affect your account or data.

Telling a "real drop" from a "fast reconnect"

Check whether the connection timer in the client has reset to zero: if it has, the connection really did drop; if not, the connection was up the whole time and some app just stalled on its own — the acceleration path isn't the problem. Then check the log for consecutive reconnect entries: several in a row means a real drop, while a single occasional entry is just network jitter.

If you have a lot of devices at home and want the whole network to go through the accelerator, a router-level setup saves you configuring every device individually, but the hardware bar and maintenance cost are higher — see the trade-offs in Router VPN options compared. Pick the right approach and most desktop drop problems go away.

Subscription Update Failures: Links, Cache and Import Protocol

Bottom line first: subscription update failures usually come down to three things — an incomplete or expired link, the client caching old content, and the wrong import protocol. None of the three needs a client reinstall to diagnose or fix; just try them in order.

Where the subscription link comes from and what it looks like

Sign in to the user panel and copy the subscription link from the overview or download area. The link looks like the one below; the token is a string unique to your account and is only visible after you sign in:

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

The above is a format example, not a working address. Don't post the real link in public channels or share it in screenshots — anyone who has the link has your subscription. When you need it on a new device, just sign in to the panel and copy it again.

Four reasons an update fails

1. Incomplete copy: chat apps and note-taking apps insert line breaks into long links or drop the middle. When copying, make sure the start and end are intact, and check for stray spaces after pasting.
2. The client cached old content: run "Update subscription" manually in the client rather than reinstalling. A reinstall throws away your split-tunnel settings and brings the old cache back with it.
3. System clock offset: request validation is time-sensitive, and a wrong clock gets rejected outright. Turn on automatic time sync and try again.
4. Wrong import protocol: the import priority is clashplus://, Shadowrocket, Stash, sing-box, Clash, in that order. The same subscription link is recognised by different protocols in different clients — use the ones earlier in the list first, as they have the best compatibility.

When to fetch the subscription again

After reinstalling a client, changing devices, or changing plans, copy the subscription again from the panel rather than continuing to use one you saved months ago. Go by whatever the panel currently shows — even if an old link still works, that doesn't mean it carries the latest routes and rules.

If an error appears during the update, write down the exact error text first — pasting it into the ticket is far more useful than describing it as "the update doesn't work". Account and plan matters are handled in the ticket area of the user panel; see the last chapter of this page for the details.

One App Won't Use the Proxy: How to Check Split-Tunnel Rules

Bottom line first: when a single app won't go through the accelerator, nine times out of ten it's the split-tunnel rules or the app's own networking, not a route failure — because every other app works, which already proves the route is up.

Three ways split-tunnel rules match

Domain rules: match on the domain being visited — the most common and the easiest to understand. IP range rules: match on the destination address range, used for services that aren't reached by domain. Process and application rules: match on the program making the request — the finest granularity, but the client has to support it.

Matching runs from specific to broad: process rules take priority over domain rules, domain rules over IP range rules, and the default policy comes last. If a direct-connection rule matches, that app's traffic won't go through the accelerator — this is the most common reason an app won't use the proxy, and it's completely invisible in the UI.

Three typical scenarios

Four-step troubleshooting

1. Switch to global mode for a comparison test. If it works in global mode, the route is fine and the problem is in the rules; if it still doesn't work, the limit is in the app itself or the destination service. Global mode is a diagnostic tool only — keep using rule mode day to day.
2. Go through the client's rule list and see whether a direct rule matches that app. If it does, reorder the rules or add a dedicated rule for the app.
3. Try a different route type to rule out UDP and port-related limits.
4. Only after all three steps above are confirmed should you consider custom rules. Fewer custom rules is better — the more you add, the harder later troubleshooting becomes.

Streaming apps are a special case: content and availability differ by region on every platform, so you need the route for the matching region — the regional notes are on the Streaming page. The logic for choosing a route is the same as the four steps above; only the destination region follows the platform.

Devices, Data and Account Issues: Which Limits Actually Exist

Bottom line first: VPNOh doesn't limit simultaneous devices — the same account can be used on Windows / macOS / iOS / Android / Linux at the same time. So the "device limit exceeded" message common with other services doesn't exist here; only two things can actually stop you — account status and remaining data.

What unlimited devices means

Unlimited devices means there's no cap on how many devices can be online at once: the computers, phones, tablets, and TV boxes at home can all be signed in to the same account at the same time, with no need to buy a separate plan for each. Sharing one account within a household is allowed; the only figure to watch is data — every device draws on the same allowance.

The details of how sharing works across devices, and what to watch out for, are covered in full in the Best VPN for multiple devices article, including how a family can split data, which devices suit an always-on connection, and which should connect on demand. Device count isn't the limit; planning how you use the data is what needs thought.

What to do if you see a "device limit exceeded" style message

First confirm which client the message comes from. If other services are installed on the device and still present, the message may come from them and have nothing to do with this service — uninstall or disable them and check again.

If you've confirmed that this service's account is being used elsewhere, the fix is to change your password and then fetch the subscription again from the panel. When the client has an old subscription cached, you can also see "status looks wrong" behaviour; updating the subscription manually restores normal operation.

Data and plans

There are three monthly plans: ¥9.9/month with 60GB, ¥18/month with 250GB, and ¥28/month with 500GB. Data resets monthly on the day you subscribed, not on the calendar month; if you upgrade mid-cycle, the price difference is converted into the remaining days, with no need to wait for the next cycle.

Data packs suit users with irregular usage: ¥158/300GB, ¥358/1000GB, and ¥658/3000GB — use them until they run out, and they never expire. For how much data light browsing, long-term streaming, and remote work each need, the Data packs vs monthly plans article gives estimation methods. Full pricing and plan comparisons are on the Pricing page.

Refunds and account matters

This service offers a 14-day no-questions-asked refund; the request form is inside the user panel, submitted through the ticket process. Account sign-up doesn't require an email address — a username and password is all it takes; so keep your password in a password manager and don't reuse a password from another site.

Account, order, and payment issues all fall into the category that needs a human to check, so just open a ticket using the checklist in the next chapter — there's no need to keep trying random operations in the meantime.

When to Contact Support: What to Include in a Ticket

Bottom line first: if you've worked through the matching chapter, changed networks and routes, and the problem is still there, it's time to open a ticket. The quality of the ticket directly determines how fast it's handled — a one-line ticket and a ticket with complete information take completely different paths.

Three cases where you can open a ticket straight away

First, the flow on this page didn't solve it: you've tried all three swaps, fetched the subscription again, and synced the system clock, and the connection is still abnormal. Second, account, order, and payment issues: these need a human to check and can't be solved by self-troubleshooting. Third, operations that need manual confirmation: plan changes, refund requests, and account-related handling.

Conversely, if you open a ticket before doing the three swaps, whoever handles it will certainly ask you to do them first. Getting the variables clean before you submit is the fastest route.

Five things to include in a ticket

The last two of the five are the ones most often left out. The exact error text is more useful than "it won't connect", and the troubleshooting you've already done is more useful than "I tried everything" — write up the results of the three swaps clearly and whoever handles it can jump straight to the next step instead of starting over from the first question.

Ticket entry point and other channels

Sign in to the user panel and submit in the ticket area: Open a ticket. Other contact methods and support scope are on the Contact page. Don't submit several tickets for the same issue — duplicates split the handling record and actually slow things down.

Cases where you don't need a ticket

Data used up: renew or upgrade the plan directly in the panel — data resets monthly on the day you subscribed, and an upgrade's price difference is converted into remaining days. Don't know how to import a subscription: see the Quick Start guide, which has full step-by-step instructions by platform. The destination site itself is down: compare on another network or another route to confirm it isn't this service, then wait for it to recover.

There's another category beginners ask about most: can I use it on several devices, how is data counted, should I leave it on all the time, will it be throttled. VPN FAQ for beginners answers that whole group in one place; more detailed Q&A by topic is in the Help Center. Use this troubleshooting guide alongside them: locate the problem here first, then go to the matching page for the details.