Troubleshooting handbook

Before you start: identify the four layers

Failures in an acceleration service look wildly different, but they can only originate in four places. Working layer by layer is far faster than restarting the client over and over, and it stops you wasting time on settings that were never involved. From nearest to farthest, the four layers are: the local network, client traffic capture, subscription and account, and the exit node.

What each layer covers

• Local network layer. Device to router, router to ISP. If this layer is down, no route will connect — the symptom is that no website loads at all.
• Client layer. Whether the client process actually captures traffic, whether the system proxy is in effect, and how routing rules are being evaluated. When this layer fails, the client says connected but apps don't go through the proxy.
• Subscription and account layer. Whether the token in the subscription URL is valid, whether the route list is current, and whether the plan is still active. When this layer fails, the route list is empty or updates fail.
• Exit node layer. The path from the landing node to the destination site. When this layer fails, only one region or one website is affected.

Work from near to far. First confirm the device can get online at all, then check whether the client is capturing traffic, then check the subscription and account, and only then suspect the node. Do it the other way round and the usual outcome is mistaking a local network problem for a node problem — swapping every route won't help.

Thirty-second starting point

Turn the client off and open a site hosted in mainland China. If it loads, the local network is fine and you can carry on; if it doesn't, fix the local network first and skip everything below. It sounds too basic to bother with, but in practice a good share of "can't connect" cases end here: the router dropped, the broadband bill is unpaid, or the public Wi-Fi still needs portal authentication.

Three commands to inspect the path

When the GUI shows nothing useful, the command line gives you specifics. The commands below ship with every system — nothing to install.

In the commands, www.example.com can be replaced with any domain you want to reach. If pinging the domain fails but pinging a known IP address works, the problem is resolution rather than the path — jump straight to the DNS chapter.

Change one variable at a time

The most common mistake is changing three things at once: switching route, switching protocol and reinstalling the client in one go. If it works you don't know which change did it; if it doesn't, you don't know which step to undo. Do it properly: note the current state, change one thing, retest immediately, and roll back if it doesn't help. The same habit pays off in a ticket — support can reproduce your environment from it.

Capture evidence before you touch anything

Most clients have connection logs or a diagnostics entry point. When something breaks, export or screenshot the logs first, especially the exact error text. Reinstalling the client wipes local logs, so capture evidence before you consider a reinstall. The three most valuable things in a ticket are: the exact error, the time it happened, and the steps you have already tried.

Won't connect at all: error messages or an endless spinner

First separate the two behaviours. One is the client explicitly reporting a failed connection or a timeout — the handshake itself failed, so the cause is usually clear. The other is a permanent "connecting" state with no feedback, which is usually packet loss on the path or a stuck client process. Chase the first by error message, the second by network environment.

Four steps to narrow it down

1. Confirm the local network. Turn the client off and visit a site in mainland China. If it won't load, fix the local network first: cable, Wi-Fi association, router indicator lights, portal authentication on public networks.
2. Try another route. Switch to a route in a different region inside the client. If every route fails, the problem is in the account or subscription layer; if only a few fail, just pick another one and stop there.
3. Try another network. Connect once over a different network. If it works there, the original network is restricting specific ports or protocols — it isn't an account problem.
4. Check account status. Sign in to the user panel and check whether the subscription is still active and whether data is used up. Monthly plans reset their allowance each month on the activation date; data packs last until used up and never expire.

Common causes at a glance

If the four steps haven't located it, work down this table from the top.

System time is the easiest thing to overlook

Encrypted handshakes are time-sensitive. If the device clock is a few minutes off from standard time, certificate validation fails — the symptom is a connection that drops immediately, or a handshake that simply times out. A laptop that has been offline for a long time, a dying CMOS battery, or a manually changed time zone will all do it. Turn on automatic time, wait for the sync to finish, and try again.

Security software and leftover system proxy settings

Some security suites intercept the network activity of client processes, especially on first run. The symptom is a client that reports connected while traffic goes nowhere. Add the client to the trusted list or allow rules and retry. Another case is a system proxy left behind by an abnormal exit: the system still points at a local port that no longer exists. Set the proxy back to off in system settings and let the client take over again.

If you've been through the four steps and the table and the problem still reproduces reliably — same result on another network and another device — it's safe to conclude this isn't your local environment. Collect the information listed in the last chapter and open a ticket.

Connected but pages won't load

The client says connected, but the browser spins, reports that the site can't be reached, or fails DNS resolution. This is the case most often misdiagnosed as a dead node; in reality it's usually how traffic is captured or how resolution is configured. Start with a binary split: is it every site, or only some?

No site loads at all

That means traffic isn't leaving at all, or it leaves and never comes back. Check three things in order.

