VPN troubleshooting guide

Start with observable symptoms, not assumptions

Effective troubleshooting does not begin with “the route is down” or “the client is broken.” It begins with a repeatable symptom. For example: every route fails to connect; only the current network fails; the connection shows as established but neither the browser nor other apps can access the internet; only one app bypasses the proxy; or the subscription URL opens but the route list will not update. These descriptions point to different areas, including transport, system networking, DNS, routing rules, and subscription parsing. Describe the symptom first so every later change has a clear verification goal.

Keep the current configuration for now instead of deleting the subscription immediately. Confirm that the plan is still valid and that available traffic has not been exhausted, then check whether the client still displays the existing routes. Monthly plan traffic resets each month on the activation date; if the reset is near, use the status shown in the user panel as the source of truth. Traffic packs remain valid permanently until their traffic is used. Check plan rules on the pricing page, while the actual account status should be verified in the panel.

Use comparison tests to locate the boundary

The most useful comparisons usually involve the network, route, client, and device. If the current network cannot connect, try another available network. If one route behaves abnormally, switch to a different region or route type. If one client has trouble, check another supported platform while keeping the subscription intact. If one device is affected, compare it with other devices on the same account. VPNQD allows unlimited simultaneous devices, so a multi-device comparison is not invalidated by a fixed device cap. However, duplicate imports, leftover processes, and system network extensions on the same device can still interfere with one another.

Change only one condition per comparison. If you change the network, route, and client installation at once, you will not know which step fixed the problem even if it disappears. A more reliable record is: “symptom before the change, the single item changed, result after the change.” The result need only distinguish whether you can connect, resolve a domain, open a website, whether only certain services fail, and whether the disconnect can be reproduced. This record also makes later support handling much more efficient.

Keep a recoverable baseline

Before editing rules, replacing DNS, or changing system networking, record the original state. If the client supports configuration export, save a copy. Otherwise note the mode name, current route, and enabled system proxy options. Never paste a real subscription URL into a public forum, screenshot, or shared document. When demonstrating the format, use an obvious fake value, such as:

https://example.com/sub?token=YOUR_TOKEN

After troubleshooting, undo unnecessary temporary changes, especially global proxy mode, debug logging, and routing rules disabled for testing. The final configuration should be understandable, reproducible, and still work after a restart. If it depends on a set of unexplained accidental settings, the problem has probably not been properly isolated.

First distinguish “no routes available” from “route handshake failed”

An empty client, an outdated route list, and an endless wait after clicking Connect are different problems. If the client shows no routes, go to the subscription update section first. If routes are visible but the status immediately returns to disconnected, check for permission, configuration, or authentication errors. If it remains connecting for a long time, the cause is more likely the current network, route reachability, system time, or a leftover process. Do not group all of these symptoms under a server failure; their troubleshooting paths differ.

Sign in to the user panel and confirm that the account and subscription are valid. If you recently changed your username or password, do not enter the panel password into another authentication field in the client. Subscriptions are normally delivered through the panel and do not need to be manually split into unknown parameters. If the panel opens normally but the client subscription has expired, obtain the current subscription from the panel and replace the old content. Do not append parameters to the old URL yourself or process a real subscription through a third-party converter.

Check system network permissions and leftover state

A common issue on Windows and Linux is that the client lacks permission to create a network interface or modify routes. On macOS, iOS, and Android, the first connection may require confirmation for a system network extension or VPN configuration. After permission has been denied, the client may still let you click Connect even though the system cannot establish the tunnel. Open the system network settings and confirm that the relevant configuration exists and is allowed. If multiple old configurations remain, quit related clients first and remove only clearly unused entries to prevent competing network extensions from claiming control.

After a client exits unexpectedly, a background process may still hold the system proxy or virtual interface. Repeatedly clicking Connect will only compound the error. Fully quit the client rather than merely closing its window, then check whether the system proxy still points to a stopped local process before restarting. If the device has just resumed from sleep, disconnect the existing session, wait for system networking to recover, and connect again. Do not repeatedly reset system networking while the client is still running; this can separate the interface state from the system’s actual state.

Compare the current network with other routes

