VPN Troubleshooting Guide

Establish a diagnostic baseline first

Break “not working” into verifiable symptoms

“Cannot connect,” “very slow,” and “one app does not work” describe outcomes, not where the fault is. Before starting, write down the status shown by the client, which network you were using, which websites or apps were affected, whether switching routes changed anything, and whether the same device can access ordinary websites normally when disconnected. If the client remains stuck on Connecting, the issue is usually related to the handshake, protocol, or network entry point. If it says Connected but domains will not open, DNS, the system proxy, or routing rules are more likely. If only video buffering or file transfers are slow, check route quality, the target service, and the local link.

Also distinguish between “everything fails” and “one target fails.” For the former, check the connection state, system proxy, default route, and DNS first. For the latter, check whether the app follows the system proxy, whether the target service restricts the current exit region, and whether a rule has incorrectly sent the domain direct. If only one device is affected while the same subscription works elsewhere, the issue is usually that device’s client configuration, permissions, or network stack—not a reason to change plans immediately.

Preserve evidence before cleaning anything up

Do not start by deleting the client, clearing its configuration, or resetting the system network. A full cleanup removes logs, error messages, and configuration details you could compare, leaving you to guess. A safer order is to capture the client status page and error message, note the current route name and protocol, export a diagnostic log with credentials removed, and make a copy of the current configuration. Then test switching routes, restarting the client, or refreshing the subscription.

If logs contain a subscription URL, access token, username, or other authentication details, redact them before submission. Support usually needs the error type, time, platform, client status, route name, and reproduction steps—not full credentials. Use an obvious fake value for example subscription URLs, such as:

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

Build a comparison with the smallest possible change

Keep the device and network environment unchanged while testing, and replace only one route first. If nothing changes, keep the route and switch only the protocol; change the network environment after that. If you change the route, protocol, client, and network all at once, even a recovery will not tell you what worked. The next time the same issue occurs, you will still have to start over. The minimal-change approach may seem slower, but it substantially reduces repeated work.

If the issue can be reproduced reliably, record the full sequence, such as “Start the client, select a route, click Connect, the client shows Connected, and the browser fails to open the test domain.” This is far more useful than “It has not worked all day.” If the issue is intermittent, record the network changes, sleep/wake events, client background state, and route switches before and after it occurs. This helps determine whether the problem is tied to the system lifecycle.

Troubleshooting order for complete disconnection

Confirm the basic network and system time first

When the client cannot establish a connection at all, disconnect first and use a browser to visit a website you normally use. If ordinary websites also fail, restore the local network before doing anything else; repeatedly switching VPNHG routes will not change the result. A Wi-Fi connection showing Connected does not necessarily mean you have a usable internet exit, and public networks may require confirmation in a browser. Complete the network’s own access process before starting the client.

A significantly incorrect system clock can also cause encrypted handshakes to fail. Certificate checks and some protocols depend on the current time. A device that has been powered off for a long time, an incorrect time zone, or an unsynchronized clock can all look like an immediate connection failure. Restore automatic date, time, and time-zone management, then fully quit and reopen the client. “Fully quit” means confirming that the tray icon, menu-bar item, or background process has ended—not merely closing the window.

Cross-test routes and protocols

Once the basic network is working, read the nodes page to understand when to use IEPL dedicated routes, relay routes, and direct routes, then cross-test different regions and route types. If only one route fails while others connect, the issue is more likely limited to that route or entry point. If every route fails on one device but works elsewhere, return to that device and check client permissions, the system proxy, and network extensions.

Protocol changes should also follow the one-variable principle. Keep the route fixed and switch among Shadowsocks, VMess, Trojan, and Hysteria2 supported by the client. Note whether the failure is an “immediate error” or a “timeout after waiting.” Immediate failures commonly indicate that the configuration was not loaded, permission was denied, or protocol parameters do not match. A timeout is more consistent with an unreachable network path, a restricted entry point, or a handshake with no response. Do not judge speed by the protocol name; a stable connection on the current network matters more.

Check client permissions and conflicting processes

