VPNRH Troubleshooting Guide

Establish a reliable troubleshooting baseline first

Most network issues have more than one possible cause. The client, current access network, system proxy, DNS, route type, target website, and account status can all affect the result. If you change the client, route, and network at once, even a successful recovery will not show which change worked. The next time the same symptom appears, you will have to start over. A more reliable approach is to record the current state, define the scope of the issue, and change only one variable at a time.

First, turn subjective descriptions into verifiable symptoms. “It does not work” does not guide troubleshooting. Rewrite it as “the client reports a connection failure,” “the client says it is connected, but the browser cannot open any website,” “only one app is inaccessible,” “the page opens but the video keeps buffering,” or “the connection drops after the app goes into the background.” The more specific the symptom, the shorter the diagnostic path. Also note whether the issue is constant or appears only on a particular network, at a certain time, or on a specific route.

Second, define the scope. On the same device, visit a commonly used mainland China website and a website that requires an international route, then check again in another browser or app. If all network access fails, start with the local access network and system settings. If mainland China websites work but international access fails, check the client connection, route, and proxy mode. If the browser works but one app does not, focus on app routing, how the app reads the system proxy, and the app’s own network cache.

Third, save baseline details. Record the platform, the connection status shown by the client, the current route name and route type, the approximate time of the failure, the access network in use, and the exact error text. Do not capture only a red status icon; include the route name, connection status, and complete error message. When showing account pages, hide subscription links, access tokens, usernames, and payment details. A ticket does not need the complete values of this sensitive information.

Retest with the minimum number of variables

The minimum-variable method should move from the external environment toward the client itself. Keep the route and client unchanged and switch only the access network. Then keep the network unchanged and switch only to another route in the same region. Only afterward should you consider changing the protocol or rebuilding the client configuration. This quickly distinguishes “the current network does not allow the connection,” “one route is having trouble,” and “the client’s local state is damaged.” If you click connect repeatedly after each change, the old session may not have been released and the observed errors can interfere with one another. Disconnect deliberately, wait until the client returns to a disconnected state, and then start the next test.

Do not use a large download, speed-test site, or livestream as the only test during a retest. These activities are also affected by target-site throttling, content delivery networks, disk writes, and application buffering, so they cannot directly show whether a route is usable. A better baseline is whether the client completes the connection, whether ordinary websites open, and whether several unrelated sites behave consistently. Once basic access is restored, test video, AI Tools, or long-lived connections.

Check account and traffic status before the network

Before troubleshooting the network, sign in to the dashboard and confirm that the subscription is active. Check whether the monthly subscription traffic has been used up: ¥9.9/month includes 60GB, ¥18/month includes 250GB, and ¥28/month includes 500GB. Monthly traffic resets on the activation date, and an upgrade mid-cycle is prorated by the remaining days. Traffic packages are ¥158/300GB, ¥358/1000GB, and ¥658/3000GB; they remain available until used and never expire. If the account status or remaining traffic does not meet the connection requirements, changing DNS or routes will not solve the issue.

Do not use calendar-month dates to decide whether traffic should have reset; monthly subscriptions reset on the activation date. Do not confuse this rule with traffic packages. If the dashboard does not match your expectations, first save the plan name, page status, and time of the discrepancy, then submit a ticket for verification. Avoid repeated sign-outs or deleting configurations, which can obscure the original state.

Common diagnostic commands without sensitive information

Desktop systems include built-in tools for checking DNS resolution and basic access. The examples below use only public test domains and contain no real subscription links or credentials. A successful command does not prove that every app works, but it helps distinguish DNS resolution failures, connection failures, and browser-specific issues.

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

If nslookup cannot return a result, start with the DNS section of this guide. If resolution works but curl cannot establish a connection, continue by checking the system proxy, client routing, and current route. Some environments do not include curl; you can simply open the test domain in a browser instead of installing an unknown tool for troubleshooting.

The client cannot connect at all

