VPN Troubleshooting From symptoms to causes

Can't connect at all: separate local issues from route issues

“Can't connect” can mean the client won't start, the connect button does nothing, the connection keeps timing out, or just one website won't load. These symptoms can have different causes. Stay on the current screen, note the button state and exact error message, then check whether the client actually established a connection. A “connected” status doesn't prove that websites are reachable, and one app's error doesn't mean every route is down.

Establish a baseline for your local network

Disconnect the client and open a website that normally works in your browser. If it still won't load, check whether your Wi-Fi or wired connection has an IP address, whether a public Wi-Fi sign-in page needs your attention, and whether the router is online. A public network may connect your device without granting internet access until you sign in or accept its terms. Complete that step, then reconnect the client. Repeatedly switching remote routes won't fix a local network issue.

If your browser still says the proxy server is unavailable after disconnecting, check whether a system proxy setting was left behind. Some clients route browser traffic through a system proxy, and an unexpected exit can leave the system pointing to a local port that is no longer active. Reopen the original client, use its option to disable the system proxy, then exit normally. Don't remove unfamiliar network adapters or copy a fixed port from another client's guide; the local port must match the current client's settings.

Follow the evidence when a connection fails

Once the local network is working, open the client's subscription or configuration list. Make sure you're using an imported configuration, not an empty one or an old manual setup. Check whether the route list opens, whether the selected group contains any routes, and whether your account shows available data and an active service status. If the client asks for system permission, make sure you've granted it. Denied permissions, an inactive configuration and a remote connection failure can all look like the connect button simply resets.

Next, keep the same configuration and choose another route shown as available in the panel. Leave all other settings unchanged. If only the original route fails, the issue is more likely with that route or its path from your current network. If every route fails, try the same setup on another available network. If that works, investigate the original access network first. If the same configuration works on another device, check permissions, proxy handling and software conflicts on the affected device instead of repeatedly rebuilding the account.

Distinguish permission, timeout and configuration errors

For an authorization or authentication message, check your account status in the user panel before updating the subscription. For a hostname resolution error, go to the next section and check DNS. For a connection timeout, note the route and time, then compare another route and another network. Error wording is a clue, not a diagnosis. A timeout can occur during DNS lookup, connection setup or the destination service's response; the word alone doesn't prove the remote service is at fault.

If other proxies, network filters or security software are running on the device, check which one is handling traffic. Temporarily pause nonessential network-handling features and try again, then restore the original settings when you're done. Don't disable management policies on a work device; ask the device administrator to check them. If the same configuration fails on multiple networks even after an update, include the exact error in a support request. That's more useful than saying “nothing works.”

Reinstalling shouldn't be your first step. It can erase rules, custom route selections and local diagnostic details without fixing an account or access-network issue. First save the configuration name, the stage where it fails and the results of your comparisons. If you do need to reinstall, get the client from the client download page, then restore the configuration using the setup guide. If the client won't start at all, note your operating system, where you got the installer and the system message, then continue with platform troubleshooting or contact support.

Connected but can't browse? Check DNS and the request path

A “connected” status means the connection feature is enabled; it doesn't mean every app is using that connection. Before a webpage can load, its domain usually has to be resolved to an IP address, a connection must be established, a secure handshake completed and the website must respond. A failure at any step can look like the same blank page. First note whether all sites are affected, only international sites, or just one domain. Then decide whether to check DNS, proxy handling or the destination website.

Use the error type to narrow things down

If your browser says it can't find the server or resolve the domain, start with DNS. If it reports a proxy connection failure, check the local proxy process and port. If there's a certificate or system-time error, correct the device's date and time zone before trying again. Don't bypass certificate warnings to test the connection or install certificates from unknown sources. A certificate error and a website's regional restriction are different problems; skipping the warning can hide a genuine configuration issue.

In the same browser, try different types of websites, then open the same domain in another installed browser. If only one browser has trouble, check its extensions, separate proxy settings and Secure DNS settings. If all browsers fail but other devices work on the same network, check DNS resolution and network filtering on the affected device. A browser's Secure DNS may use a different path from the client's DNS, so a successful system lookup doesn't prove the browser uses the same resolver.

How DNS settings interact

The operating system, browser and client may each have DNS settings. In rule-based mode, the client may also use a domain to decide where traffic goes. If an app resolves a domain before the client sees the request, the client may only see the destination IP, and some domain rules may not match as expected. Other configurations use mapped addresses to keep the domain associated with the request. If something isn't compatible, restore the subscription or client's default DNS settings first instead of stacking unrelated settings from different guides.