Desktop systems commonly require a virtual network interface, system proxy changes, or route-table updates. If permission approval was skipped on first launch, the client interface may open normally while the connection action cannot affect system traffic. Check system settings to confirm that network extensions, virtual interfaces, and background permissions are allowed. On managed devices, policy may restrict network configuration; the client may not be able to fix this itself, so the device administrator may need to adjust the policy.

Running multiple proxy, filtering, packet-capture, or network-acceleration tools on the same device can make them compete for the system proxy port, virtual interface, or default route. During troubleshooting, fully quit other network tools and run only one client. If the issue clears, re-enable the other tools one at a time to identify the conflict. Minimizing a window usually does not stop its background service; check the system tray, menu bar, and task manager.

When to stop troubleshooting locally

When the same failure appears across multiple network environments, regions, and protocols while the basic network works, open a support ticket. Include the platform, client name, error text, route name, protocol, time, and cross-tests already completed. If other devices work, explicitly state “the same account connects on other platforms.” This lets support narrow the issue directly to the endpoint configuration. Do not submit authentication credentials or leave the full subscription URL visible in screenshots.

Connected, but websites will not open

Separate connection, routing, and DNS status

When the client shows “Connected,” it only means the connection flow completed; it does not guarantee that browser traffic is entering the tunnel. Web access also depends on the system proxy, default route, DNS resolution, and the browser’s own settings. First try a regular site by domain, then use a command to check whether the domain resolves. If resolution fails, focus on DNS. If it resolves but access fails, check routing, the system proxy, and the target site.

A browser may also use its own proxy, extensions, or secure DNS, causing it to ignore the system configuration. The clearest comparison is to test with a browser that has no network extensions installed. If the new browser works, the connection and system network are broadly fine; the issue is in the original browser’s extension, proxy, or cache. If every browser fails, continue at the system layer.

Use system commands to confirm that DNS works

The purpose of the command is not to measure speed, but to see whether the domain resolves. Replace the example domain with the one you cannot access, but never paste a URL containing authentication parameters into a public record.

nslookup example.com

ipconfig /flushdns

curl -I https://example.com

If nslookup returns a domain result but the browser still fails, DNS has completed basic resolution, so continue with the system proxy and target connection. If the lookup times out, disconnect the client and run it again for comparison. If it works when disconnected but fails when connected, the client’s DNS mode, virtual interface, or rules usually need adjustment. If both states fail, handle the local network or system resolver first.

Clearing the DNS cache only removes old resolution results; it will not fix an incorrect route or an unavailable route. After clearing it, reopen the browser or fully quit the affected app because the process may keep its own cache. Do not run cleanup commands repeatedly and mistake a coincidental recovery for the root cause. Record the resolution results before and after the cleanup.

Check the system proxy and virtual interface

In system-proxy mode, browsers usually read the operating system’s proxy settings. If the client has exited but the proxy address remains, every webpage can fail because no process is listening on the proxy port. Reopen the client and use its Disconnect or Restore system proxy action to clean up the setting instead of manually deleting an unfamiliar network interface. Confirm that ordinary websites work after restoration, then reconnect.

Virtual-interface mode takes over traffic through the routing table. Common problems occur after waking from sleep, switching from Wi-Fi to Ethernet, or another network program rewriting the default route while the old interface remains. Disconnect, wait for the system network to recover, and reconnect. If that does not help, fully quit and restart the client. Only after preserving the logs should you consider the system’s network reset, because it may also remove other network settings.

Branch handling for DNS issues

If a domain resolves differently on different routes, do not manually pin an unknown address. The target service may use dynamic routing; fixing an old address can appear to work briefly and then fail again. A safer approach is to restore the normal client and system resolution path, then use route switching to verify that the exit region meets the target service’s requirements.

If DNS results are normal but the page remains stuck connecting, test another target site at the same time. If several unrelated sites fail, continue checking routing and the proxy. If only one site fails, check whether it requires an exit region or whether the current routing rules are sending it to an unsuitable route. Do not reinstall the entire client because a single target is failing.

Slow speeds and peak-time lag

First identify whether the bottleneck is local, at the entry point, or at the exit

Speed is determined by the weakest segment of the entire path: the device-to-router link, local network, route entry point, cross-border link, exit region, or target service. One peak speed test cannot show stability. A more useful approach is to keep the device, target, and test method the same while comparing disconnected, current-route, and alternate-region results. Observe what changes in initial page load, sustained downloads, video buffering, and interactive latency.

