VPN Troubleshooting Guide

CONNECTION / BASELINE

Can't connect at all: identify where the problem occurs

First check whether you can get online with the proxy turned off. A connection failure in the client only means the connection attempt did not complete; it does not prove that a route is at fault. Pause the proxy, visit a site you can normally access, and make sure your system is not waiting on a network sign-in page. If your basic connection is unavailable too, troubleshoot Wi-Fi, your router, or network access first; reimporting the subscription usually won't help. Public networks may require you to sign in through a browser before starting the client.

Establish a repeatable starting point

Note where the client gets stuck: configuration won't load, the route list is empty, an error appears immediately after you click Connect, or the connection keeps timing out. For the first, check the subscription and parsing; for the second, check permissions and local listening; for the last, check the network path. Keep the exact error text instead of writing only “it doesn't work.” Quit other proxy apps, then open the VPNEdit client normally to prevent multiple apps from changing system proxy settings or competing for a virtual network interface.

Check that your system date, time, and time zone are correct. A significantly incorrect clock can interfere with certificate checks, causing sign-in, subscription requests, and route handshakes to fail at once. Use automatic time sync if available; don't turn off certificate verification to get connected. If you see an untrusted certificate warning, check whether the network requires sign-in and whether the device has a network management profile that affects encrypted connections. On a managed device, ask your administrator to verify the settings.

Compare networks and routes

With your account in good standing and the configuration loading correctly, keep the client settings unchanged and try a different access network. If it fails only on the original network, the cause is more likely that network's sign-in requirements, egress policy, or router settings. If it fails on multiple networks, keep the network unchanged and try a route in a different region. If only one route fails, switch routes for now and note its name and when the issue occurred.

Don't cycle through every option in quick succession. Handshakes, DNS lookups, and system network routing can take time to complete; repeated interruptions make results harder to compare. Wait for each connection attempt to finish before trying the next check, and note whether the error changes. A failed route latency check does not necessarily mean that browsing will fail. Some checks may be restricted by the network; use normal browsing after connecting as the final test.

Use reversible fixes based on the error

For a permissions error, check whether the system allows VPN connections or network extensions. If a virtual network adapter fails to start, quit the client normally, reopen it, and grant permission when prompted. Don't delete system adapters. If your security software shows a block, review the process and action before deciding whether to allow it. Don't try to work around restrictions on a managed device by changing system policies; ask your administrator and explain what you need.

A local port conflict usually causes the proxy listener to fail, but the route itself may be fine. Close other proxy clients and try again, or use the client's port settings to check for a conflict. Don't copy fixed ports, startup arguments, or certificate files from an untrusted guide. If the conflict persists after restarting, send the error log to support instead of repeatedly killing unfamiliar system processes that other apps may depend on.

If the same error occurs across different networks and routes after reloading the configuration, stop reinstalling without a clear reason. Include your platform, where you got the client, the stage where it fails, the exact error, and the comparisons you've already made in your support ticket. See the global server locations page for route types. You don't need to share your subscription URL or account password with support; a redacted log is enough to describe most connection issues.

WEB / RESOLUTION

Connected, but websites won't load: distinguish proxy issues from DNS

First distinguish “the client connected” from “the browser's request is going through the client.” The former may mean only that a tunnel was established; the latter also depends on system proxy settings, a virtual network interface, and routing rules. After connecting, try different sites and note whether none load, only certain sites fail, or only the browser has trouble. Don't rely on cached content from an open page to test connectivity. Open a new page and refresh so you know the request was made with the current connection.

Check whether the request reaches the client

Open the client's connection history or log, then visit the affected page. If there's no matching request, check whether the system proxy is enabled, whether the browser has its own proxy settings, and whether a proxy extension is routing traffic. Disable duplicate proxy extensions temporarily to compare results instead of switching routes right away. If the request appears, check whether it matched a direct or proxy rule and whether it failed during DNS resolution, connection setup, or response delivery.

If only one browser is affected, check its proxy extensions, secure DNS, and site data. Secure DNS may use a separate resolution path, so its results can differ from the client's DNS checks. Temporarily switch it to follow the system setting for comparison, and note the original value first. Don't start by clearing all browsing data: that signs you out and can make a network issue look like a website sign-in problem.

Know what DNS results can—and can't—tell you

