Cross-Border Network Troubleshooting

Diagnostic Baseline: Identify the affected layer first

This page is a systematic troubleshooting manual for situations where installation and subscription import are complete but the connection does not behave as expected. If you have not finished signing up, purchasing, obtaining a subscription, or making your first connection, start with the Quick Start Guide. Follow the basic setup path first, then return here for specific symptoms. The division of labor is clear: the guide answers “Where do I click next?”, while this page answers “Why is it not working as expected, and how can I verify the fix?”

Network problems often look the same: a page keeps loading, an app says it is offline, or the client button will not stay connected. Yet the underlying fault may be in entirely different places. The full path can be divided into four layers: the local access network, the client and system permissions, the UQVPN route, and the destination website or app. The goal is not to guess the cause immediately, but to eliminate layers through repeatable comparisons. Change one condition at a time and record the result before and after; otherwise, switching routes, changing DNS, and reinstalling the client at once makes it impossible to tell what helped.

Save the current state before making any changes

Before you begin, record the platform, client connection status, selected region, network environment, affected service, and whether the issue is constant or intermittent. If the client shows an error, save the complete wording rather than quoting only “failed” or “timed out.” If the issue affects just one app, compare it with a browser on the same device. If every program is affected, check the system proxy, DNS, and local network first instead of blaming a single app.

Next, create a minimal test setup: pause downloads, cloud sync, and streaming tasks that are not part of the test, leaving only the browser and client running. Visit a normally reliable website, then the affected service. Focus on whether a connection can be established and how broad the failure is, not on chasing a speed figure. If both ordinary sites and the target service fail, the fault is likely earlier in the chain. If ordinary sites work but the target service fails, look more closely at the destination, regional matching, app cache, or routing rules.

Build meaningful comparison tests

The most useful comparisons are usually: “same device, different local network,” “same network, different device,” “same device, different route,” and “same route, different destination.” If changing the local network fixes the issue on the same device, inspect restrictions, routing quality, or DNS on the original network. If other devices work on the same network, focus on permissions, leftover proxy settings, and security software on the affected device. If changing routes fixes the issue, the original path may not match the destination well. If only one destination fails, there is no need to rebuild every setting.

Do not switch routes rapidly and repeatedly during testing. The previous connection must be released, the system proxy restored, and the DNS cache updated before the next round. A safer sequence is to disconnect, confirm that the system has returned to a direct connection, select a different region, reconnect, and reopen the test page. Existing browser tabs may retain old connections; use a new private window when necessary to rule out cache, extensions, and existing sessions.

After establishing the baseline, you should be able to describe the issue in one sentence, such as “Windows cannot establish any route on the current network,” “iOS connects successfully but one app has no traffic,” or “Android pauses the connection after the screen locks.” This is far more actionable than “the network does not work.” The following chapters use symptoms as the entry point, presenting a decision path first and then explaining the relevant mechanism and repair boundary.

Cannot Connect at All or Subscription Updates Fail

“Cannot connect at all” should first be divided into four cases: the client will not launch, subscription content cannot be read, routes are listed but connections fail, or the connection button changes briefly and then returns to its previous state. These occur at different stages. A client that will not launch usually points to system permissions or an incomplete installation. An unreadable subscription points to sign-in status, subscription content, or the local network. A populated list with every route failing points to the network entry point, system components, or subscription status. If only a few routes fail, try another route in the same or a nearby region before reinstalling the client.

The client cannot establish any route

First confirm that the device can access ordinary websites directly. If ordinary websites also fail after disconnecting UQVPN, restore the local network first: reconnect to Wi-Fi, check the wired connection, and make sure the system is not stuck using an invalid manual proxy. Continuing to operate the client at this stage only adds variables. Once direct access works, fully quit and reopen the client, then check whether the system requests a network extension, VPN configuration, or administrator permission. If permission was previously denied, the client interface may still open while the system component required to create the tunnel remains inactive.

On Windows and macOS, check the system network settings for configurations left behind by other proxy tools. When multiple network tools control the system proxy, the connection button may work while traffic has no clear exit, or a newly established connection may immediately be overridden by another program. During testing, quit other network filters, proxies, and packet-capture tools rather than merely closing their windows. On Linux, confirm that the client process has permission to create a network interface and adjust routes, and check that the desktop network manager has not enabled another connection profile at the same time.

