VPN Troubleshooting Guide

Can't Connect at All: Separate Network Issues from Configuration

“Can't connect” can mean several different things: the client won't launch, the subscription list is empty, the connection button keeps spinning, or the app says it's connected but no traffic gets through. Note exactly where it gets stuck and copy the full error message, then follow the relevant steps in this section. Don't start by uninstalling the client; that could erase the subscription source, rules, and diagnostic history, leaving you with only “I reinstalled it and it still doesn't work.”

Establish a Baseline for Your Local Network

Disconnect in the client and make sure the system proxy turns off too. Then try a website that normally works without a proxy. If basic browsing fails, troubleshoot your current network first: check that Wi-Fi is actually connected, whether the network requires a sign-in page, and whether your router still has internet access. On public Wi-Fi, complete the network's normal sign-in process first. A lit Wi-Fi icon only means your device is connected to the local network; it doesn't confirm internet access.

Once your basic connection is working, test the same client and configuration on another network you're allowed to use. If it works there, investigate restrictions, router settings, or connection quality on the original network. If it fails on multiple networks, check your account and client. Company, school, and other managed networks may have specific usage policies; follow them and don't disable management controls to force a test. If you don't have another network available, note that in your records—there's no need to keep changing settings just to gather more evidence.

Check Your Account, Subscription, and Connection Permissions

Open the account overview in the user panel and check your plan status and available data. Being able to sign in to the panel doesn't guarantee that your current subscription is usable, and an old configuration saved in the client doesn't reflect your account's current status. If the panel shows an issue, resolve the account or order problem first. If the account is fine but the client list is empty, see the subscription update section. If the list is populated but every connection fails, confirm that the imported subscription belongs to your current account and that your operating system has allowed the VPN configuration.

On desktop, distinguish between “the client is running” and “the proxy is routing system traffic.” Some modes only start a local listener and don't change the system proxy automatically. On mobile, check whether the system prompted you to add a VPN configuration and whether another VPN configuration is already in use. Repeatedly tapping Connect won't grant permission after it's been denied; follow the client's setup flow or change the relevant system setting. Menu names vary by client, so don't assume another app uses the same paths.

Narrow It Down with One-Variable Tests

With the configuration in place, select another route shown in your current panel and keep the target website and connection mode the same. If only one route fails, the issue is more likely related to that route or its exit. If all routes fail, look more closely at the account, client, or local network. After switching, wait for the connection status to update before trying again. An old page spinner or existing connection may persist, so don't treat it as a test of the new route.

In the client's diagnostic information, distinguish connection timeouts, name resolution failures, authorization errors, and local port conflicts. These point to an unreachable link, a DNS path issue, credentials or account status, and a local software conflict respectively—they don't all mean the “node is broken.” Don't follow unfamiliar tutorials that tell you to change multiple ports or turn off security software. If the log says a listening address is already in use, close other proxy apps first, then restart this client normally.

Connected but Websites Won't Load: Check DNS and Traffic Routing

“Connected” usually means the client has established some kind of session. It doesn't prove that your browser's request reached its destination through that session. Browsing also depends on DNS resolution, proxy rules, certificate checks, the browser's connection cache, and the destination service itself. First identify the scope: no websites load, only some domains fail, or the page shows text but misses other content. The affected domain and the browser's exact error are more useful than a screenshot of a blank page alone.

Check Whether the Request Reaches the Client

If your client supports connection logs, open them and reload the target page. If the request doesn't appear, check whether the system proxy is active, whether the browser has its own proxy settings, and whether the current mode covers that app. If a rule sends the request through a direct connection, see the apps and rules section. Only investigate DNS, the handshake, and the remote response once you've confirmed the request is using the selected route; not every website issue is caused by DNS.

Browser extensions may configure a separate proxy, and security software may install filtering components. To compare, keep your current setup and temporarily try a browser profile without the relevant extensions. If another browser works, focus on the original browser rather than resetting your system's network settings. Private browsing doesn't necessarily disable every extension or use separate network settings, so it's only a partial comparison—not a fully isolated environment.

