Can't connect at all: establish a troubleshooting baseline
If you can't connect at all, first determine whether the client won't start, the configuration won't import, the connection fails during setup, or traffic stops after connecting. These occur at different stages and need different fixes. Note the exact on-screen message and what you were doing: does it fail as soon as you click Connect, or time out after waiting? Does it happen on every route or only the one selected? Save the message before changing settings so you don't lose the original evidence.
Make sure your basic internet connection works on its own
Disconnect the client and try a website you can normally access without a proxy. If that fails too, complete any network sign-in, check your Wi-Fi connection or restore local connectivity first. Hotel, public and guest networks may require you to confirm access in a browser. Even if the client says it's running, it can't authenticate your underlying network for you. Don't keep switching subscriptions or reinstalling the client before your local connection is back.
Once your basic connection works, check that your system clock is set to update automatically. Certificate checks and connection authentication rely on the correct time, and a significant mismatch can cause a handshake to fail. Then make sure the client has loaded a valid configuration rather than an empty, sample or removed one. Open the route selector and check for available entries. If you see a subscription name but no routes, go to the subscription update section.
Narrow down the issue with cross-checks
Stay on the same network and select another route, then repeat the same test. If the other route works, the issue is more likely with the original route or its path to the destination service. If all routes fail, keep the client configuration unchanged and try another available network. Disconnect before switching networks, wait until the new connection is stable, then reconnect. This avoids mistaking a brief handover interruption for an ongoing problem.
If another device on the same network connects successfully, focus first on the affected device's permissions, proxy settings and other network software. If every device fails on that network but works on another, focus on the network environment. Cross-checks aren't about proving who's at fault; they're a way to isolate variables. Change just one thing at a time—network, route or device—so you can compare results.
Check permissions and overlapping network controls
On first launch, your system may ask permission to create a VPN configuration, enable a network extension or authorize a virtual network adapter. If you denied the prompt, check your system settings instead of repeatedly clicking Connect. The setting may have a different name on each platform; follow the client prompt and your system's documentation. If your work device is managed by an organization, don't remove management policies yourself. Check whether the required network component is allowed first.
Running another VPN, proxy tool or security app that controls network traffic at the same time can cause routing conflicts. Disconnect through each app's own interface, then check the current client. Don't delete system services you don't recognize. If disconnecting a particular tool fixes the issue, note its name and mode before deciding how to configure the tools together. Turning off all security protections is not a routine fix and should never be a long-term requirement.
Submit a support ticket if you've confirmed that your basic connection works, your account is active and your configuration contains routes, but the failure still reproduces across different routes and networks. Include your platform, where you got the client, the exact error, the stage where it fails and the results of your cross-checks. If only one route is affected, name its region and display name. Don't include your full subscription URL or account password.
Connected but websites won't load: access & DNS
Being connected while websites won't load doesn't necessarily mean the route is unusable. First determine whether all sites fail, only international sites fail or just one domain is affected. DNS lookup errors, connection timeouts, certificate warnings and access-denied messages point to different causes. Record the exact message and the domain; “doesn't load” alone isn't enough. The domain is usually sufficient for initial troubleshooting, so there's no need to share a full URL that may contain personal information.
Separate browser issues from network issues
Keep the current connection and try the same domain in another browser. If it works there, check the original browser's extensions, independent proxy and secure DNS settings. A private window can help rule out some cache and extension issues, but it doesn't necessarily disable every extension, so check which ones are active. If all browsers fail, test whether other apps can connect to see if the issue goes beyond the browser.
If a page shows text but images, the sign-in window or video area stays blank, supporting domains may be using a different route. Don't assume the configuration is correct just because the home page loads. Check the client connection log for the domains behind failed requests and compare their rules with the main site. A third-party content outage can look similar, too. Compare another route before expanding proxy coverage for all apps.
What a DNS check can—and can't—tell you
DNS resolves domain names to addresses that can be reached. A successful lookup doesn't mean the destination port is reachable, and a failed lookup doesn't necessarily mean the route is down. Browsers, operating systems and clients may each use separate caches and DNS settings, so a successful command-line lookup alongside a browser failure isn't contradictory. Note which environment produced the result. Check the client's recommended defaults first, and avoid combining incompatible DNS setups.
nslookup example.comThe command above shows the basic response from your system's current DNS resolution path. Check whether it returns a result, times out and which resolver it uses. An address differing from an online screenshot doesn't automatically mean something is wrong; a destination may return different addresses based on the access region. Command output may contain local network details, so review and redact anything unrelated before sharing it. Don't upload your entire terminal history.
| Symptom | Check first | Doesn't necessarily mean |
|---|---|---|
| Name resolution failed | DNS path, cache and browser settings | All routes are down |
| Connection keeps timing out | Routing, destination reachability and network changes | Your account is inactive |
| Certificate validation error | System clock, network authentication and domain name | You should ignore the certificate warning |
| The website denied access | Destination service policy and account status | The network connection wasn't established |
Retest the full request after making a change
If you manually changed DNS, note the original settings, then restore the recommended setup in the client instructions. Don't enter a public DNS address at random: some connection modes need DNS requests to go through the tunnel, while others use the system resolver. Clearing the cache only removes old results; it won't fix a misconfigured path. After making a change, close and reopen the affected app, then revisit the same domain to confirm whether anything changed.
For a certificate error, check your system clock and the domain, and make sure your basic network isn't waiting on a sign-in page. Don't bypass certificate warnings, install certificates from unknown sources or disable validation just to load a page. If the issue happens only on a work network, ask your network administrator. If DNS fails only on one route, keep the route name and error message, along with the result from another working route, so support can investigate.
Use the IP check page to see the browser's apparent exit location, but remember it only reflects the path used by that browser request. It can't prove that every app uses the same exit. Don't rely on a DNS region label alone; consider the actual rules, the client's DNS mode and whether the request completed. If the page works but an app still fails, continue to the app routing section rather than repeatedly changing DNS settings that are already working.
Slow speeds and peak-hour slowdowns
Start by defining what “slow” means for the task. A delayed first page load, a slow file download, video buffering and choppy calls place different demands on a connection. Slow page loads may be due to DNS or connection setup; download speeds may be limited by the source server; video buffering can also depend on playback quality and the app. Note the action that's actually affected before deciding what to compare. A single speed test doesn't describe every use case.
Keep test conditions consistent when comparing routes
Check whether a system update, cloud sync, game download or another device is using your local network. Pause background tasks you can control, and keep the test device and connection method the same. Weak Wi-Fi, power-saving settings and a busy router can all cause fluctuations. If ordinary websites are unstable on your basic connection, fix the local conditions first instead of repeatedly switching international routes and hoping for a better result.
Test the same destination with the same action on your current route and another one. After switching, reopen the destination connection so the app doesn't reuse an old session. Note whether the task completed, where the delay occurred and whether it kept disconnecting. Don't change the device, network, browser and route all at once; even if the issue goes away, you won't know which change helped.
Look for reproducible conditions during peak hours
If things work during the day but slow down in the evening, possible factors include local network congestion, changes in shared network use, cross-border routing or a busy destination service. A time-of-day pattern is a clue, not proof of the cause. Keep the device and task the same, compare results at different times and also test your basic connection without a proxy. If that slows down too, the selected route can't account for all the change.
A route in a nearby region isn't necessarily shorter in practice. Exit region affects how a service identifies your connection; route type and access path affect how data travels. Consider them separately. See the route selection guide on the Routes page, then judge by how your target app actually performs. IEPL dedicated lines, relayed routes and direct connections describe path types, not a universal speed guarantee across every network, time and website.
Choose practical adjustments for each app
For video, first confirm that the platform is available, then lower playback quality to see whether buffering stops. If playback stabilizes, the connection may not meet current streaming demands, but you'll still need to distinguish between local access, the route and the content source. For file downloads, compare with another trusted source. If only the original source is slow, its server may be limiting delivery; that doesn't mean all downloads will be affected.
For interactive apps, focus on whether the connection stays up. Long waits with AI tools, delayed chat messages and failed web uploads may be caused by interrupted sessions rather than low throughput alone. Keep the exit region fixed during a task to avoid switching routes mid-session. For a method to organize test records, see How to Compare Successful Connections and Disconnects and gather results that can be reproduced.
If the client offers auto-select or automatic switching, check whether it's enabled. Its decisions may be based on a probe that doesn't target the service you're using. For troubleshooting, temporarily pin a route, then restore your original setting when you're done. Don't infer route priority from the order of regions on screen, and avoid repeatedly reconnecting in a way that interrupts an active task.
If the slowdown keeps reproducing at the same time on the same route, while your local network test remains normal, submit the time, access type, destination domain, action and comparison route results. Don't claim an entire region is unavailable; describe exactly what you tested. This gives support useful evidence to assess the route instead of guessing at your setup based on “it's slow.”
Frequent disconnects and mobile background dropouts
First distinguish between the tunnel disconnecting, a session expiring in the destination app and a change to the system icon. An app asking you to sign in again doesn't necessarily mean the VPN disconnected; a VPN icon still showing doesn't guarantee that the original session is alive. Check whether the client logged a reconnect, whether the system switched networks and whether the issue appears consistently after locking the screen. Put these events in order—it's usually more useful than a single screenshot of a disconnect.
What to check when foreground use works but background use fails
If the app works in the foreground but fails after you lock the screen or switch apps, check battery optimization, background activity and how the system manages network extensions. Android devices may restrict background apps, and settings vary by device. Follow your system's instructions to allow the necessary background activity. Don't grant permissions unrelated to connectivity or install unknown keep-alive tools.
iOS VPN configurations are managed by the system, so Android background app settings don't apply. First make sure the system still has the configuration you're using, and check for VPN configurations or auto-connect rules created by other apps. If the client starts but the system tunnel repeatedly stops, note when the screen locks, the network changes and the connection is restored. Avoid repeatedly deleting configurations, which can make the original issue harder to reproduce.
Check network changes and recovery from sleep
Switching from Wi-Fi to mobile data, moving out of Wi-Fi range or waking a device from sleep all change the connection conditions. An app may keep waiting on a stale connection even after the client reconnects, and may not rebuild the session automatically. First confirm the new network works, then reconnect the client, and finally reopen the affected app. This helps distinguish a network recovery issue from an app that failed to resume.
Desktop devices can also run into network interface changes after sleep. If Windows, macOS or Linux loses connectivity on wake, check the system's basic connection first, then reconnect the client. Don't keep starting multiple connection processes before the network interface is back. If you use a dock or switch between wired and wireless, note exactly what changed; it may help identify interface priority issues or stale routes.
| Platform | What to check | Verify after recovery |
|---|---|---|
| Android | Background restrictions, power saving and network changes | Repeat the same request before and after locking the screen |
| iOS | System VPN configuration and auto-connect rules | Check system status and app requests separately |
| Windows / macOS | Recovery from sleep, interface changes and overlapping proxies | Check basic connectivity before reconnecting |
| Linux | Network management services, routes and process status | Distinguish a running service from actual reachability |
What if only one route disconnects?
Keep the device, network and app the same, pin another route and run the same task. If the other route stays stable, note the original route name and time of the disconnect. If every route drops during the same action, focus on the local system and access network. Don't label an app ending playback, an expired login or a destination service closing a persistent connection as a route dropout by default. Check whether the client itself logged a reconnect at the same time.
If the client offers keep-alive or auto-reconnect settings, read its documentation and start with the recommended defaults. Keep-alive may preserve some connection states, but it can't restore a lost basic connection or prevent the system from stopping a background process. Shortening the interval at random may increase battery use and background activity; it's not a universal fix. If a change helps, note it and keep the original value so you can restore it.
Before upgrading or reinstalling, make sure you can retrieve your configuration from the dashboard and save any necessary non-sensitive settings. Windows, macOS, Android and Linux clients fetch it after you sign in; follow the dashboard's instructions for iOS. Don't look for unofficial “special repair” builds on unknown mirrors. If the issue appeared alongside a local update, note what changed in your support ticket without assuming the update was the root cause.
Subscription update failures and configuration issues
Subscription updates and route connections are separate requests. A route in an old configuration may still connect while the update endpoint temporarily can't retrieve new content. Or the subscription may update successfully without affecting the currently selected configuration. First identify whether the failure happens while accessing the dashboard, copying, importing or updating, then record the client's message. Never paste your full subscription URL into a public forum or third-party checker while troubleshooting.
Verify the source and active configuration
Open the subscription section from the user dashboard and make sure you're signed in to the intended account. A subscription URL may contain access credentials, so treat it as sensitive information. If you've shared it or uploaded it publicly, use the dashboard's management options and contact support about next steps. Don't assume that changing your password will invalidate subscription credentials; check how the dashboard actually handles them.
The client may retain multiple configurations with similar names. Check which one is active, the last update result and the actual route list so you don't keep updating an unused copy. A successful import usually means only that the client accepted the input; it doesn't guarantee the content is complete or that the active configuration changed. If the list is empty, parsing fails or entry names look wrong, note where and how the error occurred instead of deleting every old configuration immediately.
Tell a retrieval failure from a format error
A connection timeout is more likely to point to an issue retrieving the content; a parsing error means the client couldn't interpret the response as expected. The response could also be a sign-in page, error page or network authentication page—not an actual subscription file. Don't overwrite your existing configuration with unknown content. Return to the dashboard, select an import method supported by your client and make sure the basic network isn't waiting for public network authentication.
Extra spaces, line breaks, truncation or missing characters can break an address when copying it. Use the dashboard's copy or import function where possible, and don't edit address parameters by hand. The address below is for illustrating the format only; it is not a usable VPNQP subscription. Never expose a real address in screenshots, shared documents, terminal command history or configuration files synced to a public repository.
https://example.com/sub?token=YOUR_TOKENCheck which path the update request uses
Some clients let you choose how subscription updates connect to the internet, separately from the routing rules for regular traffic. If the current proxy is no longer working and updates depend on it, you can end up unable to recover through the client. Check the documentation to see whether updates can use your normal connection. Don't switch all request modes at random, or you may disrupt business traffic that was working.
If the dashboard opens in your browser but the client keeps failing to update, check the client's retrieval method, system proxy and response format. Being able to sign in through a browser doesn't guarantee the copied address is complete. If switching networks fixes it, note what differed. If only one client fails, check where you got it and which import formats it supports. Don't combine or force-convert configurations from other clients.
Check subscription validity and monthly plan data in the dashboard. Monthly plan data resets each month on the activation date; data packs remain available until used and never expire. Don't assume that data has reset just because a new calendar month has started, or mistake a delay in refreshed plan details for a client import failure. For billing details, see the Plans page. If the account status looks wrong, follow the account troubleshooting section.
When you submit a support ticket, say whether the issue is a timeout, access denial, parsing failure or an empty list, and include when it happened and which client you use. Keep screenshots focused on status, configuration name and error, and redact the full address and credentials. If support needs more information, send it through a ticket after signing in; don't send the raw subscription file upfront. New users can review the main steps in the subscription import guide.
An app won't use the proxy: check routing
If your browser works but one app doesn't, check whether that app is actually using the expected route. It may ignore system proxy settings, use its own network configuration or send requests through a background component. First compare the same destination in a browser, then check whether the client sees connections from the app. A working web page is a useful comparison, but it doesn't mean desktop apps, embedded browsers and background processes all share the same network path.
Identify the traffic interception mode in use
System proxy settings generally apply to apps that read those settings. Tunnel-based modes may capture more traffic but require the relevant system permissions. The exact behavior depends on the client and active configuration, so don't infer the scope from a button label alone. Check the client's documentation to see what the selected mode covers. A mode that hasn't been authorized may appear selected without actually taking effect at the system level.
Rule mode chooses a route based on domains, addresses or other conditions. An app's main site, authentication, resources and upload endpoints may match different rules. Reproduce the failed action first, then check the relevant connection records. Searching only for the app name may miss domains used by background requests. If you need to add a rule, identify the type of request that failed first; don't replace your entire configuration with rules from an unknown source.
Use a temporary comparison, not a permanent expansion
If your client supports a broader proxy mode, you can test it temporarily after understanding the impact and saving the original settings. Quit the affected app before switching modes, then restart it so it doesn't reuse an old connection. If the temporary mode works but rule mode doesn't, focus on routing rules. If it still fails, also check the destination service's account, regional policies, app status and protocol compatibility.
Restore the original mode after your comparison. Broader traffic interception can change access to local networks, company resources and other apps, so “proxy everything” isn't a long-term fix for every issue. Follow your organization's network policies on work devices. If you need access to both a company intranet and international services, check whether the client supports a suitable split-routing setup. Don't bypass management settings.
| What you observe | Next step | Keep in mind |
|---|---|---|
| The client has no connection records for the app | Check the traffic interception mode and app-specific settings | Connection logging itself may not be enabled |
| The main site works, but authentication fails | Check the authentication domain's rules and exit route | Don't share your login credentials |
| The issue changes after switching modes | Find the missing rule, then restore the original mode | A temporary comparison isn't a long-term conclusion |
| Traffic is routed through the proxy but access is denied | Check the service's region and account requirements | Network reachability doesn't mean the service authorizes access |
Check persistent connections and sign-in status separately
AI tools, chat and image generation apps may depend on persistent connections. The home page may load while message submissions, generation tasks and uploads use different requests. Keep the exit region fixed for the entire task and avoid switching routes during authentication or generation. See the AI Tools access guide and Midjourney and Discord connection tips.
Streaming apps are also affected by account region, content licensing, device status and the provider's policies. If you see a region-unavailable message, first determine whether the network request failed or the service returned an explicit region notice. VPNQP route coverage doesn't mean every title will always be available. For more on these limitations, see the Streaming access guide; the destination service's response at the time is what matters.
Command-line tools may read proxy environment variables, while graphical apps use system settings. If only a command-line tool fails, check its official proxy options. Avoid putting proxy addresses and credentials in shared scripts. Don't copy a local listening port from someone else's screenshot or expose your local proxy to an untrusted network. App-specific settings should match how the client actually listens for connections.
If connection records show that requests followed the expected route but the app still reports an error, save the destination domain, exact message, task stage and selected region. This helps support assess route reachability, but you'll generally need to ask the destination service about account restrictions or authorization. Describe exactly what failed instead of saying “this app isn't supported.”
Account, data and device alerts
If you see a device limit, invalid subscription or insufficient data message, first check where it came from. It may be from the VPNQP dashboard, the active client, a different account configuration or the destination app. VPNQP has no limit on the number of devices online at the same time, so a client pop-up alone doesn't mean the service has a device limit. Save the exact message and confirm that the selected subscription matches the signed-in account.
Make sure the account matches the client configuration
The dashboard in your browser and the client may not share the same local sign-in state. The dashboard may look fine while the client still uses an old account configuration; seeing routes in the client doesn't prove they came from the account currently open in the dashboard. Check the configuration name, import source and dashboard status. Don't mix another person's configuration with your account. Stop using any entry with an unknown source and retrieve a fresh one from the dashboard.
You can create an account without an email address; a username and password are all you need. For troubleshooting, sign in through the official dashboard only, and never send your password to support. If you can't sign in, check your username, keyboard state and whether your password manager filled in the expected details. Don't keep trying many similar combinations. Save the error message and ask for next steps through an available support channel in the dashboard.
Data allowances and connection speed are different things
Monthly plans are ¥9.9/month for 60GB, ¥18/month for 250GB and ¥28/month for 500GB. Data resets monthly on the activation date. Data packs are ¥158/300GB, ¥358/1000GB and ¥658/3000GB; they remain available until used and never expire. Check the type shown in your dashboard. A data pack doesn't replenish every month, and a monthly plan isn't a permanently accumulating allowance.
No device limit means there is no cap on the number of devices online at once. It doesn't mean every device has a separate data allowance. When checking usage, see whether other devices are still syncing, downloading or transferring data in the background. Background tasks may continue after you close an app. If usage changes unexpectedly, check the dashboard and activity across your devices; a device with no web page open doesn't prove the usage count is wrong.
How to check upgrades and order status
The price difference for an upgrade mid-term is converted into remaining days. If the result after upgrading doesn't match what you expected, keep a record of your original plan, upgrade action and dashboard status, then check the order result. Don't recalculate it using another billing period and assume the charge is wrong, or submit another payment just to refresh the status. Check the order in your dashboard and compare it with the plan details. Contact support through a ticket if something still looks wrong.
Payment methods include Alipay, WeChat Pay and USDT. If your account status doesn't update after payment, check whether the order shows as successful in the dashboard and whether you're signed in to the account that placed it. Don't use unfamiliar links to make a supposed follow-up payment or transfer money to an unverified contact. For an order issue, keep the order reference and relevant payment status, and redact unrelated personal transaction details.
If a device limit appears only in a particular destination service, check that service's account settings. Don't edit or remove your VPNQP subscription to try to change the service's authorization. If the message comes from the client, include where you got it, the selected configuration and what you were doing when the pop-up appeared. If all devices stop working, consider data, account and subscription update status together. If only a new device fails, check its import and permission steps first.
VPNQP offers a 60-day no-questions-asked refund. See the Terms of Service for details. You can document a refund request separately from technical troubleshooting; you don't need to make risky changes to prove there's an issue. For guidance on long-term use and choosing a plan, see Long-Term Use and Plan Selection. The article discusses how to choose; it doesn't add billing periods beyond those listed in the plan details.
Submit a support ticket and verify the fix
Submit a support ticket once your basic connection works, your account status is checked and the issue still reproduces under clear conditions. You don't need to change every setting or repeatedly reinstall the client to prove you've tried something. A useful report describes the environment, action, result and comparison, so support can continue from the same troubleshooting steps. You can also report an intermittent issue that has gone away, but make clear that it's no longer happening.
Share only what's needed
Include your platform, client name and download source, connection type, and any other proxy or network management tools in use. Describe when the issue happened, the selected route, destination domain, action and exact error. Specify your time zone so support doesn't mistake local times from different regions for the same event. If the client displays its version, include the value shown; don't guess or look up a recommended version online.
Comparison results are more useful than a large collection of screenshots. Say whether switching routes on the same device helped, whether switching networks with the same configuration helped and whether other devices were affected. If you haven't checked something, say so instead of guessing to make the report sound complete. Mention any restrictions imposed by a work network or device permissions so support can suggest a practical next step instead of repeating instructions you can't follow.
Redact logs and screenshots before sharing
Don't attach subscription URLs, access tokens, account passwords or full configuration files to a routine support request. Redact them from screenshots, and check that notifications, other windows and browser tabs don't reveal personal information. Logs may contain domains, network addresses and local paths; include only relevant lines from just before and after the issue. If the client supports changing the log level, do so only when support instructs you and restore your usual setting when finished.
VPNQP's no-logs policy doesn't replace your responsibility to manage local diagnostic files. Screenshots and client logs you choose to submit may contain personal information, so review them before sharing. Don't repeatedly upload raw logs to public communities or let strangers sign in to your dashboard remotely. See the Privacy Policy. For technical issues, use the official support ticket system after signing in.
When to contact someone else for support
If your basic network can't connect, contact the network provider or administrator. If organizational policies block network extensions, ask your device administrator. If a destination service explicitly reports an account authorization, content region or payment issue, contact that service. VPNQP support can help assess network routing, but can't remove restrictions on another service's account. Knowing where to ask helps avoid repeated handoffs and time spent changing unrelated settings.
If you encounter a certificate error, an installer from an unknown source or a suspected credential leak, stop what you're doing, preserve relevant evidence and contact support through an official channel. Don't weaken security checks to keep testing or give a new subscription URL to an unknown tool. If you've deleted or reset a configuration, say so; that helps support distinguish the original issue from anything caused by later changes.
Verify the original scenario after the fix
After a fix, repeat the action that originally failed instead of just checking whether the connection button says Connected. For a web issue, revisit the original domain and sign-in flow; for an upload issue, complete an actual upload; for a background disconnect, repeat the lock-and-resume test. Keep the other conditions the same and confirm the problem hasn't shifted to another stage. If you only checked some scenarios, note that in the ticket so a partial recovery isn't recorded as a complete fix.
Then restore temporary changes one at a time, including the log level, test routing mode and paused background tasks. Keep settings that are genuinely needed, and record what they do and their original values. If restoring a setting makes the problem return, that's a useful diagnostic result; there's no need to keep changing things at random. Once everything is stable, you can remove old configurations you've confirmed are no longer needed, but first make sure the active configuration source and dashboard access still work.
Submit or add information through the support tickets section of the user dashboard. Keep follow-ups about the same issue in one ticket so the context stays together. Your troubleshooting notes can also help next time: compare the conditions first, then decide whether to repeat the steps. If you haven't completed your first connection, return to the Quick Start Guide and follow the main setup steps instead of starting with advanced settings.