Before checking DNS, note any custom settings you've added, then undo recent changes one at a time. System defaults, client defaults and custom resolvers can all work, but they need to suit the current mode; there's no setting that works for every network. Avoid enabling multiple DNS-handling tools that do similar things. If some sites work after a change and others don't, note the affected domains and matching rules, undo the change and test again. This helps show whether the cache or DNS path changed.

Use system tools, but don't read too much into the results

To check DNS results, you can run the command below in a system terminal. It uses a public example domain; replace it with the domain of the affected site when troubleshooting. Don't include account details from the webpage. A returned address only shows that the resolver used by this command returned a result. It doesn't prove the result is suitable for the current route or that the website's secure handshake succeeded. If the command isn't available, just note the browser error; you don't need to install extra tools to troubleshoot.

nslookup example.com

After changing DNS settings, close and reopen the affected page. If needed, clear the DNS cache using your system's instructions, then restart the relevant apps. Don't clear all website data at once, since changes to login state can complicate troubleshooting. If only one site is still affected, check for an old manual address mapping and whether the client incorrectly routes that domain directly. For manual mappings, review only entries whose purpose you understand; don't copy an entire configuration file from an unfamiliar source.

If the same domain fails consistently across different networks and routes, include the domain, error type and matching rule in your support request. Don't send the full URL; session IDs and query parameters may contain sensitive information. VPNBaby doesn't keep logs. You can review diagnostic information stored locally on your device, but check and redact credentials before sharing it with support. If the page loads but says the region isn't supported, check the destination platform's policies rather than treating it as a DNS issue.

Slow speeds and peak hours: separate bandwidth from response time

First describe what “slow” means. A long wait before a page starts loading, images that keep loading, video buffering, slow downloads and slow AI responses can all involve different steps. Response time is more likely to be affected by the route, DNS or destination service. Sustained transfers also depend on the local network, remote connection and how the app manages traffic. Don't treat a client's route-probe result as your actual download speed, or use one app's performance to judge every service.

Start with a like-for-like comparison

Use the task you're actually having trouble with, such as the same webpage or video. Keep the device, app and network the same, change only the route, and note where the delay occurs. Then keep the route unchanged and check whether other devices are syncing, downloading or streaming at the same time. Backups and system updates can use your access network even when you only have a browser open. Pause nonessential transfers and repeat the same task to see what changed.

Check your Wi-Fi separately. Distance from the router, walls and weak coverage at the edge of a signal can cause retries and slow local transfers. Move closer to the router, or use a wired connection for comparison if possible. If improving the local network helps every route, focus on the access network first. Don't assume a route with a nearby-sounding name will be faster; the path between your current network and that route often matters more than geographic distance.

How to assess slowdowns at peak hours

If the problem happens mainly during busy periods, note your access network, route and app, then try the same task at another time. A slowdown at peak hours doesn't prove a particular part of this service is congested; home network sharing, the access provider, international paths and the destination platform can all change when traffic is high. If switching routes helps, use the one that works better on your current network. If switching access networks helps, investigate the local network and access provider first.

When comparing regions, keep the region required by the target app unchanged if possible. For example, if an account is consistently used in one region, compare the available routes in that region instead of switching regions repeatedly for a temporary speed boost. A platform may ask for additional verification based on the account and access environment, making troubleshooting more complicated. See the global network coverage page for coverage; the user panel shows the routes currently available to your account. Coverage figures can't replace a real test with your task.

Troubleshoot based on how the app behaves

For video playback, first distinguish a slow start from buffering that continues during playback. A slow start may involve DNS, account verification or content delivery selection; ongoing buffering points more toward sustained transfers and local bandwidth. Pause other downloads and lower the video quality in the app for comparison. If that helps, it only shows that the task is more sensitive to transfer conditions; it doesn't identify the exact bottleneck. For video quality and platform-region issues, see the Streaming guide.

If an AI tool's page and input box work but it takes a long time to respond after you submit, check whether the platform shows a queue, usage limit, service-busy notice or account message. Response generation speed isn't determined by the network alone. If static pages and other requests work but generation is slow, note the platform message and see the AI Tools guide to distinguish network issues from service-side status. Don't repeatedly clear account data or change regions to troubleshoot generation delays; that adds new variables.

