VPNKM Troubleshooting

Can't Connect at All: From Your Local Network to the Exit Node

“Can't connect” can mean several different things: the client won't launch, the subscription list is empty, an error appears as soon as you tap Connect, or the client stays on Connecting without finishing. These issues occur at different stages and need different fixes. Note the exact message on screen and when it appeared. Don't immediately delete the client or repeatedly reimport the subscription. If you've already changed anything, record what you changed. The goal is to identify where the failure occurs, not to keep switching settings until something works once.

Check Your Basic Connection Without the Proxy

Disconnect the client and check whether your device can still access websites you normally use. If basic access also fails, check Wi-Fi, the Ethernet cable, your router, and any network sign-in page. Hotel and guest networks may require you to confirm access in a browser; connecting to Wi-Fi doesn't necessarily mean you have internet access. Complete any sign-in step before starting the client. If you've switched networks, disconnect the old connection before reconnecting on the new network, so you don't mistake a stale network state for a route issue.

Once your basic connection is working, try the same steps on another network if permitted. Keep the device, client, subscription, and selected route unchanged; change only the network you're connecting through. If it works on another network, the issue is more likely related to the original network or its access policies. If the result is the same, continue checking the client and subscription. Follow public network rules. On a managed work network, ask the administrator which connection methods are allowed; don't test by disabling workplace security policies.

Distinguish Subscription, Connection Permissions, and Route Failures

Sign in to the user dashboard and check your plan status and remaining data, then check the configuration name currently selected in the client. Being able to sign in doesn't prove the current configuration is still valid; an old configuration saved in the client may also differ from the subscription status shown in the dashboard. Make sure you haven't selected an older imported configuration, then try a normal update. If the list is empty or the update fails, go to the subscription section instead of repeatedly tapping Connect without a usable configuration.

If your system asks whether to allow a network configuration to be added, approve it as part of the client setup. If permission was denied, the configuration may still appear in the interface without the system permissions needed to connect. Check your system network settings for other active tunnels, security software, or proxy tools. Exit tools you don't need in an orderly way, then test again. Don't clear every network configuration at once. Identify work-managed settings, remote-work connections, and this service's configuration separately, and confirm their purpose and recovery steps before removing anything.

Use Repeatable Comparisons to Narrow Down the Issue

When changing routes in the client, keep the app and network unchanged and see whether only the original route fails. Then try another region and compare the results. Hong Kong, the United States, Singapore, Japan, France, and Switzerland are available as region reference points; the options shown after you sign in are authoritative. For route type definitions, see the Servers page. If every available route produces the same error, check local permissions, configuration validity, and network access first rather than trying every route one by one and losing track of the results.

Once the connection is restored, keep the working configuration and selected route, and turn off any extra settings you enabled temporarily while troubleshooting. Reopen the app that originally failed and confirm that it can actually access what you need—not just that the client's status text has changed. If the connection only works intermittently, continue recording the conditions when it fails; don't assume one successful connection means the issue is fixed. If a permission prompt is unclear, save a screenshot rather than guessing what it means.

Connected but Websites Won't Load: Proxy and DNS

A connected status in the client usually means only that the connection process has reached a particular state; it doesn't prove that websites are accessible. Other possible causes include DNS resolution, the system proxy not handling traffic, browser-specific settings, a website outage, or account permissions. Start with the browser's exact error: a domain not found, a connection timeout, a certificate warning, and a website refusing access are different problems. Don't label all of them as network failures, or you won't know what changed when you switch routes.

First Check Whether Everything Fails or Just One Site

Keep the client and route unchanged. Try different websites, and open the same target in another browser. If only one site fails, check the URL, service status, and sign-in state first. If the page loads but its content isn't available, check the target service's account or regional policies too. If only one browser fails, check whether it has a separate proxy, proxy extension, or secure DNS setting. A private browsing window can help rule out some extension and cache issues, but it doesn't prove the system network configuration is correct.

If every browser fails, check whether the client has actually enabled the system proxy or is using another traffic-routing method it supports. In rule mode, a target domain may be assigned to a direct connection. Not every app reads the system proxy settings either. If you understand the impact, briefly switch to the client's existing global mode as a comparison, then restore the original mode when you're done. If global mode works but rule mode doesn't, focus on which rules are being matched. You don't need to reinstall the client or change your account as a first step.

