VPN Troubleshooting Guide

Can't connect at all: check the connection path first

Separate client status from access results

“Can't connect” might mean the client won't turn on, stays stuck connecting, or simply that a particular website won't load. Note the exact message shown in the client rather than treating these as the same problem. Close the app you’re testing, disconnect the VPN, and use a browser to visit a site that normally works without it. If your regular internet connection also fails, check Wi-Fi, Ethernet, the router, or network sign-in first. Switching VPN servers repeatedly won’t fix a problem between your device and the local network.

Public Wi-Fi may require sign-in through a browser. Your device can show as connected while still lacking internet access. Keep the VPN disconnected, open the network provider’s sign-in page, and complete the process before testing a regular website. Never enter your VPNKQ password on a page you don’t recognize. If no sign-in page appears, check your system’s network settings for a login prompt. If you can’t confirm that you’re authorized to use the network, test on a network you know works; that’s more useful than changing client settings at random.

Check your account, subscription, and system permissions

Once your basic internet connection works, sign in to the account overview to check your plan and remaining data, then confirm the client has loaded the servers. An empty server list means the configuration hasn’t been imported; it isn’t a connection failure. A populated list doesn’t guarantee the configuration is still valid: old subscriptions, the wrong account, or expired settings can leave server names behind. Check where the subscription came from, then follow the subscription update steps. Don’t overwrite a configuration you’re using with one from an unknown source.

The first time you connect, your system may ask you to authorize a network extension, VPN configuration, or other network access. If you denied permission earlier, return to system settings and follow the client’s prompt. On macOS, network extension permission is separate from the client’s own connection switch. Mobile devices may also ask you to approve adding a configuration. Grant permission only to clients obtained through the panel. If no prompt appears, fully quit and reopen the client, then check whether a permission request is hidden behind another window.

Use controlled comparisons to narrow down the cause

Once you’ve confirmed the configuration and permissions, try connecting to one server and note the result, then compare it with a server in another region. Comparing regions is more useful than repeatedly clicking the same server, but don’t change the region, mode, and DNS at the same time. If only one server fails, the issue is more likely with that server or the path from your local network to it. If every server fails on the same device, check the client environment. If the same configuration works on another network, focus on what’s different about the original network.

Other proxies, VPNs, or network filtering tools running on the device may compete for the system’s network connection. Pause them in their respective apps, make sure only the client you’re testing is connected, and try again. Don’t permanently disable system protection or remove managed settings for a test; follow your organization’s policies on managed devices. If the client reports a port conflict or that a service failed to start, save the exact message and check for another running client process instead of entering a random port value.

Troubleshoot in this order: basic network, account status, valid subscription, system permissions, and server comparison. Change one thing at a time and keep the original settings so you can tell what actually affected the result.

If the VPN connects but websites still won’t load, continue to the next section. If it won’t start at all, or shows the same error after you grant permission, stop reinstalling it repeatedly. Note your device platform, client name, system message, and the checks you’ve already tried. Windows, macOS, iOS, Android, and Linux handle permissions differently, so similar errors don’t always have the same cause. For the initial setup sequence, see the guide. If you need help from support, submit the details listed at the end of this page.

Connected but websites won’t load: access & DNS troubleshooting

Pinpoint where the failure occurs

A connected status only means the client has established a connection; it doesn’t guarantee that the website, DNS resolution, and app requests are all working. Test a regular website, then the one that failed. Note whether all websites fail, only one site fails, or the browser works while an app doesn’t. If both regular and target sites fail, check the system proxy, routing, and DNS. If only one site fails, consider whether the site is down, requires a particular account, or restricts access by exit region.

Browser errors can help narrow things down. “Server IP address could not be found” points to a DNS lookup issue. “Connection timed out” means the request didn’t complete in time, but doesn’t identify which part of the network failed. For certificate or time errors, check your device’s date and time and verify the domain. Don’t ignore certificate warnings and enter account details, or disable certificate checks just to load a page. If the site shows a specific access-denied message, save its text rather than simply reporting that it won’t open.

Check the system proxy and connection mode

Check whether the client uses the system proxy or a mode that routes system traffic, and confirm the relevant setting is actually enabled. Some apps ignore system proxy settings, so a working browser doesn’t prove that every app uses the same route. Test the same destination in the same browser, then briefly compare rule mode with global mode. If global mode works but rule mode doesn’t, check rule matching and the selected policy group. Don’t treat global mode as a permanent fix without understanding the cause.

