Troubleshooting · Connections & Routes

Can't connect at all: start with your local network

First, identify where the process stops

A connection failure can happen when you open the client, load a configuration, start the proxy, connect to an exit route or access the destination service. Each stage calls for different checks. Note the last step that worked: Does the client launch normally? Can you see the route list? Does an error appear as soon as you connect, or does it stay on “Connecting” without a result? If the configuration hasn't loaded, check the subscription section. If the client says it's connected but websites won't load, go to Websites and DNS instead of switching settings back and forth between the two issues.

Then disconnect the proxy and visit a website that normally works without it. If that also fails, check that your device is actually online, whether the Wi-Fi network requires a sign-in page, and whether your router has internet access. Public Wi-Fi may show as connected before authentication is complete; a proxy can't complete that sign-in for you. Meet the network's requirements, then return to the client. Don't use an international website as your only test of local connectivity—it may not be suitable for a direct-connection check.

Narrow it down with cross-checks

Once your local network is working, keep your current configuration and test another route from the dashboard. Then, on the same device, try a different network. If only one route fails while others work, the issue is more likely with that route or the path between your network and that route. If every route fails on your current network but works on another, focus on the current network. Don't update the subscription, change modes and switch routes all at once; if that fixes the issue, you won't know which change helped.

If you have another supported device at home, compare it on the same network. If that device works, focus on the original device's client permissions, system proxy and network extensions. If all devices fail, check your account status and route availability. Use configurations suited to each device; don't copy an entire desktop configuration folder to a mobile device. VPNGR supports Windows / macOS / iOS / Android / Linux. Find the relevant option on the client downloads page.

Check permissions, conflicts and system time

The first time you start a proxy, your system may ask permission to create a network connection or enable a network extension. If you previously denied it, check the relevant permission in system settings, then return to the client and try again. Check whether another proxy, security networking client or corporate networking tool is also handling traffic. You can temporarily quit other networking tools to compare, while keeping your existing settings; don't uninstall corporate management software or disable system protections. Ask your administrator about restrictions on managed devices.

An incorrect system clock can also cause encrypted connections or certificate checks to fail. Set the date, time and time zone correctly, then try again. If the log reports insufficient permissions, a configuration parse error or an unreachable address, keep the full message—don't copy just the last word. For certificate errors, first check the clock and network authentication status. Don't disable certificate checks: it won't identify the cause and will weaken connection security.

When to stop retrying

If your local network works, your account status is confirmed, the client has the necessary permissions, and the same error persists across different routes and networks, submit a support ticket. Include the stage where the error occurs, your operating system, the name shown in the client, the route name and the results of your cross-checks. There's no need to keep clicking Connect or repeatedly reset all network settings. A reset can erase useful clues and affect other network apps.

Connected but websites won't load: check the proxy and DNS

Connection status and request routing are different things

When the client says it's connected, that usually means the connection or proxy service has started. It doesn't prove every browser request is using it as expected. First try a website that normally works directly and the site you're having trouble with, then compare with another browser. If only one browser fails, check for its own proxy settings, network extensions or secure DNS. If no apps can access the web but direct sites work when the proxy is disconnected, check whether the client is handling system traffic and whether its current configuration is valid.

System proxy settings, in-app proxy settings and virtual network adapter modes handle traffic differently. One app may use the system proxy while another ignores it; virtual network adapter modes also rely on system permissions and routing. Check which mode the client has enabled, then see whether the connection log shows the relevant domain when you visit the site. If there's no entry, check whether the request reached the client. If there's an entry marked direct, check the rules. If it reached the proxy but failed, check DNS and the route.

Separate DNS lookup from the connection that follows

DNS translates domain names into addresses. A failed lookup, an unexpected result and a timeout after a successful lookup can all look like a website is down, but they happen at different stages. If your browser says it can't find the server, use a system tool to look up the domain. If it reports a timeout or a reset connection, also check the route to the destination. A successful system lookup doesn't prove the client's DNS is working: the client may use a different resolver, and the browser may bypass the system resolver.

nslookup example.com