Separate Domain Resolution from the Web Connection

DNS translates domain names into addresses. The system, browser, and client may each handle resolution, so a successful command-line lookup doesn't mean the browser used the same path. Running the query below in a system terminal checks only the resolution environment used by that command. The example domain is there to check whether the command returns a normal response; it doesn't prove the target service is accessible. If the command isn't available, you don't need to install extra tools for troubleshooting. Use the system's network diagnostics or provide relevant client logs instead.

nslookup example.com
curl -I https://example.com

If domain lookups fail while your basic connection works, check for leftover manual DNS settings or an old configuration that the client kept after an update. Note the current settings, then restore automatic configuration or reconnect according to the client instructions. Don't fill in every DNS address you find online, and don't change the browser, system, and client settings all at once. If you see a certificate error, check the device time, target address, and network sign-in status. Don't dismiss certificate warnings to decide whether the service is working again.

Clearing the Cache and Knowing Its Limits

After correcting the configuration, close and reopen the affected browser, then test the original destination again. You can use the system's network diagnostics or DNS cache-clearing options if needed, but first confirm that resolution is actually involved. Clearing the cache triggers a new lookup; it won't fix incorrect rules, an expired subscription, or restrictions imposed by the target website. If an old page works but a new domain fails, keep track of that distinction. It's more useful for tracing the resolution path than a vague report that it works intermittently.

If multiple sites fail in different browsers and switching networks and routes doesn't help, include the affected domains, browser error messages, mode in use, and DNS lookup results in your support ticket. The domain is usually enough; don't send a full page URL containing account parameters. If only one destination rejects the current exit, describe the rejection page accurately. Don't attribute it to DNS or assume that all routes are unavailable.

Slow Speeds and Peak-Time Slowness: Compare Each Part of the Connection

First pinpoint what is slow: the initial page load, sustained file downloads, video buffering, or choppy audio on calls. Different tasks have different network requirements, and a single speed test can't represent every destination. For a useful comparison, keep the destination, task, and conditions as consistent as possible. That helps avoid mixing in changes to website content, background app updates, or local Wi-Fi fluctuations. Without consistent test conditions, “it was fast earlier, but it's slow now” describes how it feels but doesn't point to a specific fix.

Rule Out Competition for Local Bandwidth First

Check whether your device is syncing cloud storage, updating its system, or uploading a large file, then check other devices on the same network. Upload usage can also affect page responsiveness and call quality, so it's not just downloads that matter. Pause nonessential tasks and test again; don't stop unfamiliar system processes. For Wi-Fi, check signal strength and whether your location makes a difference. If moving a mobile device closer to the router helps, or using an existing wired connection restores speed on a computer, address the local connection first.

Next, compare basic access with the client disconnected. The goal isn't to visit the same international destination; it's to check whether the local network is generally slow. If ordinary websites also take a long time to load, address your broadband connection, Wi-Fi interference, or network congestion first. If basic access is fine but tasks are slow on one route, move on to route comparisons. Avoid repeatedly running high-volume speed tests; the tests themselves use your plan's data allowance and may compete with work in progress.

Route Type Is a Clue, Not a Speed Guarantee

Use the actual route list in VPNKM as your reference. Route details such as IEPL, relay, and direct connections can inform your choice, but a route label alone can't determine how a target website will perform. The access network, relay, exit, and target service can all affect the result. Keep the task unchanged and compare routes first, then regions. If only one destination is slow while others work normally, the difference may be in the path from the exit to that service; don't automatically blame your device's performance.

Assessing Peak-Time Slowdowns and Sustained Throughput

Compare performance across different times of day to investigate peak-time slowdowns; there's no need to create an elaborate speed-test log. Note the time, access network, selected route, and specific symptom—for example, the page loads but the video keeps buffering. If every route slows down on the same network but performance improves on another, look first at the access network. If the same route repeatedly has the issue, include its name for support to check. Don't assume a region must be faster just because it appears closer on a map; actual routes don't necessarily follow straight-line distance.

