VPN Troubleshooting Guide

Check your account and basic network

Separate account, network and client issues

Start troubleshooting by identifying which layer is failing, not by switching through every route. Your account determines whether the subscription is valid; your basic network determines whether your device can reach the service; and the client handles the connection and routing. Note which app is affected, which network you’re using, what the client shows and what changed recently. If the issue started after switching networks, check the network first. If it began after updating a configuration, check that configuration. Don’t combine symptoms from different times or devices into one conclusion, and don’t assume that opening the dashboard proves every route can connect.

Disconnect the client temporarily and open a website you can normally access directly on the same network. If those sites won’t load either, check your Wi-Fi connection, router and whether the network requires a sign-in page. A public network may let your device connect before you’ve completed its web-based sign-in; the connection icon can appear while external access is still unavailable. Get the basic network working first, then start the VPNYJ client. If the network works normally until you connect, keep this comparison for the next steps.

Check account status and device messages separately

Open the account dashboard and check your account, subscription status and remaining data. Monthly subscription data resets each month on the activation date, so don’t assume it resets on the first of the calendar month. Data add-ons remain available until used and never expire, but that doesn’t mean service continues after the data is used up. Check whether the transaction completed and whether the account matches the subscription imported into the client. If the payment page shows success but the dashboard hasn’t updated, keep the order status and submit a support ticket. Don’t place another order before the mismatch is resolved.

VPNYJ supports unlimited devices. If the client says you’ve exceeded a device limit, don’t assume VPNYJ has a device cap or that you need to buy more slots. First check whether the message comes from the VPNYJ dashboard, your operating system or another app. Make sure you haven’t imported an old service configuration and that another client isn’t still running. Unlimited devices doesn’t mean they can’t compete for bandwidth on your home network, or that proxy settings on one device apply to another. For advice on sharing an account, see our guide to multiple devices and family sharing.

Set up tests you can roll back

Before making changes, note the current configuration and route names, connection mode and which toggles are enabled. When closing other proxy tools, check whether they leave a system proxy, tunnel or background process running; closing a window may not stop the service. Don’t remove management policies, security software or enterprise networking tools from a work device. You can quit duplicate tools you installed yourself, restart this client and test the original website again. Before resetting network settings, read the system prompt and check whether saved networks or organization settings will be removed. Avoid turning a local issue into a device that can’t connect at all.

You’re ready to move on when the basic network works, the account is valid, the data status is clear, the configuration belongs to VPNYJ and duplicate proxies have been ruled out. If any condition isn’t met, address that issue first. If all are met and you still can’t connect, continue to the next section. Contact support if the dashboard and payment status don’t match, an unexplained device limit appears or a managed device won’t allow a required permission. Include the exact message and where it appeared—not just “my account doesn’t work”—so support can distinguish account delivery from a local issue.

Can’t connect at all: troubleshoot the connection path

Identify where the connection stops

No response after clicking Connect, a connection that keeps loading and an error immediately after connecting are different symptoms. If nothing happens, check local permissions and background services first. If it keeps waiting, check whether the route is reachable. If there’s a clear error, save its exact wording. Open the client’s status or log page and check whether the action creates a new connection entry. If the log doesn’t change, the issue may not have reached the network-request stage. Switching locations repeatedly won’t help diagnose that; first check that the client started correctly and that the system allows it to create a network connection.

On Windows, check whether another tool has taken over the system proxy or background components. On macOS, confirm the network permissions requested by the client in System Settings. On iOS and Android, look for the system prompt to authorize a VPN connection. On Linux, check whether your desktop environment and launch method allow the client to perform the required network operations. Menu names vary by system, so don’t look for options that aren’t there. If an organization policy blocks authorization, ask your device administrator instead of disabling system protections to get around it.

Compare routes across networks

After confirming permissions, stay on the current network and test another route. Try a different route in the same region first, then another region if needed. This helps distinguish a route issue from a regional path issue. VPNYJ offers IEPL dedicated routes, relayed routes and direct routes; see the routes page for details. Record the full route name and type, not just “Asia route.” If one route fails but others work, use an available route for now and report the failed example to support. That requires a different investigation from a failure across every route.

