VPN Troubleshooting Guide

Can't connect at all: Connection checks in order

“Connection failed” can mean the client won't start, a route rejected the connection, or simply that the website didn't respond. First, note the exact message and what the interface does: does the connect button work, does it immediately return to disconnected, or does it stay on “Connecting”? Record the route name and network in use when the error occurred. Don't rely on the icon color alone or assume a browser error means the route is at fault; each symptom points to different checks.

Check the underlying network before the client

Disconnect the proxy and try a website you can normally access directly to confirm the network itself is working. If even the local network sign-in page won't load, check your Wi-Fi connection, router or network authentication first. Public networks may require you to accept terms in a browser before connecting. If the same device works on another available network, note what changed instead of deleting the subscription right away; removing the configuration won't fix an underlying network problem.

Once the underlying network is working, check that the client is running and a connection configuration is selected. Some clients let you browse routes even when their background service hasn't started. Others may still have an obsolete entry selected after a configuration update. Open configuration management and confirm you're using the VPNRQ subscription, then check whether the route list loads. If the configuration is empty, fails to parse or has no selectable routes, go to subscription update checks; don't keep switching connection modes for now.

Use a comparison test to separate route issues from device issues

On the same network and in the same client mode, select a route in another region and see whether the error changes. Refer to the route list for route names and types; the routes available to you are those shown in your account subscription. If only one entry fails while others connect, note the failing entry. If all fail, compare with another device that is already configured. Keep your existing rules during the test. Changing DNS, routing and network interfaces at the same time makes it impossible to tell which change mattered.

Check that your device's date, time and time zone are correct, and enable automatic time setting if needed. A significantly incorrect clock can interfere with certificate validation for encrypted connections. If the error mentions insufficient permissions, a network extension that isn't allowed, or an unavailable background service, check the client's permissions in system settings. Grant only the permissions required by a client from a trusted source; don't loosen all system restrictions just to dismiss a warning. On a managed device, first confirm with your organization that proxy settings or network tunnels are allowed.

Check for conflicting network tools and leftover configurations

Check whether another proxy client, a security app with network filtering, or an old VPN configuration is running at the same time. These can compete for the system proxy, virtual interface or default route. Quit tools that aren't part of the test normally, then reconnect with the current client; closing a window may not stop its background service. Don't uninstall every security app or delete unfamiliar system interfaces. If your device is managed by an organization, ask the administrator to check for conflicts before changing work network settings.

If the connection still fails, open the client's diagnostic log and capture the error summary around the time of the test. Look for the difference between a configuration read error, connection timeout, connection refused and permission error; don't copy the entire session log. For a timeout that reliably occurs on one route, include the network type and comparison results. If every route fails at the same step, include details about device permissions, other network tools and system errors. Support can use this information to decide what to check next; reinstalling shouldn't be the first step.

When to stop: If the underlying network isn't working, fix that first. If it is working, the configuration is valid and connections still fail across networks, keep the logs and submit a support ticket. Repeated retries aren't a diagnosis.

Connected but websites won't load: troubleshooting routing and DNS issues

A connected status only means that a connection process completed; it doesn't prove that browser requests are using it. First, narrow down the symptoms: do all websites fail or just one domain? Does the issue affect only the browser or other apps too? Does the error say the server can't be found, the connection timed out or the certificate is invalid? Save the exact error text. If you see the target service's own sign-in or region message, the request has reached at least part of the service; don't simply classify it as a complete network failure.

Check whether the request reaches the client

Confirm that the system proxy or tunnel mode is enabled as required on your platform, then open the request log and reload the affected page. If there is no matching request in the log, check whether the browser uses its own proxy, an extension overrides system settings, or the client handles only selected apps. If the log shows the domain going direct, check which rule matched. Switching remote routes is useful for diagnosis only after confirming that the request actually reaches the client.

You can temporarily compare rule-based routing with global proxy mode, then restore your usual settings afterward. If global proxy mode works but rule mode doesn't, check domain rules, rule order and DNS routing instead of assuming the route is unavailable. If both modes fail, try another route in a region suited to the same service. Don't install a browser proxy extension to “stack another fix”; adding another layer usually makes the request path harder to trace.

Tell DNS resolution failures apart from connection failures