Video apps may adjust their bandwidth needs automatically based on quality settings, buffering, and content delivery location. Keep the content and quality the same when comparing routes, so an automatic quality reduction isn't mistaken for a network improvement. AI tools can also combine generation time, queues at the service, and network transfer. If the page works normally but generation is slow, check the target service's status. For details on access considerations, see the AI Acceleration Guide. Don't assume every wait is caused by a slow route.

If the issue is consistently reproducible, say in your support ticket whether the slowdown is ongoing, limited to busy times, or specific to one destination, and include the comparisons you've already made. A plan's data allowance and connection speed are different things; upgrading your data tier isn't a substitute for diagnosing the issue. Monthly subscriptions reset each month on the activation date. See the Plans page for data options. If you're running low on data, check your dashboard status before using large-file tests that consume the remaining allowance.

Frequent Disconnects and Background Drops: The Connection Lifecycle

For frequent disconnects, distinguish a tunnel that actually drops from an app reconnecting or a device stopping transmission while asleep. A browser error doesn't necessarily mean the client disconnected. Conversely, a connection icon in the status bar doesn't prove that background traffic is still working. First note whether the screen locked, the network changed, power-saving mode started, or the device resumed from sleep before the disconnect. Matching these actions to log timestamps is often more useful than repeatedly switching routes, and helps keep separate issues from getting conflated.

Network Changes and Resuming from Sleep

When a device switches from Wi-Fi to another network, the address and path used by the original connection may change. Some apps reconnect automatically; others need a new request. After switching, confirm that the new network works, then check whether the client needs to reconnect. Don't keep trying while the new network is still waiting for sign-in. Computers can behave similarly after waking from sleep: the system network interface needs to recover, and the client and apps may resume in a different order. Check their statuses separately.

If disconnects always happen after switching networks, keep the device still and test on a fixed network. If it's stable there, focus on the recovery process after network changes. If it still disconnects, compare other routes. Long-running downloads and remote sessions may not resume automatically; even after the client reconnects, the target app may need to reconnect. Distinguish “the network is back” from “the original session is still active” so you don't keep changing a connection configuration that's already working.

Mobile Background Permissions and Power Management

On Android, check the system settings for background activity, battery optimization, and data permissions for the client. The names vary by device. If disconnects happen only after the screen locks, follow the system instructions to allow necessary background activity, then see whether anything changes. Don't turn off every power-saving feature on the device just to test, and don't copy menu paths from another model. If the system shows another network configuration handling traffic, check for a similar tool running at the same time. Keep the existing configuration and switch tools in an orderly way.

On iOS, check both the system network configuration and whether apps can actually access the network. An app's interface may stop refreshing when it moves to the background; that doesn't tell you whether the connection itself is still active. First unlock the device, check the client status, then make a new request in a browser. If an error appears only when a particular app returns to the foreground, try rebuilding that app's session first. Don't make force-quitting the client routine maintenance. It can change the background behavior you're trying to observe and make the issue harder to reproduce.

Distinguish an Unstable Route from a Local Conflict

If the device disconnects while the screen is on and the network is unchanged, check whether another network tool started, a system update ran, or security software displayed an alert around that time. Exit proxy tools you don't need normally, keep one valid configuration active, and test the original route again. If switching routes stops the issue, give support the original route name and error time. If every route is affected, compare another device. When only one device is affected on the same network, check its system permissions and local software first.

To recover, wait for the basic network to be ready, reconnect the client, then retry the target app. Don't start multiple configurations at once in an attempt to improve stability, or keep media playing to force the client to stay active in the background. If the problem is consistently linked to screen lock or sleep, say so in your support ticket and include relevant screenshots of the device system and power settings. For work that needs a stable, long-running session, use the target app's own autosave and recovery features. Don't rely entirely on the network never disconnecting to protect a session.

Subscription Update Failed: Account, URL, and Configuration

Subscription updates and route connections are related but separate operations. An update requires the client to retrieve and parse a configuration; a connection uses a configuration it has already retrieved to establish a network path. An old route may still connect even when subscription updates aren't working, and a successful update doesn't prove that traffic from the target app is being routed through the proxy. Start by checking whether the update message indicates an unreachable URL, failed authentication, content that couldn't be parsed, or an empty list after updating. Keep the exact message so different issues don't all get labeled “subscription expired.”

Start by Checking the Dashboard

