How to use a VPN is not simply a matter of clicking Connect once. A first setup usually includes creating an account, choosing a plan, completing payment, getting a subscription link, installing a client, importing the configuration, selecting a node, and verifying the exit connection. If any step is incomplete, the client may show “nodes available but unable to connect” or “connected” while websites remain unchanged.
This guide follows the real setup sequence. Each step covers the expected result, common mistakes, and the first things to check. “Subscription service” refers to the provider of route configurations, while “client” means the software that reads those configurations and creates the connection. They are separate: obtaining a subscription in the dashboard does not automatically connect the device.
Create an account and place an order: Check the dashboard status first
Open the service dashboard, create an account, and sign in before opening the plans page. Choose a plan that fits your needs and complete payment using one of the methods shown. The priority is not to find a Connect button immediately, but to confirm that the order and service status have synced to the current account.
Under normal circumstances, the dashboard shows the available service, traffic details, active status, and a subscription entry point. Button labels vary by provider; common examples include “Subscription,” “Copy subscription link,” “Subscribe in one click,” and “Import to client.” If the entry generates a configuration set that a client can read, it is a subscription link as described in this guide.
- ✅ After signing in, the selected service is visible rather than showing an inactive status.
- ✅ A subscription entry appears in the dashboard, with an option to copy the link or open it in a client.
- ✅ The service status and payment record belong to the account currently signed in, so you do not search for the order under another account.
- ❌ If the payment page shows Processing, do not create the same order repeatedly or keep importing a subscription that is not active yet.
If payment is complete but the dashboard still has no subscription entry, refresh the account page and sign in again to rule out stale browser cache. If it still has not synced, keep the order details from the dashboard and contact support through the site. Do not buy supposed “supplementary configurations” from an unfamiliar page; they will not repair the order status on the current account.
What is a subscription link, and how should you protect it?
A subscription link is an address generated by the service. When a client accesses it, the client retrieves node names, server addresses, ports, protocol types, and other connection parameters. It is not a normal webpage link. Pasting it into a browser address bar may produce a download, encoded text, a blank page, or an unsupported message; none of these alone proves that the subscription is invalid.
A subscription link usually acts as an access credential for the current account. Copy it directly into a trusted client rather than posting it in a public chat, screenshot, code repository, or online parsing tool. If the link is exposed accidentally, reset the subscription in the service dashboard instead of merely deleting it from the chat history.
Check the link’s integrity when copying it. Line breaks, leading or trailing spaces, missing characters, or copying explanatory text along with it can cause updates to fail. Some clients support QR scanning or importing from the system clipboard; in essence, they are still transferring the same subscription information.
A subscription is not a permanently static file. When the service updates its nodes, the client must run “Update subscription” to retrieve the new configuration. Updating only downloads the configuration and may not switch the current connection automatically; after the update, check that the selected node is present and available.
Choose a client: Match the platform and protocol
A client must meet two conditions: it must support the current operating system and the protocols used in the subscription. Windows, macOS, Android, and iOS use different system proxy mechanisms, and similarly named features may work differently. Desktop clients can usually control the system proxy, virtual network adapter, and routing rules; mobile clients generally take over traffic through the system VPN interface and are affected by background execution policies.
| Platform scenario | First-use priority | Common issue | Check first |
|---|---|---|---|
| Windows | Confirm that system proxy or virtual network adapter mode is enabled | The client is connected, but some applications bypass the system proxy | Check the application’s own proxy settings and the current operating mode |
| macOS | Allow the client to add system network settings | System authorization is incomplete, so the connection cannot take over traffic | Review the configuration status and permission prompts in network settings |
| Android | Accept the system VPN connection request and allow background operation | The connection is paused by battery-saving rules after the app goes into the background | Check battery optimization, background restrictions, and the current VPN status |
| iOS | Allow the VPN configuration to be added and complete the system confirmation | The import is complete, but the configuration has not been enabled by the system | Check the system VPN indicator and the client’s connection logs |
The protocol must match as well. Shadowsocks is an encrypted proxy protocol; its configuration usually includes the encryption method, key, server, and port. VMess and VLESS are common in the same client ecosystem, but their authentication and data structures differ, so their parameters cannot be mixed by changing only the protocol name. Trojan typically runs over a TLS connection and requires the correct domain, certificate-related parameters, and server configuration.
Hysteria2 and TUIC use transport designs built around UDP and QUIC. They may perform differently on networks with high packet loss or instability, but the local network must allow the relevant UDP traffic and the client must fully support the server parameters. A newer protocol is not automatically a faster route. Real-world performance also depends on the access network, cross-border path, server load, exit location, and destination website.
Import the subscription: From an empty client to a node list
After installing the client, look for an entry such as “Subscription management,” “Subscription settings,” or “Import from clipboard.” Paste the complete subscription link, save it, and run an update. Some clients require you to create a subscription name before entering the address; the name is only for local identification and does not affect the server connection.
- Copy: Use the service dashboard’s copy-subscription-link action instead of typing the link manually.
- Add: Paste the address into the client’s new-subscription entry and save the configuration.
- Update: Run a subscription update manually and wait for the client to finish parsing it.
- Check: Confirm that the node list shows regions or route names, rather than only a subscription title.
- Select: Choose a node and set it as the current connection target.
- Connect: Enable the system proxy, VPN mode, or the client’s connection switch.
Direct evidence of a successful import is that the client displays a node list and recognizes the corresponding protocols. If only the subscription name appears and there are no nodes, the subscription may not have been updated, its contents may be unparsable, or the client may not support that format. Do not change ports or encryption parameters first; in subscription mode, those fields should be supplied by the service.
If you see “subscription update failed,” first determine whether the subscription fetch failed or the node connection failed. The former occurs while downloading the configuration, commonly showing a timeout, invalid address, or unsupported format. The latter occurs after nodes appear, commonly showing a connection timeout, handshake error, or unreachable destination. The troubleshooting paths are completely different.
Nodes and routes: How to choose direct, relay, or IEPL
Node names often include both a region and a route type. The region indicates the exit location, while the route type describes the approximate path from the local network to that exit. On your first connection, there is no need to test every node. Choose an exit based on the destination service’s region, then compare connection stability among routes in that region.
Direct routes usually connect the local network straight to an overseas server. The path is simple, but performance depends more heavily on the carrier’s current international gateway. Evening congestion, inter-carrier routing, and local network fluctuations can all affect the connection directly.
Relay routes connect to a nearby entry point first, then forward traffic through a relay network to an overseas exit. This can avoid some unstable direct paths, but performance still depends on the combined condition of the entry, relay, and exit. A relay does not automatically mean lower latency, nor can it eliminate problems in the local access network.
IEPL dedicated routes are generally used to reduce reliance on public international internet paths and suit situations where cross-border link stability matters more. Keep in mind that route stability and whether a destination accepts the exit IP are separate issues. Video platforms, developer tools, and account systems may also evaluate the exit region, IP type, and account settings.
| Route type | Path characteristics | Good first-use scenarios | What it cannot solve |
|---|---|---|---|
| Direct | The local network connects directly to an overseas exit | When the local international gateway is stable and the path is clear | Local congestion, indirect inter-carrier routes, or destination restrictions |
| Relay | Connects to an entry point first, then forwards traffic to an overseas exit | When the direct path is noticeably unstable | Entry-network failures or restrictions on the destination exit |
| IEPL dedicated route | Reduces the impact of public-network paths across the border | Long-lived connections, remote collaboration, and sustained transfers | Poor local wireless service or a region mismatch on the account |
Do not judge a node solely by the latency test shown in the client. Some tests only probe the server response and do not represent the full path to the destination website. A better approach is to choose the target region first, connect, then open the service you actually need and observe page loading, long-lived connections, and sustained transfers.
Verify the connection: “Connected” is not enough
When a client shows “Connected,” it only confirms that the client considers the connection process complete. To verify that traffic is actually using the selected node, check the exit address, DNS resolution, and application traffic. Before testing, disable other proxy extensions and parallel network tools so multiple configurations do not take over the system at once.
- ✅ Check the exit IP before and after connecting, and confirm that its region matches the selected node.
- ✅ Open a regular webpage to confirm that domain resolution and HTTPS access both complete successfully.
- ✅ Test the applications you actually need instead of relying only on the client’s built-in probe.
- ✅ After disconnecting, check the exit again to confirm that the system proxy or VPN configuration has been restored correctly.
- ❌ Do not assume that a numeric node latency means every application is using the proxy.
If the browser works but command-line tools, game platforms, or standalone applications do not, the issue is usually related to the scope of proxy capture. System proxy mode mainly affects applications that follow system proxy settings; virtual network adapter mode can cover more traffic but requires more from permissions, routing, and DNS configuration. Some applications also use their own network stack or built-in proxy and need to be checked separately.
Conversely, if subscription updates work but every node connection fails, first check whether the current network restricts the relevant protocols. Retest on another trusted network to distinguish a local network issue from a service-side issue. If only one node fails, switch to another route in the same region and keep the protocol, handshake, and timeout details from the error log.
DNS leaks and routing rules: Check again after connecting
DNS converts domain names into network addresses. A DNS leak generally means that application traffic passes through the proxy while domain queries are still sent to an unexpected local resolver. This can produce inconsistent region detection or cause some domains to resolve in a way that does not suit the current exit.
When DNS results are inconsistent, first check whether the client has enabled remote DNS, encrypted DNS, or virtual network adapter capture. Also check the browser’s secure DNS setting, since a browser may bypass the system resolution path. Avoid assigning different resolvers independently in the system, browser, and client; otherwise it becomes difficult to identify which one is handling the queries.
Routing rules determine which traffic uses a node and which connects directly. Common modes are global, rule-based, and direct. Global mode is convenient for initial troubleshooting because the traffic path is more consistent; rule-based mode suits daily use, but outdated or incorrect rules may send a destination domain directly by mistake; direct mode does not send target traffic through a node.
A typical routing failure is that some websites work normally while others still show the local region, or the page body loads but images, APIs, and sign-in requests fail. Modern websites often use multiple domains, so routing only the main domain is not enough. Check the client’s connection log to see which rule ultimately matched each relevant domain.
Troubleshooting common issues: Work through the layers
Subscription will not update
Copy the subscription address from the dashboard again and confirm that there are no leading or trailing spaces or missing characters. Then check whether the client supports that subscription format. A client that has not been updated for a long time may also fail to recognize newer protocol fields. Do not manually delete or edit subscription content unless you understand what each parameter means.
Nodes appear, but every connection fails
Switch the current access network first, then test different routes in the same region. If errors are concentrated around UDP or QUIC while other protocols work, the current network may restrict that traffic. If every protocol times out, also check the system clock, firewall permissions, the client’s network permissions, and the service status.
Shows connected, but the exit has not changed
Check whether you selected a node without enabling system proxy or VPN mode. On desktop, also confirm that the target application follows the system proxy. A browser proxy extension, an old system proxy address, or another client running at the same time may override the current settings.
Websites open, but applications do not work
This usually means the browser is using the proxy while the target application is not being captured. Check whether the client offers virtual network adapter mode, or review the application’s own proxy options. Before switching modes, close other network tools to prevent routing tables and DNS settings from overriding one another.
The connection drops after running for a while
On mobile platforms, check background restrictions and battery-saving policies first. On desktop, review network changes, sleep and wake behavior, and the client logs. When a wireless network switches between access points, the existing connection may fail and the client may need to rebuild the tunnel. Frequent automatic node switching can also interrupt long-lived connections.
First-day completion criteria: Keep a reproducible configuration
After the first successful connection, do not immediately pile on custom rules. Keep one verified working node, one clearly defined routing mode, and one explicit DNS setup. Record the client, operating mode, and error details from any failure so you can reproduce the issue later.
Subscriptions need periodic updates, but you do not need to import them again every time you open the client. The normal approach is to update the same subscription entry. Creating multiple copies of the same subscription can lead to duplicate node names, leftover old configurations, and uncertainty about the actual connection target.
- ✅ The service status in the dashboard is normal, and the subscription entry is accessible.
- ✅ The client can update the subscription and display nodes using supported protocols.
- ✅ After selecting a node, system or application traffic actually uses the expected exit.
- ✅ DNS resolution and routing results match the current use case.
- ✅ After disconnecting, the local network can access the internet normally again.
Once these checks are complete, the first-day setup is finished. Optimize later based on the specific issue: compare route paths when long-lived connections are unstable, check the exit when the service region is wrong, inspect capture mode when only some applications fail, and review DNS and rules when only certain domains are affected. Do not attribute every issue to the protocol or judge quality from the node name alone.