VPNQN Troubleshooting

Connection

Can't Connect: Find Where It Fails

Here, “can't connect” means the client never reaches a connected state, or displays an error as soon as you tap Connect. This is different from being connected but unable to load websites. Start by checking the client: does the route list appear normally? After selecting a route, does it keep waiting, show an error right away, or briefly connect before disconnecting? Note these details to guide the checks that follow. Don't start by reinstalling the client. If the problem is caused by your local network, subscription status, or an old configuration, reinstalling usually won't help and may erase settings you could use for comparison.

Check your network and account first

Disconnect VPNQN temporarily and use a browser to open a website that normally works without it. If your internet connection itself is down, troubleshoot your current Wi-Fi, wired network, or system connectivity first. The client also needs a working internet connection to connect. If websites load, open the Service Dashboard to check your subscription and traffic, and confirm that the client is using the account you intend to use. An old route name in the client doesn't prove that your subscription is still active: the local list may have been saved earlier.

Next, update the subscription manually in the client. Once the update completes, reopen the route list. If the update itself fails, go to the Subscription Updates section of this guide instead of using an old list to judge whether every route is available. If the list has refreshed, try connecting to an available route in a different region from your current one. Change only the route, not other settings at the same time. If another route connects, the problem is more likely with the original route or the path to it. If all routes behave the same way, check your device and local network next.

Test on a different network

If possible, connect the same device to another available network, then test the same account and route. This helps distinguish between a route that fails on every network and one that fails only on your current network. Public and office networks, as well as networks with a sign-in page, may require you to complete a local access step in a browser first. Until you do, other apps may also time out. If switching networks fixes the issue, check whether the original network requires sign-in, uses a local proxy or gateway policy, or has system network settings that could affect the connection. There's no need to change your VPNQN subscription right away.

If other network proxies, system-wide tunnels, or security software with network filtering are enabled on the device, note their current settings, then temporarily disable conflicting tools and test one at a time. When multiple tools compete for the system's network access, the client may fail to establish a tunnel or disconnect soon after connecting. Restore the original settings after testing as needed. Don't disable management settings on a work device without permission; share your test results with your network administrator instead.

When to stop troubleshooting locally

If your internet connection works, your subscription is active, the route list refreshes, and changing both the network and route doesn't help, there's no need to keep changing protocols and system settings at random. Keep the exact error message, time of the issue, platform, selected region, and route type, then submit a support ticket using the checklist at the end of this guide. If only routes in one region fail, specify the region and a route that works for comparison. If all routes fail, list the local conditions you've already ruled out. This helps support determine whether the issue is related to your account, configuration, network path, or the route itself.

Website access

Connected but Websites Won't Load? Check DNS and Routing

“Connected” only means the client reports that it has established a tunnel. It doesn't mean every browser request is taking the expected path. First define the scope: do no websites load, or only a particular site? Does the same site behave differently in another browser? Can you refresh an open page, and can you open a newly entered URL? If only one site fails, consider its regional rules, account requirements, or a temporary outage before assuming the route is at fault.

Tell DNS lookup issues from connection issues

DNS translates domain names into addresses your device can reach. A DNS problem often makes the browser report that it can't find a server or resolve a domain. A connection problem may result in a long wait or a reset connection. Keep the exact error message instead of just writing “the website is broken.” Then try another site that normally works and compare the results. If several domains won't resolve, check system DNS, the client's DNS settings, and whether the current network forces the use of its own DNS service. If domains resolve but pages still time out, check routing, split tunneling, and the route path.

You can use a system command line to look up a public domain and see whether your device gets a DNS result. This is for troubleshooting only; you don't need to include account details in a support ticket. On Windows, run nslookup example.com. The same command also works on macOS and Linux. A successful result doesn't guarantee that the website will load; it only confirms that this particular DNS lookup returned a result. If the command times out, first check whether DNS works on your current network with the client disconnected, then compare the result after connecting. The difference can help show when the DNS settings change.

nslookup example.com