Next, keep the same device and route, but switch to another available network. If the original network fails and the alternative works, the issue is more likely related to the original network’s access conditions, routing or policies. If both networks fail, test the same subscription on another device, but don’t assume an old configuration on that device is an equivalent test. Matching errors across devices are useful evidence. After switching networks, reconnect the client; don’t judge the new network while the client is still using an old session.

Match the fix to the error—don’t change settings at random

Authentication failures and connection timeouts call for different checks. For an authentication failure, check account status, whether the subscription is up to date, and whether the device date and time sync automatically. For a timeout, check network reachability and route differences. For certificate errors, verify the system time, check for a network sign-in page and find out whether a managed network inspects traffic. Don’t disable certificate validation or install certificates from unknown sources. Parameters shown in a log may be internal to the client; don’t copy protocol settings from another service’s guide to replace the configuration supplied by VPNYJ.

After service returns, revisit the original test website to confirm it works; don’t stop just because the Connect button changed color. If you still can’t connect, include your device platform, the version shown on the device, the failed route name, network type and relevant log excerpt. Use the version displayed on the device. If permissions are in place, the account is valid and the issue reproduces across networks, support can investigate the client-service interaction. Remove subscription URLs and authentication fields from logs before submitting. Don’t keep reinstalling to collect evidence: a reinstall may erase the most useful error details without fixing the underlying network issue.

Connected but websites won’t load: DNS and exit routes

Connection status doesn’t guarantee access

When the client says it’s connected, that means it reports an established connection—not that every app is using it or that the destination site will accept the request. First check whether all websites fail or just one. If none load, focus on the system proxy, tunnel and DNS. If ordinary sites work but one service doesn’t, check the service status, account restrictions and exit region. Save the exact browser error: a name-resolution failure, connection timeout and certificate error point to different stages. Don’t lump them together as “the network is blocked.”

Use the same browser to open different sites and check whether the client log records the corresponding requests. No entries may mean the browser isn’t using the current proxy, or that client logging is disabled; an empty log alone isn’t conclusive. An old proxy address left in the system may also conflict with a new tunnel. Note the old settings, then reapply the proxy or tunnel using the method supported by the client. Don’t enable multiple connection modes while also changing the browser’s own proxy settings; stacking routes makes requests hard to trace.

Check name resolution separately from web connections

DNS translates domain names into addresses. If name resolution fails, the web request may never reach the destination server. If resolution succeeds but the connection times out, check routing, the proxy and the destination’s response. You can use the commands below on Windows, macOS and common Linux systems. If the tool isn’t available, use diagnostics built into your system or client. The example domain is for testing DNS only; it isn’t a VPNYJ server address. Save the result alongside the connection status at the time of the test—a result without its network conditions is hard to interpret.

nslookup example.com

A successful command doesn’t mean your browser used the same resolver. The browser may have encrypted DNS enabled, the client may handle DNS inside the tunnel, or the system may have an old cache. Check whether the browser has a separate DNS service configured. Note the current value, temporarily switch back to using the system resolver, then test the same site again. If the client manages DNS, restore its default configuration rather than entering an address found online. Corporate domains may require your organization’s private DNS path; a public resolver may find regular websites but not internal services.

Check caches, certificates and location

If only one browser fails, compare it with another browser or try a temporary session in the original one. A temporary session can help rule out some cache, extension and session-state issues, but it doesn’t change system routing. If clearing data fixes the issue, note whether you cleared the DNS cache or browser cache—they’re not the same. On Windows, use the command below to clear the system DNS cache when needed. It won’t fix a bad proxy, invalid subscription or destination-site outage. Reopen the site afterward and check whether the original symptom has actually changed.

ipconfig /flushdns