If the same account connects on other devices but every route fails on the current device, focus on that device. Proceed in order: quit the client, restore a direct system connection, reopen the client, reauthorize system network permissions, and test one route. If every device fails on the same access network but works after switching networks, the original access network is the main variable. Do not repeatedly change the account password or plan, because authentication is not the only possible failure point.

Subscription Cannot Update or the Route List Is Empty

A subscription update is a separate network request. Its failure does not necessarily mean that existing routes are unusable or that account data has been lost. Check whether the client reports a timeout, malformed content, or an authentication failure. Timeouts usually involve the current network, leftover system proxy settings, or the subscription request being routed incorrectly. Malformed content may result from spaces, line breaks, or explanatory text copied along with the address. An authentication failure should be handled by obtaining the subscription again from the user panel rather than editing the old address.

The marketing site does not publish a static subscription address. Get the current subscription from the user panel and copy it in full. If a format must be shown in troubleshooting or educational material, use an unmistakable dummy value, such as:

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

When importing, do not paste the address into a search box, route name, or notes field. If the client offers both “Import from clipboard” and “Import from URL,” choose the URL-based method that supports periodic updates. Temporarily disconnect before updating so the request is not routed through the currently failing connection. After the update, check that route names have refreshed before reconnecting. If the old subscription remains in the client, disable it rather than deleting it immediately, so you can compare whether the old and new configurations belong to the same account.

Only Some Routes Cannot Connect

When only some routes fail, first review Global Nodes and Route Details, then cross-check with a nearby region or a different route type. Different route names do not necessarily mean completely different paths, so choose a comparison that differs in both region and type. If one region keeps failing while others remain stable, record its name and the full error text rather than treating the issue as an account-wide failure. UQVPN covers 100+ countries / 150+ routes; the goal is to find a path that works on the current network and submit the specific unavailable path for review.

If the client shows an empty list immediately after import, check whether filters are hiding every item. Some clients remember the previous search term, region filter, or group selection; updating a subscription does not automatically clear those interface settings. Clear the filters first, then confirm that the subscription itself contains content. If the interface shows that the subscription exists but no route can be selected, quit and reload the configuration. If that still fails, preserve the client log and subscription update time, then follow the support ticket process at the end of this page.

Connected but Websites Won’t Load: DNS Issues and Leftover Proxy Settings

A client showing a successful connection while browser pages fail is one of the easiest situations to misdiagnose. The connection status only confirms that the necessary handshake between the client and route completed. Name resolution, handing the request to the proxy, browser reuse of an existing connection, and destination acceptance of the current exit can each fail independently. First determine whether all domains fail, only domain names fail while direct addresses work, only the browser fails, or only a specific website fails; then choose the appropriate direction.

Separate resolution failures from request failures

DNS converts domain names into reachable addresses. When resolution fails, browsers often report that the server cannot be found, the name cannot be resolved, or remain in the lookup stage for a long time. Request failures are more likely when resolution has completed but the subsequent connection times out, resets, or loads only part of the page. Do not rely solely on the browser’s simplified message. Run a basic query in the system terminal and use an ordinary test domain to check whether the device can resolve it.

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

The first command checks whether domain resolution returns a result; the second verifies the basic web-request path. The example domain is for troubleshooting only and contains no account credentials. If the resolution command fails while the client shows connected, check whether old software has fixed the system DNS, whether the client uses its own resolution mode, and whether stale results remain cached after switching networks. If resolution succeeds but requests fail, focus on the system proxy, route, and destination rather than repeatedly changing DNS.

Clear the cache instead of blindly changing addresses

Both the system and browser may cache resolution results. After switching routes, old results may not expire immediately, especially when the browser has been open for a long time. On Windows, run this in a terminal:

ipconfig /flushdns

On macOS, run this in a terminal:

sudo dscacheutil -flushcache

After running the command, close the affected browser tabs and test again in a private window. On mobile, there is no need to install an extra cleaner just to clear the cache. A cleaner refresh usually comes from disconnecting, closing the target app, switching networks once, and reconnecting. If only one browser is affected, disable extensions that modify requests, filter content, or control the proxy, then compare with the system browser. If another browser works, the route and account are usually not the main cause.