DNS translates domain names into addresses. A page may fail to load if resolution fails, returns an address that doesn't work on the current path, or the app is still using an old result. A system lookup tool can check what the operating system resolves, but the browser or proxy may use a different result. If the lookup succeeds but the page still fails, check the client log too; a successful lookup doesn't prove the full connection path is working.

nslookup example.com

curl -I https://example.com

These examples use public sample domains and contain no subscription credentials. The first checks whether the system returns a DNS result; the second uses curl, if available on your system, to check whether an encrypted web request returns response headers. Command-line tools may not follow the system proxy automatically, so a different result from the browser doesn't mean either one is broken. Check the client log to see where the request actually went. Don't run diagnostic scripts from unknown sources against unfamiliar domains.

Restore DNS resolution without weakening security checks

If the issue started after switching networks, disconnect and reconnect the client, then close and reopen the affected app so it can establish a new connection. Once you've confirmed the basic network doesn't require sign-in, use the system's DNS cache flush or network diagnostics if available. Don't change DNS settings on your router, browser, and client all at once. Keep the original settings and restore defaults one layer at a time to identify the cause.

Don't enter account details if your browser shows a certificate warning. Check that the device time and site address are correct, and make sure you haven't been redirected to a public network sign-in page. If the site reports a regional restriction or account verification issue, follow the site's own guidance; that isn't evidence of a DNS leak. The network check page can help you inspect your egress IP, but a single IP result doesn't prove that every app uses the same DNS path.

For this type of support ticket, include the domain, browser name, whether all sites are affected, whether the request appears in the client, and the text of the error page. Redact unrelated account details and browsing history from screenshots. If switching browsers fixes the issue, say so clearly; that helps support narrow it down more than a vague “connected but no internet.”

PERFORMANCE / ROUTE

Slow speeds and peak-time lag: compare the path, not just latency

First identify what feels slow. A slow initial page load, slow file transfers, video buffering, and delayed interactive requests point to different issues: DNS and connection setup, sustained throughput, content delivery, or server response time. Latency is only one part of the connection and doesn't directly measure download speed. Pause background sync and downloads, then test the app you normally use instead of relying on an unrelated one-off speed test.

Compare your access network and egress route separately

Keep the egress route the same and compare different access networks; then keep the access network the same and compare different egress routes. If every app is slow on the same network and regular browsing is also affected with the proxy off, check Wi-Fi signal, router load, and local bandwidth use. If your basic connection is fine and only one egress route is slow, investigate that route or the path to the target service. Use the same task for each comparison to minimize differences in content size and caching.

If Wi-Fi is unstable, move closer to the access point or compare with a wired connection supported by your system before changing proxy settings. Check for cloud sync, system updates, or transfers on other devices. Increasing traffic in the client log only confirms that data is being transferred; it doesn't show that your task has the connection to itself. Stop identifiable background tasks first and see whether the foreground app improves. Don't kill unfamiliar system services.

Track peak-time issues over time

If performance is fine during the day but repeatedly degrades in the evening, note the time window, access network, egress route, and target app. The same symptoms can come from congestion on your access network, changes to cross-border routing, or load on the target site; switching regions won't fix every cause. When comparing route types, keep the app and content the same. If playback improves only after changing the source or video quality, that alone doesn't prove a route has recovered.

Route labels help explain path selection; they are not fixed performance guarantees. An egress route that's physically closer may not work better on your current network. A farther route with a more suitable path may work better for a particular service. Use the route selection guide to choose what to compare, but you don't need to test every route as part of your routine. Once you find a stable path for your task, keep the settings unchanged.

Treat video quality and browsing speed as separate issues

If a video automatically drops to a lower quality, check whether the player is still buffering and what happens when you change the quality for the same video. Streaming platforms also determine quality based on your device, account benefits, source, and session, so improved bandwidth may not immediately increase resolution. Changing your egress route doesn't guarantee a specific video quality. For background, read video bitrate and bandwidth explained, and see our Streaming guide for viewing tips.

If one site remains slow while other international sites work normally, compare different pages on that site and other egress routes in the same region. Avoid making large changes to your account region. If all routes slow down only in the evening on a particular access network, include that comparison in your support ticket. Support needs reproducible conditions and the direction of the change—not unverified performance claims or a pile of unrelated speed tests.

