VPN Troubleshooting Guide

Can’t Connect at All: Check from Your Network to the Tunnel

“Can’t connect” could mean the client won’t turn on, stays stuck connecting, or fails a route test. These symptoms point to different parts of the process. Note the button state and exact error first, then identify whether the issue occurs before configuration import, while connecting, or after the connection is established. Don’t rely on the status icon alone: some icons only indicate that the local proxy has started, not that requests are reaching the remote end.

First, make sure the device itself can access the internet

Temporarily disconnect the client and open a website you can normally access directly. If ordinary websites are also unavailable, check whether the Wi-Fi network requires a browser sign-in, whether the router is online, and whether an old system proxy is still enabled. Hotel and office networks may require you to confirm access in a browser first. Complete the network’s normal sign-in process rather than repeatedly importing your subscription. On a managed network, follow the administrator’s rules and don’t change organization-controlled restrictions yourself.

Once direct access works again, keep the same device and client but test on a different network. If the connection works there, the original network is worth investigating first, but that alone doesn’t identify what caused the issue. If other devices have the same problem on the original network, note the connection type and time and share them with the network administrator. Don’t start by clearing configurations on every device.

Tell a startup failure from a remote connection failure

If the button switches off immediately, check permissions, network extensions and local port conflicts first. When the system asks to add a VPN configuration or authorize a network extension, approve it through the normal process. If you previously denied permission, check system settings instead of repeatedly clicking Connect. If the button stays on but requests time out, check the selected route, proxy mode and subscription status. The client’s exact error is more useful than “it doesn’t work.” When taking a screenshot, include the error type but hide account details.

Close other proxy or VPN clients that are taking over network traffic, then test again with the original configuration. Multiple network-control tools running at once can conflict over routes or local listening ports. Closing an app window doesn’t necessarily stop its background service, so check its connection status or system network settings. Don’t try random fixes such as removing drivers or disabling all security software. If organization security software is involved, ask an administrator for help first.

Narrow it down by changing one route at a time

Once the network is working and permissions are in place, choose another route from your current subscription. Try another route in the same region first to check whether the issue affects a single route; then try another region if needed. See Nodes and Routes Explained for route types. Don’t change the route, client and DNS at the same time, or you won’t know which change helped.

If all routes fail, check the account panel for an active subscription and available traffic, and make sure the client imported the subscription for the current account. A significantly incorrect system clock can also cause secure connection checks to fail, so enable normal time synchronization. If the error mentions a certificate or handshake, don’t disable certificate checks. Record the error, check the time and ask support what to do next.

Check in this order: Does direct access work? → Can the client start? → Is the configuration valid? → Does changing routes affect the result? Record what happens at each step; repeating attempts isn’t a diagnosis.

When to stop troubleshooting on your device

If your subscription is active and ordinary websites work, but the same error occurs across different networks and routes, preserve the current state and contact support. Include your platform, client name, connection mode, displayed route name, network type and a redacted error. If only one route fails, mention which other routes connect successfully. Reinstalling at this point often just removes configurations and logs without helping identify a server-side issue.

Connected but Websites Won’t Load: Separate DNS from Requests

A connected status in the client doesn’t mean a web request has completed successfully. Loading a page involves DNS resolution, establishing a connection, security negotiation and loading content; any step can fail. First check whether all websites are affected or just a particular domain. Note whether the browser says it can’t find the address, waits indefinitely or shows a specific access-denied message. The failed stage determines what to check next.

Start with a result you can compare

Keep the route unchanged. Test an ordinary website and the affected site, and note the browser’s exact error. If only one site shows access denied, a region notice or an account verification prompt, check that platform’s rules first rather than assuming a DNS issue. If text appears but images, login windows or video don’t load, different routing rules may be affecting resource domains, or a browser extension may be interfering. Check the connection logs to narrow it down.

Try a private browsing window as a comparison to reduce interference from old cache and extensions, but don’t treat it as a fix. If the site works there, check extensions, site permissions and cache in your regular session. If all browsers fail, look at the system network and client. Use a page that doesn’t contain private information, and avoid repeatedly submitting payments or account actions while troubleshooting.