This command helps check whether the system can return a lookup result. For troubleshooting, replace the domain with the public website you're having trouble with. Don't enter a subscription link or account information. Record which network you used, whether the proxy was on, and the complete error message. Don't treat one resolver's address as the only correct answer to use permanently; websites may return different addresses depending on your region and network. Visiting a resolved IP directly isn't a substitute for testing the domain, since many websites require the correct hostname to match their certificate.

Adjust settings by scope; don't replace everything at once

If system lookups fail, first check whether your local network requires authentication, whether you've set DNS manually, and whether lookups work with the proxy disconnected. If system DNS works but the client log keeps reporting lookup failures, check whether the DNS settings in the subscription configuration loaded successfully. You can also restore the default settings recommended for your client and test again. Don't copy a full DNS configuration from an unknown guide over your existing file; supported fields and how lookup requests are routed depend on the client and mode you're actually using.

If you recently changed DNS settings, note the previous values first. Then clear the relevant cache using the method supported by your system or client, and close and reopen the affected app. Clearing only the system cache may not clear the browser's or app's own cache. If the problem persists, don't keep adding public resolvers one after another; that can send requests along different paths and make regional checks and troubleshooting harder.

Check whether the destination service itself is the issue

If other websites work and only one service returns an error, save the specific error page and distinguish between a maintenance notice, a regional restriction, a sign-in issue and a network timeout. A service may determine your region from account details, browser state and its own rules—not just your current exit route. In your ticket, include the public domain, error text, matched policy and route. Don't upload private page content. To check whether an app is using the proxy, see the App Routing section.

Slow speeds: distinguish bandwidth, responsiveness and use case

Describe what “slow” means in observable terms

A long wait before a page starts loading, buffering during video playback, slow downloads and delayed responses in an interactive app aren't the same problem. A slow first load may involve DNS resolution and connection setup; slow large-file transfers are more likely related to sustained throughput; interactive apps are more sensitive to round-trip time and brief fluctuations. Note exactly what you were doing and what happened before deciding whether to try another region, route type or local Wi-Fi connection. “Everything is slow” isn't enough to diagnose the issue.

Use the service you actually want to access as your test. The same route may take different paths to different websites, and a single speed test can't represent how video, AI tools or downloads will perform. Keep the device, network, destination content and test method the same; pause other high-bandwidth tasks, then switch routes and compare. If you change websites or video quality each time, it's hard to tell whether the route made a difference, even if the experience feels different.

Rule out device load and local network congestion first

Check whether the system is syncing files, downloading updates or backing up in the background. Then see whether other devices on the same network are using the connection. Processor load, storage space and power-saving modes can also affect page rendering and encryption, making it seem as though the network is waiting. If the client log shows ongoing traffic but a page is stuck, compare with another app. If all apps slow down at once, check device load and your local network before changing the subscription.

A strong Wi-Fi signal doesn't rule out interference or router issues. Try moving closer to the access point, or compare with a wired connection if available. If switching local networks fixes the issue, the cause may be somewhere between the original network and the exit route, rather than your account's data allowance. No device limit doesn't mean your local connection has unlimited bandwidth; devices on the same network still share its available resources.

Choose a route type based on how you'll use it

VPNGR offers three route types: IEPL dedicated lines, relay routes and direct routes. These describe how a connection is routed; they don't guarantee a fixed speed ranking for every region or time of day. Direct routes take a more direct path but are still affected by your local carrier and cross-border routing. Relay routes pass through an intermediate node, so performance depends on the connection between the entry and exit points. IEPL dedicated lines also need to be assessed in light of your local connection and destination service. The name alone can't tell you which route will be fastest on your current network.

Compare routes only in regions that meet your destination's requirements; don't switch to an unsuitable region just for a faster response. For regional streaming, check which region the service detects. When using AI tools, follow their regional availability and account rules. See How to choose a route for your use case for tips, and the Locations page for available regions and route types. The dashboard shows the routes currently available to you.

Slow speeds don't necessarily mean you've run out of data

