VPNRZ Troubleshooting Guide

Establish a reproducible troubleshooting baseline first

Describe the symptom before guessing the cause

Effective troubleshooting starts with observable behavior. Rewrite “the service is broken” as something testable, such as: the client cannot complete a connection; the client says it is connected but no browser can open a website; only one app fails; it works during normal hours but becomes noticeably sluggish at peak time; or switching to a mobile network restores access while the current Wi-Fi still fails. This level of detail determines which layer to check next. By contrast, “the server is bad” or “the protocol is broken” assumes a conclusion and can send every later step in the wrong direction.

When recording symptoms, keep four types of context: the platform, the current network entry point, the selected region or route type, and the action that failed. List Windows, macOS, iOS, Android or Linux for the platform. For the network, distinguish only home broadband, an office network, public Wi-Fi or a mobile network. Record the full route name shown by the client. Describe the action as connecting, opening a website, playing content, updating the subscription or resuming from the background. Do not reproduce an error popup from memory; copy the exact text or attach a screenshot. “Authentication failed,” “resolution failed” and “connection timed out” point to completely different troubleshooting layers.

Create a minimal comparison set

The goal of a minimal comparison set is not instant recovery, but finding what the symptom follows. Keep the same device and client unchanged, and switch only the current network to another available entry point. If the symptom changes with the network, focus first on the local network, router or network provider. If both entry points fail, change to a route in another region. If only one route is affected, the scope is narrowed to that route; if every route fails, check the account, subscription contents and client configuration.

Next, use the same network and subscription on another supported platform. If another device connects, the account and route are probably still usable; return to the original device and check client permissions, the system proxy, DNS, background restrictions and leftover configuration. If the other device also fails, stop reinstalling repeatedly. Sign in to the user panel, confirm the subscription status and obtain the current subscription again. VPNRZ supports Windows / macOS / iOS / Android / Linux with unlimited simultaneous devices, so a normal multi-device comparison is not undermined by a device-count limit from this service.

Change one variable at a time

A common troubleshooting mistake is changing several things at once to save time. For example, you might clear the configuration, switch protocols and restart the router in one sequence. Even if service returns, you will not know the real cause and may have to start over next time. A safer approach is to keep a short record of the current route, protocol, network entry point and result. Change only one item, wait for the connection state to settle, then test the same destination. If the change has no effect, restore the original value before moving to the next item.

Keep the test destination fixed too. Start with an ordinary website that is usually stable and requires no login, then test the service that is actually failing. If both the ordinary site and the destination service fail, check the connection, routing or DNS. If the ordinary site works but the destination service fails, check the exit region, app routing, the destination service’s own status or the account region. Do not use a complex app as your only initial test: it may have its own cache, private DNS, built-in proxy or regional policy, mixing route and app issues together.

After this chapter, you should be able to place the issue into a clear category: cannot connect at all, connected with no websites loading, slow speeds or peak-hour problems, frequent disconnects, subscription update failure, a specific app not using the proxy, mobile background drops, DNS issues or inconsistent account status. The later chapters follow the same principle: identify the layer, take one action, then retest with the original destination.

How to diagnose when the client cannot connect at all

First distinguish “not configured” from “configured but failing”

If the client has no routes or the route list is empty, the issue is usually not the connection protocol itself. The subscription may not have been imported, the imported content may be invalid, or the client may not have loaded the configuration. Do not keep clicking Connect. Open the user panel, obtain the subscription again and import it using the method supported by the client. Subscription content is account-delivery information; do not post the full address in a public forum or open it through a search engine. If this is simply your first setup, return to the quick-start guide and complete the import steps for your platform.

If routes are visible but clicking one quickly returns to a disconnected state, read the client log or error popup. For authentication errors, first check that the subscription was generated for the current account, that no characters were lost during copying and that an old configuration is not still selected. For timeouts, try another network entry point and route. For system-permission errors, check whether the client has the authorization needed to establish a network connection. Do not assume an account is invalid just because you see a timeout, or restart the router repeatedly just because you see an authentication error; the error category already points to the more likely layer.

Check the account, route, network and system in that order