Sign in through the user dashboard login and check your plan status, data allowance, and current subscription link. VPNKM doesn't require an email address; you can create an account with a username and password. When troubleshooting, make sure you're signed into the account you originally used, not a newly created one. If your browser has saved multiple accounts, check the username. Being able to open the dashboard homepage doesn't prove your plan is active. Don't pay again before confirming the order status.

Monthly subscription data resets each month on the activation date; don't assume it resets at the start of a calendar month. If you upgrade partway through the cycle, the price difference is prorated for the remaining days; check the exact result in the dashboard. Data packages don't expire and remain available until used up. They don't follow the monthly subscription reset schedule. If an update failed around the time your allowance ran out or your plan status changed, resolve the account status first, then retrieve the configuration again. See the Pricing page for pricing and billing details. Don't clear your local configuration instead of checking your allowance.

Replace and Update Configurations Safely

Use the subscription link in the dashboard after signing in, and follow the import method supported by your client. When copying a URL, extra spaces or line breaks can be included, or a chat app may truncate it. Prefer the dashboard's built-in copy or import option. Don't paste a real subscription URL into public websites, online parsing tools, or discussion forums. It may contain access credentials. If you need help checking its format, share a redacted error message instead of giving the full URL to an unrelated service.

Before importing a new configuration, note the current configuration name and the rules in use so you don't switch to the wrong one. After the update succeeds, check that the selected item, region list, and route names match what the dashboard provides, then connect. If the client says the configuration format isn't supported, use the dashboard's compatible import option or review the import steps in the Getting Started Guide. Don't delete unfamiliar fields just to get the configuration through validation; they may contain necessary rules or resolution settings.

The Update Path Can Also Be Affected by the Network

If an update stays on “Requesting” indefinitely, try another access network without changing the account or client. If the client offers an option such as “Update through proxy,” first check whether the current proxy path works; a failed connection may also prevent updates. Follow the client instructions to choose an available update path instead of switching options at random. Being able to sign in to the dashboard in a browser is a useful comparison, but it doesn't prove that the client request uses the same network, certificates, or proxy settings.

If your dashboard status is normal, the subscription link still won't update after retrieval, and switching networks doesn't help, submit the time of the update attempt, client name, exact error message, and import method. You can say whether you kept the old configuration and whether its routes still connect, but don't include a real subscription URL. If the log shows that the response isn't a configuration, ask support to check the response rather than forcing the unknown content into the client. After recovery, test the target site or app to verify the full path from account to service.

One App Won't Connect: Routing Rules and App Traffic

If a browser works but one app doesn't, that points to an app-specific routing issue; it doesn't mean you need to replace the entire subscription. Different apps may use the system proxy, their own proxy settings, a separate DNS resolver, or persistent background connections. First identify whether the failure occurs during sign-in, content loading, file downloads, or syncing. Then try the service's website in a browser as a comparison. A successful website visit only proves that the browser's path works; it doesn't prove that the desktop app's sign-in callback or background requests use the same path.

Check Proxy Routing and Rule Matches

Start with the client's connection logs. Check whether requests appear after you launch the target app and which policy they're assigned to. If no request appears, the app may not use the current proxy method, or its request may come from another process; that doesn't prove the route is at fault. In rule mode, the main website, sign-in, resource, and update domains may each match different policies. Change only relevant rules you can identify, and save the original settings first. Don't delete every direct-connection rule.

If the client supports global mode, use it briefly as a comparison after checking what it will affect. If the app works in global mode, investigate routing rules or related domains rather than treating global mode as a permanent fix. Restore the original settings after testing and reopen the target app. For apps that need traffic interception, first confirm that the client and system support it, then enable it as instructed. Don't layer traffic-routing methods from multiple tools at once, or you won't know which set of rules handled the request.

Separate Proxy Settings, Terminals, and Developer Tools

Developer tools and command-line programs sometimes use their own proxy settings. A system browser working doesn't mean terminal requests automatically use the system proxy. Check the app's settings and the current terminal environment for an old local proxy address that may have been left behind. The commands below check whether common proxy environment variables are set. Their output may include internal addresses or credentials, so inspect it locally and don't paste it into public discussions. If you're unfamiliar with the terminal, check the app settings and logs first.

