Establish a diagnostic baseline: identify the failing layer first
The most common networking mistake is to reinstall the client, repeatedly import the subscription, or switch through many routes as soon as a page will not load. That changes several conditions at once, so even a recovery does not reveal what fixed it. A more reliable approach is to keep the test environment fixed and split the problem into layers: local network, client process, subscription data, route connection, name resolution, and app rules. Each layer should answer one question: can the basic network reach an ordinary website directly; has the client started correctly and obtained system permissions; does the subscription include currently available routes; has the selected route completed its connection; can the domain resolve; and is the target app actually using the network path provided by the client?
Before starting, record the affected device, operating system, client, network environment, selected region, and exact behavior. “The network is not working” is not specific enough; write “the connection button stays on Connecting,” “it says connected but no browser page loads,” “the browser works but one app does not,” or “it is normal during the day but slows noticeably at a regular busy time.” These descriptions lead to different troubleshooting paths. Also check whether the issue reproduces consistently: every time usually points to configuration or permissions; only on one network usually points to the local network path; only on one route suggests route status; and only in one app calls for per-app rules and the app’s own network settings.
Use the same device, network, and test target, and avoid broad changes at the start.
Compare different networks, routes, and apps to see which change the failure follows.
Record the exact error, time, route name, and checks already completed so the issue can be investigated further.
Start with the smallest reproducible test
The smallest test needs only one browser, one ordinary webpage, and one clearly identified route. Disconnect the client and confirm that the current network can reach familiar sites; then start the client and connect to just one route. After connecting, open a new private window and visit the test target. A private window reduces interference from old cache, extensions, and lingering sign-in state, but it does not replace DNS or system-proxy checks. If the private window works while a regular window does not, the cause is more likely a browser extension, cache, separate proxy setting, or web-filtering module in security software than the subscription itself.
Next, compare the scope. Keep the device and client unchanged while switching only the local network; keep the local network unchanged while switching to another route in the same region; then keep the route unchanged while switching the browser or app. If the failure follows the local network, check the access network first; if it follows the route, review the region and route type on the server page and choose an alternative for a similar use case; if it follows only the app, move to this page’s single-app section. The value of comparison is elimination, not a one-time lucky success.
Keep a rollback point
Before changing anything, preserve the original subscription and rules. If the client supports configuration export, export it locally first; otherwise record the current mode, selected route, and rule toggles at minimum. Do not combine subscriptions from multiple sources into one configuration before troubleshooting: same-named policy groups, duplicate rules, and different DNS settings can override one another. Do not copy a complete configuration from an unknown article to replace the current one. Adjust only the items directly related to the current hypothesis, then decide whether to keep or revert them after testing.
Once the baseline is complete, move to the section matching the symptom. If no connection can be established, start at the connection layer; if the client reports a successful connection but pages do not load, start with routing and DNS; if speed varies significantly, start with the test method and route match; if one app fails alone, start with the app’s proxy support and rule matching. This order reduces unnecessary reinstalls and gives a later support ticket enough context.
Cannot connect at all: separate network access, permissions, and route handshakes
“Cannot connect at all” needs to be split into more specific cases. An immediate failure after clicking Connect often indicates missing configuration, an unloaded subscription, denied system permissions, or a client core that has not started. A timeout after waiting may mean the current local network cannot reach the selected route, or that the route is temporarily unavailable. A connection that drops immediately calls for a check for another network tool competing for the proxy, virtual network interface, or DNS. The exact error text matters; keep the complete message and time, not just a cropped title.
First disconnect other software that changes the system network path, including another client of the same kind, a browser proxy set independently, or security tools with network filtering. This does not mean uninstalling anything; exit them temporarily to check for a control conflict. Then fully quit the JWVPN client and reopen it instead of repeatedly toggling the switch in its window. If the system has requested permission for a network extension, VPN configuration, or firewall, verify the permission status in system settings. When permission is denied, the client interface may still open but cannot create an actual network tunnel.
Confirm that the basic network is working
Keep the client disconnected and visit several ordinary sites that are normally reliable. If they also fail, fix the local network first and do not keep switching routes. You can disable and re-enable the current network connection, obtain network settings again, or compare with another trusted network. Public networks may require browser-based authentication; the sign-in page usually appears only while the client is disconnected. If a public network has just connected but internet access still does not work, open an ordinary webpage to trigger authentication, then return to the client and connect.
If the basic network works, check whether the system clock is obviously wrong. Encrypted connections rely on certificate validity periods, and a clock offset can cause a handshake failure. Enable automatic time and time-zone synchronization, then restart the client. Next, update the subscription and confirm that the route list is not empty. If every route name has disappeared, move to the subscription-update section; if routes exist but only one fails, switch to another route in the same region first; if all routes fail across multiple networks, check permissions, the client process, and subscription validity.
Use a comparison matrix to identify the access network or the route
| Test result | Most likely area | Next step |
|---|---|---|
| All routes fail on the current network, then work after switching networks | Local network access or network policy | Keep the working-network result and check authentication, routing, and filtering on the original network |
| Only the same route fails across multiple networks | Status of a single route | Switch to an alternative route in the same region and include the route name in the support ticket |
| All routes fail immediately across multiple networks | Permissions, the client core, or subscription status | Check system authorization, restart the client, and update the subscription |
| Disconnects immediately after connecting | Network-control conflict or sleep/wake transition | Exit other network tools, disable automatic network switching, and test again |
When to rebuild system network settings
Rebuilding network settings should come later, not first. Do it only when permissions have been confirmed, multiple networks and routes all fail, other devices can connect with the same subscription, and the current device has retained old virtual-network settings for a long time. Before deleting anything, quit the client and confirm that you are removing the intended network configuration; do not clear every saved network at once. Reopen the client, let the system create the required permissions again, and then run a single-route test.
If the client log shows consecutive failures, copy the text surrounding the failure time instead of uploading a complete system log containing unrelated private information. If the interface has no log entry, provide the exact error, system type, network in use, route name, whether the issue reproduces on another network, and the permission-check result. Support staff need a reproducible path, not a condition-free request to “fix it quickly.”
Shows connected, but websites do not load or DNS fails
A client showing Connected only means that the connection process completed; it does not confirm that browser traffic, domain resolution, and system routing have entered the tunnel correctly. Split this symptom into three cases: no address loads; a domain fails but a known direct address responds; or only some websites fail. For the first, check the system proxy and default route; for the second, focus on DNS; for the third, consider rule matching, the site’s own status, the regional route, or browser cache.
Open a new browser window and visit an ordinary webpage, then visit the target page. If every page fails, check whether the client has enabled a system proxy or virtual-network mode, and make sure the system proxy is not still pointing to another program that has exited. After an abnormal client exit, the system proxy may remain enabled while the local listening process is gone, producing the appearance of a successful connection while every browser request fails. Fully quit the client, disable the system proxy, test a direct connection, then restart the client; this usually confirms whether stale configuration is responsible.
Separate domain resolution from routing
DNS converts domain names into network addresses. When resolution fails, the browser may say that the server cannot be found, the name cannot be resolved, or something similar; when routing fails, it usually waits for a long time and then times out. You can use the system’s built-in lookup command to check whether a domain returns a result. The commands below query public example domains only and contain no subscription addresses or credentials:
nslookup example.com
# Also works on macOS or Linux
dig example.comA lookup can return an address while the browser still fails, so DNS is not necessarily working perfectly: the browser may use its own secure DNS, and the client may apply a separate resolution policy. Check the browser’s network settings, temporarily restore system DNS, and compare again. If the lookup itself fails, disconnect the client and repeat it: success while disconnected but failure while connected points to the client DNS configuration or selected mode; failure in both states means the DNS provided by the local network should be checked first.
Record the original DNS settings before changing anything, and avoid changing the router, system, browser, and client at the same time. With several layers configured, it is difficult to know which one is actually in use. The minimal approach is to have the browser follow the system and the system use automatic configuration, keeping only the client’s recommended resolution settings. If that restores service, add necessary custom settings one at a time and retest after each change.
How to assess when only some websites fail
First confirm that the target website itself is available. Visit the same address from another device or network rather than relying only on a search-results page. If the site works elsewhere, keep the client connected and switch to another route in the same region. If it recovers, the issue is related to the original route’s exit path or how the site handles that exit; if different routes all fail while other sites work, check whether a custom rule sent the target domain direct or whether the site requires a particular region. See the server page for route coverage and region selection, and do not assume the nearest route is best for every site.
Browser extensions can also create localized failures. Content filters, script controls, privacy tools, and independent proxy extensions may affect only specific domains. If the page works in a private window where extensions are disabled by default, check them one at a time. If the private window also fails, clear the cache and cookies for that site only; there is no need to delete all browsing data at the outset. Sign-in state, region preferences, and old redirect cache can all make a site issue look like a network problem.
DNS still points to the original network after connecting
Some split-routing modes let part of DNS resolution continue through the local network; that can be part of the rule design and should not be labeled a leak solely from the resolver name. The real questions are whether the target domain resolves as expected, whether the target app’s traffic follows the selected path under the rules, and whether results change as expected between disconnected and connected states. For a global test, temporarily switch to the client’s global mode and repeat the lookup and visit; restore the original mode afterward so other apps do not remain on altered paths.
After sleep, a network switch, or a client crash, old DNS cache entries may remain. Disconnect and quit the client normally, then reconnect the network and client. If needed, use the system’s built-in method for flushing the name cache, but do not copy long commands requiring elevated privileges from unknown sources. Flushing the cache only removes old records; it will not fix incorrect rules or an unreachable resolver, so return to comparison testing afterward.
Slow speeds and peak-hour lag: standardize the test first
Speed cannot be judged from a single download result. Slow page loads, video buffering, slow file downloads, and high interaction latency have different bottlenecks. Browsing depends more on resolution and connection setup; video depends on sustained throughput and how the platform identifies the exit region; remote work and gaming care more about round-trip latency and variation; and file downloads may be limited by the source itself. Before troubleshooting, write down exactly what is slow so results remain comparable after switching routes.
To establish a baseline, disconnect the client and perform the same task once on the same device and network, then repeat after connecting. Keep the target, file source, quality, browser, and time period consistent. Do not change the speed-test site while switching routes, and do not compare numbers displayed by different platforms directly. If the direct connection is already slow, the client cannot remove local wireless interference, congestion at the ISP access point, or public-network limits. First move closer to the access point, pause background sync, or use a stable network, then evaluate the route.
Choose routes by path, not just map distance
Geographic distance usually affects latency, but route type, transit quality, access-network conditions, and the target service’s location matter too. For a service in Japan, a Japan route is often a sensible starting point; for a work platform hosted in the United States, an Asia route is not always fastest. Choose candidate routes by target region first, then compare connection setup time, sustained stability, and error rate under the same task. JWVPN covers 100+ countries / 160+ routes, providing room to choose; it does not mean every target benefits from frequent cross-region switching.
If a route is fast immediately after connecting but becomes noticeably unstable with continued use, check whether background tasks started syncing, video quality rose automatically, the system is updating, or another device is using the local network. Unlimited devices means the account can be used across devices, but several devices running high-volume tasks still share the current local network and plan traffic. Pause nonessential tasks during speed troubleshooting so competition for access bandwidth is not mistaken for route congestion.
Compare peak hours under identical conditions
Peak-hour lag is usually time-dependent. Do not record only “slow at night”; record the difference for the same network, device, target, and route during normal and busy periods. If direct access and every route slow down together during busy hours, focus on the local access network; if direct access remains stable while one route slows and another in the same region works, keep the route name and switch; if every distant region is slow while nearby regions work, the cross-border path may be congested at that time.
For video or live streams, distinguish slow startup, automatic quality reduction, buffering at fixed intervals, and complete stream loss. Slow startup points more toward resolution or handshake issues; sustained quality reduction suggests insufficient throughput; fixed-interval buffering may reflect the player’s caching strategy; and complete loss requires checking whether the connection dropped as well. Sports streams are more sensitive to concurrent demand during event hours. See real-world sports streaming route tests for scenario-based comparisons, while treating results on the current network as the deciding evidence.
Change protocols and modes only with evidence
If the client offers different connection modes, do not assume that a more complex mode is always faster. Some modes improve compatibility but add processing overhead; others take a more direct path but may be unstable on the current network. Keep the same route and test target, change only the mode, and observe whether the issue changes consistently with it. If the difference appears only once, restore the previous mode and confirm again. In rule mode, also verify that the test traffic actually uses the route; otherwise you may be measuring direct access.
| Symptom | Check first | Useful comparison |
|---|---|---|
| Webpage opens slowly but is normal afterward | DNS, handshake, browser extensions | Private window and system DNS lookup |
| Video quality keeps dropping | Sustained throughput, local usage, route fit | Pause background tasks, then switch to a route in the same region |
| Lag at a regular busy time | Access congestion and cross-border path | Compare normal and busy periods under the same conditions |
| A single download source is slow | Source-side throttling or regional path | Compare other trusted sources instead of only changing routes |
When submitting a speed-related ticket, include the time period, access-network type, device and operating system, route name, the specific slow task, the direct-connection comparison, the result with an alternative route in the same region, and whether background tasks were paused. Do not attach only an isolated speed-test screenshot; it does not show the target, whether the intended route was used, or why the application became slow.
Frequent disconnects and mobile background drops
For frequent disconnects, first determine whether the connection tunnel actually stopped or whether the app simply stopped activity in the background. In the first case, all apps usually lose network access at once and the client status changes; in the second, an app may load briefly after returning to it and delayed messages may appear only in the foreground, while the client still shows connected. Mobile operating systems limit background processes, freeze inactive apps, or reclaim connections during network changes to save battery and network resources, so mobile troubleshooting differs from desktop troubleshooting.
Record what triggers the drop: after locking the screen, switching from Wi-Fi to mobile data, leaving the device idle, only in battery-saving mode, or even while using it in the foreground. If it happens only during a network switch, wait until the new network is fully usable and then see whether the client reconnects automatically. When Wi-Fi still appears connected but no longer works, the system may alternate between networks and repeatedly rebuild the tunnel. Temporarily disable automatic joining for unreliable Wi-Fi to test whether network switching is the cause.
Check mobile background and battery policies
On iOS or Android, confirm that the JWVPN network configuration still exists and that the client is allowed to perform necessary background activity. If strict battery saving, low-power limits, or per-app background restrictions are enabled, temporarily restore the system defaults for testing. Menu names vary by system, so do not follow a fixed path word for word; the key is to confirm that the client is not restricted from running in the background. After changing the setting, lock the screen and wait through a scenario similar to normal use before unlocking to check the connection, rather than returning immediately and drawing a conclusion.
If only one messaging or work app is delayed in the background while other apps reconnect immediately in the foreground, the issue may be that app’s background permissions rather than a dropped route. Compare the browser, system notifications, and another network app. If every app fails at once, the connection layer is more likely; if only one app is delayed, check its background refresh, notifications, and data-use permissions as well. Do not delete the entire global connection configuration to fix one app.
Common sources of desktop disconnects
On Windows, macOS, and Linux, check sleep/wake behavior, network-interface changes, and conflicts between clients. After a device wakes, an old network interface may be invalid while the client still retains its previous connection state. Disconnect normally and reconnect before force-quitting the process; this is more likely to preserve useful logs. If it happens after every sleep cycle, record the full sequence—“working before sleep, failed after wake, recovered after reconnecting”—so support can assess reconnection behavior rather than treating it as a random route failure.
When wired and wireless networks are connected at the same time, the system’s default route may move between interfaces. Temporarily keep only one stable interface; if that restores service, check interface priority in the system. A security tool’s network-filtering module may also reset the connection after a rule update. You can temporarily disable that module for comparison, but long-term security protection should remain enabled. If a conflict is confirmed, configure a compatible rule for the client’s network component in the relevant software.
Tell a dropped route from an app timeout
When a disconnect occurs, do not click reconnect immediately. First observe the client status, then try an ordinary webpage. If the page opens, the tunnel may still be active and the original app may have timed out or been disconnected by its server; if the page and other apps also fail, check whether the client is reconnecting. Then test another route in the same region. If the failure always occurs on the same route, use an alternative and include the route name in a ticket; if it follows the device rather than the route, focus on power settings, network interfaces, and system permissions.
If disconnects have no obvious pattern, keep a short log: time, current network, whether the screen was locked, whether the network changed, route name, whether all apps or one app was affected, and whether reconnecting restored service. After a few entries, shared conditions usually emerge. Compared with repeated reinstalls, this makes patterns such as “only on one Wi-Fi network,” “only after waking,” or “only on a particular route” easier to find.
For long-term use, keep system time synchronized automatically, avoid running several tools that control the system proxy or virtual network interfaces, and allow the client time to reconnect after a network change. Frequently toggling the network, force-quitting the client, and clearing system components can turn an observable issue into a new failure, so avoid these actions during troubleshooting.
Subscription update failed: address, authentication, cache, and traffic status
A subscription delivers the routes and policies available to the account to the client. Update failures may appear as an empty route list, old routes that remain, download errors, parse errors, or invalid authentication. First distinguish “the subscription content cannot be retrieved” from “the content was retrieved but the client cannot parse it.” The former points more toward sign-in state, network access, or the subscription address; the latter points more toward client compatibility, cached content, or the import method. Do not search for a replacement subscription after an update fails, as that makes the account state and source harder to verify.
JWVPN requires no email address; a username and password are enough to create an account. Get subscriptions and clients from the user panel; static marketing pages do not provide real subscription addresses. If you no longer know which source was imported, sign in to the panel and copy it again from the download or subscription entry instead of trying to construct the address manually. Avoid copying leading or trailing spaces, line breaks, or punctuation added by chat apps. If the client supports both scanning and pasting, use the other method for comparison, but do not import the same subscription into multiple configurations.
Confirm your account and plan status before updating
Sign in to the panel to view the current service status and traffic usage. 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. During troubleshooting, simply check whether the panel matches your current selection; do not calculate the remaining term or traffic yourself. If the status looks wrong, keep a panel screenshot and submit a ticket.
If the account is normal but updates fail, first confirm in a browser that you can sign in to the panel, then check the client’s current network. Some clients request subscription updates directly through the local network rather than through an existing route; others follow the system path. Try updating while connected and disconnected, using the results to determine whether the request path matters. If it works while disconnected but fails while connected, check whether a rule incorrectly routes the subscription domain; if both states fail, check the copied address, client compatibility, and system time.
Clear the old cache instead of rebuilding every configuration
If an update succeeds but the route list does not change, the client may still be using an old cache. Switch manually to another configuration and back, or use the client’s refresh function. If there is a cache-clearing option, clear only the current subscription cache; do not delete all local rules and custom settings. If re-importing is necessary, give the old configuration a recognizable name, import the new one, verify its route list, and then remove the old entry. This provides a quick rollback if the update fails.
A parse failure often means the client does not support the current content format, the copied content is incomplete, or the imported item was not the subscription entry. Use the panel’s client entry to obtain the method suited to the current platform. Import flows and system permissions differ across Windows / macOS / iOS / Android / Linux, so a local configuration file from one platform cannot simply be copied to another. If a new client imports successfully while an old one fails, keep the client name and exact error, but do not invent or guess a compatibility conclusion.
Use an obvious dummy value to check text handling
If you need to tell support that “the address was truncated at a certain step,” do not post real subscription content on a public page or forum. Use the clearly fake value below to demonstrate the field structure; provide the real address only through a controlled support ticket when requested:
https://example.com/sub?token=YOUR_TOKENIf the client deletes everything after the question mark when you paste, or automatically splits the address across lines, check whether the input field received the complete text. Paste directly from the system clipboard and avoid rich-text editors. If scanning fails, increase screen brightness, keep the entire QR code visible, and confirm camera permission; if it still fails, return to the copy-and-paste method. A QR code transfers the same content and cannot bypass account status or client-compatibility issues.
Update succeeds but routes are unavailable
A successful subscription update only confirms that the route list was retrieved. If the list appears but no route can connect, return to the Cannot connect at all section and check the local network and system permissions; if only some routes fail, switch to an alternative in the same region; if route names differ from expectations, first confirm that the client has activated the new configuration rather than an old configuration with the same name. With multiple subscriptions present, it is easy to update one configuration while connecting through another.
For a subscription-related ticket, include the platform, client name, whether the update was attempted while connected or disconnected, the exact error, whether the panel status is normal, whether copying the address again still fails, whether an old configuration exists, and whether another device can update. If the same account updates successfully on another device, the account and subscription source are probably usable, so the current device’s client, cache, or network path deserves closer inspection.
One app cannot use the proxy: check the app’s network stack and rule matching
When the browser works but one app does not, a route problem is often blamed incorrectly. Apps use different networking methods: some follow the system proxy, some use only the system virtual interface, some include their own proxy, some ignore system settings, and others split name resolution and business connections across separate processes. First confirm the scope of the failure and whether the app’s traffic entered the client; do not switch regions as the first step.
Keep the route unchanged and use the browser to open the web entry for the same service as the app. If both the web entry and app fail, the issue may be the route, region, or service; if the web entry works but the app fails, focus on the app. Fully quit and reopen the app so it creates a fresh connection; closing its window may leave a background process running. If the app has its own proxy setting, confirm that it does not point to an old local address and is not being layered on top of the system proxy.
Global mode is a diagnostic tool, not a permanent answer
Temporarily switch to the client’s global mode to determine whether rules are sending the traffic direct. If the app works in global mode but fails in rule mode, the route itself is probably usable; check whether the target domain, process, or address matches the intended policy. Do not abandon rule troubleshooting just because global mode works: it changes the path for other apps and may send local services through an unnecessary remote route.
Start rule troubleshooting with match records. If the client provides connection logs or an active-connection list, open the app, perform one clear action, and observe the new domains and processes. Record the assigned policy group and check whether it is expected. An app may contact separate domains for sign-in, content, updates, images, and messages, so adding only the main domain may not be enough. Do not force every domain seen in the log onto one route; identify the failed request first and verify changes one at a time.
System proxy vs. virtual-network mode
With system-proxy mode only, apps that follow system proxy settings usually work, while apps that bypass them may connect directly. Virtual-network mode takes control at a broader system level and is better for diagnosing these apps, but it requires the relevant system permissions. If switching from system proxy to virtual-network mode restores service, confirm permissions and rules before choosing a daily setup. Fully restart the target app after changing modes, because existing connections do not automatically migrate to the new network path.
On mobile, apps are generally managed by the system network configuration, but per-app settings, local-network permissions, and background limits can still create differences. If an app fails only on mobile data but works on Wi-Fi, compare its data-use permission; if it fails only in the background, go to the background-drop section; if sign-in works but content does not load, different service domains may match different rules. Trigger sign-in, refresh, and download separately to compare the results.
In-app DNS and encrypted resolution
Some browsers and apps use their own encrypted resolution and bypass system DNS. If rules depend on domain recognition, an app’s independent resolution result may produce matches different from those expected. Temporarily make the app follow system DNS for comparison. If that restores service, choose a compatible configuration based on the client documentation; do not force multiple resolution services in both the app and client. Independent app resolution is not automatically a problem; treat it as a cause only when results change consistently with that setting.
If an app uses account region, device region, or content-licensing checks, connecting through a route in a particular region does not necessarily change the app account’s status. A network route changes the access path, not the app’s own regional policies. For streaming scenarios, see Streaming support for route-selection boundaries; for AI tools, see the AI Tools guide. When a service says the account is unavailable, distinguish a network error from an account policy instead of treating every message as a connection failure.
| Comparison result | What it points to | What to do |
|---|---|---|
| Browser works, app fails | App proxy support, independent settings, or process rules | Restart the app, check its independent proxy, and observe rule matches |
| Global mode works, rule mode fails | Incorrect domain, process, or address routing | Inspect the failed request and correct the rule; do not rely on global mode long term |
| Foreground works, background is delayed | Background permissions or system resource reclamation | Check the app and client background policies |
| The same service fails in every mode | Route region, service status, or account policy | Switch to a route in the same region and compare the web entry with another network |
For this type of ticket, include the app name, the exact failed action, whether the browser works, the difference between global and rule modes, the selected route, whether the app was foregrounded or backgrounded, whether the network was Wi-Fi or mobile data, and the failed-request domain or exact error from the log. Do not write only “this app does not work”; support cannot tell whether sign-in, content, uploads, notifications, or updates are failing.
Device-count notices and ticket escalation: when to stop local troubleshooting
JWVPN allows unlimited devices. If the client or panel shows a notice related to device count, do not guess at a hidden limit or delete every device configuration. First identify whether the notice comes from the JWVPN panel, the client, or the target website itself. Some apps limit signed-in devices or concurrent sessions, which is separate from the network service’s device policy. Keep the exact notice and the interface where it appears to avoid reporting a third-party account restriction as a subscription issue.
Unlimited devices does not mean every device must use exactly the same client configuration. Windows / macOS / iOS / Android / Linux differ in system permissions, import methods, and background policies. If only one device has the problem, compare it with a working device: same network, same route, same subscription source, correct system time, client permissions, and other network tools running. A working second device is valuable evidence; it shows that the account, subscription, and route work in at least one environment.
When to submit a support ticket
Stop local troubleshooting once you have a clear conclusion rather than continuing indefinitely. Submit a ticket when every route fails across multiple trusted networks, the same route fails consistently on different devices, the subscription cannot update on multiple platforms, the panel status does not match actual service, or the client keeps returning the same error despite normal permissions and basic network access. If only one public network fails, one app is delayed in the background, or the issue cannot be reproduced and has no record, support has little to work with; add comparison results first.
Describe the sequence of events in the ticket. State the normal condition first, then the triggering action, error behavior, checks already performed and their results, and finally the current status. For example: “The basic network works; after selecting a route in one region, the connection times out; an alternative route in the same region connects; switching networks does not resolve the timeout on the original route.” This is easier to investigate than “the route is broken.” For speed issues, also describe the use case and direct-connection comparison instead of posting only a speed test.
Support-ticket checklist
- Environment: device operating system, client name, and current network type.
- Symptom: whether the issue concerns connection, websites, DNS, speed, subscription, or one app, plus the exact error.
- Scope: all routes or one route, all apps or one app, and whether another device reproduces it.
- Conditions: time, selected region and route name, and whether it relates to screen locking, network switching, sleep, or busy hours.
- Checks completed: results after changing networks, switching to a route in the same region, updating the subscription, checking permissions, and exiting conflicting software.
- Attachments: redacted screenshots and log excerpts from around the failure time; do not expose the real subscription address.
How to provide useful screenshots and logs
A screenshot should include the error and enough of the interface to show the current state, while hiding the username, subscription address, and other private content. Do not capture only a red icon or submit an image cropped so tightly that its context is gone. Logs need only the relevant excerpt before and after the failure, with timestamps and error lines preserved. If the log is long, state the time of the failure in the ticket so support can locate the matching section.
Copy command-line results as text for searching, but before running a command confirm that it only reads network status, uploads no files, and changes no system settings. Do not run elevated-privilege scripts directly from public articles. If support asks for extra diagnostics, confirm the command’s purpose first and communicate through a user-panel ticket. JWVPN tickets are handled in the user panel; the available facts do not provide a public email or other external contact, so do not send account information to addresses found through search.
The boundary between refunds, plans, and troubleshooting
JWVPN offers a 7-day no-questions-asked refund. Refund policy and technical troubleshooting are separate paths: if you want to continue using the service, provide diagnostic details through a ticket; if you need the refund rules, see the refund policy. Payments support Alipay / WeChat Pay / USDT. For order-status questions, provide identifiable order details from the panel in the ticket and do not send complete sensitive payment-account information.
Plan selection can also affect how the experience is interpreted. Monthly-plan traffic resets each month on the activation date, while traffic packages remain available until used and never expire. If the panel shows traffic status that differs from expectations, screenshot the current status and ask support to verify it instead of calculating remaining traffic from the price. See the plans page for complete pricing and upgrade rules. Technical troubleshooting should focus on whether the connection is established, traffic follows the intended path, and the app works; do not mix plan calculations into route logs.
How to retest after submitting a ticket
After support provides a recommendation, verify one change at a time. If the advice is to update the subscription, keep the network, device, and route-selection method unchanged and retest only after updating; if it is to change routes, do not reinstall the client at the same time; if it is to adjust rules, preserve the original rules before editing. In your reply, state what you did, what happened, and whether the result reproduces consistently instead of replying only “still not working.” If service has recovered, also state the last effective action and the retest conditions.
An intermittent recovery does not confirm the root cause. For peak-hour, background-drop, and network-switching issues, verify again under the original trigger conditions; for subscription and permission issues, restart the client and confirm that the configuration remains valid; for a single app, repeat the specific action that failed before. Results are comparable only when the retest conditions match the original failure.
Related resources
If the symptom categories on this page do not cover the issue, visit the help center for account, connection, route, and billing questions, or open a user-panel ticket directly. Before submitting, include the environment, symptom, scope, conditions, and comparison results from this chapter’s checklist; that usually leads to useful troubleshooting faster than repeating “it does not work.”