Sign in to the panel first and confirm that the account opens normally. Check that the current subscription is still usable. Monthly-plan traffic resets each month on the activation date; once the traffic is used up, connection behavior may differ from normal. Traffic packages last until used and never expire. After confirming the status, obtain the subscription again and update the client configuration. An email address is not required; registration uses a username and password. During troubleshooting, however, make sure you are signed in to the original account rather than an empty account saved under a different username.

Once the account is confirmed, switch to a route in another region. VPNRZ covers 100+ countries / 220+ routes, and different routes use different entry points and relays, so one failed route does not prove that all routes are unavailable. Start with a region relatively close to your location, then try another route type. Route lists and type descriptions are available on the Global Nodes page. When switching, wait for the previous connection to close completely before starting a new one, so an unreleased session does not create confusing status information.

If several routes time out, switch the network entry point. If home broadband fails while a mobile network works, the client and subscription are capable of connecting, so focus on the router, local DNS, office-network policies or the current access environment. Office and public networks may restrict certain connection methods; do not modify network equipment you do not control. Keep the logs and continue testing on a network you can manage. If every entry point fails, check that the system clock is synchronized automatically, that system network permissions are enabled and that security software has not recently changed its network rules.

Clear old sessions instead of reinstalling blindly

A client can sometimes retain a virtual network session that did not close cleanly. Disconnect from inside the client, exit the program completely and open it again. If the system still shows a proxy or virtual network as enabled, disable the corresponding item in system network settings, then restart the client. Only consider deleting old configuration or reinstalling after confirming that the configuration is backed up and the subscription can be obtained again. Uninstalling immediately may also remove logs and diagnostic context, turning a clear error into an irreproducible intermittent issue.

If you still cannot connect at all after reinstalling, stop repeating the reinstall cycle. Cross-check instead: use the same account on another device, the same device on another network and the same network with another route. These three comparisons can narrow the scope to the device, network or server-side route. If all supported platforms, multiple network entry points and multiple routes fail at the same time, include those comparison results in a support ticket. That is more useful than writing only “cannot connect.”

If the error appears only on a specific network, record the network type and the time when it can be reproduced. If it appears only on a specific route, record the full route name. If it appears only on one platform, record the system and client name. Do not guess at the server-side cause. The goal is to split “cannot connect at all” into verifiable branches and confirm whether the failure occurs during configuration generation, client loading, the route handshake, the local network or system permissions.

Connected but websites will not open and DNS issues

“Connected” only means the tunnel has been established

When the client shows Connected, it means the local client completed the connection process with the selected route. It does not guarantee that domain resolution, system routing or the destination service is working. Stop focusing on the Connect button and test the domain, network exit and app separately. First open an ordinary website that requires no login. If every website fails, test whether the command line can retrieve response headers. When ordinary sites all fail, likely causes include DNS returning no result, system traffic not entering the tunnel, an old proxy setting still taking control, or the local network failing to update routes after connection.

If a domain will not open but a direct request to a known network address responds, the issue is more likely DNS. If the domain resolves but the request waits indefinitely, routing, the route or the destination response is more likely. You do not need to distinguish these by intuition; use the tools built into your system. The example domain is for testing only and contains no real subscription information:

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

nslookup returns a resolution result but curl cannot establish a request, which means the resolution stage is responding and you should continue with the system proxy, routing and route checks. If the resolution command itself fails, clear the system DNS cache first, then disconnect and reconnect the client. Preserve the complete command output; do not keep only the last line, because the upstream server, timeout description and error type may all be useful.

Confirm the scope before clearing caches

If the browser cannot open websites but other apps work, first test in a private window and temporarily disable proxy extensions configured inside the browser. The browser may have cached old DNS, certificate state or proxy rules, so do not immediately change the entire system. If the browser, command line and other apps all fail, check system-level DNS and proxy settings. Disconnect the client and confirm that the local network can open an ordinary website without it. If the local network itself is failing, restore basic connectivity before troubleshooting the accelerated connection.

DNS cache-clearing methods differ by system. The commands below are common system operations; after running one, reconnect and test the same domain again. The exact service on Linux depends on the distribution and network manager in use. If a command is unavailable, check which resolver service is actually enabled instead of copying an unrelated configuration file from the internet.

Check the system proxy and the app’s own resolution path

