VPN Troubleshooting Guide

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

Tell a network outage from a route connection failure

Being unable to connect can have several causes. The client may not open, show any routes after launch, report an error when you select a route, or show a connection while apps remain unresponsive. These are different stages. Note the last step that worked instead of grouping everything under “the network is down.” Disconnect in the client and open a website you normally visit directly to confirm your local connection works. If direct access also fails, check Wi-Fi sign-in, your router, or network access before repeatedly updating your subscription.

Some public networks require you to complete a sign-in page in your browser first. You may see a normal network icon but only be able to open the sign-in page. Complete the network’s legitimate access steps before starting the client. Don’t ignore browser certificate warnings to get connected, and never enter your VPNWailian password on an unfamiliar sign-in page. If switching to another trusted network resolves the issue, the original network environment may be involved; that’s a clue, not proof that a particular network device is faulty.

Check your account, configuration, and system permissions

Open your account overview in the user panel and check your plan status and remaining data. Being able to sign in confirms that account authentication works; it doesn’t mean the routes in your subscription are available. Back in the client, make sure you’ve enabled the subscription you just imported, not an empty or outdated configuration saved earlier. If the route list is empty, go to the subscription update section. If routes are listed but won’t connect, check connection permissions and logs.

The first time a system asks to add a VPN configuration, enable a network extension, or create a virtual network interface, approve it as prompted. If you dismiss the authorization dialog, the client may still show a start button even though the system connection was never established. Start the connection again from the client and check system settings for any pending approval. Company-managed devices may restrict network extensions; if you see a management policy message, contact your device administrator. Don’t remove management settings or disable security features required by your organization.

Check whether another VPN, proxy tool, or network filter is also handling connections. Disconnect and properly quit those apps, leaving only the client you’re testing. Closing a window may not stop its background service. Don’t delete system network services or disable security software in bulk; compare results before and after quitting the conflicting app. Keep the system date and time accurate, too: an incorrect clock can affect certificate checks and some authentication flows. Turning off certificate validation is not a fix.

Narrow down the cause with controlled comparisons

On the same network and client configuration, try a route in a different region or of a different type, then visit the same destination. Next, keep the route unchanged and switch to another trusted network. If only one route fails, note its name and check its type in the route list. If every route fails only on this device, check device permissions, system proxy settings, and leftover network configurations first. A route working on another device only shows that conditions differ; it doesn’t rule out a configuration issue.

Don’t treat timeouts, connection refusals, authentication failures, and certificate errors in logs as the same problem. A timeout means a response didn’t arrive in time and may involve the network path; an authentication failure points you back to your subscription or account; a permission error calls for checking system authorization. Keep the exact error text, not just a screenshot of a red icon. If the same error occurs on multiple trusted networks, permissions are in place, and the configuration is up to date, stop reinstalling and send support the relevant log excerpt, reproduction steps, and comparison results. That’s more useful than “nothing works.”

Connected, but websites won’t load: check DNS and your exit route

A connected status doesn’t mean a website has loaded

A successful status in the client usually means one part of the connection is established. A website still needs to resolve its domain, connect to the destination, verify its certificate, and receive content. A failure at any step can leave a blank page or an endless loading indicator. Try a website you can normally open directly and a destination that needs an international route. Note whether everything fails, only some domains fail, or text loads while images don’t. These differences help separate general network issues from routing rules and destination-side problems.

If your browser shows a specific error page, save the exact wording. A domain not found, connection timeout, reset connection, and certificate date error each call for a different response. If the destination shows a sign-in restriction, regional availability notice, or access-denied page, it has returned an application-level response; this isn’t simply a case of “the website won’t load.” Check the destination service’s account requirements, regional availability, and selected exit route instead of repeatedly changing local DNS at random.

Check whether the failure is at the DNS lookup stage

DNS translates domain names into network addresses. The system, browser, and client may each use a different resolution path, so one browser working while another fails may mean they’re using different settings. First check whether the client logged a DNS error, then see if your browser has its own Secure DNS setting enabled. Don’t point it to an unfamiliar DNS server or change system and browser settings at the same time. Note the original values, then follow the client’s guidance to restore compatible settings.

