Complete VPN Troubleshooting Guide

Can't connect at all: check the connection path

“Can't connect” can mean the app won't launch, a route won't connect, or a website isn't responding. Start by describing exactly what happens: does the connection switch stay on, does the app show an error, do all routes behave the same way, and can you reach local websites with the proxy off? A lit connection icon only shows that the app is in a particular state; it doesn't prove that an international route is working. Save the exact error text rather than repeatedly tapping Connect—it makes diagnosis easier.

Separate basic network problems from client issues

Disconnect in the client, then use a browser to open a local website you can normally reach. If that fails too, check Wi-Fi, Ethernet, network sign-in or your router first. Public networks may require you to complete a sign-in page in your browser. Without a working base connection, updating a subscription or switching routes won't fix the underlying problem. If other devices work but this one doesn't, check its network settings for a manual proxy left pointing to a client that is no longer running.

Once basic access is back, reopen the client and make sure the imported configuration is selected. Some apps keep multiple configurations; importing one doesn't mean it's the active one. Check the active configuration name, route list and connection mode to rule out a blank profile or an old local file. Then check your account dashboard for subscription status and remaining data. If the dashboard shows an issue with your plan, address that first instead of changing protocol settings.

Check that your system date and time are correct, and enable automatic time sync if available. Secure connections rely on valid certificates, and an incorrect system clock can cause a handshake to fail. Don't turn off certificate verification to clear an error, or treat a “skip verification” option in an unfamiliar configuration as a universal fix. Certificate errors can also come from a network sign-in page or an incorrect service address, so consider the exact error and your network environment.

Use controlled comparisons to isolate route and local network issues

Keep your current configuration unchanged. Choose another region or route type from the routes actually available in your dashboard, then test the same website. If only one route fails, the issue is more likely specific to that route or its path. If every route fails, continue checking your local network, client permissions and configuration. For background on route types, see the server page. Don't judge performance or compatibility by region name alone.

If possible, repeat the same connection test on another trusted network. Note the original network type before switching, and don't change the routing mode or configuration at the same time. If the same device and configuration work on another network, investigate the original network. If another device works on the original network, focus on the current device's settings. These comparisons narrow down the possibilities but don't prove which side is at fault.

Check whether the client needs permission to use a network extension, proxy or virtual network interface. If permission was denied, the app might still show routes even though traffic can't reach it. Regrant access through system settings or the client's official prompt. Don't install certificates or helper tools from unknown sources. On a managed device, administrator policies may restrict these permissions; confirm you're authorized to use the service rather than repeatedly reinstalling the app.

Choose your next step based on the error

A “timeout” usually means a request didn't get a response at the expected stage, but it doesn't identify whether the problem is the network entry point, route or destination service. “Connection refused” means a connection target didn't accept the request; check the configuration source and selected profile. For a “certificate” or “handshake” error, check the system clock, configuration updates and network sign-in status. Logs can report errors from different components, so consider when each occurred and what it targeted. Don't mistake a subscription download error for a route connection error.

If an old configuration fails but a freshly retrieved one from your dashboard works, save a screenshot of the old configuration and stop using it. If the updated configuration also fails, don't edit the server address, authentication details or transport settings yourself. Those fields must match the server, and arbitrary changes can introduce new errors. Restore the dashboard-provided configuration and record a controlled comparison; this makes the information in a support ticket more useful.

If your basic network and subscription are working but different routes still fail, submit the exact error, platform, network type and checks you've already completed. Don't send your password, full subscription link or an unredacted configuration.

If the client crashes or won't launch, there's no need to keep testing routes. Note the system message, client name and what you were doing when it failed to start. Check the device section on this page for installation source and permissions, then contact support. Work through the connection in order, confirming each layer before moving on. There's little value in adjusting app rules while the network entry point is still down.

Connected, but websites won't load: routing & DNS

