VPN Troubleshooting Guide

Connection layer · From your local network to the remote route

Can't connect at all? First separate network issues from client issues

Establish a clear baseline

“Can’t connect” could mean the client won’t start, the connection toggle fails, a route times out, or simply that a particular website won’t open. These problems call for different fixes. Note the exact message, whether the connection switch stays on, whether a connection indicator appears in the status bar, and whether the error appears immediately or after waiting. Avoid vague reports like “the network is broken”: a permissions error before startup usually points to the local device, while a remote timeout after startup calls for checking the route.

Pause the client and try opening a website that normally works without it. Check whether the system asks you to complete a public network sign-in. If the basic connection isn’t working, resolve that first; a client can’t replace a network connection that hasn’t been established. On hotel, office or guest networks, follow the network’s normal access process rather than repeatedly importing your subscription. Once the basic connection is back, repeat the same test with the client to avoid mistaking an access issue for a route failure.

Check your account and local startup conditions

Open the user dashboard to check your plan, remaining data and subscription details. Make sure the client configuration belongs to your current account. Payment completed, plan activated and client configuration updated are separate steps, so verify each one. Monthly subscription data resets each month on the activation date, not necessarily on the first of the calendar month. Data packs remain valid until used and never expire, but that doesn’t mean data is still available after the pack is used up. Check the dashboard and plans page for details.

If the connection switch won’t stay on, check whether the system has granted VPN permission, whether the client reports that it couldn’t create a network interface, and whether other networking tools are still running in the background. System proxies, tunneling tools and security software can all alter network traffic. Save your work, pause other tools of the same kind, and test with only the current client; don’t leave system security protections disabled as a troubleshooting measure. On managed work devices, ask the administrator what’s permitted rather than forcing changes to system services.

Narrow down the cause with cross-tests

If the client starts normally but can’t connect remotely, keep the network unchanged and try another route in the configuration. Then keep that route selected and switch to another network you’re authorized to use that works normally. The first test checks whether the issue is limited to one route; the second checks whether your current access path is involved. If possible, test the current account configuration on another device as well. Record the route name and result for every test. Don’t change the network, client and route at the same time; if things start working, you won’t know which change helped.

If one route keeps failing but others work on the same network, switch routes to get your work done, then send support the route name and time of failure. If all devices fail on one network but work on another, describe the difference between the networks. If only one device fails, keep records of its local permissions, network interface and client errors. If configuration validation keeps failing, an interface still won’t be created after permission is granted, or multiple routes fail on different networks, stop retrying at random and submit the evidence using the support template at the end of this guide.

Resolution and routing layer · Checks after connecting

Connected but websites won’t load? Check routing rules and DNS

First check whether the problem affects just one app

If the client says it’s connected but your browser can’t open websites, the connection status and actual access results don’t match. That doesn’t mean the entire route is down. Test a regular website and the service you’re trying to use separately. Note whether all pages fail or only one domain, then try the same address in another browser. If only one browser has a problem, check its own proxy, extensions and encrypted DNS first. If all apps are affected, investigate the system proxy, tunnel mode, DNS resolution and default route.

The exact error can also point you in the right direction. A domain that won’t resolve, a connection timeout, a reset connection, an untrusted certificate and restricted account access each suggest a different issue. Never treat “continue anyway” as a routine fix for a certificate warning. Check the system date and time zone, make sure the domain is correct, and look for a network sign-in page or security software interference. Don’t install root certificates from unknown sources to suppress warnings. If the website shows an account or region notice, keep the exact message; don’t confuse a service restriction with a network timeout.

Check whether requests are taking the expected path

A system proxy usually affects only apps that follow that setting. Tunnel mode involves a virtual network interface and routing. Turning on either one doesn’t mean every program sends requests along the same path. Check the client connection log when you open the target website: does the domain appear, which rule matched, and was the connection proxied or direct? If there’s no record, first check whether the request is reaching the client. If it’s marked direct, review the rules. If it’s proxied but fails, check the selected route and remote access result.

