Can't connect at all? Find the source of the problem
Work out whether the device is offline, the proxy isn’t handling traffic, or the route can’t connect.
First, pinpoint where the connection fails
“It won’t connect” doesn’t tell you enough. A client that can’t sign in, an empty subscription list, a route that times out and a website error after connecting are different problems at different stages. Note where the process stops and save the exact error. Then turn off the proxy and use your browser to open a site that normally works without it. If that fails too, check your Wi-Fi, Ethernet, router or network sign-in first. Switching international routes can’t fix a device that isn’t online.
Public Wi-Fi may require you to accept terms or sign in through a browser. Seeing that you’re connected to Wi-Fi only means your device has joined the access point; it doesn’t mean internet access has been approved. Disconnect the proxy, open a browser and look for a network access prompt. Complete the authorized sign-in process before reconnecting. On a work- or school-managed network, follow its usage rules and don’t change managed settings without permission.
Narrow it down with cross-checks
Once basic internet access works, check that the client has the network permissions it needs and that your account shows an active plan with data remaining. Then try another route on the same device and network, leaving other settings unchanged. If only the original route fails, the issue is more likely with that route or the path to it. If every route fails, try the same device on another network you’re authorized to use. These comparisons are more useful for diagnosis than repeatedly restarting the client.
Next, see whether another device can connect on the original network. If it works on the other device but not yours, check your device’s system proxy, virtual network interface and security software alerts. If all devices fail on the original network but work after switching networks, the access network is a more likely cause. You don’t need to make every device use the same settings; just note which client and route each one uses so configuration differences aren’t mistaken for network differences.
Check for client conflicts and traffic interception
Other proxy tools, corporate access software or apps with network filtering may compete for the system proxy or routes. Quit other tools that manage network traffic, start the client you intend to use and check that no proxy setting still points to an exited app. Don’t delete virtual network adapters, system certificates or all network settings; that could disrupt work software. If you need to adjust security software, act only on a clear block record and restore the original protection after testing.
An incorrect system clock can also affect encrypted connections and certificate checks. Check the date, time zone and automatic time settings, then see whether the error changes. If a certificate is marked untrusted, don’t bypass the warning or install a certificate from an unknown source. First confirm that the client came from the client download area in the user dashboard, save the certificate warning and ask support to review it.
Once the connection is restored, don’t immediately import more configurations or switch back to every old setting. First open the target app with the working setup, then restore other network tools one at a time. If the issue returns after restoring a tool, keep that comparison. The website, speed and routing checks below all assume that a basic connection is already working; otherwise, you may keep changing settings at the wrong level.
Connected but can’t open websites? Check web access and DNS issues
Check DNS resolution, connection setup, certificate validation and the site’s response separately.
Check the error before changing DNS settings
When the client says it’s connected, that usually means one part of the connection is working—not that every app is using the right route. “Server not found,” a timeout, a certificate error and “access denied” mean different things. Note the full domain in the address bar and the browser’s exact error, then try another website and browser. If only one site has a problem, check its status, app rules or account restrictions instead of resetting your entire network.
DNS translates domain names into addresses that can be reached. If name resolution fails, the connection may never start; successful resolution, however, doesn’t guarantee that the service at that address is reachable. Browser cache, secure DNS in the browser, the system resolver and the client’s DNS settings can all use different paths. So it’s possible for a system command to return an address while the browser still can’t open the site. Note which resolver you tested rather than just copying down an address.
Check DNS resolution with system tools
On Windows, run the query below in Command Prompt. You can also try it in Terminal on macOS or Linux, depending on whether the tool is available. The example uses a public domain for testing and requires no account details. Check whether you get a result, whether the request times out and which server appears in the output. Don’t permanently add a returned address to your settings: website addresses can change, and pinning one may break certificate checks or regional routing.
nslookup example.comIf curl is available, use it to check whether a request reaches the response stage. The command below reads only the response headers; a redirect or denial still means some parts of the connection completed. Command-line tools may not use all the same proxy settings as your client, so interpret the result in context. A successful command doesn’t prove the browser will work, and a failed command alone doesn’t prove the route is down.
curl --head https://example.comRestore the DNS path one setting at a time
First note your browser’s secure DNS and the system’s private DNS settings. Then temporarily restore the system- or client-recommended default, changing only the setting you’re testing. Reopen the browser and check the same domain. If it works, investigate the previous DNS path further; that doesn’t prove a particular public DNS service is at fault. Have an administrator handle DNS settings on managed devices—don’t override organization policies.
If a system lookup still returns an obviously outdated result, refresh the local cache after confirming your settings are correct. On Windows, ipconfig /flushdns clears only the local DNS cache; it won’t fix a remote route or clear every browser cache. Steps vary on other platforms. Prefer reconnecting to the network or restarting the app you’re testing, and don’t copy administrator commands from an unknown source. Run the lookup again after each change and keep the before-and-after results.
If one domain keeps failing, include the domain, error type, time of occurrence and DNS check results in your ticket. Redact personal information before sharing publicly; there’s no need to submit your full browsing history. For more detailed checks of your exit route and per-app traffic, see How to check that your VPN is working. The goal is to match each app’s actual behavior to its current settings—not to draw conclusions from the connection icon alone.
Slow speeds and peak-time lag: compare the route
Rule out local network contention first, then compare routes. Don’t treat one test as a permanent performance guarantee.
Describe exactly what feels slow
A slow-loading page, video that keeps buffering, an interrupted download and choppy audio in a remote meeting are different performance issues. Pick one task you can repeat. Note when it slows down, whether the slowdown lasts and whether it affects every app. Don’t run several speed tests and downloads at once; they compete for bandwidth and make the results hard to compare. The same route name also doesn’t guarantee an identical path every time you connect.
Pause cloud sync, system updates and large file transfers on the device, then check whether other devices are using your home network. Wi-Fi signal quality and distance from the access point can affect performance; switching international routes won’t fix interference between your device and router. If possible, compare wired and wireless connections in the same location, or repeat the task on another network you’re authorized to use. Keep the app, file or video the same so you don’t change too many variables at once.
Compare route types, not just locations
Different routes can exist in the same region. Compare the available route types for your current use case before trying another location. IEPL, relay and direct connections describe how a route is organized, not a universal ranking of app speeds. An exit location that’s closer geographically may still perform differently because of local access, external peering or how the destination site routes traffic. Choose based on how well the route handles your actual task, not its name.
| Type | What to watch | How to compare |
|---|---|---|
| IEPL | Consistency for your current task | Keep the app the same and compare available routes |
| Relay | Performance from the access network to the relay route | Compare the same task on your original and another network |
| Direct | Changes in local access and external peering | Note differences by time; don’t draw conclusions from one test |
Compare time periods when checking peak-hour slowdowns
If an issue occurs only at peak times, compare it with other times while keeping the conditions consistent. Record how the same device, network, route and app perform at different times, then check whether all routes slow down together. If it happens only on your original access network, look more closely at the local provider network and shared bandwidth. If the same route repeatedly has issues on different networks, share the route and time with support. Don’t assume that “slow at night” means your plan has too little data.
Plan data is an allowance, not an unstated fixed speed tier. Check your remaining data and plan status in your account before deciding whether you need to change your usage. VPNSweet monthly subscription data resets monthly on the activation date; mid-cycle upgrades are prorated by the remaining days. See the plans page for current prices and data allowances. Upgrading just to fix occasional buffering may not address the actual cause.
Video apps may choose different delivery routes based on the content source, exit region and cached data. Compare using the same content and video quality, let it finish loading, then see whether buffering continues. AI tools may take a long time to process a request after it starts; that isn’t the same as a slow network route. If regular websites work but a particular task gets no response, note the exact stage in that app rather than describing everything as a slow connection.
Route comparisons are meaningful only after you’ve ruled out local network contention, found a repeatable task and confirmed that changing routes makes a difference. When submitting a performance ticket, say whether the issue affects page loads, sustained transfers or app response times, and include your comparison conditions. If the issue doesn’t recur, note which network and route were working so you have a baseline if it happens again.
Frequent disconnects and mobile background drops
Separate route interruptions, network changes and system power management.
First, identify what triggers the disconnect
If disconnects happen after locking the screen, switching Wi-Fi networks, moving away from an access point or waking the device, check system behavior before blaming the route. Note what you did just before the drop, whether the client was still running, whether the system network icon changed and whether reopening the app restored the connection. A disconnect during active use is different from one that happens only in the background; describe and test them separately.
When a device switches between network types, its address and routes may change, so the existing connection might not continue seamlessly. A brief interruption alone doesn’t mean there’s an account or subscription issue. Wait for the network switch to finish, then let the client reconnect. Don’t repeatedly toggle the connection while the network is still settling. If it doesn’t recover, return to the basic network checks and confirm that the new network itself can access the internet.
Check how your platform manages background networking
On Android, battery management, background activity and app sleep policies can affect persistent connections. Open the client’s app info in system settings and check whether the background activity it needs is allowed, adjusting the options your device provides. Menu names vary by device, so don’t look for one exact label. Change settings only for the client rather than setting every app to unrestricted, and note which change affects the test.
On iOS, first check whether the system VPN status matches the client’s connection status, then look for other configurations that may be managing network traffic. Leaving an app in the recent apps list doesn’t necessarily keep its connection active, and battery settings from other platforms don’t apply. If the issue happens only after locking the screen, note the network type before and after locking, the client’s status when you reopen it and whether you had to reconnect manually. That’s more useful than repeatedly clearing the app.
| Platform | Check first | Verify recovery |
|---|---|---|
| Windows / macOS | Wake from sleep, network switches and other network tools | Reopen the original task after waking |
| Android | Background activity and battery management for the client | Compare the connection in the foreground and after locking the screen |
| iOS | System VPN status and configuration conflicts | Check whether the connection recovers after switching networks |
| Linux | Network management services, sleep and proxy settings | Compare service status with access from the target app |
Compare routes if disconnects continue
If the device stays in the foreground and the basic network hasn’t changed but disconnects keep happening, try another route while keeping other conditions the same. If the original route fails but another stays stable, the original path may need closer investigation. If every route disconnects after the same action, focus on the local system and network. Don’t change background permissions and switch routes at the same time; if the issue clears, you won’t know which change helped.
On desktop, pay particular attention to stale system proxy settings after waking from sleep. If the client has exited but the system still sends requests to its local proxy, your browser may appear completely offline. Stop the proxy and quit the client normally, then check that the system proxy doesn’t still point to an inactive endpoint. Linux users should also distinguish between the desktop environment’s proxy and proxy variables inherited by terminal processes; they may not update when the client exits.
If you need support, describe the trigger and recovery steps—for example, “disconnects after locking the screen; still needs a manual reconnect when brought to the foreground”—rather than just saying it “drops a lot.” Include only the relevant log excerpt and redact it first. After recovery, repeat the same screen-lock, wake or network-switch action to make sure the original trigger is no longer causing the issue.
Subscription update failed? Keep your working configuration
First determine whether the update failed or the connection failed; don’t treat them as the same issue.
An update failure doesn’t mean your existing configuration stops working immediately
A subscription update is how the client fetches configuration; a route connection uses configuration already on the device. Either can work while the other fails. If your current configuration still works, keep it rather than deleting everything because of an update error. Note whether the message says timeout, download failure, parse error or account status, then check whether you can open the user dashboard. The stage where it fails determines whether to investigate the network or the configuration.
Open the account overview and check your plan status and remaining data first. Monthly subscription data resets each month on the activation date, not at the start of the calendar month. Data packs remain available until used and never expire, but check your actual balance. If a payment is recorded but the plan status hasn’t been confirmed, check the order and plan details in your account. Don’t create repeated orders while troubleshooting or assume a payment screenshot proves the configuration is active.
Check the source and import process
Get subscription details from the user dashboard and use the client process provided there. Extra spaces, line breaks or other text added during copying may prevent the client from reading the details. Don’t paste subscription information into public chats, online format-checking sites or unfamiliar conversion tools. A subscription URL may contain access credentials and is as sensitive as account information; also cover its QR code and full URL in screenshots.
If the client says it can’t recognize the configuration format, first check that the import method matches the client. A browser opening an address doesn’t mean its response is suitable for the client. Don’t change the format based on a file extension or save an error page as subscription configuration. If the response is a login prompt, network sign-in page or service error, fix how the information is being retrieved rather than editing the configuration line by line.
Test the update path separately from the proxy path
Depending on the client’s settings, update requests may use the current proxy route or a separate fetch method. If the route in use has stopped working, the update may fail too. After confirming that your basic network works, stop the current proxy using the client’s normal method and try the update again. If another route in your existing configuration works, you can switch to it before fetching. Don’t refresh repeatedly in quick succession; that makes temporary errors harder to distinguish from repeated requests.
After a successful update, check that the client has actually switched to the newly fetched configuration. Some clients save multiple configurations, so a new entry in the list doesn’t mean it’s now active. Check the current configuration name, route list and selection, then connect to a route to test it. If the new configuration has an issue but the old one still works, keep the old one for comparison and tell support how each behaves. There’s no need to keep overwriting it.
If you think subscription details may have been exposed, update them through a relevant dashboard feature if one is available, then reimport them on your own devices. If you can’t find an appropriate option, ask support how to proceed. Don’t put access credentials in a public document for convenient sharing. Accounts can be created with a username and password, without an email address; keep both secure and don’t rely on an unconfirmed recovery method.
Submit an update support ticket if the dashboard status is normal, the source is correct and your basic network works, but the same update step keeps failing. Include the client name, platform, exact error and fetch methods you’ve tried; also say whether your existing connection still works. To review the standard import process, follow the Getting Started Guide rather than looking for a subscription link on an unfamiliar site.
An app isn’t using the proxy? Check traffic handling and routing
Start with how the app handles network traffic; one browser can’t represent an entire device.
System proxy settings don’t cover every app
If your browser works but a target app doesn’t, your basic connection may already be working; don’t delete the subscription right away. A system proxy is a network setting offered to apps by the operating system, but whether an app uses it depends on how it’s built. Some apps have their own proxy settings, some background processes read settings only at startup, and others need a different traffic-handling mode in the client. Different results across apps on the same device are not unusual.
Quit the target app and its related background processes, confirm that the client is connected, then relaunch the app. Closing a window may not stop its background network connections, which can retain the previous failure state. If the app has its own proxy settings, check whether they point to a local endpoint left behind by another tool. Don’t copy port numbers from online instructions; use the local proxy details shown in your current client and note the original settings before changing them.
Use a temporary comparison to pinpoint rule issues
If the client offers rule-based and other traffic-handling modes, temporarily compare the target app’s access in each mode. Treat this as a diagnostic test, not a recommendation to reroute all traffic permanently. If the app works in one mode but fails in rule mode with other conditions unchanged, check which domains it uses and how the rules categorize them. If it fails in every mode, investigate the app’s authentication, network protocol, account region or service status.
An app may connect to separate services for sign-in, APIs, static resources and file transfers. Changing only the main domain you see in the interface may not fix the failing part. Use the connection information provided by your client to see which domains the app actually requests, and keep only entries relevant to the error. Don’t force every connection onto the same route or disable rules broadly for convenience; that can disrupt local services that were working properly.
Distinguish between terminals, editors and browsers
Command-line tools, editor extensions and browsers may use different proxy settings. Terminal environment variables are usually passed to a process when it starts, so an existing terminal may not pick up system proxy changes. Editor extensions may also run in separate processes. First identify whether the problem is in the editor interface, an extension request or a terminal command, then restart the relevant process. In remote development, a request may run on the remote machine; a working local browser doesn’t prove the remote machine’s network is working.
For AI tools such as ChatGPT and Cursor, distinguish between a page that won’t load, a failed sign-in, a request that keeps waiting and a server-side rejection. A working route doesn’t guarantee that a third-party account, regional policy or service quota will allow the request. Note the error and the stage where it occurs, then see the AI Tools guide for access information. For Streaming, also distinguish website access from content playback; connection status alone can’t guarantee third-party content availability or access policies.
If the client’s current mode can’t handle the app’s connection method, check the client documentation instead of enabling an unknown driver or running an administrator script. For managed work apps, ask your administrator first. Every temporary change should be reversible. Once you’ve confirmed a rule issue, give support the app name, failing stage and results for each mode instead of simply saying the software “isn’t supported.”
After a fix, test sign-in, core features and background requests—not just whether the app opens. If the change affected apps that were working, restore the temporary traffic-handling settings and check them again. Keep only the smallest adjustment that meets your needs, with rules, system proxy and app settings each serving a clear purpose rather than sending all traffic through one exit indefinitely.
Check device-limit messages and account status
First identify where the message came from, then check whether it refers to this service.
A “device limit exceeded” message? Check its source first
VPNSweet allows unlimited simultaneous devices. If you see a device limit warning, note whether it came from the client, the user dashboard or a third-party app before attributing it to VPNSweet. A third-party website’s login-device limit is separate from a network subscription’s rules, and a client may also store configurations for other services. Check the current account and configuration so a warning from an old subscription doesn’t affect your conclusion.
If the warning really comes from the VPNSweet dashboard or your current service configuration, save a screenshot of the exact message and submit a ticket. You don’t need to remove other devices just to clear the warning. Unlimited devices doesn’t mean every device gets a separate data allowance; usage still comes from your chosen plan. With more devices, several apps transferring large amounts at once can make data use and local network contention more noticeable. Check those separately rather than calling them a device limit.
Check your plan, remaining data and reset schedule
Make sure the account overview matches the subscription you’re using. Monthly plans are ¥9.9/month for 60GB, ¥18/month for 250GB and ¥28/month for 500GB; data resets monthly on the activation date. Check your account’s actual status before changing plans. Don’t assume data has reset based on memory, or automatically blame a connection failure on data usage. Mid-cycle upgrades are prorated by the remaining days; make changes in the dashboard.
Data packs cost ¥158 for 300GB, ¥358 for 1000GB and ¥658 for 3000GB. They don’t expire and remain available until used. “Never expires” describes how data packs work; it doesn’t mean your balance can’t decrease. If you’re unsure whether your account has a monthly subscription or a data pack, compare the full plan details with your account status, then ask support. Don’t guess about billing or reset issues without checking the account.
Separate sign-in problems from network problems
If you can’t sign in to the dashboard, check your username, keyboard layout and the account details filled in by your password manager. Don’t copy your password into a public note-taking service or send it to support for troubleshooting. Creating an account without an email address is a privacy benefit, but it also means you shouldn’t assume an email-based recovery option exists. Use the recovery options actually shown in the dashboard, or ask through official support if you’re unsure.
If you can sign in to the dashboard but the client configuration belongs to another account, a normal-looking account page doesn’t prove that the current configuration is correct. Check where the configuration came from and when it was imported. If needed, fetch a new one from the current account while keeping the old configuration for comparison. When several people use the same device, note the active configuration name; the dashboard account and client configuration don’t necessarily stay in sync. Before clearing your browser sign-in, make sure you still have the correct login details.
Payment methods include Alipay, WeChat Pay and USDT. If you have a question about a payment, keep the relevant order status in your dashboard and any necessary payment proof, then contact support in a ticket. Don’t share full payment details publicly, pay repeatedly because of a network error or follow personal payment instructions from an external chat. Record connection issues and order status separately, and link them only when you’ve confirmed they’re related.
VPNSweet offers a 14-day no-questions-asked refund. For details, read the refund policy and submit a request through the dashboard. You can explain a troubleshooting issue and a refund request separately; you don’t need to try every possible setting before describing the problem. For an account issue, state the status you see, what you expected and what you did. Avoid diagnosing it based only on assumptions such as “too many devices.”
Submit a support ticket and retest after recovery
Give support the facts you know; you don’t need to guess what caused the issue.
When to stop troubleshooting on your own
Submit a ticket if your basic network works and your account status is clear, but the same error keeps occurring after you switch routes or networks. Stop making high-risk changes if you see a certificate warning, suspect credentials have been exposed, find an account status that doesn’t match the plan details or use a managed device. Troubleshooting is about narrowing down the cause, not exhausting every network setting. If the next step would remove system components or change security policies, ask for guidance first.
Submit a support ticket through the user dashboard and keep adding updates to the same conversation. Title it with the symptom and affected component, such as “Client connects, but browser shows a DNS error.” In the message, include when it happened and the time zone, device platform, client name, current route and network type. Report the client version shown on your device; don’t guess or copy a version number from an online tutorial.
Share reproducible troubleshooting notes
A useful report follows this order: what you were doing, where it failed, the exact error and the individual checks you’ve tried, ending with the configuration currently in use. For example, say whether switching networks on the same device fixed it, whether switching routes on the same network helped and whether other apps were affected. Mark checks you haven’t done as “not tested”; don’t invent results to make the report look complete. Clear uncertainty is useful too—it keeps support from treating guesses as facts.
Capture just the error and relevant status information; you don’t need to send a screenshot of your entire desktop. Include only the log excerpt around the time of the problem, not your full connection history. Redact subscription URLs, QR codes, passwords, session details, private file paths and anything unrelated. You can leave route names and error types visible. Share account identification details only through the official dashboard; support shouldn’t need your login credentials to troubleshoot.
Make one change at a time, even when following support advice
When support suggests a change, first check what it’s intended to test. Follow the recommendation and record the result. If it involves clearing a configuration, confirm how to back it up and restore it; for account changes, check which account is signed in; for system permissions, understand what they affect. In each reply, say what you changed, whether the error changed and whether the original task worked. That’s more helpful than simply saying “still not working.”
After the issue clears, repeat the action that originally failed instead of switching to an easier test. For a website issue, check the original domain; for a background issue, test locking and waking the device; for a subscription issue, verify the update and active configuration; for an app issue, retest the original feature. Then restore your usual routing mode and make sure local services weren’t affected by temporary settings. Restoring the connection and restoring the original task are separate checks.
Keep a known-good baseline, not a pile of fixes
Tidy up your final configuration, undo temporary changes that didn’t prove useful and remove diagnostic copies you no longer need. Keep a brief baseline with the working network, client, route type and essential settings—never passwords or subscription credentials. If the issue returns, compare what changed instead of starting with a reinstall. If it’s hard to reproduce, add the time and trigger to the original ticket when it happens again.
Coverage includes 110+ countries and 250+ routes, but troubleshooting doesn’t require testing them all. Choose available routes that give you a useful comparison; that’s usually better than switching at random. For common questions, see the FAQ. For first-time setup, return to the Getting Started Guide. To verify whether traffic is actually using the intended route, read the guide to checking your exit route, DNS and per-app traffic. Keep each check focused on the right layer to avoid going in circles.