What a DNS check can—and can’t—tell you

DNS translates domain names into network addresses. A successful system lookup only shows that the current lookup path returned a result; it doesn’t prove the browser or proxy used the same path. Browser Secure DNS, client-side remote resolution and system DNS may all work independently. If results differ, note where each setting comes from. Don’t replace every resolver at once or add a temporary address to the system hosts file as a permanent fix.

nslookup example.com

Run the commands above in a terminal that supports the tool to view system lookup results. If the command isn’t available, use the system’s built-in network diagnostics; there’s no need to download an unfamiliar utility. Note whether the lookup timed out or returned a result, and whether the connection was active. Don’t publicly post full output containing internal domain names. On an organization’s network, replacing internal DNS may also make internal services unavailable.

Save evidence before clearing the cache

After changing routes or routing rules, an app may continue using an old connection or cached DNS result. Fully quit the affected app, reopen it and test again. Clear the cache only when evidence points to it, using the standard method for your system or browser. Instructions vary by platform, so avoid copying bulk-reset commands from unknown guides. Run the lookup again and retry the same page after making a change to see whether the two are related.

Don’t read too much into a diagnostic result

Opening an IP address directly often fails because sites rely on domain names and certificates; that doesn’t mean the route is down. Likewise, what a DNS test page displays isn’t enough on its own to prove a privacy leak. Check your egress IP on the Network Test Page and compare it with the client logs. If system lookups work but an app continues to report DNS errors, note whether it uses its own DNS. If you see an unexpected certificate or redirect, stop sensitive activity and submit redacted details.

Slow Speeds and Peak-Hour Lag: Keep Comparisons Consistent

Don’t judge speed by download numbers alone. Slow page loads, frequent video buffering, unstable file transfers and sluggish interactions can have different causes. Describe the affected task first, then check whether other tasks work normally. A fast route test doesn’t guarantee fast large-file transfers: destination rate limits, network congestion, device performance and wireless interference can all affect the experience.

Start with bandwidth shared on your local network

Pause system updates, cloud syncing and other downloads on the device, then check the original task again. Account for heavy transfers on other devices sharing the network, too. A strong-looking Wi-Fi signal doesn’t rule out retransmissions; if possible, compare using a wired connection or by moving closer to the access point. Don’t blame the route based on a single buffering incident on Wi-Fi, and don’t run several speed tests at once.

Keep the content, device and network the same, and change only the route. A website may serve the same content from different servers depending on your exit location, so this comparison only reflects how the current task performs. If ordinary browsing is fine but a particular download stays slow, check the download source’s limits. If every task is slow, investigate the network and route.

For peak-hour issues, keep comparable records

To investigate “slow in the evening,” note the time, task and connection path, and whether all regions are affected. Describe how the same route performs at different times. If switching networks resolves the issue, the original network may be congested. If only one route is affected on the same network, try another route and report the results. Don’t guess latency, bandwidth or packet-loss figures; if you can’t measure them, say they weren’t measured.

Don’t change a bunch of settings after every attempt. Check local bandwidth use first, then try another route in the same region, and finally change exit region to suit the task. This leaves useful evidence even if the problem only occurs at certain times. Route types describe how traffic is carried; they don’t guarantee speed at every hour. Distance, carrier interconnection and the destination site’s policies still matter.

What dedicated routes, relays and direct connections do—and don’t—mean

IEPL dedicated routes, relays and direct connections describe different network arrangements, not a simple ranking from slowest to fastest. A route that works well for interactive tasks may not suit a particular video stream, and routes in the same region can perform differently depending on the destination server. Choose from the routes actually included in your subscription and see Route Types Explained for their intended use. Don’t infer dedicated bandwidth or a fixed priority from a route name.