If you’re comfortable with the command line, use the command below to check whether the current environment can resolve a domain. The example domain is for troubleshooting only; it doesn’t test access to a particular streaming service or AI tool. A successful command means this lookup got a response, not that your browser used the same resolution path or that the destination website can connect. If the client uses internal address mapping or handles DNS itself, interpret the result according to the client’s documentation. The address format alone can’t confirm a leak.

nslookup example.com

On Linux systems using systemd-resolved, you can check the current resolver information. If the command isn’t available, your system doesn’t provide that tool; there’s no need to install it just for troubleshooting. A missing command isn’t a network failure. The output may include private network addresses and names, so include only relevant details if you contact support.

resolvectl status

Check settings for your platform; don’t reset the whole network

Caching can also make a change appear to have no effect. After switching exit routes, your browser may reuse an old connection, and an app may retain regional information. Properly quit and reopen the destination app first; if needed, compare in a separate browser session instead of immediately clearing all browsing data. Clearing site data signs you out, so make sure you can access your account before doing so. Entering a website’s IP address instead of its domain isn’t a universal test: modern websites often rely on domains and certificates, so failure by IP alone doesn’t prove the route is faulty.

If only one destination fails while other pages work, keep the failed domain, exact error, selected region, and relevant client logs. If lookups for all domains fail but work again when you disconnect the client, tell support how DNS is handled and which platform you use. Don’t upload your full DNS history; a few carefully selected examples are enough. If the destination itself is under maintenance or your account is restricted, address that first before assessing whether to change international routes.

Slow speeds and peak-hour lag: choose a route for the task

First, describe what feels slow

A slow first page load, video buffering, slow downloads, and choppy calls aren’t the same metric. Pages also depend on DNS and connection setup; video depends on sustained throughput and the platform’s bitrate settings; calls are more sensitive to latency variation and packet loss. Pick one destination and one action, such as opening the same video or joining the same test call, then compare before and after switching routes. A single speed test result can’t explain everything happening in a real app.

First rule out other tasks using your local bandwidth. Cloud-drive sync, system updates, and file uploads can compete with the app you’re testing, especially when uploads are busy. Pause nonessential tasks you control and repeat the same action. Weak Wi-Fi, a hot device, and a busy router can also affect results. If possible, compare using a more stable local connection. Don’t attribute every change to the international route when your local link is clearly unstable.

Compare like for like during peak hours; don’t assume the cause

To assess peak-hour lag, note whether you used the same device, network, destination, and route during the day and evening. If those conditions changed, the comparison won’t tell you much. Congestion on one path at busy times doesn’t mean every region is affected equally; the destination service’s load may also change. Keep the region the same and try a different route type, or keep the route type similar and change regions. This helps narrow down whether the issue is closer to the entry point, international path, or destination.

IEPL dedicated lines, relay routes, and direct connections use different path arrangements, but the name alone doesn’t guarantee a particular experience. Choose based on what you need and how the connection performs now, rather than assuming one type will always be fastest. For AI tools, check the service’s regional requirements and session stability; for streaming, check catalog region, playback stability, and account requirements; for remote work, pay attention to call audio, video, and collaboration responsiveness. See all available regions in the route list and route type guide.

Separate app restrictions from plan data allowances

A plan’s data allowance isn’t a speed guarantee for every website. Monthly subscription data resets each month on the activation date. Data add-ons don’t expire and remain available until used. Choose a billing option based on your usage patterns, not as a substitute for troubleshooting. Check your available data and account status in the account overview, then visit the plans page to find an allowance that suits you. Changing your data tier won’t explain or fix a destination’s regional restrictions or local Wi-Fi interference.

Streaming quality can also depend on adaptive bitrate, device capability, display settings, and your platform plan. Don’t conclude that a route lacks bandwidth based only on the player’s indicator. Read Netflix picture quality and route selection, then distinguish between playback failing to start, buffering during playback, and lower picture quality. For calls, see choosing a route for remote work and look at packet loss and latency variation rather than chasing a single download speed result.