If the disconnected connection is already unstable, address the Wi-Fi signal, router load, or local network first. Move closer to the access point, pause large background sync jobs, or compare with a wired connection to eliminate local variables. If the local network is fine but every distant route is slow while a nearby region is stable, the issue may relate to path distance and the current network entry. If only one route slows down, try another route type in the same region first.

Choose routes by use case, not by a single peak result

IEPL dedicated routes, relay routes, and direct routes use different paths. For stable interaction, video playback, or long-lived connections, prioritize consistency, disconnects, and buffering rather than the route with the highest single speed test. A direct path is more straightforward but depends more on the current network environment; a relay can change the entry path; an IEPL dedicated route suits scenarios with higher stability requirements. See the node list for currently available routes.

Regional distance also affects interactive performance. When the target service is located in a particular region, a nearby exit usually reduces unnecessary detours. If the service provides different content by exit region, regional requirements matter too. For streaming issues, see Streaming access notes; for AI Tools connection issues, see AI acceleration notes. Those articles cover service-specific differences; this chapter focuses only on general path diagnosis.

Recognize the signs of peak-time congestion

Peak-time lag usually means the same device and route degrade consistently during a particular period and recover at other times. Confirm this by using the same test conditions at different times; do not compare different devices, Wi-Fi positions, or targets. If nearby-region routes decline together but improve after switching to another entry point or route type, adjust the path first. If every network activity slows, including ordinary access while disconnected, the bottleneck is more likely the local connection.

For video playback, do not check only whether it starts. Observe startup time, repeated quality drops, whether playback resumes after seeking, and whether buffering recovers after pausing. For file transfers, check whether the sustained rate remains stable. For interactive apps, watch response time and whether long-lived connections drop. Treating every scenario as simply “slow” can hide the real bottleneck.

Reduce interference outside the client

System updates, cloud sync, media backups, and high-volume tasks on other devices all use the local exit. VPNHG supports unlimited simultaneously connected devices, but “unlimited devices” does not mean other devices on the shared network cannot consume bandwidth. Pause known high-volume tasks during testing and confirm that the router is not applying rules that change traffic priority. If only one app is slow, check whether it uses its own download servers or limits background transfers.

Protocol settings can also affect performance on a particular network, but do not switch them randomly. Keep the route fixed, test each protocol offered by the client, and record which connects faster and remains more stable on that network. If the difference appears only on one network, the protocol and path may be interacting differently there. If every environment slows down in the same way, continue checking the route and target service.

When opening a ticket about speed, specify the device platform, basic network type, route name, protocol, affected activity, time period, and comparison after switching routes. Do not attach only one speed-test screenshot; it cannot show the test target, target region, background traffic, or sustained stability. The more complete the reproduction steps, the easier it is to determine whether the entry point, route, or endpoint configuration needs adjustment.

Frequent disconnects and mobile background drops

Distinguish route interruptions from system-initiated suspension

Frequent disconnects usually have one of two causes: the connection path really breaks, or the operating system pauses the client when the screen locks, the device sleeps, or the network changes. The former can happen even while the app is in the foreground and may change after switching routes or protocols. The latter often appears after the screen turns off, power saving begins, the app moves to the background, or Wi-Fi changes. Recording what happened before the disconnect is more useful than recording only its time.

If a desktop device cannot recover after waking from sleep, first confirm that the basic network has reconnected, then disconnect and reconnect VPNHG. The system needs time to restore networking, and an early client attempt may retain a failed interface or old route. If it happens after every wake, preserve the client logs and check whether the system allows the client to keep running in the background after login.

On mobile, check background activity and battery settings first

Mobile operating systems manage apps based on battery level, temperature, background activity, and network changes. After the client moves to the background, it may be suspended while the interface still shows its last connection state even though the tunnel has failed. Allow background activity in system settings, keep the client out of strict battery-saving or sleep lists, and confirm that another network app has not replaced the system VPN configuration.

