VPNPM Troubleshooting Guide

Troubleshooting sequence / CONNECTION → ROUTE → APPLICATION

Identify the problem layer

Turn “it doesn't work” into an observable symptom

“Can't connect” can mean the client won't launch, the subscription list is empty, a connection attempt immediately returns an error, or the client says it's connected but the site you want won't load. These happen at different stages and need different fixes. First check whether the client lists any servers, then check its status after you tap Connect, and only then investigate the browser or a specific app. If there are no servers in the list, check the subscription import. If servers appear but connections fail, check your local network and the route. If the client says it's connected, move on to websites, DNS and traffic routing.

Run a quick comparison without the client: disconnect temporarily and open a site you can normally access to confirm your Wi-Fi or wired connection is working. If ordinary sites won't load either, fix the local network connection before switching international routes repeatedly. Then reconnect and test both a browser and the app with the issue. If the browser works but one app doesn't, the problem is more likely related to how that app's traffic is handled. If both fail, check the system proxy, DNS or current route.

Keep a short troubleshooting log

Before changing settings, note what was in place, what you changed and what happened. For example, keep the original route and mode, and switch only to another region. If that works, switch back and retest the original route. Then compare rule mode with global mode. Changing one variable at a time helps distinguish a region or route issue from a traffic rule issue, and avoids crediting a temporary network recovery to a setting change. If a page loads slowly, don't draw conclusions from just one site: test another familiar site and browser window to rule out a site outage or stale cache.

Compare different network environments when possible. Try your current Wi-Fi and another available network. If the issue occurs only on one network, check its captive portal, proxy restrictions or local DNS settings. Public Wi-Fi may require you to complete its web sign-in before the client can connect properly. Don't assume that a connection icon means the target service is reachable: it usually indicates only that the client has established a session with the selected route. Check the actual result in the app to confirm its traffic is using that route.

Finally, classify the symptom: if the connection attempt fails, continue to the next section; if you're connected but all websites fail, see the browser and DNS section; if speeds drop only during peak hours, compare routes; if just one app has a problem, see the split tunneling section. If the subscription list and plan status are both involved, check your account first, then investigate the network. VPNPM covers 110+ countries / 250+ routes, but coverage doesn't replace local troubleshooting. Pinpointing the issue is faster than trying every route at random.

SYMPTOM / CONNECTION FAILED

Can't connect: from your device to the route

Find out exactly where the connection fails

If the client won't open or quits immediately after launch, the problem is before the route connection stage. Check whether your operating system is blocking the app, and make sure you're using the client for your platform from the user dashboard. Don't download an installer from an unknown source. If the client opens but shows no servers, see “Subscription updates and account” to check the import status. If servers are listed but the client stays on Connecting or returns an error, note the exact error, check your local network, then compare another route.

Check that your system time and time zone are set automatically. If the time is significantly off, certificate checks can cause connection failures. Correct it, disconnect and try again. Also check whether another network proxy, corporate network client or system-level filtering tool is running. When multiple tools compete for the system proxy, they may all appear enabled even though traffic isn't following the intended route. For testing, keep one network tool active and check whether the symptom changes. Don't permanently disable security settings required on a work device just to troubleshoot.

Compare routes to isolate a local issue

On the same network, first try another route in the same region. If the issue persists, try another region. If only one route fails to connect, keep its name and error details, switch to a working route and report the issue to support. If all routes fail, don't keep trying at random. Check whether ordinary websites load on your current network, and whether you need to complete a network sign-in page first. Then see whether you can connect from another network. Differences between two networks can reveal more about local connection conditions than assuming every route is down.

Route types can help narrow down the cause. VPNPM offers IEPL dedicated routes, relay routes and direct routes in its region selector. They use different connection paths, but no type is guaranteed to be faster or more stable on every network. If one type keeps failing while another connects, report the network environment, region, route type and error together. That's more useful than a region name alone. Visit the Global Servers page to check regions and route types, then choose based on how you plan to use the connection.