A system proxy and virtual network mode may coexist. If you previously entered a proxy address manually and later switched to the client’s global mode, the old address may still intercept browser requests. Open system network settings and confirm that the current proxy state matches the client’s operating mode. Do not delete enterprise-managed settings or system configurations you do not recognize. If the device is organization-managed, ask the administrator first. On a personal device, record the original value, temporarily disable the manual proxy and reconnect the client to test.

Some browsers and apps enable their own secure DNS or private resolution, so a successful system command does not mean the app uses the same resolution path. If only one browser fails, check whether it specifies its own DNS in the browser settings. If only one app fails, continue to the app-routing chapter below. Do not randomly try multiple DNS addresses. Frequent changes make the cache, system settings and client settings change together, making it difficult to identify what helped.

Another common situation is that ordinary websites open while a service requiring an exit region reports that the region is wrong. This is not a DNS failure. Confirm the selected route region and restart the target app to clear its old session. The destination may determine available content from the account region, cache, exit region or its own policies; one message does not prove that the route is unusable. Test an ordinary website over the same route first, then compare it with another region-appropriate route.

If all domains still fail to resolve after clearing the cache, disabling the old proxy and switching routes and network entry points, submit the complete resolution output, platform, route name and network type in a support ticket. If only the destination service is affected, include the comparison showing that ordinary websites work. This tells support that the tunnel is established and that the issue is in the resolution, routing or destination-service layer, rather than starting again with account login questions.

How to separate slow speeds from peak-hour lag

First distinguish throughput, responsiveness and app buffering

“Slow” can describe three different things: a website taking a long time to start loading, a file transfer maintaining a low speed, or a video or meeting buffering intermittently. Initial page load is more affected by resolution and response paths. Sustained transfer is more affected by local bandwidth, route congestion and destination-side limits. Video meetings are also affected by jitter, packet loss and the app’s adaptive behavior. Identify which type you are seeing before troubleshooting; a single speed screenshot is not enough. It reflects one destination during one session and cannot by itself explain why an app is stalling.

Disconnect the client first and confirm that the local network itself has no obvious problem. When the basic network is congested, every cross-border route has to work within those conditions. Then keep the device, network and test destination unchanged, connect through a relatively nearby route and repeat the real-world task. Do not simultaneously run cloud sync, system updates and large file transfers; background tasks compete for local upload and download capacity. For meeting issues, check the upload direction especially carefully, because blocked outgoing video may look worse to other participants than on your own screen.

Match the route to the destination, not just the region name

For destinations in Asia, start with nearby regions. For services in Europe or the Americas, choose based on the destination’s region and actual results. Shorter geographic distance often means a shorter path, but cross-border links are also affected by entry points, carrier interconnection and relay design, so map distance is not the only answer. VPNRZ offers IEPL dedicated routes, relay routes and direct routes, each with different use cases and path structures. Read the route notes on Global Nodes, then compare them with the same fixed destination.

IEPL dedicated routes suit situations where cross-border path stability matters more. Relay routes use an additional entry point to organize the cross-border path. Direct routes take a more direct path, but actual performance still depends on the local network and destination. These names describe how the route is organized; they do not promise identical results for every location or time. The most reliable method remains to keep the same device, network and destination, test each available type in turn and record the real app behavior.

Use a time-based comparison to confirm peak-hour issues

If performance is normal during ordinary hours but repeatedly slows at peak time, first determine whether congestion is on the local access network or the cross-border path. Keep the same device and route, then test through another network entry point. If the other entry point is clearly normal, focus on the original network. If different entry points show similar behavior at roughly the same time, try another route type or region. Do not directly compare tests taken far apart or against different destinations; destination load and local background tasks may also have changed.

When peak-hour lag occurs, switching through many routes usually makes the diagnosis less clear. Keep the current route as a baseline, then choose one nearby route and one route of a different type, completing the same real-world task on each. For video, observe startup, seeking and continuous playback. For meetings, observe voice continuity, video recovery and reconnects. For AI Tools, observe page loading, request submission and continuous response output. Once you know which stage fails, you can distinguish resolution, time to first byte, sustained transfer and session persistence.

Change protocols only after checking the route and network