When switching between Wi-Fi and a mobile network, the device’s exit changes and the old connection usually needs to be rebuilt. If the client remains stuck in the old state, return to it, disconnect, and reconnect. Do not click Connect repeatedly before the network stabilizes; this creates multiple retries and makes logs harder to read. If one network type drops frequently, test the same route and protocol separately to determine whether that entry point triggers the issue.

On desktop, check sleep behavior, virtual interfaces, and conflicting software

Windows and macOS may retain old proxy or route states after sleep, fast user switching, or a network-interface change. Quit every program that modifies network settings and leave only the VPNHG client running. Then restart the client and reproduce the sleep or network-switch action. If the problem disappears, restore the other programs one at a time. This distinguishes a client recovery failure from multiple tools competing for control of the system network.

On Linux, preserve the virtual-interface, route, and service logs. Desktop network-management services may rewrite the default route when an interface changes, and the local firewall may load a different rule set after the network zone changes. Do not watch only the client window; inspect the system network state as well. If a script or service starts the client automatically, confirm that the old process has exited before starting a new one to prevent duplicate instances from competing for ports and interfaces.

Handle seemingly random intermittent disconnects

Intermittent issues most often lead to repeated retries because there is not enough evidence. Record whether the device changed networks, entered sleep, started a high-volume task, or whether the client switched routes automatically before the disconnect. Also note whether ordinary networking remained available afterward. If ordinary networking failed too, address the local network first. If it stayed normal while the tunnel failed, compare other routes and protocols.

Do not mistake automatic reconnection for a solved problem. It may restore access, but if disconnects continue, identify the trigger. For live meetings, remote terminals, and sustained transfers, even a short reconnection interrupts the session. Choosing a more stable route type, closing conflicting tools, allowing background activity, and preventing sleep during the task are usually more effective than increasing the retry rate.

Subscription update failed

First confirm that you received a subscription endpoint, not webpage content

Import the subscription from the download or subscription section of the user panel. Do not treat a marketing-page URL, a browser login page, or a third-party sharing page as the subscription URL. VPNHG provides the client and subscription entry through the user panel; static pages do not contain direct installer links or real subscription URLs. If you have not completed the first import, return to Guides to confirm the retrieval path.

If the client reports an invalid content format, copy the subscription endpoint again from the panel and avoid including leading or trailing spaces, line breaks, or explanatory text. Never paste the real URL into a public webpage or shared screenshot. For document-format testing, use only an obvious fake value:

subscription:
  source: "https://example.com/sub?token=YOUR_TOKEN"
  update: manual

If opening the URL in a browser returns a login page, error page, or ordinary HTML, the client cannot parse it as subscription content. Check the account login state, retrieval endpoint, and import method supported by the client instead of manually editing the response.

Distinguish retrieval, parsing, and application failures

A subscription update has several stages: the client sends a request, the service returns subscription content, the client parses the nodes, and the client writes the new configuration into the active configuration set. Retrieval failures often appear as network errors, timeouts, or invalid authentication. Parsing failures usually show format, field, or configuration errors. An application failure may report a successful update while the list does not change, or the new configuration is not selected as current.

Record the exact error text first. For a retrieval failure, switch the basic network and confirm that the user panel opens normally. For a parsing failure, copy the endpoint again from the panel and use an import method supported by the client. For an application failure, check which configuration set is active and confirm that the updated configuration was not overwritten by an old one. Do not assume that “the node list did not change” means the service returned no data.

Check cached results, old configurations, and duplicate configuration sets

Some clients cache subscription results or retain multiple configurations with the same name. If old routes still appear after an update, confirm which configuration set is active and compare its source instead of deleting everything. Temporarily disable the old configuration and import again so you retain a fallback. Once the new configuration works, remove only the old entries you have confirmed are unnecessary.

Automatic update tasks can fail while the device is asleep, the client is not running, or the network is unavailable. Open the client manually and run one update to distinguish a scheduled-task problem from a subscription-endpoint problem. On mobile, background restrictions may prevent automatic updates; as with background connection drops, check how the system manages the client’s background activity.

Check account status and the traffic period

If a subscription suddenly stops updating, check the plan status and traffic information in the user panel. Monthly subscription traffic resets each month on the activation date; an upgrade made mid-cycle converts the price difference into remaining days. Traffic packages last until used and never expire. Do not infer the reset date from the calendar month or try repeated imports to change the account state. The order and subscription status shown in the panel are the basis for troubleshooting.

