VPNDT Troubleshooting Guide: Diagnose by Symptom

Don't rush to switch clients when something breaks. Along the path from your device to the international gateway, a fault at any point can look like “it won't open.” If you reinstall, reset, and swap software all at once, you may change three things and still not know which one mattered. A faster approach is to split the path into four layers, work out which layer the symptom belongs to, then go to the matching chapter.

How to use the four layers

Work from the top down. If L1 is broken — the device can't even reach the local network — the other three layers don't matter. If the client can't connect at all, focus on L2 and L4. If only one website or one app fails, the problem is most likely in L2 routing rules or L4 route selection. Once you know the layer, the matching chapter on this page is your checklist.

Five-minute general self-check

• Turn the client off and confirm the device can reach everyday websites on its own. If it can't, fix the local network first.
• Check the client status: “not connected,” “connecting,” or “connected.” Each state points to a different chapter.
• Confirm the subscription was updated recently. Routes in a long-stale subscription may already have changed.
• Think about whether you recently changed networks: home Wi-Fi, office network, public hotspot, cellular data. Different networks restrict ports and protocols differently.
• Check that the system clock syncs automatically. A large time offset makes the encrypted handshake fail outright, which shows up as “it just won't connect.”
• Confirm no second proxy or accelerator app is running. Two apps fighting over the system proxy usually leaves both of them broken.
• Log in to the user panel and confirm the plan is still valid and the data allowance isn't used up.
• Note whether the problem only happens on one website, in one app, or at one time of day — those three details narrow things down fast.

What to prepare before opening a ticket

Whichever chapter your problem ends up in, have these ready first: platform and client name; when the problem started and how often it occurs; the exact error text or a screenshot; the steps you already tried and their results (which routes you switched, which network you switched); the region names of the routes involved; and the order number if billing is involved. The last chapter turns all of this into a checklist you can copy directly.

First, tell the three kinds of “can't connect” apart

1. It fails the moment you click connect, or the button does nothing: most likely the client layer or the local network layer.
2. It spins and eventually times out: usually the route is unreachable, or the current network blocks the port in use.
3. It shows connected but no website opens: that isn't a connection problem — go straight to the next chapter, “Connected but pages won't load.”

Device and local network layer

Fully quit the client first and confirm the device can get online by itself. The fastest one-shot test is to switch networks: move from Wi-Fi to a cellular hotspot, or the other way round. If switching fixes it, the problem is a restriction on the original network, not your account or route. Office networks, campus networks, and some public hotspots restrict uncommon ports, and no client-side setting can get around that — switching networks is the only direct fix.

A router that has been running for a long time can exhaust its connection table, which shows up as “everything suddenly stopped working”; a reboot fixes some of these cases. Also check that the system clock syncs automatically: a large time offset makes the encrypted handshake fail outright, and this is not rare on devices where the time or time zone was set manually.

Client layer

Quit the client completely and start it again — quit the process, not just minimize the window. Then switch routes one at a time inside the client. Recommended order: another route in the same region first, then a different region, and finally a different route type (dedicated, relay, direct). If the client offers transport protocol options, switch protocols between two routes and retest; that rules out “this network doesn't like this transport.”

Next, confirm that your firewall and security software aren't blocking the client process. On Windows the most common case is a first-run prompt that got dismissed with “Block,” after which the client can never connect and shows no warning at all. Reinstalling the client comes last. Before you do: get the subscription again by logging in to the user panel rather than relying on a local cache, then import it after reinstalling.

Account and plan layer

Your login may have expired — log out and back in once. In the user panel, confirm the plan is still valid and the data allowance isn't used up: monthly plans come in three tiers, ¥9.9/month with 60GB, ¥18/month with 250GB, and ¥28/month with 500GB, and the allowance resets each month on the activation date. If you use up the monthly allowance early, data packs are available (¥158/300GB, ¥358/1000GB, ¥658/3000GB — use them until they run out, they never expire).

There is no limit on simultaneous devices, so “too many devices got me kicked off” can't happen with this service. Conversely, if several devices fail at the same moment, the problem is in the account, the link, or the local network rather than in one device — that single observation can save you a lot of per-device troubleshooting.

When to contact support

• You have tried more than three routes in different regions and still can't connect at all.
• Switching networks fails the same way, and a second device behaves identically.
• The client log shows a clear error code, or repeated retry entries.
• You still can't connect after resetting the subscription, and the plan status in the panel looks normal.

Opening a ticket with these results is far faster than saying “it won't connect.” Support can start from the directions you have already ruled out.

First, tell the three patterns apart

“Won't load” isn't one fault. Work out which one you have: no website loads at all, only some websites fail (local sites are fine), or only one browser fails. Each pattern points in a completely different direction, and the table below is a direct path through them.

Global vs. rules: one retest sets the direction