DNS translates a domain name into the address needed to connect. A resolution failure may make the browser report that it can't find the host. If resolution succeeds but the connection fails, continue checking the route, network path and target service. The commands below only show how your system's current resolver responds to an example domain; they don't verify whether the proxy is working. Replace the example domain with the public domain you're troubleshooting. Never paste a subscription link, account details or an address containing access credentials into a command.

nslookup example.com

A difference between system command results and browser results doesn't prove which one is at fault. The browser may use its own secure DNS, while the client may resolve domains internally, so a system lookup can take a different path. Check which resolver settings are actually in effect before making changes. If your subscription includes a matching DNS configuration, keep it intact. Switching arbitrarily to a public resolver may make DNS resolution inconsistent with the actual exit route.

Change settings based on observable results

After changing settings, close the failed page and, if needed, restart the browser before trying the same address again. Browser cache, old connections and site data can preserve results from before the change, but don't clear all personal data right away. You can first compare in a temporary browser profile without extensions. If you see a certificate warning, check the system clock and network sign-in page, and save the warning text. Don't “fix” the issue by ignoring certificate validation; that can hide the real problem.

If the same error persists after restoring DNS settings, submit the target domain, error summary, matched rule and route name. Provide only the domain and a path without private parameters; don't upload the full address from a signed-in session. Support needs to know whether the error happened during resolution, connection setup or the service response. Mentioning that other websites work is useful too: it helps narrow the issue from a device-wide network failure to a specific request path.

Slow speeds and peak-hour slowdowns: how to compare routes

Start by defining the task. A slow first page load, low sustained download speed, repeated video buffering and choppy meeting audio aren't the same metric. Page loads are affected by resolution and connection setup; sustained transfers rely more on available bandwidth; real-time meetings are more sensitive to jitter and packet loss. Choose a real task you can repeat, and note the network, route and client mode. Without consistent test conditions, it's hard to compare routes by feel alone.

Keep other conditions unchanged

Pause background downloads, cloud sync and system updates that are using the network, and check that other devices on the same local network aren't transferring data continuously. Weak Wi-Fi, a heavily loaded router or congestion on the local connection can all look like a slow international route. Compare the same task closer to the router, or use a wired connection if available. If the underlying network is unstable, fix that first; changing remote regions over and over will usually produce inconsistent results.

When comparing routes, keep the target service, device and activity the same. A cached page and a newly downloaded file aren't directly comparable. Video quality may also adjust automatically based on network conditions, so note the player quality and any error message when checking for buffering. Don't run a stream of speed tests; they use bandwidth and can affect the meeting or playback you're trying to evaluate.

Understand route types; don't treat names as results

IEPL, transit and direct routes describe how a connection is arranged; they don't imply a fixed performance ranking for every network. Results depend on your access network, the target service's region, the current exit path and local Wi-Fi conditions. Start with a region suited to the target service, then compare entries within that region. For details on route types and choosing a region, see the route list. A shorter geographic distance doesn't automatically mean faster access to a service.

Compare peak-hour results across times and networks

If the issue mainly occurs in the evening, compare the same task at other times and note which access network you're using. Peak-hour slowdowns may originate from local broadband, shared Wi-Fi, the ISP's route or the route's exit; the time of day alone doesn't identify the cause. If switching access networks clearly improves performance, give support the network comparison. If only one route slows down on the same network, note that route and a route that works normally.

For real-time collaboration, prioritize a stable connection instead of chasing the route that looks fastest while a meeting is underway. Changing exits may reconnect the session, turning a brief slowdown into a sign-in or meeting interruption. Compare routes before the meeting, and switch during use only if the issue persists. For differences between meetings, shared documents and remote desktops, see the guide to choosing a route for remote work; its comparison framework also applies to everyday troubleshooting.

Check your remaining data and subscription status in your account. VPNRQ monthly subscription data resets each month on the activation date, not on a shared calendar date. Don't mistake a reset date that hasn't arrived for a billing error, or expect more data to fix a local network problem. To compare data tiers, see plan pricing. If you have plenty of data but still experience slowdowns, sharing the task, time of day and route comparison results is more helpful than simply saying “it's slow.”

Frequent disconnects and mobile background drops: check connection stability