A protocol affects the handshake, transport characteristics and adaptability to the network environment, but it is not the first answer to every speed problem. First establish that the account, basic network and route work, then try another compatible protocol offered by the client. Record the original value before switching and test only the same destination afterward. If the protocol improves connection success but not sustained transfer, continue investigating the route and local bandwidth. If only one network entry point is sensitive to the protocol, record the network type together with the error log.

Do not ignore stability in pursuit of a single peak figure. Cross-border access is more useful when it consistently completes the task: whether pages load reliably, meetings reconnect frequently, Streaming repeatedly drops quality or AI responses stop halfway. See the blog’s guide to troubleshooting connection and disconnect rates, and judge routes with repeated tasks rather than one peak result. For annual-plan comparison criteria, see the comparison of speed, stability and support.

If several routes slow down only for one destination while ordinary websites and other apps work, consider the destination’s status, account region and app cache. If every destination is slow, check the basic network and route. If only peak hours are affected, use different network entry points and route types to isolate the congestion. The goal of performance troubleshooting is not to find one highest number, but to identify which part of the path changes with the conditions and choose the most stable combination for the current network and task.

Frequent disconnects and mobile background drops

First determine what ended the session

Frequent disconnects may result from a brief local-network change, the system reclaiming background tasks, the client reconnecting, a route-session timeout or a device switching from Wi-Fi to a mobile network. Observing the system state before and after the drop is more useful than immediately reinstalling. If it happens after every screen lock, focus on background operation and battery-saving policies. If it happens while moving between networks, focus on reconnection after the switch. If it still occurs periodically while the device is idle and the network is stable, compare routes and protocols next.

First confirm whether the basic network dropped at the same time. When the disconnect occurs, check whether the Wi-Fi indicator disappeared, whether other devices also briefly lost access and whether the router redialed. If the whole local network was affected, fix the basic network first. Only investigate routes, protocols and background permissions when the client disconnects while ordinary network access remains normal. Mixing these two problems makes support investigate a route failure that may not exist.

On mobile, check background policies and network switching

Mobile systems manage apps based on battery-saving status, background activity permissions and network quality. If the connection disappears after screen lock, check whether the client is allowed to run in the background, whether strict battery restrictions are enabled and whether the virtual network connection remains authorized. Do not conclude immediately after changing these settings. Reconnect, lock the screen, return to the foreground and retest the same website or app. If the drop occurs only after a long idle period, record the client state and system messages before and after entering the background.

When switching from Wi-Fi to a mobile network, the existing path has changed and the client usually needs to establish a new session. If it remains stuck on “Connecting,” disconnect manually and reconnect; do not keep tapping the switch. Apply the same check when returning from a mobile network to Wi-Fi. Some public Wi-Fi networks require web authentication. If the basic network is not truly online, the client cannot build a stable connection over it. Complete network authentication with the client disconnected, then reconnect.

If only one mobile app cannot access content after returning to the foreground while the browser works, the issue is more likely the app’s session cache or routing rules. Fully close and reopen the target app, then check whether it recovers. If it does, the route did not drop completely. If every app fails, check whether the client still shows Connected, whether the system retains the virtual-network indicator and whether DNS was reassigned. Do not mistake an expired app login for a route disconnect.

On desktop, rule out sleep, adapters and old proxies

After sleep and wake, Windows, macOS and Linux may change the network-adapter state, routing table and DNS. If the issue appears only after wake, disconnect the client, wait for the basic network to recover and reconnect. Do not repeatedly start connections before the basic network has obtained an address. External adapters, docks and Wi-Fi switching can also invalidate an existing session. Record whether sleep, an adapter switch or a network-entry change occurred just before the issue.

If a desktop disconnects repeatedly while the device remains active, open the client log and check whether the same error appears before each interruption. If the error is consistent and occurs only on one route, compare another route in the same region. If different routes disconnect on the same network, change the network entry point. If only one device disconnects, check local security software, network drivers and the system proxy. Do not upgrade every component or modify drivers at the outset; high-impact actions should follow the comparison tests.

Verify with a stable task, not just the status light

