Troubleshooting Guide

Can’t Connect at All: Separate Network Issues from Client Issues

“Can’t connect” can mean the client won’t start, the subscription list is empty, the Connect button shows an error, or a connection succeeds but websites still won’t load. These point to different parts of the setup. Note where things get stuck and copy the full error message, then follow the relevant checks below. A connection status only tells you how far the local app has progressed; it doesn’t confirm that websites or apps actually work. Likewise, one inaccessible site doesn’t prove that every route is down.

First, make sure your device is online

Disconnect the service temporarily and open a website you can normally access. If regular websites won’t load either, check whether you need to sign in to the Wi-Fi network, whether your router has internet access and whether your device reports a restricted connection. Public Wi-Fi may require accepting terms in a browser; the client can’t complete that step for you. Restore your regular connection before reconnecting, so a local network issue isn’t mistaken for a route problem.

Next, try another trusted network on the same device without changing the client settings. If the connection works on the new network, check the original network’s sign-in requirements, access policies or router settings. If it fails on every network, check client permissions and account status. Networks managed by your workplace or school may have specific usage rules; ask the administrator what’s allowed rather than trying to disable those policies. Changing only the network makes the comparison more useful than changing the device and route at the same time.

Check whether the connection is actually established

Open the client’s connection log and check what appears after you tap Connect: a permission denial, an invalid configuration, an unreachable destination or a timeout, for example. For a permission error, check system authorization; for a parsing error, check the subscription; for a timeout, compare routes and networks. Don’t search for a single word in the error and blindly copy a set of settings. The same timeout can come from your local network or a destination that isn’t responding; use the surrounding log entries to narrow it down.

If your device asks to allow a network connection or add a VPN configuration, verify the app’s source and grant permission. If you denied permission earlier, check the app’s network permissions in system settings. On a managed device, you may not be able to change this setting; stop retrying and ask the administrator. A common reason the Connect button appears to work but no connection is made is that the app hasn’t been allowed to create a system network interface.

Rule out proxy conflicts, then compare routes

Check whether other proxy clients, browser proxy extensions or network-filtering apps are running at the same time. Note their current state, pause one tool that might be handling traffic, then test again. If several tools change the system proxy or virtual network adapter, traffic may be sent to the wrong local port. Don’t remove security software or leave system protection disabled. If a comparison confirms a conflict, check the relevant app’s compatibility settings or ask an administrator for help.

Once you’ve confirmed your account has an active subscription, compare routes in different regions from the current subscription list. Start with the original route and one in another region, rather than repeatedly switching between similar names in the same region. BaiVPN offers 120+ countries / 160+ routes. This gives you options; it doesn’t guarantee access to every destination. See the routes page for route types and selection tips. The routes available to you are those shown in your account.

When to stop: Your regular connection works, system permissions are granted, the subscription is visible, but routes in different regions fail at the same stage. Save the connection log and submit a support ticket; this is more useful than repeatedly reinstalling the client.

Connected but Can’t Load Websites: Troubleshooting

If the client says it’s connected but websites won’t load, separate the issue into DNS resolution, traffic routing and the destination’s response. DNS translates a domain name into a network address; the proxy determines where a request goes; and the website may check your account, region and its own service status. A failure at any stage can look like a browser timeout or error page. Note the specific error—server not found, connection timeout, certificate warning or an explicit access restriction—so the next steps don’t get mixed up.

Compare different destinations and apps

Keep the same route and try a regular website, the destination that failed, and another browser. If regular sites work but one destination doesn’t, check its service status, regional requirements and account messages. If it works in a browser but not in an app, see the app-routing section. If every domain-based request fails while the client log still shows traffic being routed, focus on DNS. Don’t mistake one platform’s maintenance or login issue for a general connection problem.

If you see an error about a certificate’s date or issuer, first check your system’s date, time and time zone. Then make sure you aren’t still on a network sign-in page. Don’t ignore certificate warnings or install certificates from unknown sources to restore access. A browser certificate error is different from a DNS error; clearing the DNS cache usually won’t fix it. Save the error text—it’s more useful than simply reporting a blank page.

Check which service is handling DNS

