Connection Basics
Can't Connect at All: Find Where the Problem Starts
Check Your Local Network First
“Can't connect” could mean the client won't start, the server list is empty, the connect button does nothing, or the connection stays stuck on “waiting.” Note exactly where it stops instead of treating these as the same problem. Disconnect, then open a website that normally works without the VPN to confirm your device has internet access. If that fails too, check for a network sign-in page, your Wi-Fi connection, and system network alerts. Switching between international routes repeatedly is unlikely to help at this stage.
On hotel, campus, and public Wi-Fi, showing as connected doesn't necessarily mean you've completed network authentication. Open a browser to check whether you need to accept terms or sign in. Do that before starting the client. If the network uses a proxy, note its current settings and check whether they belong to the network you're using. Don't remove network settings managed by your organization or disable system security features unless you know what they do.
Switching the same device to another available network is a useful way to isolate a local connection problem. Keep the client, subscription, and selected route unchanged; change only the network. If the connection works on the new network, the original network's access policy or transport conditions may be the cause. If other devices connect on the original network but yours still can't, check your device permissions, leftover proxy settings, and security software alerts first.
Tell Apart an Empty List, Permission Issues, and Handshake Failures
If the route list is empty, first check your subscription status in the account panel, then make sure the client has selected the right configuration. An imported configuration with no routes is different from a route that fails during the handshake. For the former, see the subscription update section; for the latter, compare routes, networks, and logs. Seeing the service name in the client doesn't prove that the configuration loaded completely.
On mobile, the system usually needs to grant VPN permission before the first connection. If you dismiss the permission prompt, the client may still show an active connect button even though the system hasn't created a tunnel. Try connecting again and approve the system prompt. If a desktop client needs a network component or elevated permissions, follow its instructions in the account panel. If your organization blocks changes to network settings on a managed device, contact the administrator rather than trying to force a change.
If routes are listed and permissions are granted but the connection still fails, look for the first error in the log. A connection timeout generally means no response arrived within the wait period, but it doesn't prove the route is broken. An authentication error points more toward an account, subscription, or configuration issue; a name-resolution error means you should check DNS next. Save a short section of the log from just before and after the error. It's more useful than a screenshot of the last red warning alone.
Check that your system date, time, and time zone are correct. Secure connections validate certificate expiry dates, and a badly incorrect clock can cause certificate checks to fail. Correct the time using your system's normal time-sync feature; don't disable certificate validation just to get a temporary connection. If the time is correct but certificate warnings keep appearing, save the original error and contact support rather than weakening security checks in an unknown configuration.
Compare Routes Under the Same Conditions
When testing another route, keep the intended use the same and compare routes by type or region. Don't update the subscription, reinstall the client, change proxy mode, and switch networks all at once. If the connection comes back, you won't know which change fixed it. See the route list for available routes and types. The only way to tell whether a route works well on your current network is to test it; distance alone isn't enough to judge.
If only a few routes fail while others reach the same destination, use a working route for now and note the failed route name, network, and error. If all routes fail but direct access works, temporarily quit other software that uses the system VPN or proxy, then test again. Save its settings first and restore them afterward so you don't disrupt your normal setup.
If permissions are confirmed, the subscription is valid, and the same error persists across different networks, reinstalling the client again is unlikely to help. Submit reproducible details instead: your platform, the error shown by the client, selected route, whether direct access works, and what happened on another network. Don't send your full subscription URL, account password, or an unredacted configuration. Support usually needs the conditions and relevant log lines, not your credentials.
Check in this order: Does direct access work? → Does the configuration list any routes? → Does the system allow the connection? → Where does the log stop? → Does changing the network or route change the result?
After Connecting
Connected but Websites Won't Load? Check Access and DNS Separately
A Connected Status Doesn't Mean Websites Are Reachable
When the client says “connected,” it usually means the tunnel or proxy entry point is up. It doesn't confirm that the destination's DNS lookup, routing, or app requests are working. First check whether all websites fail or just one, then compare your browser with other apps. If only one site is affected, note its domain and error instead of assuming the entire subscription is unusable. The site's own maintenance, regional requirements, or account status may affect access.
“Server not found” and “connection reset” point to different checks. For the former, start with DNS. For the latter, check whether the request reached its destination, was handled by local software, or was interrupted along the way. A clear access restriction, regional message, or account verification prompt means the destination service responded. Read its instructions rather than trying to fix an account permission issue by clearing DNS cache.
Trying the same page in a browser's private window can reduce the effects of old cache, extensions, and existing sign-in state, but it doesn't create a separate network environment. If the private window works, check extensions, site data, and browser proxy settings first. If both windows fail, continue troubleshooting the network. For work sites, don't clear all browsing data without need; start with the individual site to avoid losing sessions you still need.
Check for DNS Resolution Problems
DNS translates domain names into addresses that can be reached. Your setup may involve the system resolver, the client's built-in DNS, encrypted DNS in the browser, and proxy-side resolution. If these settings override one another, requests may use an unexpected route. Check the client log first to see whether the domain resolves, then identify which layer returned the result. Don't enable every DNS option at once; stacking features doesn't necessarily make things more reliable.
On desktop, system commands can show whether a name resolves. The commands below use an example domain and contain no subscription or account information. They only help confirm whether the system can get an address; they don't prove the destination service is usable. Some clients resolve names inside the proxy, so the result from a system command may differ from the browser's actual request. Check the client log too, rather than treating command output as the final answer.
nslookup example.com
curl -I https://example.comIn Windows Command Prompt or PowerShell, if curl runs as a different command, use curl.exe -I https://example.com to call the intended program explicitly. On macOS and Linux, first confirm the tool is installed, then run the test. A “command not found” error means the tool isn't available; it doesn't indicate a route failure. Don't download scripts from unfamiliar sites for this check or paste unknown commands into a terminal.
If name resolution fails, first restore the default DNS settings recommended by the client and check whether your browser has a separate DNS configuration. If you've edited your local hosts file, look for outdated entries for the affected domain. Back it up first and remove only entries you've confirmed are wrong. Ask an administrator to review hosts files or DNS policies managed by your organization; don't overwrite the entire file.
Cache, Leftover Proxy Settings, and Destination Responses
After fixing DNS settings, your browser or system may still have cached an old result. Close the affected pages and restart the browser, then clear the cache using your system's recommended method. On Windows, you can use the command below to clear the local DNS cache; it won't update your subscription or fix a broken route. Test the same domain again and note whether the error changed from “couldn't resolve” to something else. Don't assume the problem is fixed just because a page refreshed briefly.
ipconfig /flushdnsIf websites work while connected but all fail after you quit the client, check whether the system proxy still points to a local proxy endpoint that's no longer running. Quit the client normally or restore the proxy settings, preserving any proxy value used by your organization. Don't delete all system network settings. Some apps read proxy settings only at startup, so you may need to fully quit and reopen them after a change; refreshing a page won't make the app reload those settings.
If DNS and other websites work but the destination still shows a regional or playback restriction, check the destination service's terms and relevant guide. See the streaming access guide, but remember that a route's region label doesn't guarantee the destination service will accept it. In a support ticket, include the domain, browser message, whether other sites work, DNS check results, and differences between routes. For private pages, describe only the necessary path; don't upload a full request that includes your signed-in session.
An error page is useful evidence too. A clear account, region, or maintenance notice calls for a different response than getting no reply from the server.
Speed and Use Cases
Slow Speeds and Peak-Time Lag: Compare the Full Experience
First Pinpoint What's Slow
“Slow” could mean a page takes a long time to open, a video keeps buffering, a download stalls, or an AI response takes ages to start. These symptoms don't necessarily share the same bottleneck. Initial page loading involves DNS, connection setup, and the destination's response. Smooth playback depends more on steady data transfer, while streamed AI output can also be affected by the destination's queue and account limits. Describe what you were doing and where it stalled before troubleshooting; “it's laggy” alone isn't enough.
Keep the destination, device, and steps as consistent as possible. Compare a site that works without an international route with the destination that needs one. If sites that normally work directly are also slow, check Wi-Fi signal, network congestion, and background activity on the device first. System updates, cloud sync, and downloads on other devices can all use your connection. Pause background transfers you can identify, then repeat the same steps to get a meaningful comparison.
Don't treat the client's latency ranking as a download-speed ranking. Latency reflects the response along a particular test path, while sustained transfers depend on route congestion, the destination server, connection count, and your local network. Whether video plays continuously, a file downloads steadily, or a tool completes its output is a better measure of your actual use case than a single test result. VPNNQ doesn't make fixed speed-test promises that can replace these checks.
Compare Peak-Time Performance and Route Types
When things slow down during peak hours, compare the same route at different times and note the network you're using. If the destination, device, and network stay the same but performance drops during busy hours, shared-link congestion may be a factor. If it's unstable all day, check your local setup, routing, and the destination service. One failed visit isn't enough to prove persistent congestion; check whether you can reproduce the issue under the same conditions.
When comparing routes, you can test IEPL dedicated routes, transit routes, and direct routes for your use case, but don't assume the route type guarantees a particular speed. Transit may improve the path on some networks, while direct routes depend more on local connectivity to the exit. Dedicated routes still rely on your local connection and the destination service. Available options are listed in the account panel; see the route list for details.
| Comparison | Keep Constant | What to Check |
|---|---|---|
| IEPL Dedicated Route vs. Transit | Device, network, and destination | Whether long-lived connections drop and whether repeated requests remain stable |
| Transit vs. Direct | Use case and test steps | Connection success and initial page response |
| Exit regions | Destination account and client mode | Destination response, regional prompts, and content availability |
When testing video, use the same content and playback settings. Automatic quality may lower the resolution after you switch routes, making playback appear to recover even if the connection hasn't actually improved. Check the quality selected by the player, then watch for buffering. Don't run a large download and a video test at the same time on one device; they'll compete for resources and skew the results.
If an AI tool is slow, distinguish connection delays from generation delays. If the page has loaded and you're signed in but output takes a long time to appear, the destination service may be processing the request. If the tool keeps reconnecting or cuts off streamed responses, check the route and client logs. See the AI acceleration guide for related use cases; for coding tools, see this guide to choosing routes for AI coding.
Don't Treat Tweaking Settings as a Speed Shortcut
Don't change transport parameters, cache sizes, or system network stack settings just because you saw a suggestion in a forum. A mismatched setting can make some sites work while other requests hang, making the problem harder to fix. Start with the client's documented defaults and check whether the issue still occurs. Only change a specific setting when logs or support point to it, and keep a record so you can undo the change.
If switching routes clearly helps, keep the working configuration and test it with your regular tasks instead of chasing the lowest number in a test list. When reporting a speed issue, say whether it's pages, playback, downloads, or streamed output that's slow. Include the approximate time, destination, connection type, and route comparison. Don't treat a speed-test screenshot from another service as proof of VPNNQ performance; it may test a different destination and path.
For a useful comparison, change only one thing: the route, network, or destination. Change all three at once and you won't know what fixed the speed.
Connection Stability
Frequent Disconnects and Mobile Background Drops
Tell a Disconnected Tunnel from an Interrupted App
An app reporting a lost connection doesn't necessarily mean the system VPN disconnected. Check the client's connection status, whether the system still shows a VPN indicator, and whether other apps can still connect. If only a video or chat app stops working while other access remains normal, the issue may be with that app's session or a specific request. If the client also shows disconnected, check the network, background restrictions, and connection logs.
Note what the device was doing just before the drop: locking the screen, switching Wi-Fi networks, entering battery saver mode, waking from sleep, or starting another network tool. These details are often more useful than “it disconnects sometimes.” Try repeating the same action while keeping the selected route unchanged. If every network switch triggers a disconnect, check how the client reconnects instead of testing routes only while the device is idle.
Switching networks can change your local address and route, so an existing connection may no longer work. A page may recover when refreshed, while a streaming task fails because it depends on an established session. Save your progress before reconnecting and restarting a task that's generating content or uploading a file. Don't automatically resubmit every failed request; the destination may have completed an action even if its confirmation didn't reach you.
Background Settings on Android and iOS
On Android, battery optimization and manufacturer background-management features may restrict the client when the screen is locked. Open the system app settings and check battery use, background activity, and network permissions for the VPNNQ client. Allow the background activity required by the client. Menu names vary by device, so look for the relevant settings rather than blindly following screenshots from another brand. After making a change, lock the screen and test the same scenario again.
If your system has background cleanup, auto-start, or app-lock options, check whether they could stop the client process. Adjust only the permissions the client needs; there's no need to expand permissions for other apps. System updates can change settings, so permissions that worked before may no longer be active. See the Android setup and verification guide to check that installation and permissions are complete.
On iOS, check that the system VPN configuration still belongs to the current client and that another app hasn't taken over the connection. Don't keep deleting configurations just because there's no Android-style background allowlist. If the connection doesn't recover after a network switch, disconnect and reconnect using the client, then check the system prompt. If your device is managed by your organization, ask an administrator which connection methods are allowed.
Desktop Sleep, Conflicts, and Recovery Checks
After waking from sleep, Windows, macOS, and Linux may take time to restore the network interface and get an address, while the client still shows its old connection state. Wait until the local network is working, then disconnect and reconnect using the client. If that fixes the problem, note that waking from sleep triggers it. Starting the client at login can address launch issues, but it doesn't guarantee the tunnel will connect as soon as the network is ready.
Multiple tools that change system proxy settings, virtual network interfaces, or VPN configuration may conflict. For troubleshooting, leave one connection client active and make sure other tools are fully quit—not just hidden or closed. Compatibility between an organization's remote access tools, security software, and this service depends on their individual policies. Don't disable all protection just to connect or remove network interfaces you don't recognize.
When checking disconnect logs, see whether the timestamps match system sleep, Wi-Fi reconnection, or the client process closing. If the log stops as soon as the screen locks, the system may have ended the background process. If it keeps recording connection retries, the problem is more likely with the network or route. Don't send only the final “reconnected” entry; the context before and after the drop helps identify the cause.
After changing background settings, test the original trigger instead of leaving the client in the foreground. Check access after locking the screen, recovery after switching networks, and whether a long-running task finishes. If the same action causes a disconnect across routes and networks, or the client quits on its own, include your platform and the system message in a support ticket. If it happens only on one route, include its name and comparison results to help support separate device issues from route issues.
A background fix means the service still works when the app is in the background—not just that it reconnects after you reopen the client. Repeat the original screen-lock or network-switch action to verify it.
Configuration Delivery
Subscription Update Failed? Keep Your Working Configuration
Separate Account Status from Retrieval Errors
Subscription updates involve your account panel, subscription URL, network access, and client parsing. A problem at any step can appear as “update failed.” Sign in to the account overview to check your subscription status, remaining data, and plan validity. If the account panel itself shows a problem, resolve the account or order issue first rather than repeatedly deleting and importing the same URL in the client.
If your current configuration still connects, keep it when an update fails. Don't clear the route list just to try again. The existing configuration can help establish whether the problem is limited to fetching the new one. If you delete it and lose your only working route, you'll have both an update problem and a connection problem to troubleshoot. Before changing anything, note the configuration name, selected route, and proxy mode—but don't share screenshots containing credentials.
Make sure you copied the subscription URL from the account panel, not the panel's web address, sign-in page, or a temporary redirect in the browser address bar. Extra spaces, line breaks, or other text can prevent the client from recognizing it. Use the panel's copy or import option first; if that fails, follow the instructions for manual import. Download the client and retrieve your subscription through the user panel.
Choose the Right Steps for the Error
A timeout during an update means the client couldn't complete the retrieval. The cause may be your current network or the route used for the update request. Keep the URL unchanged and compare whether it updates with the connection on and off. If the client offers an option to update through the proxy, read its instructions and note the original setting. Some networks need a direct connection; others may require an existing connection. Neither approach is right for every network.
If you see an authentication or access-denied error, return to the account panel and get the subscription URL again. Check whether you previously reset it. Treat the URL as sensitive. If it's been exposed, reset it using the panel's controls, then update the configurations saved on your devices. Don't reuse an old URL from a chat or send it to an unfamiliar online converter to “check the format”; that could expose your access credentials.
If retrieval succeeds but the client reports a configuration parsing error, first check that the client supports the import format. A subscription may contain routes, rules, and client-specific settings, and import methods aren't always interchangeable. Choose the entry for your platform and client in the account panel instead of editing unfamiliar fields in the file. Don't overwrite this service's configuration with a template from another provider; it may leave unusable proxy groups and rule references behind.
Some errors that look like parsing failures actually mean the client received a web page instead of a configuration. A network sign-in page, destination notice, or redirect can cause this. Check the client log for a content-type or invalid-format message; you don't need to publish the full response. If it contains account information, keep only the error and necessary structural details when contacting support, and redact anything sensitive.
Verify the Updated Configuration
After the client reports a successful update, make sure the configuration you're using is the one that was updated. Multiple configurations with the same name can make it look as if the update changed nothing. Give the configuration a recognizable name and check that the current proxy group still points to an active route. The selected route may have changed when the list refreshed, so choose a route again and test access rather than relying on the success message alone.
A subscription update may change rules, so checking only the connect button isn't enough. Test your usual websites, AI tools, or streaming use cases to confirm they still work as expected. If only one app is affected, see the apps and proxy rules section. Don't disable all rules just to restore the previous behavior. Compare the modes and match records before and after the update to find where they differ.
When multiple devices share an account, each device's saved configuration remains separate; updating one doesn't update the others. After resetting a subscription URL, update each device you still use and remove old copies only when you're sure you no longer need them. This service allows unlimited simultaneous devices, but each device still has its own client settings. The same account doesn't mean the same system permissions, configuration format, or proxy mode.
When reporting an update issue, say whether you can sign in to the account panel, whether existing routes connect, whether the update fails with the connection on or off, and what kind of error the client shows. Include redacted logs, but don't send the actual subscription URL. To show what an address looks like, you can use the example https://example.com/sub?token=YOUR_TOKEN; make clear that it's only a sample and can't be imported as a real configuration.
Importing a subscription, connecting to a route, and accessing your usual apps are separate checks. After an update succeeds, verify the active configuration and proxy group too.
App Routing
An App Can't Use the Proxy? Check Its Mode and Rules
Why Does the App Fail When the Browser Works?
If your browser works but a desktop app or command-line tool doesn't, the programs may be using different network paths. System proxy settings are read by apps that support them; they don't automatically cover every network request. Some apps have their own proxy settings, while others depend on the system VPN or the client's virtual network mode. Find out which path the app uses before deciding whether to change the client mode.
Don't leave all traffic on the same route just to get one app working. Global mode can be a short-term comparison to check whether a rule is causing the problem, but it may also reroute services that should connect directly. Before testing, note the current mode and keep the app and route unchanged. Fully quit and reopen the app after switching. If it works, check the matching rule in rule mode instead of treating the test setting as a permanent fix.
Some apps read proxy settings at startup and won't immediately pick up system changes. Closing a window doesn't necessarily quit the process, so use the app's quit command before reopening it. Command-line tools may get proxy settings from the terminal environment or their own configuration. If a new terminal behaves differently from an existing one, note that as a clue. A working browser screenshot doesn't prove that another app is using the proxy.
Rule Matches and App Requirements
Open the client's connection log and find the app's requested domain and matching rule. Check whether it was sent direct or assigned to a proxy group. The brand's domain shown in the app may not cover every request: sign-in, downloads, APIs, and content delivery may use different domains. Fixing only the main domain while missing the failing API can leave the home page working but sign-in or generation broken.
When editing rules, follow the format and rule order supported by your client. More specific rules may need to come before broader rules that would otherwise override them, but check the client documentation for its actual matching behavior. Don't paste a large configuration from the web into an existing subscription, especially if it replaces proxy group names or references. Save a recoverable copy first and change only destinations confirmed by the logs, so other use cases keep working.
If an AI app opens but won't work, also check the destination account's eligibility, regional notices, usage limits, and service status. A network connection can't replace the destination's own access requirements. Cursor, Copilot, and command-line tools may use long-lived connections and different request paths. See our guide to VPNs for AI coding for context; troubleshoot specific failures using the app's original error and client logs.
Platform Differences and Permission Limits
| Platform | Check First | Easy to Miss |
|---|---|---|
| Windows | System proxy, app proxy, and network component permissions | The app process hasn't restarted, or another tool has overridden the settings |
| macOS | Network service proxy and system permissions | A different network service is in use after switching networks |
| iOS | VPN configuration and regional notices from the app | Another app has taken over the connection |
| Android | Per-app include or exclude rules and background permissions | The target app is set to bypass the VPN |
| Linux | Desktop proxy, terminal environment, and tool configuration | The desktop app and terminal use different environments |
If your Android client supports per-app include or exclude rules, check that the target app isn't excluded. Don't look only at domain rules; per-app settings can decide whether a request enters the tunnel at all. After changing app selection, reconnect as prompted by the client and reopen the target app. Work-profile and personal-profile apps may be managed differently; follow your device's management policies.
Desktop virtual network mode may require additional permissions or a network component; it isn't a universal fix for app problems. Confirm that the client supports the mode and follow the account panel's instructions to authorize it. If local services stop working after you enable it, switch back promptly and check routing or exclusion rules. Corporate networks, remote desktops, and local device access have their own requirements. Don't force all local traffic onto a different path just to use one international app.
On Linux, desktop environments and command-line tools may handle proxy settings differently. Start with the tool's own proxy documentation, then check whether the current terminal has old proxy variables. Record their original values before removing or changing them. Don't keep appending settings to shell startup files without removing outdated entries; new terminals may inherit conflicting values. Don't enter a local proxy address until you've confirmed the client's actual endpoint.
If rule mode fails but a comparison mode works, include the target app, failed action, matching rule, and assigned proxy group in your support ticket. If every mode fails, add the app's original message and the browser comparison. Logs may contain private filenames, work projects, or request parameters; redact them before sending. Support doesn't need your password for the destination account. A reproducible set of steps and a redacted error are usually enough.
Account and Billing
Device Limit Warnings, Data Usage, and Subscription Status
“Too Many Devices”? Check Where the Message Came From
VPNNQ allows unlimited simultaneous devices. If you see “device limit reached” or a similar message, first check whether it came from the VPNNQ account panel, the client, or the service you're trying to access. Streaming, collaboration, and other destination services may have their own device or session policies. VPNNQ's device policy doesn't override theirs. Save a screenshot showing where the message appeared and its full wording so you don't mistake a destination-service restriction for a plan limit.
If the warning comes from the client, make sure the selected configuration belongs to your current VPNNQ account. When multiple service configurations are stored in one client, you may still be using an old subscription or another provider's setup. Check the current subscription in the account panel, then verify the configuration name, route list, and proxy group in the client. Don't pay again to resolve an unverified warning or infer VPNNQ's device limits from another provider's rules.
If both the account panel and client confirm you're using VPNNQ but you still see a device warning that conflicts with unlimited devices, contact support with a redacted screenshot. Check the source of the warning, account status, and configuration—not by deleting your devices one by one and hoping for a fix. Devices have different permissions, networks, and background settings; a problem on one device doesn't mean your account has a device limit.
Data Rules and Status Sync
Monthly plan data resets each month on the activation date, not on the first of the calendar month. Monthly plans are ¥9.9/month for 60GB, ¥18/month for 250GB, and ¥28/month for 500GB only. If you upgrade mid-cycle, the price difference is prorated by the remaining days. Compare plans on the plans page; don't infer your current billing status from a cached client label or old screenshot.
Data add-ons never expire and remain available until used. Options are ¥158/300GB, ¥358/1000GB, and ¥658/3000GB. “Never expires” describes the add-on's validity; it doesn't mean the data can't be used up or that it follows the monthly plan's reset schedule. Check the available balance in the account panel. If the client won't connect and the panel shows insufficient data, verify your plan type and remaining data before investigating routes or DNS.
Usage shown in the client and billing status in the account panel may use different measurement methods or update at different times. Don't simply subtract one from the other and conclude that data is missing. Background transfers, other connected devices, and requests already sent can also affect usage. If you have questions, record what the panel shows, when it happened, and what the connected devices were used for, then ask support to check. Don't invent your own conversion rules or assume a fixed usage rate.
If the order status hasn't updated after payment, check the order details in the account panel and the final result on the payment page. Make sure you're back in the same account. Supported payment methods are Alipay / WeChat Pay / USDT. Closing the payment page doesn't confirm that payment went through, and you shouldn't create the same order repeatedly before checking its status. Save the order details needed to identify it and contact support through the account panel.
Protect Your Account and Configuration
This service doesn't require an email address; use a username and password to get started. Keep your login details safe. If you forget your password, use the recovery options actually available in the account panel. Don't send your password to a stranger who claims they can “look up your account.” If your browser has saved multiple accounts, make sure you're signed in to the one you used to purchase a plan or get the subscription. The wrong account can make a plan appear missing or a subscription seem unrelated.
Checking your account on another device can help distinguish browser cache from your actual account status, but use a device you trust. Sign in and check the account overview, then refresh the page or sign in again on your original device. If the devices show different statuses, record the difference and make sure the account names match. Don't delete all browsing data to force a sync; you could lose useful sign-in details and troubleshooting evidence.
A subscription URL and a login password serve different purposes, but neither should be shared publicly. Get subscription details from the account panel when setting up your own devices, and remove saved configurations from devices you no longer use. If you think your subscription URL has been exposed, reset it using the panel's tools and update your devices. Renaming a local configuration doesn't change its credentials or stop continued use of a leaked URL.
Ask support to investigate account, order, or plan issues; there's no need to change your system network settings. A ticket can include the plan shown in your account, order status, where the message appeared, and the sign-in checks you've tried. Keep credentials redacted. This service offers a 14-day no-questions-asked refund; see the Terms of Service for the refund terms. You can mention a connection issue when asking about a refund, but don't assume an undiagnosed fault proves a billing error.
Unlimited devices, monthly data resetting on the activation date, and data add-ons that never expire are separate rules. Check the message source and plan type before troubleshooting.
Support and Follow-Up
When to Contact Support and How to Verify a Fix
When to Stop Changing Settings Blindly
If you've checked your local network, subscription status, and permissions and can still reproduce the problem, submit a support ticket. This is especially important if every route produces the same authentication error across different networks, configuration parsing keeps failing, or the account panel disagrees with the order status. Reinstalling again is unlikely to provide useful information. Support needs clear symptoms and conditions; you shouldn't have to change your device until it's impossible to restore.
If you see a certificate warning, conflicting account messages, or unfamiliar configuration content, stop before weakening security checks. A temporary connection isn't a reason to ignore a warning. For organization-managed devices, check with your administrator about network permissions, internal routing, and security policies. A VPNNQ support ticket can help identify client or route issues, but it can't replace your organization's authorization to manage the device.
If you've found a working backup route, keep using it and note the conditions that cause the failure. Avoid making broad configuration changes in the middle of important work. For tasks that require continuous output, uploads, or remote sessions, test with something you can safely resume before changing settings. Don't use important files or irreversible actions to test an unstable connection. Troubleshooting should reduce the impact of a failure, not create a data-loss risk.
Build a Clear Trail of Evidence for Your Ticket
Submit the issue through a support ticket in the user panel. Start with the symptom and its impact, such as “websites work in my browser, but my command-line tool times out” or “the client stops logging after I lock the screen.” Then include your platform, network type, selected route, configuration mode, and the action that failed. “It doesn't work” alone doesn't tell support whether to check your account or network first.
Describe the results of comparisons you've already made, not just the steps you tried. “It still fails on another network with the same error” is more useful than “tried changing networks.” “Rule mode fails, but comparison mode works” is clearer than “changed settings.” Say which conditions stayed the same so support can tell whether the comparison is valid. If you forgot to restore a setting afterward, state its current value so everyone is troubleshooting the same setup.
Include the section of the log from just before and after the failure, keeping the timestamps and original error text. Screenshots should show which app displayed the message, but redact account credentials, subscription URLs, private paths, sensitive payment details, and work content. Some logs include request parameters or authentication fields, so review them before sending. Don't publish your full configuration or upload logs to an unfamiliar analysis site unrelated to the account panel.
Example ticket: On macOS, websites work in the browser, but a desktop app times out during sign-in. I'm using rule mode. The issue persists after fully quitting and reopening the app; another route gives the same error. I can sign in after briefly switching to comparison mode. I've restored the original mode and attached a redacted rule-match log for the failed request.
Give the time you actually observed the problem and your time zone; don't treat an inaccurate device clock as a reliable event time. If the issue happens only during peak hours, describe the time range you can reproduce and what you were doing. For background drops, note whether the screen was locked, the network changed, or the device woke from sleep. Don't add latency, bandwidth, or availability numbers you haven't measured; guesses can obscure confirmed facts.
Return to Your Normal Setup After the Fix
After receiving a recommendation, save your current settings and make changes one at a time. Repeat the action that caused the failure after each change and record whether anything changed. If it didn't help, undo unnecessary changes. Don't combine support recommendations with unrelated settings you found online; otherwise, you won't know what worked. If menu labels differ by platform, describe what you actually see rather than guessing which switch to use.
Don't stop verification at “connected.” Check that the destination website, app sign-in, long-running tasks, and background use work again. Make sure normal local services still work too. If you used temporary global mode to isolate the issue, return to an appropriate rules-based setup afterward. If you cleared leftover proxy settings, confirm that direct access still works after quitting the client so you don't leave behind a new network dependency.
Keep a brief note of the conditions that worked: which configuration you used, which permissions need to stay enabled, what action triggered the problem, and how to restore the defaults. This makes it easier to spot what's changed after a system update or network switch. Don't put subscription URLs or passwords in your troubleshooting notes. Your use case and setting names are enough; keep sensitive details managed in the account panel.
For your first installation, follow the setup guide. Find quick answers in the Help Center and compare routes on the route list. If the issue turns out to be the destination service's account or regional content rules, follow that service's requirements. If it involves your subscription or route, add the results to the same support ticket to document the symptoms, comparisons, and recovery without having to repeat the background.