Don’t start by changing every DNS setting at once. Resolution can happen in the browser, operating system, client or remote network, and each layer may cache results. If the browser uses its own resolver, the address returned by a system command may differ from the one the browser uses. With address-mapping DNS in the client, the address shown by the system may not be the target server’s real address either. Record the current resolution mode, then check the relevant client logs. An unfamiliar-looking address alone isn’t proof of a DNS leak.

Use lookup commands, but don’t mistake a lookup for access

On desktop systems, you can run the domain lookup below in a terminal. It doesn’t include account information and can show whether the system resolver returns a result. A successful lookup only confirms that this resolution path works; it doesn’t mean the browser uses the same path or that the subsequent encrypted connection succeeds. If the lookup fails, note whether it timed out, was refused or couldn’t find the domain, then compare that with the client logs. Don’t add lookup results directly to permanent routing rules: websites may use dynamic addresses or content delivery networks.

nslookup example.com

After changing DNS settings, reopen the target app to establish a new connection and compare the results. If you need to clear a cache, use the method provided by your system and note what happened before the change. Don’t test a domain issue by opening an HTTPS site at its numeric address; this can affect certificate validation and site selection. If several valid domains fail to resolve on different networks, or the client keeps reporting a resolution loop, send support a redacted log. Check your exit region on the My IP page if useful, but an exit-region change alone doesn’t prove all DNS requests use the same path.

Performance layer · Separate bandwidth, response time and app delays

Slow speeds? First find out what’s slow

Describe the problem in specific terms

A page that takes a long time to start loading, a slow download, video that keeps buffering and choppy audio in a meeting may all feel “slow,” but the causes can differ. Delays before a page starts may relate to DNS, connection setup or the site’s response. Sustained downloads depend more on available throughput. Real-time meetings are sensitive to packet loss and jitter. Note which app you’re using, whether the delay happens on opening or during transfer, and whether it comes with reconnects. Don’t rely on a single result from a speed test.

Pause unnecessary large downloads, cloud sync and system updates on the current device, and check whether other devices on the same network are using bandwidth. Unlimited devices means multiple devices can be online at once; it doesn’t give each one a separate network connection. Home Wi-Fi, routers and your internet provider’s connection are still shared resources. You don’t need to delete other devices’ configurations to test this. Temporarily reduce concurrent activity under controlled conditions, repeat the same task, and see whether performance changes with local load.

Keep the task fixed, then compare routes

Keep the content, device and network the same, and switch only the route for comparison. Re-establish the app connection before testing: a browser, meeting app or download tool may keep using an existing session even after you change a client setting. Fully end the current test and reopen it. If the download source is busy or throttles transfers, speeds may stay similar after switching routes. Try another legitimate, reliable service to check rather than blaming the plan for limits imposed by the source.

Choose a region based on the service you need. A shorter physical distance doesn’t always mean a shorter network path, and remote services may assign different content delivery nodes to different exit regions. Start with a region the service supports, then compare route types within that region. Don’t switch regions repeatedly on an account in active use just to improve a test result; some platforms may require extra verification when a session changes. The servers page explains route categories and coverage, including the differences between IEPL dedicated routes, relay routes and direct routes, but it can’t replace testing on your current network.

Check for device-side limitations

If other devices on the same network work normally, check the current device’s processor load, storage and client background status. Tunnel forwarding, encryption and large numbers of connections all use local resources. Overheating, power-saving modes or busy background tasks can affect network performance. Save the logs, restart the client and repeat the same task. Don’t reinstall the operating system as a first step or install unknown “speed-up” patches. Before changing network interface settings, make sure the client logs point to that issue and note the original values so you can restore them.

If small pages load but large downloads or certain websites consistently stall after transfer begins, note that pattern. It may involve path transport, packet handling or app protocol compatibility. Don’t change the network interface’s maximum transmission unit or disable system networking features without clear evidence. First test a different route and access network. If the issue persists only on one device, give support the client mode, operating system and failed task. For a single affected service, keep its error message and the time you tried to access it.