First determine whether the client actually disconnected or an app simply stopped responding temporarily. If the client still shows a connection and only one app needs to reload, check that app's requests and session. If the system VPN indicator disappears or the client shows disconnected, check background permissions, network changes and the client service first. Note whether the device was locked, asleep, out of Wi-Fi range or switching back from another network before the disconnect. These triggers can be more useful for diagnosis than an error screenshot.

Separate network changes from remote issues

Switching from Wi-Fi to mobile data or resuming from sleep may require the existing connection to be re-established. If disconnects occur only after these actions, check whether the client supports and has enabled an appropriate auto-reconnect option, then observe how it recovers. A brief reconnect doesn't necessarily mean the route is persistently failing. If the device disconnects while staying on the same network and in active use, check the client logs for timeouts, interface resets or remote closures.

A router reconnect, Wi-Fi roaming or expired network authentication can also interrupt an existing session. Compare the same task on the same device using another reliable network. If other apps lose connectivity at the same time, the underlying network is more likely to be the cause. If only the proxy connection drops, check the client and route. Avoid changing both the region and network during a test; if it recovers, you won't know which change mattered.

Android: check battery and background restrictions

In system settings, open the client's app details and check battery use, background activity and data restrictions. Menu names vary by device manufacturer, so follow the options shown on your device. If background activity is restricted, the client may be paused when the screen is locked. Change only the permissions this client needs; there's no need to disable power-saving protections for the whole device. Afterward, confirm the connection in the foreground, then lock the screen and repeat the task to see whether it disconnects under the same conditions.

Some devices also use system cleanup tools to stop background tasks. Keeping an app in the recent apps list doesn't necessarily grant permission to run continuously, so check the restrictions applied to that app. If your organization's policy blocks background tunnels or network routing, ask an administrator. Don't install unknown “keep-alive” tools or change low-level device permissions just to troubleshoot. Keep any system restriction message so support can assess whether the issue is within the client's control.

iOS and desktop: check system network control

On iOS, check that the system VPN configuration is still present and managed by the client you expect. Another network tool may have switched the active configuration, making it look like the connection dropped when it was actually replaced. If a system authorization prompt appears after an OS update or client change, confirm it through the official system settings. Don't delete all profiles repeatedly. Ask your device administrator about unfamiliar managed configurations to avoid disrupting networks needed for work or study.

On Windows, macOS and Linux, also check whether the background service is running after the device wakes, whether the system proxy still points to the current client, and whether the network interface has changed. After reopening a laptop, an app may retain an old session even though the tunnel has been rebuilt; restarting the app's connection is more appropriate than reimporting the subscription. If the client needs system extension or service permissions, verify that they're granted. An open client window alone doesn't prove that its background functions are working.

Verify recovery by repeating the action that triggered the issue

After making a fix, repeat the action that first triggered the problem, such as locking the screen, waking the device, switching networks or joining a meeting. Don't just leave the desktop idle and watch it. If one route repeatedly disconnects while the network stays unchanged, use another route as a temporary workaround and submit the failing entry with its logs. If every route disconnects only after the screen locks, include the platform's background settings and system messages. If frequent disconnects leave no log events, mention that too; the system may have terminated the background process.

A restored connection doesn't mean the original app session resumed automatically. Check whether the meeting, download or remote desktop has resumed. This check is complete only when both the client status and the actual task are working again.

Subscription update failed: from your account to configuration import

Subscription updates retrieve routes and configuration; route connections carry your requests. These are separate processes. An old configuration may still connect while the update step temporarily fails, or an update may succeed while the selected route doesn't work. Note where the failure occurs: copying the subscription, adding a configuration, downloading it or parsing it. Don't delete a local configuration that still works just because an update failed. Keep a way to revert while you troubleshoot the new configuration.

Check your account and subscription status in the dashboard

Use Account Overview to check the account you're using, plan status and remaining data, and make sure you haven't signed in to a different account by mistake. No email address is required; create an account with a username and password. When troubleshooting, verify the username you actually use instead of relying on browser autofill. Never include your password, subscription URL or access credentials in a support ticket or public screenshot. If the account page won't open, start with the underlying network and website troubleshooting sections.

For order status, rely on what the dashboard shows rather than assuming a subscription is active based only on a payment app's charge notice. VPNRQ accepts Alipay / WeChat Pay / USDT. For payment issues, provide redacted order details; never share your account password. Monthly subscription data resets each month on the activation date, and mid-cycle upgrades are prorated by the remaining days. Data packages remain valid until used and never expire. First confirm which type of plan you have, then check whether the remaining data matches your account status.