• Is the system proxy in effect? On Windows, look at the proxy section under Network and Internet in Settings; with the client running you should see a local address and port. If it shows off and the client is in system-proxy mode, capture has failed.
• Is the client in TUN mode? TUN mode captures traffic at the network adapter, so the system proxy showing off is normal. In that case watch the client's own connection status and whether its traffic counters increase.
• Does the MTU match? A connection that establishes but drops large packets shows up as pages that stall halfway and eventually time out. Lower the client MTU by one step and retry.

Only some sites won't load

That means traffic is leaving, but the routing rules decided the destination should go direct, or the destination site is rejecting the request by region. Switch the client to global mode once to check: if it loads in global mode, it's a rules problem; if it still fails in global mode, it's the destination site or the route's region.

In rule mode the client decides whether to use the proxy by domain or address. Some sites use several domains: the main domain goes through the proxy while the static-asset domain is judged direct, so the page structure loads but the styling and images are missing. When that happens, add the site to the proxy rules or use global mode temporarily.

Rule out the browser first

Open the same site in a private window. If it works in private but not in a normal window, it's almost certainly cache or an HSTS record — clear the cache once. Also, a browser's built-in secure DNS skips system resolution and breaks routing rules, so turn it off while you troubleshoot.

Confirm the exit region

Some sites don't fail to load — they load and then report that your region is unavailable. That isn't a fault; the exit region doesn't match what the site requires. Check the current exit region in the client's connection details, then switch to a region the site supports. Streaming and AI tools are especially strict about region; see the AI acceleration feature on this site for details.

Slow speeds and peak-hour congestion

There are at least three kinds of slow, and they're handled completely differently. Slow page loads mean a long time to first byte, usually high latency or slow resolution. Slow downloads mean sustained throughput won't climb, usually limited bandwidth or a congested path. Choppy video means a blurry picture and constant buffering, usually enough bandwidth but high jitter. Work out which one you have before treating it.

Measure in stages

1. Measure a baseline without the client. Test the device's speed to a site in mainland China directly and write the result down.
2. Measure with the client on. Connect to the nearest region and test again. A big drop means that route's path to your location isn't great.
3. Test different route types in the same region. A region usually has dedicated, relayed and direct routes; test each one and the difference will be obvious.

Turn off background downloads, cloud-drive sync and system updates while testing. Instantaneous peaks from speed-test tools aren't very meaningful; the average over a minute of sustained download is closer to what you'll actually feel.

Peak hours are a physical phenomenon

Between 20:00 and 23:00 the cross-border path is at its most crowded. During those hours the shared bandwidth at the international gateway is divided among a lot of users, latency rises and packet loss increases — no service escapes it. What differs is the route type: dedicated lines run on their own channel and don't compete for shared gateway bandwidth, so they hold up relatively well at peak; relayed routes reach a relay node first and then leave the country, cost less, and fluctuate more than dedicated lines; direct routes use the public internet gateway, cost the least, and are the least stable at peak.

If your main use is 4K in the evening or long meetings, pick a dedicated route; if you only look things up during the day, direct is enough. The routes page groups 90+ countries / 220+ routes by region so you can pick by use case.

What you can optimise locally

• Wired first. Wi-Fi on the 2.4GHz band is prone to interference; if you can plug in a cable, plug it in.
• Split the two bands. When the router publishes 2.4G and 5G under one name, devices may end up on 2.4G. Give them separate names and connect to 5G manually.
• Change protocol. The same node behaves differently under different protocols against interference; if one protocol is being throttled on a particular network, another may recover.
• Stop background bandwidth hogs. System updates, cloud-drive sync and cloud backups all eat bandwidth in the background.
• Lighten the browser. Too many ad-blocking extensions and dozens of open tabs also make pages feel slow.

What 4K and long meetings need

4K streaming platforms generally recommend a stable bandwidth in the tens of Mbps — stable, not peak. Video meetings care more about latency and jitter: enough bandwidth with high jitter still stutters and drops audio. Both cases should push you towards a dedicated route rather than picking on speed-test numbers alone.

Records beat impressions

The same route can perform very differently at different times of day. Test in the morning, evening and late at night, write the results down, and then decide whether it's the route or the time of day. That record is also one of the most useful things you can put in a ticket — far more concrete than "it feels slow".

Frequent drops and mobile background disconnects

Drops come in two kinds: periodic drops on desktop, and drops on mobile after the app has been in the background for a while. The causes are completely different, so handle them separately.

Periodic drops on desktop

• System sleep. After the computer wakes from sleep the connection usually has to be rebuilt. Check whether the client has an option to reconnect after wake.
• Network adapter power management. Windows allows the adapter to be powered down to save energy by default, and once it's off the connection naturally drops. Uncheck that option in Device Manager.
• Router session timeout. With no traffic for a long time, the router reclaims session table entries. Turn on the client's keepalive or heartbeat feature.
• Wi-Fi roaming. With several access points at home, moving between them briefly interrupts the network.
• Scheduled ISP re-dial. Some broadband connections re-dial every 24 hours; if the drop happens at a fixed time, check against that.

