VPNQY Troubleshooting Guide

Build a Repeatable Baseline First

The most common troubleshooting mistake is not missing a hidden switch, but failing to identify which layer is affected. A connection involves the local network, client, subscription configuration, selected route, DNS resolution, and destination service. An issue at any layer may look like “the site won’t open” or “everything is slow.” If you reinstall the client, change protocols, edit DNS, and switch routes at the same time, even a successful recovery will not reveal the real cause. The next occurrence will still require starting over. This guide therefore uses one-variable comparisons: record the current state, change one item per round, then retest the same page or app.

Turn the Symptom into a Testable Statement

Do not simply write “the VPN does not work.” A useful description includes the platform, stage, route, and observable result. For example: “The Windows client imports the subscription, and the Tokyo route shows connected, but the browser cannot open any new page”; or “iOS works normally in the foreground, but requires reconnection after returning from the lock screen.” The first points toward routing or DNS after the tunnel is established; the second points toward mobile background management. The more specific the description, the more useful each comparison becomes. Preserve error messages exactly instead of paraphrasing them: “timeout,” “authentication failed,” “name resolution failed,” and “invalid configuration” point in different directions.

Before testing, confirm that the ordinary network works without a connection. Disconnect, open a website that normally works, then try another site to rule out a single-site issue. If ordinary access also fails, fix the Wi-Fi, Ethernet, system network settings, or upstream network first. A client cannot replace a functioning base network. Public networks may also require portal confirmation in a browser; the device can appear connected to Wi-Fi while still lacking external access. Open any ordinary webpage, complete the network’s confirmation flow, and then start the client.

Create a Minimal Test Environment

During testing, temporarily quit other tools that rewrite the network path, disable proxy extensions configured separately in the browser, and avoid enabling both a system proxy and an in-app proxy. Do not immediately disable security software or the system firewall; first check for access prompts or blocked-event logs. If the device is managed by an organization, do not remove management settings yourself. Record the policy message and ask the device administrator to confirm. After cleanup, connect through one route and test with a single browser window. If the browser works, restore other apps one at a time to identify where the conflict returns.

VPNQY supports Windows / macOS / iOS / Android / Linux, covering 110+ countries / 150+ routes. The interface differs by platform, but the diagnostic layers are the same. Do not skip the basic checks just because button labels differ. To understand IEPL dedicated routes, transit routes, and direct routes, start with the global routes page. By the end of this chapter, you should know whether the issue is “the connection cannot be established,” “there is no internet after connecting,” “it affects only a specific app,” or “the connection works but performance is unstable.” That distinction is the entry point to the chapters that follow, not a paperwork exercise.

Cannot Connect at All: Start with Permissions, Time, and Routes

“Cannot connect at all” means the client stays on Connecting, quickly returns to Disconnected, or shows a clear authentication, handshake, timeout, or invalid-configuration message. Do not start with browser and DNS checks; the tunnel has not been established. First confirm that the client still recognizes the subscription: is the route list present, are route names complete, and does a subscription update report success? If the list is empty, contains only old entries, or updates fail immediately, go to the subscription update section. If the list is normal, continue by checking client permissions and system time.

Use the Failure Timing as a Clue

A failure immediately after tapping Connect usually points to local configuration, permissions, or formatting. A timeout after waiting is more likely to mean that the current network cannot reach the selected route, the route is temporarily unavailable, or the local network limits that connection method. Select other routes in the same region in succession instead of repeatedly retrying one route. If one route fails while others connect, record it as a single-route issue; reinstalling the client is unnecessary. If every region fails, compare with another trusted network, such as switching from the current Wi-Fi. Success after changing networks suggests that the account and configuration are probably valid, so focus on the original network.

