VPN Troubleshooting Guide

Turn “can’t connect” into an observable symptom

“Can’t connect” could mean the client won’t start, the connect button does nothing, the connection hangs, or it drops as soon as it comes up. Each symptom points to a different place to check. Note which screen the failure occurs on, the exact error message, and whether the selected route came from your latest subscription import. Don’t just capture a red icon or describe every error from memory as a timeout. Messages about authentication, name resolution, permissions, or connection refusal can help narrow down the cause.

Temporarily disconnect the client and check whether your local network can load ordinary websites. Public Wi-Fi may require you to confirm access in a browser first; a system message saying you’re connected to Wi-Fi doesn’t mean the network is ready to use. If regular browsing also fails, check your router, network access, or system connection first. Switching international routes repeatedly won’t fix a local outage. Once regular browsing works, restart the client and test again so you don’t mistake a failed prerequisite for a route problem.

Check account and client status separately

Sign in to the account dashboard and check whether your plan is active, whether data remains, and whether the client is using the subscription linked to your current account. A payment record and an active subscription aren’t the same thing; go by the benefits shown in the dashboard. Monthly data resets each month on your activation date, not on the first of the calendar month. Data packages never expire and remain available until used, but you still need to check the remaining balance. No expiry doesn’t mean unlimited data.

If your account is in good standing, check the client’s system permissions next. Mobile devices typically require permission to add a VPN configuration. Desktop tunnel features may need system privileges or network components. If you see a specific permission prompt, follow the client and operating system instructions rather than disabling all system protections. Work devices may have network settings restricted by your organization; ask your device administrator what’s allowed. Don’t try to get around a policy restriction by reinstalling, or mistake an administrator restriction for an expired subscription.

If your computer is also running another VPN, proxy app, network filter, or old background service, temporarily stop anything that isn’t needed for the current test. Multiple programs can change the default route or system proxy, making the connection look normal while their paths conflict. Save your original settings, then test with only the current client running. Restore settings afterward as needed so troubleshooting doesn’t leave your work environment changed. Get administrator approval before adjusting security components on a corporate network.

Use cross-checks to distinguish a route issue from an environment issue

On the same network, try other routes in your subscription without changing the client mode or target page. If one route fails but others connect, the issue is more likely with that route or the path to it. If all routes fail, test on another available network. If switching networks fixes the problem, investigate the original network environment. If other devices work on the original network, focus on this device’s permissions, leftover proxy settings, and client configuration instead of concluding that every route is down.

Seeing a route in the list doesn’t mean you can connect to it: the list comes from your subscription, while connecting requires access to the route’s entry point. Conversely, a client that can’t refresh the list doesn’t mean every imported route is unusable. Test subscription updates and route connections separately so you can describe the right issue in a support ticket. For route types and regions, see the international routes list. For now, focus on whether you can connect; there’s no need to change your route, mode, and DNS all at once.

Check in this order: regular network access → account and data → client permissions → one route vs. multiple routes → the same device on another network. Move to the next step only after the current one checks out. The first step that fails is where to focus.

When to stop troubleshooting and contact support

Submit a support ticket if your account is in good standing, system permissions are set, and you still can’t connect on different available networks, or if the error clearly concerns account authentication. Include your operating system, client, displayed route name, the stage where it fails, the exact error, and what happened when you switched networks. Include only the relevant log lines from around the failure, and redact your subscription URL and credentials first. Don’t keep repeating the same failed steps just to collect more logs. A short, reproducible sequence is more useful than a pile of repeated screenshots.

A successful connection doesn’t mean your requests are taking the right path

When the client says it’s connected, that only means it accepted the connection request or established part of a tunnel. It doesn’t prove that your browser is using it. Compare different websites first: one target site failing while others load is different from all sites failing. Note whether the browser reports a name resolution failure, connection timeout, certificate issue, or an access restriction returned by the site. A site-generated error page usually means the request reached a server, so don’t assume the whole network is down.