The system, browser and client may each have their own DNS settings. A browser using secure DNS may take a different resolution path from the system; a client that offers remote resolution or DNS interception may also change the result. Check the current mode first instead of enabling every resolution option at once. Restore the client’s recommended defaults and test, then review extra settings one at a time. If the issue occurs in only one browser, check its extensions, proxy and secure DNS settings first.

You can use a system command to check whether a domain resolves, but its query may not follow the same path as your browser or client. The example below queries a public example domain and contains no account information. On Windows, run it in Command Prompt. macOS and Linux usually include the same lookup command; if the tool isn’t installed, skip this step rather than installing unfamiliar software just to troubleshoot.

nslookup example.com

Note whether the command returns an address, times out or can’t find the domain; don’t treat any returned address as the one permanently correct answer. Results can vary by network, cache and service routing. A successful lookup only confirms that this query got a response; it doesn’t prove the website is reachable. If the command succeeds but the browser still fails, compare the browser’s own DNS and proxy settings rather than blindly changing system DNS again.

Clear the cache only when there’s a reason

If you’ve just changed DNS settings, fully quit and reopen the browser, then reconnect the client. On Windows, if you’ve confirmed that the system DNS cache needs clearing, run the command below. It clears only the local cache; it won’t fix subscription, route or website account issues. Cache management differs across platforms, so don’t mix commands intended for other operating systems.

ipconfig /flushdns

If restoring the default DNS settings brings regular websites back but a particular service remains unavailable, note that service’s error page and the route region together. If lookups keep timing out on one network but work after switching networks, focus on the original network. If DNS issues occur on every network, send support a screenshot of the client’s DNS settings and relevant error logs. Hide your subscription URL and any account credentials before sharing screenshots.

Don’t start by entering a random DNS address, disabling certificate checks or resetting all network settings. Find out which layer is handling DNS, then change the settings at that layer.

Slow Speeds and Peak Hours: Compare the Network Path

“Slow” can describe several different things: a webpage taking a long time to open, video buffering, downloads slowing down or an AI response taking ages. Describe what’s affected first, then note when it happens and which route you’re using. Wider regional coverage doesn’t mean a more distant route will be faster. The destination’s hosting location, network congestion, Wi-Fi signal and background tasks can all affect performance.

Rule out local bandwidth and Wi-Fi interference first

Check whether your device is syncing files, installing updates, uploading photos or downloading large files. Other devices on your home network may also be using bandwidth; sustained uploads can especially slow down webpage responses. Pause background tasks you control and compare again using the same app. If possible, compare a wired and wireless connection on the same network. Don’t change networks, client modes and destinations all at once, or you won’t know what helped.

Disconnect from the service and check whether regular websites are also slow. If local browsing is slow too, troubleshoot the network connection first. If only destinations through the service are slow, compare routes. You don’t need to turn every test into a speed-test number; completing the same real-world task is more useful. For example, open the same page, play the same clip or repeat the same request without sensitive information, and note whether there’s a consistent difference.

Choose a route based on the destination and route type

Start with the destination’s regional requirements, then try a nearby region. Labels such as IEPL dedicated line, relay and direct connection describe different route setups; they aren’t a fixed speed ranking for every user. A direct route is simpler, but can still be affected by your network. A relay adds another leg and may improve performance on certain networks. A dedicated line also needs to be assessed across the entire path, from your device to the entry point and from the exit point to the destination.

Available route types depend on your subscription. See the route guide for more selection tips. Keep the original route as a baseline, switch to a route with a different path, then reopen the target app. Some apps reuse existing connections, so a switch may not establish a new session and the app may still be using the previous path. Don’t switch repeatedly in the middle of playback and judge a route by a brief buffering pause.

Tell peak-hour congestion apart from delays at the destination

To identify a peak-hour issue, compare the same task at similar times—not different dates and websites. If things work during the day but several routes slow down in the evening, while your regular connection is also affected, congestion on your network is more likely. If only one route fluctuates at night and a different path improves things, use the more stable alternative for now and give support the original route and time of the issue.

Slow AI responses don’t always mean slow network traffic. If the page and history load normally but generation takes a long time, check for messages from the service and any account notices. Video buffering on only certain titles may also be related to content delivery. Describe “page loads,” “generation starts” and “content keeps streaming” separately so support can tell whether to investigate the network or the destination.

