VPN Troubleshooting Guide

Network problems are easy to misdiagnose because several symptoms can appear at once. For example, the client may show Connected while the browser cannot open a page; or webpages may work while video, AI Tools or a standalone app does not. Reinstalling the client immediately rarely provides new information. First define the fault boundary: Is the original network working? Are all devices affected? Do all routes behave the same? Do all apps behave the same? The clearer the boundary, the fewer settings you need to change.

Keep a stable baseline for comparison

Before troubleshooting, disconnect the client and use the current network to open a website that normally works reliably. If the original network itself is not working, address the router, Wi-Fi, carrier link or system network state first. A VPN runs on top of the existing network; it cannot restore a broken underlying connection. If everything works while disconnected but fails after connecting, narrow the scope to the client, route, rules or DNS.

Next, record the platform, network type, client status, selected region and affected app. NeeVPN supports Windows, macOS, iOS, Android and Linux. Each platform handles system proxies, background operation and DNS interception differently, so “the same subscription works on another device” is a valuable clue. It usually indicates that the account and subscription are usable, while the issue is more likely related to permissions, rules or the network environment on the current device.

Change one variable at a time

A common ineffective approach is to switch through several regions, change proxy mode, replace DNS, restart the router and re-import the subscription in one sequence. Even if service returns, you will not know the cause, and the next occurrence will require starting over. Keep the client and system settings unchanged, change only one route and test again. If nothing changes, restore the original route and check the next item. After each action, disconnect completely and reconnect to prevent an old session, cached resolution or background connection from affecting the result.

Keep the test target consistent as well. For speed issues, use the same download source or video segment; for webpage issues, check the same domain repeatedly; for app issues, use the same account and network. Do not compare completely different services, because their regional policies, cache locations and access restrictions may differ. If one website works while another fails, that only suggests an issue related to the target service, region or rules; it does not prove that the entire route is unavailable.

Recognize when to stop local trial and error

If multiple devices on different networks cannot connect at the same time and routes in several regions behave identically, a local settings problem is less likely. Check service or account status instead. If only one website refuses access while other international websites and apps work, do not keep resetting the entire client. Check whether the target service restricts regions, retains an old login session or is sensitive to changes in exit location. If the error clearly indicates an expired subscription, authentication failure or traffic status issue, check the dashboard first rather than repeatedly changing system DNS.

The goal of a baseline check is not to fix every issue immediately, but to reduce the symptoms to a verifiable statement such as “Windows connects on a home network, but every browser fails to resolve domains,” “Android disconnects after moving to the background but works normally in the foreground,” or “Only one app on the same device bypasses the proxy.” This maps directly to the later sections and helps support avoid repeating basic questions.

“Cannot connect at all” means the client never reaches Connected, or returns to disconnected immediately after connecting. This is a different fault layer from “connected but webpages will not open.” The former usually occurs before the tunnel is established, so check the local network, system time, client permissions, configuration validity and current route first. The latter points to the system proxy, rules or DNS. Separating these symptoms prevents you from repeatedly clearing browser caches when the handshake is failing.

Confirm that the underlying network can establish a normal encrypted connection

Disconnect NeeVPN and check whether the browser can open a familiar HTTPS page. Also confirm that the system date, time and time zone are not significantly incorrect. Secure connections rely on certificate validity checks, so an incorrect system clock can appear as a handshake failure, certificate error or timeout. If the device has just resumed from sleep, moved between regions or had its clock adjusted manually, let the system synchronize the time before fully quitting and reopening the client.

Then switch the underlying network once for comparison. For example, move from the current Wi-Fi network to another trusted network, or switch between wired and wireless. The purpose is not to avoid the problem permanently, but to determine whether it comes from the device or the current network. If the same client, subscription and route connect after changing networks, the account and configuration are probably fine; check the original network’s router policies, guest-network isolation, enterprise restrictions or upstream link.

Check whether the client has system-level permission

During the first connection, the system usually asks to add a network configuration, enable the VPN configuration or allow a related network extension. If permission was declined, the client may still show a route list but cannot establish a tunnel. Open the system’s Network or VPN settings and confirm that the relevant configuration exists and is allowed. Do not keep multiple proxies, VPNs or network filters running at the same time. They may compete for the same system entry point and prevent the client launched later from taking over traffic.

On Windows and macOS, fully quit other network proxy tools rather than simply closing their windows; some remain active in the background. On iOS and Android, check whether another VPN configuration is connected or set to connect on demand. On Linux, confirm that the user launching the client has permission to create network interfaces and modify routes. If permission was previously denied, reinstalling may not restore it automatically; grant it again in system settings.