An incorrect system clock can break connections that depend on certificate validity and handshake timing. Enable automatic date, time, and time-zone settings, let synchronization finish, then fully quit and reopen the client. “Quit” means ending the process from its menu on desktop, or removing the current connection before reconnecting on mobile. The first time a desktop system creates a network extension, virtual adapter, or VPN configuration, it may require permission. If permission was previously denied, check the relevant network, privacy, or security settings. Never install certificates from unknown sources or weaken system security merely for troubleshooting.

Clear a Stuck Connection State

After an abnormal client exit, the system may retain a virtual interface, system proxy, or incomplete connection state. On desktop, disconnect in the client, then quit it completely. Check the system VPN or network settings to ensure no other similar connection is still starting. Reopen the client with only one configuration retained for testing. On mobile, disconnect in the client, confirm in the system VPN settings that the session has ended, then reconnect from the client. If the system remains stuck on Connecting, restart the device so network services can initialize again. A restart is not a universal fix, but it can clear residual interfaces and suspended permissions.

If the error indicates an invalid configuration, do not manually edit the server address, port, credentials, or encryption fields generated by the subscription. Manual changes can turn an updateable configuration into an unmaintainable copy. Delete that imported entry, return to the user panel to obtain the subscription again, and follow the import steps on the guide page. The example link is only for understanding the format and must not be used as a real subscription:

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

On managed devices, network extensions may be blocked by organizational policy. Even with a valid account and working routes, a regular user may be unable to authorize them. If the system clearly reports an administrator restriction, stop reinstalling and ask the device administrator which connection methods are allowed. If a personal device fails across multiple networks and regional routes while subscription updates work, collect the client name, platform, route name, failure time, complete error, and steps already tried, then submit a ticket. Do not upload a cropped screenshot without context; it should show the original error and selected route while hiding subscription links, tokens, and passwords.

Once the issue is resolved, restore security software, browser extensions, and other network tools one at a time. If the issue returns after restoring one item, you have found the conflicting condition. Keep system protection enabled whenever possible and adjust only the conflicting app’s network control. For occasional timeouts, record the network and route instead of immediately blaming the client. Before a connection is established, the goal is to distinguish among account configuration, local permissions, the original network, and a single route. Once that distinction is clear, the path to a fix becomes much shorter.

Connected but Websites Won’t Open: Check Routing and DNS

If the client shows connected but the browser cannot open websites, the issue occurred after the tunnel was established. First distinguish between “all network requests fail” and “only domain names fail.” Test a normally accessible website, a different site, and a local app. If every site and app fails, check system routing, proxy interception, and residual connections first. If only some domains fail, or the error explicitly says that the host cannot be resolved, focus on DNS. If the browser fails while other apps work, check browser extensions, the browser’s own encrypted DNS, and differences in system proxy handling.

Rule Out a Leftover System Proxy

Some clients leave the system proxy enabled after disconnecting, while the new connection mode does not use it. Requests then go to a local port that no longer exists. In the client, perform one “disconnect—quit—reopen—connect” cycle so it can rewrite the system state. On desktop, also inspect the proxy settings in the system network panel and make sure an automatic proxy script, manual HTTP proxy, or configuration written by another app is not still active. If you are unsure of the original value, do not enter a random address; disable entries clearly belonging to a tool that has been quit, then retest. Temporarily disable browser proxy extensions so the browser follows system settings.

Routing mode can also produce “connected, but the destination is not going through the tunnel.” Rule mode relies on domains, addresses, and rule sets to choose a path; global mode is better for diagnosis. Temporarily switch the client to global routing. If the webpage immediately works, the route itself is available and the issue is in rule matching or DNS mapping. Restore the original mode after testing, then update the configuration or adjust the destination-domain rules. Do not keep a complex rule set you cannot explain, and do not overwrite the subscription with large configurations copied from unknown sources.

Use One DNS Resolution Path