“Cannot connect at all” means the client never reaches a connected state, or immediately returns to disconnected after connecting. Do not start with browser, Streaming, or app-routing checks because the traffic channel has not been established. First determine whether the failure occurs while reading the configuration, resolving the domain, completing the server handshake, obtaining system permission, or accessing the current network. The complete error text is usually more useful than the status color: timeout, resolution failure, authentication failure, invalid configuration, and insufficient permission each point to a different branch.

First distinguish one route from all routes

Without deleting the existing configuration, test another route in the same region. If only one route fails while others connect, the scope is narrowed to that route or its current entry point; reinstalling the client is unnecessary. Use a working route temporarily and include the failed route name, route type, and time of occurrence in the ticket. If several routes from different regions and route types all fail, continue by checking the local network, system permissions, and subscription status.

VPNRH provides 120+ countries / 170+ routes. The routes page explains the different uses of IEPL dedicated routes, relays, and direct connections. During troubleshooting, do not switch repeatedly among routes of the same type. If the current access network is poorly compatible with one connection method, testing another route type provides more diagnostic value. First review server and route details to understand the labels before comparing results.

Change the access network to locate the restriction

Keep the client, subscription, and route unchanged and switch only to another available network. If the connection recovers immediately, the client configuration and account are probably fine; the issue is likely related to DNS, egress policy, a captive portal, or link quality on the original network. Public networks often require confirmation in a browser before access is granted. Until that page is completed, ordinary websites may redirect and the client connection may time out. Disconnect the proxy, confirm in a browser that the local network works normally, and then reconnect.

If the connection fails on multiple access networks, check that the system date is correct, that the client has the system permissions needed to create a network connection, and that security policies are not blocking it. An inaccurate system clock can make certificate checks fail during the encrypted handshake, appearing as a timeout or handshake error. After correcting the date, fully quit and reopen the client to clear the old connection state.

Check system permissions and stale sessions

On Windows and macOS, the client needs to create a system proxy or virtual network interface. On iOS and Android, it requests network-configuration permission the first time a connection is established. If permission was previously denied, the client may still import subscriptions and display routes while being unable to create the actual channel. Open the system network settings and confirm that the relevant configuration exists and can be enabled instead of repeatedly clicking Connect in the client. After restoring permission, close other similar networking tools so they do not compete for the system proxy or virtual interface.

A stale session can also cause a click to do nothing or a connection to drop immediately. The proper sequence is to disconnect in the client, fully quit it, and then check the system network settings to confirm that the old proxy and connection state have been released. Reopen the client and keep only the configuration being tested. Force-quitting a process can sometimes leave a system proxy address behind, causing the browser to become completely inaccessible because traffic is still being sent to a local port whose client has exited. That does not mean the new route is faulty.

Handling authentication failures and configuration errors

Authentication failures are usually not solved by switching routes repeatedly. Confirm the subscription status in the dashboard, then update the subscription in the client. If the error appeared after manually editing the configuration, undo the custom changes and restore the original configuration generated by the subscription. Protocol names, server addresses, ports, authentication fields, and transport parameters are interdependent. Any field replaced by an input method, cut off by a line break, or given extra spaces can make a configuration look complete while preventing a handshake.

If the subscription source was pasted into a public page, chat screenshot, or untrusted tool, reset the subscription in the dashboard and import it again. Do not put the real subscription link in the body of a ticket. Support needs the update status, client error, and route name—not a complete usable link. For tutorials or reproduction, use an obvious placeholder such as https://example.com/sub?token=YOUR_TOKEN.

When to stop local troubleshooting

Submit a ticket when the issue fails on different access networks, the account and traffic status are normal, the subscription has been updated, different route types cannot establish a connection, and system permissions have been confirmed. Continuing to delete system network components or install multiple clients only adds variables. Include the platform, client name, complete error text, failed route, access-network type, troubleshooting steps already completed, and approximate time of occurrence. If only one route fails, state which other route types work; this comparison is more useful than saying that everything was tested.

Connected, but websites do not open, or DNS is failing

A connected status only means that the connection action completed; it does not prove that DNS resolution, the system proxy, and app traffic have entered the channel. When websites do not open, separate the issue into domain access and direct connection status. Common causes include an inactive system proxy, DNS requests still using the original network, a browser-specific proxy, stale cache entries, and client rules sending the target domain through an unsuitable exit.