Aim for a reproducible comparison, such as: “On the same network and with the same file source, one route took noticeably longer to start; switching routes fixed it, and switching back reproduced the issue.” This is more useful than a speed-test screenshot alone. For meeting issues, see choosing a route for remote-work meetings, which focuses on session continuity and packet loss. If the app is working again, record the effective route and original settings; there’s no need to keep changing things just to make every test match.

Time of day and network paths · How to compare peak-hour performance

Peak-hour lag: compare routes at different times

Check whether the slowdown really follows the time of day

“Fine during the day, slow in the evening” is a clue, not proof of route congestion. More devices at home, changes in Wi-Fi conditions, busy internet provider routes and load on the target platform can all contribute. Note the approximate time, access network, route name and type of activity, then repeat the same task at another time. If you’re streaming at a higher resolution or syncing large files in the evening, the test conditions have changed and can’t be directly compared with daytime web browsing.

Don’t compare only the client’s connection test. A probe request is usually much shorter than an actual video, meeting or file transfer; getting a response doesn’t mean there’s enough capacity for sustained traffic. Test the service you actually care about: listen for gaps in meeting audio, watch for repeated pauses in video, or check whether documents save and sync. Keep “got a response” separate from “the service worked,” and don’t assume a brief recovery means the connection will remain stable all evening.

Understand route types and choose based on the issue

IEPL dedicated routes, relay routes and direct routes describe how traffic is routed. They don’t guarantee the same results across all networks and times. Direct routes generally rely more on the path from your access network to the exit. Relay routes forward traffic through an intermediate node. Dedicated routes involve their own link arrangements. Route labels in the client can help you sort the options, but you still need to test them with your current access network and target service. A route label alone can’t guarantee a good experience for meetings, and occasional lag doesn’t mean an entire route type is unusable.

First compare route types within a region required by the service, then compare other regions. Re-establish the app connection after each switch so an old session doesn’t keep using the previous route. If one route type works on your current network and switching back reproduces the lag, record that repeatable difference. If every type is slow but another access network works, focus on the local or access path. Comparing regions may also change the target platform’s content delivery node; call that out in your support ticket.

Treat reducing service load as a temporary fix, separate from long-term settings

For an ongoing meeting or important work, prioritize continuity. Pause background sync, use the app’s adaptive video quality, or switch to a route you’ve verified works. These are temporary recovery steps, not a confirmed diagnosis. Once things are stable, compare routes in a quiet test environment rather than repeatedly toggling the tunnel during important work. Video quality, AI service response times and account permissions can also depend on the platform itself; not every delay is a network issue.

Automatic route selection may not know that your task needs the same region and session throughout. If the client supports automatic policies, find out what triggers a route change. If the issue happens during a switch, temporarily pin a route you’ve tested and see whether continuity improves. Don’t enable scripts you don’t understand or combine several automatic route-selection rules. The easier the current configuration is to explain, the easier it is to tell whether a slowdown came from a route change or the service itself.

Contact support if the same route repeatedly lags at similar times, switching to another route in the same region fixes it, or one route behaves abnormally across different access networks. Include the time, route, type of activity, access network and alternative routes you’ve tried. Avoid vague reports like “peak hours don’t work,” and don’t present one evening’s results as a long-term conclusion. For help comparing plans and usage, see the monthly budget guide. Plan data allowance and diagnosing current congestion are separate questions.

Sessions and system background activity · Record what happens before and after a disconnect

Frequent disconnects and mobile background dropouts

Tell the difference between a dropped tunnel and an app session ending

A meeting ending or a page needing to reload doesn’t necessarily mean the client tunnel disconnected. When a problem occurs, check whether the connection switch and system indicator are still on, then check the client log for reconnects, network changes or a restarted process. If the tunnel stays up but one app session ends, check the app’s timeout, sign-in state and whether the outbound route changed. If the client itself stopped, look first at system background restrictions, why the process exited and local network changes—not the target website’s rules.

Switching Wi-Fi networks, putting a device to sleep and waking it, or changing network access can interrupt an existing connection. Note whether the device was locked, moved out of Wi-Fi coverage, just woken from sleep or switched to another network before the disconnect. Existing real-time sessions may not survive a path change, and a client reconnect doesn’t necessarily restore the app’s old session. Wait for the basic network to stabilize, reconnect the app and note whether reconnecting restores service.