On desktop, check whether system proxy or tunnel mode is actually enabled. In particular, the connect button and the proxy-routing toggle may be separate settings. Some apps follow the system proxy; others need tunnel routing. A working browser doesn’t prove that every app can connect. Start with the browser as a baseline, then check individual apps in the app troubleshooting section. If the client shows connection logs, open the target page and see whether its domain appears and whether it’s routed directly or through the proxy.

DNS finds addresses; it can’t guarantee that a website will load

DNS translates domain names into network addresses. If this step fails, the browser may never start connecting to the site. Check whether the client is using the DNS settings included with the subscription, or whether they’re being overridden by custom DNS, encrypted system DNS, browser Secure DNS, or local filtering software. Don’t change all of these at once. Save your current settings, then temporarily undo the most recently added custom setting and compare. If the default works, you’ve narrowed the issue down to your custom DNS settings instead of needing to replace the entire subscription.

Browsers may resolve domains on their own, so a successful system lookup doesn’t guarantee that a page will load in the browser. Proxy clients may also resolve domains inside the tunnel, meaning system commands use a different path. A lookup only proves that the tool you used got a response at that moment; it doesn’t prove the site is reachable or establish your privacy status. If only one browser fails, check its Secure DNS, extensions, and proxy settings, then compare with another browser.

Cached results can stick around after you change settings. Close the affected app, then refresh the DNS cache using the method provided by your operating system or client and reconnect. Clearing browser cache alone isn’t a reliable fix, and repeatedly deleting all site data can disrupt sign-ins without fixing a bad network path. If switching networks helps only briefly, note that and check whether the network’s DNS settings or the client’s routing behavior changed.

Use local commands to capture results you can verify

These Windows commands show network settings, look up an example domain, and check a web response. The example domain is for troubleshooting only, not a subscription URL. Network output may include local addresses and adapter details, so remove anything irrelevant before sharing it. If a command fails, include the exact error instead of just saying “the test failed.” macOS and Linux also have built-in lookup tools; note whether the tool follows your proxy settings.

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

The web response command is only supporting evidence. Command-line tools don’t always use the system proxy, and some websites respond differently to this type of request, so it can’t replace testing in a browser. If DNS succeeds but the page times out, check the connection path. If DNS fails but browsing works through the client, the two may be using different DNS routes. Record browser results, system lookups, and client logs side by side to avoid judging the whole device based on a single result.

Tell certificate errors, site restrictions, and network issues apart

If you see a certificate error, check the system clock and whether security software is altering connections. Don’t ignore certificate warnings and enter account details. If the site reports a regional restriction or account eligibility issue, check its terms; changing routes may not fix account requirements. VPNJI route coverage doesn’t guarantee access to any particular platform. For relevant cases, see the streaming access guide and verify the result on the platform itself.

When reporting a website issue, include the domain, the browser’s exact error, whether only that site fails, DNS lookup results, and the client’s routing result. Don’t include private page content or account session details.

First, pinpoint what’s slow

“Slow” could mean a long wait for a page to open, constant video buffering, an unstable download, or a chat tool that takes too long to respond. These tasks can be affected at different stages. Web browsing involves DNS and multiple connections; video relies on sustained transfers; AI tools are also affected by the service’s response generation. Observe the same task and distinguish initial delay, pauses during transfer, and the app’s own processing time. A slow response from one service doesn’t automatically mean the international route lacks bandwidth.

Before troubleshooting, pause large downloads, cloud sync, and system updates on your device, and check whether other devices are using the same network. Weak Wi-Fi, router issues, and network congestion can all affect sustained transfers. If possible, compare using a wired connection on a computer; on mobile, compare the current Wi-Fi with another available network. If regular browsing is noticeably slow even with the client disconnected, check local network conditions first. Otherwise, the same local bottleneck will affect your comparisons across every route.

Keep other conditions the same when comparing routes

When comparing routes, use the same device, network, target service, and client mode; change only the route. The region in a route name can help identify the exit location, but a nearby location doesn’t necessarily mean a shorter or smoother end-to-end path. Client test results can help identify routes that won’t connect, but they can’t replace real-world use. Open the content you actually need and observe load times, buffering, and interruptions. Choose a route that works for your task instead of chasing the lowest test reading in the list.