DNS problems do not only appear as “website not found.” An unsuitable regional address, a stale cached result, or different resolution services used by the browser and system can also cause long waits, blank resources, or failed app logins. Reduce the number of resolution sources during testing: disable encrypted DNS enabled separately in the browser so it follows the system, then confirm whether the client is already handling DNS. If the client handles resolution, do not let multiple security tools rewrite DNS at the same time. After changing settings, close and reopen the browser so old connections are not reused.

On desktop, you can clear the local DNS cache. Run the command in the system terminal; no extra tool is required. Windows:

ipconfig /flushdns

macOS:

sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder

On Linux, the procedure depends on the resolver service in use. If systemd-resolved is active, run:

resolvectl flush-caches

Reconnect to the route and open a new browser window after running the command. If the command says that the service does not exist, do not apply commands from another system; check how the current system manages networking. Mobile devices generally do not need a cache-cleaning app. Disconnect, change networks, and reconnect, or restart the device to rebuild the resolution state.

Check Whether the Destination Site Is the Problem

A single failed website does not mean the whole route is broken. The destination may be under maintenance, restrict certain regions, require a new login, or have cookies that conflict with the previous region. Test other sites first. If they work, open the destination in a private window or clear that site’s own cache and cookies instead of wiping the entire browser. For streaming services, the region may also depend on account details, content rights, and the app-store region; changing the exit location alone cannot change account-side conditions. See Streaming access support for these boundaries.

If the issue occurs only on one base network, compare with another network. Public, campus, and office networks may use their own DNS, portals, or security policies and continue restricting some requests after connection. Recording “fails on the original network, works on the alternative” is more useful than repeatedly switching routes. A support ticket should state whether the domain resolves, whether global mode works, whether other websites work, and whether the browser and app behave the same, along with error details that contain no personal data. Do not submit your full browsing history or place a subscription link in a screenshot or log.

Slow Speeds and Peak-Time Lag: Identify the Bottleneck

Do not judge speed from a single download or one speed-test page. Real-world cross-border access depends on the local connection, wireless quality, route path, destination server, app protocol, and congestion at that moment. A slow first render, video buffering, slow file downloads, and high game latency are different metrics. Downloads emphasize sustained throughput; video also depends on the platform’s delivery nodes; meetings and games are more sensitive to jitter and packet loss. Define the scenario first, then compare the same device, base network, destination, and approximately the same time.

Test the Base Network Before Comparing Routes

Disconnect the client and confirm that the local network itself is stable. A full wireless signal can still suffer jitter from interference, distance, or channel contention. Move closer to the access point, pause syncing and downloads, then test an ordinary webpage and a stable file transfer. If the base network is already slow, switching to a cross-border route will not remove the local bottleneck. When possible on desktop, compare with Ethernet. On mobile, try another trusted Wi-Fi network to see whether the issue follows the original network.

Once the base network is stable, compare different routes to the same destination. Start with a geographically closer region, then test other routes in that region. IEPL dedicated routes, transit routes, and direct routes have different path characteristics, but none can be declared universally faster without considering the user’s location, destination region, and current network. During peak-time lag, try another route in the same region first; if all perform poorly, choose a nearby region rather than switching across continents based only on country names. See global nodes for the full route categories.

Tell Peak-Time Congestion from Site-Specific Throttling

If performance is stable during the day but repeatedly lags during a specific evening period, and the local network is also congested at that time, the bottleneck may be in the access network. If ordinary local access is fine and only one cross-border route slows down, switch to another route in the same region and record the difference. If several regions are slow only for one platform while other websites and downloads work, consider the platform’s delivery network, account region, or content source. Reinstalling the client will not help. Test webpages, video, and files separately to determine whether the issue affects one destination or the entire connection.

Global mode sends more background traffic through the route. Cloud-drive sync, system updates, photo backups, and continuous downloads on other devices all compete for the current network. Pause these tasks during testing and check the system task manager or network monitor for heavy background transfers. VPNQY allows unlimited simultaneous devices, but that does not mean high-volume tasks on multiple devices will not share the user’s own access bandwidth. On a home network, one device downloading continuously can affect video and meetings on another.