For video, check whether the platform adjusts picture quality automatically, whether playback resumes after seeking, and whether other content on the same platform works. Platforms often adjust quality based on buffering and device conditions, so a change in picture quality alone doesn’t prove a route problem. See Streaming Quality and Bandwidth Explained for more context. Don’t repeatedly stream large amounts of content while troubleshooting without checking your account’s remaining traffic.

A useful comparison records the same task, device, network, route name, time and observed result. The more conditions you change, the harder it is to interpret what happened.

When to contact support about speed

If the same task remains consistently slow after ruling out local downloads and Wi-Fi issues, share the task type, destination domain, affected times and results from comparing routes. A single speed-test screenshot isn’t enough, and there’s no need to upload your full browsing history. If you’re comparing plans, check Plans and Traffic Rules first. Don’t treat a different traffic tier as a speed upgrade: plan differences describe traffic allowances, not additional speed benefits.

Frequent Disconnects and Mobile Background Dropouts

Distinguish between the tunnel actually stopping, a brief reconnect after a network change, and an app that still shows connected even though requests no longer get through. First check whether the system connection indicator disappears, then see whether the client logs a reconnect. If it happens only when the screen locks, the device sleeps or you leave Wi-Fi range, check how the system manages background networking. If it also happens while you’re using the device, investigate the route, network and client together.

Note what happened just before the disconnect

Think about whether the screen locked, the network changed, the device woke up, another network tool started or the route changed just before the disconnect. Write down the action and result in order; that’s more useful than saying it “keeps dropping.” Test with the device in the foreground and the network unchanged first. If it still disconnects, compare with another route. If it happens only during a network change, check whether the client can reconnect on the new network; an existing connection can’t always stay intact.

Switching between Wi-Fi and mobile data changes the underlying network path, so an old connection may need to be re-established. Some apps keep a long-lived connection after it has stopped working, so they may still appear offline even after the client reconnects. Reopen the app or refresh the page to check whether only the app session failed to recover. Don’t delete the subscription immediately or treat an app’s offline indicator as proof that the tunnel is down.

On mobile, check background restrictions first

On Android, background restrictions may come from battery optimization, background activity permissions or a device manufacturer’s power-saving policy. Check in system settings whether the client is restricted, and allow normal background activity if needed. Setting names differ by device, so don’t copy menu paths from another brand. Adjust only the client that needs to stay connected; there’s no need to disable system-wide battery management just to troubleshoot.

On iOS, check that the VPN configuration is still present, hasn’t been replaced by another VPN configuration, and that you can reproduce the issue on a particular network or after locking the screen. A system-managed VPN isn’t the same as an ordinary background app process, so don’t assume every disconnect means the app was closed. If the device is managed by an organization, network settings may be controlled by its policies. Ask the administrator rather than removing the management profile yourself.

On desktop, check sleep and network recovery

After waking from sleep, network interfaces on Windows, macOS and Linux may come back online at different times. If the client starts before the network is ready, it may get stuck waiting. First confirm that direct access works, then disconnect and reconnect normally. If you have to do this after every wake, note the network type and client logs before and after sleep rather than disabling sleep permanently to hide the problem.

If the Wi-Fi itself disappears, the router reconnects or other devices go offline at the same time, troubleshoot the local network first. If only one device is affected, check its network driver and system update notices. Use trusted system or device-manufacturer channels for driver maintenance. Don’t run network repair scripts from unknown sources; they may change routing, proxy or DNS settings and make it harder to find the original problem.

The key to background disconnects is finding the trigger, not repeatedly turning the connection back on. A connection that works in the foreground but fails when the screen locks calls for different checks than one that fails while you’re actively using the device.

Record how the connection recovers, not just when it drops

In your support request, say whether the connection recovers automatically after a dropout, whether switching routes helps, and whether reopening the app makes a difference. If one route repeatedly reconnects, use another available route and report it. If all routes fail only on the same network, include the network type. Don’t upload screenshots of every background app; include only settings related to the client. Before sensitive activity, verify that the connection has recovered rather than relying on an old status indicator.

Subscription Update Failures and Configuration Issues