IEPL dedicated lines, transit, and direct connections describe how traffic is routed. The label alone can’t predict how every app will perform. The path from your network to the route entry point varies, as does the path from the exit to the target platform. Start with a route suited to your target region, then compare route types. Avoid changing region, DNS, and proxy mode all at once. For a full selection guide, see How to choose a route by region, type, and use case. The routes page is the reference list.

For peak-hour slowdowns, compare the time and route

When speeds drop at peak hours, note the time, network, route, and task. Normal performance during the day only shows that it worked under different conditions; it doesn’t tell you whether congestion is on your local network, at the route entry point, or at the target service. Try the same route at different times, then try other routes during the problem period. If all routes and regular browsing are slow, focus on your network. If only one route is affected, keep notes comparing it with routes that work.

Don’t repeatedly refresh pages or resubmit app requests while things are slow. Repeated actions can create extra connections or restart tasks that need a persistent session, making the problem harder to diagnose. You can temporarily lower video quality to see whether sustained transfer is involved, but if that helps, it’s a diagnostic clue—not proof that the route issue is fixed. For tools that need a persistent connection, check for reconnect messages. If the main problem is disconnection, see the frequent disconnects section instead of treating it as a speed issue.

Don’t confuse plan data with transfer speed

Plan data is the total amount of data you can use; it doesn’t determine your moment-to-moment transfer speed. Upgrading to a larger monthly data plan shouldn’t be treated as a general fix for peak-hour slowdowns. Check whether data is available, then investigate the route and task. If you genuinely need more data, see plan pricing. Monthly data resets each month on your activation date; mid-cycle upgrades are prorated for the remaining days. Check your current benefits before troubleshooting instead of guessing how the billing cycle works.

If you can reliably reproduce a slowdown on a particular route with a specific task, include the task type, time, network type, route name, and results from switching routes in your support ticket. You don’t need to include speed figures without reliable measurements, and other people’s tests aren’t evidence about your device. You can use a verified working alternative while keeping details about the failed route for follow-up. Don’t discard all your comparison notes just because the issue temporarily goes away.

Track client disconnects separately from app session drops

First, identify what disconnected. The client changing from connected to disconnected, an app asking to reconnect while the route is still up, and a failed request on one page are different symptoms at different layers. Check whether the system network changed, whether the client selected a different route, and whether the app kept its session. If only one app disconnects while the browser works, don’t assume the whole route dropped. Check app routing and the target service before investigating the tunnel itself.

Knowing what triggers a disconnect is more useful than saying it “happens a lot.” Note whether it happens when the screen locks, the device wakes from sleep, you switch Wi-Fi networks, join a public network, start another proxy app, or just keep using the device. First, keep the device in the foreground with the network unchanged and repeat the task. If that works but switching networks causes a failure, focus on reconnecting after a network change. If it disconnects during otherwise uninterrupted use, compare routes and target apps next. Don’t lump different triggers into the same report.

Network changes affect existing connections

Apps rely on the network path available when a connection is established. If your device switches from Wi-Fi to another network, an existing connection may not continue over the new path. Even if the client reconnects automatically, the app may need to start a new session. First make sure regular browsing works on the new network, then reconnect the client, and finally reopen the affected app. Don’t reverse this order: the app could send requests before the tunnel is ready and cache a brief failure as an ongoing problem.

During computer sleep, the network adapter may pause, and after waking, system routing and the client may resume in a different order. If the connection drops after waking, check whether the client has finished reconnecting before reinstalling it. If restarting the app is enough to fix things, note that “the client reconnects, but the app still needs a restart.” If you have to reconnect the client, record its status and logs. These cases point to different issues—app sessions versus recovery of network routing—and provide different evidence.

Narrow down client settings to avoid interference from automatic switching

While troubleshooting, try a fixed route temporarily to reduce variables from automatic selection or failover. A change in exit location may cause a service to request reauthentication, showing up as a refreshed account page or signed-out session rather than a failed tunnel. If your client offers this feature, save the original settings and make a temporary comparison as described in its instructions. If it doesn’t, there’s no need to look for or add one. Don’t change low-level connection parameters casually, especially by copying an entire configuration from an unrelated guide over your current subscription.