Tell download failures apart from parsing failures

If the client says it can't download the configuration, first confirm that the underlying network works and that the update request isn't being routed through a proxy that has stopped working. Some clients let update requests use a separate network path; make changes only based on the actual interface and logs, not option names copied from other software. If the subscription downloads but shows a format error, check that the import method matches, the copied content is complete and you haven't used a regular webpage address instead of the subscription URL.

Get your subscription link from the user dashboard on this site. Don't copy it from an unknown source in chat or upload it to a public online conversion tool. When copying, avoid extra line breaks, explanatory text or punctuation. If you use the dashboard's import option, first confirm that the system opens the intended client, then check that the new configuration appears in its list. If nothing happens, the system may not have an app association for the link; that doesn't necessarily mean the subscription is invalid.

What to do when old and new configurations are both present

Give configurations names that make their source easy to identify, then check whether the active entry is the subscription you just updated. Some clients don't switch automatically after adding a new configuration, so an update may appear successful even while the connection still uses an old entry. Select the updated configuration and check that its route list and rules have loaded. If you use local overrides, make sure they haven't broken the new configuration's DNS, proxy groups or rule structure. If needed, compare temporarily with the configuration without overrides.

If route names change after an update, a manually pinned option may no longer exist. Select a route that appears in the current list instead of editing underlying files to force an old name back in. If the new configuration won't parse but the old one still works, keep the old one and note the new configuration's parsing error. If the old one also fails, include the account status and the error from the download stage. Don't reset the subscription repeatedly; that may invalidate an old link still in use on another device.

What to include when reporting a failure

Tell support which update option you used, the client and operating system, the stage where it failed, and the error summary. Also mention whether you can sign in to the dashboard. In screenshots, show only the configuration name and error message; cover the entire subscription URL and any QR code. Check the edges of the window too, in case the address is visible there. Redact complete request URLs in logs as well. Support needs the error type and steps to reproduce it, not credentials that provide direct access to your subscription.

After a successful update, verify configuration loading, route selection and the target task separately; don't rely only on an “Update complete” message. If you need help with the import steps, follow the main workflow in the getting started guide. If you think you selected the wrong billing or data type, check the plan details. Subscription retrieval and billing can be related, but don't assume every update failure is a plan issue without checking the account status first.

An app won't use the proxy: routing rules and exit routes

A working browser doesn't mean every app uses the same proxy settings. Some apps use the system proxy; others make connections independently or rely on a background service or separate update process. First narrow down the failure: does the main interface fail, or only sign-in, downloads or real-time features? Does it affect only the desktop app while the same service works in a browser? Record these cases separately so you don't add overly broad rules for the whole app while missing the component that's actually making the request.

Check request logs before choosing a routing method

Open the client's request log and repeat the action that fails in the app. If no matching request appears, check whether the app uses its own proxy and whether the current system proxy mode can handle it. Consider tunnel mode as a comparison only if the client supports it, system permissions allow it and it's appropriate for your environment. Tunnel mode affects system routes and DNS. Don't run other network-routing tools at the same time, and don't change office connections that your organization requires you to keep.

If the request appears in the client, check the rule it matched and its exit route. A proxy rule for the main domain doesn't guarantee that sign-in, static assets or update domains use the same route. Check domains directly related to the failed action in the logs, but don't treat every request in the network log as something that needs changing. Failed ad, analytics or other nonessential requests may not be the reason the app is unusable; judge by whether the actual feature works.

Rule order matters more than adding another rule

Routing rules are usually processed in the order set by the client. A new domain rule may be saved but still overridden by an earlier rule, leaving the exit unchanged. First confirm you're using the current configuration, then check whether override rules are loaded and which rule matched the app request. Don't replace the entire subscription rule set to fix one app or paste unfamiliar settings from a forum. References to missing proxy groups or unsupported fields can break an otherwise working configuration.

An app's sign-in state can also affect the results. After switching exits, a service may ask you to verify your session again or continue using an existing long-lived connection. Save your work, quit the app normally and reopen it to test instead of clearing all its data right away. Follow administrator requirements for enterprise sign-ins, trusted devices and organization policies. If the service explicitly reports an account, region or permission issue, handle it under the service's own rules; not every such message indicates a network problem.

