VPN Troubleshooting Guide

DIAGNOSIS / Define the failure boundary

Build a reproducible troubleshooting baseline

Describe the symptom before guessing the cause

Effective troubleshooting starts with observable symptoms. Do not conclude that a route is broken based on a vague impression; record whether the client is disconnected, connecting, or connected; whether the issue affects every site or one service; whether the browser and standalone apps behave the same; whether switching networks changes anything; and whether the same subscription works on another device. The more specific the symptoms, the easier it is to identify whether the issue lies with the local network, client settings, name resolution, routing, the destination service, or the account.

Start with one minimal test cycle: keep the same device, client, and network, and change only the route. Then keep the same route and change only the network. Change one condition at a time and record the result. If you reinstall the client, switch networks, reset system settings, and change routes all at once, even a temporary fix will not reveal which step worked, leaving you to start over next time.

Break the connection path into separate layers

A cross-border connection can be understood as a sequence of the local network, name resolution, the client process, tunnel establishment, system routing, the remote route, and the destination service. Opening a local site only proves that part of the local network is working; a connected status only proves that the tunnel has been established, not that every app uses it; and a destination page showing its own regional or account notice does not mean the route cannot transmit data. Mixing these layers leads to unnecessary actions.

Look for the last component that is still working. If the client cannot even load its login screen, check the local network and system time first. If it can update the subscription but cannot connect, inspect the configuration, protocol, and route. If it is connected and some addresses work directly but domains do not open, prioritize DNS. If the browser works but one app fails, investigate app proxy settings and routing rules. This order is more reliable than repeatedly clicking reconnect.

Prepare a clean comparison environment

A comparison environment does not require complex tools. Close programs that modify the proxy, DNS, filtering rules, or network interfaces; temporarily disable browser proxy extensions; and confirm that the system proxy has no leftover manual address before reopening the QhVPN client. Corporate, campus, and public networks may use an additional authentication page. If the browser has not completed that network’s own sign-in, the tunnel usually cannot establish correctly. Disconnect the accelerated connection first, confirm that ordinary pages load in the browser, and then continue testing.

Keep the system clock synchronized automatically. Certificate validation depends on the correct time, and clock drift can appear as failed subscription requests, a blank login page, or a failed connection handshake. If a problem appears after waking from sleep, fully quit and restart the client instead of merely closing its window. Some clients remain active in the background after the window closes, so old interfaces and processes are not actually released.

Keep evidence, not just error screenshots

Screenshots should show the client status, route name, and complete message, but never expose credentials or subscription content. If the client can copy diagnostic logs, capture the relevant section before and after the failure; if the log is long, keep the original file and note the approximate time in the ticket. For web errors, also record whether the domain resolves, whether other browsers behave the same, whether a private window works, and whether clearing site data changes anything.

When troubleshooting is complete, record the actions that did not help as well. This prevents support from repeating the same steps and helps the route team focus its checks sooner. If the issue appears only at specific times, record the time period rather than saying simply that it is often slow. If it affects only a particular app, name the app, platform, routing mode, and whether background networking is allowed. A clear baseline is the common starting point for every section that follows.

CONNECTION / Tunnel not established

Cannot connect: check from the local network to the route

The client stays on Connecting

Remaining on Connecting usually means the client has sent a request, but the handshake, system network interface, or remote route has not completed its response. Cancel the connection, wait until the status fully returns to disconnected, and start again. Repeated rapid clicks can overlap requests and leave the interface showing an old state. Then switch to a route in a different region and test again. If only one route fails, record its name and use another route instead of immediately reinstalling the entire client.

If every route stalls at the same stage, disconnect and reconnect the current network and confirm that ordinary pages are accessible. Then fully quit other proxy tools, network filters, packet-capture tools, and corporate security clients. When multiple programs create virtual network interfaces, the system may assign the default route to the wrong interface. Closing a window may not end a process; use the system task manager to confirm that related processes have exited, then restart QhVPN.

The client fails immediately