Also check whether the system proxy, tunnel, and other network tools are repeatedly competing for control in the background. If a disconnect consistently starts when a particular program launches, it’s easier to investigate than a random one. If stopping the program helps, that shows a possible link but doesn’t reveal which setting it changed. Security software, corporate management components, and local development proxies may all serve a purpose. Coordinate settings as needed instead of permanently disabling everything for convenience. Keep your original settings so you can restore them and avoid disrupting other work.

Test long-running tasks separately from regular browsing

A page that opens briefly doesn’t prove that a persistent session will work. Test the task that originally disconnected and watch the client’s connection logs. AI coding tools may use different routes for autocomplete, chat, and command-line requests, so one working feature doesn’t prove they all work. For relevant cases, see route selection for Cursor and Copilot. This page focuses on finding where the connection drops; it doesn’t speculate about the tool’s account or server status.

If the same route disconnects across different apps while other routes remain stable, note the differences and submit a support ticket. If only one app fails, save its error and the client’s routing results first. Don’t classify expired authentication, target service maintenance, or an app crash as a network disconnect. A retry in the logs doesn’t necessarily mean the entire client disconnected. Read it alongside status changes and the actual task result. Ask support to interpret the logs if needed; you don’t have to diagnose every line yourself.

Record one complete disconnect: what you were doing beforehand, whether the network changed, the client’s status, and what restored the connection. Don’t send only a screenshot taken after everything is working again.

If a disconnect comes with an unexpected device restart, a system network component error, or a removed managed configuration, address the device issue first. Reconnecting repeatedly may hide the symptom temporarily without fixing the system. For mobile disconnects after screen lock, see the background section. Record the difference between normal foreground use and background failures, then send support a reproducible sequence to reduce back-and-forth about your setup.

First, identify which step failed

Updating a subscription involves fetching its contents, parsing them, and enabling the configuration. If the client says it can’t fetch the subscription, the failure may be at the request stage. If it fetched the contents but reports a format error, the import method or compatibility is a more likely cause. If the import succeeds but the old routes remain, you may not have switched to the new configuration. Save the exact error and selected configuration name. Check whether you updated the existing subscription or created a new configuration, especially if the list has several similar entries.

Get your subscription URL from the account dashboard and import it using a method supported by your client. Copying can add spaces or line breaks, and messaging apps may truncate the URL. Copying it again directly from the dashboard and importing it is more reliable than reconstructing it from an old screenshot. A subscription URL contains access credentials. Keep it as secure as your account password, and don’t post it publicly, put it in a shared document, or include it in an unredacted support screenshot.

If fetching fails, check your account and connection path

First, make sure you can sign in to the dashboard and that your plan and data are in good standing, then try updating again. If the dashboard won’t load in a browser either, check your network and proxy settings first. If the dashboard works but the client can’t fetch the subscription, check whether it uses a different network path. Some clients send subscription update requests outside the current proxy; others offer an option to change the update path. Follow the instructions in the client itself. Don’t assume every client follows the system proxy, and don’t keep using a routing setting that’s already stopped working just to update.

If an old configuration can’t connect and you need that same configuration to update, you may be stuck in a loop. Once regular network access is working, temporarily change the subscription update path as described by the client and compare results, then restore the original setting. This tests the fetch path; it doesn’t mean you should permanently reroute all traffic. If the update returns an authentication error, stop retrying and check that you’re using the current account’s subscription URL. Confirm account status through the dashboard or support instead of repeatedly changing network settings.

If parsing fails, don’t mistake a web page for a configuration

The client may have fetched a sign-in page, an error page, or an unsupported format instead of the expected subscription data. A completed download doesn’t mean the content can be imported. Check that you’re using the right import option for your client. Don’t use a browser page URL as a subscription URL or force an import method intended for another platform. If the update reports an unexpected content type or format, include the error message. Don’t paste the full response into a public tool for analysis—it may contain route credentials.

Check client compatibility separately. Use the client download page for instructions suited to your operating system. You need to be signed in to get the subscription, and a valid plan is required to use the installation package. Before upgrading or reinstalling, make sure you can recover your credentials and back up any personal routing notes that don’t contain sensitive information. Try a new configuration first and keep the old one for comparison. Remove obsolete entries only after the new setup works, so you don’t delete everything only to find you can’t access your account.