Your data allowance determines how much data you can use; it isn't a speed measurement. Check your plan and remaining data in the dashboard first. If your account is in good standing but performance has dropped, compare your network and routes. Don't treat a plan upgrade as a general fix before you know the cause. For support, include what you were doing, the destination domain, time of day, local network and routes tested. Say whether the initial response was slow or the transfer remained slow; that's more useful than a speed-test screenshot alone.

Peak-time slowdowns and frequent disconnects

Build a timeline before blaming congestion

Performance can vary at different times with the same settings due to local network contention, carrier routing, route load or the destination service. Note when the slowdown starts, how long it lasts and what it affects. Does everything at home slow down, or just one route? Does video buffer, or does the client also keep disconnecting? Describe a “page that stops loading” separately from a “proxy connection that drops” so you can decide whether to check throughput, rules or the network session itself.

During the problem, keep your current configuration and pause local background tasks first. Then compare with another route in the same region. If an alternative in the same region works, compare route types next. If all routes fail on your current network but work on another, focus on the original network. Peak time describes when it happens, not why. Don't compare a daytime test on one device directly with an evening test on another; too many conditions have changed.

Compare routes systematically within the same region and across types

For services that require a specific region, keep the region fixed and switch only between routes available in the dashboard. This reduces interference from regional checks and makes it easier to spot differences in routing. If the service doesn't require a specific region, you can also compare other regions. IEPL dedicated lines, relay routes and direct routes offer different paths, but judge them by whether they complete your current task and remain stable over time—not as guaranteed protection against peak-time slowdowns.

After switching routes, make sure a new request actually starts a new connection. Browser tabs, downloads and chat apps may keep using an existing session; switching successfully in the client doesn't necessarily move every open connection. Close and reopen the affected page, or restart the session using the app's supported method. Before restarting a download, check whether it can resume so you don't lose progress. Don't keep cycling through routes while the connection is still changing.

Check what happened before and after a disconnect

If the client itself shows as disconnected, check whether the device went to sleep, the screen locked, the network changed, Wi-Fi reconnected or the system updated just beforehand. A desktop may pause its network connection when it sleeps after you close the lid. A mobile device may need to reconnect after switching from Wi-Fi to a mobile network. Add these observable events to your timeline. If the disconnect follows the same system event each time, check system settings before changing exit routes again.

If nothing obvious happened, check whether the log reports a connection timeout, remote closure, unreachable network or client restart. A single error may not reveal the root cause, but it can help distinguish a network-path issue from an app lifecycle issue. Keep the context around the error; you don't need to upload a full day's logs. If only one app repeatedly signs you out while others work, the issue may involve its session or account security rules. A sign-out alone doesn't prove the proxy disconnected.

Keep reconnection settings simple

If your client supports automatic reconnection or connecting at startup, enable it if useful—but first make sure the basic connection works. Auto-reconnect can't fix a configuration parse error, an account issue or missing system permissions. Don't run multiple keep-alive services, scheduled route switchers and automatic speed tests at the same time; they may override each other's settings. Run one client by itself first, check whether the symptom still occurs, then decide whether to restore other tools.

If you need support, include when the issue occurred, your local network type, the route name and whether another route in the same region worked. If it happens only after sleep, say whether reconnecting manually after waking fixes it. If it also drops during continuous use, mention whether every app is affected. See the Mobile Background Connections section for power-saving checks. Don't submit a ticket that says only “unstable at peak times” without describing how to reproduce it.

Subscription updates fail or the configuration behaves unexpectedly

First distinguish a failed download from a parse error or an update that didn't take effect

A subscription update can fail while downloading, download successfully but fail to parse, or import successfully while the client continues using the old configuration. Read the error message and check whether the client reports a network error, an authentication issue, an unsupported format or a problem with a particular configuration field. If the displayed update time changes but the expected routes don't appear, check which configuration is selected. Don't judge whether an update succeeded by the route count alone.

Check your account status in the dashboard overview, then get the subscription from the dashboard option designed for your client. When copying it, avoid adding spaces, line breaks or punctuation inserted by a chat app. Don't use the dashboard webpage address as the subscription URL. Clients may support different formats, so match the import method to the configuration format. If you're unsure, follow the quick-start guide rather than guessing between similarly named formats.