A connected status light does not prove that the app session has not been interrupted. A brief reconnect may also have no visible effect on an app that can recover. Verify by task: keep the same site open while browsing, observe whether voice and video recover in a meeting, and check whether a long-lived connection drops in a terminal. For tasks that must remain active, avoid deliberately switching network entry points or routes during the test.

If only Streaming buffers after playing for a while, do not classify it immediately as a connection drop. Return to the performance chapter and check sustained throughput and destination-side policies. If the page reports a domain-resolution error, return to the DNS chapter. Focus on route, protocol and system background settings only when the client clearly changes from Connected to Disconnected and the log records the session ending. Accurate classification prevents repeated actions in the wrong chapter.

If disconnects continue and comparisons across networks, routes and devices cannot identify the cause, include log excerpts from before and after the drop, platform, route name, network entry point, whether the screen was locked or the network switched, and whether ordinary network access also stopped. You may hide personal subscription content in the logs, but do not remove the context around the error time. Support needs to see which layer ended the session, not just the final disconnected screen.

Subscription updates fail and an app will not use the proxy

For failed subscription updates, check the retrieval path first

A subscription update has several consecutive steps: sign in to the correct account, obtain the current subscription, have the client retrieve it, parse the configuration and replace the local route list. A failure at any step can appear as “update failed,” so identify where it stops. If the panel cannot be opened, handle the account credentials first. If the panel opens but the client says the address is invalid, copy the current subscription again. If the client can retrieve it but reports a parsing error, check whether the client supports the subscription content. If the update succeeds but the route list does not change, check whether you are still viewing an old configuration group.

Do not manually remove or rewrite characters when copying a subscription, and do not pass the address through a third-party URL shortener. A subscription is account credential material and should move only between your own user panel and client. If you suspect it has been exposed, handle the account delivery information again in the panel and avoid pasting the full address into a ticket. You can write “subscription retrieval returned an authentication error” or attach a screenshot with sensitive parts covered; support usually does not need to see the complete credential.

When a client contains multiple configurations, the Update button may update only the currently selected group. Confirm the configuration name you are operating on, then update it and check whether the route list changed. Do not repeatedly import edited configuration copies across multiple clients; it becomes difficult to identify the current source. For subscription retrieval, import and exposure handling, see the complete guide to subscription links.

Use an obviously fake address to check the client’s input format

To check whether an input field accepts a complete URL, use a documentation example to confirm the structure, but never treat the example as a real subscription. The address below uses a public example domain and a fake token solely to show that the client needs a complete link rather than truncated text:

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

If the client interprets the address as a search term, inserts spaces or keeps only part of the text, paste it again from the system clipboard and confirm that the field is for “Import from URL,” not “Local file.” If QR-code import fails, return to the text method to verify the subscription, rather than mistaking a camera-permission issue for a subscription problem. After the update completes, connect through one route and then test the app; seeing a route list does not mean a connection has been established.

When one app fails, compare it with the browser first

If the browser works but one app cannot access content, the account, route and basic resolution are at least partly usable. Focus on whether the app follows the system proxy, uses its own network stack, is set to direct in the routing rules or cached a connection at startup. Fully exit the target app, confirm that the client is connected and launch the app again. If it recovers, the issue was probably an old session. If it still fails, compare the client’s rule mode with global mode, recording the original mode before changing it.

Rule mode matches traffic by domain, address or app. Missing or outdated rules, or a newly added destination domain, can leave the main page working while some resources fail. If global mode works but rule mode fails, check the rule set and the domains used by the app. If both modes fail, check the route region, destination-service status and app account region. Do not keep global mode as the only permanent fix; it is a comparison tool for locating the routing layer.

Some apps do not read the traditional system proxy but do follow the virtual network established by the system. Others may use their own DNS or connection optimization. Behavior also varies by platform. Android and Linux may offer per-app routing choices, while macOS and Windows commonly have both system-proxy and virtual-network modes. First confirm how the client is currently taking over traffic, then check whether the target app is excluded. Do not copy menu names or configuration paths from another platform.

If the target app fails only on one region’s route while other regions work, record the route and app name. If every route fails only for that app, include the exact error after launching it, the rule-mode versus global-mode comparison and whether the browser works. For a failed subscription update, state whether the panel can be opened, whether obtaining it again still fails, the client’s parsing message and whether the old configuration connects. Describe subscription and app-routing issues separately so support does not treat two independent failures as one.