SESSION / BACKGROUND

Frequent disconnects and mobile background drops: check system routing first

First determine whether the network, tunnel, or app session disconnected. If the client still shows as connected but a messaging app asks you to sign in again, the app session may have expired. If all apps briefly lose access after switching Wi-Fi networks, the access path is a more likely cause. Note whether disconnects happen after locking the screen, sleep, a network change, or starting another VPN. A clear trigger is more useful than randomly switching routes, and can help distinguish system power-saving behavior from a persistent route problem.

Distinguish network changes from route disconnects

When a device switches access networks, the address and path used by the existing connection may change, and some apps need to reconnect. First see whether the client recovers automatically, then check whether the target app resumes its requests. If the tunnel is back but the app is still stuck, close and reopen the app normally to compare results; there's no need to reinstall the client right away. Keep the device on one access network during testing to check whether disconnects still happen while stationary.

If the connection stays stable while stationary but drops when you move or switch networks, check whether the system is repeatedly switching between saved networks or the access point requires you to sign in again. Don't turn off all system protections to keep the connection alive. For long tasks, use a reliable access network and keep the device charged and online. The task itself should support saving or resuming; restoring the connection doesn't necessarily restore the app's state.

Check background permissions on mobile

Android power-saving settings may restrict background processes, and the menus vary by device. Check the app's battery usage, background activity, and data permissions to make sure the client isn't set to strict restrictions. Change only settings related to the client and note their original values; don't disable all system power-saving features. If your system offers an always-on VPN or similar option, understand how it works before deciding whether to enable it.

On iOS, check both the system VPN status and the client's own status. Other network extensions, management profiles, or manually started VPNs may change which app is routing traffic. If a target app stops refreshing after the screen locks, that doesn't necessarily mean the tunnel has disconnected. When you wake the device, check the system status first, then review the client log. Repeatedly force-quitting the client won't keep it running in the background and may interrupt an active connection.

On desktop, check recovery from sleep

After a desktop device wakes from sleep, network interfaces may come back before the proxy process or system proxy settings are ready. If websites won't load, first confirm the basic network is connected, then reconnect the client normally. If the issue occurs only after sleep, note the interface name, client status, and exact error after waking. Don't disable unrelated network adapters or run commands that reset all network settings.

If a disconnect happens when you start a security or network tool, check whether it also creates a virtual interface or changes routes or proxy settings. You can quit the other tool normally to compare results, but get approval from your administrator first on a managed device. If only one route repeatedly disconnects while the network and device remain unchanged, investigate the route and include how another route performs under the same conditions.

When you contact support, explain whether the device was in the foreground or background before the disconnect, whether the screen was locked, whether the network changed, and whether you had to reconnect manually. Include only the relevant status in screenshots and remove private notifications. If the client still shows connected but the target app signed out, say so; that shifts the focus from tunnel stability to the app session and egress changes.

SUBSCRIPTION / CONFIGURATION

Subscription update failed: check retrieval, parsing, and loading separately

A subscription update involves more than one step. The client must retrieve the configuration, recognize its format, and load it into the current session. A failed request, unsupported format, or updated configuration that hasn't been activated can look similar, but each has a different fix. First identify the stage where the error occurs and check your account and plan status in the dashboard. You must sign in to retrieve a subscription. Don't keep importing old or unverified links from chat history.

Check delivery status in the dashboard first

Open the account overview and check your current plan, data status, and subscription link. If the page doesn't update after payment, refresh the dashboard and check the order status before taking further action. Don't pay again just because the client list hasn't refreshed. Monthly plan data resets each month on your activation date, not on the first day of the calendar month. Data packs don't expire; these are separate terms and shouldn't be confused.

If your account status doesn't match what you expected, ask support to check the order instead of changing authentication fields in the subscription. If you upgrade partway through a plan, the price difference is converted into remaining days, so an old screenshot alone won't show your current benefits. Check prices and data allowances on the plans page and in your dashboard. You don't need to switch plans repeatedly to troubleshoot a subscription. Never enter payment details on a page you don't recognize.

Treat request failures and parsing errors separately