If the client says it's connected but websites keep spinning, check DNS resolution, the proxy path and the destination service separately. Try opening one local website you can normally access and one site that needs an international route, then review the client's connection logs. If the local site works but the international one doesn't, focus on the route and rules. If neither works, check the system proxy, DNS and network interface. If only one website fails, note its domain for a focused check.

Check whether the request reaches the client

Open the client's connection or rule-match log, refresh the affected website and look for its domain. No log entry doesn't necessarily mean the client is broken: browser cache, an existing connection or log filters can affect what's shown. Close the tab, reopen the address and check the log filters. If the request still doesn't appear, check whether the browser uses its own proxy and whether the current connection mode handles browser traffic.

If you see a log entry, check which rule matched and the final route. If the destination is set to connect directly, temporarily compare it with another routing mode offered by the client. If that fixes the problem, review the original rule or rule order. Switch back to your usual routing mode after the test; global proxy mode isn't the default answer to every problem. Sending local websites over an international route can also cause sign-in issues or slower loading.

If the log shows traffic using the expected route but the browser returns a clear denial, region or account message, distinguish a network problem from the service's own policies. A network connection doesn't guarantee that a destination service will accept your account or current exit route. Save the exact message and use another route only as a comparison; don't keep refreshing or signing in repeatedly. If you see a certificate warning, stop entering account details and check the URL, system time and network sign-in status.

Check the DNS result instead of changing DNS at random

DNS turns domain names into network addresses. A lookup failure happens before the site is reached. System DNS, a browser's secure DNS and a client's internal resolver can use different paths, so it's not unusual for a browser to fail while other apps work. First check whether the browser has custom DNS enabled, then compare it with the client's recommended settings. Don't copy a DNS address you found online into every setting; changing several places makes the request path harder to trace.

You can run the query below in a system terminal to see whether you get a response, whether an error appears and which resolver is used. The example domain illustrates the command; it doesn't test whether a particular international service is available. For troubleshooting, replace it with the domain that fails and don't include account details. This checks how the system tool resolves the name; it doesn't diagnose the client's internal DNS or a browser-specific resolver.

nslookup example.com

A successful lookup only means that this query returned a result; it doesn't mean the website is reachable. Some websites use content delivery networks that return different addresses, which can be normal. Don't test an HTTPS site by replacing its domain with a numeric address: certificates and site routing often depend on the domain. Don't add an address from an unknown source to your hosts file, either. If you've previously added a mapping for the affected domain, back up the file before checking whether it's outdated.

Handle caches and conflicts in ways you can undo

After changing DNS or routing rules, old DNS cache entries and existing connections may still be in use. Close and reopen the affected app, and clear the DNS cache using the system's supported method if needed. Save your original settings first, and don't reset all network settings at once; a system reset can affect work networks, Wi-Fi settings and other software. If you're unsure what to do, restart the client connection and observe the result rather than copying an unfamiliar command that requires administrator access.

Ad blockers, security software and other proxy tools can also change the DNS path. Check their network settings and event logs first; don't leave security protection turned off. If you need a brief comparison, use a trusted network and restore the settings immediately afterward. Change one setting at a time and note the result. Otherwise, even if the site starts working, you won't know which change fixed it.

If the same domain behaves differently across apps, or only one DNS path fails, include the domain, app name, exact error and matched rule in your support ticket. Don't assume an address that looks virtual in the logs is an error; some clients use internal mappings. The key question is whether later requests are handled correctly. Sharing the full request path gives support more to work with than a single address.

Slow speeds and peak-hour lag: compare the route

Pin down what “slow” means: a website takes too long to open, a video buffers, a download stalls or an AI response takes a long time to start. These activities involve different network stages, so one speed test can't explain them all. Note the destination service, network type and what you're seeing. Then check whether downloads, cloud sync or system updates are using bandwidth in the background. If your base connection is congested, changing an international route may only improve part of the experience.

Set up a comparison you can reproduce