Manually specifying DNS is not a universal fix. When the client already controls resolution, adding another fixed value at the system level can create a conflict. If the destination relies on regional resolution, a resolver in a region that does not match the route may also produce mismatched page regions, login risk checks, or resource addresses. The safer approach is to restore automatic system settings and let the client handle resolution according to its configuration. Only run a single-variable test when there is clear evidence of a local resolution problem, and keep the original settings so you can revert.

Check whether the system proxy is restored after disconnecting

An abnormal exit, forced process termination, or alternating between multiple clients can leave a proxy configuration pointing to an inactive local port. Even after the client disconnects, the browser may continue sending requests to a nonexistent local service, causing every page to fail immediately. Check the proxy section of the system network settings and make sure it matches the client’s current state. If the client’s system-proxy mode is active, do not enter another address manually. If the client has exited, the system should not retain the temporary proxy it created.

Also check whether the browser has its own proxy setting. Some browsers and extensions can bypass system settings, producing cases where system apps work but the browser fails, or the reverse. During troubleshooting, return them to the system default path and confirm basic access before enabling separate rules as needed. An automatic proxy configuration file from an old environment may continue overriding manual changes, so disable it temporarily and test again.

Only the Target Website Fails

If ordinary websites work but the target site does not, test first in a private window on the same route, then clear that site’s cache and session. The destination may handle existing sessions, regional records, or resource domains differently. The main page may open while images, video, or the login endpoint fail because some subdomains are not following the same rule. Record the failed page, the step where it occurred, and the browser message; this is more useful than simply saying “the website won’t load.”

For streaming region and content matching, see Streaming Access Guide and Netflix Regional Libraries and Bandwidth Guide. For developer tools or API requests, distinguish web access from command-line requests and continue with the AI API Networking Guide. If the destination is undergoing maintenance, has an account issue, or has changed its regional content, local setting changes will not solve it. Preserve the conclusion that only this destination is affected.

Layered Diagnosis for Slow Speeds and Peak-Hour Lag

Speed cannot be judged from one test result. Downloads, web pages, video, remote desktops, and API calls have different requirements: large files depend more on sustained throughput; pages are affected by connection setup and many small resources; video needs steady buffering; remote interaction is more sensitive to latency variation; and API calls may depend on persistent connections and timeout policies. Define which task feels slow first, then compare direct access, the local network, the route, and the destination instead of using one page to represent the entire path.

Rule out the local network and background usage first

Disconnect UQVPN and test whether the local network is already lagging. If ordinary websites are unstable even directly, address Wi-Fi signal quality, router load, mobile-network changes, or congestion on the access network first. The client cannot improve local access quality; it can only choose a cross-border path once the local network is usable. Pause system updates, cloud-drive sync, photo backups, large uploads, and other streaming tasks on the test device. When the upload link is saturated, downloads and page responses also slow because acknowledgements and control traffic cannot get out promptly.

On Wi-Fi, distance from the access point, frequent roaming between access points, and nearby interference can all cause brief packet loss. This can look like route congestion, but often improves after switching to wired access or a stable mobile network. During mobile testing, keep the screen on and disable battery-saving restrictions so the system does not reduce background network activity midway through the test. Route comparisons are meaningful only after the local baseline is stable.

Route Distance and Route Type

Physical distance affects the round-trip path. For everyday browsing, work, and messaging, start with a geographically closer region and a more direct route. For content tied to a particular region, also consider where the destination is located. A longer distance is not automatically unusable, but it expands the network path and makes performance more sensitive to changes along the way. Review region and route-type details in Global Nodes; establish a baseline with a nearby region before switching for specific content.

The difference between IEPL dedicated routes, relays, and direct connections is mainly how the path is organized, not a simple ranking of good and bad. Dedicated routes suit situations that prioritize stability across the international segment. Relays can improve connection quality on some networks by coordinating entry and exit points. Direct routes are more straightforward but more sensitive to local carriers and changes in international routing. Test which works best on the current network using the same time, device, and task. Do not change the region, route type, and test app at the same time, or you will not know what caused the improvement.

Peak-hour issues occur only at set times

If performance is normal during the day but slows at a consistent evening time, record direct local access and UQVPN performance separately. If both slow down, congestion on the local access network or carrier exit is more likely. If direct access remains stable but a route category slows, try a different entry point, region, or route type. Do not test only once at the worst moment; repeat the same task after recovery to confirm whether the issue is time-related.