Obtain a fresh configuration instead of layering it over the old one

If the client has not updated the subscription for a long time, or the import was interrupted, delete the invalid local configuration first and retrieve it again from the user dashboard. Do not keep duplicating subscriptions with the same name in one client; an old configuration may remain selected, making it look updated while the client still uses the old entry. After importing again, check whether the route names have changed and explicitly select the new configuration before testing.

Compare routes across different regions, but do not click through them rapidly. After each switch, wait for the previous connection to release completely before starting a new one. If one route fails while others work, use a working route temporarily and record the failed route name. If every route fails on one device but works on another, return to the current device’s permissions and conflicting tools. If all devices, networks and multiple routes fail, preserve the original error and submit a ticket.

A Connected status only shows that the tunnel or local network interface has been established. It does not mean every app is sending traffic through the route correctly. When a webpage will not open, determine whether the domain cannot resolve, the app is ignoring the system proxy, the route has not taken over, the browser is retaining an old connection, or the target website is independently rejecting the current exit. The key is to break “does not open” into a specific result.

Test domain resolution and direct connectivity first

After opening a command line, run a basic query against a public domain. The example below only checks whether the device can receive a response and contains no subscription information. If domain resolution fails and direct access to other known services also fails, check DNS first. If the command line receives a response but the browser does not, check browser proxy settings, extensions, cache and security software. If only one site fails, examine the target service’s region and account status.

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

nslookup returning a result while the browser still says it cannot find the server does not necessarily prove that DNS is completely healthy. The browser may have enabled its own secure DNS, or the client may use a separate resolution path. Fully quit and reopen the browser first to clear old connection pools and resolution results. If the browser has proxy-switching, privacy-filtering or network-debugging extensions, test in a standalone window without extensions to determine whether the issue is at the browser layer.

Check proxy mode and system traffic capture

Common traffic-capture methods include a system proxy, a virtual network interface and per-app rules. A system proxy usually covers browsers and apps that follow system settings, but some programs ignore it. A virtual interface covers more traffic, though conflicts with other network filters are also more visible. If the browser works but a standalone app does not, the main route may be healthy; check whether the app follows the system proxy. If no apps work, check whether the default route and DNS have been captured correctly.

When viewing proxy status in system network settings, do not manually enter an address from an unknown source. Normally, the client writes the setting when connecting and restores it when disconnecting. If the client is disconnected but the system proxy remains enabled, you may be left with a state where there is no connection and webpages will not open. Disable the residual proxy first, quit the client and reconnect. If the same state remains after every disconnect, record the system and client environment and submit a ticket.

Rule out browser cache and the target service’s regional status

Websites often determine region using cookies, login sessions, DNS results and exit location together. After switching routes, an old session may still retain information from the previous region. For testing, sign out of the target website, close existing tabs and use a private browsing window. Do not rapidly switch between several countries or regions and then sign in to the same account, as the target service may see frequent exit-location changes and trigger additional verification.

If ordinary webpages open but Streaming or AI Tools reports that the region is unavailable, choose a route consistent with the account’s usual region and keep the session stable instead of changing DNS again. For checking whether the exit and connection are actually working, read How to Check Whether a VPN Is Working: Exit IP, DNS and Per-App Tests. That article focuses on verification; this section focuses on locating the failing layer after verification fails.

Slow speed is not a single metric. A slow first page load, video buffering, low download throughput, fluctuating game latency and peak-hour lag may indicate completely different bottlenecks. Download speed is mainly affected by bandwidth and the target server; real-time interaction depends more on round-trip latency and packet loss; video playback is also affected by content-distribution region, encoding and caching policies. Do not judge an entire route from one page load or a single speed-test page.

Test the original network first, then compare the connected state

Disconnect the client and observe the original network on the same device, network and test source. If the original network already fluctuates noticeably during peak hours, an international route will inherit some of that bottleneck. Changing the remote region alone may not help; first check the Wi-Fi signal, router load, concurrent downloads at home and the carrier link. Weak Wi-Fi can cause speeds to swing sharply rather than disconnect completely.

After reconnecting, keep the test source unchanged and change only the route. Prefer a geographically closer region with a more direct path; if the target service requires a specific region, compare routes that meet that requirement. Do not assume the farthest route is best for accessing content: more network hops usually mean more variables. NeeVPN provides 90+ countries / 200+ routes. Use the routes page to review coverage and types, but choose based on the current network and target service.