Check your remaining data when troubleshooting speed. Monthly subscription data resets each month on the activation date. Data add-ons remain available until used and never expire; these are different reset policies. Check your plan and balance in the panel. See the pricing page for the details. Don't infer your account balance from the client's historical traffic counter, since its measurement range and billing calculation may differ. If the panel shows an unexpected status, note the message and contact support instead of assuming an undocumented speed limit.

Useful evidence is a comparison of the same task across routes, networks and times—not a pile of unrelated speed-test screenshots. Say whether background activity was paused, whether you used a wired connection, and whether the delay affected the first response or continued transfers. Don't expect or claim that every website will perform the same way; destination services can change too. Reproducible conditions help support more than a one-off fast or slow result.

Frequent disconnects and background drops: check runtime conditions

First distinguish “the client stopped” from “the client is still running but requests are failing.” If the system's connection indicator disappears or the client shows disconnected, check the process, permissions and network changes. If the indicator remains but apps temporarily won't load, the connection may not have recovered after a network change, or the current route may have an issue. Note whether the device was locked, switched networks, went to sleep or entered battery-saving mode before the drop. That's often more useful than just counting disconnects.

Troubleshooting a mobile device after locking the screen

Keep the screen awake first and repeat the task that usually fails. Then lock the screen, return to the app and compare. If the problem only occurs in the background or while locked, check the system's battery management, background activity and network restrictions for the client. Android settings vary by device and system version; look for battery, background activity and data usage in the app information page. Relax only the restrictions that affect the client; there's no need to turn off battery-saving settings for every app.

Some system cleanup features stop the client when they close apps. A setting to keep an app in the recent-apps list is different from granting system permission for a VPN connection: one affects whether the process stays alive, the other whether it can connect. After changing a setting, test the actual sequence—browse with the screen on, lock it, then return to the app. If it still fails, note whether the system says the client was stopped and whether you have to reconnect manually when reopening it.

On iOS, check that the VPN configuration shown in system settings matches the client you're using, and make sure another configuration isn't taking over. After switching clients, changing network settings or updating a configuration, you may need to establish the connection again. Don't enable multiple VPN configurations at once to compare them. Before using options such as on-demand connection, check the current client's documentation. Blindly enabling automatic behavior may make a reconnect after a manual disconnect look like a problem.

Network switches and desktop sleep

When a device switches from Wi-Fi to another access method, the existing connection may stop working because the local network address changed. Wait until the system confirms the new network can access ordinary websites, then reconnect in the client. If you need to reconnect after every switch, note the direction of the switch and the client's message, then check whether an automatic recovery option is available. Don't keep switching routes before network authentication is complete; you'll create more timeouts without learning whether recovery works.

After a desktop wakes from sleep, first make sure the network adapter is online, then check the client connection and system proxy. If the process is running but the local proxy isn't responding, disconnect and reconnect normally; you don't need to restart the whole device first. If this happens after every wake, check power settings, network adapter status and security software events. If your company's device policy controls sleep settings, ask the administrator before changing managed settings.

How to narrow down repeated disconnects

If disconnects continue with the screen on and the network unchanged, try another route while keeping the app task the same. If only one route fails, note its name and when it happened. If all routes fail, compare with another device. If that device is stable, check network filtering, permissions and client settings on the affected device. If all devices on the same network disconnect, compare with another network. This helps distinguish fluctuations in the access network from background keep-alive issues.

Don't enable every automatic retry option at once. Repeated retries can hide the original error, leaving you with a connection that keeps changing but no clear cause. Keep the default behavior first and note the client's original message when it disconnects. Then enable a specific recovery option if needed. If the system has settings to always use a VPN or block internet access when disconnected, make sure you understand what they do. Being unable to browse when a connection fails may be the intended behavior.

In a support request, say whether the problem occurred in the foreground, background, while locked or after waking from sleep, and whether other apps also lost network access. For Android background settings and per-app routing, see the Android background operation and per-app proxy guide. If only one app stops refreshing in the background while the browser works, check that app's background permissions instead of repeatedly changing the whole network setup.

Subscription update failed: check the source and configuration

Subscription updates and route connections are related, but either can fail independently. A subscription supplies configuration to the client; a route connection uses the loaded configuration to make requests. An old configuration that still works doesn't mean the subscription URL is still valid. A successful update doesn't mean your current network can connect to every route in the list. First note whether the failure happens during copying, importing, fetching, parsing or saving, then check that step.

Check the subscription source in the user panel

Open the user panel and check your account status and subscription options. No email address is required; create an account with a username and password. When troubleshooting, sign in to the account that holds your current service. Don't create accounts repeatedly because you can't remember which one you used. Being able to sign in and having an active plan are separate things; check the message on your account page before deciding what to do.