Before changing DNS, note whether your system is set to obtain it automatically or use a manual address. A browser's secure DNS, system Private DNS, or DNS settings provided by another app may use a different resolution path from the client. Change only one setting temporarily and test again; don't change DNS in the browser, system, and client all at once. If your device is managed by your employer, follow its policies rather than overriding organization settings. For more ways to check your exit IP and DNS results, see the guide to checking your exit IP, DNS, and per-app routing.

Check routing rules and site-specific requirements

If DNS works, check whether the client is in global proxy mode or split-tunneling mode. A routing rule may send the site or one of its dependent requests through a direct connection, so the homepage loads but login, images, or video don't. Note your original settings before switching modes, then test the same site on the same route. If global mode works but split tunneling doesn't, check the rules for that site's traffic rather than switching every route. Browser extensions, system proxies, and client rules can each determine how requests are routed. Check them layer by layer to avoid multiple proxy settings overriding one another.

If only one platform refuses access, first check whether the selected route region matches the region of your platform account. Some services also apply rules based on content rights, sign-in status, or their own policies. Choosing a VPNQN route doesn't replace a platform membership or guarantee that every page is available in every region. See the Streaming guide for common regional checks. If multiple sites fail, compare another route and network. If only one site is affected, include its name, the browser message, and your test results in the support ticket. Don't include your login credentials.

Performance

Slow Speeds and Peak-Hour Lag: Check Each Part of the Connection

Slow page loads, video buffering, and slow file transfers can have different causes. First check whether the issue only happens when connected to VPNQN: disconnect without changing anything else, visit the same type of content on the same device, then reconnect and test again. The goal is to see whether the symptoms change with the connection status, not to judge a route based on one speed test. Other downloads at home, background syncing, or fluctuating Wi-Fi signal can also slow any cross-border connection.

Choose a route by region, purpose, and network path

Start with a route in the region required by your target service, then compare route types within that region. Requests that cross more regions usually take a more complex network path, but distance isn't the only factor: the connection between your network and the route also matters. VPNQN offers IEPL dedicated routes, relayed routes, and direct routes. The right choice depends on what you're doing and your current network. The Routes page explains the different types and regions. Keep the target app constant and test routes one by one, noting which performs better with the same content.

IEPL dedicated routes use specific cross-border paths. Relayed routes pass through an intermediate path and may improve connectivity from some networks to a destination region. Direct routes are more direct, but performance still depends on your local network and the service you're accessing. These aren't ranked from best to worst, and there isn't one route that's always fastest for everyone. For region-specific content, choose the right region first and compare playback. For AI tools, check sign-in, response delivery, and whether longer sessions stay connected—not just how quickly the homepage loads.

How to test during peak hours

If slowdowns happen only during busy evening hours, note the network type, route region, route type, and affected app. Then test another route in the same region, keeping the device, network, and app as consistent as possible. If routes in the same region perform similarly, consider whether another region meets the service's requirements. Don't change routes while also clearing app data or changing DNS; otherwise, you won't know what helped. For video buffering, check whether it affects only one title or platform. Changes to the platform's content delivery path can cause isolated issues.

If your Wi-Fi signal is unstable, move closer to the access point or compare results using a stable wired connection. If your internet connection fluctuates even when disconnected from VPNQN, troubleshoot the local network first. Pause large browser downloads, cloud syncing, or other devices using the connection before testing again; the results will be easier to interpret. To check whether the client itself is working properly, see if your system restricts its background network activity. A restriction can sometimes look like slow speeds when the connection is actually being repeatedly re-established.

If the same symptoms persist across multiple routes and websites on the same device and network, send your comparison results to support. Specify whether pages load slowly at first, transfers remain slow, or video starts buffering after playback begins; each points to a different area to check. VPNQN covers 110+ countries and has 230+ routes, but the number of available options doesn't replace testing them on your current network. For occasional slowdowns, note the circumstances when they happen. There's no need to keep reinstalling the client.

Connection stability

Frequent Disconnects and Mobile Background Dropouts

For frequent disconnects, first determine whether the network connection drops, the client stops running, or only the target app loses its session. Check whether the client changes from connected to disconnected. If it still shows connected but a website asks you to sign in again, the issue may be with the site's session or the app itself, not the route. Note whether the device switched Wi-Fi networks, entered standby, locked, or moved between areas with different network coverage when the disconnect happened. These triggers are more useful than simply saying it “disconnects a lot.”