If a website loads but shows content for an unexpected region, use IP lookup to check the browser’s current exit address. If the lookup page fails, that alone doesn’t prove the tunnel is down; consider other access results too. The DNS lookup location, web exit and service account region may all differ. A single DNS result doesn’t prove a DNS leak or confirm the correct streaming region. For streaming availability, see streaming access support. If DNS errors persist after restoring the configuration, or normal sites keep showing certificate errors, submit the lookup output, browser error and network comparison so support can investigate.

Slow speeds and peak-time lag

First, identify what feels slow

A slow first page load, a slow sustained download, video buffering and choppy live calls put different demands on the network. First loads involve DNS, connection setup and page assets. Downloads depend more on throughput, while live calls are also affected by packet loss and jitter. A route-response figure in the client covers only part of the path; it doesn’t directly measure the speed of a destination website. Test the affected app and note whether the delay happens at the start, during sustained transfer or during playback. Don’t treat one speed-test site as representative of every international service.

Check whether other tasks are using your local bandwidth. System updates, cloud sync and video streaming on home devices can all compete for the same connection. Pause nonessential high-bandwidth tasks and retest the original app. Don’t run several downloads or speed tests at once. If your Wi-Fi signal is weak, move closer to the router or compare with a wired connection if available. If regular services are slow even with the VPN disconnected, troubleshoot the local network first. Changing routes can’t fix interference between your device and router or increase the capacity of your internet connection.

Choose routes by region, type and use case

Use the same device, network and destination service, then repeat the same action on a different route. Compare different route types in the same region first, then try another region. That makes it less likely you’ll mistake a difference at the destination server for a route difference. IEPL dedicated, relayed and direct routes describe path types, not guaranteed speed tiers. Performance also depends on your connection, destination and current conditions. A nearby location doesn’t always mean a shorter network path. Choose a route for the app’s region and access requirements, not just because its name sounds premium. See how to choose a VPN route for more guidance.

For video tests, keep the content and quality setting the same, and check whether the player automatically lowers the quality. Smooth playback after an automatic quality reduction doesn’t mean buffering at the original quality is fixed. Download tests also depend on the source: the server may limit speed, a browser extension may inspect the file, or storage writes may be the bottleneck. If other services work on the same route and only one source remains slow, report that service and what you were doing rather than concluding that every route is slow. Don’t include private download links in full in a support ticket.

Compare peak-time performance under the same conditions

Peak-time lag describes when an issue happens, not its cause. Home internet, regional networks, route paths and destination platforms can all change throughout the day. Keep a route that works at other times, repeat the same action at different times and note your time zone. If only the original network slows down in the evening while an alternative works, investigate the access network first. If one route slows markedly while another recovers, switch routes temporarily and report the comparison. Don’t treat “no peak-time lag” as a guarantee for every device or network. Diagnose the difference under consistent conditions.

See our guide to testing connection stability and tracking disconnects for comparison tips. If local bandwidth contention is ruled out, the destination stays the same and lag persists at reproducible times, submit your network type, route name, time, affected activity and results on an alternative route. Actual observations are more useful than “not enough bandwidth,” since bandwidth is only one possible factor. Once the issue is resolved, resume paused tasks one at a time to see which one brings it back. If cloud sync triggers the slowdown, manage local traffic rather than changing your subscription plan.

Frequent disconnects and mobile background drops

Tell a dropped tunnel from an expired app session

A chat app reconnecting or a website asking you to sign in again doesn’t necessarily mean the VPN tunnel dropped. Check the system connection indicator and client status, then see whether other apps lost access at the same time. If the tunnel is still up and only one app session ended, check that app’s background behavior or server session. If all requests fail at once, investigate the tunnel and network change. Note whether the device was locked, asleep, switching networks or out of Wi-Fi range just before the disconnect. These details are more useful than saying it “drops sometimes” because they can reveal a repeatable trigger.

A mobile device switching from Wi-Fi to cellular data, or a desktop waking from sleep, may need to establish a new connection. First test on one fixed network while the device is in the foreground. Then test with the screen locked and the app in the background. If it works in the foreground but fails in the background, look at system power-saving settings or background restrictions. If it fails in the foreground too, continue checking the network and route. Don’t change routes, battery settings and client installation all at once; even if the problem goes away, you won’t know which change helped or what to do if it returns.