Use the panel's copy or import option instead of piecing the address together from chats, old notes or screenshots. Copying can introduce spaces, line breaks or explanatory text, leaving the client with an incomplete address. If you've reset the subscription, check the address saved on your other devices too. A subscription URL is a credential: don't post it publicly, paste it into online conversion tools or send it to group chats. Don't put the real address in a support request title just to demonstrate the issue.

Distinguish a fetch failure from a parsing failure

If the client times out while fetching, first make sure your current network can reach the panel. Then check whether the update request uses a direct connection or an existing proxy. If the existing configuration no longer works, forcing the update through that old proxy can create a loop: the client needs to connect before updating, but the old connection is unavailable. Keep the original configuration and use the client's update-path option for comparison. Don't delete the old configuration, so you have something to revert to.

If the client reports invalid formatting, a configuration parsing error or an unsupported field, check whether the import type selected in the panel matches the client. Clients don't all accept the same configuration formats; similar-looking addresses aren't enough to establish compatibility. Use the panel's entry for the relevant client, then check the configuration name and route list after updating. Don't remove large sections of unknown fields by hand: the file may load but its rules or DNS settings may break.

What to check after an update succeeds

After updating, check that the newly updated configuration is active, then check whether the route list and rules loaded. Some clients save a subscription in the list without switching to it; others let you save route selections separately from the configuration. If the client still uses an old route after an update, the update may have worked—the selected group may simply still have its previous choice. Confirm the active configuration name and matching records, not just the success message.

If the list suddenly gets shorter after an update, check search, region filters and collapsed groups first, then compare with the content shown in the panel. A static page's coverage information doesn't define which entries must appear in every account. VPNBaby covers 90+ countries / 160+ routes; the panel is the source of truth for what's available to your account and where to find it. If the panel and client differ significantly, note the configuration type, update time and missing entries for support to check.

If automatic updates fail but manual updates work, first check background network permissions, the conditions for scheduled tasks and whether the device was offline when the update ran. Don't set an overly aggressive update schedule; repeated requests won't fix an invalid address or incompatible format. Use a clear, easy-to-understand update method and confirm the client shows a recent successful update before continuing. For an overview of the basics, see Subscriptions, routes and rules: a quick glossary.

If updates fail on multiple devices and the panel can't provide the expected content either, stop importing repeatedly and contact support. Include the error text, client type, import method and steps to reproduce; don't send the subscription contents or full URL. If you think the address has been exposed, use the panel's reset option if available, then update your devices. Contact support if you're unsure what to do. Sending the address to other people to test repeatedly makes troubleshooting and credential management harder.

An app isn't using the proxy: trace its routing

If the browser works but one app doesn't, don't assume the whole route is at fault. The app may not use the system proxy, may choose its own DNS method or may be excluded by per-app rules. In rule-based mode, the client chooses an exit based on domains, addresses or other conditions. First check whether the app's traffic reaches the client, then which rule matches, and only then whether the selected route can complete the request. This order helps you avoid changing settings at the wrong level.

Check how traffic is routed through the proxy

A system proxy is used by apps that read that setting; it doesn't automatically cover every network request. Some desktop apps, command-line tools and isolated environments need their own proxy settings. Other setups require a network-handling mode supported by the client. Check the current client's features and permissions, then check the target app's network settings. Don't enter a remote route address as the local proxy address or guess the local listening port.

Terminals, virtual environments and containers may not share the desktop app's network settings. A website working in the host browser doesn't mean a program in a container uses the same route. Check for proxy settings in the environment where the error occurs and look for environment variables pointing to an old client. Remove only entries you know are no longer used, then restart the relevant process. Apps usually read these variables at startup, so changing system settings later may not update them.

Compare modes to identify a routing-rule issue

With the network and route unchanged, temporarily switch between the client's rule mode and global mode for comparison. If global mode works but rule mode doesn't, check rule matches and the default exit. If both modes fail, check whether the app's traffic reaches the client, as well as the destination service and route status. Global mode is a diagnostic tool, not a permanent fix for every issue. Restore the original mode when testing is complete so other traffic that should connect directly isn't rerouted.

When checking the local connection list, have the target app make a new request and look for the corresponding domain or process. If no related request appears, the problem may occur before traffic reaches the client. If a request matches a direct-connection rule, check whether the rule is correct. If it matches a proxy group, check which route that group actually selected. A group name doesn't tell you the exit: it may still point to a direct connection, automatic selection or an unavailable entry. Follow the chain to the final selection.

