Connection Troubleshooting Guide

Cannot Connect at All: Identify the Failing Layer First

“I clicked Connect, but nothing happened” is only the surface symptom. The client may not have received a valid subscription, the selected route may be temporarily unreachable, the local network may be offline, the system proxy may not have switched, or an old configuration may still be occupying the channel. During diagnosis, do not change the route, protocol, rules, and DNS at the same time. Change one variable, retest, and record the result; otherwise, even if the connection returns, you will not know what fixed it and will have to troubleshoot in the dark next time.

Start with a Minimal Check

First, quit and reopen the client. Confirm that route names are visible instead of an empty list, an expiration notice, or a subscription read error. Then disconnect and reconnect to the current route, watching where the status stops. If clicking Connect immediately returns to Disconnected, check whether the configuration is complete. If it remains on Connecting for a long time, an unreachable route or local network filtering is more likely. If the interface says Connected but no page opens, move to the next section to check the system proxy and DNS instead of clicking repeatedly.

Next, verify the local network. Temporarily disconnect the accelerated connection and open a website that normally works. If the underlying network cannot open it either, fix the local network first; a client cannot conjure a track for a device that is offline. If the basic network works, test another route in a different region. JVVPN covers 90+ countries / 200+ routes. Switching routes is not about blindly trying options; it helps determine whether the failure is limited to one route or affects the entire client environment. If only one route fails, note its name and switch routes for continued use. If every route fails, check the client and system layers.

Stop Programs Fighting for the Steering Wheel

When multiple proxy, network-filtering, security, or corporate-access tools run at once, they may compete for the same system proxy settings. The client may show a successful connection while system traffic never enters it. Or a previous tool may leave behind a proxy address, sending pages to a local endpoint that no longer exists. Fully quit other tools of the same kind during diagnosis—not just their windows—and check that no process remains in the tray or menu bar. Then check the system network settings to confirm that the current client controls the proxy. Do not manually retain an address from an unknown source.

On Windows, use the system proxy settings to confirm that automatic or manual proxy settings match the current client state. On macOS, check the network service currently in use rather than an idle interface. On Linux, remember that the desktop proxy, terminal environment variables, and app-level proxy are three separate configurations that may not recognize one another. If a proxy environment variable was previously set in the terminal, inspect the current session first:

env | grep -i proxy

If you see an old address, unset the corresponding variable in the current terminal, then restart the command-line program you need to test. Do not place proxy variables from an unknown source in a global startup file; that is like handing every terminal an expired boarding pass.

Reset Order Matters More Than Reinstalling

If you still cannot connect at all, follow this order: disconnect, quit the client, close other network tools, reopen the client, update the subscription, switch to another route, and connect again. Only consider obtaining the client again if it will not start, its configuration file is damaged, or system permissions are clearly missing. Download the client from the download area in the user panel, not from an untrusted installer. Quit the old client before reinstalling to prevent old and new processes from running together.

If the connection works after changing networks, the original network may differ in routing, DNS, or access policy. If every network fails but the same account works on another device, focus on the current device. If multiple devices and routes fail at the same time, record the time, client platform, route name, and exact error text, then go directly to the support-ticket section. This branching approach is more useful—and kinder to your hair—than trying “one more restart.”

Connected but Websites Won’t Open: Separate Proxy and DNS

A Connected status only confirms that the connection sequence completed. It does not prove that domain resolution, the system proxy, and app traffic are all following the same path. When a website will not open, distinguish between “every site fails,” “only domain names fail,” “only one site fails,” and “the browser fails while other apps work.” These symptoms look similar, but the fixes are completely different.

Use Domains and Basic Requests to Isolate the Fault

Disconnect first to confirm that the basic network works, then reconnect and open several different websites. If every site fails while the client shows no obvious error, check whether the system proxy is enabled and whether the browser has its own proxy configured. Browser extensions may override system settings, so temporarily disable relevant extensions and test in a normal window rather than a session full of old state. If only one site is affected, clear that site’s cache and sign-in state, then retest with another route. Do not condemn the entire client because one site is undergoing maintenance.