Before enabling the accelerated connection, confirm that the current network can access ordinary websites normally. If the underlying network cannot resolve domains, requires browser-based authentication, or is a restricted guest network, the client will usually be unable to establish a connection. Public networks often require confirmation in a browser first. If that page does not appear, temporarily disable the system proxy and open a normal webpage again so the network can complete its own authentication, then return to the client.

Once the underlying network works, use the server page to learn how IEPL dedicated routes, relays, and direct routes are used, then compare routes of different types or from different regions. If only the current route fails, preserve the error details and switch to another route in the same region. If every route fails, retest on another available network. Opposite results across networks point more strongly to the local network path; identical results across networks call for further checks of client permissions, subscription content, and system time.

When to stop trying locally

If the account is valid, the subscription updates successfully, system permissions are confirmed, and every route fails to connect across different networks, submit a support ticket. Include the platform, client name, actions taken when the issue began, whether all or only some routes are affected, comparison results across networks, and the complete error shown by the client. If logs contain a subscription URL or authentication content, redact the sensitive parts first. Do not write only “cannot connect,” as that does not distinguish network rejection, permission errors, corrupted configuration, and an invalid subscription.

Also mention if the problem occurs only for one system user, one network interface, or after a particular system update. Support can use these boundaries to determine whether to change routes, reissue the subscription, or guide you through removing system leftovers. Without boundary information, the investigation must restart with the most basic questions, which prolongs diagnosis.

A connected status does not mean the complete access path is working

When the client shows Connected, it only confirms that the local client completed the connection process with the selected route. Browser access still depends on system routing, proxy capture, DNS resolution, the destination service’s response, and the app’s own cache. If no websites open after connecting, first determine whether system traffic is actually entering the client. If only domains fail while known network requests can still leave the device, check DNS first. If only certain websites fail, the cause is more likely the destination region, browser state, routing rules, or the destination service’s own policies.

First undo temporary rule changes in the client and return to a recognizable default configuration. Check whether a manual proxy and the client’s virtual network mode are enabled at the same time. When both capture methods overlap, the browser may send requests to a nonexistent local port or create duplicate forwarding. If the client supports both a system proxy and a virtual interface, follow its instructions and test one primary mode rather than enabling both. During verification, also quit other tools that modify the proxy, DNS, or network filtering.

Use a domain-resolution command to isolate DNS issues

The purpose of a command-line test is not complexity; it is to confirm whether the system can resolve a domain to an address. Windows can use its built-in name lookup command, while macOS and Linux can use common lookup tools. Choose a public, stable test domain, and never put a real subscription URL in command history:

nslookup example.com

curl https://example.com

If name lookup fails while the client log repeatedly reports resolution errors, the problem is concentrated in DNS or system networking. If lookup succeeds but the browser fails, continue by checking the browser proxy, extensions, and cache. If both the command line and browser fail but recover when the connection is disabled, compare the route and capture mode. Do not capture only the last line of command output; the complete error type, query target, and resolver used are more useful.

Resolve DNS cache and lookup conflicts

After changing networks, routes, or proxy modes, the system and browser may continue using old resolution results. Fully quit and reopen the browser, then use the network refresh method provided by the system to clear stale state. If the client lets you choose between system and client-side resolution, test them separately and keep only one setting at a time. Do not enter multiple custom DNS configurations in the router, system, browser, and client simultaneously; the more layers involved, the harder it is to know where the query actually went.

Some browsers have their own secure DNS feature, which can bypass system settings. If other apps work but only the browser has domain-resolution problems, temporarily let the browser follow system settings for comparison. Decide whether to restore independent browser resolution after testing. Enterprise networks and managed devices may also enforce proxy and certificate policies; have the device administrator verify these instead of deleting managed configuration to work around them.

Do not reset all networking when only one website fails

When one website is affected, first use the same route to access other services, then try another browser or a private window to rule out old cookies, cache, and extensions. Next check whether the domain is marked for direct access, proxying, or incorrect blocking by the rules. If switching to a route near the destination region restores access, adjust the route choice instead of reinstalling the client. Related regions and route types are listed in the server directory.