Peak-hour troubleshooting should not rely on repeatedly refreshing a speed-test page. The test server’s location and load differ from those of the target app, so its numbers do not directly represent the real task. A better method is to choose a repeatable action—open the same set of pages, play the same content, download the same test file, or make the same development request—and record whether it completes consistently. For continuous content such as live sports, see the Low-Latency Live Streaming and Peak-Hour Route Guide, focusing on sustained buffering and recovery after switching routes rather than a single peak result.

How Protocols, Systems, and Security Software Affect Performance

Start with the client’s default settings. Adding system proxies, browser proxies, security filters, and packet-capture tools creates more processing layers. Security software that inspects encrypted connections can also affect connection setup and many small requests. Temporarily quit related programs for comparison. If one is confirmed to matter, grant the client the required system permissions or compatibility settings instead of leaving device protection disabled.

Verification after a fix should cover the real task that failed. A working webpage does not prove that video will remain stable, and a successful short request does not prove that a long connection will stay alive. Record the task, route region, local network, and time period. If the issue returns, you can compare the conditions directly instead of guessing from scratch.

Frequent Disconnects and Mobile Background Dropouts

First distinguish a route session ending from an app being paused by the system. The former can happen even while the screen is on and the app is in the foreground, with the client status changing clearly. The latter is more common after locking the screen, switching apps, enabling battery saving, or moving from Wi-Fi to mobile data; you notice it only when reopening the client. The symptoms are similar, but the fixes are completely different.

Disconnects also occur during foreground use

First check whether the disconnect coincides with a local network change. A brief Wi-Fi loss, roaming between access points, or a mobile-network technology change can invalidate the current session. If ordinary websites also pause directly when the disconnect occurs, stabilize local access first. Keep the device in the foreground at a fixed location on a fixed network and avoid movement or network switching. If disconnects stop, the cause is more likely local network changes than the account or client.

If the local network is stable but a specific route disconnects repeatedly, compare it with a route from a different region and type. If only one route is affected, record its name. If all routes disconnect during similar activity, check system sleep, network-extension permissions, security software, and other proxy programs. A desktop system may pause the network interface during sleep and require the client to establish a new session after waking. Distinguish “reconnects after sleep” from “drops during normal use” so expected system behavior is not logged as a persistent fault.

If the client still shows the old connection after a network change, manually disconnect and reconnect so the system route and DNS are rebuilt together. Do not repeatedly click the connect button while switching between Wi-Fi and mobile data; this can create several incomplete operations. If you must fully quit the client after every network change, preserve that sequence and the system log so support can determine whether the issue involves permissions, the network extension, or client state synchronization.

Background Limits on iOS and Android

Mobile operating systems manage apps according to battery level, memory, background activity, and manufacturer policy. If the connection stops after locking the screen, first check whether the client is allowed to run in the background, whether strict battery saving is enabled, and whether the app has been placed in a sleep or background-restriction list. Settings names differ across Android devices and are usually found under app info, battery, or background activity. Set the UQVPN client to allow background network activity and prevent automatic cleanup.

On iOS, confirm that the VPN configuration still exists, the client has the required permissions, and the dropout occurs only after switching between Wi-Fi and mobile data. If it appears only after a long locked-screen period, compare with Low Power Mode disabled. If it also occurs during continuous foreground use, do not simply blame background behavior; return to the route and local-network checks. Do not enable multiple VPN configurations or network-filtering apps at once on mobile, as they may compete for the same system entry point.

Keep conditions clear during a background stability test: choose a known-working route, start a task that continuously uses the network, lock the screen, and observe what happens after unlocking. Do not switch networks or start other network tools during the test. If the client still shows connected after unlocking but the app has no data, reopen the target app first. If every app has no data, disconnect and reconnect. This distinguishes an app being suspended from a system-wide route failure.

Desktop Sleep, Lid Closure, and Network Wake

Closing the lid on macOS, sleep on Windows, and suspension in a Linux desktop environment all pause networking. After waking, the system may restore Wi-Fi first and the client’s network extension afterward, briefly leaving connection status out of sync with the actual route. Wait for local networking to recover, confirm that the ordinary network interface is connected, and then let the client reconnect. Switching routes repeatedly immediately after wake-up can prolong recovery.