Use the following command-line checks to see whether a domain resolves. The example domain does not involve a real subscription or credential:

nslookup example.com

curl -I https://example.com

If the first command returns no resolution result while other basic network operations work, the problem is more likely DNS. If the first succeeds but the second fails, continue checking the proxy path, certificate time, and app settings. If the system clock is clearly wrong, encrypted connections may be rejected because certificate validation fails, so enable automatic time synchronization first. Do not skip error messages: “address not found,” “connection reset,” and “certificate invalid” point to different failure layers.

Typical Signs of a DNS Problem

DNS converts domain names into addresses the network can recognize. After switching connections, the system may continue using an old cache; the client may take over resolution while an app insists on its own method; or a home network device may retain an earlier result. Common signs include domains opening intermittently, different results in a browser and an app, content remaining unchanged after a route switch, and traffic still pointing to an old address after disconnecting.

Close the affected app first, disconnect the client, reconnect, and reopen the app. If the problem remains, clear the operating system’s DNS cache and try again. On Windows, run the following in a terminal with the required permissions:

ipconfig /flushdns

Caching behavior on macOS and Linux varies by system environment, so avoid copying long, high-privilege commands from unknown guides. A safer approach is to reconnect to the current network, restart the system’s resolver service, or restart the device. If the client offers DNS takeover, keep it consistent with the current mode. Do not enable client-side resolution while forcing a second resolver in the browser and expect them to fly in formation.

Make Sure Rules Are Not Sending Requests Through the Wrong Exit

Rule mode decides whether traffic uses an accelerated route or the local network based on a domain or address. If rules are outdated, categories are incomplete, or custom rules appear in the wrong order, a site may be sent through a direct connection by mistake. Temporarily switch to Global mode for testing. If Global works but Rule mode fails, the route itself is usable and the problem is in the rules. If both modes fail, return to DNS, the system proxy, or the route layer.

When users search for “VPN troubleshooting,” the actual issue is often inconsistent DNS and rule routing rather than a completely broken client. Focus on verifiable request paths: did the domain resolve, which rule matched, and which exit ultimately sent the request? Keep error screenshots and the domain used for reproduction. This lets support identify a rule issue directly and is far more useful than saying only “the website doesn’t work.”

Slow Speeds and Peak-Hour Stalls: Find the Bottleneck First

Slow speed does not necessarily mean a route is broken. The final experience depends on local access quality, wireless interference, route distance, the target service’s response, rule mode, device load, and time of day. A single speed test on one route that only considers the peak result produces emotion, not a conclusion. For a more complete method, see How to Test VPN Speed Accurately. This section focuses on quickly locating the fault in the moment.

Compare Before and After Connecting

On the same device and network, at roughly the same time, test website loading, file transfers, or streaming both disconnected and connected. If it is already clearly slow when disconnected, start with the local network. If disconnected performance is normal but every route is slow after connecting, check the client mode, device resource use, and the local network’s effect on encrypted traffic. If only a particular route is slow, switch to a region that is closer or better suited to the path.

Pause programs that are syncing, downloading, or uploading during the test. Cloud drives, system updates, video meetings, and local-network backups can consume the link. This is especially noticeable when upload capacity is saturated, making web requests feel sluggish too. Wireless connections are also affected by distance and co-channel interference. If a stable wired connection is available, use it for one comparison. The goal is not to switch permanently to wired networking, only to confirm whether the issue lies in this wireless segment.

Latency, Throughput, and Stability Are Different Metrics

Latency affects how quickly a response arrives after a click. Throughput affects sustained transfer capacity. Stability determines whether playback or a meeting pauses periodically. A low-latency route may not be best for large files, and a high-throughput route may not respond fastest to short requests. Choose based on the task: websites and interactive tools favor consistent responsiveness, streaming favors sustained throughput, and remote collaboration is particularly sensitive to jitter and brief interruptions.