A subscription update is how the client retrieves and parses configuration; it’s separate from whether the current tunnel can connect. When an update fails, the existing configuration may still work. Conversely, a successful update doesn’t mean every route can access its destination. Keep the last working configuration, identify whether the problem is a failed network request, an account status issue, a parsing error or the wrong import location, and only then decide whether to import again.

Check your account and subscription source in the panel

Use the Account Dashboard to check the current account, plan status and remaining traffic. X4VPN doesn’t require an email address; you can get started with a username and password. Make sure you’re signed in to the account used to purchase the plan, not a newly created empty account. A configuration name left in the client may just be a local label; it doesn’t update automatically when the dashboard status changes.

Monthly subscription traffic resets each month on the activation date. If you upgrade mid-cycle, the price difference is prorated for the remaining days; traffic add-ons remain available until used and never expire. For balance or billing questions, compare the Plans page with your dashboard records. An update failure doesn’t by itself mean the plan is inactive. If the dashboard shows an unexpected status, note it and contact support rather than making another payment to test.

Tell a retrieval failure from a parsing failure

Retrieval failures often appear as a timeout, connection error or access-status message. Parsing failures may show an unrecognized format, invalid fields or unreadable content. For retrieval issues, first check that the device can access the dashboard and whether existing client routing rules are affecting the update request. For parsing issues, check that you’re using the right import option, haven’t entered the dashboard URL instead of the subscription URL, and didn’t copy extra spaces or line breaks.

An update request may use the client’s own network path or follow the current proxy mode; check the client’s documentation. If there’s an option such as “Use proxy for updates,” compare settings only when you understand what it does, and keep a record of the original value. Don’t disable security checks to force an update or send your subscription to an unfamiliar conversion site. The subscription URL is a private access credential.

Keep local changes before importing again

First note the selected configuration, route and any rules you added yourself. A client may contain a remote subscription, a local copy and a manual configuration; updating one entry doesn’t mean the active entry changed. If you need to import again, get the current link from the dashboard and choose the format required by the client. Don’t delete the old entry before trying to retrieve the new one, or you could lose a working setup if the update still fails.

A remote subscription update may overwrite content managed by that subscription. Whether custom rules are retained depends on how the client organizes configurations, so check its documentation first. If manual rules disappear, don’t assume the service removed them; check whether they were stored in a configuration file that gets updated. If you’re unfamiliar with a configuration snippet, keeping the defaults is usually easier to maintain than copying unknown settings.

Never include your subscription URL in a support ticket title, public screenshot or code example. Support needs the update time, error type and client name—not your full credentials.

When to contact support

If the dashboard is accessible and your subscription is active but retrieval or parsing keeps failing, provide the exact error, client and platform, the page where you started the update, and roughly when it last worked. Mention whether the old configuration can still connect, but don’t attach the full configuration file. If you shared the subscription publicly, use the dashboard’s available security feature to address it first. If you can’t find the right option, contact support; don’t share the exposed link any further.

Only One App Is Affected: Check Routing

If your browser works but one app doesn’t, that doesn’t necessarily mean the entire device has lost internet access. The app may not use the system proxy, may use its own DNS, may contact additional resource domains, or may be affected by its own account or regional policies. First check whether the same service works in a browser, then see whether the client can detect the app’s connections. Don’t change every route setting just because one app fails.

First check whether the app’s requests reach the client

If the client provides connection logs, open them before launching the affected app and performing an action that reliably reproduces the problem. If there are no related connections, check whether the app supports the system proxy and whether the client uses a system proxy or system-wide tunnel. They cover different traffic, so an enabled switch doesn’t prove that every app’s traffic is being routed through the proxy.

Some desktop apps have their own proxy settings. Use the local listening address, port and type shown by your current client; don’t copy fixed values from another guide. Selecting the wrong type may allow a local connection but prevent requests from completing. If you’re unsure, restore the app’s original settings and use a method officially supported by the client. Record the original values first so you can undo the change.