Don’t upgrade your plan just because of a brief slowdown. Monthly subscriptions and data packages address billing and data needs; they aren’t a general fix for congestion. Check your account overview to review data usage, and see the plan details when comparing plans. For a persistent issue, include the original route, an alternative route, your network and what you were doing in the support ticket—not just “the speed is bad.”

Frequent Disconnections and Mobile Apps Closing in the Background

First distinguish a dropped tunnel from an interrupted app session. A tunnel drop usually appears in the client log as a reconnect, network-interface change or connection failure. An interrupted app session may simply mean an app needs you to sign in again, a video stopped or a request timed out. Background behavior can change when a device locks its screen. Note whether the disconnection follows a screen lock, network switch, sleep or battery-saving mode before deciding whether to check the system or route.

Match disconnections to system events

Note what was happening beforehand: Did the device just wake from sleep? Did it leave its previous Wi-Fi network or move to an area with a weaker signal? When the network changes, the original connection needs to be re-established, while an app may still hold an expired session. First confirm that the client has reconnected, then reopen the app. If the client recovers but the app still shows an error, investigate the app session rather than assuming the route failed to reconnect.

If the device stayed in the foreground and the network didn’t change, check the connection log to see whether only one route is affected. Try a route with a different path under the same conditions. If switching routes resolves it, note the original route and send it to support. If different routes all disconnect after the same action, the cause is more likely device network management, client state or the local network. Don’t hide the trigger by repeatedly tapping Connect.

Android: Check background and battery settings

Some Android devices restrict background app activity. Open the app settings, find the client’s battery and background-activity options, and check whether it’s under strict restrictions. Setting names vary by device, so follow the system’s guidance. Adjust settings only for a client that needs a persistent connection; you don’t need to allow every app to run in the background. After making a change, repeat the same lock-and-unlock test and check whether the client state or connection log changes.

If your device has automatic cleanup, app-sleep or data-saving features, check whether they might stop the client. Seeing an app in the recent-apps list doesn’t necessarily mean its network process is still running; closing its interface doesn’t necessarily mean the system connection has dropped. Compare the system VPN status with the client log. If your device is managed by an organization, don’t try to remove that management—ask what background activity is allowed.

iOS and desktop: Check network switches and wake-up

On iOS, first make sure the active system VPN configuration belongs to the client you’re using; an old configuration can be confused with the current one. When an issue occurs, check the system connection status, then look for an error in the client. If it happens only when switching between Wi-Fi and mobile data, test on a stable network first. Don’t copy Android battery-whitelist steps or disable system-wide security protections just to keep the connection active.

Sleep, closing a laptop lid and network-adapter changes can also interrupt connections on Windows, macOS and Linux. After waking the device, confirm that your regular connection is back before reconnecting the client. If the problem occurs only after sleep, note the order in which the network recovered and the client reconnected. For macOS authorization issues, see the Mac VPN setup and permissions guide. A single failed wake-up isn’t a reason to delete every existing configuration.

When to ask support to investigate

If different devices and routes all disconnect during use on the same network, include when it happened and what was affected. If only one device is affected, include its platform, the version shown in the client and its background-management status; use the version displayed in the app rather than guessing. Logs should cover the period before and after the disconnection, not just the successful reconnection. Support needs to see what triggered it to distinguish a network switch, system cleanup and remote disconnection.

Keep a working route available: Once you’ve found a stable alternative, you can keep using it while preserving the original issue details. Troubleshooting doesn’t require leaving your device in a broken state.

Subscription Update Failed: Check Retrieval and Parsing

Subscription updates and route connections are separate requests. A failed update doesn’t necessarily disable routes already imported, and a working route doesn’t mean the subscription can refresh successfully. Check whether the client reports a download failure, authentication error, empty content or parsing error. Don’t delete existing settings before confirming your account status and update method. If a route still works, preserve that working setup while you troubleshoot the subscription.

Check your account to confirm the subscription is active

Open your account overview and check your current subscription and data status. Payment completion, order status updates and client refreshes may need to be checked separately; a payment app’s confirmation alone may not tell the full story. If an order looks wrong, check its record in the dashboard and contact support rather than creating another order. Keep the order ID if needed, but don’t share your payment password or full payment account details.