Use the same device, destination service and task to test your current route and another route available in the dashboard. Don't also switch Wi-Fi, browser and routing mode, or the results will be hard to interpret. For video, note the playback quality and whether content is already cached; cached segments can mask a change in the current connection. Repeated website visits can be affected by cache too. Try comparable content you haven't opened before, and describe how you tested rather than giving only a subjective impression.

Record local network performance separately from international access. If local websites are also much slower with the proxy off, the issue could be Wi-Fi interference, router congestion or your internet connection. If local access is fine but one route is slow, compare other routes. If every route is slow for the same destination but other services work, consider the destination's load or how it handles different exit routes. One service's response time doesn't represent the speed of your entire subscription.

A strong Wi-Fi signal doesn't guarantee a stable connection. Try the comparison closer to the router, or use Ethernet if available. After switching networks, wait for the system to settle before connecting the client. Work and public networks may manage traffic in ways that affect large downloads or long-lived connections. Follow the network's usage rules and compare on a trusted alternative network; don't change managed network equipment yourself.

For peak-hour issues, note the time and route type

If the issue mainly occurs at peak times, note roughly when it starts and clears, and whether it happens every day. Changes at different times on the same path can help show whether your access network or route is congested. “Slow in the evening” doesn't identify the cause by itself: your local broadband, international path, destination service or exit capacity can all vary by time. Compare routes and local access to narrow it down.

Choose routes from the list actually shown in your VPNWH dashboard. IEPL dedicated lines, relay routes and direct routes describe different network paths; they aren't a fixed speed ranking for every network. Start with a route suited to your destination region, then compare different types using the same task. A closer region isn't always faster, and a more distant one isn't necessarily unusable. Routing and the destination's location both affect performance.

Don't choose a route based only on the latency shown in the client. Latency measures the round-trip wait for a particular test, while file transfers also depend on bandwidth, packet loss, connection type and the destination service. A low-latency route can still stall during a transfer, while one with higher latency may stream smoothly. A more useful test is whether your task completes reliably and whether the client reports repeated reconnects or failed requests.

Distinguish bandwidth, connection issues and server response time

Check your remaining data and plan status in the account dashboard. Monthly subscription data resets each month on the activation date, not on a shared calendar-month schedule. Mid-cycle upgrades are prorated for the remaining days. Don't treat low data as a routing issue, or assume a higher data tier automatically means faster speeds. See plans and pricing for allowances and data pack rules. Choose based on your actual usage and billing terms.

If a video opens but keeps buffering, check whether the client is still connected, then compare after lowering playback demands. If that helps, sustained transfer performance is worth investigating, but it doesn't prove the cause. For downloads, compare trusted sources so you don't mistake a particular download server's limits for a route issue. Don't run large-scale tests repeatedly on public networks; they affect others without adding diagnostic value.

When AI or developer tools are slow to respond, distinguish a request that hasn't been sent from a connection that keeps dropping or a service that's still processing. A browser opening the service homepage doesn't mean that a desktop tool's sign-in, autocomplete or long-lived connection domains are routed correctly. See the route selection guide for Cursor and Copilot. If the logs show requests taking the wrong route, check the app routing section instead of searching for a route with a higher speed-test result.

For a peak-hour support ticket, include the time period, task, results on the original and alternative networks, and the current and comparison routes. If you didn't measure speed or packet loss, describe what you actually observed—don't guess at figures.

If one route consistently performs poorly while others remain stable, you can temporarily use a route you've verified and report the affected route in your support ticket. If switching routes only helps briefly, continue checking disconnects and background behavior. Avoid repeatedly clearing configurations or reimporting subscriptions; these actions usually don't fix congestion and can erase custom rules and troubleshooting records.

Frequent disconnects and mobile background dropouts

First establish what stopped running: did the client process exit, did the system's connection icon disappear, did the route session reconnect, or did just one app lose its connection? Each points to a different cause. Note whether the device was locked, switched from Wi-Fi to mobile data or entered power-saving mode before the disconnect, and whether reopening the client restores service. “It disconnects after a while” doesn't distinguish a route problem from system background management.