Compare Across Time Periods and Routes During Peak Hours

If performance is normal during the day but repeatedly stalls in the evening, the issue has a clear time-of-day pattern. Do not repeatedly reconnect to the same route only when it stalls. Compare different regions or route types, and record which routes remain stable at the same time. See the routes page for route details and types. Direct routes are usually more straightforward but more sensitive to local network changes. Relay routes add an intermediate hop but may avoid an unsuitable cross-border path. IEPL dedicated routes suit situations where path stability matters. Choose based on the actual experience on the current network, not because one label is a universal charm.

When streaming quality drops, distinguish server-side adaptation from connection speed. Players adjust quality based on sustained transfer over a period of time, so checking immediately after switching routes can be misleading. Stop playback, switch routes, reopen the content, and see whether performance remains stable. For the relationship between bitrate, bandwidth, and quality drops, continue with Why 4K Streaming Drops All the Way to 480p.

If every route is slow on the same network but performance clearly returns on another network, include the local network type and time period in the ticket. If only one target service is slow while other sites work, record the target domain and the region in use. If speed fluctuates sharply, describe what happened over a sustained period rather than capturing only one peak result. Stability problems need a timeline; a single screenshot rarely shows exactly when the track went off course.

Frequent Disconnects and Mobile Background Drops

First distinguish between “the client disconnected itself,” “the system paused networking,” “the wireless network switched,” and “the system froze the app after it went into the background.” If foreground use is stable but the connection drops after locking the screen or switching apps, check background permissions and power-saving policies first. If it disconnects at regular intervals even in the foreground, network fluctuations, an expired route session, or conflicting network tools are more likely.

On Desktop, Rule Out Sleep and Network Switching First

After sleep, wake, a wireless-network switch, or a transition from wired to wireless, Windows, macOS, and Linux may continue to show the old connection as enabled even though the underlying path has changed. The safest recovery is to disconnect the client, confirm that the new basic network can open websites, and reconnect. If the issue appears after every wake-up, check whether power settings allow the network interface to shut down while idle, and disable other tools that automatically take over networking.

If a device is connected to multiple available networks, the system may switch automatically as signal strength changes. The session was established on the old interface and may break when the new one takes over. During diagnosis, stay on one network and temporarily disable automatic joining of others. If the connection becomes stable, the route is not the problem; interface switching is. Do not drift between access points while expecting the session to stay welded to the track.

Background Policies on iOS and Android

Mobile operating systems pause processes based on battery level, background activity, and app usage. If the client stops working soon after going into the background, check whether it is allowed to maintain a network connection, whether it is subject to strict power saving, and whether the system disables the current network when the screen locks. Do not use one-tap cleanup tools to force-close the client, and do not swipe away a process that still needs to work from the task switcher.

On iOS, confirm that the network configuration required by the client is still present. If it does not recover after a network switch or wake-up, open the client and reconnect manually. Android power-saving behavior varies widely, so allow the client to run continuously in the system battery or background-app settings and confirm that data access is not restricted. Setting names vary by device; the only standard is whether the client process and network connection are still allowed to remain active in the background.

Use Timing Patterns to Tell Route from Device

When disconnects are completely random, record whether a network switch, screen lock, wake-up, or high-volume transfer occurred. If it happens only on one route, switch routes but keep the route name. If every route drops on the same device while other devices work, check the current device first. If multiple devices drop on the same network but recover after changing networks, the local network is more likely at fault. This cross-check needs no complex tools—just change fewer variables each time.

If the client reconnects automatically after a drop but the app does not recover, close and reopen the affected app because it may still hold an old network session. If the client itself cannot recover, quit it completely and reopen it. When the issue is reproducible, do not keep reinstalling. Put “stable in foreground,” “what happens after screen lock,” “whether switching routes helps,” and “whether switching networks helps” in the ticket so support can trace the session lifecycle directly.

Subscription Update Failed: Check Each Link in the Chain