An immediate failure is more likely to indicate an unusable configuration, an expired subscription, insufficient local permissions, or connection parameters that the client did not read correctly. First run a subscription update and determine whether it says “update succeeded but connection failed” or whether the subscription itself cannot be updated. These branches lead to different sections. If the subscription updates, check that a valid route is selected. If the list is empty, names look wrong, or the configuration is clearly incomplete, go directly to the subscription-update section.

On desktop systems, creating a network interface for the first time may require system authorization. If authorization was previously denied, reinstalling may not restore it automatically. Check the relevant permissions in the system network or privacy settings, then restart the client. Linux environments should also confirm that the client process has permission to create a tunnel interface and modify routes. Do not permanently use elevated privileges to bypass the issue; complete the one-time authorization requested by the client and confirm that the installation came from the QhVPN user panel.

What recovery after switching networks tells you

If the same device and route work on another network, the client configuration and account are probably usable, and the issue is concentrated on the original network path. The original network may still require its authentication page, restrict certain connection methods, have abnormal DNS, or retain an old session on the router. Disconnect the accelerated connection, open an ordinary page in the browser so the network sign-in page can fully appear, complete authentication, and then reconnect in the client. On a home network, restart the router through its normal process and test again only after ordinary connectivity has fully returned.

If only a public network is affected, do not repeatedly change the entire system. Try another route or choose a connection method in the client that is compatible with the current network. After making a change, retest the same destination page so cached content is not mistaken for recovery. Follow the stated usage rules on corporate networks; do not attempt to evade their access policies.

When to switch routes and when to reset interfaces

The correct order is to switch routes first, restart the client second, and reset system networking only last. Switching routes is the lowest-cost step and the easiest way to identify a single-route issue. Restarting the client can release leftover processes and routes. A system network reset affects saved networks, DNS, and other software settings, so leave it until the end and make sure you know how to restore the original settings. Broad resets without evidence often introduce new variables.

On Windows, first clear the name-resolution cache and network socket state, then restart as prompted by the system. Run the commands in a terminal with the required permissions:

ipconfig /flushdns
netsh winsock reset

If every route still fails after restarting, collect the client error, current network type, reproducible time period, and routes tested before submitting a ticket. If only one route fails, use another available route and name the affected route in the ticket so support can inspect it separately.

RESOLUTION / Connected but inaccessible

Connected but pages will not open: check DNS and routing

First distinguish a domain failure from a transport failure

If the client shows Connected but the browser says it cannot find the server, the domain may not have resolved correctly. If the page loads until it times out, the issue may involve routing, the route, or the destination service. Both look like a page that will not open, but they require different responses. Test several unrelated sites, then try another browser or a private window. If only one site fails, do not immediately blame the whole connection; it may be under maintenance or affected by account verification, regional policy, or browser cache state.

A name-resolution failure usually affects multiple domains at once, although cached pages or some standalone apps may still work. A transport failure can occur after the domain resolves but before the page connection is established. If client logs mention resolution, a name server, or query timeouts, prioritize DNS. If they mention a reset connection, no response from the remote side, or an unreachable route, return to the route and system-routing checks.

Clear old resolution results from the system and browser

The system, browser, and apps may all store DNS cache entries. Clearing only one layer may leave an old result in use. Fully quit the browser first, clear the system cache, and reopen it. On Windows, use the cache-clearing command shown earlier. On macOS, run the following command in Terminal; the system will request local authorization:

sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder

On Linux environments that use systemd-resolved, run:

sudo resolvectl flush-caches

No output after a command does not necessarily mean it failed. Reopen the browser and first visit a page you have not opened before to avoid hitting its internal cache again. If only one browser is affected, check its secure DNS, proxy extensions, and site-data settings. A browser’s built-in resolution strategy may bypass the system path or conflict with the way the client takes over DNS.

Check for leftover system proxy settings