If it disconnects in the foreground, check the network and connection conflicts

Keep the client in the foreground and use the same destination service while watching the connection log. If it repeatedly reconnects in the foreground, start with the basic network and route comparisons rather than changing power settings alone. Switching Wi-Fi networks, a brief network outage or a router restart can invalidate a session. Automatic reconnection is recovery; the key question is whether something keeps interrupting the session and whether service works after reconnecting.

Check whether another proxy, network accelerator or tool using the system VPN interface is running at the same time. Multiple tools can compete for the system proxy or network interface, with one app overwriting another's settings. Stop unneeded connections through their own interfaces, then start the current client. Don't delete an unfamiliar network interface. If work security software needs to stay active, check compatibility rather than leaving essential protection disabled for testing.

A browser or app may also close its own idle connection. If an interruption occurs only in one tool while the client and other apps keep working, check that tool's error message and connection method. Developer tools may use different domains for autocomplete, chat and sign-in, so a partial failure can look like a disconnect. Note the affected feature and time, and check its matched rules. Don't classify every app error as a dropped route.

If it disconnects when the screen locks, check background management

On Android, battery optimization, background activity limits and manufacturer task cleaners can affect whether a client keeps running. Open the app's battery and background settings and check whether background activity is restricted. If the client requires ongoing activity, allow the relevant background permission available on your device. Menu names vary, so don't follow paths that don't match your device. After changing a setting, test the same task before and after locking the screen, and keep the original setting so you can undo the change.

Some devices close apps when you clear recent tasks; others keep the system connection but stop the app interface. Don't rely only on whether the app appears in the recent-apps list—check the system connection status and client logs too. Allowing background activity doesn't mean granting every permission; consider network-related permissions separately. For more on Android choices and settings, see Android VPN background operation and per-app proxy settings.

On iOS, the system network extension usually helps maintain the connection. If a page won't load after the screen locks, check the system connection status, then reopen the client and check the route. A temporarily stale app screen doesn't prove that the extension has stopped. Network changes, system sleep and the destination app resuming can all rebuild a connection. If the connection never recovers automatically after switching networks, note the network types before and after and what you did to restore it, so support can review the client's behavior.

Test desktop sleep and long-lived connections separately

On Windows, macOS and Linux, an existing connection may stop working after sleep, wake or a network change. After waking the device, check that basic network access is back, then check the system proxy and client connection. If the client says it's connected but the destination service fails, disconnect and reconnect through the client as a test; don't reset every network setting right away. Starting the client on login also doesn't mean the network is ready at startup. Check whether it reconnects after the network comes back.

For ongoing tasks such as downloads, video or AI conversations, a network change can invalidate the original session even after the client reconnects. Wait until the connection is stable, then start the task again and check whether the new request completes. For file submissions or payments, check the service's status before retrying to avoid duplicate submissions. Restoring the network and restoring an app task are separate steps; a recovered connection icon doesn't prove the original action succeeded.

If a disconnect follows a specific action, such as launching a network tool, entering power-saving mode or unlocking the screen, keep that trigger in your notes. If it continues after changing background settings, don't keep expanding permissions. Check the client logs for process exits, interface resets or route connection errors. If there are no clear logs, record the trigger, system state, client state and recovery steps in that order in your support ticket.

Don't use an always-on screen, disabled security protection or an unfamiliar keep-alive app as a substitute for diagnosis. Grant only the background permissions needed for a clear purpose, and verify them with a foreground/background comparison.

If the issue affects one route both in the foreground and background, report that route first. If all routes fail only after the screen locks, focus on the device's background behavior. This helps avoid unnecessary route changes and tells support whether the issue is more likely in the network path or system restrictions. If logs may contain visited domains, include only relevant lines around the failure and redact them as requested.

Subscription update failed: check the configuration source and status