When reporting peak-hour issues, include roughly when they started and recovered, the network you used, route name, destination service, and the specific action you took. Compare it with an alternative route under the same conditions. Don’t just say “slow at night,” and don’t run repeated speed tests just to gather evidence. If different parts of a service behave differently—for example, text works but attachments are slow—describe each separately. This helps narrow down domain routing, the source-side path, or app-specific restrictions.

Frequent disconnects: distinguish the tunnel from the session

First, identify what actually disconnected

“Disconnected” could mean the system VPN status disappeared, the client still shows connected but traffic stopped, a website asked you to sign in again, or a call ended. Check the system status first, then the client event log, and finally the message from the destination app. If the system connection stayed up but one account session expired, focus on the destination service’s sign-in state and changes to your exit route. If the system status also disappeared, look at the client process, system sleep, network changes, or underlying connection.

Don’t assume there was no problem just because auto-reconnect restored a “connected” status. Event logs may show the earlier drop and reconnection. Save the relevant entries as soon as the issue occurs, before testing another route. Repeated reconnects can overwrite useful information and make the destination app see frequent network changes. Properly quit the client and app, then reconnect for a controlled retest. Repeatedly force-quitting processes adds extra variables and shouldn’t be a routine troubleshooting step.

Check for network changes, sleep, and local conflicts

When a device switches between Wi-Fi and mobile data, wakes from sleep, or leaves Wi-Fi coverage, the underlying connection may need to be re-established. First observe what happens on a stable network while the device stays awake, then test screen lock or a network switch separately. If the issue only occurs after waking, note the order in which the system resumed, the client reconnected, and the destination app recovered. Don’t describe an issue that only happens after a network change as “it disconnects all the time”—the trigger is a useful clue.

On desktop, check system power settings, Wi-Fi adapter power saving, and whether the client’s background process is being stopped. On mobile, check battery restrictions and background permissions; see the section below for details. Company-managed devices may also block non-organization connections under management policies. If you see a clear notice, ask your administrator. For security software, look for block logs or network component conflicts, but don’t leave protection disabled to keep the connection up or turn off every filter at once.

Multiple network tools running at the same time may take turns changing system proxy, routing, or DNS settings. The connection may not drop right away; access might fail later and return briefly after a restart. Properly quit other tools, then check the current system proxy and VPN status. If things stabilize after quitting an app, note the app-client combination anyway. One successful retest doesn’t prove the issue is permanently fixed. Ask your device administrator to check any remaining network components if needed.

What to do when only a specific route or app is affected

Keep the device and network the same, switch routes, and repeat the same task. If the system connection drops only on the original route, send support a comparison with the alternative. If every route drops after the same action, focus on the app, device, and network environment. If file transfers stop while browsing still works, check the source session and upload limits. If a call ends but browsing still works, note the meeting app’s own error instead of clearing all network settings.

Changing your exit region can affect sign-in sessions, especially when a destination service checks account context. Don’t keep switching regions to test speed during a call, form submission, or file upload. Save your work, then compare routes when idle. If a destination asks you to verify your account again, follow its normal process. Don’t mistake its security check for a VPNWailian account problem, and never include the destination service’s password or verification details in a support ticket.

A brief incident log can capture the sequence: what you were doing before it happened, whether the device locked or switched networks, whether the client still showed connected, whether other websites worked, and what came back after reconnecting manually. Use your local time and include the time zone to avoid confusion. If the issue reproduces reliably, there’s no need to keep interrupting your work to gather more examples; send the clearest one.

Subscription update failed: check the source and status

Importing, updating, and connecting are separate steps

A subscription update fetches configuration; connecting uses the routes in that configuration. A failed update doesn’t necessarily make existing routes stop working immediately, and working routes don’t prove the subscription URL is still valid. Check whether the client reports a failure while downloading, reading, or enabling the configuration. A timeout, authentication error, and parsing failure each need a different response. Keep the exact error text and confirm that the enabled subscription is the one you meant to update.

Get your subscription only from the user panel, not from an unfamiliar guide, chat screenshot, or forwarded link. The URL may contain account access credentials, so protect it like a password. Don’t paste it into public speed-test sites, online conversion tools, or public forums, and don’t put the full URL in a ticket subject. If you think it may have been exposed, check whether the panel offers a reset option. If you’re unsure, contact support through a ticket rather than sharing the URL further.

