How to use a VPN is not simply a matter of downloading a client and repeatedly clicking “Connect.” The process is to choose a plan, obtain a subscription link, import it into a compatible client, select a suitable route, and then verify that traffic is being forwarded as expected. When setting things up for the first time, separating each step’s inputs, outputs, and possible errors usually makes connection issues much easier to pinpoint—there is no need to keep reinstalling the software.
The steps below follow the order you would use them in practice. This guide also explains subscription links, protocols, direct and relay routes, IEPL dedicated lines, DNS leaks, and split-tunneling rules. Button names may vary slightly across platforms, but the troubleshooting logic remains the same.
Before you begin: confirm your plan and use case
When choosing a plan, first estimate the kind of traffic you handle rather than looking only at route names. Text messaging, web research, and code synchronization usually use relatively little data; HD video, system images, cloud-drive sync, and large updates can consume bandwidth continuously. If you regularly switch between several devices, also check how the plan describes device usage. RqVPN supports unlimited devices, but running too many high-bandwidth tasks at once can still make them compete for your local bandwidth.
No email address is required to create your access credentials; a username and password are enough. Your password and subscription link serve different purposes: the password gets you into the dashboard, while the subscription link provides node configuration to the client. Keep both private and separate, and never paste the subscription link into public posts, screenshots, or shared documents.
- ✅ Identify your main use case: web browsing and development tools, or video, downloads, and cloud synchronization.
- ✅ Confirm that your current network can access commonly used mainland China websites normally, so a local connectivity problem is not mistaken for a route failure.
- ✅ Save your dashboard login details, and treat the subscription link as a private credential that can directly access the service.
- ✅ Complete the setup on the device you know best first, then apply the same method to other platforms.
- ❌ Do not install and enable multiple clients that take over the system proxy or virtual network adapter at the same time.
Get and import the subscription link
After signing in to the user dashboard, find the subscription or client-configuration section and copy the complete link. Use the dashboard’s copy button rather than selecting it manually, which can omit characters at the beginning, end, or middle. Some chat tools add previews or line breaks to long links, so they are not suitable for storing or relaying them.
Open a compatible client and look for “Subscription,” “Configuration,” “Import from clipboard,” or “Import from URL.” Paste the link, confirm it, and run an update. When successful, the client will show region, route, or protocol entries. If it only creates an empty group with no nodes, the link may have been copied incompletely, the subscription may not have refreshed, or the client may not support the configuration format returned by the service.
- Copy the complete subscription link from the dashboard; do not edit its parameters manually.
- Create a subscription inside the client rather than adding a single node manually.
- After saving, update the subscription manually and wait for the node list to finish loading.
- Choose a node that is geographically close and suited to your use case.
- Enable the system proxy or the client’s virtual network adapter mode, then check connectivity.
“Import successful” and “Connection successful” are two separate stages. The former only means the client has read the configuration; the latter means it can establish a session with the remote node. If the node list appears normally but the connection fails immediately, check protocol compatibility, system time, the local firewall, and current network restrictions instead of repeatedly importing the subscription.
Client differences across platforms
Windows and macOS clients can usually manage the system proxy directly and may also offer a virtual network adapter mode. The system proxy mainly affects browsers and apps that follow proxy settings; virtual adapter mode takes over a broader range of traffic and is better suited to command-line programs, game platforms, or some desktop apps that do not read system proxy settings. Do not enable either mode redundantly across multiple clients.
Android clients generally take over traffic through the system VPN interface. When the system displays a connection-permission prompt, approve it; otherwise, the client may show the configuration as selected without actually establishing a network interface. Battery-saving policies can also terminate the connection when the app is in the background. If it disconnects after the screen locks, check the system’s background-activity restrictions for the client.
iOS and iPadOS likewise require a system network configuration to be installed. A system confirmation prompt on the first connection is normal. If the client can update the subscription but cannot connect, first check whether another similar configuration remains in system settings, then return to the client and select the node again. On macOS, if you use command-line development tools, also confirm whether terminal processes follow the system proxy; testing only in a browser does not prove that every program is being routed.
| Platform | Common traffic takeover method | First-time setup focus | Common roadblocks |
|---|---|---|---|
| Windows | System proxy, virtual network adapter | Confirm the proxy toggle and active configuration | Security software blocks the network interface, or multiple clients are running at once |
| macOS | System proxy, virtual network adapter | Allow the system network configuration | Proxy behavior differs between terminal and desktop apps |
| Android | System VPN interface | Approve the system connection permission | Background restrictions cause disconnection after the screen locks |
| iOS and iPadOS | System network configuration | Confirm configuration installation and connection permission | Conflicting old configuration or a subscription that has not refreshed |
Different client names do not change the basic logic: the client must parse the protocols in the subscription, create a local proxy or virtual network interface, and send matching traffic to the remote endpoint. If the service dashboard recommends a client, use the corresponding version where possible to reduce format incompatibilities and missed system permissions.
How to choose protocols, routes, and nodes
Shadowsocks, VMess, Trojan, VLESS, Hysteria2, and TUIC may all appear in subscription ecosystems, but they are not simply ranked from “newest” to “fastest.” Real-world performance depends on the protocol implementation, transport layer, congestion control, route quality, local network, and client compatibility. Beginners should not manually change the port, encryption method, transport path, or certificate parameters provided by the server.
| Protocol | Key characteristics | What to watch for |
|---|---|---|
| Shadowsocks | Relatively simple configuration with a mature client ecosystem | The encryption method must match the server; do not rewrite it yourself |
| VMess | Often combined with multiple transport methods | The client must fully support the transport parameters delivered by the subscription |
| Trojan | Typically establishes connections over TLS | Incorrect system time, domain settings, or certificate validation can all cause the handshake to fail |
| VLESS | Lightweight protocol often combined with different security layers | Do not judge by the protocol name alone; check whether the accompanying transport method is supported |
| Hysteria2 | Built on QUIC, with congestion control designed for unstable networks | Some networks restrict UDP, in which case it may not work effectively |
| TUIC | Also uses QUIC over UDP | Requires support from both the client and the network; TCP connectivity alone is not a sufficient test |
Route type matters too. Direct means the local network connects straight to an overseas node, keeping the path simple but making quality more dependent on the carrier’s international gateway and current congestion. A relay route first connects to a nearby entry point, then forwards traffic through an intermediate network to the exit. This can reduce reliance on unpredictable public-internet paths, but the quality of scheduling between the entry and exit still matters.
IEPL dedicated lines generally describe international Ethernet routes with dedicated-carrier characteristics. Their path organization differs from an ordinary direct public-internet connection. A dedicated line does not mean every local network, time of day, or destination will perform identically; access quality, entry-point load, and the destination service’s response still affect results. Judge it through sustained use with your own applications rather than a single peak speed test.
Verify that the connection is really working
A client showing “Connected” only means that the local program completed one connection stage; it does not by itself prove that every app is forwarding traffic as expected. Verify connectivity at four levels: basic access, exit address, DNS resolution, and the target application.
- Open a website that normally works for you and confirm that the local network has not been disrupted by the proxy settings.
- Visit the site’s My IP page and check whether the exit region matches the node you selected.
- Disconnect and check the exit again, then reconnect for comparison so a cached page is not mistaken for the result.
- Test the browser and your main apps separately. If the browser works but command-line tools fail, focus on the system proxy, environment variables, or virtual network adapter mode.
- Run through a complete task for a while—such as signing in, navigating between pages, requesting files, and maintaining a long-lived connection—instead of checking only whether the homepage opens.
What a DNS leak means
DNS resolves domain names to network addresses. If app traffic travels through a remote route while DNS queries are handled directly by the local network, the resolution path and access path do not match—a situation commonly called a DNS leak. It may expose the domains being queried, or cause the destination service to return the wrong region or an invalid address when local resolution does not match the exit region.
The solution is not to enter a random public DNS address, but to make sure the client’s DNS mode works with its split-tunneling rules. Virtual adapter mode can usually take over more queries consistently; in system proxy mode, some apps may bypass the client and resolve DNS themselves. After making changes, reconnect, clear the app cache, and check the result again.
How to evaluate split-tunneling rules
Split tunneling uses domains, address ranges, apps, or rule sets to decide whether traffic connects directly or goes through the proxy. Sensible rules keep local services on direct connections while sending only requests that need international routes through a node. Outdated rules or an incorrect matching order can leave the main page working while images or login APIs fail, because different domains required by the same page are taking different paths.
- ✅ The exit region matches the selected node, and disconnecting restores the local exit.
- ✅ The browser, main desktop apps, and command-line tools have each been verified.
- ✅ DNS queries follow the client’s configuration and are not obviously bypassing it.
- ✅ Local services remain direct, while destinations that need international routes load reliably.
- ❌ Do not use the client’s status icon or a single homepage load as the only measure of success.
A practical troubleshooting order
Start with local prerequisites, then move layer by layer through the subscription, client, protocol, node, and destination service. Skipping the basics and changing many settings at once can turn one straightforward issue into several.
The node list is empty
Return to the dashboard to confirm the plan status and subscription entry, then copy the complete link again. Delete any clearly incomplete subscription record in the client, add it again, and run an update manually. If the list is still empty, check whether the client supports the format returned by the subscription. An empty node list is not a route-speed problem—the configuration has not reached the connection stage yet.
No nodes can connect
First, confirm that the system time is accurate, then close other proxy clients and conflicting network extensions. Check whether the current network restricts UDP. If Hysteria2 or TUIC cannot connect, test a TCP-based protocol when the subscription offers that option. If every protocol fails, test on another reliable network to distinguish a local configuration issue from a problem with the current access network.
Only some websites are failing
This is usually related to split tunneling, DNS, the target region, or the website itself. Keep the same node and briefly switch to global proxy mode for comparison. If global mode works, focus on the rules; if it still fails, recheck the exit region and DNS. Restore split tunneling after testing to avoid routing unnecessary local traffic through the proxy.
The connection starts normally, then slows down or drops
Check whether the problem appears only after the device sleeps, the client moves to the background, Wi-Fi changes, or the network fluctuates. On mobile platforms, review background-activity restrictions; on desktop platforms, make sure another network utility has not reset the virtual adapter. If it happens only at certain times, keep the same protocol while comparing other entry points or routes. Do not change DNS, split tunneling, and transport parameters all at once.
Routine maintenance after the first setup
After the first successful connection, you do not need to re-import the subscription every day. Once the client has saved it, update it as needed to retrieve node configuration changes from the service. If node names or parameters change, use the refreshed subscription rather than relying on old nodes copied manually.
If problems appear after a system upgrade, client update, or change in network environment, first recheck permissions, the system proxy, and the virtual adapter status. Once you are sure they are no longer needed, remove outdated clients and old network configurations to prevent multiple components from competing for the system proxy. When changing devices, copying the subscription again from the user dashboard is more reliable than forwarding an old configuration file and makes its source easier to verify.
In daily use, sustained stability is more useful than a single peak speed. Keep a familiar region and protocol, and watch whether page loads, long-lived connections, video buffering, and development-tool synchronization remain consistently normal. Change routes only when your app needs, exit region, or network conditions change. This reduces pointless switching and makes genuine route changes easier to identify.