A subscription update downloads a configuration to the client; connecting with an already imported route is a separate process. An old configuration may still work after an update fails, and a successful update doesn't guarantee the new configuration is selected. First note whether the failure occurred while retrieving the subscription, importing the configuration or connecting to a route, and save the exact error. Don't delete a configuration that still works just because the update button reports an error; you'll lose a useful comparison and fallback.

Confirm the source in your account dashboard

Sign in to the account dashboard, check your subscription status and data, then get the subscription from the dashboard's provided link. VPNWH doesn't require an email address; you can create an account with a username and password. When troubleshooting an existing account, make sure you're signed in to the original one, not a different account you created. An unknown configuration source, mismatched account or manually saved old link can all lead to unexpected update results.

Use an import method supported by the dashboard and make sure you've selected the right client. When copying a link, don't include extra spaces, punctuation added by a chat app or line breaks, and don't mistake the dashboard page URL for a subscription link. A subscription link is sensitive account information; never paste it into a search engine, public converter or shared document. Example URLs in a guide aren't substitutes for the actual subscription link issued to your account.

If you reset your subscription link in the dashboard, use the current link shown there and check the source saved in your client. Repeatedly pressing Update won't fix an expired link. Don't paste the full link into a support ticket. You can provide screenshots of the dashboard status and client error instead. If support needs more information, use the secure process in the dashboard rather than exposing authentication details.

Tell a download failure from a parsing error

An update timeout can happen while the configuration is downloading. First check basic network access and whether you can open the dashboard. Then check whether the client offers an option to update through the current proxy; support varies by client, so don't assume every update request uses the connected route. If you change the update path, note the results before and after, then check the setting again when you restore it. Avoid repeated retries that make it harder to distinguish a network problem from request processing.

If the download completes but the client reports a format or parsing error, check whether it received the right configuration. A network sign-in page, login page or error response may have been downloaded in place of the configuration. Check the error category shown by the client; don't paste the full downloaded content into a public forum. If importing directly from the dashboard still fails, note the client, platform and error field so support can check compatibility.

The same protocol name doesn't mean every configuration format is interchangeable. Clients may differ in their support for configuration structure, rules and transport options; changing a file extension doesn't convert it. Use the dashboard's supported import option and check which configuration is selected. Get clients and subscriptions from the dashboard download section. Sign in to access the subscription; client download access is determined by the dashboard.

After updating, check routes and custom rules

After a successful update, check that the route list loaded, the selected route is still available and the routing mode suits your usual use. Some clients may retain a selection for a route that was replaced; select a route currently available in the dashboard. Don't stop at the “update successful” message. Open the destination service and check the connection log to confirm new requests are using the expected path.

If you use local overrides or custom rules, they may be applied alongside the updated configuration. Save the rule content and order first, then look for references to old route names, incorrect rule groups or missing local files. You can temporarily compare against an unmodified configuration from the dashboard, but don't overwrite your only working setup. If the original configuration works and the customized one doesn't, troubleshoot the overrides before updating the subscription again.

Understand data allowances according to their billing terms. Monthly subscription data resets each month on the activation date; data packs remain valid until used and never expire. A data pack that doesn't expire isn't unlimited, and consumed data doesn't automatically come back. For questions about your plan or an upgrade, check plans and billing details, then include relevant order information in a support ticket. Don't infer benefits from calendar dates that aren't specified.

Useful details for a subscription support ticket include the stage that failed, exact error, how you retrieved the configuration, dashboard status, client and platform. A full subscription link, password or configuration containing authentication details isn't appropriate for public troubleshooting.

Contact support if your account status is normal but the current source still won't update, the same source fails to parse in a compatible client, or importing directly from the dashboard doesn't work. If the problem is limited to an old link or a custom conversion process, first retry with the configuration obtained directly from the dashboard. Keep the source clear so further route and app checks are based on a reliable configuration.

An app won't use the proxy: check the matched rule

If a browser works but one app can't connect, it may use its own network settings, its requests may not be handled by the current connection mode, or a rule may send them the wrong way. First note whether the error occurs during sign-in, content loading, uploading or an ongoing session, then check whether the client logs show the request. Don't assume the app is broken just because other software works, and don't start by sending all traffic through the same route.