Background behavior varies by platform

On Android, app battery management, background data limits and manufacturer power-saving settings can affect a persistent connection. Open the app’s settings on the device and check that background activity and network access are allowed as needed. Menu names vary, so follow the options shown on your device. Note the original settings before changing them, then consider any battery-life impact. On iOS, check that the VPN configuration is still valid, whether another system configuration is taking over the connection and whether the issue happens only after a network switch. Don’t apply background-permission instructions written for another platform.

On desktop systems, check whether the disconnect follows sleep or a network adapter restart. On Windows, see whether the client’s background service is still running. On macOS, check network extension permissions and whether other network tools are running alongside it. For guidance, see our guide to using VPN on Mac and compatibility. On Linux, distinguish a client launched with your desktop session from a standalone service that runs independently. A process stopping after you sign out of the desktop doesn’t prove the route disconnected. Set up automatic startup using the client’s own instructions; don’t add startup commands from unknown sources.

Choose the next step based on a reproducible trigger

If the connection drops after a specific action, test that action. For example, if it fails after screen lock but works again after unlocking and reconnecting, check background restrictions first. If it fails after leaving a network, check the network switch. If it fails immediately after selecting a particular route, check that route and its configuration. Also distinguish a normal shutdown, connection timeout and process exit in the logs. A system stopping a process is different from a remote disconnect. Don’t submit only the final error line; keep the events that led up to it so support can follow the sequence.

If disconnects continue on a fixed network while the app is in the foreground, test another route and another network. If the issue reproduces across networks and routes, or the client keeps exiting, ask support to investigate. Include the platform, version shown on the device, disconnect time, foreground or background state, and how the connection recovered. If only one app disconnects while others work, move on to the app-routing section. After recovery, test screen lock, wake-up and network changes again; a webpage working briefly in the foreground doesn’t resolve a background issue.

Subscription update failures and restoring configurations

Separate download failures from import failures

A subscription update involves fetching content, parsing it and applying the configuration. A fetch failure often appears as a timeout or access error. A parse failure means the client received content but can’t interpret it using the selected import method. An apply failure may mean the configuration parsed successfully but wasn’t selected for use. Save the full error and identify the stage where it occurs. Being able to open the dashboard in a browser doesn’t prove the subscription request succeeded; they may use different network paths. If the basic network requires a web sign-in, complete it before fetching the subscription again.

Check subscription delivery in the account dashboard; use the dashboard as the source of truth for the client and subscription link. When copying, avoid extra spaces, line breaks or explanatory text. Use the import method provided in the dashboard, not an old address of unknown origin from a chat history. A subscription URL grants access to your account; don’t paste it into a public checker or search box. If you need to show the steps, use an example value. The address below illustrates the format only; it cannot be used for a real import and is not a VPNYJ subscription endpoint.

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

Check the configuration source and update path

If the dashboard shows an active subscription but the update times out, try fetching it with the current connection temporarily disconnected. This can reveal whether you’re trying to update a configuration over a route that no longer works. If your organization’s network requires a specific proxy to access the service, don’t assume that disconnecting will prove the service is unreachable; record the network conditions. If content downloads but parsing fails, check that the client and import method match. Don’t convert the response into another service’s format or delete fields you don’t recognize. Choosing the correct import option in the dashboard is usually more reliable than editing the configuration by hand.

After updating, check the name and source of the configuration currently in use, and whether the route list changed. A client may store multiple configurations, so successfully updating one doesn’t mean it’s selected. You may still be using an old manually created route group. Select the correct configuration, then choose a route using the setup guide. Still seeing an old route name doesn’t necessarily mean the update failed; check what was actually delivered. The most useful evidence is the client’s displayed update time, result and active configuration—not a guess based on the number of routes.

Keep a way to roll back and avoid configuration clutter