Device-limit messages and account status checks

First identify where the message came from

VPNRZ supports unlimited simultaneous devices, so a message such as “device limit exceeded” should not immediately be attributed to this service. Identify whether it came from the user panel, client, operating system or destination app. Some clients limit local configuration instances, some apps limit the devices signed in to their own accounts, and enterprise networks may limit concurrent sessions. Similar wording can point to completely different handling. When taking a screenshot, keep the window title and source of the message; do not crop to one sentence.

If the message comes from a destination Streaming service, AI Tool or other third-party account, check that service’s own account rules; this service cannot change a destination’s login limits. If it comes from the client, check for duplicate imported configurations, old processes still running in the background and whether the client recognizes one configuration as multiple local instances. If it comes from the VPNRZ panel or the route-connection process, record the complete text and submit a ticket. It conflicts with the unlimited-device fact and requires an account-session check.

Keep the account source consistent across devices

For personal or family use across multiple devices, the most common issue is not device quantity but different devices retaining subscriptions obtained at different times. One device may use an old configuration while another uses the current one, making the problem look like a “new device pushed out the old one.” Sign in to the same account, obtain the current subscription from the panel and confirm the configuration source on each device. An email address is not required; registration uses a username and password. Keep the exact username safe so you do not enter another account with a similar name.

After changing the password, resetting account information or updating the subscription, an old client may retain cached data. Update the subscription on the affected device first, then disconnect and reconnect. Do not send configuration files through public channels or place the subscription address in a shared document. For shared use, agree on who manages account updates rather than having each device edit the configuration independently, which makes it impossible to tell which copy remains valid.

If only a new device cannot connect while the original still works, the account and routes usually still have a usable path. Compare the client type, configuration group, route name and network entry point on both devices. First put the new device on the same network as the original and choose the same route. If it still fails, the issue is more likely the new device’s configuration or system permissions. If changing the network restores it, investigate the original network rather than continuing to suspect a device limit.

Being able to sign in does not prove the subscription is fully healthy

A successful login only confirms that the credentials work. Also check the current plan, traffic status and whether the subscription belongs to that account. Monthly plans include ¥9.9/month with 60GB, ¥18/month with 250GB and ¥28/month with 500GB; traffic resets monthly on the activation date, and a mid-term upgrade is converted into remaining days based on the price difference. Traffic packages are ¥158/300GB, ¥358/1000GB and ¥658/3000GB, valid until used and never expiring. If the plan status differs from what you expect, verify the username and order first instead of changing the client again.

If the remaining time changes after a mid-term upgrade, understand it as the price difference converted into remaining days, not as an account fault. Monthly-plan traffic resets on the activation date rather than on a universal calendar-month schedule. Use the panel and activation date when checking traffic. If you need to select another plan, open the pricing page to review the rules, then manage it from the user panel. Alipay / WeChat Pay / USDT are supported payment methods. For an account-status issue after payment, keep the order-status page and do not repeat the same operation multiple times.

Separate the VPNRZ account, subscription and destination account

One cross-border session may involve the VPNRZ account, the client’s local configuration and the destination-service account. The VPNRZ username is used to obtain the subscription. The client reads that subscription and establishes the connection. The destination app uses its own login system. If the destination app asks you to sign in again, that does not mean the VPNRZ account signed out. If the client says the configuration expired, that does not mean the destination account is invalid. Record the three separately to avoid resetting the wrong credentials.

If you suspect someone obtained the subscription information, protect the VPNRZ account and update the relevant delivery information first, then re-import it on each device. Do not keep copying the same subscription to more devices while account security is uncertain. For family device-management questions, see the guide to shared accounts and simultaneous devices, focusing on the difference between login count, simultaneous sessions and local client instances.

A ticket should include partially identifying information for the current username, the message source, platform, client name, whether only the new device fails, whether the original still works and what happened after obtaining the subscription again. Do not submit a password or complete subscription address. For an order issue, state only that the panel’s order status differs from what you expected. Support needs to verify account ownership and subscription status, not obtain your private credentials.

When to contact support and what information to include