Subscription updates have their own network route

A website working doesn't necessarily mean the client can reach the subscription endpoint over the same route. Some clients fetch updates directly; others can use the current proxy, depending on their settings. If an old route has stopped working and the update request must use that route, you can end up in a loop where the subscription can't be refreshed. Check the update method first. If your local network is working, try an appropriate fetch option supported by the client, and record the results before and after.

If you can open the dashboard but subscription downloads keep failing, keep the status or error message shown by the client. Check whether system network permissions, a separate proxy setting or a network sign-in page could be interfering. Don't paste your subscription link into a public converter, checker or search engine. It's account delivery information; being able to open it doesn't make it safe to share. If you need support, describe the error type first and follow the ticket team's instructions.

Keep a recoverable copy when parsing fails

If the error mentions an unknown field, rule format or configuration structure, first confirm that your client supports the format provided by the dashboard. Keep your working configuration and test the import in a separate new profile; don't overwrite your only copy. Custom rules, policy groups or DNS settings may be overwritten during an update or cause an incompatible merge. First test with an unmodified configuration suited to your client, then restore custom settings one at a time.

Content that won't parse isn't necessarily a configuration file. A network sign-in page, error page or access notice may have been saved by the client as subscription content. If the error points to the start of the file or the text is clearly unexpected, check how it was fetched. Don't post the returned content in a public forum; it may contain account details. For support, provide a redacted error line, the format used and how you imported it. You don't need to share the full subscription content.

If routes disappear after an update, check which configuration is selected

After a successful update, the original policy group may revert to its default selection, and you may need to reselect a route you chose manually. Check that the configuration is enabled, the policy group points to an available route, and automatic selection hasn't overridden your manual choice. If multiple configurations are present, distinguish between “a new configuration was downloaded” and “the new configuration is active.” Confirm what's currently in use, then test a public website. Don't repeatedly reimport just because the list looks different.

If your account data or plan status looks wrong, check it in the dashboard rather than repeatedly refreshing the configuration. Monthly subscription data resets each month on the activation date. The price difference for a mid-cycle upgrade is prorated for the remaining days. Data packs remain valid until used and never expire. See the Plans page for billing details. For an update issue, include the client name, configuration format, approximate time of the last successful update, current error and whether you have custom rules. Don't include your password or full subscription link.

One app won't use the proxy

First check whether the request reaches the client

If your browser works but one app doesn't, don't change the entire route setup yet. Open the client's connection log, then trigger a clear network action in the affected app, such as refreshing a public page or loading a list. If the log doesn't change, the app may ignore the system proxy, use its own network settings or not have sent a request. If a matching connection appears, check the matched rule, policy group and actual exit route. Finding where the request stops can prevent unnecessary region switching.

Background preloading, cached pages and offline content can make testing misleading. An old page appearing immediately after a tap doesn't prove the app went online, and closing and reopening it may not start a new connection. Choose an action that clearly makes a network request and watch the log. Don't rely only on a connection indicator near the app icon. Some apps connect to several domains; if the home page works but images or sign-in fail, check the requests those features use separately.

Check rule order and policy groups

In rule mode, rules are usually matched in configuration order. A domain may match a direct-connection rule, an app rule or a broader category rule before a later proxy rule gets a chance to apply. Check the rule actually matched in the log rather than just looking for a relevant-looking rule in the configuration. A policy group's name doesn't reveal the actual exit route: it may point to another group, an automatic selection or a direct connection. Expand it to confirm the final choice.

If the client supports a temporary global proxy mode, you can use it briefly as a comparison. If the same app works in global mode but not in rule mode, focus on rules and routing. If it still fails, check how the app handles networking, regional availability and account status. Restore your usual mode after testing and note the original settings. Global mode isn't a long-term fix for every issue, and it doesn't change how the destination service evaluates your account.

System proxy and virtual network adapter boundaries