On Windows and macOS, check whether the client has the system permission needed to create a network connection. On iOS and Android, confirm the system's network connection permission prompt. Linux users can check whether their current session has permission to apply the network settings requested by the client. Prompts vary by system version, so follow what appears on your device rather than looking for a button that matches someone else's screenshot. If the connection used to work but all routes suddenly started failing, consider whether you recently changed networks, modified the system proxy or enabled another network tool.

If you still can't connect after these checks, don't repeatedly delete your account or change plans. Send support the client's status message, affected route, network type, approximate time the issue started and the alternative routes you've tried. Support needs to know whether the failure occurred during launch, import, handshake or access to avoid making you repeat the entire setup process.

SYMPTOM / CONNECTED, NO PAGE

Connected but can't browse: check the proxy and DNS

First, check whether all sites fail or just one domain

When the client says it's connected, that only confirms the connection completed on the client side. Whether a web request goes through the route also depends on browser proxy settings, traffic rules, DNS resolution and the website itself. Try a few familiar sites. If none load, check whether another tool has overridden the system proxy and whether the client's current mode is active. If just one domain fails, save the error page and exact message, then check its DNS result and routing rule. Don't use only your browser's home page as a test: cached content may appear even when the network hasn't recovered.

Try switching between rule mode and global mode without changing anything else. If global mode works but rule mode doesn't, check whether the domain was incorrectly assigned a direct route. If neither works, compare another route, then check DNS or the target website's service status. Global mode is useful for a short diagnostic test; it doesn't mean all local websites should always use the same international route. When you're done, restore the mode that suits your regular use so temporary troubleshooting settings aren't left on your device.

Use DNS results to identify a DNS issue

DNS translates domain names into addresses used to connect. Common symptoms include a browser saying it can't find the server, a domain behaving differently on different networks, or an app failing to resolve a domain while other sites work. On Windows, run nslookup example.com in a terminal to see whether it returns a result. The same command also works on macOS and Linux. example.com is a public example domain, not a VPNPM subscription address. If the command isn't available, use your system's network diagnostic interface; there's no need to install extra software just to run it.

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

These two commands check different things: the first checks whether a domain resolves, while the second tries to retrieve a website's response headers. A successful DNS lookup followed by a failed connection doesn't automatically mean DNS is the cause; also compare the route and proxy path. If DNS resolution fails, check whether your system has a manually configured, unavailable DNS server and whether your browser uses secure DNS settings that differ from the system's. Note the original values before changing them so you can restore them later. On Windows, if you've corrected the DNS settings but still see an old result, run ipconfig /flushdns in Command Prompt to clear the local DNS cache. On other platforms, reconnect through the system's network settings instead of copying the Windows command.

Browser extensions can also manage the proxy independently. If one browser works and another doesn't, compare them in a window without extensions and check the affected browser's own proxy or secure DNS settings. There's no need to clear all browsing history right away. Corporate networks, campus networks and public Wi-Fi with a sign-in page may require local authentication first. Complete the network's sign-in process before troubleshooting further. If the issue occurs only on one route, note the domain and route type, try another region, then check your exit information on the Network Check page.

Compare what happens when disconnected, connected and switched to another route. If ordinary websites fail even when disconnected, the issue is likely closer to your network connection. If they fail only after connecting and switching modes changes the result, check traffic rules. If all apps report domain errors, focus on DNS. Don't present an unconfirmed cause as a conclusion. List the symptoms for each state in your support ticket so the team can reproduce the same steps.

SYMPTOM / SLOW OR PEAK HOURS

Slow speeds and peak-hour lag: compare routes fairly

First, identify what feels slow

“Slow” might mean a webpage takes a long time to appear, video keeps buffering, downloads fluctuate or audio drops during a remote meeting. Each activity depends on connection quality in different ways. For a slow first page load, start with DNS and latency. For a long download, observe a continuous transfer. Real-time calls need not just speed but also low jitter and packet loss. Don't judge an entire route by a download site's peak result or rely only on the client's connection status. First note the affected app, selected region and time of day.