After a successful update, verify which configuration is in use

Check that the new configuration is selected, the chosen route isn’t still an entry from the old list, and personal overrides aren’t masking subscription rules. An update may refresh subscription content without removing your custom settings. First test a new configuration without extra overrides, then restore your rules one at a time. If the problem returns after adding one back, investigate that setting instead of assuming the subscription source is at fault again.

Don’t repeatedly update at high frequency to check whether the service is working, or assume a single failure means you need a different account. If attempts keep failing, note the request stage, network, proxy status, and whether a new configuration works, then submit a support ticket. If the dashboard offers an option to reset the subscription URL, understand that the old URL may stop working. Use it only if the URL has been exposed or a reset is genuinely needed. After resetting, update the devices you use; don’t expect the old URL to keep working.

In a support ticket, “fetch failed,” “parse failed,” or “update succeeded but the configuration didn’t take effect” is more useful than the vague phrase “the subscription is broken.” Don’t include subscription URLs, route keys, or account passwords in public troubleshooting materials.

If this is your first import, return to the Quick Start Guide and check the full setup sequence. If you’ve already imported the subscription but only some routes won’t connect, see the connection section. For devices you use occasionally, check that the configuration still works before you need it so a long gap without updates doesn’t get confused with a current connection issue.

Start by comparing the app with a browser

If a browser can open web pages but one app won’t work, the basic connection may be fine. Focus on the network path used by that app. First check that the app account works and that the service isn’t showing a maintenance or permission notice. Then compare the same service in a browser and in the app. A working website is a useful comparison, but the app may use different domains, connection methods, or proxy settings. Note whether sign-in fails, content won’t load, or a persistent session drops instead of describing every feature as one issue.

Desktop apps may follow the system proxy or connect directly; command-line tools may also read their own environment variables. Tunnel routing and the system proxy don’t necessarily cover the same traffic. Check the client’s current mode, then see whether the app has its own proxy settings. If you don’t have a specific reason, avoid setting up multiple proxy paths at once. Requests could end up at an old port or be routed more than once. Include local proxies in your development environment in your comparison instead of assuming they won’t affect the VPN client.

Connection logs are more useful than adding rules at random

If the client provides connection logs, open the feature that’s failing and see whether its domains appear, which rule matched, and which route the traffic used. Apps often contact separate services for sign-in, APIs, static assets, and persistent connections. A working main page alongside a failing API is entirely possible. Find the request that actually failed before changing rules. Don’t add an overly broad rule based only on the app’s name or replace your configuration with every domain you found online.

If rule-based routing fails but the client’s temporary global proxy mode works, routing rules are worth checking—but that doesn’t prove every request to the service needs the proxy. Restore the original mode after comparing results, then adjust only the rules needed for the failed requests. Global mode changes how other traffic is routed and shouldn’t be left enabled as the default after troubleshooting. If global mode also fails, check the route, app account, or protocol compatibility instead of adding more and more domains.

App caches and environment variables may retain an old route

An app may read proxy settings at startup and continue using them after the system proxy changes. Fully quit the app and its background processes, make sure the client is connected, and then relaunch the app. If a command-line tool inherited proxy environment variables from an old terminal session, check the terminal’s startup environment and the tool’s own settings. Save the original values before changing them. Don’t assume there’s one standard local proxy port; check the current client settings rather than guessing.

For browser extensions, IDEs, and in-app browsers, distinguish requests from the host app from those made by the extension itself. If the host’s web pages work but an extension fails, it may use a separate network stack or account authentication. Check the account on the official website, then review the client logs. Clearing the cache can be a useful comparison, but don’t delete your workspace or local data casually. Before quitting, updating, or rolling back development tools, save any uncommitted work.

Test the app’s actual task, not just its sign-in page

AI tools may have separate tasks for sign-in, history, chat, file operations, and streaming responses. After signing in, test the feature that originally failed. If a conversation stops midway, check whether the client also disconnected or the app returned its own error. For coding tools, see the AI tools guide and route selection guide for AI coding tools. For image generation and community apps, see the Midjourney and Discord connection guide.