Keep network conditions consistent while testing

Keep the device on one network and use the same route while troubleshooting. If the disconnects stop, check how the system handles the connection when the network changes. If they continue on a fixed network, compare another route in the same region. Don't run multiple clients that manage system proxies or network tunnels at the same time. An old client process that hasn't fully closed may still control network settings; make sure only the client you intend to use is managing the connection.

Some devices use power-saving features to limit idle apps. If disconnects happen only after you lock the screen and the connection returns when you reopen the app, check the system's background activity, battery optimization, and network settings for the VPNQN client. Allow the necessary background activity, reconnect, and test again with the screen locked. Menu names vary across operating systems. If you can't find the relevant setting, open the client's app information page in system settings. Don't disable all system protections for troubleshooting; adjust only the settings for this client and note the results.

Compare iOS, Android, and desktop behavior

On desktop, the network adapter may reconnect after the computer wakes from sleep. If the client still shows connected but pages won't load, disconnect and reconnect to see whether that helps. On mobile, the system may need time to switch paths when moving between Wi-Fi and another network. If only an app stops playing or syncing when sent to the background while the client remains connected, check that app's background permissions. Don't confuse this with the VPNQN client disconnecting.

Keep retest notes brief but specific: platform, client status before and after locking or sleep, whether the network changed, whether you had to reconnect manually, and whether a different route helped. If disconnects continue on a stable network after you've ruled out background restrictions and network switching, submit a support ticket. Include the error message shown in the client or relevant excerpts from its diagnostic log. Review the contents before sending, and don't upload passwords, full subscription URLs, or other sensitive information. For help checking an initial mobile setup, see the iPhone setup guide.

Configuration

Subscription Update Failed: Check Retrieval, Import, and Refresh Separately

“Subscription update failed” could mean the service dashboard won't open, the client can't retrieve the subscription, no routes appear after import, or the old routes aren't refreshing. First identify which step failed instead of treating these as one issue. The dashboard manages your account, while the client imports routes. Seeing your plan in the dashboard doesn't mean the client has retrieved the latest configuration. Conversely, seeing old routes in the client doesn't prove that the dashboard can't provide an update.

Check your dashboard and import source

Open the Service Dashboard and check the account you're using, subscription status, and traffic. VPNQN monthly plans include ¥9.9/month with 60GB, ¥18/month with 250GB, and ¥28/month with 500GB. Traffic resets monthly on the activation date. Data packages are ¥158/300GB, ¥358/1000GB, and ¥658/3000GB; they remain valid until used and never expire. If your account status doesn't match what you expect, check the plan and order in the dashboard instead of repeatedly importing the same local configuration. For mid-cycle upgrades, the price difference is converted into the remaining subscription days, so check the actual status shown in the dashboard.

To retrieve the subscription again, use the option provided in the dashboard. Don't use an old page from your browser history or a configuration file saved earlier. If the client can update an existing subscription, make sure you've selected the VPNQN subscription before refreshing. If you've imported several similar configurations, check which one the current connection is using. To avoid mixing up duplicate configurations with the same name, note the original configuration, remove duplicates you no longer use, and import again from the dashboard. Don't post your full subscription URL in a public discussion or in a support ticket; it provides access to your account.

Continue based on where the error occurs

If the dashboard itself won't open, test your internet connection and other websites first, and make sure you're using the official dashboard entry point. If the dashboard works but the client times out while updating, check whether the issue also occurs on another network. Also check that your system clock is correct and that local network filtering isn't blocking the client. If you see a format error or the list is empty after import, note the exact error and client platform. Confirm that you're using an import method supported by the dashboard, rather than trying to import a format through an incompatible option.

After an update, check that the client has actually switched to the new configuration. Some clients keep both old and new configurations. The route list may look the same even though the connection is still using an old entry. Compare the list before and after updating, the selected subscription name in the client, and the dashboard status. If the update reports success but the connection still has problems, return to the Connection section of this guide. A successful refresh confirms only that the configuration was retrieved; it doesn't guarantee that the network path from your device to the route is working.