Check how you copied it and which network you used to update

When copying the URL again, check for extra spaces, line breaks, surrounding instructions, and characters changed automatically by the browser. Don’t guess missing parts or use a sample URL as your own subscription. Some clients can detect a subscription on the clipboard; others require you to select an import type. Use the normal import option for your client. If the content is treated as plain text instead of configuration, check how you imported it rather than editing subscription fields at random.

The update request itself needs a working network. If the client relies on a failed route to reach the update URL, you may end up in a loop. Save your current configuration and, if possible, try the update over a normal direct connection, then compare with another trusted network. If the network requires browser sign-in, complete that first. A failed update alone doesn’t mean your account is restricted. Check whether the panel opens and whether the same error occurs on different networks.

If the download succeeds but the content can’t be parsed, the format may not be compatible with your client. Confirm that you’re using the subscription link provided by the user panel, and check whether it offers different import options for your platform. Don’t add undocumented fields or send the configuration to an external service for conversion. You can keep the old configuration as a fallback, but be clear about which one is enabled so you don’t confuse “updated the subscription” with “still using the old configuration.”

Check your plan status; don’t guess reset dates from the calendar

Use the status shown in the panel as the source of truth. Monthly subscription data resets each month on the activation date; it doesn’t necessarily refresh at the start of a new calendar month. If you upgrade mid-cycle, the price difference is converted into remaining days; that doesn’t mean all billing details start over. Data add-ons remain available until used and don’t expire. If routes stop working after an update, check your allowance and plan status before investigating the configuration. See the full plans page for pricing, data, and billing details; don’t rely on an old screenshot to determine your current benefits.

If the panel shows a normal status but the client keeps reporting authentication errors, note the last successful update, the action that failed, and the client’s error. You don’t need to publish your full subscription to prove there’s a problem. If logs include request URLs, redact query parameters, credentials in the path, and account identifiers. If support needs more information, provide only the requested, relevant details through a panel ticket.

Reinstalling the client isn’t the first thing to try when an update fails. It may delete old configurations, logs, and split-tunneling settings, making the issue harder to reproduce. First record your settings without including sensitive data, and confirm you can sign in and retrieve your subscription before considering a fresh import. Don’t clear every subscription just to experiment unless there’s clear evidence the configuration is damaged. If updates fail on different networks despite a normal panel status and correct import method, contact support so they can check the configuration delivery process.

One app won’t use the proxy: check split-tunneling rules

A working browser doesn’t mean every app uses the same route

System proxy settings, in-app proxy settings, and virtual network interfaces handle traffic differently. A browser may follow the system proxy while some desktop apps, terminal tools, or background services use their own network settings. First check whether only one app is affected or all destinations that need international routes fail. Note the client’s current mode, whether the app is included in the split-tunneling list, and whether the system has established a VPN connection. A working browser doesn’t prove that every process should work automatically.

Check your client’s documentation to understand what its rule mode, global mode, and app-routing options actually do. Global mode can be useful for a brief comparison, but it isn’t a permanent workaround for every rules issue. Restore your original settings after the test so traffic that should stay local doesn’t use an international route. On a managed device, also check whether the app needs your organization’s network; two connection policies shouldn’t override each other.

Check app lists, domain rules, and rule order

App-routing settings may offer options such as “include selected apps only” or “exclude selected apps.” Seeing an app in a list doesn’t necessarily mean its traffic is being proxied; first check what the list represents. Note the current mode and selections before changing anything, then adjust only the affected app. If the app uses separate background components, a browser sign-in window, or an update process, requests may come from those components rather than the main app.

Domain-based rules can also match only part of a service. Sign-in, images, attachments, and real-time communication may use different domains, so the home page might work while sign-in fails, or text might load while attachments don’t. If the client provides connection logs, check which rules matched the relevant requests while reproducing the issue. Keep only the domains and rule results related to the failure; don’t send your full connection history. If there’s no logging feature, don’t install an unfamiliar capture certificate to gather evidence.