Mobile background disconnects

Both iOS and Android reclaim network activity in the background — that's the system's power-saving policy, not a client fault. To keep the connection alive in the background, add the client to the system whitelist.

Beyond system settings there are two common cases. One is network switching: moving from Wi-Fi to cellular means the connection has to be rebuilt, and a brief interruption is normal. The other is disconnecting after the screen locks: on some models the power-saving mode restricts background networking once locked, and whitelisting the client helps.

First work out whether the client dropped or the whole device did

When a drop happens, open a site in mainland China at the same moment. If that won't load either, the whole device has a network problem and the acceleration service isn't involved; if mainland sites are fine and only proxied traffic drops, it's the client or the route. This one step halves the search space.

Don't stack proxy tools

Running two clients or two proxy tools at once for extra stability is a common mistake. They fight over the system proxy setting and the routing table, so both end up unstable, and their logs contaminate each other so you can't tell whose problem it is. Keep exactly one running at a time.

If drops follow a fixed cycle — once an hour, say — write down the exact times. A fixed cycle usually points at a scheduled task, a router policy or the ISP's behaviour, and is easier to pin down than random drops.

Subscription updates fail

A subscription URL is an address carrying a token; it determines which routes the client can pull and which exit it uses. If the link is invalid, truncated or blocked, the update fails. For the fuller explanation, see the article What a subscription link is: where to get it, how to import it, how often it updates on this site.

Start with the error type

Order of work

1. Copy again from the panel. Don't copy from a chat log, a screenshot or an old email — one missing character and it fails.
2. Delete the old subscription, then import. Clicking update sometimes doesn't overwrite a corrupted local cache.
3. Retry under a different network state. First update with the proxy off; if that fails, turn the proxy on and try again. The two cases correspond to a subscription address that needs a direct connection and one that needs the proxy.
4. Check the device clock. A time offset breaks certificate validation and looks a lot like an invalid link.
5. Check security software. Some security suites block requests to subscription addresses.

The subscription address looks roughly like this. This string is an example and won't work — copy the real link from the user panel.

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

A link is a credential

The subscription URL carries a token, and anyone who has it can pull your routes. Don't post it in public groups or screenshots, and don't paste it into the body of a ticket. If you suspect a leak, reset the subscription link in the panel: the old link stops working immediately and clients need to import the new one. After a reset, clients still holding the old link will fail on their next update, but cached routes may still show in the list — which looks like a connection that succeeds but can't reach the destination. If you see that, update the subscription first rather than blaming the node.

How often to update

Clients can update automatically; once a day is plenty. Update manually after routes change. Refreshing constantly won't make routes faster, it just adds pointless requests. If the route count drops noticeably after an update, check the account status first, then whether the client is caching old data.

Update succeeds but you still can't connect

That's a different class of problem: the subscription is fine, but the routes it returns won't connect. Go back to the four-layer check in chapter one, confirm the local network, then try another route. If every route fails while the subscription updates normally, focus on account status and local network restrictions.

One app won't use the proxy

System proxy and TUN mode cover different ground. Some apps ignore the system proxy setting, some are restricted by the system, and some implement their own network stack. That's how you end up with a browser that works fine while one particular program can't get through.

First confirm whether the app is going through the proxy

1. Check the client log. Open the connection log and look for requests from that app. If they're there, traffic is arriving and the problem is at the exit; if not, the traffic was never captured.
2. Verify with global mode. In global mode all traffic goes through the proxy. If it works then, it's a rules problem; if it still doesn't, the app itself doesn't use the proxy.
3. Verify on another device. Try the same app with the same account on a second device. If both fail, it's the route or the app; if only one fails, it's that device's settings.

Three common cases

Apps that ignore the system proxy. Some desktop software, game launchers and updaters use the low-level network interface directly and never read the system proxy setting. The fix is TUN mode, which captures all traffic.

Loopback restrictions on store apps. Such apps aren't allowed to reach the local loopback address by default, and proxy clients usually listen there. You need to grant the app a loopback exemption in the system, otherwise it keeps reporting a network error.

UDP apps. Voice, games and some video calls use UDP. If the current route doesn't support UDP, those features fail while web pages still work. Switch to a route that supports UDP, or turn off QUIC inside the app.

Browser extensions can interfere too

Some proxy-type browser extensions override the system proxy, so the browser and the system end up on different exits. The symptom is sites that load in the browser but not in desktop software, or the reverse. While troubleshooting, disable all proxy extensions and keep only the client.