Some clients use the system proxy, while others use a tunnel interface. After switching connection methods, the system proxy may retain an old address. The client may appear connected while the browser continues sending requests to a local port that no longer exists. Open the system network proxy settings and confirm that the automatic proxy script, manual proxy address, and exception list match the current client requirements. If unsure, disconnect the client, restore the system proxy to normal direct access, prove that ordinary pages load, and let the client take control again.

Browser extensions can also change the proxy independently. During troubleshooting, temporarily disable similar extensions, especially those that switch routes by site or apply proxy rules. If a private window works but a regular window does not, check extensions, cache, and site data first rather than reinstalling network drivers. If every browser fails while command-line tools and other apps work, check the network components shared by the system proxy and browsers.

A DNS leak warning is not the same as a DNS failure

If a DNS test page shows a resolution exit that differs from expectations, that is a question about the resolution path; if pages cannot open at all, that is an availability failure. The former calls for checking the client’s DNS handling and routing policy, while the latter requires restoring basic resolution first. Do not adjust many advanced rules while pages are inaccessible. Validate the basic connection with the client’s default settings, then restore custom DNS, routing rules, and filtering one at a time.

If you manually configured system DNS, record the original settings and temporarily switch back to automatic assignment before reconnecting. A custom resolver may be unreachable on the current network or may compete with resolution inside the tunnel. If restoring automatic settings fixes the issue, the fault is in the custom resolution chain rather than the account or route. Reconfigure within the client’s supported options and verify each change separately.

When to hand the issue to support

If multiple devices on different networks cannot resolve domains through the same regional route, but switching to another region immediately restores access, submit the affected route name, test domains, platform, client status, and time period. If every route shows the same issue while ordinary networking and subscription updates work, include the resolution error and client logs. Do not send the full subscription; support needs troubleshooting context, not usable access credentials.

THROUGHPUT / Speed and congestion

Slow speeds and peak-hour congestion: separate the variables

First determine whether the issue is slow downloads, slow response, or playback buffering

“Slow” can describe several different symptoms: a long wait before a page opens, consistently slow file transfers, frequent video buffering, or sluggish interactive apps. Initial page load is more affected by latency and DNS; sustained transfers depend more on route throughput, the local network, and the destination server; and video is also affected by platform region, account status, quality policies, and caching. Describe the specific action first so you can choose a suitable route.

Do not run system updates, cloud sync, video playback, and large file transfers at the same time as a speed test. Other devices on a home network may also consume the uplink. Stop background tasks, run a comparison on the ordinary network, then connect QhVPN and test the same destination. The goal is not to chase a fixed number, but to identify whether the bottleneck is local access, the accelerated route, or the destination service. The facts do not promise a fixed test result, so one measurement should not be treated as a long-term performance guarantee.

Choose routes by purpose, not just by region

For websites and AI Tools, stable response and continuous sessions often matter most; large downloads depend more on sustained throughput; and Streaming also requires checking how the target platform identifies the route’s region. A nearby route usually has a shorter path, but it is not guaranteed to be faster on every network or at every time of day. QhVPN covers 90+ countries / 200+ routes. For comparison, test a small number of representative regions instead of cycling through the entire list at random.

Choose a geographically nearby route as the baseline, then test the region where the target service is located or a route labeled for the client’s intended use. After each switch, wait for the old connection to disconnect completely before starting a new test. Previously buffered browser content and app sessions can distort the result, so refresh the page or restart the target app after changing routes. If an old session still uses the previous exit, it may appear that switching routes changed nothing.

Peak-hour issues require comparisons across time periods

If buffering occurs only during peak evening hours and normalizes at other times, the cause may involve the local carrier network, shared access, or congestion along the international path. During the affected period, keep the same device, network, and destination, test routes in different regions in sequence, and record which type restores access. Repeat the same test the next day outside peak hours. This record separates persistent failures from time-based congestion and helps support decide whether route adjustments are needed.

Do not repeatedly reinstall the client during peak hours. The installation files have not changed, so reinstallation normally will not improve congestion on a shared network. More useful steps are to reduce simultaneous transfers, switch route types, use a stable wired or higher-quality wireless connection, and close sync programs that continuously upload. Unstable Wi-Fi causes retransmissions and can look very similar to congestion on the remote route.