If the request fails, first check whether the device can reach the account dashboard. If the dashboard won't open either, return to basic network and DNS checks. If it works but the client can't update, check whether the client is trying to fetch the subscription through a proxy that is no longer working. Keeping the original settings, try the client's built-in direct update option for comparison. Use the options shown in your client; don't assume another app has the same menus.

When copying the subscription link, use the copy function in the dashboard to avoid missing part of it. Leading or trailing spaces, line breaks, chat app formatting, or truncated parameters can cause a request to fail. Don't paste your subscription into a public online conversion tool to test it; subscription links usually contain access credentials. If you think yours has been exposed, reset it using the dashboard if possible, or open a support ticket.

If parsing fails, check that you used the import option for your client. Different apps support different configuration formats, protocol fields, and rule syntax; being able to open a link doesn't mean the app can load its contents. Use a compatible option from the dashboard or a client provided by VPNEdit. Renaming a configuration file doesn't convert its format. Don't delete fields that cause errors just to make parsing succeed; this could change what routes or rules mean.

Confirm the active configuration after updating

If the route list hasn't changed after an update, check that the updated subscription is the one currently enabled and that search filters or groups aren't hiding routes. Some clients keep your previously selected route instead of switching automatically when the configuration refreshes. Confirm the active configuration name, then select an available route. Keep a working old configuration temporarily for comparison, but don't run multiple routing processes with duplicate configurations at the same time.

Get clients from the downloads section of the account dashboard. Sign in to access the Windows, Android, macOS, and Linux clients; the iOS download option requires an active plan. Eligibility to download a client is separate from subscription status, so access to the downloads section doesn't tell you how much data remains. For your first import, see the Quick Start Guide. For troubleshooting, check the error and status instead.

For a failed update ticket, say whether the dashboard opens, whether you can copy the subscription, the exact client error, whether the current configuration still connects, and whether the issue persists on another network. If parsing fails only in one client, include the result from another client for comparison. Don't upload a configuration containing your full subscription to a public community. For help protecting your account and links, see the account safety checklist.

APPLICATION / ROUTING

An app isn't using the proxy: check routing and rules

First confirm that the problem affects only the target app, not all network access. Being able to browse doesn't mean other apps use the same proxy entry point. Some apps use the system proxy, others have their own network settings, and some require the client to route more of their traffic. Check whether the target request appears in the client log. Then determine whether it never reached the client, matched a direct rule, or went through the proxy and was rejected by the target service.

Use connection logs to see where traffic goes

Close and reopen the target app, repeat an action that reliably triggers the issue, and check the client's connection list. Note the target domain, process name, matched rule, and selected egress route. Whether the process name appears depends on the platform and routing method, so its absence doesn't mean no traffic was sent. An egress IP alone isn't enough: different apps and domains may take different paths, and a network check page can't replace the app's own request logs.

If there is no request in the log, check whether the target app has its own proxy option and whether the system proxy is actually enabled. If the app already has a manual proxy, don't stack another proxy entry without a reason. Temporarily restore its default setting to follow the system and compare results; note the original value first. If you need virtual network interface mode, use the client's official switch and permission process. Don't import routing settings from an unfamiliar guide.

Rule mode vs. a temporary global test

If the request reaches the client but matches a direct rule, briefly switch to the client's global proxy mode to compare. If that fixes the issue, review the matched rules instead of immediately switching routes. Global mode may change the path used by other apps, so restore your usual mode when the test is done. It's a troubleshooting tool, not a recommendation for ongoing use, and it doesn't guarantee the target service will accept the current egress route.

Before changing a rule, confirm which domains the target service actually uses. Sign-in, content APIs, images, and push notifications may use different domains, so changing only the main website domain may not be enough. Use the client's supported rule management tools, save a copy of the original configuration, and use logs to check changes one at a time. Avoid broad wildcard rules, and don't disable all security checks to make a single app work.

Network access and service eligibility are separate

If the target app returns a clear account, region, or plan message, the request has usually reached the service. Check the service's account status, regional policies, and usage requirements instead of continuing to reset your local network. AI tools and streaming services may evaluate account region, egress region, and session status separately. A network route provides a path to the service; it can't replace third-party account eligibility or content rights.

If a desktop app fails while the browser works, the app may be holding onto an old connection, using its own proxy settings, or resolving domains differently. Quit and reopen the app normally so you don't confuse a new browser session with an old desktop app session. Don't repeatedly switch between very different egress regions to test sign-in; this may trigger additional checks from the service. Compare under similar conditions and keep the error page.