Identify the typical boundaries of peak-hour issues

If performance is stable during the day but slows noticeably at a specific time in the evening, and the same device shows similar changes across several target websites, the issue may be at the local carrier exit, a regional transit link or congestion on the current route. First switch to another route in the same region while keeping the target website unchanged. If performance returns, the original route is unsuitable at that time. If all routes in the region are slow, compare a nearby region. If every region is slow and the original network also degrades, address the local and carrier links first.

Peak-hour troubleshooting should not focus only on instantaneous peaks. Persistent video buffering, repeated webpage timeouts and downloads staying slow for a long period are more meaningful than a brief maximum speed. Observe a complete task continuously and record the time range, route name and target service when lag occurs. Support needs this information to determine whether the issue is concentrated on a particular path rather than guessing from “it is slow.”

Reduce interference from the device and apps

Pause cloud sync, system updates, large uploads and background downloads, then test again. When upload capacity is saturated, webpages and real-time apps can also slow significantly because acknowledgements cannot return promptly. Many media pages open at once, multiple devices sharing one network and router sessions left open for too long can make a route issue appear worse than it is. NeeVPN supports unlimited simultaneous devices, so device count itself is not a plan limit, but devices sharing one access network still compete for local bandwidth.

If only one download source is slow while other public sources work normally, the issue may be with the target server or its route for the current region; do not keep resetting the client. If all sources are slow on one route but recover after switching routes, record the original route. If the issue reproduces consistently across different routes and networks, submit a ticket with the comparison results. For more on latency, packet loss and proxy use, see Gaming Accelerator Recommendations: A Practical Comparison of Latency, Packet Loss and Proxies.

Frequent disconnects may appear as a connection status that keeps changing, access failing after the device wakes, the tunnel not rebuilding after a network switch, or a mobile connection expiring after the app has been in the background. This differs from a one-time connection failure: the client successfully established a session, but the conditions for maintaining it changed. Focus on whether the underlying network switched, whether the system paused background tasks, whether another network tool took over and whether the client can rebuild the tunnel after the network returns.

Separate route drops from device sleep

First check whether the client status changes at the same time as the disconnect. If the client clearly shows Disconnected, record whether the device was locked, entered sleep, switched Wi-Fi or moved out of the original network’s coverage. If the client still shows Connected but all access has stopped, disconnect and reconnect, then check for a residual system route. If only one app stops responding while others work, the entire session has not dropped; continue with the per-app section.

After a desktop device wakes from sleep, its network interface may not yet have recovered while the client still retains its pre-sleep state. Wait for the system network to return before reconnecting instead of repeatedly clicking Connect without a working underlying network. If the issue reproduces after every sleep cycle, disable automatic connection and test manual reconnection first. If manual reconnection works but automatic recovery fails, submit the complete pattern: “normal before sleep, fails after waking, manual reconnect works.”

Check mobile background policies

Mobile operating systems manage apps based on battery level, background activity and network state. If the client is stable only in the foreground and disconnects when the screen locks or you switch apps, check whether background operation is allowed and whether power-saving policies restrict network activity. Device manufacturers use different names for these controls, but the method is the same: allow the client to run in the background, prevent the system from ending it automatically, then repeat lock-and-resume tests on the same network.

Also check whether another on-demand VPN configuration is enabled. When the network switches from Wi-Fi to cellular data and back, multiple configurations may compete to connect. Keep the configuration you need and temporarily disable other automatic connections. If dropouts occur only during a network switch, let the client complete a new handshake instead of selecting several routes repeatedly during the transition.

Check network jitter and route sessions

If the device stays in the foreground and the network does not switch but the connection still drops frequently, first try another route in the same region. If only one route has the problem, record it and temporarily use another available route. If several routes drop on the current network but recover after changing networks, the original network may have session timeouts, packet loss or route changes. If both the current and alternate networks drop while another device works, return to device permissions, conflicting tools and client configuration.

Do not use automatic reconnection to hide the problem. It can handle an occasional network change, but persistent underlying jitter makes the client repeatedly create and release sessions, causing battery drain, repeated app-request failures and changing exits. Check the Wi-Fi signal, router status and frequency of network changes first. If the dropout has a consistent trigger—such as screen lock, sleep, a network switch or launching a security tool—state that action clearly in the ticket.