Check rule order and app exceptions

Rules usually match in a particular order. A broad rule near the top may match before a more specific rule below it. Check whether recently added rules override specific domains, and remember that an app's login, static resources and APIs may use different domains. Adding a rule for the app's homepage doesn't mean every request is covered. Start with the rule system in your current configuration, and add a narrowly scoped exception only when you've confirmed what's missing. Note why you changed it.

For Android per-app proxy settings, check whether the list means “only these apps use the proxy” or “exclude these apps.” The two options are easy to confuse, and a checkmark doesn't necessarily mean proxying is enabled. Fully close and reopen the target app after changing the list, then check the path of a new request. If the app also exists in a work profile, cloned-app space or separate user, confirm which instance the settings apply to. A change in the main profile may not affect the others.

If the target app reports a region restriction, account risk or unavailable content, treat these as separate issues. If a request reached the platform, the problem may not be that it bypassed the proxy. Account region, billing details, platform policy and content licensing can still affect the result. For streaming, see the guide to Japanese anime and streaming routes. Don't use frequent region changes as a substitute for troubleshooting, or mistake an account error from the platform for a route connection failure.

If custom rules stop working, first export notes about your changes, then compare with an unmodified configuration. Don't upload a full configuration containing credentials to an unfamiliar online tool. If the original configuration works, restore only the changes you need, one at a time. If it has the same problem, note the app, requested domain, matching rule and selected exit, then contact support. For an overview of routing, global mode and routes, see the beginner's glossary before changing settings.

Platform differences and device messages: check the source of the status

VPNBaby supports Windows / macOS / iOS / Android / Linux, with unlimited simultaneous devices. If you see “too many devices,” “already connected” or a similar message, don't assume VPNBaby has a device limit. The message may come from the operating system, another client, the target app or a local connection profile. Note the exact message and where it appears: the user panel, client, system settings or destination website.

Unlimited devices doesn't mean local connections can't conflict

The number of devices and how network traffic is handled on one device are separate issues. A system may not allow multiple VPN configurations to work as expected at the same time, and proxy tools may compete for the same local listening address. If another tool is already handling network traffic, a new client may show a connection or permission error. That doesn't mean you've reached an account device limit. Disconnect the other connection normally before enabling this client; running multiple tools at once won't improve your chances of connecting.

Also distinguish limits imposed by the target app. Video, work and other account services may manage their own signed-in devices, independently of VPNBaby's simultaneous-device policy. If the error appears only in the target app, check its account page and message. If it appears in the user panel or VPNBaby client, save a screenshot and contact support. Don't create another account or choose a different plan just because the message is vague.

On desktop, start by checking system-level network handling

On Windows, first check whether the client is still running, then check whether the system proxy points to it. If the browser works but another program doesn't, check whether that app reads the system proxy. If security software blocks network handling, look for a specific notification or event rather than disabling all protection. On a managed device, a policy may restore system settings after you change them. Ask the administrator to check permissions if settings keep reverting.

On macOS, the client opening successfully doesn't mean its network extension or required system permissions are enabled. Follow the system prompts to grant permission, reconnect and test the target app. If you've uninstalled other network tools, check whether their network configurations remain, but only remove entries whose source you can identify. On Linux, desktop proxy settings and terminal environment variables may be separate. A running service doesn't mean the current desktop session is using it.

On mobile, check permissions and configuration

On iOS, first make sure the system VPN configuration belongs to the client you're using, so an old configuration doesn't switch on again. New users can follow iPhone: from importing a subscription to verifying the connection and check the configuration, permissions and connection in order. Get the client through the panel. The iOS download option shown there depends on your plan status; don't install apps from unknown sources using instructions on a static page.

On Android, in addition to background policies, check whether the current client is allowed to create a VPN connection and whether the per-app list accidentally excludes the affected app. Different user profiles on the same device may have separate permissions and app lists. Check the profile where you use the target app before comparing connections. On other platforms, sign in and get the client and related instructions from the client download page. Subscriptions are available after sign-in; don't substitute a forwarded installer link for the official entry point.

If all devices on the same account show the same service-status problem, check the panel first. If only one platform is affected, check its permissions and configuration. If the same device behaves differently with another client, don't immediately conclude that the original client is defective. Compare network-handling modes, DNS settings and the active configuration first. Results from comparisons with different conditions may not be reliable.

