VPNTe Troubleshooting Guide

Set a troubleshooting baseline

Before fixing anything, answer three questions: Can the local network access ordinary websites directly? Does the issue affect only one device? Does it occur only on one route? These answers correspond to the network entry point, the device environment and the remote path. If ordinary websites still fail after disconnecting the client, check the router, Wi-Fi or network provider first; switching VPNTe routes will usually add little information. If other devices on the same network connect successfully, focus on permissions, time, DNS, client settings and security software on the affected device. If only one route fails, there is no need to reinstall the client—switch to another route in the same region and record the result.

First write down the current state: Is the platform Windows, macOS, iOS, Android or Linux? Is the connection a home, office or mobile network? Does the client show a connection failure, a connection with no data, or a connection that drops after a while? Avoid writing only “it does not work.” “Returns to disconnected immediately after clicking Connect,” “shows connected while the browser keeps waiting,” and “only one app fails to load” point to very different checks. The more specific the symptoms, the fewer wrong turns you will take.

Cross-check with minimal changes

For the first check, change only the route. Keep the client, device and access network unchanged, and switch from the current route to another route in the same region. If it works, local permissions and the subscription are probably valid; the issue is more likely with the original route or its path from the current network. For the second check, change only the network. Keep the device, client and route unchanged and use another available network. If it works, inspect the original network’s DNS, routing policy or session handling. Only then compare devices: on the same network, use another configured device and see whether the issue returns.

Do not clear every setting during cross-checking. Clearing settings removes a baseline you can compare and may turn a route problem into a new import problem. Consider reimporting only when subscription content is clearly missing, the client cannot recognize the configuration, or repeated changes have made the settings impossible to trace. Before reimporting, confirm that the user panel opens normally and retrieve the subscription entry again from the panel. Do not keep using an address from chat history, old notes or browser history.

Check time, traffic and account status

An incorrect system clock can affect certificate checks and secure connections. Enable automatic date, time and time-zone synchronization, then fully quit and reopen the client. Traffic status also needs to be distinguished: monthly subscription traffic resets each month on the activation date, and mid-term upgrades convert the price difference into remaining days; traffic bundles remain available until used and never expire. If the panel shows that available traffic is exhausted, switching routes, changing DNS or reinstalling the app will not restore data transfer. Check the right option on the plans page first.

VPNTe requires no email address: a username and password are enough to create an account, so the username is the key account identifier in a support ticket. Never include your password, full subscription address or payment credentials in screenshots or ticket text. When showing a subscription error, capture the client’s error area and mask the link parameters. Support usually needs the time range, platform, access network type, route name, exact error text and steps already taken—not private credentials.

Cannot connect at all: permissions to routes

“Cannot connect at all” means the client never reaches a connected state or quickly returns to disconnected after you click Connect. It is different from “connected but websites will not open.” The former usually occurs before the tunnel is established, so check whether the configuration is readable, whether the system permits a network interface, whether the current route can complete a handshake and whether the local network blocks the connection. Read the exact client error first; do not infer the cause from the status icon alone.

Identify the failed stage first

If clicking Connect produces no system prompt and no status change, check whether the client has the system permissions needed to create a VPN connection. Mobile platforms usually show a system authorization prompt on the first connection; after a previous denial, the client may simply return the button to its original state. Check the relevant permission in system settings instead of clicking Connect repeatedly. On desktop platforms, if the system, security software or network components were recently updated, fully quit the client and restart the device so the network interface can reload.

If the client keeps trying before failing, the configuration was read but the handshake or route setup did not complete. Keep all other conditions unchanged, switch to another route in the same region, then compare with a route in a different region. VPNTe offers 120+ countries / 190+ routes, so there is more than one possible entry point. If routes in several regions fail on the same device and network, compare another network. If the connection works there, the original network path is the main variable.

If the error mentions an empty configuration, unsupported format, missing nodes or unparseable subscription content, skip to “Subscription update failed.” A visible Connect button does not mean the subscription is complete. Some clients retain the names of expired configurations while the parameters needed to connect are missing. Repeatedly clicking routes will only reproduce the same error; retrieve the subscription again from the user panel and import it into a supported client.

Check system network permissions by platform