Tell DNS Errors Apart from Encrypted Connection Failures

DNS maps domain names to addresses that can be reached. A lookup failure, an unsuitable result, or different lookup paths in the app and client can all prevent a request from connecting. Start by checking whether the domain resolves with a system tool, then compare that with the client's connection log. A system command only reflects the system's DNS path; it doesn't prove that the browser's encrypted DNS or the client's internal DNS uses the same path. Different results are a starting point for investigation, not proof of a leak.

nslookup example.com

The example domain is there to show how to run the command. Replace it with the affected domain when troubleshooting, and don't include login tokens or private paths. If the command returns a result but the browser reports a certificate error, check the device's date, time, and time zone, and make sure the address is spelled correctly. Don't “fix” the connection by ignoring certificate warnings. Certificate checks are a security boundary; public Wi-Fi sign-in pages and local filtering components can affect them too, so check those separately.

Save Evidence Before Clearing the Cache

After switching networks or changing DNS settings, an old lookup may remain in the cache. Save the error and diagnostic results first, then clear the cache using the method for your operating system. On Windows, use the command below to clear the system DNS cache. For other platforms, follow current system documentation or the client's built-in instructions. Reopen the target page afterward; if needed, restart the browser so old connections don't affect the test. Clearing the cache won't update your subscription or fix a problem with the remote service.

ipconfig /flushdns

While troubleshooting, don't change system DNS, browser encrypted DNS, the client's DNS mode, and router DNS settings all at once. If access returns after several changes, you won't know which one helped. Start with the configuration recommended by the client, then test one setting at a time. DNS settings on managed devices may be controlled by an administrator; don't override them without authorization. If only a sign-in page or image domain fails, note the affected domain and where its requests are routed, and check whether rules are splitting resources for the same service across different paths.

Slow Speeds and Peak-Hour Lag: Compare the Full Connection Path

Speed isn't just one number. Time to first render, download throughput, video buffering, and call jitter reflect different parts of the connection. Describe what you're trying to do before choosing how to test it. A single speed test can't represent performance on every AI tool, video platform, or region. The test server's location, connection method, and current load also affect the result.

Separate Your Local Connection from the International Route

Before testing, pause unnecessary downloads, cloud sync, and system updates on your device, and check whether other devices on the same network are using bandwidth. Weak Wi-Fi, an overheating router, or frequent reconnections can all slow things down. If possible, compare with a more stable connection; if you can't switch, note your current setup. Trying a resource that normally works with the proxy off can help reveal whether the local connection is already the bottleneck.

Next, keep the same target, device, and network, and change only the route. A geographically closer exit isn't always faster; the actual path also depends on your local carrier, international links, and how the destination service connects. VPNBonus covers 100+ countries / 160+ routes, giving you options without guaranteeing the same performance for every destination in every region. See the global nodes page for region and route details. Available options in your panel may vary.

Compare Different Times of Day to Diagnose Peak-Hour Issues

If things work during the day but slow down in the evening, the time alone doesn't prove where congestion is occurring. Try the same target at different times and note how your basic connection, selected route, and task perform. If your basic connection also slows down, start with the local network. If it stays normal but one route slows, compare another region or available route. If only the target platform is affected, its own load and regional service differences may be a factor.

Describe what you experience—for example, “the page keeps loading,” “the video buffers repeatedly,” or “the connection drops”—and preserve the test tool's actual output. Don't invent precise-looking performance numbers or treat one smooth session as a guarantee of long-term stability. Peak-hour reliability is something to observe over time; one connection can't prove it. See our VPN speed test guide for a fuller testing approach. This section focuses on narrowing down the cause.

Don't Make Tuning Your Default Fix

Connection mode, transport settings, and split tunneling can affect performance, but change them only when there's clear evidence. Arbitrarily changing packet sizes or stacking other acceleration tools may create new routing problems. Start with the client's recommended configuration and check whether multiple proxy or network filtering apps are running. If small pages load but larger transfers consistently stall, note the difference for support. Don't copy parameter combinations that weren't made for your system and network.