If the connection never recovers automatically after waking, check whether the system blocks the client from launching in the background, whether the network extension remains authorized in system settings, and whether cleanup software is terminating related processes. For macOS installation and permissions, see the macOS Installation, Permissions, and Subscription Import Guide. On Linux, also check whether the desktop network manager resets DNS or the default route during recovery. If command-line requests work but desktop apps fail, inspect the proxy environment of the desktop session.

How to Verify That Disconnects Are Fixed

After a fix, test the original scenario that was easy to reproduce rather than watching only the connection button. For foreground disconnects, stay on the same network and complete the original task. For background dropouts, repeat the original lock-screen, app-switching, or wake-up sequence. For network-change issues, test both switching from Wi-Fi to mobile data and returning to Wi-Fi. If the reproduction conditions change, temporary normal behavior does not prove that the cause is gone.

If disconnects continue, record whether the local network changed before or after the event, along with the client status, selected route, target app, and system action. If logs contain a subscription address or authentication content, redact sensitive sections before submitting them. Never publicly share a complete subscription link. Support needs the error timestamp, action sequence, and surrounding log context—not credentials that could be used directly.

A Single App Ignores the Proxy: App Routing and Traffic Paths

If a browser works on the same device but one app cannot connect, the basic route is usually available and the fault should be narrowed to the app’s traffic path. Common causes include the app ignoring the system proxy, the client using rule-based routing, the destination using a domain not covered by the rules, the app retaining an old connection, or a separate network restriction on that app. Reinstalling UQVPN, changing the account, or purchasing more traffic is usually not targeted at this kind of issue.

First identify how the client takes control of traffic

System-proxy mode mainly affects programs that follow system proxy settings. Some apps open network connections directly and do not read the system proxy, which is why a browser can work while an app connects directly. A virtual network interface mode usually covers more system traffic but requires full system permissions and may conflict with other network-filtering software. Before troubleshooting, check the client’s current mode and whether it matches the target app’s traffic behavior. Do not cycle through every advanced option without understanding the difference.

The most direct test is to temporarily switch routing rules to a broader coverage mode and restart the target app. Fully terminate the app instead of merely returning to the desktop, because an old connection may continue to be reused. If broader interception restores access, the basic route is working and the next step is to inspect rules, not routes. If it still fails, check the app’s own network permissions, destination status, and system restrictions. After testing, restore the mode that fits everyday needs so unrelated traffic paths are not changed long term.

Domain Rules and Direct-Address Connections

Rule-based routing usually selects a path based on domains, address ranges, or app information. A target app may contact its main domain first, then content domains, login endpoints, update servers, or direct addresses. Adding only the main domain to the rules can produce an incomplete state: the home page is visible but login fails, text loads but images do not, or messages arrive but attachments cannot be sent. Browser developer tools, client logs, or system network logs can help identify failed requests, but do not permanently add every domain found in a log without review.

If an app connects directly to an address, a domain-only rule may not match it. Use the client’s app-routing feature or a broader traffic-interception mode to verify. An app update may also change its service domains and invalidate old rules. Prefer updating the subscription and client rules instead of maintaining an ever-growing manual list. The more manual rules there are, the harder future conflicts become to locate.

App cache, sign-in status, and regional information

An app may determine its region or establish a persistent connection at launch. If it is not restarted after connecting UQVPN, it may continue using a session from before the connection. The correct order is to fully quit the target app, connect to a suitable region, confirm that the route works, and reopen the app. If the issue remains, sign out of the target account and sign in again—but first make sure the credentials are available so a network issue does not become an account-recovery issue.

Apps serving regional content may also save cache, cookies, or local settings. Before clearing them, check whether offline content or sign-in status will be deleted. In a browser, use a private window for a low-risk test. In a mobile app, first try signing out within the app and restarting it rather than clearing all data. Proceed to cache handling only when a new session works but the old one does not.

Developer Tools and Command-Line Programs

Terminals, package managers, developer tools, and background services do not necessarily inherit the desktop system proxy. If a graphical browser works but a command-line request fails, the terminal environment may not have loaded the proxy settings. Conversely, stale environment variables in the terminal may continue pointing to an inactive service after the client disconnects. Check proxy variables in the current session and test again in a new terminal window. Never paste a complete environment dump containing credentials into a support ticket.

API calls also involve fixed exits, persistent connections, concurrency, and timeout policies, so a working webpage is not equivalent to a working API. Reproduce the issue with the project’s smallest real request and distinguish name resolution, connection setup, service response, and app retries. For a fuller developer scenario, see the AI API Networking Guide. If both web and command-line requests work but the developer tool fails, inspect that tool’s separate proxy settings and runtime environment first.