How AI tools, streaming and work apps differ

An AI tool's website, desktop app and API may use different request paths. If the website works but API calls fail, check the app's own proxy settings, runtime environment and the type of error returned by the service. Don't include API credentials in log screenshots or share complete requests in public chats. If the service returns a clear account or access-permission error, the request may have reached its servers; check the relevant account settings instead of continuing to switch routes.

Streaming can also depend on content region, account status and playback device capabilities. If the home page loads but video won't play, note the player error, current route region and whether only certain content is affected. Switching routes changes the exit environment, but may not immediately change an existing playback session. For help with playback and region checks, see the streaming guide. Don't assume that one successful playback means all content will work, or that a quality indicator proves the route is fine.

Meeting software, remote desktops and games may use different transport methods from ordinary websites. A successful webpage test only confirms that the webpage path works; it doesn't replace testing the actual app. For work, keep your organization's intranet requirements in mind so global proxy settings don't disrupt local printers, shared resources or corporate sign-in. Windows users can consult the guide to global proxy and routing rules on desktop to check for system proxy conflicts, but follow the menus in your current client.

Verify the complete task after making a fix

Test sign-in, the main feature and continued use—not just whether the app launches. Keep track of which settings are part of the original configuration and which rules you added, then remove temporary test rules after confirming the fix. If the app works in a browser but the desktop client never appears in the request log, report the difference and routing mode. If requests appear but a particular exit fails, include the matched rule and service error. This turns “the app doesn't work” into a specific request issue that can be investigated.

Platform differences and device-limit warnings: check permissions

VPNRQ supports Windows / macOS / iOS / Android / Linux, with unlimited devices online at the same time. If an interface says you've exceeded a device limit, don't assume it's a VPNRQ plan restriction or buy another tier right away. First check whether the message comes from the client, operating system, target app or account dashboard. A device limit set by a service is separate from the device policy for a network subscription. Save the exact message and where it appeared before deciding what to troubleshoot.

For a device-limit warning, check its source and account first

Check that the configuration in use is from VPNRQ, that no subscription from another service is still present, and that autofill hasn't signed the device into a different account. Some clients show their own authorization warnings, and some apps limit active sessions; don't confuse these with a route device limit. If the VPNRQ dashboard or connection process shows a warning that conflicts with unlimited devices, send support a redacted screenshot, the client name and what you were doing. You don't need to sign out of every device just to test.

If multiple devices have the same problem, check whether they're using the same router, network or a shared configuration that may have been altered. A shared environment can affect several devices at once without indicating a device quota. If only a new device fails, check import, permissions and time first. If older devices started failing after a configuration update, check the subscription and local overrides. Grouping devices by operating system and network is more useful than simply listing the total number of devices.

Desktop platforms: permissions and proxy settings

On Windows, check whether the system proxy still points to the client that's currently running, especially after another network tool has been closed or at startup. If an old tool left behind proxy settings but its background process isn't running, the browser may be unable to connect. Before restoring settings, check whether they're managed by your organization; don't delete a required corporate proxy configuration. If a mode needs a tunnel or background service, grant permissions as prompted by the client. Running everything as administrator isn't a general fix.

On macOS, check whether the network extension, VPN configuration and system permissions requested by the client have been approved. An open app window doesn't mean its extension has been allowed, and you may need to reconnect after approval. If macOS blocks the app, verify its source instead of trying to bypass system checks. For the installation and permissions workflow, see the Mac setup guide. Keep the current configuration while troubleshooting so you can compare it with the original state instead of losing that reference during reinstallation.

On Linux, distinguish desktop proxy settings from the network behavior of individual programs. A terminal app may not use the desktop proxy, and a desktop app may not inherit terminal environment variables. Check running services, the current configuration path and error output before deciding which layer to change. Don't copy local proxy ports or administrator commands from another device; port and permission requirements depend on your client. Before changing an unfamiliar service, save its configuration and make sure you know how to restore it.

Mobile platforms: system configuration and app coverage

On iOS, check that the active VPN configuration belongs to the client you expect. On Android, in addition to background permissions, check the app inclusion and exclusion lists. An excluded app won't be routed as expected even if the system shows a connection. If your device is managed, don't remove organization settings yourself. After changing the app scope, restart the target app and check its requests and actual features—not just whether the system icon is present.