Avoid Misleading “Optimizations”

Do not copy MTU, congestion-control, network-adapter duplex, or registry parameters from random online articles. A wrong value can make small packets seem fine while larger packets repeatedly retransmit, creating a difficult partial failure. If you changed such parameters manually, restore system defaults before comparing routes. Choose protocols from the compatibility options provided by the client; a protocol that is faster on one network is not necessarily better on every network. Public networks, home broadband, and mobile networks behave differently, so the most reliable method remains a comparison under identical conditions.

A performance ticket should not simply say “it’s slow.” Include the platform, base network type, time, full route name, target app, whether the slowness is constant or intermittent, whether other routes work, and how the base network performs after disconnecting. Screenshots may show the client route name and error, but speed-test results should identify the target and conditions. Do not directly compare results from different dates, networks, and destinations. Support can distinguish a route, entry point, destination service, or local network only when the conditions are reproducible.

Frequent Disconnects and Mobile Background Dropouts

For frequent disconnects, first determine whether the system paused the connection, the base network changed, or the route itself broke. On mobile devices, locking the screen, switching between Wi-Fi and cellular data, enabling power-saving mode, or moving an app to the background can cause the system to reassess the network extension’s permissions. Desktop devices may disconnect after sleep, network-adapter power saving, network roaming, or security-software interception. If it happens only after locking the screen, focus on background and power management rather than route speed. If it also happens randomly in the foreground, compare different routes and base networks.

On Mobile, Check System-Level Background Conditions First

On iOS and Android, first confirm that the client has the system permissions required to create a VPN configuration. Then check low-power mode, battery-saving policies, background activity, and data-saving features. Interface names vary by system, but the principle is to let the client maintain the network activity needed while connected. Android devices may also restrict background apps after the screen turns off through manufacturer battery management; in the app’s battery settings, choose unrestricted use or allow background activity. Adjust only the current client rather than disabling battery protection for the entire device. On iOS, if the connection remains in an old state after a network change, manually disconnect and reconnect from the client.

When a mobile device switches from Wi-Fi to cellular data, its underlying address and route change. Some connections recover automatically; others need a new handshake. Test while staying on Wi-Fi and cellular data separately to see whether the disconnect occurs only during the switch. Stability on a fixed network points to network transition rather than a persistent route fault. This guide does not discuss communication verification methods; for the account, remember that VPNQY requires no email address: a username and password are enough to create an account.

On Desktop, Check Sleep, Network Adapters, and Security Software

After Windows or macOS resumes from sleep, the physical network adapter may reconnect before the virtual interface, leaving routing incomplete for a short time. If access fails after resume, actively disconnect and reconnect in the client instead of waiting on the old session. On Windows, check the adapter’s power-management settings to see whether the system may turn it off to save power. Confirm that the device is personal and adjust only the adapter in use. On macOS, check for old network extensions or duplicate VPN configurations so multiple tools do not compete for control of system networking.

Security software, firewalls, and endpoint-management tools may reapply rules when the network type changes. If disconnects always follow a switch from private to public or wired to wireless, inspect the relevant event log instead of disabling protection. Allowing the client to access the network is generally safer than turning off the entire firewall. Administrators should handle rules on managed devices. If logs show an interface reset, network unreachable, or permission denied, include the event and time in a support ticket.

Use Continuous Observation to Separate Route Issues from Local Jitter

After choosing a route, keep the app in the foreground, do not change networks, and maintain a lightweight connection to a stable webpage. If it still disconnects, test another route in the same region. A disconnect on only one route is a single-route issue. Multiple routes failing on the same base network but working after a network change point more strongly to jitter or restrictions on the original network. Only when multiple networks and routes fail should you continue checking client installation, system permissions, and configuration. This matrix provides more diagnostic value than repeatedly tapping Connect.