The final conclusion should be clear: whether the app follows the system proxy, whether broader traffic interception restores access, whether an app restart is required, and whether the fault affects only a particular type of resource. If you need to submit a ticket, include the app name, platform, client mode, steps that trigger the issue, and the comparison result from a browser on the same device. Do not send an account password or complete subscription content.

Account Status, Traffic Resets, and Device Notices

Account-level issues usually have clear boundaries: whether the subscription is still valid, whether monthly traffic has been used up, whether a traffic package still has balance, and whether the client has loaded the current account subscription. These differ from route quality, DNS, and app routing. If the client reports an authorization, subscription, or traffic-status issue, check the account in the user panel before changing device settings. Reinstalling repeatedly will not change account-side status.

Confirm the subscription type and traffic cycle first

UQVPN monthly subscriptions include ¥9.9/month with 60GB, ¥18/month with 250GB, and ¥28/month with 500GB. Traffic resets monthly on the activation date; mid-cycle upgrades are prorated by the remaining days. Do not estimate the reset date by the calendar month. Use the activation cycle shown in the user panel. If an upgrade has just been completed but the client still shows the old status, confirm in the panel that the change is active, then disconnect and update the subscription.

Traffic packages remain valid until used and never expire. Options include ¥158/300GB, ¥358/1000GB, and ¥658/3000GB. Monthly subscriptions and traffic packages follow different cycle rules: a traffic package does not reset monthly, and monthly-subscription rules do not apply to it. See the Plans page for complete pricing and availability. Use the options currently shown in the user panel to verify the amount, capacity, and cycle.

When traffic runs low, the client may not show a single immediate warning. A subscription may still update while routes can no longer carry traffic. If all devices develop similar issues while the local network is normal, check account traffic and validity. If only one app or one device is affected, insufficient traffic is less likely; return to troubleshooting that device.

Unlimited device count does not mean identical independent status on every device

UQVPN allows unlimited simultaneous devices. If the client displays a message such as “device limit exceeded,” do not delete other devices or assume a fixed device cap. First confirm whether the message comes from the UQVPN client, the target app, or another network tool on the system. Preserve the title and full text of the message in a screenshot so support can determine whether it concerns account authentication, client configuration, or a third-party app.

When multiple devices are used, the account subscription and traffic status are shared, but system permissions, DNS, route selection, and app rules are independent on each device. One working device does not prove that another is configured correctly. If every device fails, inspect the account status or shared access network. A useful comparison is to connect a known-working device to the same network, select a route in the same region, and compare it with the affected device. Do not copy a working device’s configuration file into a public location.

If a device reports that authentication has expired, obtain the subscription again from the user panel. UQVPN registration requires no email address, so store the username and password securely. In troubleshooting notes, include only the minimum account identifier needed for recognition and never submit the password. If you are unsure which account the client uses, sign in to the panel again and obtain the current subscription instead of mixing old configurations from different accounts.

Understanding Traffic Statistics and Unexpected Usage

Traffic may be consumed by system updates, cloud sync, video caching, file downloads, backups, and background apps. When usage rises, first check whether global interception is enabled and whether background tasks are running through the route. With a shared account, inspect recent activity on each device. Do not immediately change the password and wipe every client. Pause high-traffic tasks, see whether usage stops, and restore them one at a time.

In global mode, more system and app requests enter the route; rule mode handles only matching traffic. The two modes therefore cover different amounts of traffic. Operating-system updates and cloud-drive sync can continue while no window is open, so check the taskbar, menu bar, system downloads, and background activity. Mobile photo backups may also start automatically after connecting to Wi-Fi.

If there is unexplained ongoing usage, change the account password first, obtain the subscription again from the user panel, and update the devices you control. Include the time range when the unusual usage was noticed, the devices involved, and the main tasks in the ticket. Do not send a complete subscription link. Support can use these details to check account records and subscription status, but “traffic decreased” alone cannot identify which device or program generated the requests.

Handle Payments, Refunds, and Connection Issues Separately