Before deleting an old configuration, note any custom routing rules and local settings you may need. If just one configuration is damaged, create a fresh one from the dashboard for comparison rather than resetting the whole app. If the new configuration works, the issue may be in the old configuration or a custom setting. If both fail, check the network, account and import method. Restore manual rules one at a time, confirming access after each change. Don’t copy every override from the old configuration at once, or you may reintroduce the cause of the problem.

Monthly plans cost ¥9.9/month for 60GB, ¥18/month for 250GB and ¥28/month for 500GB. Data resets monthly on the activation date; mid-cycle upgrades are prorated based on the remaining days. Data add-ons cost ¥158/300GB, ¥358/1000GB and ¥658/3000GB, and never expire. Check these billing details on the plans page. Upgrading won’t fix a formatting error, permission issue or DNS problem. First check whether your data balance is affecting access, then decide if you need a different plan. Don’t mistake a technical issue for a data limit.

Submit a ticket if the dashboard shows an active subscription and you’re using the right import method, but fetching keeps failing across networks or the same parse error persists after importing again. Include the exact error, import method, platform, version shown on the device and whether you’ve used a custom configuration. If support needs private information, provide only what’s necessary through a signed-in ticket; don’t attach the full subscription. If you’re unsure about the basic steps, revisit the Guides. After troubleshooting, keep the configuration that works. Before removing duplicates, make sure you won’t delete the working one.

An app isn’t using the proxy: app routing

A working browser doesn’t prove other apps use the same route

If a browser works but an app on the same device doesn’t, first check whether both requests use the same path. The browser may follow the system proxy, while the app uses its own networking library. A system proxy doesn’t necessarily cover every app or type of traffic. A client’s tunnel mode may cover different traffic from its system-proxy mode. Note the active mode, then check client logs for the process, domain and matched rule. If there’s no relevant entry, check the logging scope; don’t treat “the app isn’t using the proxy” as a confirmed diagnosis based on that alone.

Check whether the app has its own proxy setting, network accelerator or fixed connection configuration. An old proxy address may bypass the current system settings or send requests to a local service that has stopped. Save the original value, then follow the app’s instructions to use the system settings or a path supported by the current client. Ask your organization’s administrator about work software, enterprise remote access and internal network tools. Don’t clear all corporate network settings to access external services. When multiple network tools are installed, identify which handles international access and which handles your organization’s intranet; startup order alone doesn’t reveal the final route.

Rule matches matter more than toggle labels

An app’s login, API, images and downloads may come from different domains. Loading the homepage doesn’t mean every later request follows the same rule. Check the requests generated by the failed action and match each domain to the rule that handled it. If a rule sends those requests direct, compare with a temporary mode already available in the client to see whether changing the path changes the result. A temporary test isn’t a permanent recommendation. Restore the original mode afterward to avoid affecting your organization’s intranet, local devices or other services. Don’t copy a long list of domains from an online post and guess which rule applies.

Rule priority and matching behavior depend on the client. Domain, process and final rules may apply to different traffic. Check the existing rule order before adding an exception. Process names vary by system and may change when an app updates; don’t create rules based only on the app’s icon name. If an app connects directly to an address, a domain rule alone may not cover its traffic. Keep a copy of the original configuration and follow the current client’s instructions when changing rules. There’s no universal configuration snippet that fits every platform.

Distinguish network failures from service account issues

If ChatGPT won’t open, distinguish a login page that won’t load, an API failure after login and a clear message about your account or region. For the first two, check domains, routing and connection logs; the last may not be fixed by switching routes. HBO and other streaming apps can also be affected by content licensing, account region and how the platform identifies the exit location. Route coverage doesn’t mean every route works with every service. See streaming access support for details. Don’t remove the platform’s account message and report only “connection failed.”

Browser extensions, encrypted DNS, cached data and existing login sessions can also make a browser behave differently from an app. After changing the exit route, an app may keep using an old connection. Fully quit and reopen it to test, but don’t repeatedly clear account data. Frequent region changes during payments, sign-ins or other sensitive actions may trigger the service’s own security checks. Keep the region stable during testing and note any change. For live calls, games or specialized traffic, first check whether the client supports the required path when system proxy coverage is limited. Don’t assume the route is at fault.