First check what the client handles

A system proxy usually applies to apps that follow system proxy settings; it doesn't handle all traffic on a device. Some command-line tools, games and desktop apps ignore the system proxy or use their own settings. A virtual network interface can handle more traffic, but its reach still depends on system permissions, routing and client features. Check how your client works rather than assuming that a switch label means every app is covered.

Check the app's settings for a saved custom proxy address. If it points to an old client or a local entry point that is no longer running, the system proxy won't help that app. Back up the original settings, then choose a system proxy option supported by the app or the method for your current client. Don't copy a local port from an online article; use the entry point shown by your client. A wrong port sends requests nowhere beyond your own device, rather than through an international route.

Environment variables can also affect the request path for command-line tools. Check the tool's documentation to see which proxy variables it recognizes, then find out whether your current terminal inherited old values. You can check whether variables are set without printing their values, which might expose account details in a proxy address. After making a change, reopen the terminal or refresh the environment as the tool's documentation explains; an already-running process may not pick up changes automatically.

if [ -n "$HTTPS_PROXY" ] || [ -n "$https_proxy" ]; then
  printf '%s\n' 'HTTPS proxy environment variable is set'
else
  printf '%s\n' 'HTTPS proxy environment variable is not set'
fi

The example above is for macOS or Linux terminals using a compatible shell. It only shows whether the variable exists; it doesn't check whether the address is valid. A variable being set doesn't mean the target tool will use it, or that UDP and other connection types are covered. If you're not comfortable with terminal commands, use the app and client logs instead; you don't need to install extra tools to troubleshoot.

Check domains, processes and rule order

Repeat the failed action, find the corresponding request in the logs, and check the domain, rule group and final route. An app may use separate services for sign-in, content, attachments and sessions. Routing its homepage correctly doesn't mean all its requests are routed correctly. Check logs for the feature that fails rather than assuming the app's name is a usable domain rule. If the log shows an address but no domain, DNS resolution or how the client handles traffic may be involved; check the DNS section too.

Rules usually match in order, so a broad rule can take effect before a rule for the destination. If adding a rule changes nothing, first check that it loaded and whether an earlier rule covers more. Don't keep adding duplicates to test; repeated rules are hard to maintain and can hide the actual match. Save your existing rules before changing them, then restart the destination app's connection and confirm you're seeing a new request rather than an existing session.

For Android per-app proxy settings, check that the app is included in the handled-app list and whether the current mode means “only selected apps” or “exclude selected apps.” The two modes mean opposite things, so a selected state can't be interpreted without knowing the mode. Work profiles, cloned apps and separate user spaces can also show different app instances. Check the permissions and selection for the instance actually running on your system; don't rely only on the app's home-screen name.

Handle service policies separately from network issues

If the app's request reaches the expected route but the response mentions an account, region or access policy, check the destination service's requirements. VPNWH provides network routing; it doesn't control account eligibility, content licensing or organizational policies set by third-party services. AI and streaming services may assess different requests in different ways. A working route doesn't guarantee that every feature is authorized, so report the message accurately rather than promising a particular result.

After switching routes, an existing session may continue using the old connection. Close the affected feature, start a new session and check whether the final route changed. If signing in, avoid repeatedly switching regions in ways that might trigger extra checks. For developer tools, see the AI tools access guide; for video services, see streaming support. Availability still depends on the route and destination service you test.

If only one app fails, include its name, the feature that fails, connection mode, whether a request appears in the log, the matched rule and the exact message in your support ticket. Don't send only a screenshot showing that the client is connected.

If an unmodified configuration works but the app fails after you add routing rules, restore the original rules and test them one at a time. If the client can't see the app's requests in any connection mode, check client features and system permissions rather than blindly adding domains. Routing is about sending each kind of request along a suitable path; start troubleshooting with the actual request, not guesses based on the app's brand.