These situations are appropriate for a support ticket

Submit a ticket after the basic comparisons still cannot locate the issue, or when it clearly involves the account, order, subscription generation or several routes failing together. Typical cases include: the plan or traffic shown in the panel differs from the order; authentication errors continue after obtaining the subscription again; multiple supported platforms, network entry points and routes fail together; one route repeatedly produces a reproducible error; the client log shows a clear server response; or the VPNRZ panel shows a device-limit message inconsistent with unlimited simultaneous devices.

If only one browser extension fails, the destination app reports an account restriction or the basic network itself is down, handle it first in the relevant product or network environment. Support can help assess routes and subscriptions, but cannot change a third-party app account or network equipment outside this service. Stating the boundary clearly makes it faster to identify who should handle the issue.

Put the symptom and scope in the ticket title

Do not title a ticket only “doesn’t work,” “very slow” or “urgent.” A more useful structure is “platform + symptom + scope,” such as “Windows client times out on multiple routes,” “iOS disconnects after screen lock,” “subscription update returns a parsing error” or “an app is inaccessible in rule mode.” The title should identify the troubleshooting layer first; provide reproduction steps in the body. Do not combine unrelated problems in one title. If account status and app routing are both involved, describe them separately so they are easier to track.

Start the body with the expected result, then state the actual result. The expected result might be that ordinary websites and the target app are accessible after connecting. The actual result should specify the client state, exact error and affected target. Then list the comparisons performed: which route types you tried, whether changing the network restored access, whether other devices worked and whether ordinary websites matched the target app. Do not write only “I tried everything”; support cannot know what “everything” included.

Keep enough context while hiding sensitive content

Screenshots should show the client name, route name, status and complete error, while covering the username, subscription token, order identifiers and other private content. Include a section of the log from before and after the error, not just the final line, and do not upload complete system information unrelated to the issue. Command-line output can be copied as text for searching. If it includes a local username or directory, cover it without damaging the surrounding error context.

Do not put the subscription address or password in the ticket body. If support needs to verify the account, it can usually use the ticket association in the logged-in panel. If you cannot sign in, provide only the username and the observed error; do not volunteer the password. VPNRZ registration does not require an email address and uses a username and password, so the username is an important clue for recovering troubleshooting context. Enter it accurately, but never display it on a public page.

How to describe a reproducible sequence

Start with a known state, such as “the basic network works and the client is disconnected.” Then list the actions: “select a route and connect,” “open an ordinary website” and “launch the target app.” Finally state what you observed: “the client shows Connected, the ordinary website works and the target app keeps waiting.” This order lets support reproduce the issue under similar conditions. If it does not happen every time, state the trigger, such as after screen lock, a network switch, a subscription update or during peak hours.

Do not replace observations with an unconfirmed cause. “The route server is broken” is less useful than “this route times out while another works.” “DNS is being poisoned” is less useful than “the domain-resolution command times out while a direct connection test responds.” “I am being throttled” is less useful than “normal hours work, sustained transfer drops at peak time and switching the network entry point restores it.” Careful wording does not mean writing less; it means separating facts from assumptions.

How to retest after receiving a reply

When support suggests a route, configuration or client change, return to the original baseline first. Make only the change requested in the reply; do not add other settings found online at the same time. If the retest succeeds, state which step restored service and whether the original issue can still be reproduced. If it fails, provide the new log and error rather than reposting old screenshots. This creates a clear change history and prevents the ticket from restarting with the same questions.

Keep the panel order status for account or payment disputes. VPNRZ supports Alipay / WeChat Pay / USDT and offers a 60-day no-questions-asked refund; submit specific requests through a user-panel ticket. State the order and current status that need checking, and do not display payment credentials publicly. To understand plan contents, first see plan pricing, so monthly traffic resets, non-expiring traffic packages and mid-term upgrade conversion are not confused with one another.

The goal of systematic troubleshooting is not to change every setting once. It is to reach a clear boundary: determine whether the issue changes with the account, device, network, route, time period, DNS, client configuration or destination app. If it can be fixed locally, keep the working settings and record why. If support is needed, provide the smallest reproducible path in the ticket. When a similar symptom appears again, start from the established baseline instead of repeating every high-impact action.