Can’t connect at all? First check setup and servers
First, identify where the client gets stuck
“Can’t connect” can mean the client won’t open, the subscription list is empty, a server is selectable but won’t connect, or the client says it’s connected while websites remain inaccessible. Each points to a different part of the process. Open the client and note the last step you completed, the exact message on screen, and whether the issue affects every server or just one. Don’t delete the configuration or reinstall repeatedly right away: that can erase the subscription source, the last successful connection state and useful error messages.
If the client itself won’t start, first check whether your system has granted network extension or connection permissions, then confirm that the client is compatible with your device. VPNBW supports Windows, macOS, iOS, Android and Linux; permission settings and background behavior vary by system. If the client opens but shows no available servers, go to the subscription updates section to check the import and account status. An empty list doesn’t necessarily mean there’s a server issue.
Narrow it down with comparison tests
If the server list looks normal but the connection keeps timing out, first disable other network-level tools running on the device and leave only the current client enabled. Then try a server in a different region, and test on both your current network and another available network. Change one thing at a time: if switching servers on the same device works, the original server may be the issue; if switching networks works, the cause may be your local network or connection method. Only if every server fails across different networks should you focus on client permissions, subscription validity and account status.
When switching servers, don’t rely on region alone. Check whether the list actually reloads and whether the client still shows the previous connection state. Disconnect first, select a new server and reconnect. If the interface remains stuck on the old status, fully quit and reopen the client. Then check whether it clearly reports a successful connection. A status-bar icon alone doesn’t confirm that the selected server is handling the traffic you expect; likewise, being able to select a server doesn’t mean a connection has been established.
Follow this sequence: “Can the client open? → Is the server list populated? → Can a connection be established? → Can you access websites after connecting?” Identify the failing step before moving to the relevant section. This helps avoid repeatedly changing settings that aren’t related to the issue.
Check permissions instead of reinstalling blindly
Your system may ask you to approve network configuration, a system extension or background access. If permission was previously denied, you’ll usually need to allow it again in system settings; repeatedly clicking Connect in the client won’t override a system-level denial. On macOS, distinguish between having the app installed and having its network extension approved. See the Mac VPN setup guide for related steps. On Windows and Linux, check whether your user account has permission to establish network connections and whether another active proxy configuration remains in your system network settings.
Finally, check the subscription status in your account panel rather than relying only on the server names cached by the client. An old list may still show previously imported regions, but that doesn’t prove the current subscription can be retrieved. If the panel is accessible and the subscription is active, but the client still can’t connect across different networks and multiple servers, keep the original error message and prepare a support ticket. Don’t include your full subscription URL or password. Support will usually need the time of the issue, platform, server region and error message to investigate.
Connected but can’t open websites? Check the route and DNS
Treat connection status and access results separately
A connected status means the client completed its connection steps; browser requests still depend on system proxy settings, app-specific settings, domain resolution and the destination website. Try several sites you can normally access and note whether all pages fail or just one domain. If your browser works but other apps don’t, start with the one app only section. If every app fails, check the system proxy and DNS first.
Disconnect VPNBW and try the same page again to see whether the issue occurs only while connected. If the site you could normally access still won’t load after disconnecting, troubleshoot your local network first rather than assuming the server is at fault. If access returns after disconnecting but fails again after reconnecting, keep the website and device the same and test another server region. This comparison helps distinguish an issue with one server from a proxy configuration issue on the device, and gives you clearer details for a support ticket.
Check system and browser proxy settings
In your system’s network settings, check for a manually configured proxy, entries left by an old client or a proxy extension enabled only in your browser. If several settings are active at once, requests may be sent to a local program that has already quit, making websites spin indefinitely despite a connected status. Temporarily disable proxy options you don’t need, then test the connection method currently recommended by the VPNBW client. Don’t change the system proxy, browser extensions and client mode all at once; otherwise, even if the issue goes away, you won’t know what fixed it.
If your browser loads regular pages but stalls on sign-in, payment or other pages with ongoing requests, check whether the problem occurs in just one browser. Test with another browser on the same device. If only the original browser is affected, check its extensions, private DNS settings and cache before changing the network settings for the entire device. Clear the cache only for the affected site so you don’t lose other saved sessions.
Identify DNS issues
DNS translates domain names into the addresses needed to reach them. Common DNS symptoms include a domain failing to load, some domains for the same service not working, or a browser saying it can’t resolve the name. This is different from a slow server. Note the failing domain and the exact browser message, then compare results before and after connecting and across different servers. If only domain access is affected, check whether your system forces a custom DNS server or your browser has its own DNS setting. Record the original settings before changing them so you can restore them.
Don’t try random DNS addresses one by one. Where DNS resolution takes place can affect region-specific services and app routing, and piling on arbitrary settings can make the issue harder to reproduce. Restore any unneeded manual settings in the system or browser to suit your current network, restart the affected app, reconnect and test the same domain again. If the issue occurs only on servers in a specific region and can be reproduced on different devices, send support the domain, server region and error message. Don’t submit a full webpage URL that contains personal session parameters.
“Websites won’t load” can mean all sites fail, one site fails, only DNS lookups fail, or just one app is affected. Explaining which one you’re seeing is more useful than simply saying “the internet doesn’t work.”
Slow speeds and peak-hour lag: choose a server for the task
First, work out where the slowdown occurs
Slow page loads, video buffering, sluggish file transfers and lag in remote sessions can have different causes. Note the app, destination region, time of day and server region you’re connected to. Check whether the issue is constant or only occurs during peak hours, and whether all sites are slow or just one service. “The speed test looks bad” isn’t enough to judge real-world performance: the test server, your device’s Wi-Fi conditions and the way an app makes requests can all differ.
Before comparing results, pause large downloads, cloud sync or system updates on the device, and make sure your local network can handle basic browsing while disconnected. If things are slow even when disconnected, check your Wi-Fi signal, router and local network load first. If the slowdown only occurs while connected, keep the app and device the same and compare a server in a nearby region. Test the same action each time—such as opening the same page, playing the same content or repeating the same work task—so you don’t mistake fluctuations in the destination service for a server difference.
Region and use case matter more than the server name
When choosing a server, start with the region your destination service supports, then consider physical distance and the actual results. Nearby regions are usually worth trying first, but the service’s regional requirements may matter more than distance. For AI tools, developer APIs, international websites and region-specific content, compare each use case separately instead of expecting one server to handle everything. The servers page lets you browse regions and server types. Server names are there to help you choose, not to guarantee the same performance in every app.
For Cursor, Copilot and command-line tools, a page loading quickly doesn’t prove that a long-lived connection is stable. Check whether sessions reconnect or requests repeatedly stall, and compare servers in the same region to avoid confusing the results with changes to the app’s regional session. For more guidance on choosing a server for development, read Server selection for AI coding tools. If API requests are timing out, API network options compared explains the difference between website access and API calls.
Keep a timeline for peak-hour issues
Describe peak-hour lag separately from slow speeds that persist throughout the day. Results from the same device, app and server at different times are more useful; switching devices only during peak hours makes it hard to tell whether the cause is server load or a change in device conditions. If only one of several servers repeatedly lags, temporarily switch to an available server and note the affected region. If servers in different regions all have issues at the same time, also check whether your local network is congested.
For video, don’t just check whether the home page loads. Observe playback startup, quality changes and seeking. If region-specific content won’t play, the issue may be regional availability rather than insufficient bandwidth. For remote meetings, note whether both audio and video are affected and whether the same meeting works better after disconnecting. Describing “when, which service, which server and what action causes the slowdown” is more useful for troubleshooting than a single speed-test screenshot.
A region in the server list is a clue for choosing a server, not a guarantee of performance with a particular service. If one service has an issue, compare the region and use case before deciding whether to switch servers.
Frequent disconnections and mobile background drops: find the trigger
Tell intentional switching apart from unexpected disconnects
Switching networks, waking a device from sleep, sending an app to the background or a brief local network interruption can all trigger a reconnection. Note what the device was doing before the disconnect, not just what happened afterward. If it always happens after a network change, test again with the network held steady. If it still disconnects repeatedly on a stable network, compare other servers. This helps you avoid mistaking normal network transitions for an ongoing server failure.
After reconnecting, check which region the client actually selected. Some apps restore the previous session; others require you to select a server again. A status-bar icon alone doesn’t confirm that the original server is back. If the browser is briefly inaccessible after a drop, check whether the client is still reconnecting before changing system proxy settings. Note the status text and retest after reconnection finishes, keeping the message shown at the first failure for reference.
On mobile, check background settings first
Mobile operating systems may limit background app activity and network access to save power. If everything works in the foreground but the connection drops after you lock the screen or switch apps, check VPNBW’s background activity, battery management and network permissions in system settings. Setting names vary by device, so check the actual options shown on your system. After making a change, keep the same server and repeat the action that previously triggered the drop. If the result changes, note the specific setting; there’s no need to enable unrelated permissions all at once.
Also distinguish a client disconnect from an app signing itself out. When you return to the foreground, first check whether VPNBW still shows as connected, then see whether your browser or target app needs to reload. If VPNBW is still connected but only one app has lost its session, check that app’s background settings or regional requirements. If the client itself has disconnected and this consistently happens after the screen locks, background restrictions are the most likely place to start. Reinstalling the client is only useful after you’ve made this distinction.
On desktop, check sleep and network takeover conflicts
After a desktop wakes from sleep, its network interface may retrieve new settings. If the client doesn’t reconnect properly, disconnect and reconnect manually instead of relying on a stale session that only appears active. If the same issue keeps occurring, check for other proxies, corporate network tools or programs that modify network settings. Don’t run multiple clients that take over system networking at the same time; it becomes difficult to tell which one changed the route or proxy settings.
If the issue affects only one server region while the device stays awake and the network remains stable, try another region and see whether it improves. If every server drops after the same action, check device permissions and your local network first. When contacting support, describe the trigger rather than just saying “it disconnects a lot.” For example, say whether it happens after locking the screen, switching networks, waking from sleep or during continuous foreground use, and whether you can reconnect manually. If you can’t reproduce it consistently, say so; don’t keep changing settings to force a pattern.
A mobile background drop and a server that’s consistently unavailable are different issues. First check whether the connection works in the foreground, when the app moves to the background, and what the client shows when you return. Then decide whether to check system settings or the server.
Subscription update failed? Check your account, link and client
Check whether the initial import or a refresh failed
A failed import on a new device and a failed refresh on a device that already has a subscription require different checks. If a new import reports an invalid link, first confirm you’re using the current subscription link from your VPNBW account panel and the import method that matches your client. If the list is already there but updates fail, note whether the old servers are still visible, whether the client shows an update error and whether the subscription is active in the panel. Old servers remaining in the list only means the configuration is saved locally; it doesn’t prove the refresh worked.
Check your account and subscription in the account panel, then return to the client and refresh. When copying subscription details, don’t include explanatory text, spaces or line breaks. Don’t share the subscription content in public chats or screenshots. If you’re using the system share feature to send it to the client, make sure the target client opens rather than a regular webpage in your browser. If you’re unsure of the import steps, revisit the platform-specific instructions in the Guides and follow the same setup path.
Rule out local cache and network restrictions
If the panel opens and the subscription is active but the client still can’t refresh, use the client’s update option and note the exact error. If the client lets you switch networks, try again on another available network. If the configuration downloads on one network but not another, the issue may be related to the network’s access conditions. Don’t create lots of entries with the same subscription name; each may retain old servers and make it easy to select the wrong one later. Don’t delete your last working configuration until you’ve confirmed the new one works.
An update may fail without showing an error, while the server list remains unchanged. Compare the current subscription status in the panel with the client’s last update result. Don’t use the presence or absence of a server name to infer how many regions the service covers. VPNBW covers 120+ countries / 190+ servers; the specific entries visible in a client also depend on subscription settings, how the app displays servers and whether the refresh succeeded. If the list looks out of date, note the update time or message shown by the client. You don’t need to upload the full configuration file in a support ticket.
Check account status and plan status separately
If the panel asks you to sign in again, complete account verification first, then check whether the subscription is active. VPNBW registration doesn’t require an email address; a username and password are enough. Troubleshoot using your original account rather than creating a new one just to test. A new account won’t show the original subscription, which can make an account switch look like a missing subscription. If the panel asks you to choose a plan, check plan prices to confirm the current option. Reinstalling the client won’t change the plan on your account.
If both the panel and client open, your account is in good standing, and refreshes still fail on different networks, submit a support ticket. Include your device platform, the error shown by the client, whether this is the first import, whether the panel opens and whether the old servers still connect. This helps support distinguish account configuration issues from client parsing issues. Don’t include your password, full subscription link or anything that can be used to sign in. If more checks are needed, use the secure messaging in your account panel’s ticket system.
Your subscription link is account access information. Before taking a screenshot, check the address bar, QR code and client import dialog so reusable subscription details aren’t included.
Only one app won’t connect? Check routing and region
First, confirm the issue affects only that app
If your browser can access international websites on the same server but one app keeps failing to load, the server itself may still be working. Keep the client connected, open the target service’s website or a similar page in your browser, then test the app again. Note whether the app won’t start, sign-in fails, the content list is empty, or the failure happens during playback or a request. Different stages can involve different domains, system permissions and region checks. A spinning app icon alone doesn’t identify the failing step.
If the service fails in both the browser and the app, start with the websites & DNS section to check domain resolution, then use the server selection section to compare regions. If the website works but the app doesn’t, check for app-specific network settings, device data-saving restrictions and whether the client is using an app-routing configuration. Clients handle system proxies, virtual networks and app traffic differently; browser access alone doesn’t prove that every app uses the same route.
Check the route the app actually uses
If the client has app rules or routing settings, confirm that the target app matches the intended rule. Note the original rule before changing it. Afterward, fully quit and reopen the app so it doesn’t keep using an old network session. If the app has its own proxy setting, check that it isn’t pointing to a local service that has stopped. Don’t let multiple proxy options handle the same requests at once. Managed work devices may have additional network policies; don’t repeatedly try to override system restrictions you can’t change.
Streaming and region-specific services may also consider your account region, content licensing and connection exit region when deciding what to show. Choosing a server in a particular region is a way to check regional requirements, not a guarantee that content will play. If the page opens but the content reports a region mismatch, reopen the app on the same server to rule out an old session, then compare other servers in the target region. If the message concerns your account’s region settings, check the service’s own rules; a network server can’t replace the service’s account requirements.
For development tools, check long-lived connections
Editor autocomplete, terminal requests and regular browser pages may use different network settings. If one development tool fails, check for a proxy option in the tool and old proxy variables in the terminal environment. Then note whether the first request fails or the session drops partway through. Don’t put real API keys in test commands or support tickets. If you need to test, use a public page that requires no credentials and record the error type, whether it timed out and how the same device’s browser compares. For more on long-lived connections and tool selection, read Network tips for Cursor / Copilot.
If only one app has an issue while other apps and servers work on the same device, include the app name, whether the failure happens at sign-in or during use, the target region, the client connection mode and whether app routing is enabled in your ticket. You can attach a screenshot of a clear error message after redacting personal details. Don’t upload logs containing account credentials, private conversations or API keys. These details help support distinguish server compatibility and routing rules from restrictions imposed by the service itself.
Device alerts and data usage: check sessions and your plan
“Unlimited devices” doesn’t mean old sessions need no management
VPNBW supports unlimited simultaneous devices. If the client reports a device or session issue, don’t immediately assume your plan has a fixed device limit. First confirm you’re using the original account and that the panel displays the subscription correctly. Then check for connections left active on old devices, duplicate subscription imports or client statuses that haven’t refreshed after disconnecting. Device names can look similar, so noting the platform and whether a device is currently in use is more reliable than simply counting entries in a list.
If you can confirm an old device is no longer in use, disconnect and quit the relevant client on that device, then refresh the account status and subscription on your current device. Don’t share account credentials with someone else just to investigate an alert. If the panel offers session management, use the status shown there. If there’s no self-service option, keep the original alert and submit a support ticket. Unlimited devices is compatible with an expired sign-in state, duplicate sessions or a client cache issue; check each separately.
Check how your data is billed
Monthly plans include ¥9.9/month for 60GB, ¥18/month for 250GB and ¥28/month for 500GB. Data resets monthly on the activation date. Data packages are ¥158/300GB, ¥358/1000GB and ¥658/3000GB; they expire when used up and never expire based on time. These billing models work differently. If your monthly plan’s usage changes, first check your activation date and the current billing period shown in the panel. For a data package, check the remaining data rather than waiting for a monthly reset.
If an app suddenly transfers a large amount of data, check whether cloud sync, a system update, video playback or a background download was running while connected. Apps can transfer data even when they aren’t in the foreground, so browser activity alone doesn’t show how much the whole device used. The panel and your device’s system statistics may track different things. Before comparing them, check which account, type of data and period each one covers. If you spot an unexplained change, note the item shown in the panel and when you observed it. Don’t calculate a conclusion that the panel doesn’t provide.
Don’t confuse plan upgrades with connection issues
If you upgrade a monthly plan partway through its term, the price difference is converted into remaining days. Before choosing a plan, read plan prices and check the difference between monthly plans and data packages. An upgrade is a billing action, not a general fix for DNS, permission or app-routing issues. If your subscription is active and only one server or app is affected, complete the relevant network checks first. Conversely, if the panel clearly shows that the subscription or data is unavailable, switching servers repeatedly in the client won’t fix the account status.
When reporting a device alert, include the exact message, platform, whether the panel shows a subscription and whether an old device is still in use. For data issues, include your plan type, the item shown in the panel and what you were doing before the change. Don’t submit your password or full subscription details. For order or billing disputes, follow up through a panel ticket and see the refund policy for details on 7-day no-questions-asked refunds.
Check in this order: “Is this the right account? → Is the subscription active? → Did the alert come from the panel or the client? → Are there old sessions?” Don’t interpret a device alert from the client as proof that your plan limits the number of devices.
When to contact support: gather reproducible evidence
Submit a ticket after the essential checks
After completing the comparison tests in the relevant section, submit a ticket if the same connection error persists across different servers and networks, the panel and client show conflicting statuses, or subscription updates keep failing. You can also ask for help if you can’t access system permissions, can’t verify your account status or the issue is affecting work in progress. You don’t need to keep making changes that might disrupt your configuration just to finish every possible check. The goal of contacting support is to share confirmed conditions with someone who can check the service-side status, not to try every setting again.
Before submitting, describe the observable issue in one sentence, such as “The client says it’s connected, but no websites will load in the browser,” rather than simply “It doesn’t work.” Then include your device platform, the client’s exact error, server region, approximate time and whether every server or only a specific one is affected. Note which comparisons you’ve tried: whether you switched servers or networks and whether the target app works after disconnecting. This lets support follow the same steps and avoids asking you to repeat them from scratch.
Write reproduction steps as a sequence of actions
A useful reproduction report starts with opening the client and states which server you selected, what you clicked, how long you waited, which service you opened and what message appeared. If the issue happens only in the background, during peak hours or after switching networks, state that trigger separately. If it doesn’t happen every time, describe the conditions and actions before and after the most recent occurrence rather than inventing a consistent pattern. Include only relevant screenshots, and redact personal details, account information, full subscription links and private app content.
Submit a ticket through the support section in your account panel. If no verifiable public email or other contact address is available, use the panel. The contact page also explains how to reach support on the site. If you continue testing after submitting, add the results to the existing ticket rather than creating multiple tickets with different descriptions of the same issue. State what condition you changed and whether the symptom changed; this helps distinguish the original issue from anything caused by later adjustments.
What not to send
Support needs details about the issue, not access to your account. Don’t send your password, full subscription link, sign-in verification code, payment credentials, development tool keys or unredacted full logs. Before sharing a screenshot, check the browser address bar and subscription import screen. If an error message includes a private path or account identifier, redact anything unrelated first. Keep the error type, client status and action context visible; otherwise the screenshot may be safe but won’t help troubleshoot.
If support suggests changing a setting, note its current value, apply one suggestion at a time and report the result. If it doesn’t help, say that you restored the original setting. This keeps the troubleshooting record clear and avoids a pileup of interacting changes. Once the connection issue is resolved, keep a short note of the server region that worked, the network conditions and the setting that caused the issue. If similar symptoms appear later, compare those conditions, but still verify the current account, app and system status.
A support ticket template: issue; device and platform; server region; trigger; exact on-screen message; checks already performed; results. Don’t include sensitive account information.