Device messages and platform differences: permissions and local settings

VPNWH supports Windows / macOS / iOS / Android / Linux, with unlimited devices. If a client reports something like “device limit exceeded,” don't assume VPNWH has an unpublished device limit or upgrade your plan right away. The message may come from the client app's own account system, the import source, a third-party tool or another configuration. First identify which app is showing it, then confirm you're using a subscription obtained from the VPNWH dashboard.

Check the source of device messages first

Save a screenshot showing the app name and exact message, and hide sensitive account information. Check whether you imported another subscription too, selected the wrong configuration or need to sign in to the app separately. A service subscription and a client software account are different things; don't mistake one app's permission message for a VPNWH plan rule. If the message appears related to your VPNWH configuration, ask support to check it instead of deleting all device settings.

Unlimited devices means you can use the service on multiple devices; it doesn't make their network environments and configurations identical. Different networks, clients and routing modes can result in different experiences. When comparing a working device with one that isn't, check the configuration source, destination service and connection mode. Don't copy a full configuration containing sensitive information into a public channel. Different platforms may also have different supported import methods.

If only a newly added device fails, check its basic network access, system clock and permissions before importing the current configuration from your dashboard. Don't change other devices that are working. If all devices fail at the same time, check subscription status and any shared network entry point. If only devices on one router have trouble, investigate that network. The number of devices alone isn't enough to explain a problem.

Check local connection requirements by platform

On Windows, check that the system proxy points to a running client and that no other software has changed the proxy settings. A manual proxy left behind after the client exits can prevent ordinary websites from loading too. Use the client's normal disconnect or restore option, then check system settings. Don't delete an unfamiliar network adapter or run a broad repair script. For installation and startup guidance, see the Windows setup guide.

On macOS, check whether the system network extension is authorized and whether separate proxy settings remain on different network services. Even after granting permission in the app, you may need to enable the extension as prompted by the system; simply restarting the app might not change its authorization. On Linux, check that desktop proxy settings, terminal environment variables and background services agree. A working graphical app doesn't mean the command line uses the same route, and vice versa.

On mobile, stop any unneeded system connections that may be using the same interface, then connect through the current client. Don't run multiple tools that compete for the same interface. Check Android app selection and background operation separately; on iOS, also check the system extension status. A device management policy may block network extensions; an administrator must handle that restriction. Changing plans won't resolve it.

Reinstallation and network resets come later

Before reinstalling, note the configuration source, custom rules, selected route and system proxy status. Make sure you can sign back in to the dashboard to retrieve the subscription. Uninstalling can remove local rules or leave system settings behind; without a backup, the original problem can get mixed up with new ones. Use a trusted installation source. Access to downloads is controlled by the dashboard; don't replace its official delivery route with an installer from an unknown search result.

A network reset can have wider effects, including removing Wi-Fi settings, work network configurations or settings other software depends on. Consider it only if basic network access or system traffic handling is clearly broken and you've identified what will be affected. Save any settings you need and make sure you have a way to reconnect. On a managed device, contact the administrator first to avoid disrupting certificates, network policies or dedicated access settings.

Router configurations can't simply be copied from desktop clients. Even a router with proxy features may differ in configuration format, available resources, DNS and policy routing. The platforms listed in our service facts aren't a compatibility promise for every router model. If you need help with a router, tell support its operating system and how you plan to use it. Confirm compatibility before deployment, and don't share a complete router configuration containing authentication details.

For device errors, first identify which app produced the message. For platform issues, check local permissions and how traffic is handled. VPNWH supports unlimited devices; adding a device isn't a reason to assume you need a higher plan.

Once you've sorted out the platform differences, your support ticket can say, “The same subscription works on one platform but fails on another on the same network,” followed by the relevant error. That's more precise than “I tried lots of devices,” and helps support avoid repeating checks you've already done.

Verify recovery and prepare support ticket details