Rule priority and default policies affect where traffic goes. If adding a rule changes nothing, an earlier rule may already match, or the app may be reusing an old connection. Properly quit and reopen the app before testing again. Don’t keep stacking similar rules; it makes future maintenance harder. If you need to change the configuration, save a copy you can restore and use the client’s built-in rule controls where possible. Direct edits to a subscription may be overwritten the next time it updates.

Handle desktop tools and mobile apps separately

Desktop command-line tools may read proxy environment variables or ignore the system proxy entirely. If a command-line tool fails, first check its official network configuration instructions, then compare them with the client’s actual listening settings. Don’t copy a local port from an online guide; your client may use a different one. Internal company addresses and local development services often need a suitable direct route. Understand their purpose before changing anything; a broad rule shouldn’t replace all your network policies.

On mobile, check whether the app is excluded, whether VPN authorization is still in place, and whether the app is restricted in the background. After changing a rule, the app may still be using an old session, so quit and reopen it. If an app fails but the same service works in a browser, the app version, account status, or network protocol may differ. Record the version you’re actually using, but don’t present an unverified version upgrade as a universal fix.

Don’t judge a gaming app based only on website access. Game traffic can use different routes, regions, and protocols from regular web browsing, and a faster download doesn’t necessarily mean more responsive gameplay. Read How game accelerators differ from VPNs to see whether the issue is the network path or an app requirement. Changing split-tunneling rules can’t replace the destination service’s account and regional requirements.

When contacting support about split tunneling, include the app name, the action that failed, your current routing mode, the relevant rule match, and whether a brief comparison in another mode resolved the issue. If global mode works but rule mode doesn’t, focus on the rules or traffic-handling scope. If both fail, check the route, destination service, and DNS. These details reduce repeated requests to reinstall the client and help preserve your existing work network settings.

Mobile background disconnects: check power saving and network changes

If it stops working when the screen locks, check the system and app separately

If the client works in the foreground but not after the screen locks, first determine whether the system stopped the VPN process or the destination app paused background activity. A system connection that remains active doesn’t mean the destination app is still running; no new messages in the app don’t necessarily mean the VPN disconnected. Reproduce the issue on the same network and route. Note what worked before locking the screen, the system status after waking, and the app’s behavior before changing background permissions.

Battery saving, background data restrictions, Wi-Fi sleep, and network switching can all play a part. First test in a stable power and network environment, then check power-saving mode or a network change separately. Don’t leave the screen on just to prove the background connection is stable; that removes the trigger and won’t explain what happens when the screen locks. Don’t enable every background permission at once, either. Adjust the settings relevant to the client and current symptom so you can tell which one matters.

Android: check background activity and Private DNS

Background permission names vary by device; common settings include app battery management, background activity, and auto-start. Open the client’s app details in system settings and check that it isn’t set to a strict background restriction. If your device offers an option to allow background activity or exclude the app from battery optimization, adjust it as needed and observe any effect on battery life. Don’t disable system-wide power management by default or grant permissions unrelated to networking.

Background data settings can also affect connectivity while the screen is locked. Check that network access isn’t restricted separately for the client and destination app. If only the client has permission but the destination app is restricted, notifications may still be delayed. If the system has options such as always-on VPN or blocking connections outside the VPN, first understand what they do: while the VPN is unavailable, those settings may intentionally block other network access. Note the original settings before testing, and don’t mistake this protection for a permanent network outage.

The combination of Private DNS and the client’s DNS handling may also cause issues after switching networks. If domain errors occur only after a network change or wake-up, follow the DNS steps above, keeping the original settings before testing. Don’t install system certificates from unknown sources. If you’re unsure about installation or authorization, return to Getting Started or read Android client installation and verification to confirm the basics before testing background behavior.

iOS: check the current configuration and recovery steps

On iOS, first confirm that the active VPN configuration belongs to the client you’re using. An old configuration or another network tool may take over under different conditions. Get the client from the user panel; the panel determines which options are available based on your plan status. Don’t install a replacement configuration from an unfamiliar link. If iOS asks you to authorize the connection again, start it through the current client’s normal connection flow rather than manually importing an unknown profile. Ask your administrator about organization-managed configurations.