How to assess streaming buffering separately

If Streaming opens but playback buffers, first confirm that the platform shows no account or regional notice, then lower the playback quality and see whether playback remains continuous. If low quality is stable but high quality keeps buffering, the issue is more likely throughput. If the page directly says the content is unavailable, the issue concerns regional identification or content licensing, not ordinary speed. Try a route suited to the target region and fully quit and reopen the app.

When browser playback and the native app behave differently, check whether routing rules exclude the app and whether the system restricts its background network access. See the app-routing section for related checks. Platforms such as Disney+ may also retain account-region and cache information, so a new session is needed after switching routes. Use the unblocking support page to compare the scenario, but do not mistake changes in the platform’s own catalog for a connection failure.

How to assess slow AI Tools

When an AI service opens but generation pauses, first distinguish a network dropout from an expired browser session or server-side queueing. If refreshing loses the login state, check whether switching routes changed the exit. If only one tool is affected while other international sites work, check the target service status and account notices first. Frequent route changes alter the session path and can trigger reauthentication.

For a continuous session, choose one stable route and keep it instead of optimizing only for the lowest momentary latency. For the usage environment of Cursor, Claude, and similar tools, read the AI Tools access guide. If only one tool is affected, include its name, web or app entry point, route region, and error text in the ticket instead of writing only “AI is slow.”

STABILITY / Session continuity

Frequent disconnects and mobile background dropouts

Does the disconnect follow a specific action or occur at random?

For frequent disconnects, first look for a trigger. Disconnecting after locking the screen, after switching from Wi-Fi to a cellular network, after waking from sleep, or after a long idle period points respectively to background restrictions, network switching, system-interface recovery, or keepalive behavior. If disconnects also occur randomly during continuous foreground use, suspect the route, local signal, client process, or conflicts with other network tools.

What was happening immediately before the disconnect matters more than the error afterward. When the network changes, the original connection path is gone and the client must establish a new tunnel; a brief reconnect is expected. The cases that need attention are a reconnect that never completes, a failure after every screen lock, or every route exiting after the same action. Documenting these patterns quickly narrows the scope.

Background management on iOS and Android

Mobile operating systems may reclaim background activity under battery-saving policies. In system settings, allow the QhVPN client the background network access it needs and keep it out of strict sleep or deep battery-saving lists. Menu names differ by manufacturer; look under battery, background activity, app launch, or network permissions. After adjusting the settings, restart the client, establish a connection, lock the screen, and test again during normal use.

Do not enable multiple VPN configurations at the same time. The system can assign the active connection to only one configuration, while another network tool, corporate profile, or security app may take over the interface. Open the system VPN settings and inspect the active item. Remove unused old configurations only when their source and purpose are clear; otherwise disable them first so the work environment is not affected.

Recovering after desktop sleep

When Windows, macOS, or Linux wakes from sleep, the physical network interface may have changed while the client retains an old route. Wait for ordinary networking to recover, then disconnect and reconnect in the client. If the interface is stuck in an old state, fully quit and reopen the client. In environments with frequent sleep cycles, you can enable the client’s automatic recovery or startup option, but do not use multiple system scripts to launch the same process repeatedly.

If every wake cycle requires a system restart, the issue may extend beyond the client. Check whether the wireless adapter also loses connectivity, whether the system clock is synchronized, and whether other network apps work. If only QhVPN is affected, keep the client logs from after wake. If the entire system network is affected, repair the local interface first and test the accelerated connection afterward.

Wireless fluctuations and route drops

Brief packet loss on a wireless network can make the tunnel renegotiate. If moving closer to the access point restores service or a wired connection is stable, the local wireless link is the main variable. Public Wi-Fi may also periodically require reauthentication. After authentication expires, the client may still show Connecting even though the underlying network can no longer transmit. Disconnect QhVPN, complete the network’s own sign-in in a browser, and reconnect.