Video and AI tools can also be affected by account region, platform policies, and the destination service's capacity. Switching routes may help with some connection issues, but it can't grant eligibility for a destination service or guarantee ongoing access. If tests show that one route repeatedly slows at a particular time, send the time comparisons and describe the task. If all network activity is slow, start by checking your local connection. In your support ticket, say what you've already ruled out to avoid repeating the same basic checks.

Frequent Disconnects and Background Drops: Check the Session Lifecycle

When a connection drops matters. A drop right after connecting, after locking the screen, after changing networks, or after running for a while can have different causes. First compare the system VPN status, client process, and target app. A page that needs reloading doesn't necessarily mean the tunnel dropped, and a client returning to its home screen doesn't necessarily mean the system session ended. Consider the app's status alongside what actually happens when you try to access a resource.

Separate Network Changes from Background Restrictions

When a device switches from Wi-Fi to another connection, its exit address and route may change, and the existing session may not carry over. If the problem always follows a network change, pause the task, reconnect once the new network is stable, and then try again. Don't switch networks and routes repeatedly at the same time; overlapping reconnection attempts make the issue harder to diagnose. Note whether the connection recovers automatically and whether reconnecting manually works. That's more useful than simply saying it “drops a lot.”

If everything works in the foreground but stops after you lock the screen or switch apps, check how the system manages background activity. Android battery optimization, manufacturer-specific background limits, and data saver settings can affect whether the client keeps running. Setting names vary, so check the app's system settings. Adjust background permissions only for the client that needs them, and leave normal power-saving settings in place for other apps. Keeping an app in the recent apps list doesn't guarantee that the system will let it run continuously.

Check Sleep and Permissions by Platform

On iOS, check that the system VPN configuration is still present and that another app hasn't enabled a competing VPN configuration. An app disappearing from view doesn't necessarily mean the underlying session has ended; check both system status and actual access. If the system asks you to authorize the setup again, use the client's normal process—don't install configuration profiles from unknown sources. For first-time setup, return to the getting started guide; this page covers issues that occur after setup.

Sleep, closing the lid, and network adapter power saving on Windows, macOS, and Linux can also interrupt a connection. First distinguish “it won't recover after waking from sleep” from “it disconnects while the device is in use.” For the first, check whether the network came back after wake, whether the system proxy is still set, and whether the client re-established its session. For the second, look into the route, Wi-Fi connection, and software conflicts. Don't disable device security policies globally or prevent normal sleep just to keep a connection alive.

Reproduce the Issue Under Stable Conditions, Then Check for Conflicts

For a comparison, keep the network and route fixed, use the device in the foreground, then check what happens when you lock the screen or switch apps. If it only fails in the background, start with permissions and power saving. If it fails in the foreground too, check the client log around the time of the drop. Another VPN, network filter, or tool that changes the system proxy may override the current settings when it starts. Close related apps you don't need, then reconnect. On managed devices, ask your administrator about approved settings instead of removing management components yourself.

Check auto-connect settings carefully. When a device starts up, the local network may not have finished signing in. The client may try to connect before network access is available and fail temporarily. Complete the network sign-in first, then see if the connection recovers. Repeated retries don't necessarily point to an account problem, so don't keep resetting your password. If the client has on-demand connection or network-change options, read their descriptions, keep the defaults as a baseline, and test only what is relevant.

In your support ticket, describe the trigger—for example, “After unlocking, apps can't access the internet” or “After waking, the system proxy is still on but the client isn't connected.” Also mention battery optimization, network changes, and other VPN configurations. If the drop only affects a specific route, include its name. If you can reproduce the issue after switching both route and network, say so. Include only the relevant log excerpt around the failure, and redact account details and connection credentials from public screenshots.

Subscription Update Failed: Check Retrieval, Parsing, and Account Status Separately

Updating a subscription involves fetching the configuration, reading and saving it, and loading the routes. Don't judge an “update failed” message only by whether the button finished spinning. Keep the exact error: network timeout, authorization failure, unsupported content format, and configuration load failure point to different stages. Don't post a subscription URL as if it were an ordinary webpage link; it may contain access credentials. If it leaks, use the available account management options in the panel or contact support.