On Windows, confirm that the client can create a network adapter and make sure no other network tool is taking over the system proxy. If the system proxy page still contains an address written by an old tool, the browser may be sent to a nonexistent local port even when the current client is not connected. Quit other tools of the same kind and return the system proxy to a state the current client can manage. On macOS, focus on the VPN configuration and network-extension permissions in System Settings. If an old and new configuration share a name, remove the clearly obsolete entry and let the current client request authorization again.

On iOS and Android, confirm that the VPN status in the system status bar is not being controlled by another tool. Normally, only the client currently in use should manage the connection. Android work profiles, enterprise policies or security software may restrict VPN permissions; if the Connect button does nothing, check in system settings whether the current app is allowed to establish a connection. On Linux, confirm that the running user can create a tunnel interface, modify routes and read the configuration. Do not run every program with excessive privileges for convenience; grant only the network permissions that are needed.

Separate route failures from access-network restrictions

A typical route failure affects one route while other routes connect normally. An access-network problem often causes several routes to fail on the same network but work after switching networks. Managed office, campus and hotel networks may also require web-based authentication first. After joining Wi-Fi, disconnect the VPN and open an ordinary website to complete the authentication flow before reconnecting. Until authentication is complete, the system may appear online while allowing access only to the sign-in page.

When people search for “VPN software won’t connect,” the actual issue is often incomplete local-network authentication, reset system permissions or a leftover proxy—not a damaged client. Keep the diagnosis neutral: first prove that the device can access the internet directly, then prove that the subscription can be read, and only then assess the route. If one route keeps failing while others connect reliably, record its name, the access network type and the exact error, then stop retrying and use an available route while submitting a ticket.

Reinstallation should be a later step. Before reinstalling, export or record necessary settings, confirm that the username and password work, and make sure you know how to retrieve the subscription from the panel again. After uninstalling, check for leftover system proxy or VPN configurations; otherwise the new installation may inherit the same conflict. If the issue is identical after reinstalling, further reinstalls have little value. Compare another network and inspect the error logs instead.

Connected but websites fail to load and DNS issues

A client showing “connected” proves only that the tunnel has been established. It does not prove that name resolution, the default route and app requests are passing correctly. First distinguish between “no addresses work,” “only domain names fail,” “only international websites fail” and “the browser fails while other apps work.” These point respectively to a broken route, DNS resolution, the route to the destination and app proxy settings. The more accurately you classify the symptom, the less blind configuration changes you need.

Use the difference between domains and addresses to locate DNS issues

When opening a website, the device first resolves its domain name to a network address. If DNS requests do not follow the expected path, the browser may wait indefinitely, report that the server cannot be found or receive a result unsuitable for the current route. Close all browser windows, switch routes and open the browser again to avoid interference from old connections and caches. If the client offers options such as “follow system” or “remote resolution,” restore the client’s recommended default instead of entering several DNS addresses from unknown sources.

On desktop platforms, you can inspect the system’s current resolution results. The command below queries an example domain only and contains no subscription information. If it returns an address, the basic resolution chain is responding; repeated timeouts point to the client DNS mode, system network settings or local security software.

nslookup example.com

On Linux or macOS, you can also use the resolution tools already available on the system. Tools vary by installation, so there is no need to install complex software just to run one command. The useful comparisons are whether resolution works while disconnected and fails after connecting, whether switching routes changes the result, and whether the browser’s independent secure DNS differs from the system result. When browser-level and client-level resolution operate simultaneously, you may see “works in the command line but fails in the browser.”

Clear old proxies and stale routes

If every domain resolves but web requests receive no response, check whether the system proxy points to the current client. After an improperly closed tool exits, the system may retain its old port. The browser then sends requests to that port while the client appears normal, leaving the page spinning indefinitely. Windows and macOS both let you inspect proxy entries in system network settings. If the current client uses a virtual network interface rather than a system proxy, avoid keeping a manual proxy enabled at the same time. Linux users should also check whether terminal environment variables conflict with the desktop proxy settings.

env | grep -i proxy

The command above searches the current terminal for proxy-related environment variables. If it finds an old address, correct it in the startup script or session setting that actually writes the variable instead of deleting it only from the current window. For browser extensions, make sure another proxy extension is not overriding system settings. The simplest check is to use a fresh browser profile without extra proxy extensions and visit the same page.