Determine whether all websites or only a specific domain are affected

Visit several unrelated websites first. If none open and access still fails after disconnecting the client, check the local network or a stale system proxy before checking routes. If mainland China websites work after disconnection but all websites fail when connected, focus on the client’s proxy mode, virtual interface, and DNS settings. If only a specific site fails, the basic channel is still working; check that site’s regional policy, browser cache, route exit, and routing rules.

Do not rely on repeatedly refreshing one long-open tab as the only result. The browser may reuse an old connection, cache a failed page, or retain old DNS data. Open a private window or fully close the browser and test again. If the private window works but the regular window does not, the issue is usually a browser extension, cache, independent proxy, or secure DNS setting; the subscription does not need to be changed.

Identify DNS resolution failures

DNS converts domain names into addresses that can be reached. When resolution fails, the browser usually reports that it cannot find the address before connecting to the site. An incorrect or outdated address may instead cause a long wait, a certificate-name mismatch, or only some resources to fail. On a desktop system, run nslookup example.com and check whether the public test domain returns a result. If resolution fails, disconnect and reconnect the client so it can take over DNS again, then retest.

The system, browser, and client may each maintain separate DNS settings. Avoid enabling several custom solutions at once, or it becomes difficult to tell which path a request is using. Temporarily restore the browser’s automatic setting and let the system and client handle resolution. If you previously set DNS manually, record the original value before returning to automatic configuration. Afterward, close old tabs and establish a new connection; a simple refresh may continue using the old resolution.

Check whether the system proxy points to an exited client

After an abnormal client exit, the system proxy may still point to a local proxy port. The browser then sends requests to a local service that no longer exists, causing every website to fail immediately or wait indefinitely. Check the system proxy settings. If the client has exited while the proxy remains enabled, disable the stale proxy and restart the client. Do not enter proxy addresses found online, and do not place a subscription server address directly in the system proxy field; the client’s local proxy and remote route are different layers.

If the system proxy is correct but one browser still cannot connect, check whether it uses an independent proxy extension. The extension may override the system setting or send the target site through another exit based on an old rule. The simplest test is to retry in a browser without extensions. Once the extension is confirmed as the cause, inspect its rules one by one instead of changing the entire system route configuration.

The page opens, but images, video, or the login interface fails

Modern websites often load scripts, images, video, and login interfaces from several domains. A page opening does not mean every related domain uses the same exit. If the page framework loads but content is missing, open the browser developer tools’ Network panel and inspect the failed domains and error types. You do not need to submit the full page; record only the failed domain, request status, and reproduction steps. If a resource domain is routed incorrectly, briefly test global mode for comparison.

A login loop can also be caused by a changing exit or Cookie state. Keep the same route during sign-in instead of switching regions repeatedly. Clear the target site’s own Cookies and sign in again rather than deleting all browsing data. If changing regions fixes the issue, stay on that region for the current session. For Streaming region selection, read the guide to choosing routes for live sports to understand how peak hours and regional exits affect playback sessions.

A DNS leak warning does not necessarily mean the connection has failed

Some testing pages list several resolution exits at once. Interpret the result together with the client mode, system settings, and actual access behavior; seeing names from different regions alone does not prove that the route is unusable. More importantly, confirm that international domains are resolved and accessed through the client as expected, and that system settings recover after disconnection. If results keep changing under the same configuration, first disable the browser’s independent secure DNS and rebuild the client connection to reduce parallel resolution paths.

Submit a ticket when all domains fail to resolve, results are the same on different networks, and reconnecting the client or checking the system proxy has not helped. Include the text output of the resolution command, but never include a real subscription link. If only one domain fails, also provide a comparison domain that opens normally; this helps distinguish an overall DNS issue from a problem with the target site.

How to assess slow speeds and peak-hour buffering

Before investigating speed, confirm that the basic connection is stable. If the connection is constantly rebuilding, speed tests and video buffering only repeat the effects of disconnections. Once ordinary websites remain accessible, determine whether the issue is slow first-page loading, insufficient sustained throughput, sluggish interaction, or a problem limited to peak hours. Each symptom calls for a different route choice; one speed-test result cannot determine whether an entire route is usable.