A subscription update can fail at several stages: the user dashboard cannot retrieve it, the client reports a format error during import, the route list does not change after import, or the old configuration continues to be used after updating. First identify whether the failure is in the dashboard, transfer, parsing or local selection. Never post subscription contents publicly or send a real subscription URL to a public page or group.

Confirm the account and plan status in the user dashboard first

After signing in to the dashboard, check the plan and traffic status. NeeVPN monthly plans include ¥9.9/month with 60GB, ¥18/month with 250GB and ¥28/month with 500GB. Traffic resets monthly on the activation date, and mid-cycle upgrades are prorated by the remaining days. Traffic packages include ¥158/300GB, ¥358/1000GB and ¥658/3000GB; they remain available until used and never expire. If the dashboard clearly shows an abnormal plan status or unavailable traffic, resolve the account or billing issue first; reinstalling the local client will not change the dashboard status.

Registration requires no email address; a username and password are enough. When checking the account, confirm that the signed-in username is the one with the purchased plan, especially on devices where multiple accounts have been saved. Payment methods are Alipay / WeChat Pay / USDT. If the payment record and plan status do not match, include the dashboard order status and payment time in a ticket, but do not expose complete payment details publicly.

Remove old entries before importing again

When a client contains multiple configurations with the same name, a successful update may appear to do nothing because the old configuration is still selected. Record any local rules you need to keep, delete invalid or duplicate subscription entries, then retrieve and import the subscription again from the user dashboard. After importing, check the new entry’s update time or route list, then explicitly switch to the new configuration. Do not manually assemble subscription content from text copied halfway from a webpage.

If you need to test whether a client accepts a subscription format, use only an obviously fake example to check the input and interface flow; do not expect a fake address to return routes. Always obtain the real subscription from the user dashboard. The address below is for documentation only and does not correspond to the NeeVPN service:

https://example.com/sub?token=YOUR_TOKEN

If the user dashboard opens in a browser but the client times out while updating, check whether the client is incorrectly routing the update request through an expired configuration. Some clients offer “update through proxy” or “update using the system proxy.” With the original network working, temporarily disable that option, complete the update and then restore your usual settings. If the original network cannot reach the dashboard, fix the underlying network first instead of changing subscription parsing methods.

Distinguish format errors, authentication failures and network timeouts

A format error usually appears immediately after content is retrieved, indicating that the client cannot recognize the response, the copied content is incomplete or the import method is incompatible. An authentication failure usually points to the account session, subscription status or an expired retrieval method. A network timeout means the request did not complete within the expected time; compare browser access to the dashboard and check whether changing networks helps. Each error type needs different evidence, so preserve the exact error text in a ticket instead of summarizing it as “the subscription is broken.”

If the same subscription imports normally on another platform but continually fails on the current one, first check the current client’s import entry point and system network permissions. If retrieval fails on every platform while the dashboard status is normal, submit a ticket. Client downloads and subscription retrieval must always be completed through the user dashboard download area. Do not use static installer links or copy configurations from unofficial pages.

When the browser works but an app cannot connect, or only domain access fails while the connection itself is normal, the issue has usually narrowed from “is the route available?” to “how is traffic classified and resolved?” Per-app rules determine which processes enter the route, domain rules determine which exit a request uses, and DNS determines which address a domain resolves to. They are related, but verify them separately.

Confirm that the app follows the current traffic-capture method

Some desktop programs follow the system proxy, some use an independent network stack, and others deliberately ignore system proxy settings. If the client currently uses only a system proxy, compare by switching to a supported virtual network interface mode when the browser works but a standalone app does not. Before switching, quit other VPNs, proxies and network filters so several programs do not modify routes at once. Restore the original setting after testing and confirm that the change was caused by the traffic-capture method.

When one mobile app cannot connect, first check whether the client has enabled a per-app list. The list may use either “only selected apps use the route” or “selected apps do not use the route,” which are opposite behaviors. Read the full description of the current option rather than checking only whether the app appears in the list. Add the target app to the correct scope, then fully close and reopen it; existing connections do not always migrate automatically to the new path.

Check domain rules and the final match result

In rule mode, a request typically matches domain, address, app or default rules in sequence. If the target domain is mistakenly classified as direct, that request will not use the selected route even though the client is connected. Temporarily switch to global capture for comparison: if global mode works, the route and target service are probably available and the issue is in the rules. If global mode still fails, continue with DNS, target region and the app itself. Use global mode for diagnosis; it does not need to remain enabled permanently.