Handle failures affecting only some sites or resources

If most websites work and only a few fail, the entire connection is usually not down. First switch to another route in the same region to rule out path differences between the exit address and the destination service. Then check whether the site depends on multiple domains: if the page opens but images, login or video fail, the routing rules may cover only the main domain while supporting requests use another path. Temporarily switch to global mode for verification. If that restores access, review rule matches before returning to rule-based mode instead of sending all traffic globally for the long term.

If only the browser fails while messaging or other apps work, check browser extensions, independent DNS, cache and proxy settings. If every app fails to transfer data while the client still says connected, disconnect and reconnect, then watch whether the data counters change. No upload or download activity usually means the route was not taken over correctly or the interface has failed. If restarting the client makes no difference, restart the system network or device.

Do not reset all system network settings as the first step. This may remove saved networks, enterprise configurations or other required settings. Complete route switching, browser comparison, system proxy checks and DNS-mode restoration first. Consider a system-level reset only after confirming that the network stack is abnormal and recording necessary settings. If the device is managed by an organization, consult the administrator before removing policies that must remain.

Slow speeds and peak-hour lag

Speed issues must first be localized. A cross-border request passes through at least the device-to-router link, local access network, route entry point, international path, and the exit path to the destination service. A momentary speed reading on one download page cannot prove that the route itself is slow. The destination may throttle traffic, the browser may reuse an old connection, or the local Wi-Fi may be congested. Reliable testing uses the same device, network and content while changing only the route.

Create comparable test conditions

Before testing, pause system updates, cloud sync, large transfers and background media playback. Continuous uploads from other devices on a home network can make web responses and video buffering deteriorate at the same time. Then choose a destination service you actually use and compare it while disconnected, on the current route and on another route. Do not chase a single peak reading; focus on stable page loads, repeated pauses in requests and whether video playback keeps progressing.

Do not change the test site, browser, route and network at the same time. Too many variables make the result meaningless. If one route behaves very differently across destinations, the exit-to-destination path may differ. If everything is slow, check local Wi-Fi, the access network and the route. If another device on the same network works normally, first inspect background tasks, power-saving behavior, security scans and client mode on the affected device.

Choose routes by geographic path first

Start with a route near the destination service and with a sensible path from your location, rather than choosing only by popularity. Greater distance usually means more networks in between and more potential congestion points. For services in Japan, compare Japan routes with nearby regions first; for US content, compare different US entry points or nearby exits. VPNTe’s full coverage is listed on the servers page, which identifies route regions and types to help you build a reasoned shortlist.

The difference between IEPL dedicated routes, relays and direct connections should not be reduced to a fixed speed ranking. Dedicated routes focus on organizing the international path, relays add an entry point that may improve reachability on some networks, and direct connections reduce intermediate steps. Actual performance still depends on your location, access network and destination service. Treat route type as a selection factor, not an absolute conclusion. If direct connections fluctuate on the current network, compare a relay or dedicated route; if a dedicated route performs poorly for one destination, compare another route of the same type or another entry point.

Separate local congestion from the international path at peak hours

If the connection is stable during the day but noticeably laggy in the evening, first check whether ordinary internet access also slows down, buffers video or becomes unstable over Wi-Fi after disconnecting the VPN. If it does, congestion at the network entry point is more likely. Compare with a wired connection or move closer to the router to rule out signal issues. If ordinary access remains stable while routes differ at the same time, use the route that performs better in the evening and record the comparison.

Peak-hour troubleshooting is not a good time to cycle rapidly through many routes. After each switch, let the old connection close before reopening the target app. Many apps keep their existing session, so a download or video may continue using the old path even after the route changes. Fully quit and reopen the target app to test the new route properly. In a browser, use a new cache-free session for comparison, but do not repeatedly clear every login state.

People searching for “slow internet access through a VPN” may blame every slowdown on the route. In practice, local Wi-Fi interference, background uploads, destination throttling and a poor region choice are all common. First compare the same destination on the same device and network across routes, then decide whether to report a route issue. A single speed screenshot is rarely enough; include the test destination, access network, route name, time period and whether the issue reproduces consistently.