If changing the route fixes the app, narrow down the issue to a specific domain or rule. If the route is correct but the error remains, check the destination service and app account. If a request repeatedly matches the wrong rule, a process isn’t being handled or the tunnel conflicts with a corporate network, submit the app name, failed action, mode, matched rule and a redacted log. Screenshots must not include login tokens or private conversations. Support needs more than “this app doesn’t work”: explain which action failed, where the request went and whether an alternative path changed the result.

Verify recovery and prepare a support ticket

Repeat the original action after recovery

The issue is resolved when the original task works again—not just when the client says it’s connected. For a website issue, reopen the original page. For video, use the same content and quality setting. For background issues, test screen lock and wake-up again. For subscription issues, confirm the configuration has been applied and can connect. If you paused syncing, changed proxy mode or switched networks to troubleshoot, restore each one at a time and see whether the issue returns. Keep a configuration that suits your everyday use; don’t leave a temporary test setup in place long term.

Summarize the test as: “It failed under the original conditions, worked after one change, then failed again when I restored the original conditions.” This is more useful than a generic speed test or a series of screenshots. Be clear about the limits of what you tested: recovery at one time doesn’t prove all-day reliability, one working website doesn’t prove every app works, and one working device doesn’t rule out permission issues on another. Don’t draw conclusions beyond what you observed. If the symptom has disappeared but the cause is unclear, keep the logs and settings notes so you can repeat the same comparison if it happens again.

When to contact support

Submit a ticket if your account and transaction statuses don’t match, an active subscription keeps failing to download, or you still can’t connect across networks and routes. Also contact support if the client repeatedly exits, an unexplained authentication error persists, certificate errors keep appearing or a managed device has a network conflict. Don’t keep changing random settings. If one route fails while others work, use an alternative and report the failed example. You don’t need to test every route to prove there’s an issue; once you have a clear, repeatable case, expanding the test can make the record harder to follow.

Submit details through the account dashboard support ticket. Include your system platform, the version shown by the system, the version shown by the client, network type, full route name, time of the issue and time zone. Describe the failed action and exact error, and include the dashboard status and comparisons you’ve already tried. Use the support options available in the dashboard; don’t rely on supposed dedicated support contacts found in third-party search results. If this is a new issue unrelated to an earlier ticket, explain the difference. For follow-ups on the same issue, keep the context so support doesn’t have to ask again for details you’ve already provided.

Ticket template and sensitive information

In your ticket, describe in order: what action triggered the issue; what the client showed; whether the basic network worked; what happened after changing routes or networks; which settings you changed; and whether the issue returned after restoring the original settings. You don’t need to load the report with technical jargon—describe what you observed, not what you’re guessing. If logs contain personal domains, file URLs, session IDs or private content, remove anything irrelevant while keeping enough context to show the connection stage. Before cropping a screenshot, check the address bar, sidebar and notification area; sensitive details may appear outside the main window.

Support may ask you to provide logs for a specific period, repeat a comparison or confirm your client configuration. Keep the test conditions consistent and report clear results. Don’t change every setting while waiting for a reply, or your records won’t line up. If private information is needed, provide only what’s necessary through a signed-in ticket. Never share your password or post authentication details in public article comments. If you previously shared a complete subscription URL publicly, address the access-credential risk first, then continue troubleshooting. Redacting a log shouldn’t remove the error type or timestamp; otherwise only scattered words remain, making the request sequence hard to follow.

Handle billing and service arrangements separately from technical troubleshooting. VPNYJ offers a 60-day no-questions-asked refund; see the refund policy for how to request one. Payment methods: Alipay / WeChat Pay / USDT. You don’t need to prove a technical fault to ask about a refund, and a technical support ticket isn’t a promise of an extra discount. Troubleshooting helps identify the cause and restore access; it can’t guarantee that settings will resolve access issues with every destination platform. When you’re done, visit the Help Center for common questions or follow the Guides to review normal setup and use, then keep a configuration suited to what you need.