# macOS / Linux: Check in the current terminal
printenv HTTP_PROXY
printenv HTTPS_PROXY
printenv ALL_PROXY

# Windows PowerShell: Check in the current session
Get-Item Env:HTTP_PROXY,Env:HTTPS_PROXY,Env:ALL_PROXY -ErrorAction SilentlyContinue

If you find an old variable, first check what set it and whether another task still needs it. Then correct it according to the app or system instructions. Don't add unknown ports or addresses to the global environment, or expose a local proxy to network interfaces that don't need it. Desktop editors, extensions, and command-line tools may each read different settings, and you may need to restart a process for changes to take effect. For tools such as Claude and Cursor, network access is only one requirement; check account permissions and service policies on the relevant platform too.

Distinguish Network Errors from Target Platform Restrictions

If an app displays a clear account, region, authorization, or quota message, the request may have reached the target service. Repeatedly clearing DNS or reinstalling the client may not help. Save the exact message and check the account status on the target platform. Streaming services may also determine content availability based on the account and exit location, so a page loading successfully doesn't mean the entire catalog is available. Results from different exits can help with diagnosis, but shouldn't be presented as a guarantee of permanent access.

If sign-in fails only in the app but works on the website, check whether the system is blocking the redirect to an external browser or whether the app is holding an old session. Rebuild the session using the target app's normal sign-out and sign-in flow rather than deleting all local data. Before clearing a cache, make sure it doesn't contain unsynced work. For more on AI access, see the AI Tools Access Guide. For basic terminology, see A Quick Guide to Subscriptions, Nodes, and Routing Rules.

For this kind of support ticket, the app name, the step that fails, and the browser comparison are more useful than “this software doesn't work.” Include the policy name from the logs and a redacted error message. Don't send the target platform password, session details, or work files. Support can help assess the network path, but the target platform must handle its own account authorization and content policies. After recovery, repeat the action that originally failed instead of stopping at the app's home screen.

Device Prompts and Platform Differences: What the Status Means

VPNKM allows unlimited devices online at the same time. If an interface shows a “device limit exceeded” or similar message, don't assume you need to add more device slots. First check whether the message comes from the VPNKM dashboard, the client, the operating system, or the target website. A target platform's own device limit is different from this service's simultaneous-connection policy. Save a screenshot and the title of the page where the message appears, confirm its source, and then decide what to do. This avoids changing the wrong account or choosing another plan unnecessarily.

Unlimited Devices and Local Conflicts Are Different Issues

Unlimited devices doesn't mean you can stack every network tool on the same device without conflicts. Existing system connection profiles, proxy extensions, and security tools may compete to handle network traffic. A client may also show its own authorization prompt. If setup fails on a new device while the original device works, compare the account, configuration source, and system permissions first. If every device on the same network has an issue, return to checking the basic network and routes. Device count is one clue, not a substitute for finding the source of the error.

To use the service on a new device, get the subscription and client through the normal signed-in process. Don't extract a URL from a screenshot on an old device or share configuration files in public groups. The client download page requires a login, and an active, purchased plan is required to download the client. The subscription is available after you sign in. Supported platforms are Windows / macOS / iOS / Android / Linux. For installation and import steps, see the Getting Started Guide. This page covers issues after setup; it doesn't repeat the installation steps.

Find the Right Troubleshooting Steps for Your Platform

On Windows, check the system proxy, network interfaces, and client permissions separately. On macOS, check network settings, connection profiles, and the status after waking from sleep. On Linux, desktop proxy settings and terminal processes may use different configuration sources; how a service starts can also affect whether environment variables take effect. Settings with similar names don't necessarily work the same way across operating systems. Check the actual interface and don't copy commands from another platform onto your device.

Managed devices may have network and permissions configured by an organization. Don't remove these settings just because you have administrator access; check with the responsible administrator first. Resetting network settings on a personal device should also be a later step, since it may remove saved network details, proxy settings, and other connection profiles. Before doing so, save the information you'll need to restore them and confirm that a simple reconnect, configuration update, or app restart hasn't resolved the issue. Avoid introducing more problems during troubleshooting.

Checking Data Allowances Across Multiple Devices