Check background behavior by platform

On Android, system battery saving, background activity restrictions and manufacturer task management can each affect the client. In system app settings, check whether the client is allowed to run in the background and whether a more restrictive battery-saving mode is enabled. Labels vary by device. Change settings only for the client in question; you don’t need to remove restrictions for every app. When testing after locking the screen, also check the client’s activity log rather than relying on whether a notification icon is visible.

On iOS, check the system VPN status, the client’s connection error and whether another configuration is controlling the connection. Don’t treat the regular app background refresh setting as a universal fix for VPN disconnects. On desktop, check system sleep, network adapter power saving and whether the client remains active after you sign out. If the device is organization-managed, ask the administrator about network policies you can’t change yourself. System behavior varies by platform; don’t blindly look for a menu with the same name based on a screenshot from another device.

Compare foreground and background behavior to confirm the cause

Select the same route. First keep the client in the foreground and perform the same task, then test in the background or with the screen locked. If the issue only happens in the background and the logs show the client restarting, investigate system process management first. If it also disconnects in the foreground, background permissions aren’t enough to explain it. Keep the route fixed and switch access networks to see whether the problem follows the network. Don’t change the route and background settings at the same time; you won’t know which change helped, and a temporary improvement in the network could look like a permissions fix.

Automatic reconnect may help restore a connection, but it shouldn’t hide a persistent configuration error. If the client keeps reconnecting, pause large transfers, save recent logs, then use the connection section to check your account and route. Don’t guess at keepalive intervals or connection timeouts; their meaning can vary between protocols and clients. Change these only if you know the original value, why you’re changing it and how to restore it. Repeatedly changing settings without recording results makes it harder to compare tests later.

When reporting a disconnect, say whether the connection switch turned off, the system indicator disappeared, or only the app stopped working. Include whether the screen was locked, the device woke from sleep or changed networks, and what happened after reconnecting. Android users can read background keep-alive and per-app proxy guidance for more on system differences, or follow the Android setup guide for initial setup. If the client crashes, include a redacted error summary; don’t repeatedly trigger a crash during important work just to reproduce it.

Configuration delivery layer · Verify subscription updates and connections separately

Subscription update failed? Check the source, retrieval and parsing

Check each step of the update process

A subscription update involves retrieving the link, requesting the configuration, parsing its contents and activating it. When an update fails, save the exact error message. A network timeout may mean the request didn’t finish. A format error may mean the client can’t read the content it received. An activation failure can happen after the configuration has already been downloaded. An old route list doesn’t prove the update succeeded; the client may be showing the last working configuration. Check that the configuration source, update time and currently active profile match.

Recheck the subscription source in the user dashboard and verify your current account status. Don’t use an old link from a chat, a past screenshot or another account. A subscription URL can provide access to your account configuration, so treat it as private. Check for spaces, line breaks or truncated text when copying, but never post the full URL in a public group to verify it. This guide doesn’t show real subscription URLs. For import instructions, see the setup guide.

Distinguish retrieval failures from incompatible content

If the request times out, first make sure your basic network works. Then check whether the client uses a direct connection or the current proxy to update the subscription. If the existing configuration has stopped working and the update request still depends on that same route, it can get stuck in a loop. Compare the update-path options provided by the client and keep a record of the original setting. Don’t leave all traffic on direct connections as a permanent fix. If the update works on another available network, record that difference so support can distinguish a configuration issue from a request-path issue.

If the client says the format or fields aren’t supported, check that you’re using an import option for a configuration type the client supports. Don’t rename content intended for another client and try to import it, or delete fields you don’t understand just to make the error go away. The client may also report a format error if it received a sign-in page, network authentication page or error message instead of the configuration. Save the error summary rather than assuming the server configuration is damaged. Verify the source and client, then ask support to check compatibility.

Check whether the local configuration actually changed