If the update still fails on another network, and you've confirmed the dashboard status and import method, submit a ticket with your platform, the client name shown in the app, the step that failed, and the error message. If there's no clear error, describe what happens after you tap Update: does it keep waiting, finish immediately, report success without showing routes, or show routes that won't connect? Support needs steps they can reproduce, not your account password. For the full initial import process, see Quick Start.

App routing

One App Doesn't Use the Proxy? Check Routing Rules

If your browser works but a particular app still uses your regular network, don't assume the route is slow. Whether an app uses the client depends on system proxy settings, the client's operating mode, and routing rules. The app's own connection method may also matter. First choose a browser page you've confirmed works for comparison, then test a specific action in the app: does the home screen fail, does sign-in fail, or are only playback or uploads affected? Different features in the same app may use different domains or network requests. The more specific the symptom, the easier it is to find a missing rule.

Temporarily compare with global mode

Note the current route and mode, then temporarily switch from split tunneling to global proxy mode without changing the app or network. If the app works in global mode but not split tunneling, check whether the routing rules cover the app and its dependent services. That doesn't mean the route is unusable. Switch back to your original mode after testing. If the app also fails in global mode, try another route in the same region to see whether the issue relates to the exit region or the service's own access rules.

Some desktop apps use system proxy settings, others have their own network entry point, and some connections don't go through a standard browser proxy. Don't assume every program uses the same path just because your browser's exit IP has changed. Check whether the client supports app-level routing or a system-wide connection mode, and confirm that the target app is covered by the rules. Windows, macOS, and Linux handle system proxies and permissions differently. If your organization manages the app, check with your administrator before changing managed network settings.

Check region, sign-in status, and cache

If the app connects but says content isn't available in your region, check whether the route region matches your account region and the service provider's rules. Streaming platforms may license content separately, so the homepage, a particular title, and playback requests may not all be checked the same way. For AI tools, distinguish between sign-in problems and issues with longer sessions. A failed sign-in doesn't necessarily mean the route disconnected; it may be related to the service's account requirements or session status. VPNQN provides a network connection path but doesn't determine account eligibility or which content a third-party service makes available.

After changing routes, the app may retain an earlier connection or page state. Fully close and reopen the target app, then test the same action again. If needed, compare with a new browser window. Before clearing app data, make sure you can sign in again; clearing it may remove your local session and preferences. Don't clear every cache at the start of troubleshooting, or you may lose useful before-and-after clues. If the app displays a network error, record the exact wording. If there is no error, describe what you tapped and which screen it gets stuck on.

To independently verify the exit path used by different apps, read the per-app connection test guide. If the issue persists after changing modes, restarting the app, and comparing routes in the same region, include the app name, affected feature, current mode, and an app that works for comparison in your support ticket. Don't include third-party service login details. Support can use these clues to determine whether the issue is related to routing configuration, the network path, or the third-party service's region and account rules.

Account

Device Prompts and Plan Status: Check Your Account First

If you see a device limit, account status, or configuration error on a new device, save the exact message instead of relying on its heading. VPNQN doesn't limit the number of devices connected at the same time. If an error mentions a device count, first check whether the client is signed in to the correct account, whether the subscription is active, and whether the message comes from the VPNQN dashboard, the client, or another app. Messages from different sources need different fixes; a third-party app's limit isn't necessarily a VPNQN plan rule.

Check the signed-in account and subscription

On the device with the issue, open the Service Dashboard and confirm that the username matches the subscription you're using. VPNQN doesn't require an email address to register; you can use a username and password. If you use more than one username, check especially that the new device is signed in to the same account. Don't share your password or paste it into a support ticket. If the dashboard and client show different accounts, sign out of the wrong one, then follow Quick Start to import a configuration from the correct account.

Monthly subscription traffic resets each month on the activation date, not on a single calendar date for everyone. If the traffic shown doesn't match your expectations, check the activation date and current plan first. Don't estimate usage based on the number of devices. Data packages remain valid until used and never expire, unlike the monthly subscription reset. For mid-cycle upgrades, the price difference is converted into the remaining subscription days. The current plan and status shown in your account are more reliable than an old screenshot. See the Plans page for details; use the dashboard to confirm orders and actual status.