If the connection appears active but an app suddenly stops transferring, distinguish between “the tunnel disconnected” and “the app session expired.” Video, meeting, and real-time sessions may need to be re-established after an exit-location change; fully close and reopen the relevant app after switching routes. A browser page can be refreshed, but save anything being uploaded or edited first. Do not switch routes repeatedly during an important transfer. For long-running tasks, use a route already proven stable and prevent the device from sleeping.

A ticket should state whether the disconnect occurred in the foreground or background, whether the screen was locked, whether the network changed, the platform, route, original network type, client status, recovery method, and exact error. If it can be reproduced, write the sequence as “connect—lock screen—return—observe.” Do not upload a full-screen recording containing account passwords, subscription tokens, or private notifications. A cropped recording or screenshot that still shows the state change is usually more useful than saying “it always disconnects.”

Subscription Update Failures and Abnormal Route Lists

Subscription updates synchronize the configurations currently available to the account with the client. Failures include update timeouts, format errors, empty route lists, old routes that will not refresh, or an import that produces no entries. First distinguish between “the subscription content cannot be retrieved” and “it was retrieved but the client cannot parse it.” The former usually appears as a network error, timeout, or authorization failure; the latter more often reports an invalid format, unsupported field, or damaged configuration. Never paste a subscription link into a public website or send it to someone else for testing; the link itself is an account access credential.

Confirm the Account Status and Import Source

First confirm the current subscription status in the user panel, then obtain the subscription entry point again from the panel. VPNQY monthly plans are ¥9.9/month with 60GB, ¥18/month with 250GB, and ¥28/month with 500GB; traffic resets monthly on the activation date, and the price difference for a mid-cycle upgrade is converted into remaining days. There are also use-until-depleted, never-expiring data packages: ¥158/300GB, ¥358/1000GB, and ¥658/3000GB. If the client and panel show different statuses, use the account and order status in the panel as the reference. See the plans page for details.

When re-importing, first delete the client entry confirmed to be damaged or from an unknown source, but do not clear every working configuration before obtaining a new entry. When copying the subscription link, make sure it has no extra spaces, line breaks, or truncation. Some chat apps add previews or rewrite characters, so they are not suitable for long-term storage. The safest process is to copy it in the panel and paste it directly into the client. After import succeeds, confirm that the route names appear before testing a connection.

Find Out Why the Update Request Failed

If the client can connect through an existing route but cannot update the subscription, the update request may not be following the current connection path. Disconnect first and open the user panel over the ordinary network; if the panel loads, try the update. If the update fails on the ordinary network but succeeds while connected through an existing route, the two paths have different reachability to the update endpoint. Conversely, if it fails while connected, disconnect and retry. Record the connection state for every test so opposite conditions are not mixed together.

System date and time can also affect the secure connection used by subscription requests. Enable automatic time, restart the client, and try again. If the panel opens in a browser but the client still reports a certificate or network error, check whether security software is inspecting HTTPS, whether a custom certificate is installed, or whether an enterprise policy is proxying the network. Do not bypass certificate errors to complete an update. Start with system time, a trusted environment, and network diagnostics.

Handle Duplicate, Empty, and Old Routes

Importing the same subscription repeatedly may create multiple configuration groups. Switching routes in an old group can then make it appear that “the update did not work.” Check the configuration name and latest update time, and keep only the group in use. If the route list remains empty after an update, fully quit and reopen the client so it rereads the configuration. If some routes still have old names, confirm that the selected configuration group is correct before deleting the old group. Do not manually merge subscription text; doing so can break future automatic updates.

When the client reports an unsupported format, confirm that you are using the import method recommended by the panel and obtain the platform-appropriate client from the user panel’s download entry. The site’s marketing pages do not provide static installer links; all client entry points are managed through the user panel. Import screens differ across Windows / macOS / iOS / Android / Linux; see the quick-start guide for the exact paths. If one platform fails while another imports successfully, the account and subscription are probably valid, making client compatibility, import method, or local networking more likely causes.