Check routing rules instead of chasing individual domains

If you can see the connections, check which rules matched and which exit was used. An app’s main screen, login, resource downloads, payments and live sessions may use different domains, so a working homepage doesn’t mean every dependency is working. Record the domain and rule result for the failed action instead of adding every domain you see to the proxy. Some resources are meant to connect directly; broad, indiscriminate rules may slow down other tasks.

If you understand what each mode does, you can briefly switch to another proxy mode supported by the client for diagnosis. If that fixes the issue, it only shows that the routing path is worth checking; don’t keep the temporary mode as your permanent setup. Restore the original mode after testing, then identify the specific rule that needs attention. Don’t change network handling on a managed device or organization app without permission. Ask an administrator first, especially when internal networks are involved.

Check AI tools and streaming services separately

AI tools may use different network settings in a browser, desktop app and command line. If the website works but the desktop app doesn’t, check the desktop app’s proxy path. If the command line fails, check which proxy settings that process actually reads, and don’t post full environment variables publicly. See Accessing AI Tools for more on common setups. A working route doesn’t guarantee that a platform offers service to your account or region.

Streaming services may also use account region, content licensing, exit IP detection and app cache to decide what’s available. If the platform shows an explicit regional message, keep the exact wording and distinguish it from a network timeout. Check the platform’s own status before changing routes; after switching, fully close and reopen the app to avoid confusion from an old session. See Disney+ Regions and Streaming Reliability for regional differences. No route should be presented as guaranteed to work.

When a browser works but an app doesn’t, first answer three questions: Did the request reach the client? Which rule matched? Which exit was used? Make changes only once you know the answers.

Describe the specific action when reporting an app issue

State the app name, platform, failing step, destination domain and any explicit error. A login failure, content-loading problem and failed message send are different issues. Include redacted rule-match details and say whether other apps work. Don’t submit app passwords, full request headers or session content. If a log excerpt is necessary, include only the relevant lines and check for authorization fields first.

Device Limit Messages and Platform-Specific Checks

X4VPN allows unlimited simultaneous devices and supports Windows / macOS / iOS / Android / Linux. If the client says “device limit exceeded” or shows a similar message, don’t assume you need a larger plan. The message may come from the client itself, another service configuration or the destination app’s account rules. First identify which screen displayed it and which configuration is selected, then check the dashboard. Don’t pay again for a restriction whose source hasn’t been identified.

Find out where the message actually comes from

Record the full message and where it appeared. If it came from the destination website, it may relate to that site’s device or session management, not X4VPN’s simultaneous-device policy. If it came from the client, check whether a different subscription or an old configuration is selected. If the dashboard also shows information that conflicts with unlimited devices, save a screenshot and contact support to check your account. Don’t guess that there’s a hidden device limit.

Unlimited devices doesn’t mean you can share the same local settings across them, or share account credentials publicly. Each device still needs the current subscription imported correctly, the required system permissions and appropriate network settings. System proxy, DNS and network-handling modes may differ between devices. A working second device is useful for comparison, but doesn’t prove the first one is configured correctly.

Where to check network handling on each platform

On Windows and macOS, the system proxy may remain enabled after an app window closes, or its background service may still be running while the window is hidden. Stop the connection normally first, then check whether system settings match what you expect. On Linux, the terminal environment and desktop settings may be separate, so a successful terminal lookup doesn’t prove that a graphical app works. An app that was already running may not read updated process environment settings until it’s restarted.

Control variables when comparing devices

To get a useful comparison, use the same network, destination service and available route on each device. If you change the network and route at the same time, you won’t know which caused the difference. Record each device’s proxy mode, and account for differences in browser Secure DNS, extensions and cache. Don’t remove existing organization settings just to make devices identical; check only what you’re allowed to change.

If only one device fails, check its permissions and network-handling settings first. If every device fails on the same network, investigate that network. If the same route fails across different devices and networks, report the route issue. These are troubleshooting leads, not final judgments about who is responsible. Keep both the successful and failed comparisons so support can see which condition changed the result.