VPNHG registration does not require an email address; a username and password are enough. When opening an account-related ticket, provide the username, a screenshot of the order-status page, and the time of the error—not the password. If the client reports an authentication failure while the panel still opens normally, include the subscription-update error text. If the panel is also inaccessible, first verify the username and password records.

If multiple clients return the same error for the same subscription while the plan status in the panel is normal, stop repeatedly deleting configurations and open a ticket. State which platforms you tested, whether retrieval succeeded, and whether the response was a network or parsing error. If only one client fails, export that client’s logs first and compare it with another supported platform.

An app does not use the proxy

First confirm whether the app follows the system proxy

If a browser works but one app does not, the route is often not the problem—the app may simply ignore the system proxy. Some apps open direct connections, use their own network stack, or read proxy settings only at launch. After connecting VPNHG, fully quit and reopen the affected app so it retrieves the current system network state. Closing the window alone may leave a background process using the old connection.

If the client offers system-proxy and virtual-interface modes, switch modes for comparison while keeping the current route. System-proxy mode suits apps that follow the operating system proxy. Virtual-interface mode usually covers more traffic from apps that ignore system proxy settings, but depends more on system permissions, routing, and DNS. After switching, verify an ordinary website first, then test the target app so a new system issue is not mistaken for an app issue.

Check what the routing rules actually matched

Rule mode uses domains, addresses, or app processes to decide between direct and proxied traffic. A target service may use multiple domains: sending its main page through the proxy does not mean its login, media, API, and file domains use the same path. If the client provides connection logs or rule-match records, watch for new requests while opening the target app and confirm which rule handles each related domain.

Rules generally match from more specific conditions to broader ones. If a custom rule is placed incorrectly, an earlier general direct rule may match first. Export the current configuration before editing so you can roll back. After editing, fully restart the app and clear its saved connection state. Do not send all traffic through one path indefinitely when you do not understand a domain’s purpose; solve the clearly identified target first.

When the browser works but a desktop app does not

A desktop app may have its own proxy settings. If it contains an old address, old port, or Direct setting, it may override the system configuration. Check the app’s network options and prefer Follow system or a setting that matches the current client mode. If you previously entered a proxy address manually, record the original value, then restore automatic or system mode for testing.

An app update may also replace its network component, causing an old process-name rule to stop matching. Domain rules are usually easier to verify than rules based only on process names. If a process rule is necessary, use system task information to identify the process actually making the network request rather than relying on the app window name. Helper, updater, and main processes may establish separate connections.

Handle mobile apps and embedded webpages

Mobile apps often combine native APIs, embedded webpages, and media requests. If the login page opens but content does not load, different requests may be following different rules, or the exit region may not meet the target service’s requirements. First choose a regional route that matches the target service, then inspect the domains in the rule log. If changing regions restores access, record the working region. If every region fails in the same way, check the app version, cache, and system DNS.

When an app resumes from the background, it may continue using the long-lived connection from before the disconnect. If the interface keeps loading after returning to the foreground, fully terminate and reopen the app. Mobile background restrictions may also pause the VPN client, so confirm that the system VPN is still active before blaming the target app.

Fix with the smallest rule instead of expanding the takeover scope

When troubleshooting a rule, start with the target app’s specific domain or process. A rule that is too broad can also change the path for local services that should remain direct, creating new login, regional, or speed problems. Add only one explainable category of condition at a time and record its purpose after it works. If the target service changes domains later, you will know exactly which rule to update.

If the same issue occurs in the app across every supported platform while its website works in a browser, also consider the target service’s app API policy. Include the specific failure screen, error text, and exit region rather than simply saying “the app does not work.” Support can use this to check access from the route side, but cannot infer the actual requests from the app name alone.

Device alerts, account checks, and support tickets

When a device-count alert appears, first identify its source

VPNHG supports unlimited simultaneously connected devices. If a client displays “too many devices,” “session limit,” or a similar message, do not assume it is a VPNHG plan restriction. Confirm whether the message comes from the VPNHG user panel, the site’s client, the operating system, or another app. Third-party clients may impose their own limits on local configurations, synced accounts, or connection sessions; their messages do not necessarily indicate a server-side device limit.