When submitting a ticket, include the platform, client name, update time, exact error, whether the panel opens, whether existing routes connect, whether you tested both disconnected and connected states, and whether you copied the subscription again. The subscription link only needs to be shown in a redacted form such as https://example.com/sub?token=YOUR_TOKEN. If a screenshot contains a QR code, token, or full link, redact it before sending. Support does not need the account password and should not request it through a ticket.

One App Cannot Use the Proxy: Verify the Routing Path

If the browser works normally while one app consistently fails to connect, the route itself is usually available and the issue lies in how that app makes network requests. The app may follow the system proxy, use the system network directly, contain its own proxy settings, or use a protocol not intercepted by the current mode. The goal is not to add many rules immediately, but to first prove whether the app works through global routing. If global routing also fails, check the app account, destination status, and regional conditions. If global works but rule mode fails, you can focus specifically on routing.

Move from a Global Comparison Back to Precise Rules

Record the current mode, temporarily switch to global routing, fully quit the target app, and reopen it. Sending an app to the background often preserves its old connection, so end the process from the task list or use the app’s own quit function. If the app works again, one of its domains or addresses is not matched correctly by the current rules. Restore rule mode and check whether the client supports adjustments by app, domain, or rule set. Add the destination service’s official domain range first; do not merge a large rule list from an unknown source into the configuration.

If global mode still fails, visit the service’s official website in a browser to determine whether the destination is reachable at all. If the website works but the app does not, check whether the app needs a refreshed login session, retained an old regional session, or has its own proxy or private DNS enabled. Before clearing the app’s cache, confirm that unsynchronized content will not be deleted. For services tied to account regions, the exit location is only one condition; account details, store region, and content rights remain controlled by the platform.

System Proxy vs. Virtual Adapter Mode

With only a system proxy enabled, apps that follow the system proxy are intercepted, while apps that ignore it may connect directly. A virtual adapter or system VPN mode generally covers more traffic, but requires the relevant system permissions and may conflict with other network extensions. If the target app does not follow the system proxy, test a system-level interception mode if the client supports it. Disconnect before switching modes, then authorize again and reopen the app so an old session does not continue using the previous path.

Some apps use TCP, UDP, local-network discovery, or push channels at the same time. A working webpage does not mean that voice, video, uploads, and notifications use the same connection. Record each function separately: whether login succeeds, text loads, media plays, and uploads complete. If only one function fails, specify that function in the ticket rather than writing “the app does not work.” If the app depends on local devices, confirm after enabling global routing that local-network access is still allowed; otherwise printers, TVs, or storage devices may temporarily disappear.

Additional Boundaries for AI Tools and Streaming

AI tools may evaluate exit region, account status, session cache, and service-side policies together. If the service remains unavailable after connecting, test the official website in a new browser session and verify that the account itself works. Avoid switching regions repeatedly within the same session, as the login state and exit region may become inconsistent. See AI acceleration notes for more scenarios. Streaming services can likewise be affected by account regions, content rights, and app cache; see the access support page for related checks.

When submitting an app-routing ticket, provide the platform, app name, failed function, comparison between rule and global modes, selected route, browser result for the same service, and whether fully restarting the app changed anything. Remove access tokens, cookies, account identifiers, and private content from logs first. Support needs the path difference and exact error, not the app account password. Organize the details as reproducible steps so the issue can be identified as routing, interception mode, or a destination-service condition.

Unlimited Devices, Account Issues, and Effective Support Tickets

VPNQY supports unlimited simultaneous devices, so an “device limit exceeded” message should not lead you to assume a hidden fixed device limit. First identify where the message appears: the VPNQY user panel, the client, the operating system, or the destination website or app. Many services impose their own account-device rules, which are separate from the simultaneous-device capability of a network acceleration subscription. Record the message source accurately to avoid attributing a destination platform’s account restriction to VPNQY.