When to download or reinstall the client

The client is available only from the Downloads section of the Account Dashboard; don’t use installers from unfamiliar mirrors. Before reinstalling, record your configuration and custom rules, and make sure you can still sign in to the dashboard. For initial setup, return to the Quick Start Guide. For importing and verifying on iPhone, see the iPhone Setup Guide. Reinstallation isn’t necessary for every problem. If you can identify a system setting as the cause, try a targeted, reversible change first.

Support Details, Privacy and Verifying the Fix

When you contact support, the goal is to make the problem understandable and reproducible—not to send as much data as possible. If you’ve checked the network, configuration, route and app, but the issue persists, or the account status conflicts with the published plan details, contact support through the Account Dashboard. Don’t keep running reset commands whose effects you can’t explain, and never post account information in public comments.

Describe the issue so someone else can reproduce it

Start your ticket with the affected task and symptom—for example, the connection button stays on, but a login request in a particular app times out. Then say when the issue began, whether it’s ongoing and under what conditions it goes away. List the steps you’ve tried in order and what happened after each one; “I tried everything” doesn’t help narrow it down. For an intermittent issue, include roughly when it last occurred and your time zone so support can match the time window.

Use the route name exactly as shown in the client. For the network, say whether it was Wi-Fi, wired or mobile data; there’s no need to provide your exact location. Use details shown in the current client interface for the client name, operating system and connection mode. If you don’t know something, say it’s unconfirmed rather than guessing the version or protocol. If you have a successful comparison, explain what changed; that’s often more useful than another screenshot of a failure.

Include only relevant log excerpts

Find the error near the time the issue occurred and copy only the relevant lines. Full logs may contain subscription URLs, account identifiers, visited domains, authentication fields or internal network information. Check them carefully before uploading. Check screenshots for browser address bars, window edges and notifications, too. Anonymous, no-logs service is a key privacy commitment; it doesn’t mean diagnostic information you submit is automatically redacted. These are separate things.

When removing sensitive fields, leave the error type, time and surrounding context so support can tell which stage failed. Don’t include passwords, full subscription URLs, session credentials or payment authentication details. If you’re unsure whether you’ve included enough, start with a written description and add only what the ticket requests. Don’t expose unrelated browsing records just to make the report look complete. For more on privacy, see the Privacy Policy and How to Verify a No-Logs Policy.

Support Request Template

Issue summary: Describe the failed task and error
Time: Include the actual time and time zone
Device and client: Include details shown in the current app
Network: State the connection type and whether you compared networks
Current setup: Include the connection mode and displayed route name
Steps to reproduce: List the actions in order
Comparison: Describe the conditions that worked and those that failed
Error message: Include the redacted text or screenshot
Changes made: State the original setting, what you changed and the result

For billing issues, provide plan and order details that can be checked in the dashboard; don’t share payment credentials. X4VPN supports Alipay / WeChat Pay / USDT and offers a 30-day money-back guarantee. See the Terms of Service for eligibility and how to request a refund. Don’t treat a connection diagnosis as a refund decision. If you’re unsure about plan traffic or reset dates, check the plan details first, then describe your specific question in the ticket.

Revert temporary changes after the issue is fixed

Once the issue is resolved, retest the task that originally failed—not just the connection icon. Then restore any temporary diagnostic changes to proxy mode, app settings and DNS, checking each one as you go. Keep only changes that are genuinely needed and note why. If things work only in a temporary mode, continue investigating the rule rather than leaving an unexplained configuration in place. Delete logs and screenshots you no longer need so sensitive data doesn’t linger on your device or in shared spaces.

Add the conditions that restored the connection to your ticket—for example, switching networks, reauthorizing the client or finding that only one route still fails. If support suggests a change, read what it affects and save the original value before applying it. Ask for clarification if you’re unsure; don’t make changes blindly just to move the process along. If the same symptom happens again, start with the conditions you’ve already verified. That’s usually more effective than reinstalling everything.