If regular websites stop working after you disconnect, the system may have retained an old proxy setting after the client process exited. Check system network settings to see whether a manual proxy still points to the client, then restore the normal setting as directed by the client. Don’t overwrite a proxy configuration required by your workplace network. Record the original value before making changes, then test your basic connection again. This is about the proxy your device is currently using, not deleting server addresses from your subscription.

When comparing DNS, note where the lookup was made

DNS translates domain names into network addresses. Your system, browser, and client may each handle DNS separately, so a successful command-line lookup doesn’t prove the browser got the same result. Keep the system’s existing automatic DNS setting for now. Check whether the client has its own DNS or DNS interception option, then follow its instructions. Secure DNS in the browser, custom network settings, and the client’s DNS policy can coexist in ways that send lookups and website traffic along different paths.

nslookup example.com

The command above only looks up an example domain and doesn’t require account details. Run it in Command Prompt on Windows or Terminal on macOS and Linux. If the tool isn’t available, use your system’s network diagnostics; there’s no need to install software from an unknown source. Note whether the lookup returned a result or timed out, and whether the VPN was connected. A returned address only shows that this lookup completed; it doesn’t prove the website is accessible or establish that there’s no DNS leak.

If the client uses virtual IP mapping, lookup results may differ from those on a regular network; that doesn’t necessarily indicate a problem. Don’t copy a fixed DNS address from a guide into every setting, or enable conflicting DNS interception features at the same time. Try reverting recent changes, then reload the configuration and restart the app you’re testing. If only one domain fails, try another page on the same site and check the spelling. For region-restricted content, see the Streaming guide for access requirements.

Your exit IP, DNS lookup results, and the region on your website account are different things. Use the My IP page to check your exit IP, but remember that a single IP check doesn’t test the DNS route or guarantee access to a particular site.

If the same domain keeps returning the same DNS error on different servers, or still won’t resolve after you restore automatic settings, save the browser’s exact error and lookup results for a support ticket. Don’t post full network diagnostics publicly; they may contain details about your local network. Support needs to know whether the failure happened before DNS resolution, during the connection, or after the site responded. Comparison results are more useful than a screenshot of a blank page.

Slow speeds and peak-time lag: choosing a server

Define “slow” by the task you’re trying to do

Slow page loads, low download speeds, repeated video buffering, and sluggish AI responses don’t necessarily share the same cause. First identify what’s slow and whether other services are affected too. AI tools may be queuing requests on their servers, video performance may depend on where content is delivered from, and downloads are also limited by the file host. The latency shown in a client reflects one type of test; it doesn’t measure sustained performance in your target app or fully describe connection stability.

For a useful comparison, keep the device, network, destination, and steps the same. Don’t switch servers and Wi-Fi networks at the same time. Test the same video, website, or file source and note roughly when the issue occurs. Pause file syncing, downloads, or other video streams on your network before testing. Heavy disk use, low memory, or a misbehaving browser extension can also make a page seem slow; check local device load to avoid misdiagnosing a network issue.

Separate local congestion from the server route

Disconnect the VPN and test the same everyday task. If it’s still slow, check your Wi-Fi signal, router, and local network first. If another type of connection works, focus on the original network. If direct access is fine but the task slows down with the VPN connected, compare servers in different regions and connection types. Geographic distance is only one factor: the path from your local network to the entry point, from there to the exit, and from the exit to your destination can all affect performance.

These types describe connection paths; they don’t mean every region offers every type, and they aren’t a speed guarantee. Check the panel and client for currently available options, and see the server page for an overview by region. When comparing, start with the region you need, then compare the available servers there. Switching regions repeatedly just to chase lower test latency may change content availability or trigger a website’s account security checks, without improving the task you’re trying to do.

Retest peak-time slowdowns under the same conditions

If slowdowns mainly occur during peak hours, compare results from the same setup when performance is normally good with results during busy periods. Local network providers, cross-border routes, and content servers can all behave differently at busy times. Don’t conclude that an entire server is down based on one slowdown, or assume the issue is fixed just because it worked during a quiet period. Compare other servers for the same destination and note which routes help. If all regions slow down at once and direct access on the same network is also affected, investigate local congestion first.

Lower video quality doesn’t necessarily mean you’ve run out of plan data. Players may reduce quality when throughput drops; a page loading successfully doesn’t mean video data can stream reliably. First check whether buffering improves after switching servers, then verify your subscription and quality settings. Avoid repeatedly seeking to different points, as that makes each test inconsistent. For more detail, see Choosing a plan for video quality and bandwidth. This guide focuses on differences between the task, server, and local network.