After waking the device, check the system connection first, then open the client to see whether it reconnected, and finally check the destination app. If the system connection is back but the app hasn’t resumed, properly quit and reopen it. If you have to take manual action to restore the client, note its status before and after. Background App Refresh and the VPN tunnel are separate mechanisms; changing an app’s background refresh settings alone may not fix a dropped connection.

A network change alters the underlying path, and some sessions need to be re-established. If the connection stays stable on one network but fails after you leave Wi-Fi coverage, make that trigger clear in your support ticket. Also note if the device was hot, low on battery, or had just stopped many background processes. Don’t upload every device log; the client’s connection events and steps to reproduce are enough. Remove unrelated app names, notification contents, and network identity details before sharing.

Device-limit alerts and support tickets: organize your findings

Unlimited devices; don’t assume an error reflects a plan limit

VPNWailian supports unlimited simultaneous devices. If a client shows a device-limit, unusual session-count, or similar alert, don’t assume this means the service has a fixed device limit. First check whether the message came from the VPNWailian client, the destination website, or another app. Streaming accounts, workplace platforms, and device-management policies may have their own limits. Those don’t apply to your VPNWailian plan, and creating extra accounts isn’t a troubleshooting step.

Check that you’re signed in to the right account and that the subscription belongs to it, that you haven’t enabled an old configuration, and whether another tool shows the same alert. Keep the exact message and where it appeared, then check your account status in the panel. You don’t need to delete working configurations from other devices to troubleshoot. Unlimited devices doesn’t mean every device can ignore local permissions, network access, or destination service rules. If only one device is affected, check its authorization, split-tunneling rules, and system network settings as described above.

When to stop troubleshooting on your own

Contact support when you’ve confirmed direct local access and account status are normal, client authorization is complete, and the issue still reproduces across controlled tests on different routes or trusted networks. Persistent failure on a particular route, a mismatch between panel status and client authentication, subscriptions that won’t update on different networks, and unexplained device-limit alerts are all worth escalating. There’s no need to reinstall the operating system or factory-reset your device first.

For charges, orders, or refund questions, contact support through the panel instead of repeatedly reconnecting to check your bill. We accept Alipay / WeChat Pay / USDT and offer a 14-day refund policy. See the refund policy for full details. Include the relevant order reference and a description of the issue, but never share payment account passwords, wallet keys, or login credentials. Describe connection and billing issues separately so important details don’t get buried in a long message.

No email address is required to create an account; just choose a username and password. Keep your login details safe. If you can’t sign in, don’t include your password in a support screenshot or public post. For help with your account, subscription, or order, open a support ticket in the user panel. Don’t look for or guess at a supposedly dedicated contact address without evidence, and don’t send personal details to an external account claiming to be support if you can’t verify who they are.

Write a support ticket that someone can reproduce

Start with one sentence describing the symptom, then list the steps that trigger it and what you expected to happen. Include your platform, the client version you’re actually using, network type, selected route, and current mode. Give the local time when it happened and include your time zone; “just now” isn’t enough. If only one app is affected, name it and describe the failed action. For a website, provide only the relevant domain and error text—not the full URL or private query details.

Next, list the comparisons you’ve already tried and the result of each. A useful report makes clear what stayed the same—for example, whether switching routes fixed it, switching networks still failed, or disabling the browser’s independent DNS resolved it. “I tried restarting, switching routes, and reinstalling” isn’t enough without the order and outcome; support would need to ask again. If a change made things worse, say what you changed and whether you restored the original setting so the next person isn’t faced with an unknown configuration.

Before attaching files, redact sensitive parts of subscription URLs, QR codes, access credentials, passwords, and payment details. Include only log entries relevant to reproducing the issue, not your full browsing history. When support replies, keep changing one thing at a time as advised and add the results to the same ticket. Once the issue is resolved, note the final route and settings, and keep a copy you can restore. If the same symptom comes back, you can pick up from what you’ve already verified instead of starting from scratch.

If you just need to check common account policies, start with the FAQ. To go through the import steps again, return to Getting Started. To choose a route by region and use case, see A beginner’s guide to choosing a route. Keeping setup instructions, troubleshooting, and account support separate helps avoid unnecessary changes and makes it easier for support to identify the issue.