Identify Which Account the Message Belongs To

If the message appears inside a streaming service, AI tool, cloud drive, or other third-party app, check that service’s own account and device management. Changing routes will not change a third-party device rule. If it appears during client import, check for duplicate configurations, a local limit on configuration entries, or confusion between multiple configuration groups and multiple devices. If the user panel itself shows an account or subscription issue, sign out and back in, verify the current username, order status, and subscription entry, and avoid mixing up multiple usernames.

VPNQY requires no email address; a username and password are enough to create an account. Because the account does not depend on an email address, store the username and password securely yourself. When login fails, check the keyboard layout, capitalization, automatic spaces from the input method, and whether the browser password manager filled in old credentials. Do not create multiple similar usernames to work around the issue; this can scatter orders and subscriptions across accounts. Payment methods include Alipay / WeChat Pay / USDT. For order checks, open a ticket from the user panel instead of pasting payment credentials on a public page.

When to Stop Troubleshooting Yourself

Once an issue is reproducible and the minimum comparisons are complete, submit a ticket instead of reinstalling without a clear purpose. Appropriate cases include: multiple networks and routes cannot establish a connection; the subscription is visible in the user panel but cannot be imported on multiple supported platforms; only one route keeps failing; the same route repeatedly disconnects on a fixed network; rule and global modes differ consistently but the matching rule cannot be found; or account, order, or traffic information does not match the panel result. If only one destination website is briefly under maintenance, wait for that service to recover rather than changing local configuration.

For refunds, the stated policy is a 7-day no-questions-asked refund; requests should be handled through a user-panel ticket after reviewing the refund policy. Do not place duplicate orders, reverse payments, or create multiple accounts for testing. To compare plans, see the plans page for monthly subscriptions and never-expiring data packages. The price difference for a mid-cycle upgrade is converted into remaining days; if the upgrade result looks incorrect, include the original plan, operation time, and panel result for ticket review.

What a Support Ticket Should Include

Start the title with the symptom and platform, such as “Windows: connection times out on every route” or “Android: connection ends after locking the screen.” Fill in the body in this order: platform and client, base network type, full selected route name, time, steps, exact error, whether it is reproducible, comparisons already completed, expected result, and actual result. If only one app is affected, add the app name, failed function, and global-versus-rule results. For speed issues, add the destination service, whether the slowdown is constant, and the results on other routes and after disconnecting.

Issue title:
Platform and client:
Base network type:
Selected route:
Time of occurrence:
Reproduction steps:
Exact error:
Comparisons completed:
Expected result:
Actual result:

Screenshots should retain the client status, route name, and error while cropping out unrelated private notifications. Subscription links, QR codes, passwords, tokens, payment credentials, and app login details must be redacted. If the client exports a log file, inspect sensitive fields in a text editor first. If you are unsure, submit only the exact error and time initially and let support specify the needed excerpts. Do not upload complete system logs or browsing history.

Leave a Reusable Record After Recovery

After resolving the issue, record the final cause and effective action, such as “the original Wi-Fi required portal confirmation first,” “the browser’s encrypted DNS conflicted with client resolution,” “the old configuration group was not updated,” “the target app does not follow the system proxy,” or “power-saving paused the connection after the screen locked.” Also undo any global mode, extra permission, or test setting enabled temporarily, restoring the smallest configuration needed for daily use. If duplicate subscription groups were created, keep the active configuration and delete old copies.

The end of troubleshooting is not “it opened once by chance,” but repeatable normal results under fixed conditions. For connection issues, complete at least one reconnection test; for background issues, verify one lock-and-return cycle; for routing issues, test the browser and target app separately; for subscription issues, confirm that the route list remains normal after updating. If recovery cannot be repeated, keep the time and conditions in the ticket. Systematic records reduce the next troubleshooting session and help route and client issues receive a more accurate response.