Upgrading your plan shouldn’t be treated as a general speed fix. VPNKQ monthly plans differ by data allowance; check the plans page to see whether you need more data. This guide can’t promise that a particular plan will resolve server congestion. Keep a working backup server available and avoid wasting data on repeated, unrelated tests. If a particular route keeps having problems at the same time, give support the type of destination, network, server name, and comparison results so they can assess that route.

Frequent disconnects and mobile background dropouts

Tell a dropped connection from an app interruption

A page reload, paused video, or offline message in an app doesn’t necessarily mean the VPN disconnected. When the issue occurs, check the system’s connection indicator and the client status, then try another website. If the client still shows connected and only one app has stopped working, investigate the app session or destination service. If the system indicator disappears or the client explicitly says it’s reconnecting, focus on network changes, background restrictions, and system permissions. Note whether the device was locked when the problem occurred.

Switching between Wi-Fi and mobile data changes your device’s underlying network address and routes. Some connections need to be re-established, and an active download or login session may not resume automatically. First test on a stable network with the client open in the foreground, then test what happens when you switch networks. If the stable connection works but switching networks causes problems, focus on network handoff and reconnection. Don’t assume a brief session interruption means your subscription is corrupted; deleting the configuration usually won’t help.

Check background settings by platform

Android background policies vary by device manufacturer and system settings. Check whether the client is restricted from running in the background or using network access, and whether battery optimization stops its process when the screen locks. Adjust settings for this client only; there’s no need to disable power-saving features for every app. Setting names vary, so follow your device’s own instructions. If it works in the foreground but fails only after the screen locks, note that specific pattern rather than reporting only that it “disconnects sometimes.”

On iOS, the system’s connection status is more useful than whether the app remains in the foreground. Don’t keep interacting with the app just to “keep it running,” and don’t expect the same behavior after swiping it away from the app switcher. Check the active configuration in system VPN settings and make sure it hasn’t switched to another service. If the issue occurs after changing networks, disconnect normally, reconnect, and test the task again. If the problem persists, record the system message rather than repeatedly adding duplicate configurations.

On desktop, sleep, waking the device, or network adapter changes can also leave the client status out of sync with the actual route. Disconnect and reconnect, then confirm the basic network is working. If the client has exited but the system proxy remains, follow the steps in the Websites & DNS section. If you use a background service on Linux, distinguish between closing the graphical interface and stopping the service process. Judging the connection only by whether a desktop window is open can miss a connection component that’s still running—or one that has stopped.

Know when to stop troubleshooting persistent disconnects

If the connection still drops frequently with the network unchanged, the device awake, and other proxies paused, compare different servers. If one server keeps disconnecting while others work, use an available server and report the affected name. If every server fails only on one device, check system permissions, the client environment, and recent network setting changes. Don’t adjust low-level connection settings you don’t understand. An untested setting may change the symptoms temporarily while making the original issue harder to reproduce and support harder to provide.

When retesting, repeat the action that originally triggered the problem. After checking that a page works in the foreground, also retest the screen lock, wake-up, or network switch that caused the issue. That’s the only way to tell whether the specific problem has improved.

When contacting support, say whether the disconnect happened before or after the screen locked, on a stable network or after switching, and in every app or just one. If device management policies block background activity, don’t remove them without permission; ask your administrator what use is allowed. Collect only diagnostic information relevant to the issue. Hide other app notifications and personal content in screenshots instead of sending unrelated information to support.

Subscription update failed: address, configuration & import

Separate update requests from connection requests

A subscription update fetches server settings in the client; connecting uses settings already on the device to establish a network route. These are separate processes, so an old server may still work while an update fails, or an update may succeed while the connection fails. Note where the problem occurs: copying the address, opening the import link, fetching the configuration, or parsing it. Don’t rely only on a pop-up that says “failed.” If details are available, save the status and error category, but don’t post a full subscription address publicly.

Sign in to the VPNKQ panel, check the current account and plan, and get your subscription from the panel. You need to sign in to retrieve the subscription associated with your account; marketing pages don’t contain working subscription links or direct installer downloads. When copying, don’t include explanatory text, line breaks, or extra spaces. If you import through the panel, make sure it opens the intended client. If your system launches a different installed app, return to the panel and choose the right import option rather than repeatedly importing into the wrong client.