Don't judge recovery only by whether the client's connection switch is on. Check whether the task that originally failed now works. Revisit the steps in order: basic network, configuration loaded, route established, rule matched and destination responded. Restore any temporary settings you changed for testing. If a temporary change fixed the issue, note why and when it applies. There's no need to keep a global proxy, extra background permissions or temporary DNS settings enabled indefinitely.

Verify that the original issue is fixed

Test with the original device, app and action. For a sign-in failure, confirm you can complete sign-in. For video buffering, check a new segment. For background disconnects, test a new request after locking the screen. Opening a different website doesn't prove that the original issue is resolved. If the issue clears on another network but persists on the original one, report that “the alternative network works” rather than saying the issue is fully fixed. That distinction matters for follow-up.

Keep custom rules and configuration changes maintainable; remove duplicate test entries that no longer help. Don't delete settings that work just to make the setup look tidy—back them up first. If you're using an alternative route, save the name of the original route that failed and the conditions that trigger the issue, so support can investigate. If the problem returns, add what changed to your existing notes instead of repeating every basic check.

If you need to undo changes, restore the dashboard-provided configuration and original system settings rather than using an unofficial “optimization package.” Useful findings should be reproducible: what changed, what happened and under what conditions. Even if you don't find the root cause, confirming which layers work can speed up follow-up. If you didn't measure something, say “not tested” instead of guessing.

When to stop changing settings yourself

Contact support if you've confirmed basic network access, subscription status and configuration source but multiple available routes still fail; one route repeatedly shows the same error; a configuration imported directly from the dashboard won't parse; or the client reports authentication or certificate fields you can't identify. If an administrator controls system permissions, or the issue involves a third-party account policy or local hardware, explain the boundary and contact the appropriate support channel.

Support tickets are available in the account dashboard; sign-in is required. Use dashboard tickets as your contact channel rather than sending subscription details to an unfamiliar account found through search results. Keep the ticket conversation together when adding test results later. Linking times, routes and actions in one thread helps support follow the issue without information being scattered.

Start your ticket with a short description of the symptom and who or what is affected, then include when it happened, your platform, client, network type, configuration source and exact error. Next, list the comparisons you've run, noting what you changed, what stayed the same and what happened. If you attach screenshots, show the app name, error location and relevant status rather than an isolated message. Hide account, payment and browsing information.

Protect logs and billing information

Logs may include visited domains, paths, account identifiers or authentication fields. Review relevant excerpts before sharing, keep only what's needed around the failure, and remove passwords, full subscription links, tokens and unrelated browsing records. If you can't tell whether a field is sensitive, don't upload the full file publicly. Ask in your support ticket what information is needed. Check screenshots for browser address bars, configuration details and clipboard previews too, so nearby information isn't exposed.

For payment or plan questions, provide dashboard information that can identify the order along with a description of the issue. Never send a payment password or full payment credentials. VPNWH accepts Alipay / WeChat Pay / USDT. Keep billing questions separate from network troubleshooting. Monthly subscriptions and data packs have their own prices on the plans page; monthly data resets on the activation date, while data packs never expire. Don't confuse these rules in a support ticket.

VPNWH offers a 14-day no-questions-asked refund policy. See the Terms of Service for the full terms. To request a refund, just say so in a support ticket; you don't need to complete unrelated tests first. If you'd also like help with a technical issue, mention that in the same conversation. Support troubleshooting doesn't replace checking the terms. Keep technical recovery and billing requests distinct so a temporary fix isn't mistaken for a resolution of every request.

A useful support ticket isn't about how many things you've tried. It's about a reproducible symptom, controlled comparisons and safe evidence. Stick to the facts and identify what's still unknown; that's usually more effective than changing settings repeatedly.

For everyday use, return to the quick start guide to review the connection steps. Find short answers to common questions in the FAQ. This manual helps narrow down issues by symptom; you don't need to read every section every time something goes wrong. Start with the section that matches what you're seeing, verify the key steps, then send anything you can't confirm to support.