Distinguish latency, throughput, and stability

Latency affects response after a click, terminal interaction, AI Tools conversations, and online operations. Throughput affects large files, high-definition video, and sustained transfers. Stability determines whether a long-lived connection can remain active. A distant route may provide sufficient throughput while still responding more slowly than a nearby region; another may load quickly at first but fluctuate during sustained transfer. Choose the metric that matches the task instead of pursuing one vague definition of “fastest.”

For web browsing, watch whether the first load and repeated navigation remain stable. When using AI coding tools, watch for interruptions to completion, conversations, and terminal sessions. During video playback, note repeated quality drops and whether buffering clusters at particular times. For long-lived connections, see the route recommendations for AI coding tools. That article focuses on use cases; this section focuses on narrowing the fault scope.

Use same-region comparisons to rule out geographic distance

Start with a geographically nearby region and switch between different routes within that region. This reduces the effect of changing distance on the result. If one route in the same region is clearly slower while others work normally, avoid it temporarily and record the time. If every route in that region is slow, test a neighboring region. If the neighboring region recovers, the issue may be concentrated at the original regional exit or along the path from the target site to that region.

The routes page labels IEPL dedicated routes, relays, and direct connections. IEPL dedicated routes suit situations where stability matters; relays provide another path under different access conditions; direct connections depend more on the original quality between the current network and the remote endpoint. Choose based on comparative tests under the same access network rather than treating labels as an absolute ranking. Visit all routes for region and type details.

Peak-hour issues limited to a fixed period

If the connection works during the day but buffers during peak hours, do not reinstall the client first. A problem limited to a fixed period is more likely related to the access network, inter-network path, or concurrency at the target site. Preserve the current route result while the problem is occurring, then compare another route in the same region and a different route type. If only one video site is affected while ordinary websites and other video sites work, also consider that site’s content-delivery nodes and account-region policy.

A useful comparison record uses the same time period, device, access network, and target task. Testing a website in the morning and a large download at night produces no meaningful comparison. A better record is: the same video buffered continuously on the original route during peak hours but recovered on another route in the same region; or all routes showed similar behavior but recovered after changing the access network. This points more directly to the route side or the access side.

Pause background transfers before retesting

System updates, cloud-drive sync, photo backups, and large transfers on other devices all compete for the current network. VPNRH supports unlimited simultaneous devices, but “unlimited devices” does not mean every access network has unlimited bandwidth. When several devices transfer at once, the bottleneck may be the local network, router, or broadband exit. Pause background sync temporarily and leave only the current test running. Then re-enable other tasks one by one to see which causes a clear change.

Check plan traffic as well. Monthly subscription traffic resets on the activation date, and exhausted traffic is different from a slow route. If you need to adjust usage, see plans and traffic packages. Do not run repeated speed tests to consume more traffic in an attempt to prove the issue; sustained short-term testing amplifies local network fluctuations and does not represent long-lived connection stability.

Avoid common incorrect conclusions

One low speed-test result does not prove that the service is broadly faulty, and one high result does not prove that a long-lived connection is stable. A test site may automatically choose different test servers, while the target content site may use an entirely different network path. Treat speed tests as supporting evidence and prioritize whether the real task can reproduce the issue. Do not switch routes repeatedly and judge the result immediately; after each switch, let the old connection end and allow the target app to establish a new session.

If the issue occurs only on a specific route, at a fixed time, and can be reproduced repeatedly, submit the route name, route type, target site, access network, and time of occurrence. If changing the access network restores every route, state that clearly as well. Support does not need an exaggerated claim that “everything is slow”; it needs comparable path information. If the issue cannot be reproduced consistently, keep a brief record and add details when it happens again instead of repeatedly changing system settings.

Frequent disconnections and mobile background drops

Frequent disconnections require distinguishing a client-channel drop from an app-session failure. The former usually changes the client status, removes the system connection icon, or interrupts all apps at once. The latter may affect only one website, video, or AI conversation while the client remains connected. Check the client status when the drop occurs; do not assume the entire channel is down just because one page is spinning.

Check whether disconnections follow a network switch