If the same destination service fails across different devices, networks, and routes, support may need to check the route side. Include the destination domain, route name in use, whether similar websites open, the domain lookup result, and the browser error page in your ticket. Do not send a full-page screenshot while omitting the address bar, and do not expose account credentials or a real subscription URL.

First identify where the slowdown occurs

“Slow” can mean slow connection setup, slow initial page loads, slow sustained downloads, video buffering, high interaction latency, or unstable speeds. Slow initial loads often relate to DNS, connection setup, or the destination’s response. Slow sustained transfers are more closely tied to local network quality, route congestion, or destination-side limits. Sluggish interaction is more affected by distance, routing, and jitter. Different symptoms require different comparisons; a single speed test cannot represent the experience of every app.

Before testing, stop ongoing sync, backup, download, and update tasks, and confirm that no other device on the same network is continuously using the uplink. Record the baseline without a connection, then test the selected route on the same device, network, and destination. If the underlying network is already unstable, a cross-border route cannot fix local wireless interference or upstream broadband congestion. See How to test VPN speed for testing methods; consistent conditions matter more than chasing a one-time peak.

Compare time periods during peak hours, not just route names

Peak-hour buffering often appears as normal daytime performance followed by instability during periods of concentrated use. Keep the same route and repeat the same operation at different times, then compare different route types during the same period. This helps distinguish destination-service fluctuations, congestion at the current network exit, and route-path changes. If you switch through many routes while buffering, a brief recovery may only mean that the destination connection was re-established; it does not prove that the last route is better over time.

IEPL dedicated routes, relays, and direct routes have different path structures. A route name is not a speed guarantee and cannot be ranked independently of your location and destination. A nearby region is often a useful starting point, but the exit location also matters when the content is hosted elsewhere. Build a set of routes for your own use: interactive stability matters for websites and AI Tools, sustained throughput matters for long transfers, and Streaming also depends on content region. Do not make one route handle every scenario.

Check the protocol, capture mode, and device load

Insufficient device performance, power-saving modes, background security scans, and virtual-interface conflicts can all reduce throughput. On mobile devices, low-battery policies may restrict background networking. On desktop devices, virtual machines, containers, and other network-filtering programs add processing layers. Close unrelated high-load tasks and watch for abnormal client resource usage. If only one older device is slow while the same route works normally elsewhere, focus on that device and its system environment.

When the client offers multiple capture modes, use its recommended default as the baseline. Global mode is not inherently faster, and rule mode is not necessarily slower; the difference depends on whether requests are classified correctly. If a speed-test tool connects directly in rule mode, its result does not represent the route. You can temporarily use global mode to confirm that test traffic is passing through the route, then restore normal rules so local services and traffic that does not need acceleration are not routed through the proxy.

Do not mistake traffic status for a speed problem

Monthly plan traffic resets each month on the activation date. The plans are ¥9.9/month with 60GB, ¥18/month with 250GB, and ¥28/month with 500GB. If the panel shows an unusual traffic status, check the current billing period first instead of repeatedly changing routes. Traffic packs are ¥158/300GB, ¥358/1000GB, and ¥658/3000GB; they remain valid until used and never expire. When upgrading mid-cycle, the difference is prorated by the remaining days, so the account display may change.

Once the account is confirmed to be normal, if multiple routes on different devices all show the same buffering during the same network period and improve clearly after switching networks, contact the current network provider or inspect the local routing environment first. If the issue is identical across networks and concentrated in a particular region or route type, send support the route name, destination service, scenario, and comparison results. Do not put your guess of “insufficient bandwidth” in the ticket; a reproducible symptom is more useful than a conclusion.

Distinguish route loss, network switching, and app sleep

Frequent disconnects can occur at different layers. If the client clearly shows that the connection has dropped, the tunnel itself was not maintained. If the client still shows Connected but app requests stop, system routing, DNS, or the app’s network state may be abnormal. If the drop occurs only after the device locks, background-activity limits are more likely. If it occurs when switching from Wi-Fi to a mobile network, it is a reconnection issue after an underlying network change. Recording the action that preceded the drop is more useful than writing “disconnects occasionally.”