A subscription delivers available routes and configuration to the client. When an update fails, the client may continue showing old routes or clear the list. Do not delete an old configuration that still works; deleting first can turn “partially usable” into “completely empty.” Confirm the account status, retrieve the subscription again, verify in a browser or client that the link can be reached, and only then decide whether to replace or re-import it.

Confirm You Have the Current Subscription Entry Point

Sign in to the user panel and copy the current subscription entry point again from the overview or subscription area. Do not take the link from chat history, old documents, or a historical clipboard on another device. A subscription entry point is account-delivery information: import it only into a trusted client, never publish it publicly or give it to an unknown conversion service. A teaching example may look like this, but it is not a usable address:

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

If spaces, line breaks, or punctuation are added during copying, the client may treat the link as invalid. Use the panel’s Copy button and replace the old value in the client completely. If the client supports updating an existing subscription, update it rather than creating another entry. Create a new entry only when the subscription item itself is damaged, duplicated, or not editable. Delete the old item only after the new one is confirmed working, so both configurations do not fail together.

Handle Errors by Type

“Network error” usually means the client could not successfully reach the subscription entry point. Disconnect the current proxy and try updating, then try connecting to a working route before updating again; this helps reveal how the entry point is reached on the current network. “Format error” is more consistent with an unsupported response format, an incomplete copy, or content replaced by another page. “Authorization failed” means you should sign in to the panel again and retrieve the current entry point rather than repeatedly editing its characters. If the client reports a successful update but the routes do not change, check whether another subscription with the same name is open or cached configuration is still in use.

Some clients support automatic updates, but system background restrictions may prevent the task from running. Update manually once to confirm that the subscription works, then troubleshoot automatic updates. If manual updating succeeds but automatic updating fails, the issue is client scheduling or background permission. If manual updating also fails, continue checking the network and subscription entry point. Do not set an excessively aggressive update frequency; repeated requests will not make routes magically newer and may fill logs with duplicate errors that have no diagnostic value.

Avoid Configuration Overlap and Leftover Rules

After re-importing, a client may retain an old subscription, manual routes, and the new subscription at the same time. Before selecting a route, confirm which group it belongs to and remove exact duplicates that are no longer active. If a route appears but cannot connect, return to the “Cannot Connect at All” section instead of blaming the subscription again. Subscription updates solve configuration delivery; route connections solve network sessions. They are adjacent segments, not the same component.

If you can enter the panel normally but no client can update, record the platform, client name, exact error text, and the results of updating both while disconnected and after connecting. If only one platform fails while others work, the issue is more likely that client’s import format or network permissions. If the initial import flow is unfamiliar, read Complete iOS Subscription Import Guide or return to the Guides to review the main steps.

One App Bypasses the Proxy: Check Rules, Processes, and the Network Stack

If the browser works but one app cannot access anything, the overall connection is probably fine. The problem is likely in the app’s own proxy policy, routing rules, or networking implementation. Some apps follow the system proxy, some have a separate proxy switch, and others connect directly without reading system settings. Confirm that only one app is affected before deciding whether to change client rules or app settings.

Run One Isolation Test in Global Mode

Keep the same route and temporarily switch from Rule mode to Global mode. Fully quit the problem app, then reopen it. If Global mode restores access, the route and app are probably usable and the issue is in traffic routing. If it still fails, check whether the app has its own proxy, retains an old network session, or the target service provides content only in certain regions. Restore the original Rule mode after testing and address the specific rule; do not treat a diagnostic state as the final configuration.

Rules usually match in order. A broad rule near the top can match first, leaving a later precise rule no chance to run. When checking custom rules, focus on the target domain, related subdomains, and the service domains the app actually accesses—not only the product homepage. If the client shows connection logs or rule matches, watch whether the app’s requests use a direct connection or the proxy. Logs should not contain the complete subscription entry point, and account information should be covered before sharing screenshots.

Distinguish the System Proxy from Virtual Network Mode