Some apps determine which features are available based on exit region, account eligibility, or service policies. A network connection can’t replace those requirements. If the app shows a specific regional or permission notice, follow the service’s rules rather than treating it as a reason to keep changing DNS. Sticking to a verified route can reduce changes to the session environment, but it doesn’t guarantee that a target platform will work. Limit your conclusion to the device, account, and task you tested; one successful session doesn’t prove long-term availability.

Useful comparisons include the website versus the app, rule-based routing versus temporary global mode, before and after restarting the app, and the actual path shown for the request in the client. Change only one condition at a time.

When reporting an app issue, include the app name, the feature that failed, the exact error, browser comparison results, and the matched routing rule with sensitive details removed. Don’t send chat content, private files, or account session details. If the client shows no record of the request, mention that too; the request may not have been routed through it, or may have failed earlier.

Test foreground, screen lock, and network changes separately

For mobile background disconnects, first check whether the client works in the foreground. If it doesn’t, follow the connection and web access troubleshooting steps. Focus on background conditions only if the issue starts after switching apps, locking the screen, or system cleanup. Keep the network unchanged while you test the client and target app before and after locking the screen. Then separately test what happens after switching networks. Combining these actions makes it hard to tell power-saving restrictions from network migration issues.

The VPN icon in the system status bar is a clue, not proof that apps can connect. If it stays visible but pages fail, the tunnel may not have recovered, DNS may be failing, or the app session may have expired. If it disappears, check whether the system stopped the VPN configuration or client service. Note whether things recover automatically after unlocking, whether reconnecting works, and whether you have to reopen the target app. Different recovery steps point to different failure locations, so keep those distinctions in your support ticket.

Android: check background and battery settings

Background restrictions on Android vary by device manufacturer and system settings. Find the client’s battery, background activity, or autostart settings, and follow the options shown on your device to allow the background activity it needs. Menu names aren’t the same on every device, so don’t assume one model’s steps apply everywhere. If battery saver or background data restrictions are enabled, save the current settings and compare with a temporary change. Restore or adjust them based on your needs; there’s no need to disable power saving for every app.

Cleaning up apps in the task manager may stop the client process or related services. While troubleshooting, avoid force-stopping the client and check whether the system or another management app is closing it automatically. Some devices let you keep an app in the recent-apps list, but test whether that actually affects the VPN service on your device. Seeing the app card doesn’t prove its background service is running. Check the system VPN status, client recovery, and target app access together.

iOS: check configuration permissions and recovery

On iOS, make sure the VPN configuration has system permission, the expected configuration is enabled, and no other network configuration takes over during testing. The app interface and the system-managed tunnel aren’t exactly the same thing; an app not being in the foreground doesn’t prove the tunnel stopped. If the issue happens after locking the screen, check system status first, then look for a reconnect message in the client. Don’t repeatedly delete every profile. For managed devices, check with your administrator first to avoid disrupting other services.

If the issue began after an OS update, device restore, or configuration change, note the change and when the first failure occurred. If the client offers an on-demand connection option, follow that client’s instructions rather than applying settings from a different app. For initial installation, App Store region, and configuration permissions, see the iPhone client and configuration profile guide. This section focuses on how background behavior affects recovery after a connection is already working.

The target app has its own background rules

Delayed notifications don’t necessarily mean the VPN disconnected. The target app’s background data, notification permissions, account status, and system push service can all affect delivery. If web pages work after unlocking but an app needs to be restarted, check its session and background behavior. Note whether the client disconnected and whether regular browsing works; don’t judge the route based on delayed notifications alone. For apps that need to keep running tasks, check what background activity they actually support.

If the issue reliably happens after the screen locks, include the device model, operating system, client, network type, power-saving settings, and recovery steps in your support ticket. State whether the app works in the foreground, whether the issue happens with the network unchanged, and whether switching networks makes it worse. Share only screenshots of relevant settings and redact personal account details; there’s no need to send a full device backup. If an organization’s management policies restrict background networking, ask the administrator first. Support can’t change system policies by adjusting routes.