Monthly subscription data resets each month on the activation date; don’t calculate the reset based on the calendar month. If you upgrade mid-cycle, the price difference is prorated by the remaining days; check your account for the current status. Data packages don’t expire and remain available until used, but that doesn’t mean service continues after the data is gone. If your account has run out of data, changing DNS or reimporting the configuration won’t add more. Compare billing options on the plans page.

Tell a blocked request from unreadable content

A download failure usually means the client hasn’t received the subscription content. First make sure your regular connection works, then check whether the current proxy mode is handling the update request. Some clients let you choose how subscription updates connect, but names and defaults vary. Note your current setting and test according to the client’s help; don’t assume every update must go through the proxy. If the client has no such option, don’t try to add a configuration field yourself.

A parsing error means the client may have received the content but can’t read it in the expected format. Common causes include extra spaces when copying, an incompatible import method or using a login page as subscription content. Go back to the user dashboard, use the current import option and confirm that it matches your platform and client. Don’t paste your full subscription URL into a public forum, online conversion site or unknown diagnostic tool; it usually contains access credentials.

Replace the configuration and retry safely

If you need to import again, first note the existing configuration name, commonly used routes and any manual settings, then use the current import option in the dashboard. After importing, confirm that a route list appears and test the connection before deciding whether to remove the old configuration. A matching configuration name doesn’t prove the update worked; check the client’s update time or content status instead, without sharing the full configuration. If the old configuration works but the new one fails, keep both and give support the differences in their errors.

If the client reports an authentication failure, confirm that you’re using the current account’s import option and check whether you reset the subscription in the dashboard. Don’t guess credentials or manually edit URL parameters. An old URL may stop working after the account entry is refreshed, so use the one currently shown in the dashboard. If you think your subscription URL was exposed, stop sharing it, use the dashboard’s available security features and contact support to confirm what to do.

Give support the details of the update error

In your support ticket, say whether a manual or automatic update failed, whether your regular connection works, whether existing routes still connect and what the full error message says. You can attach a screenshot of the subscription settings with the URL hidden. Don’t send only a screenshot of a red error box; without context, support can’t tell a failed network request from a formatting issue. If updates require you to be logged in, say whether the dashboard opens normally; there’s no need to provide your password.

If you’re unsure how to import for the first time, return to the quick-start guide or read what to do after getting started. This section covers update issues when you already know where to import from. Repeatedly refreshing usually won’t change the cause; save one complete error record and follow the relevant troubleshooting path.

Only One App Is Failing: Check Routing and Sessions

If your browser works but one app doesn’t, check the app’s network path. It may use its own proxy settings, additional domains, background services or long-lived connections. Rule-based mode may handle only some requests. Keep the same route, compare the service’s public website in a browser, then distinguish a sign-in failure from content that won’t load or a transfer that stops midway. Don’t assume every issue means the app isn’t using the proxy.

Find out which route the app is using

If the client provides connection logs, open the target app and check which rules matched its requests, which route they used or whether they were marked as direct. A missing request in the log doesn’t necessarily mean the app sent no traffic; the current mode may not be handling it. First check whether the client uses the system proxy, an app-specific proxy or a virtual network adapter. Then check whether the target app supports or follows that method. Features vary by client; use the options shown in yours.

System proxy settings don’t apply to every app. Some apps follow them; others use their own networking stack. Browser extensions usually affect only the browser and won’t change the route used by other apps. If the client offers a more comprehensive way to route traffic, check the required system permissions and compatibility limits before enabling it. Don’t enable multiple proxy methods for one app at the same time, as they may duplicate or override each other.

Use a temporary comparison to check whether rules are involved

If your client supports it, temporarily compare with a more comprehensive proxy mode. If the app works in that mode but not in rule-based mode, check the rule match and relevant domains rather than assuming the route itself has failed. Note the difference, restore your usual mode and check the client’s rule-update options. Don’t import a full ruleset from an unknown source, or assume adding the main domain you see on screen covers every request.

Sign-in, images, audio and video, and real-time communication may each use different service addresses. If the main page works but uploads fail, look at the requests made during an upload. Work devices may also need direct access to internal addresses, and temporarily routing everything through a proxy could disrupt internal services. Save your work before testing, and don’t change modes during an important meeting or file upload. If your device is managed by an organization, follow its approved troubleshooting process.