Separate plan traffic from speed symptoms

Monthly subscriptions include ¥9.9/month with 60GB, ¥18/month with 250GB and ¥28/month with 500GB. Traffic resets monthly on the activation date, and a mid-term upgrade converts the price difference into remaining days. Traffic bundles include ¥158/300GB, ¥358/1000GB and ¥658/3000GB; they remain available until used and never expire. Low available traffic is an account-status issue, not evidence that one route has slowed down. Check the traffic status in the panel before testing routes.

If every route across different regions and types remains slow on multiple networks while ordinary internet access is stable, organize the comparisons and submit a ticket. Support needs reproducible conditions, not a subjective request for “the fastest” connection. Specify the destination service, route, network environment and what changed after switching routes; this can substantially shorten the investigation.

Frequent disconnects and mobile background drops

First distinguish between the client ending the connection, the system reclaiming background activity, a change in the access network and an interrupted route session. They all look like the status icon disappearing, but their causes differ. If the connection drops whenever the screen locks, check background operation and power saving first. If it drops when switching from Wi-Fi to a mobile network, focus on session reconstruction after the network change. If it repeatedly drops during active foreground use on a fixed route, compare routes and inspect the error log.

Check mobile background conditions first

Android power-saving policies may restrict the client from maintaining the network in the background. In system settings, find the current client and allow the necessary background activity, while preventing cleanup tools from ending it automatically. Settings names vary by device, but the principle is the same: the client must keep running after the screen locks, and the system must not reclaim its network service as idle work. After changing the setting, reconnect and lock the screen to observe the result instead of checking only that the setting changed.

iOS manages background tasks centrally, so it generally cannot or does not need to keep an arbitrary process running indefinitely like a desktop system. If the connection drops every time you switch from Wi-Fi to a mobile network, return to the client and check whether it reconnects automatically. Another on-demand connection profile may be competing with the current client. Keep the configuration you actually use, remove clearly obsolete entries and confirm that the correct manager appears on the system VPN page.

A mobile “background drop” is sometimes just a stale app display. Judge it by actual access and the system VPN status rather than the client home screen alone. Conversely, a visible status icon does not guarantee that data is flowing. If websites fail to load after the connection returns from a locked screen, follow the DNS and routing checks in “Connected but websites fail to load.” Record both status and data behavior.

Network changes terminate old sessions

When a device leaves Wi-Fi coverage or switches to another access network, its network address and routes change, so the old tunnel may need to be rebuilt. The stable approach is to wait for the network switch to finish and see whether the client recovers; if it does not, disconnect and reconnect manually. Do not test repeatedly at the edge between two network signals, as constant switching makes it impossible to judge route stability.

Desktop devices can experience similar changes. When a laptop wakes from sleep, a dock network disconnects, or Wi-Fi and wired-network priorities change, the system may retain the old interface. The client can appear online while routing still points to an unavailable interface. Disconnect first, confirm that basic network access has returned and reconnect. If the issue occurs after every sleep cycle, check whether the client supports reconnecting after system resume and make sure another network tool is not being restored at the same time.

Rule out local power-saving and security interference

Some security software rescans or restricts a new interface when the network changes, causing the connection to drop shortly after it is established. Do not leave protection disabled; inspect event logs or allowlists to confirm that the client and network interface are not being blocked repeatedly. If temporarily disabling one network check restores the connection, apply the finding to a specific rule and restore the other protections. Vaguely disabling every security feature is unsafe and does not produce a durable fix.

Router sessions, Wi-Fi signal quality and device sleep can also cause periodic interruptions. Keep the device active in the foreground and compare it on another stable network. If the same route drops only on the original network, focus on that network. If it drops on several networks while other routes work, record the route name. If every route drops on only one device, return to device permissions and background policies. This three-way comparison is more effective than repeated reinstalls.

Some users summarize frequent disconnects as “the VPN is unstable,” but a support ticket needs more precise language. State whether the drop occurs during screen lock, sleep, a network switch or continuous foreground use; whether it recovers automatically; whether changing the route or network helps; and whether the system VPN status matches the client status. This information shows whether to start on the device, network or route side.

Record the state before and after a disconnect