Also check whether multiple client instances were started or an old process is keeping a connection in the background. Duplicate instances on one device can compete for ports, the system proxy, and the virtual interface, creating errors that appear related to device count. Fully quit the client, end leftover processes, and start only one instance before testing again. If the message remains, preserve the full error text and where it appeared.

Verify the username, plan, and order status

Start account troubleshooting in the user panel. VPNHG does not require an email address; a username and password are enough to register, so use the actual username when recovering or verifying the account. In the panel, check whether the plan is active, the subscription endpoint is visible, traffic information is normal, and the order is complete. Payment methods include Alipay, WeChat Pay, and USDT. If the order status does not match the actual payment process, include the order-page details in a ticket instead of creating duplicate orders that are hard to distinguish.

Monthly subscriptions include ¥9.9/month with 60GB, ¥18/month with 250GB, and ¥28/month with 500GB. Traffic resets monthly on the activation date, and a mid-cycle upgrade converts the price difference into remaining days. Traffic packages include ¥158/300GB, ¥358/1000GB, and ¥658/3000GB; they last until used and never expire. When troubleshooting traffic or billing periods, first confirm whether you purchased a monthly subscription or a traffic package. Do not apply monthly reset logic to a traffic package. See the plans page for the complete rules.

When to open a support ticket directly

Open a ticket when cross-testing still cannot locate the cause, or when the issue involves an order, account status, subscription response, or multiple routes failing at once. For technical issues, include the platform, client, route, protocol, network environment, exact error text, time, and reproduction steps. For account issues, include the username, order status, and what the panel shows. List each route, protocol, or device comparison you completed so support does not ask you to repeat the same tests.

Do not continue random retries when multiple network environments cannot connect, multiple clients cannot parse the same subscription, the panel status conflicts with the client’s authentication result, the same fault is reproducible and logs have been preserved, or an order is complete but the panel has not updated. Deleting configurations at this point may destroy useful evidence; structured information is more effective.

What to include in a support ticket

Issue type: connection / website access / speed / disconnect / subscription / app routing
Device platform:
Client:
Route name:
Protocol:
Network environment:
Time of occurrence:
Exact error text:
Reproduction steps:
Tests completed:
Comparison result:

Screenshots should show the error message and client status, but redact passwords, full subscription URLs, access tokens, and other authentication details. Logs may include the connection process before and after the error; there is no need to upload unrelated history. If a file contains sensitive fields, make a copy and redact that copy instead of editing the only original log and losing context.

How to describe intermittent and performance issues

Intermittent issues need a timeline: what the device was doing beforehand, whether the network changed, whether it slept, whether ordinary networking failed too, and whether automatic reconnection succeeded. For performance issues, specify the affected activity, route region, route type, time period, and comparison route. “It is very slow” alone cannot distinguish local Wi-Fi, the cross-border path, the target service, and background tasks.

If only one website or app is affected, provide the target name, error page, browser-versus-app comparison, selected exit region, and rule-match result. For regional content differences in Streaming, do not submit only the title; state the platform, selected region, and client status. For an AI Tools connection issue, state whether the web and app versions behave the same way and whether switching routes changes the result.

Regression checks after recovery

After recovery, repeat the original reproduction steps instead of confirming only that the current page opens. For connection issues, test disconnecting and reconnecting. For DNS issues, resolve the original target domain again. For disconnects, reproduce the screen-lock, sleep, or network-switch action. For subscription issues, confirm that the new configuration is actually active after updating. For app-routing issues, restart the app and verify the relevant function.

If the fix depends on a custom rule, a particular protocol, or a route type, record the working configuration and its applicable scenario. This makes recovery faster after a system update, client reinstall, or subscription re-import. Keep a copy of the default configuration as well, so you can compare it with the modified state when a new problem appears and avoid long-term interactions between accumulated changes.

The goal of troubleshooting is not to recover temporarily after “trying a few more times,” but to identify which layer failed, which action changed the result, and whether the service side needs further checking. Preserve a baseline, run one-variable comparisons, and submit a complete ticket as described here to reduce repeated communication and reuse the conclusion when the same issue appears again.