AI and streaming services have their own requirements

People searching for “ChatGPT not loading” may be facing a network timeout, a sign-in session issue, regional availability or an account restriction. If the site displays a specific account message, the request has reached at least one part of the service; read the message before drawing conclusions. Switching routes may change your exit region, but it won’t change the platform’s account requirements. For access guidance, see the AI Tools guide. Loading the homepage doesn’t mean every feature will work.

Streaming platforms determine library availability and playback access; your route region is only one factor. If the homepage loads but a particular title won’t play, check the message, your account permissions and the service region in use. Don’t treat one successful playback as a guarantee that the entire platform will keep working. After switching routes, an app may still be using an old connection or cached data. Exit playback, reconnect and test the same title to check the new route.

Be careful when clearing cache and session data

First fully close and reopen the app; if needed, compare in a browser private window. A private window can help distinguish some browser-cache and session issues, but it doesn’t change the network route or guarantee that a platform will reassess your region. Clearing app data may remove local files, sign-in state or unsynced content, so read the system warning first. Don’t make clearing all data a routine step after every route switch.

If only one app keeps failing, include its name, the action that fails, your browser comparison, the current proxy mode and any relevant rule matches in your support ticket. Keep the error message visible in screenshots, but hide chat content and account details. If the log shows that the request was routed successfully but the destination returned an account or permission error, contact that service through its official support too. Network support can’t change your account status on another platform.

Multiple Devices and Platform Differences: Don’t Mistake an Issue for a Device Limit

BaiVPN has no limit on the number of devices that can be online at once. If you see a “device limit exceeded” or similar message, don’t assume BaiVPN has the same device restrictions as another service or start removing family members’ devices. Check whether the message came from the account dashboard, the client, a system network component or the destination website. A message about “connections” might refer to app sessions, imported configurations or a destination service’s own limit—not necessarily BaiVPN’s simultaneous-device policy.

Distinguish device limits from shared resources

Unlimited devices doesn’t mean each device gets a separate data allowance. Check the subscription and remaining data shown in your account, and consider everyone’s download, sync and video needs before sharing access with family members. If everyone experiences slowdowns at once, check your home connection and background tasks first; if only one device fails, focus on that device. Don’t assume you’ve hit a device limit just because the issue began when another device came online.

If you see an explicit limit message, save its exact text and the page where it appeared. Check whether you’re using an old service configuration, a subscription from another account or an incompatible client. Don’t edit unknown configuration fields to “remove a limit.” You can sign out of the wrong account and check the current import option in the dashboard, but note the existing state first. For more on the difference between simultaneous connections and device binding, read the guide to using multiple devices with family.

Find the right checks for your platform

Supported platforms are Windows / macOS / iOS / Android / Linux. Support for a platform doesn’t mean that every system uses the same permission names or proxy methods. Troubleshoot using the client you installed and the settings shown on your device; don’t copy another platform’s steps word for word. The table below helps you find where to look, but doesn’t replace the client’s own documentation. If an option isn’t there, note the difference rather than looking for an unknown script to add it.

If regular websites stop working after you quit the client on Windows, check whether the system proxy still points to a local service that has stopped. First make sure no other app relies on that setting, then restore a configuration appropriate for your network. On macOS, check whether the system is still waiting for you to authorize a network extension. Don’t try to fix either issue by randomly deleting network adapters or all system settings; that can disrupt a connection that was working normally.

Troubleshoot Linux, terminal and router setups separately

On Linux, desktop apps and terminal processes may use different proxy settings. A terminal session may also keep old environment variables. A working browser doesn’t prove command-line tools use the same route. Check the proxy documentation for the tool you’re using, including variable names and scope. Don’t put a subscription URL in a proxy-server field; they serve different purposes. In a corporate development environment, check that changes won’t affect internal package repositories or services.

Router-wide routing also depends on hardware, firmware and compatibility with traffic rules. Support for the platforms listed in the service facts doesn’t guarantee compatibility with every router. If you’re considering a whole-home setup, read the trade-offs between router-wide and single-device connections. To troubleshoot an existing issue, compare by using the device’s own client first. Confirm whether the problem occurs only on the router path before reflashing the router.