If the client supports connection logs, check which rule matched the target domain and which exit was selected, without exposing sensitive data. If the target request is completely absent, the app may be outside the client’s capture scope. If a direct rule appears, check rule priority. If a proxy was selected but the request still times out, check the route, DNS and target service. Mask subscription and account details in log screenshots.

Handle DNS resolution failures, stale caches and independent resolvers

Common DNS symptoms include a domain reported as nonexistent, different resolution results for the same domain across apps, an old region still appearing after switching routes, or different results between the browser and system command line. Disconnect and reconnect the client to rebuild its resolution path, then fully quit the target app and clear the system or app DNS cache. Do not manually specify multiple conflicting DNS sources at once.

The browser may use independent secure DNS, the system may use the network provider’s resolver, and the client may provide an embedded resolver. When all three paths coexist, the browser may work while other apps fail, or vice versa. For comparison, first disable the browser’s independent resolver so the system and client use the same path. If that restores access, decide whether to keep the browser setting. If the client supports local DNS capture, ensure system requests actually enter the client instead of being intercepted by another network tool.

For further checks of exit IP, DNS and per-app results, follow the connection verification guide and record each result. In a ticket, state the target app, traffic-capture mode, the difference between rule and global modes, and whether DNS queries succeed. This makes it possible to determine whether to inspect client rules or route resolution.

NeeVPN supports unlimited simultaneous devices, so a device-related message should not automatically be treated as a plan limit. More often, the current device is using an old configuration, different devices are signed in with different usernames, the plan or traffic status has changed, or client settings are inconsistent. This final chapter checks account boundaries and organizes completed troubleshooting into information support can reproduce directly.

Confirm that every device uses the same valid account

Confirm the current username, plan and traffic status in the user dashboard, then check the configuration source on each device. In homes with several devices, a new device may have the latest subscription while an older device still retains an earlier configuration; one device may also be signed in with a username that has no purchased plan. Do not assume configurations match just because route names look similar. Retrieve the current subscription again on each device and remove duplicate entries.

For family sharing and simultaneous-device calculations, read Best VPN for Multiple Devices: Family Sharing and Device Limits Compared. NeeVPN’s stated limit is unlimited devices, with no fixed simultaneous-device cap. However, devices sharing one home network still share local bandwidth; a large transfer on one device can make others feel slower. This is competition for access-network resources, not an account device limit.

Confirm traffic status and billing cycle

Monthly-plan traffic resets each month on the activation date, not on a shared calendar-month schedule. Available monthly plans are ¥9.9/month with 60GB, ¥18/month with 250GB and ¥28/month with 500GB; mid-cycle upgrades are prorated by the remaining days. Traffic packages are ¥158/300GB, ¥358/1000GB and ¥658/3000GB, available until used and never expiring. If you can sign in but cannot connect further, or the dashboard reports an abnormal traffic status, first check whether the current service is a monthly plan or a traffic package.

If the dashboard status appears inconsistent with the order, do not place repeated orders as a test. Keep the order status, payment method and time of occurrence, then submit a ticket. NeeVPN supports Alipay / WeChat Pay / USDT and offers a 60-day no-questions-asked refund. Refund rules and plan details are governed by the plans page and Terms of Service. This manual covers technical diagnosis and does not speculate about order outcomes.

When should you stop troubleshooting locally?

Submit a ticket when the same error occurs across devices, networks and multiple routes; the dashboard and client status clearly disagree; the subscription cannot be retrieved on any platform; one route consistently reproduces the same error; or the client has repeatable crashes, authorization failures or leftover configurations. Randomly changing system settings further can destroy the original state and make reproduction harder.

If the issue affects only one website, first confirm that other services work, whether the target site requires a specific region and whether signing out of the old session restores access. If only one app is affected, complete a rule-mode versus global-mode comparison. If it occurs only during peak hours, record at least the time, route name, original-network comparison and target service. If it occurs only after screen lock or sleep, clearly describe the trigger and recovery method.

Protect account information when submitting

Tickets must not include passwords, complete subscription contents or other authentication data that can be used directly. Mask sensitive account areas in screenshots and keep only the error message, route name and client status visible. If support needs more information, the ticket will specify the required scope. Do not split one issue into multiple duplicate tickets; scattered context forces support to repeat checks you have already completed.

After submitting, keep the basic environment that reproduces the issue whenever possible instead of immediately changing the client, system network, route and rules together. If the issue resolves on its own, add the recovery time, route in use and any actions taken to the original ticket. This helps distinguish a temporary path change from a device-side settings issue. Check common questions in the FAQ, and continue complex cases through user dashboard tickets.