Some clients can store remote subscriptions, local configurations and overrides at the same time. After updating a remote subscription, a different profile may still be active; a local override may also continue changing DNS, rules or outbound selection. Check which profile is active, then confirm the route name in the connection log comes from the new configuration. Before removing an old profile, save a restorable record of your custom settings. Don’t delete all configurations only to discover you can’t restore your previous setup.

After an update, check the currently selected outbound route again. Configuration changes can invalidate an old selection or make the client fall back to its default policy. Then open the service you need and confirm that requests match the expected rule. Record subscription update success and service access success separately: the first means the configuration was retrieved and accepted; the second means the current connection path works for your task. Keeping these results separate helps support distinguish a configuration retrieval issue from a route connection failure.

If you edited the configuration manually, say what you changed and, after making a backup, retest with the original configuration from the dashboard. Don’t mix custom scripts, third-party conversion services and subscription updates into the same troubleshooting chain; each can change the final configuration. Never submit a private subscription to an unknown conversion website. If you need conversion or support for a specific client, ask support about approved options. Download clients only through the dashboard download page; don’t choose an installer with the same name from search results.

Contact support if the configuration can’t be retrieved on different available networks, an original configuration is consistently rejected by a supported client, or the route list is clearly and repeatedly abnormal after an update. Include the exact error, operating system, client name, import method, whether you use local overrides and results from other networks. Don’t send your account password or reset the subscription as a routine step without keeping a record. If you think the URL has been exposed, check the dashboard for available security options or ask support for help.

App layer · Per-app rules and device warnings

An app won’t use the proxy, or you see a device restriction warning

First check whether the app’s requests reach the client

If a browser works but one app doesn’t, don’t start by switching every route. Keep the client on, restart the app and watch the connection log. If you see the target request, at least some of its traffic is reaching the client. If there’s no record, first check whether the app follows the system proxy and whether it’s excluded from the per-app list. An app may connect to several domains, and its displayed name may not match the domains it actually requests. Searching only for the brand’s main domain doesn’t prove no traffic is present.

Follow the rule-mode path: “process or domain → matched rule → outbound selection → connection result.” If a direct rule matched, check the business rules in the current configuration and any local overrides. If a proxy rule matched but the app still fails, check its error message, route region and account status. System proxy and tunnel mode cover different traffic, but that doesn’t guarantee every app will work in either mode. Office software, device management policies and an app’s own networking behavior can also affect route selection.

Understand how the per-app list works

Per-app settings may offer options like “proxy only selected apps” or “bypass selected apps.” Selecting the same app can have opposite effects depending on the mode. Read the current mode and note the list and original settings before changing only the target app. Apps may use separate services for sign-in, downloads or notifications, so changing the main app alone may not cover all related traffic. Don’t leave broad, untested rules enabled to fix one app, and don’t mistake a work-account restriction for a client rule issue.

If an app uses a different transport protocol, a working website doesn’t prove that the app’s required connection is available. Check the client log to identify the failure rather than switching protocols or disabling system features at random. Streaming and AI services may also show different results depending on account, region, content rights or service policies; network connectivity is only one part of the picture. Keep the exact wording of any account or region notice. Don’t turn “results may vary” into a guarantee that a service will work in a particular region.

Check where a device-limit warning comes from

VPNLiuLiang allows unlimited devices online at the same time. If you see a message like “device limit reached” or “connection limit exceeded,” first identify who displayed it: the VPNLiuLiang dashboard, the client, the operating system or the third-party platform you’re accessing. A third-party platform’s limits on sign-in devices or playback sessions are separate from this service’s simultaneous device policy. Likewise, “connections” in a client can mean network sessions, not the number of devices you can use. Similar wording alone doesn’t tell you what the limit applies to.

If the warning really comes from this service, save a screenshot and the page address, check that you’re signed in to the right account and make sure you haven’t imported an old configuration from another provider. Then contact support. Don’t pay again or create another account to clear the warning; check your existing account first. Accounts use a username and password and don’t require an email address. Support doesn’t need your password for troubleshooting. If a public device retained your sign-in, follow the normal account security steps rather than treating it only as a route issue.