When a device moves from one access point to another, or switches from a wireless network to another network, the existing connection path changes. Some clients reconnect automatically, but an old app session may not recover. If drops always occur after a network switch, confirm the client status once the switch is complete and reconnect if necessary instead of continuing to use an invalid old session.

A mobile device recovering from a weak-signal area may retain a network state that appears online but is unusable. Turn the current network connection off and on, confirm that ordinary access works, and then reconnect the client. If this happens repeatedly in one location, the access network may be the cause. If it occurs on different networks after similar actions, check the system background policy and client permissions.

Handle mobile background restrictions

iOS and Android manage apps according to battery level, background activity, and network state. If the system suspends the client after it remains in the background, the client may need to rebuild the channel when you return to it. In system settings, allow the client the background network activity it needs and check whether battery-saving policies restrict it. Menu names vary by system version; look under app information, battery usage, and background activity rather than relying on one exact menu path.

Do not enable multiple apps that can take over network traffic at the same time. The system generally allows only one primary connection configuration, and starting another tool may replace the current configuration, making the VPNRH client appear to disconnect suddenly. To remove conflicts, exit other tools one by one and restart the current client. Removing an icon from the recent-apps view does not always stop its connection component; use the in-app disconnect function when possible.

Distinguish sleep recovery from continuous disconnections

If drops occur only after the device is locked, resumes from sleep, or switches networks while use remains stable otherwise, focus on system background behavior and network recovery. If drops continue during active foreground use, check the route, protocol, and access network. Keep the same route and retest on another access network; recovery points to poor connection persistence on the original network. Keep the network unchanged and switch route type; recovery points to the path or protocol compatibility.

After a desktop system resumes from sleep, the system proxy, virtual interface, and DNS state may also be out of sync. The safest recovery order is to confirm that the local network is working, disconnect and reconnect in the client, and then reopen the target app. If you simply restore old browser tabs, they may reuse connections that failed before sleep and make the client appear to remain disconnected.

Why long-lived connections expose problems more easily

A normal web request can end after it completes, while AI Tools, terminal sessions, real-time collaboration, and livestreams keep connections open for longer. A brief network switch may only slow a webpage refresh but directly terminate a long-lived task. For these issues, do not test only whether a webpage opens; observe whether the complete workflow continues. If the app supports automatic reconnection, also record whether the context remains after reconnecting.

To verify route stability, choose a real task that can be repeated safely, keep the device, network, and route unchanged, and observe whether the drop follows a specific action. Do not run several large transfers as a stress test, because that mixes local bandwidth contention with route stability. If pausing background sync restores the long-lived connection, address local resource usage before judging the route.

Change connection-persistence settings carefully

Some clients offer options for auto-connect, on-demand connection, resume after sleep, and reconnecting when the network changes. First use the default configuration to confirm the issue, then enable only the functions you need. Enabling several automated options at once can make the client initiate repeated connections during network changes and cause the status to cycle. Record each option and its result, and restore the original setting if it does not help.

If the same account is used on several devices, VPNRH supports unlimited simultaneous devices, so the device count itself is not a normal cause of frequent disconnections. However, several devices sharing one access network and transferring continuously can still affect local network stability. During testing, temporarily pause large tasks on other devices; there is no need to delete devices or sign out of every account.

What to include in a disconnection ticket

A reproducible disconnection ticket should state the platform, current route, access network, action immediately before the drop, whether the client status changed, whether sleep or a network switch was involved, and what happened after changing the network or route. If the client provides runtime logs without credentials, include the error lines before and after the failure, checking first for complete subscription links or authentication fields. If unsure, submit only the error text and screenshots rather than the entire configuration file.

Subscription update fails or the route list does not change

A subscription update is how the client obtains the route list and configuration parameters. An update failure does not mean every existing route has immediately stopped working: the client may still have a local copy from the last successful update while being unable to retrieve later changes. First distinguish between an unreadable subscription link, a parsing failure after retrieval, a successful update whose interface still shows the old list, and an import into the wrong configuration group.

Copy it again from the dashboard instead of manually repairing the link