Understand unlimited devices and shared data separately

VPNJI supports unlimited simultaneous devices on Windows, macOS, iOS, Android, and Linux. If a client says you’ve exceeded the device limit, don’t assume VPNJI has an unpublished device cap. First check whether the message comes from the VPNJI dashboard, the current client, or the target app, and confirm which account and subscription you’re using. Other apps’ device sign-in limits, messages about an old configuration, or client authorization issues can all look like subscription connection limits. Handle them based on where the message came from.

Unlimited devices doesn’t mean unlimited data, and it doesn’t mean local settings will sync correctly across all your devices. Check your available account data and each device’s subscription status, in case one is using an old URL or a different account. Monthly data resets each month on your activation date; data packages never expire and remain available until used. If all devices fail on the same network, check shared network and account conditions first. If only one device fails, focus on that device instead of deleting configurations from devices that work.

The source of a message determines where to address it

If a target website reports a session or device limit, check that site’s rules. If the client reports a license or configuration error, check its documentation. If your dashboard shows an account entitlement issue, contact support. Don’t share account credentials with someone else to get around a warning, and don’t repeatedly reset your subscription without understanding the impact. If you can’t tell where a screenshot came from, include the screen name and the steps that led to it. Saying exactly where the message appeared is more helpful than guessing what the limit means.

For charges, use only the information shown in your dashboard and the published plan details. Monthly plans: ¥9.9/month for 60GB, ¥18/month for 250GB, and ¥28/month for 500GB. Data packages: ¥158 for 300GB, ¥358 for 1000GB, and ¥658 for 3000GB. Payment methods: Alipay, WeChat Pay, and USDT. A 60-day money-back guarantee is available. See plans and pricing for prices and the refund policy for details. Don’t switch plans as a substitute for troubleshooting or assume there are speed benefits not stated in the published facts.

Start with a reproducible sequence, not a diagnosis

Start your support ticket by describing the symptom and its scope, then explain your setup and how to reproduce it. For example: “Regular websites load, but after the client connects, the target app times out. Switching routes doesn’t help, but changing networks fixes it.” That’s more useful than “everything is broken.” List what you’ve checked and what happened, including steps that made no difference. Avoid stating each observation as a firm diagnosis. Support needs to know what you saw to decide whether to check your account, route, or local settings next.

Include your operating system and client, the displayed route name, network type, exact error, when it happened, and any recent configuration changes. For payment or account benefit issues, provide relevant order details through the dashboard; never post account credentials publicly. VPNJI doesn’t require an email address. You can create an account with a username and password, so keep your credentials safe. Use the support ticket form in the account dashboard to contact support and follow up. Don’t use unofficial messages to find troubleshooting channels.

Support ticket template: symptom and scope; operating system and client; network type; route name; steps to reproduce; exact error; comparisons and results; temporary workaround that currently works. Redact sensitive details before submitting.

Keep context in logs, but remove sensitive details first

Include log lines from around the failure and enough context to show which request stage was involved. An isolated error word may not reveal whether it came from a subscription update, DNS lookup, or route connection. Uploading all logs without filtering may expose unrelated browsing activity. Redact subscription URLs, account passwords, tokens, route keys, and private content. After redaction, keep the error type, route name, and necessary timestamps. Don’t give real configurations to public online tools for analysis.

If you have a working alternative route, use it to get back to work first, then gather evidence. If every route fails on different networks, your dashboard benefits don’t match your order, or the subscription URL keeps returning authentication errors, stop repeating tests and submit a support ticket. When support suggests a new comparison, test each step under the original conditions and report the results. Don’t reinstall, change devices, and edit rules all at once; that can make the original issue impossible to reproduce and obscure what actually helped.

Keep your working configuration after the issue is fixed

After resolving the issue, note the routes and client mode that work, keep any personal settings you still need, remove unnecessary overrides added during troubleshooting, and restore temporary global mode or background exceptions you no longer need. Keep a redacted incident record for comparison if the same symptom returns. For everyday setup, see the guides; for common account questions, visit the help center. This reference helps identify symptoms, but doesn’t replace your system administrator’s requirements or the target app’s terms.