Observe whether the disconnect coincides with sleep, screen lock, a network switch, low-power mode, the client moving to the background, or a router redial. If it always follows the same action, inspect that system policy directly. If there is no fixed action, compare different routes and networks. Do not enable automatic route switching before judging route stability, because automatic behavior can hide what actually changed. During troubleshooting, keep one route fixed and disable unnecessary automatic selection.

Handling mobile background restrictions

Both iOS and Android manage background network activity, but the exact locations and names vary by system interface. In system settings, confirm that the client is allowed to maintain the VPN configuration and required background activity, and check whether low-power or battery-saving policies impose extra restrictions. Android devices may also have separate manufacturer power management for background apps; add the client to the allowed continuous-running list instead of disabling the entire system’s power management.

A disconnect immediately after screen lock and one that occurs after the device has been idle for a while are different clues. The former usually relates to system policy or a network switch; the latter may also come from router leases, Wi-Fi sleep, or failed route keepalive. Test on the same network: run in the foreground, lock the screen and test again, then switch networks and retest. Establish a fresh connection before each test and confirm that a webpage opens so a previous failure does not carry into the next round.

Desktop sleep and network-interface recovery

When Windows, macOS, and Linux resume from sleep, the physical network interface, DNS, and virtual interface may recover in different orders. The client may still show a connection marker even though the original tunnel is unusable. Disconnect and reconnect deliberately instead of stacking a new system proxy on top. If the issue recurs after every sleep, check whether the client has a reconnect-on-network-change option and ensure that no other network tool is competing for the default route.

Frequent switching between wired, wireless, and other networks can leave old routes behind temporarily. Fully quitting and reopening the client is usually more effective than repeatedly clicking Connect. If a system restart is required, save the client log and state the boundary clearly: “quitting the client did not help; restarting restored it.” This suggests a system network extension or leftover process may be involved, rather than only one route.

When to submit disconnect logs

When a disconnect can be reproduced consistently and screen lock, power saving, network switching, and other proxy tools have been ruled out, submit a support ticket. State the platform, network type, route name, action in progress before the disconnect, whether the client status changed, whether reconnecting restored service, and whether other routes behave the same. Logs should cover the period before and after the drop, but must not expose a real subscription URL, username, or authentication content.

If the problem occurs only in the mobile background, include a written description of background permissions and power-saving policies. If it occurs only after resuming from sleep, say whether fully quitting the client helped. Support needs the trigger and comparison, not hours of unfiltered logs. The clearer the boundary, the easier it is to determine whether the issue involves the system lifecycle, current network, or route keepalive.

First identify where the subscription update fails

Subscription problems commonly appear as content that cannot be retrieved, content that downloads but fails to parse, a successful update with no routes, or routes with abnormal names or groups. Retrieval failures point more toward the account, network, or an invalid URL. Parsing failures may come from client incompatibility, incomplete copying, or stale cache. An empty result after updating calls for checks of account status and client filters. Abnormal grouping may indicate old and new subscriptions have been combined. Preserve the error message first; do not delete all configuration immediately.

Open the subscription delivery section in the user panel again and confirm that the current account is usable. VPNQD registration requires no email address; a username and password are enough, so confirm that you are signing in with the original username rather than treating other details as the account identifier. After obtaining a new subscription, replace the old URL in full. Do not manually extract part of it or give the real URL to a third-party page. Obtain the client and subscription through the panel; marketing pages do not provide static installers or public subscription URLs.

Rule out copying, caching, and duplicate imports

A subscription URL may contain characters that are sensitive to copy integrity. When it passes through chat apps, rich-text editors, or note apps with automatic line wrapping, it may be truncated, split with spaces, or have symbols rewritten. The safest method is to copy directly from the panel and paste it into the client’s subscription field. When showing the format, use only a fake value:

subscription:
  name: VPNQD-example
  url: https://example.com/sub?token=YOUR_TOKEN
  update: manual

If the client already contains several subscriptions with similar names, first identify which configuration is currently in use. Duplicate imports can create duplicate route names, mixed rule sources, or updates to the wrong entry. Disable the old subscription first, then import the current one. After confirming that the new entry works, delete copies that are clearly no longer used. Do not clear client data and system network configuration at the same time when the contents are uncertain; that can turn a subscription issue into a connection issue.