Cases with strict region checks

Streaming and AI tools decide availability by exit region; if the route's region is wrong, you'll be refused even when connected. Midjourney runs inside Discord, where the long-lived connection needs to be more stable — a drop directly ruins an image generation. See the article AI image tools acceleration: a hands-on comparison of Midjourney and Discord connections on this site. ChatGPT and similar tools are even more region-sensitive: when you see an unavailable message, change region first and look at other causes afterwards.

DNS faults and resolution errors

DNS translates domain names into addresses. When resolution breaks, the network is clearly up but the domain won't open. This class of fault is the one most often mistaken for a dead node.

Three typical symptoms

• Resolution timeout. The browser spins for a long time and finally reports the site can't be reached.
• Resolves to the wrong address. The domain resolves to an unrelated address, so the page won't open or lands on a different site.
• Some domains fail to resolve. On the same network, some domains open and others don't.

Local vs remote resolution

With no proxy, DNS queries go to the local ISP. With the proxy on, if the client is configured for local resolution the queries still go to the ISP and only the result is used to build the connection; if it's configured for remote resolution, queries go to the exit node and are resolved by DNS on the exit side, so the result is closer to the destination's actual location. In cross-border scenarios remote resolution is usually more reliable, because it avoids the interference local resolution can run into.

Troubleshooting steps

1. Verify on the command line. Use nslookup www.example.com to see the result; on macOS and Linux you can also use dig www.example.com +short.
2. Compare with the proxy on and off. If it resolves to a wrong address with the proxy off and normally with it on, local resolution is being interfered with and you should switch to remote resolution.
3. Check the browser's secure DNS. A browser's built-in secure DNS skips system resolution and breaks routing rules. Turn it off while troubleshooting.
4. Check the client's DNS settings. Prefer remote resolution; if you must use local resolution, point the system DNS at a reliable public resolver.
5. Clear caches. Both the system and the browser cache DNS results, so clear them after changing settings.

nslookup www.example.com
dig www.example.com +short

# Windows
ipconfig /flushdns

# macOS
sudo dscacheutil -flushcache

The first two are queries, the last two are cache clearing. On Linux you can use resolvectl flush-caches, or restart the local resolver service.

Don't stack DNS-changing tools

Installing several tools that change DNS at once means they overwrite each other, so the setting looks applied but hasn't actually changed. Keep only one while troubleshooting, and restart the client after changing it.

If remote resolution is already on and the caches are cleared and only some domains still fail, note the failing domains and their resolution results and open a ticket with the time it happened. These problems usually relate to the resolution path of a specific domain and need confirmation from the exit side.

Account status, device count and tickets

The previous eight chapters cover connections and configuration. This one covers the account side, and how to hand the problem over once you've finished troubleshooting.

Device count is not a limit

VPNQF doesn't limit how many devices can be online at the same time. Windows, macOS, iOS, Android and Linux can all be signed in simultaneously; there's no need to upgrade a plan just to add a device. So a "device limit exceeded" message will never appear here. If you get signed out after logging in, it's more likely the same account signing in repeatedly from several places, or someone else knowing the password — change the password in the panel first.

Three account states

• Subscription expired. Monthly plans reset their data each month on the activation date; once expired, the route list goes empty or connections fail.
• Data used up. When a monthly plan's data runs out you can't keep using it that month. You can upgrade to a higher tier in the panel, with the difference prorated by the remaining days, or buy a data pack — packs last until used up and never expire.
• Password problems. Signing up needs only a username and password, with no email address required. If you forget the password, use the recovery entry point in the panel.

Monthly plans come in three tiers: ¥9.9/month for 60GB, ¥18/month for 250GB and ¥28/month for 500GB. Data packs come in three tiers: ¥158/300GB, ¥358/1000GB and ¥658/3000GB. Payment supports Alipay, WeChat and USDT. Prices and allowances are as shown on the pricing page.

When to stop and open a ticket

If any of the following applies after working through the earlier chapters, stop fiddling with it yourself.

• The problem reproduces reliably — same result on another network, another device and another route.
• The account state doesn't match reality, e.g. you've paid but it shows as not activated, or the data counters are clearly wrong.
• The subscription still won't update after the link was reset.
• The client log shows a consistent error code and none of the fixes in the table help.

What to include in the ticket

Don't attach the full subscription link, your password, or the complete order number from a payment screenshot. To identify an order, the order time and amount are enough.

Refunds and next steps

VPNQF offers a 60-day no-questions-asked refund. You can apply within 60 days of your first payment; just include the order details in the ticket. After submitting, it helps to freeze the current state and stop changing settings, so support can reproduce it in the same environment. And if the problem turns out to be your local network, the record you left in the ticket helps the next person who runs into it.