UQVPN supports Alipay / WeChat Pay / USDT and offers a 60-day no-questions-asked refund. Describe payment status, plan status, and technical connection issues separately. Payment completed but no subscription appears in the panel is an order or synchronization issue. A valid panel subscription with a client that cannot connect is a technical troubleshooting issue. An account problem on the destination service is not a plan-status issue. Mixing these topics in one ticket makes verification harder.

After a payment or upgrade, check the order and plan status in the user panel first, then update the client subscription. Do not submit the same order repeatedly or purchase across multiple devices as a test. If the connection works through another route, you can still submit the original route issue separately. If every route continues to fail, include an account-status screenshot, the client message, and the local-network comparison before moving to the ticket process in the next chapter.

When to Contact Support and What to Include in a Ticket

Support can verify account status, review a specific route, analyze client errors, and determine whether further action is needed. Complete the minimum checks before submitting a ticket to avoid repeated questions, but do not perform high-risk actions in the name of self-service. Deleting all configurations, resetting the entire system network, disabling device protection, or publishing subscription content is not required before contacting support.

When to submit a ticket directly

Submit a ticket when every device fails to establish any route across different local networks despite a normal account and subscription status; one route keeps failing under repeatable conditions while others work; a subscription still cannot update after being obtained again from the user panel; the client repeatedly shows a clear, reproducible error; a monthly subscription or traffic package differs from the user-panel record; or a device shows a message inconsistent with the unlimited-device policy. These cases have a defined fault boundary and are ready for support review.

You may also submit a ticket when only one destination website fails, but first show that ordinary websites work and record the URL, steps, and route region. Support cannot control the destination’s account, maintenance, or content policies, so the ticket should focus on whether the route or request path is abnormal. If only one app fails, include the same-device browser comparison, the result after restarting the app, and the client’s traffic-interception mode.

Security-related anomalies should also be reported promptly, including subscription content that clearly differs from the panel, persistent unexplained traffic usage, or an unexpected change in client permission prompts. Change the password and obtain the subscription again before submitting the relevant records. Do not include passwords, complete subscription addresses, payment credentials, or usable authentication information in screenshots or logs.

A support ticket structure that can be acted on

Write the symptom and platform directly in the title, such as “macOS cannot restore the connection after waking” or “Android background connection stops after screen lock.” Avoid titles like “doesn’t work,” “very slow,” or “please fix.” Start with the expected result, then describe the actual result, followed by the steps in chronological order. A clear ticket includes the platform, client status, local network type, route region, destination, first occurrence, whether it reproduces consistently, comparison tests already performed, and the exact error text.

Use the template below. Replace the bracketed text with your own description, and do not enter a password or subscription address:

Issue title: [Platform] + [Reproducible symptom]
Expected result: The specific task that should work after connecting
Actual result: The interface message and where the failure occurs
Local network: Wi-Fi / wired / mobile network
Route details: Region name and route type
Scope: All apps / browser / single app
Comparison results: Changes after switching networks, devices, or routes
Actions taken: Disconnect and reconnect, update subscription, check permissions
Attachments: Redacted screenshots, exact error text, necessary logs

Time information helps correlate events before and after the log entry, but there is no need for a complex format. Just make the order of events and approximate time period clear. Screenshots should include the full window context rather than only one error word. Also redact sensitive parts of the username, subscription address, and payment information. Before submitting a log file, search it for tokens, passwords, or complete links. If unsure, submit the exact error text and action sequence first and let support tell you what else is needed.

Minimum evidence for different symptoms

How to continue troubleshooting after submission

Keep the test conditions reproducible after submitting a ticket. If support suggests switching routes, updating the subscription, or changing permissions, perform one action at a time and report the result instead of completing every suggestion and replying only “still not working.” State what changed, whether the result changed, and whether a new message appeared. This lets support continue narrowing the fault tree.

If the issue temporarily recovers, explain exactly which step preceded the recovery. If it recovers without any change, record the recovery period and continue observing; this can help determine whether it relates to a local network, route path, or brief change at the destination. If switching routes fixes it, keep the original route name. If switching networks fixes it, state the original and new network types. If restarting the app fixes it, consider an old session or app cache first.

Contact support through the Support and Ticket Portal. Logged-in users can also submit a ticket directly from the user panel. For routine usage questions, first check Frequently Asked Questions and the Beginner VPN FAQ. The conclusions in this guide should always remain verifiable: symptom, conditions, comparison, change, and result. When all five are recorded, even an unresolved issue has become a technical record that can be acted on.