Verify the Source Before Editing Anything

Get the current subscription link provided for your account through the user panel, then import it using a method supported by your client. Don't reuse a link from another account, an old screenshot, or a forwarded message. When copying it manually, watch for spaces, line breaks, or punctuation added by chat apps. Don't mistake a login page or order page URL for a subscription link. After importing, check the configuration name and route list; a similar name alone doesn't confirm that the source is correct.

If existing routes still work but updates keep failing, using the saved configuration and fetching a new one may follow different paths. An update request may depend on your current network, system proxy, or the client's own retrieval settings; check the client's instructions. Try updating while your basic network is working, and use only retrieval methods the client explicitly supports. Don't keep switching between unrelated options, and never paste a subscription URL into an untrusted online converter just to update it.

Understand Format Errors and Empty Lists

Clients don't all support the same configuration formats. Content that one client can read may not work when pasted directly into another. Use the relevant option in the user panel and the download process on this site; client downloads are available in the panel's downloads section. A file extension alone doesn't tell you whether a configuration is compatible. Don't copy snippets from the web and delete configuration fields at random; the result might appear to load while breaking rules or DNS settings.

If an update succeeds but the list is empty, first check whether another configuration is selected, a region filter is hiding all results, or the account status in the panel has an issue. An “update successful” message may only mean the request returned; it doesn't prove that usable routes loaded. If the client shows the configuration source or load history, check where the error occurred. You don't need to publish the full configuration, which may contain server credentials and private subscription information.

Keep Working Configurations and Avoid Duplicate Imports

Before importing again, check whether you can keep or back up the current configuration in the app. Don't clear every configuration just to test, especially if you don't have another way to connect. After importing, give the configuration a clear local name and confirm which one is active. Repeated imports can leave several similar-looking configurations behind. You may end up changing routes in an old configuration and think the update did nothing. Remove unneeded copies only after troubleshooting is complete.

Record automatic and manual update failures separately. If manual updates work but automatic ones fail, check background activity, when the network becomes available, and the client's update settings. If both fail, continue checking the source, account, and format. An incorrect device date can affect encrypted connection checks, while insufficient storage can prevent a configuration from being saved. Don't reset all network settings just because the error is complicated; that affects other connections and may not address subscription retrieval at all.

Check how your account's data is counted too. Monthly subscription data resets each month on the activation date, not at the start of the calendar month. Data add-ons never expire and remain available until used. If you've used all your data, check the panel rather than repeatedly importing the same link. See the plans page for plan tiers and billing details; an update error doesn't automatically mean you need to upgrade.

An App Isn't Using the Proxy: Check Rules and Traffic Routing

If your browser works but one app doesn't, check that app's network path instead of reconfiguring every route. System proxy settings, in-app proxy settings, and tunnel modes cover different traffic. Some apps follow the system proxy, some use their own network settings, and others send requests through background services. Confirm the client's mode, then check whether the target app's requests appear in the connection log. A status bar icon alone doesn't prove that all traffic is being routed.

Distinguish “No Request” from “Request Failed”

Close and reopen the target app, then perform an action that definitely sends a network request. If no matching entry appears in the client, check whether the app has its own proxy settings, whether the system proxy is enabled, and whether tunnel mode has the required permissions. If the log shows a request matched to a direct-connection rule, check which rule applies. If it's using the selected route, look at the destination response, account region, or remote restrictions. Different causes call for different fixes.

Rule matching often depends on order. An earlier rule may handle the target domain before a later region or app rule has a chance to apply. Check the match shown by the client before changing anything. Don't add a large set of broad rules all at once; that can disrupt services that already work. If the client supports a temporary test mode, save the original configuration first and use it briefly for comparison. Restore your regular settings when you're done instead of leaving an unverified workaround in place.

Check Related Domains and Existing Connections

An app may use more than its home page domain. Sign-in, attachments, static resources, and real-time communication may each use different domains or background processes. Routing only the main domain through the proxy can make sign-in work while content still fails to load. Check the requests relevant to the action that failed instead of adding every unfamiliar domain to a rule. If the app has an existing long-lived connection, it may persist after you switch routes. Close and reopen the app before checking whether the new path is working.