When a disconnect occurs, capture the exact error first, then record the route and access network. If the client offers a normal log export, submit the portion around the incident, but check whether it contains the full subscription address, private parameters beyond the username or local file paths. Mask sensitive content when needed. Never copy an entire subscription configuration into a public channel.

If a mobile device still disconnects whenever the screen locks after background permissions are correctly configured, while the same account works on other devices, submit a device-focused ticket. If several devices, networks and routes all disconnect during foreground use, submit more complete connection logs. VPNTe supports unlimited devices, so the device count is not a default connection limit; the more important check is whether each device uses the currently valid subscription configuration.

Subscription update failed and invalid configurations

Subscription updates usually fail because the client cannot retrieve the content, the response cannot be parsed, an old configuration remains cached or the account currently has no available service. This is related to route connection failures, but the entry point differs: check the subscription request and format first, while route failures start with the network tunnel. If the client shows an empty node list, an update button that keeps reporting errors or no routes after import, fix the subscription before attempting to connect.

Confirm the subscription source and account status

Always retrieve the subscription from the user panel. Do not use search results, third-party documentation, outdated screenshots or addresses forwarded by someone else. Sign in to the panel, open the download or subscription section and obtain the content for the current platform. Marketing pages do not provide static installer direct links or real subscription addresses; this is intentional. The client and subscription are delivered through the user panel. If you have not completed the basic process, return to the quick-start guide and check the steps.

Before importing, confirm that the username can sign in and check the status of the current plan or traffic bundle. Monthly subscription traffic resets each month on the activation date, and a mid-term upgrade converts the price difference into remaining days; a traffic bundle remains available until used and never expires. If the service is unavailable, the client may retain old node names but still be unable to retrieve new subscription content. Handle account issues in the panel first; local client actions cannot change account status.

Classify the update error

“Request timed out” means the client did not retrieve the content within the expected time, so check the basic network and system proxy first. “Unable to parse” means the retrieved content is not in the format expected by the client, possibly because the wrong import entry or client type was selected. “Authentication failed” usually concerns the current subscription entry; retrieve it again from the panel instead of editing link parameters manually. For a “certificate error,” confirm the system clock and rule out a network sign-in page or security software replacing the connection.

A browser opening an address does not mean the client can import it. The browser may follow pages automatically, retain a login session or display text, while the client needs a direct response in a specific format. Use the entry provided for the current client in the panel. Do not confuse a webpage address, panel address and subscription address, and do not assemble parameters yourself.

Safely rebuild the local configuration

If the client contains several configurations with the same name, first identify which one is active. Pause the old configuration, import the new one from the panel and give the local configuration a clear name. Delete obsolete entries only after the new configuration updates and connects successfully. Deleting everything first removes your comparison point and could interrupt access if you cannot sign in again.

Some clients cache subscription results. If the route list does not change at all after an update, fully quit and reopen the client to confirm that the update affected the active configuration. If it still does not change, remove that subscription and import it again, but do not rapidly add the same content repeatedly or create duplicate configurations. On mobile, also confirm that the client is allowed network access; on desktop, check that the system proxy is not sending the subscription request to a stale port.

The link below illustrates the structure of a subscription address only. It is an obvious dummy value, cannot connect to any service and is not VPNTe’s real entry point:

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

A real subscription address is private credential data. Do not post the full link in forums, public screenshots, speed-test pages or group chats. In a support ticket, describe the update error and client type, and mask the parameters in screenshots. If support needs further verification, the ticket process will provide safe instructions.

Handle client format mismatches

Different clients accept different configuration structures. Importing content prepared for another client type may produce unknown fields, an empty configuration or only a partial route list. Return to the panel’s download entry and choose the method matching the current platform and client. Do not process a real subscription through an online converter; this would expose the private address to an unrelated service.

If an update fails on one network but succeeds on another, the original network or proxy path is affecting the subscription request. After a successful update, still test an actual connection because retrieving the configuration and establishing a route are separate stages. If updates fail on several networks while panel login works, record the client name, platform, exact error and approximate update time, then submit a ticket.

If the subscription updates but one route consistently fails to connect, the issue has moved from the subscription stage to the route stage; return to “Cannot connect at all.” If the node list is normal and the connection succeeds but websites do not open, continue to the DNS and routing section. Moving through the stages prevents every symptom from being blamed on the subscription link.