An app that ignores the system proxy may need a virtual network adapter or similar traffic-handling option provided by the client. Whether the client supports it and how to enable it depend on the client itself. Before turning it on, check system permissions, keep your existing configuration and watch for conflicts with corporate networks, other proxies or local services. Don't route every port or all local addresses without a reason. Printers, local network shares and development services may need their existing local access paths.

An app's transport method may also be incompatible with the current client configuration. If the log clearly says a transport isn't supported, keep the exact message and check that you're using a compatible configuration. Don't copy unverified protocol parameters from the internet. Don't promise that enabling one mode will cover every app. Follow the network policies for organization-managed software, banking apps and tools with explicit network requirements; don't force changes to how they connect.

Even with a working network connection, a service may still reject a request

AI tools and streaming services use their own rules to evaluate region, account and session. If a request has gone through your selected exit route but the service shows a regional or account notice, follow the service's instructions rather than expanding proxy coverage. For Claude region and environment issues, see Claude route selection tips. For viewing content from Japan, see the guide to Japanese routes. Neither guide guarantees support for every route.

For this kind of support ticket, include the app name, public domain, feature that failed, whether a connection appears in the log, the matched rule and exit route, and how the same service works in a browser. Redact account pages, private sessions and business information first. “The sign-in page opens, but submitting it shows a region notice” is more useful than “This app doesn't work.”

Mobile background disconnects and network switching

First determine whether the connection stopped or the app was suspended

If messages don't arrive while your screen is locked, the system may have suspended the proxy connection, or the destination app's background activity may be restricted. After unlocking, check the client connection status and whether other apps also lost network access. If only one app needs to be reopened to update while the proxy remains connected and the browser works, check that app's background permissions and notification settings first. Not every delayed background message means the route disconnected.

To reproduce the issue, keep the device on the same network. Record the route and mode while the connection works in the foreground, then lock the screen and see whether it recovers. Only after that, compare network switching or power-saving mode. Change one condition at a time to distinguish a screen lock, background restriction or network change. If you take screenshots, include the connection status and error message. Don't record private chats or disable system protections just to wait for a failure.

Android: check background activity and battery management

Android battery management may restrict background processes, and menus vary by device. In system settings, check whether the client is allowed the background activity, network access and notifications it needs. If the app has a specific battery restriction, understand what changing it will do, then adjust it for comparison. Don't copy menu steps from another device or disable battery management for every app just to keep the client running. Limit changes to the app you're troubleshooting.

Some devices may close the client when you clear recent apps; others may keep the system connection active. Check what your device actually does. A missing app card doesn't prove the connection stopped. If the system offers options to keep a connection active or block network access when it drops, understand the effects first. The latter can make the network seem completely unavailable when the proxy fails; that may be the expected result of the setting, not a new route issue. Note the original state before testing.

iOS: check system connection, configuration and network changes

On iOS, check the system connection status separately from the client interface. An app being in the background doesn't mean the system connection has ended; conversely, seeing an icon doesn't prove every request to a destination succeeded. Check whether another network configuration is enabled at the same time, whether you recently switched between Wi-Fi and mobile data, and whether reopening the client shows a permission or configuration notice. Don't repeatedly delete system network configurations to troubleshoot; keep the current state and record changes first.

Get the client and subscription through the dashboard. Non-iOS clients can be accessed after signing in; the iOS option requires an active plan, and subscriptions are available after sign-in. Check access requirements separately from connection problems: a missing download option doesn't mean your device's network is broken, and being unable to connect after installation doesn't tell you whether the option should be visible. If you need to import again, confirm you have a compatible configuration before deleting the only one you can use, especially on an unstable mobile connection.

Re-establish sessions after a network change

When you switch from Wi-Fi to mobile data or move between Wi-Fi access points, an existing connection may not carry over. Wait for the client status to update, then start a new request in the affected app. If the problem occurs only on one Wi-Fi network, check whether it requires sign-in or restricts the relevant connections. If you can't reconnect after switching networks, keep the logs and compare with a manual reconnect. An old page may still show an error because the app hasn't made a fresh request.