Compare routes on the same device and network, using the same test. First check whether your local network is slow when disconnected. Then repeat the same action on the current route, changing only the route—not the browser or test site. If switching routes helps, compare the route or destination region further. If every route and the disconnected connection are slow, check your Wi-Fi signal, local network load or internet service first. For a structured guide to choosing tools, time slots and metrics, read VPN Speed Test Comparison. Don't treat numbers on a provider's marketing page as your personal speed test results.

Choosing a route for peak hours and cross-region access

Peak-hour lag often means things work during the day but buffer more during busy periods. Keep the same device and target service, then compare other routes in the same region when the issue occurs. Next, compare nearby regions and different route types. IEPL dedicated routes, relay routes and direct routes each suit different situations. Don't assume a route type is always better based on its name. If the target service has regional content requirements, choose a suitable region first, then compare the available routes there. The Global Servers page lists regions and route types to help you build an orderly shortlist.

Streaming services may also show a regional availability message because of content licensing. That's not a speed issue. For anime streaming and other region-specific content, check your account's region, content licensing and the selected route region first. Being able to open the home page doesn't mean a particular title is available. See the Japan Routes and Anime Streaming Guide for more on choosing a route. If an AI tool loads slowly, distinguish server load, account restrictions and failed network requests rather than blaming every delay on the route. Note the specific page or action and retest on another route at the same time; that's more useful than simply reporting that it's “slow.”

Downloads, cloud sync and system updates can also use your device's network bandwidth. Pause tasks that are clearly consuming bandwidth while troubleshooting, but don't radically change your normal setup; results from very different conditions may not apply to everyday use. On Wi-Fi, check whether ordinary websites also lag from the same location before investigating international routes. For peak-hour issues, describe when things are normally fine and when they slow down, and note whether both tests used the same device and network.

If multiple route types remain slow on the same network but work on another, investigate the original network first. If the issue occurs only on one route and at a particular time, report its name, region, target service and test conditions. VPNPM covers 110+ countries / 250+ routes, giving you options to compare; this doesn't guarantee any route will be fast at all times. The goal is to find a suitable path for your current situation, not a single “fastest” route independent of device and time of day.

SYMPTOM / CONNECTION DROPS

Frequent disconnects and mobile background drops

Tell a dropped session from an app losing background access

When a drop happens, check the client's status: does it explicitly show disconnected, or does it still say connected while just one app stops loading? The first points to a route or network issue; the second is more likely related to app routing, background restrictions or the target service. Note whether the drop coincides with sleep, screen lock, switching Wi-Fi, entering a subway or moving between network types. A network change alters the underlying connection. Even if the client reconnects automatically, an app that's transferring data may need to retry its request.

On desktop, keep the device awake and monitor the same route. If the issue occurs only after waking from sleep, check whether the system restored its network connection, then disconnect and reconnect once manually. If drops also happen while the device stays awake, try another route on the same network. If all routes drop at once, check whether ordinary websites also go down at the same time. Don't keep reinstalling the client before checking whether the network connection is stable. Another network tool taking over the system proxy can also make apps seem intermittently available even when the client shows a normal connection.

Background checks on Android and iOS

Android battery-saving policies may restrict the client from running in the background. Open the system's app battery management settings for the VPNPM client and check background activity and battery optimization. Menu names vary by manufacturer, so use the settings shown on your device. After making a change, lock the screen, reopen the affected app and check whether the client is still connected. If your system has an “Auto-start” or background activity permission, review it in light of how you use the device; there's no need to exempt every app. The Android Background Access and Split Tunneling Guide explains these settings in more detail.

On iOS, if there's a brief wait when you return to the app after locking the screen, first confirm the client's network permission is still active and see whether it reconnects after the system wakes. Don't assume that the route disconnected just because the app interface reloaded: the system may have suspended the foreground app while the network connection remained active. Compare access in a browser and another app to determine whether the issue is with the client session or just one app. If it happens only on a particular Wi-Fi network, check whether that network disconnects the device during standby or requires you to sign in again.

Windows, macOS and Linux each handle sleep and network reconnection differently. First check whether ordinary websites load after the system reconnects, then see whether the client needs to reconnect. For persistent connections such as meetings and remote sessions, switching networks or putting a device to sleep can interrupt the app-level session. Note both the client's status and the app's message so an app asking you to sign in again isn't mistaken for a route disconnect.