A specific app bypasses the proxy: routing diagnosis

When the browser and most apps work but one app cannot load, shows an unexpected region or consistently uses the local network, the route itself is usually fine. Focus on whether the app follows the system proxy, whether the client is using rule-based or global mode, whether the domains required by the service are covered by the rules and whether DNS results match the traffic path. Do not reinstall the entire network environment because of one app.

Confirm that the app supports the system proxy

Some desktop apps follow the system proxy, some create their own network connections and others read proxy settings only at launch. If the app does not change after the client connects, fully quit and reopen it so old connections and DNS caches are released. Closing the window may leave the app running in the background; confirm that it has exited from the system tray or process list. If it works after reopening, the app had been reusing a session from before the connection.

If the browser works but the app always connects directly, temporarily switch the VPN client to a mode with broader traffic coverage. If the app works in global mode, the route is usable; rule-based mode either does not cover the app’s requests or the app does not follow the system proxy. After testing, adjust the rules for your actual needs rather than leaving the mode changed without understanding its scope.

Read rule matches instead of guessing domains

Many apps contact more than one main domain, including login, image, API, update and media-delivery addresses. A rule for only the main domain may let the home page open while login fails, text appears without images or a list loads without playback. If the client provides connection records or a rule-match view, inspect the request path while reproducing the issue. Check whether the failed request is marked direct, proxied or rejected, then adjust the rule accordingly.

Do not copy huge rule sets in bulk from unknown sources. The more rules there are, the harder conflicts are to locate, and old rules may override new ones. A safer approach is to use global mode briefly to prove that the app works, then return to rule-based mode and add entries gradually from actual requests. Rule order matters too: a broad direct rule placed first may prevent a later specific proxy rule from ever matching.

Check conflicts between in-app proxy and system settings

Some apps provide their own proxy fields. If an old address remains there, the app may bypass the current system settings and connect to a dead port. Check the app’s network settings and decide whether the system should manage the proxy centrally or whether the current local proxy should be entered explicitly. Do not mix both approaches. If you do not know the client’s local port or mode, let the system manage it rather than entering a common port at random.

Command-line tools may read environment variables instead of the graphical system proxy. Use the environment-variable query from earlier to inspect the current terminal. If only terminal commands fail while the browser works, the terminal likely did not inherit the system settings or still has old variables. Open a new terminal session after changing them; running processes do not automatically receive a new environment.

Region, account and network path are separate dimensions

The region shown by a streaming service or AI tool is not necessarily determined only by the current network exit. Account details, previous sessions, app-store region, cache and the service’s own policies may also affect the result. After switching routes, fully quit and reopen the app. If necessary, clear only nonessential app cache; do not delete data that cannot be recovered. If the result is normal while logged out in a browser but changes after signing in, separate account factors from route factors.

If an AI tool opens but generation repeatedly stops, first determine whether the cause is the app session, route stability or a browser extension. See the site’s AI tools page for route selection and session-handling guidance. For streaming issues, read the regional libraries and viewing guide, which separates region detection, bandwidth and playback sessions rather than attributing every problem to the route.

Some users search for “VPN rules not working,” when the real issue is rule matching and app proxy support. A neutral technical diagnosis starts with the request path: was the app restarted, does it follow the system proxy, which policy matched, does DNS use the same path and does global mode restore access? After these comparisons, the issue can usually be narrowed to a specific rule or app.

When is it a route problem?

If the same app behaves noticeably differently in global mode after switching among several routes, and the browser reproduces the same difference for the same destination, you can report it as a route-path issue. If only one app fails while the browser and other devices work, investigate app settings and rules first. A ticket should include the app name, route name, client mode, rule-match result and error screenshot; this is much more useful than “this app does not work.”

For issues that began after an app update, also consider changes to the app’s networking implementation. Confirm that other destinations still work, then check whether the current client can record the new requests. Do not invent domains or copy outdated rules. If you cannot identify the requests, submit a ticket describing what changed before and after the update so support can assess it from reproducible conditions.

Device usage, recovery limits and ticket materials