If only an app's attachments, video, or notifications are affected, note which features work and which don't instead of saying the entire app is broken. Different features may use different resource domains or transport methods; access to the home page doesn't prove that every feature works. Don't apply protocol settings you're unsure about. Send support the affected feature, its corresponding client log entry, and the result of a temporary global-mode test for more targeted advice.

For your ticket, include only the target app name, affected feature, whether a request appeared, which rule it matched, and what changed after switching egress routes. You can attach redacted connection logs, but don't include the app's password or private messages. For streaming catalogs by region, see our Disney+ regional catalogs and route selection guide to check content availability separately from network connectivity.

ACCOUNT / DEVICE STATE

Account and device-limit alerts: check where the message came from

VPNEdit supports unlimited simultaneous devices. If you see a message such as “device limit exceeded,” first check whether it came from the VPNEdit dashboard, a client feature, or the target website's account system. A third-party app's device authorization limit doesn't apply to VPNEdit. Likewise, the operating system's limit on active VPN connections isn't the same as a service device limit. Keep the full message and note which page showed it; don't assume your account is restricted based on a keyword alone.

Check your account in the dashboard

Sign in to the dashboard with your existing account and check your plan, remaining data, and order history. No email address is required; accounts use a username and password. If you can't sign in, check the username, password manager autofill, and keyboard settings. Don't create multiple accounts to see if that fixes the issue. A new account isn't linked to your existing orders, and switching between accounts can make subscriptions and payment history harder to track.

If one device fails while others work, keep the account and route unchanged and check whether the affected device has an outdated configuration, a subscription from another account, or a duplicate proxy running. Working on another device doesn't necessarily mean there's no account issue, but check whether each device loaded the subscription from the same source. Don't copy your subscription into a public shared workspace to “standardize” settings; that could expose your credentials.

Distinguish data allowance from connection count

Unlimited devices doesn't mean unlimited data. If multiple devices share the account, check your dashboard to see how much data remains. Monthly plan data resets each month on your activation date. Data packs last until used and never expire. These terms are separate and can't be used interchangeably; the account status also can't be estimated by dividing data evenly between devices. A device syncing or downloading for a long time may use shared data, so check its active tasks first.

If your plan status looks wrong, check the specific reason shown in the dashboard before deciding what to do next. Don't assume a generic client connection timeout means your plan has expired or you've exceeded your allowance. If an order is paid but the benefits aren't displayed as expected, note the order status and ask support to check it. Don't pay again for the same order. Use your dashboard and the pricing information to check plan and billing details; don't infer them from a client error message.

Fix local conflicts on the device, not by signing out elsewhere

Different VPN or proxy tools running on the same device can compete to control system routing or use the same listening port. To compare, quit duplicate tools on that device normally instead of signing out all your other devices. Keep the configuration you're using and confirm that only the intended client is routing network traffic. On an organization-managed device, ask your administrator to check for policy conflicts; don't remove management profiles or bypass device permissions.

If a video or work app says its device authorization limit has been reached, check that app's device management guidance. If VPNEdit is connected and other sites work, the issue is more likely related to the target account's device permissions. Don't send a third-party account password to VPNEdit support or pay for an unverified device-unlinking service. You can share a screenshot of the message and your network comparison results to help support clarify the issue, but the target service is responsible for its account benefits.

If the dashboard or a VPNEdit client shows a device limit that conflicts with the unlimited-device policy, open a support ticket with the page or screen, platform, steps to reproduce, and a screenshot. Don't create additional accounts, repeatedly switch subscriptions, or change authentication settings to bypass the alert; these actions alter the issue and make it harder for support to reproduce. Keep the original error and note which devices still work; that's usually more useful than making random changes.

Handle account security and payment issues separately

If you notice an unfamiliar account change or signs that your subscription has been exposed, secure your credentials first, then contact support. Your password and subscription are separate sensitive items; changing one doesn't necessarily invalidate the other. Check the dashboard for the relevant option. Payment methods include Alipay / WeChat Pay / USDT, and VPNEdit offers a 14-day money-back guarantee. Handle billing disputes through your order history and an official support ticket; don't post screenshots with full personal details in public discussions.