Sign in to the user dashboard and copy the complete link again from the subscription section. Use the copy action provided by the interface to avoid omitting the beginning, end, or query parameters during a long selection. Do not replace the domain, protocol prefix, or authentication fields manually, and do not add quotation marks around the link. A real subscription link is an account credential; never paste it into a search engine, online formatter, public code repository, or ticket body.

Links used for tutorials and issue reproduction must be obvious placeholders, for example:

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

If the update fails after copying, paste the link into a local plain-text editor to check whether it contains line breaks, but do not save it somewhere that automatically syncs or publicly shares files. After confirming there are no spaces or line breaks, return to the client and replace the old subscription link. Do not put the real address in terminal history or screenshots.

Distinguish network errors from format errors

An update error such as a timeout, domain-resolution failure, or connection failure usually means the client cannot reach the subscription endpoint; check the local network and DNS first. An invalid-format, parsing, or configuration-field error means the content was retrieved but the client cannot interpret it. Confirm that the import method matches a format supported by the client, and prefer the native import entry provided by the VPNRH client and dashboard.

If ordinary websites open in a browser but the client update always fails, check whether the client is restricted by the system firewall, an independent proxy, or an old network setting. Do not run another networking tool during the update. Disconnect first and update over a working basic network, then connect to the new route. If the current network cannot retrieve the subscription directly, you can try while connected through an already working route, but record which state succeeds so the network-path difference can be identified.

The update succeeds, but the route list does not change

First confirm that the client is viewing the configuration group that was just updated. Some clients store multiple subscriptions, so the result may go into another group while the current selection remains on the old one. Check the subscription name, last-update status, and active configuration. Do not judge only by the route count, because route changes do not necessarily change the total. VPNRH covers 120+ countries / 170+ routes, while clients may reorganize the local display by region, protocol, or policy group.

If the client reports a successful update but the content clearly remains old, fully quit and reopen it so the interface rereads the local configuration. If nothing changes, export or record necessary custom rules, then delete the old subscription item and import it again. Do not clear all client data, which would also remove diagnostic information and personal rules and make the issue harder to reproduce.

Recovery order after a configuration parsing failure

Undo manual edits first and restore the original content generated by the subscription. If the configuration was copied into another format and then imported again, conversion may have removed protocol parameters or policy-group relationships; stop using that converted copy. Return to the dashboard, obtain the subscription again, and import it through the client’s native subscription entry. After importing, test the default route before adding complex rules.

If the new import works, the problem is in the old configuration or a custom edit. Migrate only the necessary rules one at a time and retest after each change. If the original subscription also fails to parse, record the client name, platform, complete error text, and update action. Do not send the configuration body to support. Support can check the subscription output from the error type without receiving usable authentication details.

What to do after a subscription link is exposed

If a real subscription link appeared publicly or was sent to someone who should not have access, sign in to the dashboard, reset the subscription, and update every client in use. Once the old link is invalid, devices that have not been updated will show subscription-update failures or unavailable routes; this is expected. Replace the old configuration on each device instead of exposing the new link again to restore an old device.

For obtaining, importing, updating, and handling exposed subscription links, read the complete subscription-link guide. This chapter focuses on troubleshooting decisions, while the article explains the subscription’s full client lifecycle. For a first-time macOS setup, also see the macOS installation and permissions guide.

When to submit a ticket for verification

Submit a ticket when updates fail on different access networks, the dashboard shows the subscription as active, the same error remains after copying it again, and the client’s native import entry also fails. Provide the platform, client name, error text, approximate time, update action, and networks tested. Simply state that the link was recopied from the dashboard; do not include its complete value. If the failure began only after a subscription reset, clearly state the order of the reset and the failure.

One app ignores the proxy or only one service fails

If the browser works but one app cannot connect, the basic connection is usually established. The issue is more likely whether the app reads the system proxy, client routing rules, its DNS method, or its own cache. Reinstalling the entire client is often ineffective. First confirm whether the app’s requests enter the channel, then check whether the target domains use the correct exit.

System proxy versus virtual interface