Determine whether retrieval or client parsing failed

If the client says it cannot download the subscription, first confirm that ordinary webpages open and compare the result with the connection disabled and enabled. In some cases, an old proxy state affects the client’s own requests. Fully quit the client, clear leftover system proxy state, reopen it, and try the update again. If the panel also fails to open in a browser, address the current network first. If the browser opens the panel normally but the client still cannot retrieve the subscription, record the client error and check its network permissions.

If the subscription content can be retrieved but parsing fails, do not manually edit content delivered by the service. Confirm that you are using the client entry point or supported import method provided by the panel. Different clients support different fields, groups, and rules; forcing one format into another client can produce an empty list. Return to the panel and select the retrieval method for the relevant platform instead of guessing what the fields mean locally.

Update succeeds, but new routes are still missing

After a successful update, the client may still display a cached old group. Switch to the new subscription entry, confirm the source of the current configuration, and reload it. If region, protocol, or keyword filters are set, check whether they are hiding every route. VPNQD offers 120+ countries and 180+ routes, but the client interface may show different content depending on groups, filters, and the current subscription status. Do not conclude that the subscription is empty based on one collapsed group.

If the subscription still will not update after retrieving it again, replacing the old URL, and removing filters, submit a ticket. Include the platform, client name, full error text, whether the panel opens, whether the subscription failed to download or parse, whether an old subscription remains, and the URL structure with fake values masking the real content. Support does not need the real subscription content. If a new delivery is required, it should be handled only through the user panel or a controlled ticket process.

First confirm that the problem is specific to the app

When the browser and other apps work but one app cannot access the network, do not replace the entire subscription first. Check how the app behaves with the connection disabled, then whether enabling it changes anything. If the behavior is identical, the app may not be captured by the client. If it becomes abnormal after enabling the connection, it may match the wrong rule or be incompatible with the current network mode. If some features work while others fail, the app may use different domains, an independent network component, or multiple connection paths.

Some apps follow the system proxy, some establish connections directly, and others distribute content, login, and update requests across different domains. With only a system proxy configured, apps that ignore system proxy settings may continue to connect directly. A virtual network mode usually captures more traffic, but it is still affected by routing rules and system permissions. Troubleshooting should focus on whether the request entered the client, not merely whether the client shows Connected.

Use temporary global mode to verify capture scope

If the client supports rule mode and global mode, temporarily switch to global mode for comparison. If the app recovers in global mode, the route itself is broadly usable and the issue is concentrated in rule matching. If it still fails in global mode, check the app protocol, route region, system capture method, or the app’s own state. Restore normal rules after testing so local requests that do not need cross-border routes are not continuously sent through the proxy.

Before editing rules, inspect the client’s connection records or rule-match information. Once you identify the domains the app accesses, determine whether they are marked direct, proxy, or blocked. Do not write an overly broad wildcard rule based only on the app’s brand name; login, content delivery, and update domains may belong to different services. A safer approach is to start with the failed request, adjust only the necessary domains, and restart the app to verify after each change.

Check in-app proxy settings and cache

Some desktop apps have their own proxy settings. Running an in-app proxy and the system proxy simultaneously can create duplicate forwarding. If the app still contains an old local address, it may send requests to a process that has stopped. First test with the app following system settings, then decide whether a separate configuration is needed. Do not paste a subscription URL into the app’s proxy address field; a subscription and a local proxy port are different kinds of information.

An app may cache its region, lookup results, or login session at first launch. After switching routes, old connections may remain on the original path. Fully quit and reopen the app instead of merely closing its main window. If a browser private window works while the app still fails, clear only the app’s removable network cache or sign in again, but do not delete all user data first. For work files or local projects, confirm synchronization and backup status before clearing anything.

Special protocols and managed environments

Some real-time communications, games, enterprise software, and system services use connection methods that differ from ordinary web traffic and may not follow an application-layer proxy. Use the client’s recommended system capture method first and confirm that the system network extension works normally. Security policies, certificates, and network filtering on enterprise devices may also limit app connections; do not delete management policies to address this. Ask the device administrator which network methods are permitted.