The system proxy mainly affects programs that follow the operating system’s proxy settings. Virtual network mode takes over traffic at a lower level and usually covers more apps. If an app completely ignores the system proxy and the client offers a suitable takeover mode, test it after reviewing the system permission prompt. Disconnect before switching modes, then reconnect and restart the target app so an old session does not continue using the previous path.

Linux environments especially require separating the desktop proxy, terminal environment variables, container networking, and in-app proxy. A terminal program can inspect proxy variables with:

env | grep -i proxy

If the target program runs in a container or isolated sandbox, the host system’s proxy may not be passed through automatically. Configure networking according to that runtime environment instead of writing a real subscription address into an image or configuration repository. Example configurations should use dummy values and receive any required local proxy information at runtime.

Handle Cache, Region, and Sign-In Sessions

Some services consider the exit region, account region, cache, and existing sign-in session together. After switching routes, an old app process may retain its previous connection, so the website changes while the app does not. Quit the app, switch routes, confirm that the connection is stable, and reopen it. If the problem remains, clear that app’s cache or sign in again; there is no need to delete all data at the start. Begin with reversible actions before destructive ones—that is basic troubleshooting etiquette.

If a service works in the browser but not in the app, record the app name, platform, selected route, Rule-mode result, and Global-mode comparison. If results differ by route, visit the routes page to review regions and route types, then choose an exit suited to the target service. “The VPN connects but the app does nothing” often means the app ignores the system proxy or a rule sends its request through the wrong exit. Clarifying this layer is more effective than cycling through every route.

If an app stops working immediately after an update while other conditions are unchanged, first suspect a change in its network behavior or cache. Use a browser to test the same service for comparison, and state in the ticket that it “worked before the update and failed afterward.” Do not invent or guess a specific client version. Support needs reproducible conditions, not a version number that may be wrong.

Device and Account Issues: Don’t Mistake Sign-In Problems for Route Failures

JVVPN supports unlimited simultaneously connected devices, so under normal circumstances, the number of connected devices should not trigger a plan device limit. If another device works but the current one does not, focus on the current device’s configuration, subscription sync, account status, and traffic status—not on counting how many screens are running at home. For multi-device use in household settings, read A Complete Guide to Sharing a VPN Across Multiple Devices.

Check Account and Plan Status First

Open the user panel to confirm that you can sign in normally and review the current service status. JVVPN registration requires no email address; a username and password are enough, so keep the username safe. If you forgot your login identity rather than your client configuration, do not create several similar accounts. Otherwise, purchases, copied subscriptions, and support tickets can end up scattered across accounts like luggage sent onto the next flight.

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 are ¥158/300GB, ¥358/1000GB, and ¥658/3000GB; they remain available until used and never expire. If the client connects but then cannot transfer data normally, sign in to the panel and check the current subscription and traffic status instead of repeatedly refreshing the client. Plan details and the selection entry point are on the plans page.

Do Not Copy Cache Files Between Devices

On a new device, obtain the client for the current platform from the user panel and import the current subscription again. Do not copy another system’s client cache directory; it may contain platform-specific paths, old rules, expired sessions, or incompatible settings. JVVPN supports Windows / macOS / iOS / Android / Linux. System proxies, background permissions, and traffic takeover work differently on each platform. The subscription can be the same, but the client environment cannot simply be cloned.

If the route list is empty on one device while other devices work, manually update the subscription on the affected device. If updating fails, follow the subscription section. If routes are listed but none connect, follow the connection section. If a connection works but an app cannot access anything, follow the routing section. Splitting the diagnosis by stage prevents every problem from disappearing into the black hole of “account issue.”

Separate Account Sign-In, Client Subscription, and Payment Status

Successful website sign-in does not mean the client has imported the subscription. A subscription present in the client does not mean it has been updated to the current state. After payment, return to the panel and confirm that the corresponding service is displayed. Alipay / WeChat Pay / USDT are supported payment methods on this site. If an order status differs from expectations, view the order in the user panel and submit a ticket instead of creating duplicate orders to probe the system.