To compare device issues, use the same account, route and network. If the same app shows the same service warning on every device, the platform’s own rules may be involved. If only one device fails, look at its app proxy, routing and system permissions. Confirm that all devices use the same current configuration before comparing; similar route names may not refer to the same setup. Don’t copy a full private configuration into a public document. Record only the necessary names and results.

When reporting an app issue, name the app and say whether the failure happens on launch, sign-in or during use. Include the matched rule and outbound route, and say whether the corresponding website works in a browser. For a device warning, include the page or app that displayed it and the exact message, with account details redacted. New users can find explanations of multiple devices, data and usage in the frequently asked questions. If you haven’t finished importing the configuration, return to the setup guide before changing complex rules.

Evidence and support · Make your support request reproducible

When to contact support: prepare your ticket and recovery notes

Know when to stop troubleshooting on your own

If you’ve checked the basic network, account and current configuration and can still reproduce the issue, submit a support ticket. You don’t need to test every client. This is especially true when the same error occurs on one route across different networks and devices, or an original subscription keeps failing to parse in a supported client. Randomly changing local settings further is unlikely to help. For certificate warnings, suspected account issues or an unknown configuration source, preserve the evidence and stop unnecessary changes rather than increasing the risk just to “make it work.”

If the issue has temporarily cleared, keep using a route that works and organize your notes. Support requests aren’t just for complete connection failures; you can also report a recurring issue on a particular route or at a particular time. Describe reproducible conditions rather than making sweeping claims. “The original route failed, switching fixed it, and switching back caused the issue again” is more useful than “all routes are bad.” You can report an issue even if it doesn’t reproduce now; just separate what you observed at the time from what you suspect afterward.

Describe what happened in chronological order

Start with when it happened and what you were doing. Then include your device and operating system, client name, current mode, selected route and exact error message. List the tests you’ve tried and the result of each. Include the time zone, and copy the route name exactly as it appears in the client. Report the client version as shown in your device settings; don’t guess. Don’t send a long recording and expect support to find the error, or combine incidents from different dates and networks in one unordered description.

Logs only need to cover the issue and related steps. Long, full logs are harder to troubleshoot and may expose unrelated browsing activity. Before exporting, check for subscription URLs, access tokens, QR codes, account details and other personal information. Check screenshots for the address bar and notifications too. Cover entire sensitive fields rather than blurring only a few characters. Keep the original logs on your device, send support only the minimum necessary excerpts, and don’t paste them in public comments.

Use official support channels and separate technical issues from billing questions

Contact support through the dashboard support ticket or the support page. There’s no need to look for private contact details that aren’t listed. If you can’t access your account, save the error and steps you took, then use the available process shown on the page. Describe technical and billing issues separately: technical support needs route, network and log details, while billing questions need the relevant order information from the dashboard. Don’t post full payment records publicly.

To check plan details: monthly subscriptions include 60GB for ¥9.9/month, 250GB for ¥18/month and 500GB for ¥28/month. Data resets monthly on the activation date; mid-cycle upgrades are prorated based on the remaining days. Data packs are 300GB for ¥158, 1000GB for ¥358 and 3000GB for ¥658; they remain valid until used and never expire. Payment methods: Alipay / WeChat Pay / USDT. Check the pricing page for the full terms. Don’t infer extra billing periods, speed benefits or compensation from troubleshooting results.

This service offers a 30-day money-back guarantee. See the refund policy for how to apply and the terms of service for usage rules. You can ask about refunds and route diagnostics separately; there’s no need to make system changes you don’t understand just to ask for a refund. If support requests more tests, first confirm what they’re intended to check, record your original settings and repeat under the same conditions. If your device is organization-managed or you can’t switch networks, say so rather than reporting tests you haven’t done.

Once the issue is resolved, record the settings that worked, the route you kept and any temporary changes you reverted. Restore the simplest configuration needed for normal use. Delete sensitive attachment copies exported only for troubleshooting, and make sure no test proxy, temporary rule or extra networking tool is still running in the background. If the same symptoms return, use these notes to compare rather than reinstalling everything. This guide isn’t about assigning blame for every issue; it’s about separating observations, hypotheses and verified results so troubleshooting can move forward.