Browser extensions, desktop app settings, and terminal environment variables can each control proxy use. Developer tools are a particular case: an editor, its extensions, and command-line tasks may not share the same network settings. If Cursor or another AI tool opens normally but requests fail, check the relevant processes and request logs separately. Don't mistake a destination service's usage limit, account eligibility, or server error for a VPN connection issue. A route can change the network path, but it can't change your service account permissions.

Use a Request-Header Test to Help Diagnose—Never Paste Credentials

If the relevant command-line tool is installed on desktop, you can use the command below to check whether a basic HTTPS request returns response headers. The example includes no account credentials and doesn't specify a local proxy address. It tests the current terminal environment, which may use a different path from a graphical app. Interpret HTTP status codes in context; a destination rejecting a request doesn't mean the network is unreachable. When testing a private API, don't put access keys in command history that could be shared publicly.

curl --head https://example.com

If the terminal works but the target app doesn't, start with the app's own proxy settings and background services. If the app works but the terminal doesn't, check for stale proxy settings in the terminal environment. Don't copy someone else's local listening port; use the address and port shown in your current client's settings. If you find proxy environment variables, note where they came from before changing them according to your terminal and system documentation. Deleting every environment variable can disrupt your development setup and make the issue harder to reproduce.

Streaming and AI platforms may also apply their own rules based on account region, exit address reputation, and other factors. An exit that works with other websites isn't guaranteed to be accepted by a particular platform, and successful playback once isn't a promise of continued access. If the platform shows an explicit error, record the exact message and exit region, then compare routes available in your panel. In a support ticket, say whether the issue happens at sign-in, loading, playback, or when sending a request—not just the app's name.

Device and Permission Issues: Check the “No Device Limit” Policy First

VPNBonus has no limit on the number of devices connected at the same time. If a client says “device limit exceeded,” don't assume you need to buy more device slots. First check where the message came from: it could be from a destination website, another service account, the client's local configuration, or an old subscription for a different account. The full screen where the message appears matters more than its keywords. Note the dialog title and where it appeared, then confirm which account and configuration you're using.

Separate Service Limits from Local Conflicts

No device limit doesn't mean one device can run any number of VPN sessions at once. An operating system may allow only one configuration to control network traffic, and multiple clients may compete for the system proxy or local listening resources. If opening another network tool breaks your current connection, stop sessions you don't need and reconnect. Don't describe “the system won't start the current configuration” as “the account has too few device slots”—the fixes are completely different.

Configurations can differ across devices on the same account. If one device works and another doesn't, check the failing device's basic network, account status, subscription source, and permissions first, then compare client modes. Don't copy every system setting from the working device; platforms differ in how they handle proxy routing, DNS, and background activity. Using the same account rules out some account issues, but not local network or permission problems.

Handle Permission Prompts Based on Their Source

If the system asks to allow a network extension, add a VPN configuration, or start a service, first confirm that the request comes from the trusted client you're using. Grant permission through the system's normal authorization screen; don't download purported permission-fix scripts from unfamiliar websites. If permission was denied previously, you may need to allow it again in system settings. The exact wording depends on your system. If a managed device doesn't allow the required permission, contact your administrator instead of trying to bypass management controls.

If the client requires a local service component, install or repair it through the client's normal process. Don't run unknown commands with administrator privileges. If startup fails, record the system message, service status, and steps you took. Some issues appear after a system update, user migration, or network change. That timing can help with diagnosis, but doesn't prove what caused the issue. Keep a working configuration before attempting a targeted fix.

Account Recovery and Credential Safety

VPNBonus doesn't require an email address; you can register with a username and password. If you can't sign in, check your keyboard input, capitalization, accidental spaces when copying, and whether you're using the right account. No email receipt doesn't mean the service is having an issue. Keep your account credentials safe, and don't assume there's an account recovery process tied to an email address. If you can't recover access, use an available support channel and provide the details needed to identify your account. Never post your password publicly or share payment credentials with unofficial contacts.