Some desktop apps read the system proxy, while others create network connections directly and ignore system proxy settings. With only the system proxy enabled, the former may work while the latter continues using the original network. If the client supports virtual-interface mode, it can take over more traffic from apps that do not read the system proxy, but it requires the relevant system permissions. Check the current mode instead of assuming every app behaves like the browser.

Before switching modes, record the original setting and fully quit the target app. An app may read network settings only at startup, so changing the system proxy while it is running may not make it choose a new path. Reopen the app after changing the client mode and repeat the same operation. If it works, the issue is related to traffic interception; if not, check routing rules and the target site.

Use global mode for a brief comparison

If the client offers rule mode and global mode, switch briefly to global mode for diagnosis. If the target app works in global mode, the original rules probably do not cover the relevant domains or processes. If it still fails in global mode, the cause is more likely app cache, account region, route exit, or an app-side issue. Restore the normal mode after the comparison so traffic that does not need an international route is not sent through the channel continuously.

Do not add only the main domain. An app may use separate domains for sign-in, APIs, static resources, and media. Identify failed domains from app logs or browser developer tools, but do not use unknown scraping tools. If the domains cannot be identified, provide the app name, failed feature, and global-mode comparison; support can suggest a safer direction.

Do not mix process routing and domain routing when judging the result

Process routing identifies traffic by application, while domain routing identifies it by destination. An app update, helper process, or embedded webpage may be launched by another process, so adding only the main executable may not cover every request. Conversely, domain rules may be affected by the app’s independent DNS or direct-connection behavior. Use one clear comparison method at a time to avoid process and domain rules overriding one another.

If the target app has several components, determine whether sign-in fails, content fails to load, or real-time features fail. Successful sign-in with missing content may mean resource domains are outside the channel. Normal content with dropped real-time features may indicate a long-lived connection or protocol compatibility issue. If the entire app is offline, check traffic interception and local security policies first. Break “this app does not work” into a specific feature so you can choose the correct routing target.

Check the app’s own proxy and DNS settings

Developer tools, terminal programs, and some desktop software may have independent proxy settings. If an old address remains there, the app can send requests to an invalid port even when the system proxy works. Check whether the app is set to follow the system automatically or contains an old proxy value. Environment variables may also override graphical settings, especially for tools launched from a terminal.

You can use the terminal to check whether common proxy environment variables exist. The command below only reads the current environment and does not change the configuration:

env | grep -i proxy

If the output contains a local address that is no longer used, edit the configuration file that sets the variable instead of overriding it temporarily at every launch. Save the original content before editing, then reopen the terminal and target program. Do not put a remote route address or subscription link in proxy environment variables; the app should connect to the local proxy provided by the client.

Regional exits and app account status

Some services determine available content from the route’s exit region, account region, and existing session together. Switching regions frequently can trigger a new sign-in or invalidate an old session. Choose a region that matches the use case and keep it fixed, then exit and reopen the target app. If the browser works but the app does not, clear the app’s network cache or sign in again, but do not change the route and account settings at the same time.

Streaming apps depend especially on multiple resource domains and regional exits. Whether a route supports the target content should be judged by the actual result at the time. If playback fails in one regional route but works in another, record the service, route region, and failure stage, then check the route details. Do not mistake one content removal, account permission issue, or service maintenance window for a route failure.

When to provide app-level details

If global mode restores access, state in the ticket that rule mode fails, global mode works, and identify the specific feature. If every mode fails while the browser can access the same service, provide the app name, platform, route region, failed steps, and error text. Do not provide the app password, session Cookies, or complete network-capture files. For command-line tools, you may submit redacted error output and proxy-variable names, but remove tokens and internal project addresses.

Device-limit notices, account checks, and ticket details

VPNRH’s stated rule is unlimited simultaneous devices. If the interface shows a “device limit exceeded” or similar notice, do not purchase more device capacity or interpret it as a plan limit. More likely checks include the client’s local configuration, account sign-in state, old sessions, whether the subscription belongs to the current account, and whether the notice comes from the VPNRH dashboard, the client, or the target app. The source determines the correct action.

First confirm where the notice comes from