If the local signal is stable but one route disconnects repeatedly, compare another route in the same region or a nearby region. If routes in several regions disconnect on the same network but remain stable after switching networks, focus on the original network. If different devices, networks, and routes all disconnect in the same way, submit a ticket so support can inspect the service-side status.

What to include in a stability ticket

Stability issues need a timeline. State what you were doing before the disconnect, whether the client reconnected automatically, whether the exit changed afterward, whether other apps lost connectivity at the same time, and whether the issue appeared in the foreground, during screen lock, after sleep, or during a network switch. Logs should cover the period before and after the disconnect, with access credentials hidden. “It keeps disconnecting” alone does not let support distinguish background reclamation, local signal problems, and route sessions.

SUBSCRIPTION / Configuration retrieval path

Subscription update failed: check login, time, and cache

First confirm where the subscription comes from

Get the client and subscription from the QhVPN user panel, not an unverified static address. Use the username and password created with the account to enter the panel. QhVPN does not require an email address; a username and password are enough to create an account. If the panel opens but the client cannot update, account authentication and the client’s subscription request are on different paths. If the panel also refuses access, first verify the username, password, system time, and ordinary network.

Never paste the full subscription into a public page, group-chat screenshot, or ticket title. A subscription is an access credential. When support needs to investigate, report only whether the panel opens, the update error text, the platform, and the client source. If you suspect the subscription was exposed, regenerate or reset it through the panel if that function is available instead of forwarding the original again.

How to distinguish an update timeout from an authentication failure

An update timeout usually means the client did not complete the network request, possibly because of the local network, system proxy, DNS, or an old connection. An authentication failure is more likely related to the login state, subscription status, or unusable request data. Disconnect the current accelerated connection, open the user panel on the ordinary network, then fully quit and reopen the client before updating. If the page requires a connection, choose a route that is currently stable instead of using a failing route during the update.

An incorrect system clock can cause secure-connection validation to fail. Enable automatic time and time zone, then test again. A browser opening the panel does not mean a standalone client uses the same proxy and certificate environment. If the browser works but the client update fails, inspect leftover system proxy settings, security-software network filtering, and client permissions.

The subscription updates, but the route list does not change

This usually means the client is still showing a cached configuration or the new configuration has not been made active. Confirm that the client reports a completed update, then switch to the updated configuration and reload the route list. Some clients refresh only after returning to the home screen or restarting. Do not import several copies of the same subscription; identical names with different update times can leave you connected to an older copy.

Before cleaning up, identify the configuration currently in use and delete only clearly duplicated old entries. If you cannot tell, export the client log or capture the configuration name before making changes. Reinstalling clears local data and should be a last resort. Before doing so, make sure you can re-enter the user panel to obtain the QhVPN client and subscription again.

Traffic status and update results

Monthly-plan traffic resets each month on the activation date, and the upgrade price difference is prorated into the remaining days. If the panel shows unexpected traffic or plan status, refresh the panel and sign in again before updating the client subscription. The client may be showing an earlier cached value, so do not judge account status from old local data alone. Traffic packs remain valid until used up and never expire; the panel is the source of truth for their status.

Plans include ¥9.9/month with 60GB, ¥18/month with 250GB, and ¥28/month with 500GB; traffic packs include ¥158/300GB, ¥358/1000GB, and ¥658/3000GB. Compare plan details on the Plans page. If payment is complete but the panel has not refreshed, do not create duplicate orders; keep the order status shown in the panel and ask through a support ticket.

Security boundaries for manual imports

Subscription URLs in guides should use obvious dummy values. For example:

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

This address only illustrates where the field goes and cannot establish a real connection. Obtain the actual subscription from the QhVPN user panel. Do not turn the example into a guessed QhVPN path or download a third-party configuration from search results. The QhVPN client is available through the user panel; sign in there to obtain the subscription and client.

Final checks before reinstalling