If a “device limit exceeded” message really comes from your current VPNBonus configuration and persists after you confirm the account overview and subscription source, submit a support ticket. Include the exact message, where it appears, your device platform, and the action that triggered it. State that the service has no device limit. Don't guess at hidden device caps or create multiple accounts to work around the error. Support needs to identify the system behind the message, not rely on a paraphrase.

When sharing an account across devices, remember that data is still counted according to your plan. No device limit describes the number of devices you can use; it doesn't give each device a separate data allowance. If one device is downloading heavily and others see their available data change, check the account's overall usage first. Low data, destination platform restrictions, and local configuration conflicts are separate issues, even if they all occur while using multiple devices.

Support Tickets and Data Usage: Make the Issue Reproducible

The goal isn't to try every setting; it's to gather evidence that supports the next step. If you've checked your basic network, account status, configuration source, and the scope of the issue and it still persists, submit a support ticket. Don't keep making disruptive resets just to show that you've tried everything. Preserve the original error and any working configuration. Note which comparisons you've completed and which conditions you couldn't test; this helps avoid repeated questions from support.

Organize Your Details: Symptom, Environment, Comparison, Result

Describe the action and result—for example, “After connecting, opening this domain returns a DNS error”—instead of just saying “it doesn't work.” Include your operating system, the client name as shown, connection type, time of day, and time zone. For comparisons, note what changed when you switched routes, networks, or apps. State whether the issue is still reproducible and whether any configuration is temporarily usable. Mark untested items as untested; don't fill in the gaps with guesses.

Use the route name shown in the client and provide only the necessary domain and error stage. Screenshots should show the error and relevant status, but hide account details that aren't needed, order information, subscription credentials, and private content. Diagnostic logs may contain destinations, network addresses, and authorization details. Review and redact them before submitting. If support needs more information, confirm its purpose and send it through a controlled channel; don't upload a full log publicly.

For Billing Issues, Reconcile First—Don't Change Network Settings

Check network issues and plan status separately. Monthly plans are ¥9.9/month for 60GB, ¥18/month for 250GB, and ¥28/month for 500GB. Data resets monthly on your activation date, and mid-cycle upgrades are prorated for the remaining days. Don't use the start or end of a calendar month to estimate your reset date, or convert the upgrade difference into an assumed fixed discount. If the panel doesn't match your expectations, include the relevant order details and what you did so support can investigate.

Data add-ons are ¥158/300GB, ¥358/1000GB, and ¥658/3000GB. They remain available until used and never expire. “Never expires” describes the data add-on's validity; it doesn't mean the balance is automatically replenished. If your account has more than one billing item, refer to the panel and applicable terms for how usage is counted. Don't guess the deduction order without supporting rules. See the plans page for a full price and billing comparison. Connection troubleshooting shouldn't be treated as a reason to upsell you to another plan.

Payment methods: Alipay / WeChat Pay / USDT. If your panel hasn't updated after payment, check the actual order status and confirm you're signed into the same account, then follow the panel's instructions. Don't pay again repeatedly or send payment screenshots to strangers. For a support ticket, provide only the necessary order reference and a screenshot of its status; don't share complete payment details publicly. VPNBonus offers a 30-day no-questions-asked refund. See the Terms of Service for the applicable wording.

Verify Recovery Before Wrapping Up

Once the issue is resolved, repeat the action that originally failed and confirm that related content loads too. A successful connection alone doesn't prove the original task is working again. If you temporarily changed rules, disabled extensions, or switched modes, restore your normal settings one at a time and check whether the issue returns. Keep changes that are genuinely needed and undo unrelated ones. This prevents temporary settings from becoming permanent and leaves a clear record for the next time the same symptom occurs.

For more help, open a ticket in the user panel and add follow-up results to the existing ticket. If a new symptom appears, explain how it differs instead of combining every issue into “it still doesn't work.” For common account and billing questions, see the Help Center. If you need to repeat installation and import steps, return to the getting started guide. A concise, redacted troubleshooting summary is often more useful than a pile of screenshots without context.