Record the page and action where the notice appeared. If it appears inside the target app, it may describe that app’s own device policy and have nothing to do with VPNRH. If it appears in a third-party client, it may reflect client configuration or a local policy. If it appears in the VPNRH dashboard or VPNRH client, keep a complete screenshot and submit a ticket. The screenshot should include the page title and surrounding context, not just the words “limit exceeded.”

Also confirm that the expected account is signed in. VPNRH registration requires no email address; a username and password are enough, so similar usernames entered on different devices can lead to the wrong account. Check the username and plan status, but never send the password in a ticket. If you are unsure which account is in use, open the account page on a device that works and compare it with the affected device.

Clean up duplicate configurations instead of deleting all devices

Importing the same subscription repeatedly on one device can create several similarly named configuration groups. If the client switches to an old group, it may show an expired status, update failure, or old routes and be mistaken for a device limit. Confirm the active subscription and keep one verified configuration group. Record custom rules before deleting anything so a configuration still in use is not removed accidentally.

If the subscription was reset, every device must switch to the new subscription. Devices still using the old link will fail to update, which is not a device-limit issue. Copy the subscription again from the dashboard and update each device. VPNRH supports Windows / macOS / iOS / Android / Linux. The interfaces differ, but the logic is the same: confirm the account, confirm the current subscription, confirm a successful update, and then test the route.

Do not solve account and billing issues through network settings

If the dashboard shows an unexpected plan status, traffic balance, or order state, do not change DNS, the system proxy, or route settings. Those settings cannot change account records. Monthly subscriptions are ¥9.9/month with 60GB, ¥18/month with 250GB, and ¥28/month with 500GB; traffic resets monthly on the activation date, and a mid-cycle upgrade is prorated by the remaining days. Traffic packages are ¥158/300GB, ¥358/1000GB, and ¥658/3000GB; they remain available until used and never expire. Payment methods are Alipay / WeChat Pay / USDT.

If the page does not update as expected after payment, save the order-page status, payment method, and time of occurrence, then submit a ticket for verification. Do not pay again to test whether the page changes, and do not post complete payment credentials publicly. See the plans page for plan options and traffic rules. The refund policy stated in the body is a 14-day no-questions-asked refund; applications are handled according to the terms and ticket process.

A ticket should contain reproducible information

An effective ticket lets support reconstruct the diagnostic path without seeing the original environment. Write a symptom-specific title, such as “Windows: all routes time out” or “Android: connection drops after going into the background,” rather than “It does not work.” In the body, state the platform and client first, followed by the time, access network, route name and type, complete error text, reproduction steps, troubleshooting completed, and comparison results.

Describe reproduction steps in the order they occurred: open the client, update the subscription, choose a route, click Connect, open the target app, and note the error. If the issue appears only under specific conditions, state them clearly, such as only during peak hours, on one access network, after resuming from sleep, or in rule mode. Comparison results matter too—for example, recovery after changing networks, another route in the same region working, or global mode working while rule mode fails.

What not to include in a ticket

Do not submit account passwords, real subscription links, complete authentication fields, payment passwords, app-session Cookies, or unredacted configuration files. None is required to diagnose an ordinary connection issue. If logs contain URL query parameters, hide them first. If you cannot determine whether a log is safe, send only the error text and where it occurred. Support needs the troubleshooting context, not usable account credentials.

Do not send only a large screen recording without written details. A recording can supplement the ticket, but support still needs searchable error text and clear steps. If several client windows appear in a screenshot, identify the one actually in use so old and new configurations are not confused. Once the issue is resolved, add which change worked; this helps confirm the root cause and avoid repeated suggestions.

When to submit a ticket immediately

Submit a ticket when the account status or order record conflicts with the page, the dashboard shows a device-limit notice, all routes fail on multiple access networks, native subscription import continues to fail, a specific route remains reproducibly faulty, or the checks in the relevant section have not narrowed the scope. Open the user-dashboard ticket entry and organize the details using this checklist.

If switching away from one route resolves the issue, continue using the working route and submit the failed route plus the comparison results; there is no need to wait for the original route to recover. If the cause was the local network, a browser extension, or the target app, keep a brief record after handling it yourself. When the same symptom returns, reuse the verified diagnostic steps instead of reinstalling every component.