When using multiple devices, keep an eye on your plan's data allowance too. Unlimited devices refers to the number of devices; data usage still depends on your selected plan. If one device is constantly syncing or downloading, changes in the dashboard allowance may reflect that activity rather than the device you're currently checking. Pause nonessential background tasks before checking the dashboard. Don't infer a billing issue from a brief difference in display refresh, and remember to account for normal activity on other devices.

If a “device limit exceeded” message does appear in an interface related to this service and checking the account and updating the configuration don't resolve it, submit a support ticket describing where the message appeared and what you were doing. VPNKM's policy is unlimited devices, so you don't need to look for an extra device tier. Include the operating system and client details if relevant, but there's no need to send a complete device inventory or private files. After the issue is handled, test the connection and actual access on the original device to confirm that both the message and the problem are gone.

Recovery Checks and Support Tickets: Turn Symptoms into Evidence

At the end of troubleshooting, answer more than “does it work now?” Note what changed, the conditions under which it recovered, and any steps you haven't verified. If you changed several settings at once, it can be hard to know what actually fixed the issue. Revert temporary settings you no longer need, and keep the configuration that works reliably. This matters especially on work devices: when restoring this service's connection, confirm that your work network, file syncing, and other essential access still work as expected.

Retest the Original Scenario After Recovery

First confirm that your basic network works, then connect the client and reopen the destination that originally failed. Repeat the actual action, such as signing in, loading content, or submitting a request. If the issue involved screen lock, sleep, or a network change, repeat that action under controlled conditions too. One website opening successfully doesn't verify everything, and there's no need to generate excessive traffic just to prove stability. Connection status, successful DNS resolution, and service availability are different layers; check each against the original symptom.

If recovery depends on temporary global mode, a manual proxy, or temporary DNS settings, record those changes and explain why you made them. If the issue returns when you restore the original mode, that's a useful boundary condition for further investigation of the rules or configuration. For intermittent issues, keep an observation log instead of constantly changing the device. For ways to assess connection stability, read How to Compare Successful Connections and Disconnects. Focus on the test conditions, not results that haven't been verified for your situation.

When to Submit a Support Ticket

Submit a support ticket if your basic connection works, your account status is confirmed, your configuration updates, and the issue is still reproducible. You also don't need to keep trying potentially disruptive steps if you can't retrieve the subscription, the dashboard status conflicts with the client message, or an error involves permissions or a format you don't understand. Support needs symptoms that can be checked, not proof that you've tried every possible fix. List the steps you've taken accurately and note comparisons you haven't made, so support doesn't have to rely on incorrect assumptions.

Send the details through the user dashboard support ticket portal, keeping the information focused on the same issue. Crop screenshots to the relevant area and redact subscription URLs, QR codes, passwords, and session details. Redact work domains and private file paths in logs as needed. Don't upload your entire log history just to make the report look complete. Details from around the time of the issue are easier to check and expose less unrelated information.

Check Billing, Refunds, and Troubleshooting Separately

For payment or data allowance questions, include the order status shown in your dashboard and a description of the issue. Never send your payment account password. VPNKM supports Alipay / WeChat Pay / USDT; confirm the specific payment result in the dashboard. Monthly subscriptions are ¥9.9/month for 60GB, ¥18/month for 250GB, and ¥28/month for 500GB. Data packages are ¥158/300GB, ¥358/1000GB, and ¥658/3000GB; they remain available until used up and never expire. Don't make another payment to see whether it fixes a network issue.

VPNKM offers a 7-day no-questions-asked refund. See the Terms of Service for the complete policy. You can ask about troubleshooting and refunds separately: if you want to keep using the service, describe the issue you want help identifying; if you want a refund, state that directly. You don't need to complete unrelated device troubleshooting first. For information about handling personal data, read the Privacy Policy. For general account and billing questions, see the FAQ. Avoid sending screenshots with sensitive information through multiple support channels.

After support suggests a fix, follow the steps one at a time and report which step changed the symptoms. If it doesn't help, keep the new exact error message instead of replying only “still not working.” If the issue is resolved, say which network, route, and mode worked so support can distinguish a temporary change from a lasting fix. Keep a configuration you can continue to use and a repeatable set of checks for the same symptoms. Next time an issue occurs, you can start from what you already know instead of trying every setting again.