If this is your first time using the service and you're unsure how your account, plan, and subscription fit together, review the first connection walkthrough. During troubleshooting, first confirm which account, configuration, and client you're using before changing network settings. Route adjustments are unlikely to solve the root cause until your account status is clear.

RECOVERY / SUPPORT RECORD

Restore your setup and submit a support ticket: keep evidence reproducible

Once your step-by-step checks have produced a consistent result, stop making changes without a clear goal. Support needs conditions they can reproduce, not a vague conclusion after many settings have changed. Describe the original symptom first, then list what stayed the same and what you changed. If you changed DNS, proxy mode, rules, or system permissions, say which ones. Restore a known configuration where possible so the next steps start from a clear baseline.

Return to a setup you can understand

Restoring your setup doesn't mean you have to uninstall the client. First undo recent temporary changes, re-enable your original subscription and rules, and restart the client normally. If you used global mode just to diagnose the issue, restore your usual mode. If you disabled a browser extension, use your comparison results to decide whether to leave it disabled. Don't reset both your router and device settings at once, or you may lose a difference you've already identified.

If you need to reinstall, first confirm you can sign in and retrieve your subscription, and note any custom rules or settings. Download the client only from the account dashboard; don't use installers from unknown sources. Reinstalling may clear some local settings, but it won't fix your access network, the target website, or your plan status. If the error is caused by an organization policy, ask your administrator to resolve the permissions issue instead of repeatedly reinstalling.

Share only the information support needs

Start your ticket with the platform and trigger—for example, disconnects after locking the screen, one app failing, or a subscription parsing error. Then include the date and time with time zone, access network type, egress route name, and exact error. List Windows, macOS, iOS, Android, or Linux as your platform, and add system details if support asks. Don't upload a full device report just to make the ticket look complete; include only what relates to the issue.

Describe what changed in each comparison, not just that you've “tried everything.” For example, say that the basic network worked and the same configuration connected after switching networks, or that changing the egress route fixed the issue on the same network. If every test failed, say whether the error was consistent. For website issues, the domain and affected feature are enough; you don't need to share your full browsing history. Include the relevant log lines around the failure so unrelated content doesn't hide the error.

Symptom: Client shows connected, but requests from the target app time out
Platform: Enter the platform you're using
Date, time, and time zone: Enter when you observed the issue
Access network: Enter the network type; omit private network names
Egress route: Enter the route name shown in the client
Exact error: Copy the relevant error and redact sensitive fields
Checks performed: Note what you changed and the result
Current status: Is the issue resolved, and can you reproduce it?

Before submitting, check screenshots and logs for usernames, subscription links, authentication parameters, payment details, and private notifications. A full subscription link and password aren't needed for an ordinary ticket. If support requests a specific diagnostic file, confirm the submission channel and redaction requirements first. Don't upload your configuration to a public file-sharing service and send a public link, or share an importable subscription in a community.

When to contact support

Contact support if your dashboard benefits clearly don't match your order, a subscription repeatedly fails to load on different networks, multiple routes show the same handshake error, or a VPNEdit page shows a device limit that conflicts with its policy. Handle system crashes, certificate warnings, and exposed credentials carefully; don't blindly follow online troubleshooting guides. Visit the Support page for contact options, or sign in and open the support ticket dashboard to send details.

If the issue is resolved, add the conditions that fixed it to your existing ticket instead of opening a duplicate. Keeping the troubleshooting history together helps support determine whether a route change, network recovery, or configuration adjustment made the difference. For third-party accounts, content rights, or organization network policies, follow the relevant service's process. Diagnosing a network issue can't change another platform's rules.

Verify your full setup after recovery

Don't stop at loading the home page. Confirm that the target app can complete the action that failed, then check your usual sites, required content, and background activity. If the device disconnected after sleep, test using the same trigger. If a subscription update failed, make sure the updated configuration is actually enabled. Don't switch every route immediately to prove the issue is fixed; that adds unnecessary variables.

Keep a brief local note of the symptom, trigger, change that helped, and recovery steps—never the full credentials. If a similar issue comes up, you can start from what you already know instead of reinstalling again. For initial setup, follow the Quick Start Guide; see the server page for route selection and the plans page for pricing and data terms. This guide helps you apply that information to the specific layer where the problem occurs.