Record failures on the first visit after a long sleep separately from disconnects during continuous foreground use. The former is more likely to involve system wake or session recovery; the latter also calls for checks of the local network and route. If the client supports automatic reconnection, enable it once the basic connection works. If the configuration itself is invalid, auto-reconnect will just repeat the same error. Don't add multiple keep-alive tools; they can use more battery and make diagnosis harder.

If troubleshooting disrupts your daily use, restore your previous settings first, then give support a reproducible set of steps. Background policies vary by device, so don't assume one device's results apply to every platform. Check permissions, process status, network changes and reconnection behavior on the device in question.

Devices, account status and support tickets

If you see a device limit warning, first check where it came from

VPNGR has no limit on the number of devices connected at the same time. If you see a device limit warning, check whether it came from the VPNGR dashboard, the client or the third-party app you're using. Streaming, office platforms and other destination services may have their own device and session limits; these aren't the same as VPNGR's policy. Keep the page and exact error text, check whether you've accidentally used another service's configuration, then contact the right provider. You don't need to remove other devices that are working normally.

If the warning clearly appears during the current service's connection process, submit a support ticket to check your account and configuration. Don't assume there's a hidden device limit. No device limit doesn't mean you should share account or subscription details publicly; keep your login credentials and delivery links private. No email address is required: you can create an account with a username and password, so keep those details secure. You can mention your username in a ticket, but never send your password, session credentials or full subscription link.

Check your plan and data; don't mistake an account issue for a route issue

Check your current plan, data and payment status in the dashboard. Monthly plans are ¥9.9/month for 60GB, ¥18/month for 250GB and ¥28/month for 500GB. Data resets monthly on the activation date, and the price difference for a mid-cycle upgrade is prorated for the remaining days. Data packs are ¥158/300GB, ¥358/1000GB and ¥658/3000GB. They remain valid until used and never expire. Account status and local proxy settings are separate; confirm the account status before testing the network route.

If your account status doesn't match what you expected after payment, keep the dashboard order details and payment result, then ask support to check. Don't make repeated payments to try to fix it. Payment methods include Alipay / WeChat Pay / USDT. Follow the dashboard instructions and don't transfer money to a payment destination it hasn't provided. VPNGR offers a 7-day no-questions-asked refund policy; see the refund policy for full terms. For a connection issue and a refund request, explain each separately rather than sending screenshots without a clear question.

Write a report support can pick up and continue

A useful support ticket includes the symptom, environment, action and result. Start with the main issue, then list your operating system and client, local network type, route name, proxy mode and approximate time. Finally, describe the comparisons you've tried—for example, whether another route or network fixed it, and whether other apps work. Mention if the issue began around an update, sleep or configuration change, but don't assume that timing proves causation.

Main symptom: Connected, but the destination website keeps timing out
Impact: Other websites load; the target app has the same problem
Environment: Enter your operating system, client and network type
Current settings: Enter the route name and proxy mode
Time observed: Enter the local date, time and time zone
Tests performed: Describe what changed with another route or network
Error message: Paste the redacted original text
Requested help: Help identify the connection issue

Screenshots should show the error and necessary context, with subscription URLs, account credentials, private payment details and personal content obscured. Share only the relevant time range from logs, and check them for sensitive fields first. If you find that a configuration has been exposed, handle the delivery information through the dashboard or support before updating affected devices. A public post isn't a substitute for sending private logs securely. Don't repost the same unredacted content across multiple channels.

When to contact support directly

Contact support through a dashboard ticket if your account status doesn't match a completed payment, a compatible configuration keeps failing to parse, the same error occurs across routes and networks, or you see a device-limit warning that conflicts with the no-device-limit policy. If you can't access the dashboard, check the Support page for instructions. This page doesn't provide unverified contact details or ask you to share account credentials through public channels.

Whenever possible, add new test results to the original ticket and say whether you've changed any settings. If switching routes temporarily fixed the issue, tell support which route you were using and what the current state is, so you can both work from the same configuration. After troubleshooting, undo any temporary test modes, restore the daily rules you want to keep, and check your usual apps and local network services. Keep a record of the steps that worked so next time you can start from what you've already confirmed instead of changing everything again.