When contacting support about this type of issue, state the app name, the specific feature that fails, whether the browser works, the global-versus-rule-mode comparison, the route used, and whether fully quitting the app changed anything. If the client shows rule matches, attach the relevant redacted records. Do not write only “this app does not work,” because failed login, content loading, file transfer, and real-time connections require different diagnostic paths.

Unlimited devices does not mean device environments cannot interfere

VPNQD allows unlimited simultaneous devices, so a connection issue should not first be treated as a fixed device-limit problem. Unlimited devices only means the service does not impose a fixed cap on simultaneous devices; it does not mean multiple clients, virtual interfaces, or duplicate system proxies can run on one device without interference. When multiple clients compete for the default route, common symptoms include a Connect button that keeps changing state, webpages that work intermittently, inconsistent DNS paths, and failure to reconnect after sleep.

Keep one clearly designated primary client and current subscription on each device. When comparing clients, fully quit the original before launching another for testing; do not let multiple clients capture system networking at once. For household sharing, see VPN recommendations for multiple devices and device limits. The key points are to protect account details, keep each device’s configuration distinct, and avoid posting a real subscription URL in a public group.

Determine whether the issue is account-wide or device-specific

If the same account works on other devices and only one device is affected, the problem is usually concentrated in that device’s client, permissions, network interface, or local configuration. If all devices fail to update the subscription at the same time, check the account and current network first. If the result remains the same across different networks, submit a ticket. If every device on one household network is affected but works elsewhere, focus on the router, DNS, and upstream network rather than reinstalling each client.

When a router provides the whole-house network, endpoint devices may pass through both router acceleration and a local client, creating duplicate paths. Choose one method for testing: disable the endpoint client and verify the router path, or bypass the relevant router rules and verify the client separately. See Router VPN setups and their boundaries for the trade-offs of whole-home configurations. Do not change the router and every endpoint at the same time without a clear plan; otherwise you cannot tell which layer contains the fault.

Organize reproducible evidence before submitting a ticket

A useful ticket should include the symptom, environment, trigger, comparison results, and error evidence. State clearly whether the issue is failure to connect, no access after connecting, unstable speeds, a subscription failure, or an app-specific problem. The environment includes Windows, macOS, iOS, Android, or Linux and the client name. Triggers may include screen lock, network switching, resuming from sleep, updating the subscription, or changing routes. Comparison results should say whether other routes, networks, and devices behave the same.

Error evidence can be complete error text, a redacted log, or a screenshot with context. Keep the client status, route name, and error area visible while masking the username, password, real subscription URL, and authentication content. Do not crop out the error title or submit an unexplained image. If the issue involves a destination website or app, name the destination, failed feature, and whether similar services work, but do not provide unnecessary personal information.

When to contact support directly

Contact support directly when the account status and panel display disagree, every supported platform fails to retrieve the subscription, all routes fail to connect across different networks, several routes in the same region show the same persistent problem, or the client returns an authentication error that local settings cannot resolve. Payment and refund issues should also be handled through a controlled support ticket. VPNQD supports Alipay, WeChat Pay, and USDT, and offers a 30-day no-questions-asked refund. Specific requests and order status are subject to the account and applicable terms.

If the issue comes from an unclear sequence of steps, return to the Guides section to review the flow for registration, plan selection, obtaining a subscription, and importing it into the client. Registration requires no email address; a username and password are sufficient. Obtain the client and subscription through the user panel rather than using installers or subscription converters from unknown sources. To retrieve the client again, open the panel download area.

Wrap-up after troubleshooting

Once the problem is resolved, undo global mode, custom DNS, temporary rules, and debug logging used only for verification, keeping the smallest set of changes that actually worked. Restart the client and perform one normal-use test to confirm it still works after a system restart, network switch, or app relaunch. Recording the final cause and remedy can prevent starting from scratch next time.

If the problem disappears temporarily but the cause remains unclear, keep the trigger and comparison records instead of calling it solved. A reliable conclusion should identify whether the fault lies in the account, subscription, client, system permissions, network environment, route, DNS, routing rules, or destination service. Systematic troubleshooting is not about changing more settings; it is about getting a repeatable result with fewer changes.