Clients usually offer two modes: global mode sends all traffic through the tunnel, while rules mode decides by rule what goes through the tunnel and what connects directly. When troubleshooting, switch to global mode first and open the site that failed. If it opens, the problem is in the routing rules — jump to chapter seven. If it still fails, the problem is in proxy capture, DNS, or the route — keep reading. The value of this step is that one action rules out one whole direction.

Has the system proxy been captured?

The client showing “connected” doesn't mean the system proxy is in effect. On Windows, check the proxy switch and address under Settings → Network & Internet → Proxy. On macOS, look under System Settings → Network → current network → Details → Proxies. Browser extensions, other accelerator apps, and some download tools can quietly rewrite the system proxy to point at their own port. If the proxy address isn't the one your client shows, quit those apps and retest.

Fragmentation and MTU: connected but nothing loads

If the handshake succeeds and the connection looks fine but pages never finish loading, or only some sites time out, packet fragmentation may be involved. Tunneling adds header length, and in some network environments fragments larger than the path MTU are simply dropped. Clients usually offer an “automatic” or manual MTU option — leave it automatic at first, and only fine-tune within a sensible range if the problem persists, changing one value at a time and retesting right away. Changing several parameters at once is the worst thing you can do here.

The browser's own DNS

Most modern browsers ship with “secure DNS” that resolves domains directly, bypassing the system resolver. When it resolves to an address that doesn't suit your current route, the symptom is “the client is fine, other apps are fine, only this browser fails.” The fix: turn the browser's secure DNS off or set it to “follow the system,” clear the browser cache once, and retest.

Order of handling, summarized

• Retest in global mode to tell a rules problem from a capture problem.
• Check the system proxy switch and confirm the address matches the client.
• Turn off the browser's secure DNS and retest in a private window.
• Switch to another route, then another network.
• Compare against another device to see whether it's a single-machine issue.

Do one thing per step, then retest immediately and note the result. If all five steps are done and pages still won't load, move on to chapter eight and work through the DNS resolution path.

Quantify “slow” first

Slow is a subjective feeling — turn it into something comparable first. On the same device, the same website, and at the same time of day, measure “client off, local site” and “client on, target site.” If the local site is slow with the client off too, the problem is local bandwidth or Wi-Fi. If only cross-border access is slow, keep reading. Look at the median of several speed tests rather than a single peak — one run is heavily affected by momentary variation and isn't enough to judge route quality.

Route types and where they fit

Routes on this site come in three types, each suited to different use cases. Picking the wrong type is one of the most common causes of “slow speeds.”

Why peak hours are slow

The bottleneck at peak hours is usually not the server side but the cross-border link itself: international gateways are congested overall during this window, and home broadband upstream is heavily used as well. Three things help: switch to a dedicated route so a private channel avoids queuing on public paths; switch to a nearby region (Hong Kong, Japan, Singapore) to shorten the cross-border segment; and move heavy tasks (system updates, cloud drive sync, game updates) out of peak hours so you don't saturate your own bandwidth.

Don't overlook local factors

• Weak Wi-Fi signal, or a crowded band. Use a network cable if you can — it's the easiest one-time improvement.
• An old router, or one that hasn't been restarted in a long time, degrades both its connection table and forwarding performance.
• Background system updates, cloud drive sync, or file downloads saturate the upstream, and then every route looks slow.
• A browser with dozens of tabs and extensions open slows down page loading on its own.
• Security software running a full-disk scan hogs disk and network at the same time.

What counts as a valid test

Same tools, same time window, several rounds. The full method — which tools to pick, how many runs at peak and off-peak, and what latency, jitter, packet loss, and throughput each tell you — is laid out step by step in the blog post How to Run Your Own VPN Speed Test: Methods, Tools, and Time Windows. Follow it once and you'll have a comparable record.

Two common misreadings

The first is mistaking a streaming platform's automatic bitrate drop for a route fault. Platforms adjust picture quality based on real-time bandwidth, so a blurrier image is their policy and not necessarily a route problem; the mechanics are covered in Best VPN for 4K Streaming: Why Quality Drops to 480p and Which Route Metrics Matter. The second is treating a single peak as a conclusion: one fast or slow run says nothing about a route's long-term behavior — several rounds of medians are what count.

Record the drop pattern first

The worst thing about drop issues is the feeling that “it's always dropping.” Two minutes of note-taking makes the direction obvious:

• Drops at a fixed interval, say five or thirty minutes: usually related to keep-alive behavior or a system policy.
• Random drops with no pattern: usually network jitter, or the route itself being adjusted.
• Drops only when switching networks, e.g. between Wi-Fi and cellular: a system reconnect policy issue.
• Drops only after screen lock or sleep: system power saving and background limits.
• Drops only at a certain time of day: related to link congestion windows.

Desktop: sleep, power saving, and the network adapter