If switching routes stops the drops, note the original route. If switching networks fixes them, note the original network type. If locking the screen triggers them, note the platform and background settings. Each points to a different next step. Before contacting support, describe when it disconnects, what the client shows afterward, whether it reconnects by itself and whether manual reconnection works. “It disconnects a lot” isn't enough to distinguish a route issue from a network change or system background policy.

SYMPTOM / SUBSCRIPTION & ACCOUNT

Subscription update failures and device prompts

Check your account before troubleshooting the import

A failed subscription update doesn't necessarily mean the routes are unavailable. Sign in to the user dashboard and confirm you're using the original account. Check your plan and subscription status. VPNPM registration doesn't require an email address; a username and password are enough. If you use more than one username, don't mistake another account's empty subscription for a missing subscription on your current account. Once you've confirmed the account, get the subscription from the dashboard and update it using the client's import process. Don't use old content from chat history that may have expired, and never post subscription details in a public forum.

When an update fails, note exactly where: can't open the dashboard, can't copy the subscription, client reports a format error during import, or import succeeds but the server list doesn't refresh? If the dashboard won't open, follow the browser and DNS checks. For a format error, make sure there are no extra characters in the pasted content and that the import method matches a format the client supports. If the list hasn't changed, check that you updated the configuration you're actually using. If the client has multiple configurations with the same name, identify the active one before deleting anything—you could otherwise lose settings you can't restore.

Traffic resets and plan upgrades aren't connection settings

Monthly plans include ¥9.9/month for 60GB, ¥18/month for 250GB and ¥28/month for 500GB. Data resets monthly on the activation date; upgrades partway through a cycle are prorated by the remaining days. Data add-ons are ¥158/300GB, ¥358/1000GB and ¥658/3000GB; they remain available until used and never expire. To check your data balance, reset date or upgrade history, rely on the account details shown on the Plans page and in the user dashboard. Switching routes or modes, or reimporting a subscription, won't change your plan. Don't treat an account balance issue as a DNS or regional route problem.

VPNPM allows unlimited devices to be connected at the same time. If the client shows a device-related prompt, don't assume there's a fixed device limit that hasn't been announced. First check that you're signed in to the right account, the subscription belongs to that account and whether the prompt comes from the client or a target service. A device management message from the target service isn't the same as VPNPM's simultaneous connection policy. Send support the prompt, platform and account status to avoid misreading a screenshot that only shows the word “device.”

If updates fail on only one device, but the same account can retrieve routes on another, compare the client platform, import method and local network. If no device can retrieve a subscription from the dashboard, focus on the account status and dashboard error message. Download the client only from the Client Downloads page in the user dashboard. Don't look for an unofficial “fixed” version from an unknown source. If you're unfamiliar with the initial Windows import process, read the Windows Setup and Verification Guide, then come back to identify where the update failed.

After retrieving and importing the subscription, check that the server list appears, try connecting, then open the target website. Keeping these steps separate helps you tell whether the update succeeded but the route connection failed, or whether the subscription never updated. If the dashboard status and client message don't match, note the exact text and order in which they appeared, then send it to support. Buying another plan isn't a troubleshooting step for a failed subscription update.

SYMPTOM / ONE APPLICATION

One app won't use the proxy: check routing and region

Compare modes to trace the traffic path

If a browser can open websites but one app can't load, don't assume the entire route is unavailable. First check what error the app shows when disconnected. Keep the route the same, then compare rule mode with global mode. If global mode works but rule mode doesn't, check the app's routing rule: its domain or process may have been sent directly. If both modes fail, try another route in the same region and check whether the app needs an update, a fresh sign-in or different permissions. Restore your normal mode after testing so a temporary diagnostic setting doesn't become a permanent setup.

Some apps make separate requests for login, images, APIs and content delivery across different domains. A loaded home screen doesn't prove every request followed the same route. If you can sign in but the content area is blank, note exactly which step gets stuck. Split tunneling works the same way: the main app may use the route while its linked browser login page or a system component takes another path, preventing verification. On Android, check whether the app is included in the proxy scope. See the Android Split Tunneling Guide for instructions.