When describing a device issue to support, the operating system, client name, permission message and stage where it occurs are usually enough. Don't send device serial identifiers, system passwords or a complete network configuration. If the error explicitly mentions a device limit, quote it exactly and say where it appeared. VPNBaby allows unlimited simultaneous devices; there's no need to verify that by upgrading to a paid tier. Identify who issued the message before deciding who should address it.

Support requests and configuration recovery: keep the evidence

Troubleshooting doesn't always end with a fix you can make yourself. You may have isolated the problem enough for support to investigate. Contact support if subscription updates fail across multiple working networks, the same route consistently fails on different devices, the panel status doesn't match the service, or an unmodified configuration reproduces the same error. Reinstalling, clearing settings or repeatedly switching regions at this point may destroy useful evidence.

Describe the issue in a reproducible way

Start with the expected result and what actually happened. “The browser opens the homepage, but requests fail after sign-in” is more useful than “the website is broken.” “After locking the screen and reopening the app, the client shows disconnected” is easier to assess than “background operation is unstable.” Then describe the steps, time and time zone, type of access network, client and operating system. If you need to provide version information, copy what's shown on the device rather than estimating or using details from another device.

Next, list the comparisons you've already tried and say what you changed each time. For example, note whether another route or network helped, whether another device on the same account works, and whether the original and customized configurations behave differently. If you haven't run a comparison, say so. Don't guess to make the support request look complete. Support needs to know the limits of the evidence, not a confident-sounding conclusion mixed with assumptions.

Redact local diagnostics before sharing

VPNBaby doesn't keep logs. That's separate from whether your device has a local diagnostics screen: the client may show connection errors, matching rules or request status for you to troubleshoot. Don't enable overly detailed diagnostics for an extended period just to ask for help, and don't export the full log. Share only the relevant error near the time the problem occurred, and redact subscription URLs, credentials and personal browsing details.

Check the edges of screenshots too. They can accidentally reveal account names, clipboard notifications, browser tabs, query parameters or content from other windows. For a website issue, the domain and error type are usually enough; you don't need to send a full URL containing your session. For an order, provide the details needed for support to identify it and hide unrelated payment information. Don't post an unredacted screenshot in a public comment or chat and then forward its link to support.

A ready-to-use report outline

Use the outline below to organize details; you don't need to fill in every field. Write “not sure” for unknowns and “not tested” for comparisons you haven't made. Use the route name exactly as it appears in the panel; don't invent a route type or city. For an app issue, add the app's message and the stage where it fails. For a network switch, note the client's status before and after. This gives support a clear path to continue the investigation without starting with broad questions.

Issue:
Time and time zone:
Operating system and client:
Access network type:
Current mode and configuration name:
Selected route:
Exact error message:
Result after switching routes:
Result after switching networks:
Result on another device:
Settings changed recently:
Relevant screenshots with credentials redacted:

After submitting your request, keep the configuration that still reproduces the problem and avoid making major changes in multiple places at once. If you fix it yourself later, update the original request with the last action you took before it recovered rather than just saying “fixed.” If support asks you to test a setting, record its original value, the new value and the result, then check whether it should stay changed. Revert temporary settings that serve no clear purpose so you don't have to guess what they were for next time.

After recovery, test your normal workflow

Once the connection is restored, repeat the task you actually need instead of relying on the connection icon. Check the browser, target app and apps that should connect directly. Confirm that rule mode, the selected route and background behavior suit your everyday use. If you switched to global mode, paused security software, changed background policies or modified DNS to troubleshoot, verify each setting and restore it as needed. A brief record of changes is more reliable than trying to remember them next time.

If the problem is actually related to your plan, compare monthly subscriptions and data add-ons on the pricing page, then use the panel as the source of truth for your account status. Monthly subscription data resets each month on the activation date; if you upgrade mid-cycle, the price difference is converted to the remaining days. Data add-ons remain available until used and never expire. The service offers a 14-day no-questions-asked refund; see the Terms of Service for the application rules. A temporary recovery during troubleshooting doesn't mean your plan includes an extra benefit, and you don't need to upgrade just because the issue is unresolved.

Keep the configuration that works reliably as a baseline for future comparisons. If the same symptom returns, check your network, system permissions and recent changes first, then follow the relevant steps in this guide. For a new device, start with the setup guide. If the connection works but an app behaves unexpectedly, return to the routing or DNS sections. This guide isn't meant to make every user an expert on every setting; it's here to give each check a clear starting point, useful evidence and a sensible stopping point.