VPNTe supports Windows / macOS / iOS / Android / Linux with unlimited device use. When a new device cannot connect, do not assume a fixed device limit first. More common causes include importing an old subscription, missing system authorization, an incorrect clock, incomplete network authentication or multiple clients competing for the system VPN configuration. Troubleshoot across the same four dimensions: device, network, subscription and route.

Compare new and existing devices under the same conditions

Connect the new and existing devices to the same network that has already been confirmed to work, and choose a route in the same region. If the existing device works but the new one fails, the account and route are probably usable, so focus on the new device. If both fail, switch to another route or network. Do not immediately modify the working device after the new device fails; keeping a known-good reference greatly reduces diagnostic effort.

On a new device, retrieve the client and subscription again from the user panel. Do not copy a configuration from an old device that contains caches, absolute paths or platform-specific fields. Platforms differ in their network permissions and configuration formats. A Windows configuration should not be transferred directly to mobile, and mobile-shared content may not suit Linux. The panel provides a unified entry point; sign in and obtain content for the current platform.

When sharing across a household or several personal devices, avoid distributing the subscription in public groups. Unlimited device use describes the permitted device scope; it does not change the fact that the subscription address is private credential data. If you suspect that unrelated people obtained it, explain the situation in a ticket and update it according to support’s instructions instead of importing the old address on more devices. For plan considerations, see unlimited devices and family sharing.

Confirm that you have reached the troubleshooting limit

Some issues only get worse with further self-directed changes. If the same authentication error appears across multiple platforms, networks and routes, stop clearing configurations and contact support. If one route keeps failing while others work, keep the working route and submit its details. If account status and payment records do not match, do not place another order; verify them through a ticket. VPNTe supports Alipay / WeChat Pay / USDT. You may state the payment method in a ticket, but never submit a payment password or complete credentials.

For refunds, use the standard wording “7-day money-back guarantee.” Handle the specific request through the user panel or service process rather than inferring eligibility during connection troubleshooting. Your troubleshooting record still helps: it shows the scope of the issue and what has been tried, avoiding repeated tests. Refer to the plans page for plan details and traffic rules.

What to include in a support ticket

Write the symptom and platform directly in the ticket title, such as “Websites fail to open after connecting on macOS” or “Connection drops after locking the screen on Android.” Start the message with your username, followed by the platform, access network type, route name, exact error, time range, whether the issue reproduces consistently and the comparisons already completed. If switching networks restored access, state that clearly. If only one app fails, include its name, client mode and rule-match details.

Screenshots need enough context. A single red icon is rarely useful; include the client status area and complete error text, but mask the full subscription address, password, payment credentials and other private parameters. Logs should cover the period around the failure; there is no need to upload unrelated history. If logs contain sensitive fields, mask them first or ask support which sections are needed.

Do not use “today” or “just now” as the only time information. A ticket may be handled later, making relative times ambiguous. Give the date and approximate time period, and specify the time zone. If the issue occurs only at certain times, recording several instances shows the pattern better than a single screenshot. If it has recovered, state which step restored it so support can determine whether the route or account still needs attention.

Username:
Platform:
Access network type:
Route name:
Symptoms:
Exact error:
Date and time period:
Can the issue be reproduced consistently:
Result after switching routes:
Result after switching networks:
Steps already completed:

How to confirm the issue is truly resolved

After the connection returns, do not stop after opening one website. Confirm that the client remains stable, visit the destinations you use every day and check DNS, app routing and recovery after screen lock. If the issue occurred at peak hours, observe again under the same time conditions. If it affected mobile background operation, test screen locking and network switching. If subscription updates failed, confirm that the route list can update again instead of relying on an old cached connection.

Keep the changes that actually fixed the issue and undo temporary settings that are no longer needed. For example, global mode is only for proving a rules issue; restore an appropriate routing mode after confirming the rules. Re-enable temporarily disabled security checks and replace them with specific allow rules. Delete duplicate test subscriptions and keep the clearly named current configuration. This prevents temporary settings from causing the next problem.

If you still cannot identify the affected area after completing the full process, submit a ticket from the user panel. Support cannot directly see the network state on your device, so the quality of the materials determines how efficiently the issue can be located. Clear symptoms, single-variable comparisons, exact error text and masked screenshots are far more useful than a vague description.