Find out whether the content couldn’t be fetched or couldn’t be read

A fetch timeout usually means you should check the network path used for the update request. Some clients fetch subscriptions through the current proxy, so an update will fail if that connection is down; others use the underlying network. Check whether the client lets you choose how to update and follow its instructions to retry over an available connection. Don’t assume disconnecting the VPN is always the right answer, and don’t enable multiple proxies to “help” with the update. First make sure regular websites and the panel open, then change the update path and record each result.

A configuration parsing error usually means the content was fetched but couldn’t be read. Possible causes include choosing a subscription format the client doesn’t support, an unrecognized setting, or a response that isn’t a configuration at all. Don’t paste webpage source into a configuration editor or delete fields at random based on an error message. Check that the format selected in the panel matches the client, and note the field name in the error. If you edited the configuration manually, back up your changes and compare with a fresh copy from the panel so old edits don’t affect the result.

Keep the old configuration and verify the new one

If you still have a working server, don’t delete the existing configuration first. If your client allows it, create a separate configuration entry and confirm it loads before selecting it as the active configuration. A successful import pop-up doesn’t mean the new configuration is in use; check the active configuration name, server list, and policy selection. Repeated imports can leave multiple entries, making it easy to update one while continuing to use another. Identify the active entry before removing duplicates, and don’t accidentally delete your only working configuration.

If server names change or a previous server disappears after an update, don’t immediately assume there’s a problem with your account. The list reflects the current subscription; older names may no longer be available. Check whether a policy group still points to an old entry, then test a server from the current list. If the configuration uses automatic server selection, verify the selected route after importing. For a primer on subscriptions, servers, and rules, see VPN terms for beginners. Make sure you’re updating the configuration, not your account password.

A subscription address can provide access to your account, so treat it as sensitive information. Hide the full address, QR code, and related credentials before sharing screenshots. For troubleshooting, send only redacted error text and the step where it occurred.

Importing may also fail because of how your system handles app links. If the browser doesn’t open the client, first confirm the client is installed and launches on its own, then use its built-in subscription import option. Get the client from the panel download page, which determines what’s available for your account. Don’t download replacement apps from random search results or enter your subscription address into an unknown online converter. Either can expose sensitive information and make it harder to verify where the configuration came from.

If the panel and basic network are working and you’ve confirmed the format, but updates still keep failing, tell support the client name, platform, update method, exact error, and whether the old configuration still works. Support needs to distinguish a subscription fetch failure from a compatibility issue; you don’t need to post your full subscription address in the ticket. For the first import, see A beginner’s first-day guide to check that you’ve activated the configuration and verified the connection.

An app isn’t using the proxy: rules & split tunneling

A working browser is only one point of comparison

Not every app reads the system proxy. Some use their own networking components, others have separate proxy settings, and some send requests through background services. So a browser working while an app fails on the same device doesn’t prove the server is down. First visit the app’s corresponding website in a browser, then check the app for network or account errors. If both the website and app fail, investigate the destination and server first. If only the app fails, check the route it actually uses.

It’s also important to distinguish a login failure from a content request or update failure. A single app may use different domains for login, images, real-time communication, and downloads. Access to its main site doesn’t mean every dependent domain is routed correctly. Adding only the homepage domain to a rule may not fix the problem. Check the client’s local connection diagnostics for requests that match the time of the issue. These are temporary, device-side troubleshooting details; they don’t change what VPNKQ means by “no logs kept.”

Briefly compare rule mode with global mode

Keep the server unchanged and briefly switch to global mode to test the same action. If rule mode fails but global mode works, review the rules, policy group, or dependent requests. Restore the original mode afterward so unrelated traffic doesn’t keep using a different route. Global mode generally changes how traffic is matched; it can’t guarantee that apps which ignore the system proxy will be routed through the VPN. If the client uses only the system proxy, the app’s own network behavior still matters.

When reviewing a rule, check both what it matches and which policy it points to. A rule can match the destination domain and still fail if it sends traffic direct or to an unavailable server. Broad rules listed first can also prevent more specific rules from taking effect. Check the configuration the client is currently using; don’t edit an inactive file. If a subscription manages the configuration, manual edits may be overwritten during an update. Prefer the client’s supported local overrides or persistent rule settings, and keep a record of your changes.

App-specific settings and system traffic routing