Sleeping suspends network connections, and some clients don't recover automatically on wake, which looks like “it dropped for no reason.” Fixes: turn on auto-reconnect in the client; switch the power plan from “Power saver” to “Balanced” or “High performance” and retest; and in the network adapter driver settings, turn off “Allow the computer to turn off this device to save power.” Also, when a client exits abnormally the system proxy switch is sometimes left on, which shows up as “it dropped and now it won't connect at all” — turn the system proxy off manually and reconnect.

Mobile: background policy is the main cause

Both iOS and Android restrict background network activity when the screen is locked or the battery is low. On iOS, Low Power Mode tightens background refresh and network activity, so connections are more likely to be suspended after locking; Android vendors' battery optimization policies vary even more, so you need to add the client to the “unrestricted” allowlist and permit background activity. Also, after a major OS update, VPN configuration permissions occasionally need to be confirmed again — which shows up as “it stopped connecting right after the system update.” Just re-authorize.

Routers and multi-device setups

When you run a global proxy on the router, the router's memory and connection limits become the bottleneck, and heavy downloads compete with each other — which shows up as “it drops when there are more people.” This service places no limit on simultaneous devices, so multiple devices won't kick each other offline; if several devices drop at the same moment, suspect the exit link or the local network rather than the device count.

Telling a route drop from a local drop

• Does another device on the same account drop at the same time? Both dropping points to the link; only one dropping points to that machine.
• Does it still drop on another route? If switching routes fixes it, the original route was unstable during that window.
• Does it still drop on another network? If switching networks fixes it, the original network is at fault.
• Do local sites work while the connection is down? If local sites fail too, the problem has nothing to do with the cross-border link.

If any one of these four reproduces, you've halved the search space. Write down the drop times and compare them against local network events (router reboots, system updates, ISP fluctuations) — that often points straight at the cause.

How a subscription link works

A subscription link is an address with a token that the client uses to pull the latest route list from the server. It works like a credential: anyone who has the link can import the routes. The same link can be imported on multiple devices — this service places no limit on simultaneous devices, so you don't need a separate one per device. With that in mind, every “update failed” case follows the same logic: either the link itself is no longer valid, or the client couldn't get the request out.

Common failure patterns and fixes

Import and update paths by platform

• Windows / macOS: open the client → Subscription management → Add subscription → paste the link → Update.
• iOS / Android: add the subscription in the client, then pull down to refresh once.
• Linux: import the subscription as described by your client; with command-line clients, mind the config file path and permissions.

Subscriptions for every platform come from the user panel — log in and copy from the downloads and subscription section; this site does not publish any static subscription address. Step-by-step instructions per platform are on the guides page; the full concept of subscription links, importing, and handling leaks is covered in the blog post What Is a Subscription Link? A Complete Beginner's Guide.

Link leaks and resets

A subscription link is a credential: don't post it in public groups or forums, and don't leave it visible in screenshots. If you suspect a leak, reset the subscription link in the user panel and re-import it on each device — the old link stops working the moment you reset, and the same step also resolves “the link is being rate-limited or used abnormally.”

Example links in articles and guides are always fake, for instance https://example.com/sub?token=YOUR_TOKEN. Never paste an address that looks like a real token in a public place.

Route names change after an update

Route names and groups change with operations, and a rename doesn't affect how they work; if a route disappears, just pick another one in the same region inside the client. Don't reinstall the client over and over because a name changed — reinstalling won't undo an operational change, it only costs you time.

How routing rules work

In rules mode, the client decides by domain, IP range, or process whether traffic goes through the tunnel or connects directly. Anything the rules don't cover connects directly — in a cross-border scenario that shows up as “this app won't use the proxy.” Understand that first, then look at which kind of app you have: different categories need very different handling.

Use global mode for a quick verdict

Switch to global mode and retest: if the app recovers, the problem is in the rules and you just need to add one; if it still fails, the problem is in how the app gets captured (some apps never read the system proxy at all), or in its own use of UDP or its own DNS implementation. After this step, only one path remains.

A few common cases

• Desktop software and sync drives: some don't read the system proxy and need the client's TUN / virtual adapter mode to capture all traffic.
• Microsoft Store apps: affected by system network isolation, they need the matching capture option enabled in the client.
• Browsers: extension proxies override the system proxy — disable the extension and retest before deciding whether to configure it there.
• Command-line tools: you need to set proxy environment variables manually; see the example below.
• Games: most use UDP, so you need a mode that forwards UDP; games are also latency-sensitive, so prefer a route in a nearby region.

Command-line proxy example

export HTTPS_PROXY=http://127.0.0.1:7890
export HTTP_PROXY=http://127.0.0.1:7890
curl -I https://example.com