Confirm that no duplicate configuration is imported, the current configuration is active, the system proxy has no old address, and the client process has fully exited and restarted. Reinstall only if all of these steps fail and you can obtain the subscription again. After reinstalling, import one subscription and test the default configuration first. Restore routing and DNS settings one at a time only after the basic connection works, so you can identify which setting caused the issue.

ROUTING / Per-app paths

An app ignores the proxy: check routing rules and processes

The browser works, but a standalone app does not

This indicates that the basic connection is working and the problem is concentrated in the app’s own network path. A standalone app may ignore the system proxy, use its own DNS, or launch helper processes for updates, login, or media. If only the main program is included in the routing list, helper processes may still connect directly, causing the home page to load while login fails or content cannot load.

Temporarily switch the client to a diagnostic mode that covers all traffic. If the app recovers in that mode, the route itself works and the problem is in the routing rules. If it still fails, check the destination service, account status, cache, and the app’s network permissions. Restore an appropriate daily mode after diagnosis; do not keep a temporary setting indefinitely without understanding its scope.

How routing rules are matched

Rules are commonly matched by domain, address, app, or process. A rule matched earlier may prevent later rules from taking effect. An overly broad custom direct-access rule can exclude domains that should use the accelerated route. If rules cover only the main domain, other domains used for login, images, APIs, or media may still connect directly. Disable custom rules first, validate with the client’s defaults, and restore rules one at a time.

Do not copy large, unauditable rule sets from the internet. The longer the rules, the harder conflicts are to locate. State the purpose of every new rule and test the affected app and ordinary pages after each change. If a service has both a web version and a standalone app, test them separately to determine whether the issue comes from process matching rather than the route region.

The app suddenly stopped working after an update

An app update may change the executable path, helper-process name, or network component, so an existing process rule may no longer match. Check that the saved app path in the routing list still exists and select the app again from its current installation location. Do not guess process names manually; use the system task manager while the app is running to observe the actual related processes.

If the app uses a sandbox or a system service to send requests, selecting only its app icon may not be enough. First use system-level tunnel mode for verification. If system-level mode works but process mode does not, state the app name, platform, routing mode, which pages open, and which actions fail in the ticket. Support can then determine whether additional routing guidance is needed.

Browser extensions conflicting with the system proxy

Browser extensions can override QhVPN’s system proxy settings. Signs include different behavior between regular and private windows, only one affected browser, or an unchanged browser exit after switching routes. Disable proxy extensions, close every browser window, reopen the browser, and check the exit again. If other network tools are running, quit them all to create a single clean comparison environment.

Some apps read proxy settings once at launch and do not update them while running. After switching routes, fully quit and reopen the app. Closing only its interface while leaving a tray process active may let the old connection continue. Check the system process list to confirm that the related process has disappeared.

Differences between AI, streaming, and developer tools

AI web apps often include login, API requests, and persistent sessions; Streaming includes pages, authorization, images, and media transfers; developer tools may send requests separately from a terminal, editor process, and plugin processes. One simple domain rule cannot cover them all. Troubleshoot by the failed action: login page, content list, playback, model response, extension marketplace, or API call.

For Cursor or Claude issues, see the AI Tools access guide. For iOS client access and regional restrictions, read Best VPN for iPhone; for Android background persistence and per-app proxying, read Android VPN hands-on comparison. These articles cover specific platforms; this section focuses on identifying the network path.

What to provide for an app-routing issue

Provide the app name, platform, failed action, routing mode, route region, whether the web version works, whether global diagnostic mode works, and whether anything changed after an app update. Screenshots should show the complete error while hiding private account information. If you can identify the process, include its name; do not upload configurations from unknown sources.

ACCOUNT & SUPPORT / Account status and escalation

Device alerts, account checks, and support tickets

How to assess a “device limit exceeded” message

QhVPN supports unlimited devices, so a device-limit or similar message should not first be treated as a fixed device cap. Confirm whether the message comes from the QhVPN user panel, the QhVPN client, or a third-party client’s own local notice. Third-party tools may impose their own limits on configuration count, active connections, or local imports; that does not mean the service plan limits the number of devices.