If you need to download the client again, use the client download option in the user dashboard; don't use an installer from an unknown source. For a platform issue, provide the operating system and client names, the permission prompt and whether the device is managed. Before sharing screenshots, cover your username, device identifiers and private network details. Provide further details through a support ticket only when they're needed; unnecessary material adds troubleshooting and privacy risks.

Support materials and recovery checks: keep a troubleshooting record

If you've checked the underlying network, valid configuration, system permissions and route comparisons but still can't find the cause, work with support through a ticket. There's no need to keep changing settings at random just to prove you've tried something. Support needs reproducible symptoms, clear test conditions and a redacted error summary. Describe what happened during a specific action rather than saying “nothing works”; that makes it easier to investigate and cuts down on questions about your current configuration.

When to submit a support ticket

Submit a ticket if you can sign in to the dashboard but can't retrieve the subscription, your account status doesn't match your order, a valid configuration fails to connect across different networks, or the same error reliably occurs on a particular route. Save and share any service-side warning that conflicts with unlimited devices online at the same time. For a managed device blocked by policy or an account restriction reported by the target service, also contact the relevant administrator or provider; route support can't change their access rules.

If a remote meeting or critical work is interrupted, switch to a tested working alternative first, then gather details. There's no need to keep experimenting while the task is underway. If no alternative works, describe the task affected and whether a temporary workaround is available; don't add unverified guesses about the cause. In your ticket, distinguish what you observed directly from what you suspect so the investigation doesn't head in the wrong direction.

Describe the conditions, action, result and comparison

Record the following in order: device and operating system, access network type, client name, current mode, configuration source, selected route, action that triggered the issue, exact error text and comparisons already completed. Include the local time zone so support can correlate logs, but don't guess when a server-side issue occurred. Provide only the public domain and necessary path; remove private query parameters. If the issue affects one app, say whether the browser works and whether the request appears in the client log.

Symptom: The client shows connected, but the target app won't load.
Environment: Include the operating system, client and access network.
Path: Include the mode, route name and action that triggered the issue.
Error: Paste a redacted error summary.
Comparison: Report what happened after changing routes, networks or apps.
Changes: List the settings changed during this session and whether they've been restored.

Don't send a full-screen screenshot and expect support to guess what's important. Capture the error and relevant settings, and explain them in text. Before uploading, cover subscription QR codes and full URLs, passwords, access credentials and private content. Diagnostic files may contain the same information; exporting a file doesn't automatically redact it. If you're unsure, name the log type and ask which section is needed instead of posting the entire file in a public forum.

Keep a record you can roll back between troubleshooting steps

When you receive troubleshooting advice, save your current settings first and then follow one suggestion at a time. Record the mode, route and results before and after each change so you can reproduce the original state in the next discussion. If the suggested steps don't match the menus on your system, report what you see instead of guessing what an unfamiliar switch does. Before deleting a configuration, resetting a subscription or changing system networking, confirm which devices will be affected and how to undo the change. Don't skip backups and impact checks because you're in a hurry.

If a change doesn't help, restore the last known working state before trying the next one. Leaving every temporary change in place can create new combinations of problems—for example, global proxy mode can mask a rule issue, while separate DNS settings can hide differences between browsers. Restoring doesn't mean factory-resetting the device; it means undoing the settings you explicitly added during this troubleshooting session. On a managed device, don't reset network policies yourself; ask an administrator to review proposed changes first.

After recovery, verify the task and account status

First repeat the action that originally failed, then check the other tasks you rely on. For a connection issue, confirm that the actual website or app works. For a background issue, repeat the lock-and-resume test. For a subscription issue, confirm the new configuration is selected. For a routing issue, check that the target request matches the expected rule. Then remove temporary test configurations and keep any useful notes. If switching routes only restored service temporarily, say so in the ticket; that doesn't mean the original cause has been identified.

VPNRQ offers a 14-day no-questions-asked refund. See the Terms of Service for details. Submit billing, order and refund questions through a support ticket in the user dashboard; don't post payment details publicly. To choose a data tier, see plan pricing. To set up your configuration again, return to the getting started guide. Troubleshooting is complete when the task works, changes are understood and the account status is clear—not merely when an error message disappears.