Tell an old local configuration from an account issue

If a new device can access the dashboard but can't use routes, check whether you've imported the current account's subscription and selected the configuration you just imported. An old device that still connects while a new one reports an error doesn't, by itself, prove there's a device limit. The old device may be using a saved configuration, while the new device encountered an import or permission issue. Follow the checks in this guide's Subscription Updates section to verify the dashboard, configuration retrieval, route list, and connection separately.

If the prompt appears while the operating system is adding a network configuration, check whether you've allowed the client to create the required system connection and whether another network tool is using the relevant settings. If the prompt appears in a third-party client, note the full message and where it appears. Some generic error names have no direct connection to VPNQN's plan rules. Don't repeatedly delete every device configuration just to “make room.” Since there is no device limit, this won't confirm the cause and will create extra work when you import configurations again.

If the prompt persists after checking your account, retrieving the configuration again, and comparing devices, submit a ticket. Include the platform, the client screen where the prompt appears, your current dashboard status, and whether another device works. You can hide personal details such as your username in screenshots, leaving only the part that shows the error. For payment or refund questions, VPNQN supports Alipay / WeChat Pay / USDT and offers a 60-day no-questions-asked refund. Check the transaction status against the order in your dashboard and support ticket. Don't upload an unredacted payment receipt to a public page.

Get help

When to Submit a Ticket and What to Include

The goal of troubleshooting isn't to make you solve every problem on your own. It's to narrow down the issue enough for support to investigate. If your internet works, you've checked the subscription status, and the same issue persists after changing routes and networks, submit a ticket. It's also worth reporting a route that keeps failing, a clear subscription update error, or a device prompt that conflicts with the no-device-limit policy. You don't need to test every system setting. A consistent way to reproduce the issue is more useful than hours of random changes.

Describe the symptoms first, then the comparison results

Submit your issue through the support ticket section of the Service Dashboard. Start with what you can observe, such as “The client says connected, but several domains won't resolve in my browser” or “On the same Wi-Fi, the client disconnects after I lock the screen.” Then give your platform—Windows, macOS, iOS, Android, or Linux—the affected app, route region and type, and the exact error message. Don't just write “it doesn't work”; that could refer to connection, DNS, subscription, or app routing issues.

Next, list the comparisons you've already made: does your internet work with the client disconnected? Can the subscription list refresh? Can another route in the same region connect? Does the issue change on another network? Do global proxy and split-tunneling modes behave differently? Don't invent tests you haven't run; just say “not tested.” If the problem happens only during peak hours, specify the network type and app behavior. For occasional disconnects, note whether locking the screen, waking the device, or switching networks triggers them. This helps support avoid asking you to repeat checks you've already done.

What to include—and what not to send

You can attach a screenshot showing the exact error, relevant diagnostic details exported from the client, and steps to reproduce the issue. Before taking a screenshot, check the notification bar, account page, and browser address bar, and hide unrelated private information. Don't send your account password, full subscription URL, payment account details, or third-party service credentials. Support doesn't need them to troubleshoot routes or configuration. If you need to discuss an order, use the order information in the dashboard and provide only what's requested in the ticket. Don't post payment credentials in public comments.

After submitting your ticket, keep the recorded configuration unchanged where possible so you can retest based on the response. If you need to keep working and switch to another route that works, say which route you're using temporarily and which one had the original problem. Once the issue is resolved, you can also report whether it was fixed by updating the subscription, changing routing rules, or switching networks. This helps confirm the cause, not just that the symptoms disappeared. For account, plan, or refund questions, focus on differences between what's shown in the dashboard and the actual order instead of following network troubleshooting steps.

If you haven't connected yet, return to Quick Start to check the import process. For available regions and route types, see the Routes page. For pricing and traffic rules, see the Plans page. This guide helps diagnose issues; your account's actual status is shown in the dashboard. Recording symptoms, comparisons, and results separately can reduce repeated troubleshooting and give support clear evidence to work with.