Tell a device issue from an account issue

If the same account works on another device, then the account and at least some routes are usable together; focus on the affected device’s permissions and connection logs. If every device fails, check what they have in common: account, data and network connection. Say which devices work and which don’t; you don’t need to share family members’ identities or personal files. If the dashboard shows a message that conflicts with the unlimited-device policy, quote it exactly in a support ticket so the team can investigate.

Support Tickets and Recovery: Hand Over Clear Findings

A useful support ticket doesn’t dump every settings screenshot on the team; it explains where the issue occurs, what you’ve ruled out and how to reproduce it. If you’ve reached a clear stopping point in the checks above, submit a ticket through the account dashboard. You don’t need to wait until the service is completely unusable. If you have a stable alternative route, keep using it and describe the issue with the original route.

Describe the symptoms, scope and trigger

Use a specific title, such as “Client disconnects when screen locks; manual reconnect needed after unlocking,” rather than “It doesn’t work.” Start by saying whether your regular connection works, then explain whether all websites, one app or one route is affected. Note any recent network changes, rule adjustments, client upgrades or subscription reimports. Include only what actually changed; there’s no need to guess at a server-side cause.

Use the time recorded on your device and include the time zone. Find your platform and client version in the settings screen. Copy the route name from the current subscription instead of using a remembered nickname. If the issue occurs only in a particular environment, describe that environment without sharing your home address, workplace or full Wi-Fi network name. Support needs the connection conditions and sequence of events, not unrelated personal details.

Include comparison results that can be reproduced

Describe each test in terms of what you changed and what happened. For example, switching the same device to another network fixed the issue, or the browser worked on the same network while app sign-in failed. If you changed DNS, proxy mode or background settings, say whether you restored the original settings. If you haven’t run a check, say so; don’t invent a result to fill out the list or further troubleshooting may start from a false assumption.

A useful ticket includes: current symptoms; when they started and the time zone; system platform; client version as shown in the app; route name; network type; full error text; tests and results; and whether an alternative route works. Hide sensitive information in logs and screenshots before sending them.

Include logs covering the time before and after the failed action, preferably exported using the client’s built-in tool. Before sending, check for subscription URLs, authentication details, account passwords, browsing history and personal file paths, and hide anything sensitive. Don’t post full logs in public comments or upload a real subscription to an external diagnostic site. Keep the error type, event order and relevant setting names visible; otherwise, the logs won’t help identify the issue.

Keep track of configuration changes while you wait

After submitting a ticket, try not to change many settings in quick succession. If you continue testing, add the new conditions and results to the same ticket and note that they occurred after submission. This keeps the troubleshooting timeline clear and avoids contradictions between separate reports. If support suggests a change, confirm what it will affect, then test it step by step. Before clearing a configuration or resetting network settings, save what you need and make sure you know how to restore it.

If your subscription details have been exposed, an unfamiliar configuration has appeared or your account status has changed, stop sharing the affected information. Use the account security features available in the dashboard, then explain the situation in a support ticket. An email address isn’t required to create an account; you only need a username and password, so keep your login details safe. Support should never need your password or ask you to post a real subscription URL publicly. Check with support before taking any action you’re unsure about.

Confirm what’s working again—and what isn’t

Once service is restored, test the original scenario rather than relying on the client’s connection button. For a website issue, revisit the same destination; for a background disconnection, repeat the same screen-lock process; for a subscription issue, confirm the update succeeded and a route works. If switching to an alternative route fixed things, say that the original route hasn’t been verified. Don’t describe a workaround as a complete fix. Add your test results to the ticket so future recurrences are easier to identify.

If you decide the service isn’t right for your needs, review the refund policy and terms of service. BaiVPN offers a 30-day no-questions-asked refund. Submit your request through the relevant account option and follow up in a support ticket. This guide doesn’t replace the terms or add refund conditions. Before choosing a service, read the VPN buying checklist to compare coverage, billing and support policies.

If a similar issue comes up again, start with the relevant symptom section, but don’t assume the cause is the same. Keep a short personal troubleshooting note with your normal client mode, working routes and any important permissions. That’s more useful than memorizing a list of temporary commands. The goal is repeatable, reliable service and a clear description of anything that remains—not changing every setting along the way.