If the issue concerns expectations after payment, review the plan terms first. This site provides a 7-day no-questions-asked refund; submit the specific request through the user panel. Troubleshooting and refunds are separate processes. Continue submitting a ticket for technical diagnosis, while a refund request should clearly state the relevant order and request so support does not have to guess whether you want the connection fixed or the order handled.

When to Contact Support and How to Write a Ticket

The purpose of self-checks is not to turn users into part-time network engineers, but to collect enough information to define the fault boundary quickly. After confirming the basic network, testing another route, restarting the client, and updating the subscription, submit a ticket if the issue remains. If the same problem appears across multiple platforms, networks, and routes, stop taking the spacecraft apart locally; these symptoms are better suited to a unified service-side check.

These Situations Are Good Reasons to Submit a Ticket

All routes fail at the same time while the basic network works; the subscription entry point cannot update in different clients; one route remains faulty while switching routes restores access; a payment record exists but the panel does not show the expected service status; the same issue can be reproduced with fixed steps; or the client provides a clear error code or exact error text. Each situation has a clear object of investigation, allowing support to work through the account, subscription, route, or client layer.

If only one website is briefly unavailable, switch routes and test again later. If the basic network itself is down, fix the local network first. If only one app fails while the browser works, complete the Global-mode comparison before submitting a ticket. A support ticket is not a wishing well: the more specific the information, the fewer clarification rounds are needed.

What an Actionable Support Ticket Should Include

• Symptoms: State clearly whether you cannot connect, have no network after connecting, experience abnormal speed, frequent disconnects, a subscription update failure, or access failure in one app.
• Environment: Provide Windows, macOS, iOS, Android, or Linux, along with the client name.
• Route details: Name the route where the problem occurred and describe what happened after switching to another route.
• Network comparison: State whether the basic network worked while disconnected and whether changing to another network restored access.
• Mode comparison: If one app is involved, state whether Rule mode and Global mode behave differently.
• Exact error text: Copy the client’s message directly. Do not write only “there was an error” or rewrite it as a guessed conclusion.
• Reproduction steps: Starting when the client opens, describe each click in order until the error appears.
• Required screenshots: Screenshots should show the status and error, but cover the complete subscription entry point, account credentials, and sensitive payment information.

Recommended Reproduction Template

Issue type: Unable to open websites after connecting
Platform and client: Enter the actual platform and client name
Selected route: Enter the route name
Basic network: Websites open normally after disconnecting the client
Comparison result: Actual behavior after switching routes
Rule mode: Enter the current mode and the result after switching
Exact error text: Paste the complete message shown by the client
Reproduction steps:
Open the client
Update the subscription
Select a route
Establish the connection
Open the target website and observe the error

Replace the template descriptions with what actually happened. Do not include the complete subscription entry point or upload a configuration file containing a password. If the error occurs only during a particular period, state the approximate time and how long it lasts. If it is random, say whether the network was switched, the screen was locked, the device woke up, or a large transfer occurred beforehand. A clear timeline is more useful than a pile of unrelated screenshots.

Preserve the Scene After Submitting; Avoid Major Changes

After submitting a ticket, preserve the route name, client settings, and error information that can reproduce the issue whenever possible. If you must keep working, switch to a working route, but do not immediately delete every configuration, reinstall the system, or clear account data; once the scene is rewritten, support can only reason from fragments. If the issue resolves on its own, add the recovery time, whether you switched routes, and what actions you took to the ticket. This helps distinguish temporary route instability, expired cache, and local network changes.

The submission entry point is the support ticket center in the user panel. Support needs verifiable facts, not a cosmic broadcast such as “the server must be down.” Put the symptoms, environment, comparisons, and exact error text in place, and troubleshooting becomes an engineering problem instead of a guessing game. After resolution, restore the client to its everyday rules and usual routes rather than leaving it in Global mode opened temporarily for diagnosis.