Then check whether the same configuration was signed in multiple times, whether the client retained an old account state, and whether the plan shown in the panel is valid. Fully quit the client, sign in again, and update the subscription. If the message appears only in one client while other supported platforms work, record that client environment and the complete message. If the panel and multiple platforms show the same issue, submit a ticket so support can check the account.

Keep account status separate from local cache

The panel is the primary place to check plan, traffic, and order status; the client may show a cached value from its previous update. Monthly-plan traffic resets each month on the activation date, and the upgrade price difference is prorated into the remaining days; traffic packs remain valid until used up and never expire. When statuses differ, refresh the panel, sign in again, and update the client subscription. Editing a local traffic field will not fix the display or change the actual account status.

After a plan change, keep the order status and allow the panel to refresh normally. If the status remains inconsistent, submit the order details through the panel ticket entry. Payment methods are Alipay / WeChat Pay / USDT. Do not send a payment password or complete access credential; provide only the order identifier visible in the panel, payment method, payment status, and issue description.

When to stop troubleshooting on your own

If the issue reproduces across different devices and networks, behaves the same on routes in multiple regions, ordinary networking and system time are normal, and the subscription updates successfully, stop reinstalling repeatedly. The main locally verifiable variables have been ruled out. Continuing to clear system settings only increases the scope of change. A single-route issue, account-status problem, unsynced order, or identical errors across platforms is suitable for a support ticket.

Conversely, if only one device is affected and another device works, continue checking that device’s client, permissions, leftover proxy settings, and network interface. If only one network is affected, check its authentication and routing. If only one destination service fails, review its page message and account status first. A support ticket does not replace basic comparison tests; it handles a problem whose boundaries are already clear.

What a support ticket should contain

State the symptom and platform directly in the title, such as “Multiple domains fail to resolve after connecting on macOS” or “Connection does not recover after locking the screen on Android.” In the body, include the platform, client source, current network type, affected route, time period, reproduction steps, complete error text, comparison results from other routes and networks, and the actions already tried. If the issue involves a target app, add its name and the failed action.

Attachments may include screenshots with private details hidden, client diagnostic logs, and a necessary screen recording. Logs should cover the period before and after the failure, and screenshots should include context rather than one isolated error word. Do not attach the full subscription URL, password, or usable access credentials. Use the user panel’s support ticket system as the contact channel.

Symptom:
Platform:
Client source:
Current network:
Route name:
Time period:
Reproduction steps:
Exact error text:
Results with other routes:
Results after switching networks:
Already tried:
Attachment details:

Add evidence based on the issue type

For a complete connection failure, include the connection stage and comparisons across multiple routes. For inaccessible pages, state whether the domain fails to resolve or the connection times out, and whether multiple sites are affected. For speed issues, name the target task and time period instead of providing only an isolated speed-test image. For frequent disconnects, provide the trigger and reconnect result. For subscription issues, state whether the panel accepts login, the exact update error, and the system time status. For app-routing issues, include the result under global diagnostic mode and the default rules.

Submit order or refund requests through the user panel. QhVPN offers a 30-day no-questions-asked refund; follow the site terms and panel process for the specific request. Use the Plans page for current plan and traffic-pack pricing and periods rather than search caches or old screenshots.

Regression testing after the fix

After support recommends an adjustment, return to the original reproduction conditions instead of changing the device, network, and app and merely confirming that it works now. Test the original route or app first, then a comparison target, and confirm that connection, DNS, routing, and the destination service all recover. If the solution involves removing custom rules, restore them one at a time and retest after each change until you identify the conflict.

Record the action that actually worked and delete duplicate configurations created during troubleshooting. Restore the system proxy, DNS, and background policies to a clear, maintainable state. Keeping many temporary rules makes the next issue harder to locate. Complete troubleshooting does not end when a page opens temporarily; it ends with a conclusion that can be reproduced, explained, and verified again.