If an app has its own proxy settings, enter only the local address and port currently provided by your client. Don’t copy values from someone else’s device; these settings may stop working when the client exits. Never enter a subscription address as a proxy server in an unknown app, or use your account password as local proxy credentials. Save the app’s original settings before changing them and decide whether to keep your changes after testing. If the app requires system-level traffic routing, check that the client supports it and that it has the required permissions.

Routing all system traffic affects network routes and DNS; enabling one switch doesn’t mean you can ignore other network tools. Another VPN, network filter, or workplace management policy may conflict. Pause other connections you control, confirm the basic network works, and then test traffic routing. Don’t change management settings on a work device without permission. If other apps stop working after you enable it, restore the previous state and save the system message and affected apps. Don’t keep layering conflicting network features to fix one app.

An app may retain an old connection or DNS result, so after switching modes, fully quit and reopen it. Refreshing the screen may not restart a background session. A service you’re signed in to may also request verification after your exit region changes, or restrict content based on your account region; those are site-side conditions, and changing routing rules may not help. See the AI Tools guide for AI access requirements and the Streaming guide for content availability and video quality.

Share the destination domain, matching rule, selected policy, and error type—not your full browsing history. Before sharing local diagnostics, remove requests and account details unrelated to the issue.

If the issue persists after testing in a browser, comparing modes, and restarting the app, tell support the app name, what you were doing, and whether the client uses the system proxy or routes system traffic. If only uploads, voice, or specific content fails, say so rather than summarizing the problem as “the whole app won’t connect.” Platform permissions, destination support, and network routing need to be assessed separately. Don’t promise that changing a low-level setting will fix the issue without a specific fault to verify.

Account, data, and device-limit alerts

Check the panel before interpreting a client message

A generic client error may refer to an authorization failure, invalid configuration, or network problem. If you see “device limit exceeded” or a similar message, sign in to the VPNKQ panel and check your account and plan before removing devices or creating another account. VPNKQ allows unlimited simultaneous devices, so don’t assume this message means the service has a device cap. Find out whether it came from the system, client, an old configuration, or the destination app, and save the exact text and where it appeared.

Check whether you’re using a configuration from another account or source, especially if the device has had several subscriptions installed. Similar server names don’t mean they belong to the same account. Verify the subscription source in the panel for the account you’re currently signed into rather than relying on the name. Unlimited devices refers to simultaneous connected devices; it doesn’t override account security, configuration validity, or a destination site’s own session limits. A website’s login rules are separate from VPNKQ’s device policy.

Distinguish monthly subscriptions from data packages

VPNKQ monthly plans are ¥9.9/month for 60GB, ¥18/month for 250GB, and ¥28/month for 500GB. Data resets monthly on the day the plan was activated. When troubleshooting, use the current status shown in the panel; don’t assume the reset happens on the first of the month. If you’ve used all your data, reimporting the subscription or switching servers won’t add more. Check your remaining data and plan status before considering a plan change. See the plans page for the full details; renewing isn’t the default fix for a network problem.

Data packages are ¥158/300GB, ¥358/1000GB, and ¥658/3000GB. They last until the data is used and never expire. “Never expire” doesn’t mean you can keep using the package after the data is gone, or that data is added automatically each month. If you remember a different plan from what the panel shows, check your order and current plan rather than relying on what you paid in the past. For data packages, check the remaining data; for monthly plans, also check the active status and the reset date based on activation.

Handle payment, plan changes, and login issues separately

If you upgrade partway through a plan, the price difference is converted into remaining days; don’t assume it will be credited as another full month. If the panel doesn’t show the expected status after payment, check the order, payment result, and account you’re signed in to before paying again. Payment methods include Alipay, WeChat Pay, and USDT. Troubleshooting won’t require you to transfer money to payment details that appear unexpectedly in a support ticket. Keep the panel order and a redacted proof of payment, and verify them through an existing support channel. Don’t share full transaction details publicly.

No email address is required to create an account; a username and password are enough. If you can’t sign in, check the username, extra spaces, and whether the way you entered your password has changed. Don’t confuse your subscription address, server password, or device unlock code with your panel login. Your browser’s password manager may have saved details from another site or an old account, so confirm the autofilled credentials belong to VPNKQ. If you’re unsure which account is yours, use the official panel to contact support; don’t post your password publicly and ask someone to verify it.