Use the port your client actually shows — the example above is only an illustration. In Windows PowerShell the equivalent is $env:HTTPS_PROXY="http://127.0.0.1:7890". If the command line works after this but the app still doesn't, the problem is in the app itself, not the route or the rules.

Capture modes by platform

Order of handling

1. Retest in global mode to confirm whether it's a rules problem or a capture problem.
2. Switch capture mode: if the system proxy doesn't work, try TUN / virtual adapter mode.
3. Add a custom rule for that app's target domain or process.
4. If it still fails, try per-process proxying to narrow it down to a single program.
5. If none of that works, include the app name and target service in your ticket so it can be diagnosed further.

What DNS problems look like

• A few seconds of “resolving” before a page starts loading, then everything is normal.
• The same site opens on one device but not another, with both on the same route.
• Typing the domain fails, but visiting the IP directly works.
• The symptom disappears after switching networks.

What these have in common: the problem isn't whether you can connect, but what the domain resolves to.

Diagnostic commands

# Windows
nslookup example.com
ipconfig /flushdns

# macOS
dig example.com
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

# Linux
dig example.com
resolvectl flush-caches

Record the resolution result for the same domain with the client on and with the client off. If both results match, the lookup never went through the tunnel — a classic leak. If resolution gets slower or fails with the client on, the resolver inside the tunnel is unreachable on the current route; switch routes and retest.

What a DNS leak means

When DNS requests don't go through the tunnel, they're handled by the local network or your ISP's resolver. That has two effects: the result may be a nearby address, which actually takes a longer path for cross-border access and shows up as “connects but slow”; and your browsing intent is exposed outside the tunnel. It doesn't affect encryption itself, but it's worth fixing while you're at it.

How to fix it

• Set the client's DNS option to “use DNS inside the tunnel” or “follow the system,” try both, and keep whichever resolves more reliably.
• Switch the system DNS to a stable public resolver, then clear the cache once.
• Turn off the browser's secure DNS so it follows the system setting.
• Check DNS at the router level too, especially if the proxy runs on the router.

The My IP page on this site shows your current exit IP and its location, which confirms whether traffic really goes through the tunnel; checking the exit before digging into DNS keeps you from wasting time in the wrong direction.

How this relates to “connected but pages won't load”

DNS problems and chapter three, “connected but pages won't load,” often appear together. Suggested order: work through proxy capture and browser settings in chapter three first, then come back here for the resolution path; if both chapters are done and the problem persists, consider switching routes or comparing against another device.

No limit on simultaneous devices

Plans from this service don't limit how many devices are online at once, so using several at the same time won't trigger any restriction and you never need to buy extra “device slots.” What deserves attention instead is account sharing: when several people share one account and something breaks, it's hard to tell which device or which network is at fault, and the troubleshooting cost multiplies; sharing also spreads the subscription link around, which brings unnecessary risk. If all the devices are yours, log in on all of them at once with confidence.

Account and subscription issues

• Login fails: check the username and password first; if you've forgotten the password, use the recovery flow in the user panel. Sign-up needs no email address — just a username and password — so there's no waiting for a verification email.
• Can't retrieve the subscription: subscriptions are available after logging in to the user panel, so you can't get one while logged out or with an expired session; log in again and copy it from the downloads and subscription section.
• Plan expired or allowance used up: monthly plans come in three tiers, ¥9.9/month with 60GB, ¥18/month with 250GB, and ¥28/month with 500GB, and the allowance resets each month on the activation date. If you use up the monthly allowance early, data packs are available (¥158/300GB, ¥358/1000GB, ¥658/3000GB — use them until they run out, they never expire). If you upgrade mid-term, the price difference is converted into remaining days.
• Billing questions: include the order number in the ticket and it will be handled much faster.

Full details on plans and data packs are on the plans page; the complete list of route regions and types is on the servers page — compare them before choosing a route.

Six cases that warrant contacting support

1. The problem still reproduces after working through the matching chapter, and you can't narrow it down further.
2. Switching networks, routes, and devices all fail.
3. Several devices fail at the same moment.
4. The client log shows a clear error code or repeated retries.
5. The subscription still won't update after a link reset.
6. Orders, refunds, and billing are involved. The refund promise is a 60-day money-back guarantee — if you qualify, just include the order details in your ticket.

What to include in a ticket

• Account username (never include the password).
• Platform and client name.
• When the problem started and how often it occurs.
• The exact symptom and error text; a screenshot is even better.
• Steps you've already taken and their results, e.g. which routes and which networks you switched to.
• Region names of the routes involved.
• The order number if billing is involved.

Where to open a ticket, and how fast things move

The ticket section is in the user panel — log in and submit from there. Don't open several tickets for the same issue: duplicates scramble the queue and actually slow things down; if you need to add information, append it to the original ticket. The most common back-and-forth is “missing symptom description,” so filling in the checklist above usually says everything in one go.