Separate regional restrictions from network failures

If a streaming service or other region-specific service says content isn't available, read the exact message first. A playback page that loads but won't play one title due to regional licensing is different from the entire app being offline. Compare the selected route region, your service account's region and the content's licensing region. VPNPM offers routes in different regions, but the content platform decides what it licenses and can't guarantee every title will work on every route. For anime streaming in Japan, the Japan Route Selection Guide explains how to check regional messages, dedicated routes and other route types.

AI tools may also have account, service-region or usage restrictions unrelated to your network. If a site opens in your browser but shows a clear account message when you sign in or submit a request, note the exact text instead of calling it a route failure. Test an ordinary webpage on the same route, then try another region to see whether the service message changes. If the same account or permission message appears on different routes, switching routes repeatedly is unlikely to resolve an account-level restriction.

On desktop, if a browser works but a native app doesn't, check whether the app has its own proxy setting and whether another tool changes the system proxy after the client connects. Some apps don't use the browser's proxy settings, so they can behave differently. On mobile, also check split tunneling, background management and network permissions. Don't change network rules for a work app without checking first. If the app is managed by your organization, confirm its own connection requirements.

After troubleshooting, summarize your comparison clearly: “The browser works on the same route, but the app fails in rule mode and works in global mode,” or “The same app shows the same licensing message in different regions.” That helps distinguish routing, route and server-side restrictions. If just one app is affected, provide its name, the action you took, the exact message and your mode comparison. There's no need to upload a full screenshot containing personal content.

WRAP-UP / VERIFY & ESCALATE

Retest, restore settings and contact support

Confirm the fix in the original scenario

Don't end troubleshooting as soon as the issue temporarily disappears. Return to the original network, app and action that triggered it, then test again. If it works only on another network or in a different mode, describe it as a working alternative—not as a fix for the original issue. Restore any temporary changes to the system proxy, browser secure DNS, app routing list and route mode. Keep settings that genuinely improve your experience. For peak-hour issues, a successful daytime retest only confirms daytime performance; check again during the time the lag normally occurs.

When restoring settings, work backward through your troubleshooting log and check that access still works after each change. If you changed system DNS, check the original settings before deciding whether to restore them. If you disabled another network tool required for work, turn it back on when testing is done and confirm that it doesn't conflict with the client. If switching routes solved the issue, you can keep using the alternative route while noting the original route for support. Avoid clearing all your settings while web access is working; you could lose a configuration that currently works.

When to contact support

Contact support through the user dashboard to submit a ticket if you still can't connect after checking your local network, comparing routes and testing modes; if the dashboard says your subscription is active but the client can't update it; if routes in multiple regions show the same issue under the same conditions; or if a particular route consistently fails at a specific time. If only a target website shows a clear account or content licensing message, check that service's own requirements before requesting route support. VPNPM offers a 7-day no-questions-asked refund. See the Refund Policy for the full terms.

A useful support ticket includes your device platform, the connection status shown in the client, selected region and route type, approximate time the issue began, target app or website, exact error message and checks you've already tried. Describe your network in general terms, such as “home Wi-Fi” or “office network”; you don't need to share your exact location. If the issue is reproducible, list the steps in order, such as “Open the client, select a route, tap Connect, then this error appears.” Hide your username, subscription details, order information and any other personal data that doesn't need to be shown in screenshots.

If the issue concerns billing, describe the plan status shown in the dashboard separately from the message you received. Don't infer a payment result from a single client message. VPNPM accepts Alipay / WeChat Pay / USDT. See the Plans page for plan details. Your ticket can include the payment method and order status, but never share your payment password or full payment credentials. If you just changed something in your account, refresh the dashboard to check its status, then send support any conflicting messages you see.

While you wait for a reply, you can use an alternative route you've verified works. Avoid repeating the same steps until the original error is lost. If support asks you to retest a specific route, keep the device, network and target service the same and change only one condition as requested. A complete troubleshooting log makes it easier to distinguish device settings, network access, route paths and the target service. That's the core method in this guide: identify the layer, make comparable changes and report only what you've observed.