Cannot Connect at All: Define the Failure Boundary
A connection button that does nothing, a session stuck on connecting, and a connection that drops immediately all mean the session has not become stable—but each symptom points to a different troubleshooting path.
Record the symptoms first; do not switch every setting at once
When nothing connects, the most common mistake is changing the route, protocol mode, system permissions and client settings simultaneously. With too many changes, even an accidental recovery will not reveal what helped. Keep the current screen open and note the status text shown by the client: is it waiting indefinitely, timing out, being denied permission, or ending immediately after connecting? Then check whether ordinary websites open with the connection disabled. If the local network is already offline, changing routes will not help.
Next, determine whether “all routes fail” or “only the current route fails.” From the server page, choose another nearby region instead of cycling through the entire list. If changing routes restores access, the client, subscription and system permissions are probably usable; narrow the issue to the original route or the path from the current network to it. If every route behaves the same way, first check whether the subscription has expired, whether the client has loaded the nodes, whether the system allows network connections, and whether the local network restricts the relevant traffic.
With the connection off, open an ordinary website to confirm basic connectivity on the current network.
Change only the route; do not modify the mode, rules or system settings at the same time.
Confirm that system authorization is still valid and that the client shows routes from the current subscription.
Check whether the subscription actually loaded
Being able to open the client does not mean the subscription has loaded. An empty route list, only old routes remaining, or route names that differ from the user panel all indicate that the subscription should be addressed before the connection itself. Open the client's subscription or configuration page, confirm that the selected configuration comes from the VPNTea user panel, and run one update. Do not delete every configuration first, because the original error often disappears along with the deletion. If the update fails, preserve the message and continue with the “Subscription Update Failed” section of this guide.
If a route exists but ends immediately after you click it, check whether the operating system displayed a network configuration permission prompt. Authorization may need to be confirmed again after the first import or a system update. Windows, macOS, iOS, Android and Linux use different entry names, but the standard is the same: the client must be able to create a system network interface or write the system proxy settings. When permission is denied, even a perfectly healthy route cannot take over traffic. On managed corporate devices, network configuration may also be controlled by policy; ask the device administrator to confirm instead of repeatedly reinstalling the client.
Use a minimal environment to rule out local conflicts
Keep only one client responsible for taking over system networking at a time. Other traffic filters, older acceleration clients, manual proxies, browser proxy extensions and network inspection features in security software may compete for the system proxy or routes. Exit them, then reopen the VPNTea client and test again instead of merely minimizing the window. Some programs remain in the background after their windows close, so confirm that their processes have ended in the task area or system activity list.
Then compare the current network with another trusted network. If the same device, subscription and route fail only on one network, the boundary is the access network. If changing networks does not help but another device connects normally, the issue is with the original device's permissions, network stack or client state. If different devices and networks all fail, consider the account, subscription or route side. This matrix provides more information than simply restarting and trying again.
Preserve the scene: If the client shows a specific error, take a screenshot and copy the selectable error text before resetting anything. The time, route name, access network and system platform are the foundation for a later ticket.
When to stop local troubleshooting
Once ordinary networking works, the subscription updates, system permissions are valid, and the same failure appears across different networks and routes, do not keep uninstalling and reinstalling. Submit a ticket with the client status, exact error text, system platform, selected route, the last known working scenario before the issue began, and whether all routes are affected. If only one route fails, name both the working and failed routes so support can distinguish a route issue from an account issue faster.
Connected but Websites Won't Open: Separate Routing from DNS
A client showing “connected” only proves that the session was established. You still need to verify domain resolution, whether traffic follows the correct rule, and whether the browser is using stale cache.
First determine whether one website or every website is affected
When connected pages will not open, start by visiting several commonly used websites with different characteristics. If only one site fails, the cause may be the target service's status, regional policy, browser cache or a rule match for that domain. If every domain fails, check DNS, the system proxy and the default route first. Do not attribute a single site's error to the entire route, and do not compare several pages on the same site, since they usually share the same domain and network entry point.
Then compare the browser with other internet-connected apps. If the browser fails while other apps work, check for secure DNS, proxy extensions or custom network settings enabled in the browser. If every app fails, the issue is more likely at the system network configuration level. Browser extensions can bypass the client's rules, especially when an old proxy address is saved in an extension. For testing, temporarily use a browser window without extra extensions, but do not erase all browsing data; preserve the visible error page and domain first.
Use a domain-resolution test to locate DNS issues
DNS converts domain names into network addresses that can be reached. If the client is connected but domain resolution is still handled by an unavailable resolver or returns an abnormal result, pages may wait indefinitely, report that the server cannot be found, or work intermittently. You can run the following neutral test in a system terminal; the example domain contains no real subscription information:
nslookup example.com
curl -I https://example.comIf the domain query returns no result while the client log shows an active connection, focus on the client's DNS takeover option, leftover manual DNS settings, browser-specific DNS and other network filters. If the query returns a result but the page request fails, routing, rules or the target service are more likely. You do not need to interpret the command output line by line—keep it intact. For a ticket, whether resolution succeeded is more useful than pasting large amounts of unrelated logs.
Check whether rules mode is sending traffic the wrong way
Rules mode decides whether to connect directly or use a route based on the domain, network address or app. Outdated rules, an incorrectly classified domain or a target service that has moved to a new domain can all result in “connected, but the page won't open.” Temporarily switch to global mode for comparison: if global mode works while rules mode fails, the route itself is usually fine; update the subscription and rules, and check for custom overrides. If both modes fail, continue checking DNS, the route and the local network.
Global mode is for diagnosis, not necessarily a long-term solution. For everyday use, choose the mode that fits the actual scenario so local traffic that does not need acceleration does not take a different path. If only one app fails, go to “An App Cannot Use the Proxy” and check whether it uses an independent network stack, is listed in a per-app exclusion, or has a dedicated client rule.
Keep a rollback path when clearing cache and system leftovers
After changing DNS or rules, old resolution results may remain cached by the system, browser or app. The safest order is to fully exit the affected app, disconnect, reconnect, then reopen the app and test again. If necessary, restart the device to return the system network state to a consistent starting point. Do not begin with an unknown network-reset script: it may also erase Wi-Fi networks, corporate settings and other required configuration, adding new variables.
If you manually configured a system proxy, record its original value before switching to automatic management. When troubleshooting is complete, confirm that no invalid proxy address remains. On Linux, terminal proxy environment variables may be independent of the desktop system proxy: a graphical app may work while the command line fails, or vice versa, because the two settings differ. Check whether the current terminal session inherited old variables instead of concluding that the route is unavailable.
Note: Do not enable the client's DNS, browser-specific DNS, manual system DNS and other filters at the same time and then compare results. During troubleshooting, keep the resolution chain as simple as possible; otherwise each request may take a different exit path.
What to include in a DNS ticket
If the same resolution failure occurs across different routes but disappears after changing networks, report the access network type and the resolution command output. If only one route is affected, include its name, the failed domain and the global-mode comparison. If the browser behaves differently from other apps, name the affected app and state whether app-specific DNS is enabled. Do not submit passwords, the full subscription or screenshots containing authentication parameters. Support needs reproducible conditions, not account credentials.
Slow Speeds and Peak-Hour Lag: Examine Each Link
Slow downloads, slow first-page loads, video buffering and interaction latency are different performance problems. Record them separately by app type and time of day.
First define where “slow” occurs
A slow webpage may involve delayed DNS resolution, a long wait for the first content to appear, or slow image loading after the page opens. For video, it may mean delayed playback startup, reduced quality or buffering during playback. An AI tool may open normally but stop responding. Each symptom depends on different parts of the network, so one speed-test result cannot replace a real-world scenario. First note the affected app, exact action and time, then compare whether other apps work on the same route.
If only one service is slow, first consider the target service entry point, region and rule match. If everything is slow, check access-network quality, wireless signal, background downloads and route selection. Other devices on a home network syncing files, updating apps or streaming high-bitrate content can also compete for bandwidth. Because VPNTea supports unlimited devices, the number of connected devices is not a plan limit, but multiple devices transmitting at once still share the actual capacity of the current access network.
Build a repeatable route comparison
When comparing routes, keep the device, access network, target service and test action unchanged; replace only the route. Prefer a geographically closer node or one matching the target service's region instead of guessing speed from its name. Dedicated, relay and direct routes have different path structures: dedicated routes focus on stable organization across the cross-border segment, relays enter an optimized gateway before reaching the target region, and direct routes depend more on the local carrier and public-network path. None is universally best outside a specific scenario.
The server page shows covered regions and route types, while the complete route-selection guide explains how to choose for video, gaming and AI tools. For performance troubleshooting, start by comparing different route types in the same region. If routes in the same region perform similarly, the issue is more likely local access or the target service. If only one route type is abnormal, point out that difference in the ticket.
For Peak-Hour Lag, Compare Time and Network
If performance is normal during the day but clearly slower in the evening, record both periods on the same device and app, then compare another access network. Peak hours may affect the local broadband connection, the cross-border entry point and the target service at the same time, so one test cannot identify the bottleneck. If changing networks restores performance, the issue is closer to the local carrier. If different networks slow down only on a fixed route, switch to another route in the same region and give support the route name and time period.
Do not write only “it is very laggy at night.” A more useful description is: the first page load is slow but later navigation is normal, video starts normally but buffers midway, downloads remain slow, or interactive requests occasionally time out. This helps support distinguish latency variation, insufficient sustained throughput and connection retransmissions. For live sports and other real-time use cases, see the sports streaming route comparison for selection criteria, but base troubleshooting on comparisons from the current network.
Rule Out Device Performance and Wireless Interference
Power-saving mode, excessive heat, background sync and real-time security scans can all reduce a device's ability to process encrypted connections. First pause large-file sync and system updates, keep the device steadily powered, and repeat the same action. On Wi-Fi, a full signal icon does not prove the link is free from interference; when possible, move closer to the access point or compare with a stable wired connection. If only one older device is slow while others work normally, check that device's resource usage and client state first.
Split-tunneling rules can also affect perceived performance. A target service's page resources may come from multiple domains, with some routed through the service and others connected directly. Inconsistent paths can make the main page appear while images or video remain stuck. Temporarily testing global mode can confirm this. If global mode clearly improves things, update the subscription rules and remove conflicting custom rules instead of relying on constant route switching.
Recording method: Keep the details for “time period, access network, route, app, exact action and reproducibility.” Do not replace the complete symptom with a single speed number that cannot be reproduced.
When to stop performance troubleshooting
If different devices are slow on the same network but recover after switching networks, contact the access-network provider first. If only specific VPNTea routes remain abnormal across different networks, submit a route ticket. If all routes are abnormal only for one target service, provide the service name, selected region and rules mode. Exhausted traffic can also affect continued use, so check the current plan status in the user panel. Monthly subscription traffic resets each month on the activation date; traffic packages remain available until used and never expire. Confirm the current traffic source before troubleshooting.
Frequent Disconnects and Mobile Background Drops
Disconnects may result from network changes, power-saving policies, the client being terminated, route-session changes or competing network tools. The key is to record what triggers the drop.
Distinguish an active disconnect from a failed session
For frequent disconnects, first check the client status. If it clearly returns to disconnected, the system or client ended the session. If it still shows connected but apps can no longer access the internet, the route, DNS or connection session has more likely failed. These cases need different responses. For the first, check power saving, background permissions and network changes; for the second, disconnect and reconnect, then compare whether it happens only on a particular route.
It is important to record what happened just before the disconnect: did the device switch from Wi-Fi to a mobile network, lock its screen, enter power-saving mode, open another network tool, or move between regions? A network switch changes the local address and route, so the existing session may not continue. After the screen locks, the system may pause background tasks. Security software or system cleanup may terminate the client process entirely. Writing only “random disconnects” loses these trigger clues.
On mobile, check background operation first
On iOS and Android, the system manages apps according to battery level, memory and background policies. Confirm that the VPNTea client has the system permissions needed to maintain the network configuration, and avoid placing it in an app category that is actively put to sleep. Android manufacturers use different names for power-saving controls, usually found under app info, battery or background activity settings. On iOS, confirm that the system network configuration still exists and that no other network configuration is competing with it. For the initial setup, see the iOS Subscription Import Guide.
Do not disable every power-saving feature on the device just to keep the connection alive. A safer approach is to adjust only the current client and observe what happens when the screen locks, apps are switched or the network changes. If the foreground remains stable but the connection drops after locking, the boundary is clearly background management. If it also drops in the foreground, continue comparing routes and access networks. Android users can also consult Android Background Operation and Per-App Proxy Guide and check the app's background status step by step.
Check background activity, power management and whether the system paused the client.
Reconnect and check whether every network switch reproduces the issue.
Check DNS, the default route and whether the route session has expired.
Check background cleanup, security software and available device resources.
On desktop, check sleep, network changes and process conflicts
After sleep or wake on Windows, macOS and Linux, the system may retain an apparent connection state even though the underlying network interface has changed. If the internet is unavailable after waking, disconnect and reconnect before deleting the subscription. If it happens after every sleep cycle, record the platform, route selected before sleep and client status after waking. If the issue first appeared after a client or system update, include “normal before the update, abnormal after it” as the change point in the ticket.
Also check for programs that modify routes, proxies or DNS. Container networking, virtual network interfaces, remote-work clients and security filters in development environments may rewrite routes when they start. If VPNTea works before these programs launch but disconnects afterward, compare them one at a time in startup order. Do not delete unfamiliar system interfaces; exit the related programs and restart the client first, then decide on a long-term configuration after confirming the conflict.
Distinguish a route failure from local network instability
If ordinary websites also stop opening after the connection is turned off when the drop occurs, the local network itself was interrupted. If the local network remains stable but one route keeps disconnecting and another route in the same region works, report the original route. If every route disconnects on one access network but works on another, the issue is closer to the current access environment. This three-way comparison—local network, alternative route and alternative access network—keeps problems at different layers separate.
During frequent disconnects, do not use a long-running large-file transfer as the only test, because automatic retries may hide the exact disconnect time. Instead, observe the client status alongside a lightweight webpage request and note which status changes first. If logs contain account credentials or the full subscription, remove sensitive sections before submitting. Keep ordinary error codes, timestamps and route names.
Edge case: A brief reconnect while switching between Wi-Fi and a mobile network does not equal a persistent route failure. Continue investigating only if recovery does not occur after the network stabilizes or the same trigger repeats.
State the trigger clearly when reporting disconnects
The ticket should say whether the issue occurs in the foreground or background, whether screen locking or a network switch is involved, whether all routes or one route is affected, what the client displays after the drop, and whether reconnecting restores service. On mobile, include the platform and screenshots of power-saving settings; on desktop, include comparison results showing whether conflicting programs were exited. If only one app loses connectivity while others work, use the per-app section instead of treating it as a full connection drop.
Subscription Update Failed: Check Source, Network and Cache
A subscription update synchronizes routes and rules from the account to the client. A failed update may not affect cached routes, but new, changed or updated status information will not reach the local configuration promptly.
First confirm that the subscription comes from the current user panel
Subscriptions should be obtained from the VPNTea user panel; marketing pages do not provide static installers or public subscription URLs. Open the client's subscription management page and verify that the configuration name and source belong to the current account. If multiple configurations were copied manually, the client may be updating an old configuration while the actual connection uses another. Keep the current configurations during troubleshooting, identify which one is enabled, and then handle duplicates.
There is no need to send the full subscription URL to support, and authentication parameters should not appear in screenshots. Just report the error text returned by the client after copying from the user panel, the network environment during the update and whether the configuration has ever worked. If an incomplete copy is suspected, retrieve it again from the panel and add it through the client's standard import entry instead of manually editing the URL structure.
Distinguish retrieval failure from parsing failure
“Unable to download the subscription” and “subscription format cannot be parsed” occur at different stages. A retrieval failure usually appears as a network error, timeout or access denial, meaning the client has not received the configuration. A parsing failure means the content arrived but the client could not recognize it, it was truncated, or the import method did not match. Preserve the exact error text to distinguish them. Do not treat a parsing error as a route failure—the connection process has not started yet.
For a retrieval failure, update once with the connection off and once with it on, then compare another access network. Some networks handle subscription requests differently from ordinary webpages. If only the current network fails, record its type. If different networks all fail, check the account plan status and subscription source. For a parsing failure, confirm that the import method is supported by the client and retrieve the subscription again from the panel. Do not paste webpage content into a field that expects a subscription URL.
Find the subscription the client actually uses so you do not update an inactive old copy.
Distinguish an incomplete request, a rejected response and a content-parsing failure.
Keep the client and subscription unchanged; compare only the access network.
Handle client cache and duplicate configurations
The client may retain routes from the last successful update, so “it still connects” and “the update succeeded” are not contradictory. Check whether the route names match the panel's current display. If the client remains in an old state, refresh or reselect the subscription first. Only delete duplicate old configurations after confirming that the current configuration can be retrieved again. Deleting everything at once removes usable cached data and makes recovery harder.
If the client supports automatic updates, switch temporarily to a manual update during diagnosis so you can see the immediate error. When an automatic update fails in the background, its message may be collapsed by the system, making the exact time difficult to determine. Restore the normal schedule after a successful manual update. On mobile, ensure the client is not paused by the system during the update; on desktop, check whether the system proxy or another network tool is affecting the subscription request.
Check plan status and traffic source
Log in to the user panel to view the current plan status instead of relying on an old expiration date shown in the client. Monthly subscriptions have three tiers: ¥9.9/month includes 60GB, ¥18/month includes 250GB, and ¥28/month includes 500GB; traffic resets monthly on the activation date, and mid-cycle upgrades convert the price difference into remaining days. Traffic packages are ¥158/300GB, ¥358/1000GB and ¥658/3000GB; they remain available until used and never expire. During troubleshooting, simply confirm that the current entitlement is valid; do not calculate the remaining period yourself.
To change plans, visit the pricing page for the full details. Payment methods are Alipay, WeChat Pay and USDT. Describe subscription-update problems separately from payment-page issues: the former concerns retrieving configuration in the client, while the latter concerns orders and plan status in the user panel. Combining both into “the account does not work” makes diagnosis harder.
Security reminder: Do not paste the full subscription URL, password or complete configuration into a ticket. Provide the exact error text, client platform, access network, whether an update has ever succeeded and the current plan status.
When to re-import and when to submit a ticket
If the same subscription updates on another device, the original device is more likely to have a client cache, import-method or network-setting issue. Re-import it for comparison while keeping the old configuration. If every device and network returns the same retrieval error, submit a ticket and state the failure stage. If parsing fails only in one client while other platforms work, include the client name and exact error text so support can assess a format-compatibility issue.
After updates recover, confirm that the route list actually changed and connect through one route as a verification. Seeing “update successful” is not enough because the client may have updated an inactive configuration. Finally, remove confirmed-useless duplicates so future troubleshooting has a single subscription source. Keeping the configuration simple often prevents long-term issues better than repeated reinstalls.
An App Cannot Use the Proxy: Check Rule Boundaries
When only one app fails on the same device, the system connection is usually working; the issue is concentrated in per-app selection, domain rules, the app's independent network stack or the target region.
First prove that only one app is affected
Keep the current route unchanged and test the browser and another commonly used app. If other apps work, the subscription, route and system permissions have at least basic functionality, so do not start with a full reinstall. Record exactly what fails in the affected app: login at startup, opening the content list, loading images or timing out after entering a specific feature. An app may call several domains internally; one failed feature does not mean the entire app bypassed the connection.
Then compare the app with its web version. If the web version works while the client app fails, focus on per-app rules, app cache and independent network settings. If both fail, consider the target service region, domain rules or route. For AI tools, see the ChatGPT acceleration guide and AI API fixed-egress and concurrency requirements guide, but complete the local comparison first.
Check include and exclude logic
Per-app proxying usually follows one of two opposite rules: only selected apps use the route, or selected apps remain direct. Similar interface labels make it easy to choose the wrong one. Open the client's per-app settings, confirm what the current mode means, and check that the target app is in the correct list. After an app update, its system identifier may change, so an old rule may no longer match. If the issue began after an app update, select the target app again.
During diagnosis, temporarily disable per-app mode so all system traffic follows the current mode. If the app immediately recovers, the route itself is usually fine and the issue lies in app selection or rules. If it still fails, continue comparing global mode and rules mode. Restore the original settings after the comparison; do not leave a temporary global configuration in place.
Check multi-domain resources in rules mode
Modern apps often distribute login, APIs, images, video and updates across different domains. If the main domain uses the route but static-resource domains are classified as direct, you may be able to log in while seeing a blank page, or see text while images fail to load. Temporarily switch to global mode; if all resources return, update the subscription rules or check custom overrides. Do not add only the one domain currently visible, because later features may call other domains.
If the app offers built-in proxy settings, avoid configuring them redundantly with the system connection. A manually configured in-app proxy may point to a dead local port, causing the app to fail independently even when the system route works. Record the original setting, then switch it to follow the system network for comparison. Development tools, command-line apps and containers may also read separate environment variables and may not inherit the desktop client's system proxy.
Judge target region and account status separately
Some services display different content based on the egress region. If an app connects but reports that the region is unavailable, this is not an ordinary connection failure. Choose a regional route that matches the target content and fully quit and reopen the app. The app may cache the previous region, so switching routes in the background may not refresh its state. If only that service is affected after changing regions while other sites work, record the service name, route region and exact message.
The target service's own account restrictions, login state or risk-control message cannot be fixed by repeatedly switching routes. First check whether the error explicitly concerns the account, payment or content permissions. For an account issue, follow the service's official process. For network timeouts, resources that fail to load or inconsistent region detection, continue with routes and rules. Separating account errors from network errors prevents pointless local changes.
Minimal reproduction: In the ticket, write “the browser works on the same route, but the target app fails,” then add the exact in-app action, per-app mode, global-mode comparison and target region. This is more useful than naming the app alone.
Clean up rules after recovery
After resolving the issue, remove duplicate rules and temporary global settings added during diagnosis, keeping only rules with a clear purpose. Accumulating exceptions makes future traffic paths difficult to predict. If different apps need different paths, add and test them one at a time instead of selecting every app in bulk. Clearer rules make differences easier to identify after the next app update or subscription change.
Device-count notices and inconsistent cross-platform status
VPNTea supports unlimited devices. If a client shows a device-related notice, investigate account status, old sessions, mixed configurations and local client state instead of treating it as a plan device limit.
Confirm the fact first: unlimited devices
VPNTea allows unlimited simultaneous devices and supports Windows, macOS, iOS, Android and Linux. Therefore, when one device cannot connect, do not assume a plan limit first. More commonly, that device is using an old subscription, the client has cached an expired account state, system network permission has failed, or different devices are connected to different configurations. Log in to the user panel to confirm the current plan status, then verify the subscription source on each device.
Unlimited devices does not mean every device will have identical network performance. Devices may use different access networks, client modes, regional routes and split-tunneling rules. When comparing devices, separate “the account allows the connection” from “the device is configured correctly.” If another device works, the account and at least one route are available, so focus first on the affected device.
Build a device comparison table
For each device, record the platform, access network, subscription name enabled in the client, selected route and symptoms. Do not combine the device model, system platform and network environment into one variable. For example, a desktop working on a home network and a mobile device failing on another network does not prove a platform-compatibility issue; connect both to the same network and select the same route before comparing.
If only one device fails on the same network and route, check its network permissions, other proxy tools, per-app settings and system time. If both fail but recover after changing routes, the original route is implicated. If the same device recovers after changing networks, the access network is implicated. Cross-comparison avoids repeating irrelevant resets on every device.
Handle old sessions and duplicate subscriptions
After a device replacement, system restore or client migration, old configurations may remain. Confirm that the enabled subscription comes from the same account; do not rely on similar names. If the client stores multiple subscriptions, updating one will not automatically update another. Give the current configuration a clear name, verify a connection, then delete confirmed-useless old copies.
If the client shows an account- or device-related error, preserve the exact text and check the status again in the user panel. Do not repeatedly change the username or password as a test, because this can invalidate active sessions on other devices and widen the scope. VPNTea registration requires no email address; a username and password are enough. Keep your credentials secure—support does not need your password and will not ask you to include it in a ticket.
Platform differences are not route differences
Windows and macOS may take over traffic through a system proxy or network extension, while iOS and Android rely on system network configuration. Linux may also separate desktop settings from the command-line environment. The same subscription can expose different option names and routing implementations on different platforms, so compare the final behavior rather than requiring every interface to match. A platform lacking a switch with the same name as another platform does not mean the capability is unavailable.
If only the Linux command line fails while graphical apps work, check terminal environment variables. If only one Android app fails, check per-app selection. If iOS behaves abnormally after screen lock, check background operation and system configuration. If a desktop behaves abnormally after waking, re-establish the session and check network interfaces. Bringing platform-specific symptoms back to the relevant section is more accurate than blaming “too many devices.”
Decision rule: When a device-related notice appears, record the complete message first. VPNTea's plan fact is unlimited devices; do not delete every device configuration to address an error whose source has not been confirmed.
When to submit an account-related ticket
If the user panel shows an active plan but different platforms, networks and routes all return the same account message, submit a ticket. Include the username, not the password, and state whether the message appears during login, subscription update or connection. If only one device is affected, first include that platform's client status and the comparison-device result. Support needs to know whether the error concerns account authorization or local client state; the stage where it occurs matters more than the number of devices.
If the issue concerns plan selection or an upgrade, first review plan prices and traffic rules. Monthly plan upgrades convert the price difference into remaining days, and traffic resets monthly on the activation date; traffic packages remain available until used and never expire. Do not convert different traffic sources into device quotas; they are unrelated.
Before Submitting a Ticket: Prepare a Reproducible Record
An effective ticket is not a pile of screenshots. It is a diagnostic record that organizes the symptoms, scope, changes, comparison results and exact error text so support can reproduce the issue.
Describe the issue in one paragraph first
Start by stating the platform, access network, route, affected app and exact behavior. For example: “On Windows using a home network, a regional route connects, but no domains resolve in the browser; switching to another network restores access.” This already covers the device, environment, route, symptom and comparison. Unlike “it suddenly stopped working today,” it points support directly toward DNS and the access network.
For performance issues, state the time period and app action. For disconnects, state the trigger and client status afterward. For subscription issues, say whether retrieval or parsing failed. For a single-app issue, explain the difference between global and rules mode. Do not put unrelated problems into one long paragraph; list them by symptom so one resolved issue does not hide another that is still occurring.
Diagnostic information to include in a ticket
- ✅ System platform and client type used
- ✅ Access network type and comparison result after switching networks
- ✅ Route name, route region and whether all routes are affected
- ✅ Exact action when the issue occurred and the client's status text
- ✅ Exact error text, necessary screenshots and reproducible conditions
- ✅ Whether the subscription, system network settings, rules or app configuration changed recently
- ❌ Do not submit passwords, full subscription URLs, authentication parameters or complete configurations
Screenshots should include enough context while hiding sensitive content. A single error icon is rarely useful; include the page title, error text and current route whenever possible. Logs should cover only the relevant period before and after the failure, not an entire long-term log. If logs contain subscription data, remove it first.
How to record recent changes
Many issues begin at a change point: a system update, client re-import, access-network switch, split-tunneling change, target-app update, new device-management policy or plan-status change. A change point is not proof of causation, but it can greatly narrow the scope. State “normal before the change, abnormal after the change” and whether reverting it restored service.
If you cannot remember a specific change, do not guess. Write “no configuration changes made intentionally” and describe where you first noticed the issue. Support can continue with route status, account status and error details. Inventing a plausible cause can send troubleshooting in the wrong direction. Keep facts and assumptions separate: write observed behavior as fact and mark assumptions with “may.”
Describe the exact action, error text and current client status.
Change one variable among the route, access network, device or app.
Keep diagnostic context, but do not submit passwords or the full subscription.
When to contact support directly
Submit a ticket when the same account or subscription error appears across different devices, access networks and routes; when the user-panel status clearly differs from the client status; when one route remains unable to connect while other routes in the same region work; or when the minimum comparisons in this guide still cannot define the boundary. Handle payment and plan-status issues through a ticket as well, stating whether the payment method was Alipay, WeChat Pay or USDT, but do not upload complete payment credentials.
If you simply need help with the initial import, return to the Quick Start Guide. To compare regions and route types, see the server page. To choose a monthly subscription or traffic package, see the plans page. Directing each usage question to the right resource avoids unnecessary account changes. VPNTea covers 90+ countries and 200+ routes; during troubleshooting, compare a small number of representative routes instead of testing every route.
Final checks after recovery
Do not end troubleshooting immediately after service returns. Repeat the action that originally failed under the same conditions, then disconnect and reconnect to confirm the recovery is not a one-time result. Finally, remove temporary global mode, duplicate subscriptions, custom DNS and any necessary security settings disabled for testing. Keep only verified changes and record the final configuration for future reference.
Even if the issue disappears on its own, keep a brief record, especially of the time period, route and network. If an intermittent issue returns, before-and-after notes can show whether the same pattern is repeating. For peak-hour lag, disconnects after network changes and failed resource loading in a specific app, a continuous record is often more useful than a single screenshot.
Submit a ticket with your diagnostic record ready
The user panel provides a ticket entry. Before submitting, confirm that it contains no password, full subscription URL or authentication parameters; keep only the username, platform, route, exact error text and comparison results. An email address is not required to register; a username and password are enough to use the account.