If your account is in good standing but the connection fails, return to the connection and subscription sections rather than assuming one authorization error means your order is missing. If the panel opens, your order is active, and you have data remaining, compare with another device that’s already configured. If the other device works, focus on the configuration source and client environment on the affected device. If all devices show the same authorization message, send support the consistent error details so they can check your account status.

Unlimited devices is a fact about this service; an error mentioning a “limit” needs context. It may refer to the destination app’s account, system management policies, or an invalid configuration—not necessarily VPNKQ’s simultaneous device policy.

VPNKQ offers a 7-day money-back guarantee. Check the Terms of Service for eligibility and the refund process. Refund requests and technical troubleshooting are separate matters; if you want a refund, say so clearly rather than adding payment or account details to every connection report. Submit the information support needs through a panel ticket, and include only what’s necessary to link the order to your account. If anyone asks for your full password or a public subscription link, stop sharing and verify that you’re using an official support channel.

Support details & recovery check

When to stop making changes yourself

If your basic network works and you’ve checked your account, subscription, and permissions, but the same error keeps happening, gather the details and contact support. You don’t need to exhaust every setting before asking for help when the system clearly reports a permission, configuration parsing, or authorization error. Stop if the issue involves workplace management policies, an unknown certificate warning, or a download from an unfamiliar source. Troubleshooting should narrow down the cause, not leave your device unrecognizable. If you don’t know what a setting does, keep the original value rather than copying one blindly.

Before submitting a ticket, write a clear one-sentence description, such as: “On a stable Wi-Fi network, the client connects, but my browser times out on the target domain while other sites work.” Then say when the issue began, whether it’s ongoing, and whether it’s linked to locking the screen or switching networks. Separate what you observed from what you suspect; don’t state that “the server must be broken” as a fact. Support needs reproducible symptoms, not a conclusion. If the issue has since recovered intermittently, include what happened and what conditions allowed it to recover.

Include enough detail to diagnose the problem, but don’t collect more than needed

Name your platform—Windows, macOS, iOS, Android, or Linux—instead of just saying “computer” or “mobile device.” Specify the client, connection type, and mode separately. If the issue started after an update or restart, note what changed recently, but don’t assume that was the cause. You can include the system and client versions shown on your device for support to assess. This guide doesn’t prescribe a version number or ask you to install an old version just to reproduce the issue.

Include enough context in screenshots to show where the error appeared, whether the connection was on, and whether the configuration had loaded. A screenshot showing only “failed” often doesn’t reveal what stage went wrong. Before sharing, hide subscription addresses, QR codes, passwords, unrelated payment details, and notifications from other apps. Full logs or configurations may contain more sensitive information, so don’t upload them as-is. Follow support’s instructions to extract a redacted section relevant to this issue instead of sharing all your device’s network activity.

Record what you tested and what the original settings were

Describe the steps you actually tried in order, along with the result of each one. For example: the destination still failed after switching servers, worked after switching networks, or succeeded in global mode but not rule mode. This can prevent unnecessary repeat tests. Don’t just say “I tried everything,” and don’t list steps you didn’t actually take. If a change broke other apps, explain the original setting and whether you restored it. Support’s next steps can then reflect the device’s current state instead of assuming its default settings are still in place.

Organize a ticket summary in this order: symptom and destination → platform and network → current server and mode → exact error → tests and results → what you need help with. Don’t include actual credentials.

Submit your request through a panel support ticket, then add follow-up results to the same ticket. Keep the details together instead of splitting one issue into unrelated requests. If you temporarily switched to another server and the problem went away, distinguish the working route from the one that failed so support doesn’t think the issue is still ongoing. If you need an account check, refund, or client compatibility review, say so explicitly to help the support team route your request.

After recovery, retest the original scenario

Start recovery checks with the action that originally failed, then test the relevant app and your basic network. For a subscription update issue, confirm the new configuration is actually active. For background disconnects, test locking and waking the screen again. For a rules issue, restore rule mode before retesting. For peak-time problems, keep observing under similar conditions. Finally, remove duplicate configurations you no longer need and undo temporary test settings. Note the changes that worked so you can start from known conditions next time rather than reinstalling everything from scratch.

Systematic troubleshooting doesn’t have to solve every network problem at once. Restore the task you need first, then narrow down the cause to avoid unnecessary changes. For quick import and connection checks, follow the guide. Choose a server based on the server page and your client’s current list. Check your account and billing in the panel and on the plans page. Keep to the facts, protect your credentials, and record comparison results; these are the most useful things to have when following up or investigating the same issue again.