“What do subscriptions, nodes and protocols mean?” is one of the first questions many beginners have after importing a configuration into a client. In simple terms, a subscription delivers configuration to the client, a node is a selectable connection endpoint, and a protocol defines how the client communicates with the server. Routes, split tunneling and operating modes then determine where data travels and which apps use the connection. They form one connection chain, but the terms are not interchangeable.
The best way to understand these terms is not to memorize definitions, but to follow the real workflow: obtain a subscription link and import it into a compatible client; the client parses it into nodes; after you select a node, the client establishes a connection using its protocol; once connected, global mode or split-tunneling rules decide which requests enter that connection. DNS then translates domain names into addresses and must also align with the routing policy.
What does a subscription link actually contain?
A subscription link is usually a server-generated address that a client can read. After accessing it, the client retrieves a set of encoded or structured configurations. These may include server addresses, ports, protocol types, authentication parameters, node names and update information. Users see one link; the client sees data that can be converted into a node list.
“Buying a subscription” and “importing a subscription” are therefore two different actions. The former means obtaining permission to use a service; the latter simply adds existing configuration to a client. A successful import does not mean the route is connected—it only means the client can read and parse the configuration. You still need to select a node, start the connection and check whether the target app uses the proxy or tunnel as expected.
Treat a subscription link as sensitive credentials. Anyone who obtains it can usually read the node configuration, so do not post it publicly or include it in screenshots or shared documents. When troubleshooting, you can share the client’s error message, but conceal the full link, authentication fields and server configuration. If you suspect the link has been exposed, update the credentials in the service panel rather than merely deleting the entry from the local client.
Importing, Updating and Local Configuration
“Import” means reading a subscription for the first time, “update” means retrieving the latest configuration from the original address, and “local configuration” is stored only on the current device. An update may add, remove or adjust nodes, and may overwrite some fields in entries with the same name. Direct edits to subscription-generated nodes are often lost at the next update. Custom rules that need to persist should go in the client’s supported override, rule-set or separate configuration area.
- Copy the complete subscription link from the service panel; do not manually remove or alter any characters.
- In a compatible client, choose “Import from URL” or a similarly named option.
- After importing, run one update to confirm that the client can retrieve the configuration normally.
- Choose a node and start the connection, then use the actual app to check the result.
- When the node list changes later, update the subscription first before treating the issue as a connection failure.
What’s the difference between nodes, servers and routes?
A node is a selectable configuration item in a client. It usually points to a server endpoint and includes a protocol, port, authentication details and display name. One server can offer different protocols or endpoints, so multiple nodes shown in a client do not necessarily represent the same number of physical machines. Conversely, nodes in the same region may be hosted on different servers.
A server is the computing resource that runs a network service; a node is a connection endpoint a user can select; and a route describes the path data takes from the local network to the destination network. When a node name includes a region, it usually indicates that the exit or primary endpoint is associated with that region, but the full route cannot be inferred from the name alone. The actual path is also affected by the local carrier, endpoint location, backbone transport and the destination site’s network policies.
| Term | Primary meaning | What users can see directly | Common misconception |
|---|---|---|---|
| Subscription | Distributes and updates configuration for the client | Subscription name, update time and node list | Mistaking a successful import for a successful connection |
| Node | A selectable server endpoint configuration | Region, protocol, name and status | Assuming every node maps to a separate physical server |
| Server | The computing resource that actually runs the connection service | Complete underlying details are usually not shown | Judging the entire route only by the server’s region |
| Route | The transport path between the local network, entry point, backbone and exit | Service-side labels such as direct, relay or dedicated route | Treating a route label as a guarantee of fixed speed |
Direct, relay and IEPL dedicated routes
A direct route usually means the local network connects straight to an overseas server endpoint. Its structure is simple, but the experience depends more heavily on the local carrier and international exit conditions. A relay route first connects to an entry point that is closer to or better suited to the local network, then forwards traffic to the target exit. This can improve route selection in some network environments, but the extra hop also requires the service to coordinate the entry, relay and exit points.
An IEPL dedicated route generally refers to enterprise-grade international Ethernet transport. In services for individual users, this label typically describes a controlled section of the transport path; it does not mean that every segment from the user’s device to the destination site uses the same dedicated route. The local connection to the access point and the exit to the destination may still use ordinary networks, so “dedicated” should not be understood as guaranteeing identical performance at every location or time.
Region is only one factor when choosing a route. The destination’s location, whether the app depends more on latency or sustained throughput, whether the local network restricts UDP, and whether the current entry point is congested can all affect the result. A reliable approach is to narrow the choices by destination region, then compare availability in the same use case rather than focusing only on adjectives in node names.
What does a proxy protocol determine?
A protocol defines how the client and server establish a session, authenticate identities, encapsulate data and transmit it over the network. The node configuration must match the protocol and parameters supported by the server; you cannot manually change a Trojan node to VLESS and expect it to keep working. A protocol is not a speed switch on its own. Route quality, congestion, device performance, transport settings and the destination site all affect the experience.
Shadowsocks, VMess, Trojan and VLESS
Shadowsocks is a widely used encrypted proxy protocol. Its configuration usually centers on the server, port, password and encryption method. It has mature implementations and broad client support, but its actual security and compatibility depend on the selected encryption method and client implementation. On its own, it mainly handles proxy transport and does not automatically provide a sophisticated split-tunneling interface.
VMess is an earlier, widely adopted protocol in the V2Ray ecosystem. Its authentication and transport settings involve factors such as the user identifier, transport method and time synchronization. If the device clock is significantly inaccurate, some configurations may encounter authentication problems. VLESS uses a lighter authentication design and does not provide encryption by itself; it is typically paired with TLS, REALITY or another secure transport mechanism. When you see VLESS, check the transport and security layers it uses rather than looking only at the protocol name.
Trojan typically runs over a TLS-protected connection. Key settings include the server name, certificate verification, password and transport options. Disabling certificate verification may get around certain configuration errors, but it weakens verification of the server’s identity and should not be treated as routine troubleshooting. The correct approach is to check the system time, server name, certificate status and configuration match.
Hysteria2 and TUIC
Hysteria2 and TUIC both rely heavily on QUIC and UDP transport, combining capabilities such as congestion control, multiplexing and connection migration. On networks with high packet loss or noticeable instability, they may adapt better than some TCP-based options, provided the local network allows UDP to work reliably. If an office network, public network or router strictly restricts UDP, the connection may fail or degrade. In that case, switch to another protocol offered by the service instead of repeatedly changing unrelated parameters.
| Protocol | Transport characteristics | Key configuration checks |
|---|---|---|
| Shadowsocks | Encrypted proxy with broad client support | Confirm that the encryption method, password and port match |
| VMess | Supports multiple combinations of underlying transports | User identifier, transport parameters and system time |
| Trojan | Typically establishes connections with TLS | Server name, certificate verification and password |
| VLESS | Lightweight authentication, usually paired with a secure transport layer | Supporting parameters such as TLS or REALITY |
| Hysteria2 | QUIC-based, designed to handle network instability | UDP availability, authentication and bandwidth parameters |
| TUIC | QUIC-based with multiplexing support | UDP availability, congestion control and authentication settings |
Global mode, rule mode and split tunneling
After establishing a connection, the client still has to decide which traffic enters the node. Global mode generally sends as many client-handled requests as possible through the selected node. Rule mode instead chooses proxy, direct access or blocking based on domains, IPs, apps or rule sets. This decision process is split tunneling. Its goal is not to send every request along a longer route, but to give each request a more suitable exit.
In rule mode, a request may first match a direct-access rule for the local network, then a rule for a specific domain, and finally the default rule. Rule order matters: more specific rules should generally come before broader ones. If a broad direct rule matches too early, later proxy rules will not run. Conversely, an overly broad proxy rule may send local services, printers or internal systems through an unnecessary remote route.
System Proxy, TUN and In-App Proxy
A system proxy provides an HTTP or SOCKS endpoint for apps that follow the operating system’s proxy settings. Some apps read these settings; others create their own connections and ignore them. TUN mode uses a virtual network interface to handle a broader range of IP traffic. It can cover programs that do not read the system proxy, but it is also more likely to conflict with firewalls, virtual machines, enterprise networking software or other tunnel tools.
An in-app proxy is configured with a proxy address and port inside one particular app. It has the smallest scope and is easy to troubleshoot. When a beginner finds that “the browser works but other apps do not,” the common cause is not a failed node: the browser follows the system proxy while the other apps do not. Check the client’s operating mode before deleting the subscription.
- ✅ If only the browser needs an international route, start with the system proxy or the proxy settings supported by the browser.
- ✅ If you need to cover desktop programs that do not read the system proxy, then assess whether TUN mode should be enabled.
- ✅ In rule mode, confirm that the local network, commonly used domestic services and target international services match the intended rules.
- ✅ Reopen the target app after changing modes so that an old connection does not continue using the previous route.
- ❌ Do not run multiple clients that take over system traffic at the same time, as their routing and DNS settings may overwrite one another.
- ❌ Do not treat a “connected” icon as proof that every app is using the node.
DNS leaks and domain resolution
Before an app accesses a domain, it usually queries DNS to obtain the corresponding address. A DNS leak occurs when queries that were meant to be handled inside the tunnel or by a specified resolver bypass the expected path and go to the local network’s DNS instead. As a result, the resolver location may not match the access exit, or different local results may cause a site to fail, show the wrong regional content or match the wrong rule.
DNS issues are closely tied to split tunneling. If the client decides routing by domain, it needs the domain information early in the connection. If an app resolves the domain to an IP address beforehand, the client may only be able to apply IP-based rules. Some clients use Fake IP, remote resolution or encrypted DNS to preserve the relationship between domains and connections, but implementations vary across platforms and cores.
When checking DNS, do not look only at whether a webpage opens. Also confirm whether the client handles DNS, which resolver rule mode uses, whether an old manual DNS setting remains in the system, whether the browser has its own secure DNS enabled, and whether TUN mode and system proxy mode use different configurations. Independent browser resolution is not necessarily wrong, but it may bypass the domain-routing workflow designed by the client.
Why do clients on different platforms use different settings?
Windows, macOS, Android, iOS and Linux handle system proxies, virtual network interfaces, background operation and permissions differently. As a result, the same subscription may look and behave differently after being imported into different clients. The subscription provides server configuration, but how a client implements rules, DNS, TUN and automatic updates depends on the local core and the operating system.
Windows clients often provide both a system proxy and TUN. The former is straightforward to configure; the latter covers more traffic, but enabling TUN may require installing a virtual network component and granting the necessary permissions. macOS also supports system proxies and tunnel solutions, but network-extension permissions, the system firewall and other network extensions can affect traffic capture.
Android clients generally use the system VPN interface to handle traffic and may support per-app routing. If battery management restricts the client’s background activity, the connection may be paused after a long period of standby. iOS clients are constrained by the system network-extension model, so feature names may differ from desktop versions, and subscription updates and background connections depend more heavily on system scheduling.
On Linux, differences are more often caused by the desktop environment, network-management tools and how the client runs. A command-line core may only expose a local proxy port; whether the system uses that port automatically requires separate configuration of environment variables, desktop proxy settings or transparent forwarding. If the core shows “running,” that only means the process has started—it does not prove that all program traffic passes through it.
Which settings should beginners check first?
- ✅ Does the client support the protocols and transport methods used by the subscription?
- ✅ Is the subscription updating normally, and is the node list complete?
- ✅ Is the active mode system proxy, TUN or in-app proxy?
- ✅ Does the default exit in rule mode fit the current use case?
- ✅ Do the DNS settings match the split-tunneling mode, and does the browser have separate resolution settings?
- ✅ Is the system time accurate? Certificate checks and time-sensitive authentication both depend on it.
- ❌ Do not copy “optimization parameters” indiscriminately from unknown sources. Parameters must match the server and local network conditions.
How to locate connection failures layer by layer
The practical value of knowing these terms is understanding which layer to check when something goes wrong. If the subscription cannot update, check the link status, network access and the client’s parsing capability. If it updates but no nodes can connect, check protocol support, authentication parameters, system time and local network restrictions. If only some nodes fail, the cause is more likely a specific endpoint, route or protocol configuration.
If the client shows as connected but an app still uses the local network, check whether the app is handled by the system proxy or TUN. If global mode works but rule mode does not, inspect rule matches and DNS. If a domain will not open but a known address connects directly, the issue is more likely in the resolution path. If the domain resolves but the connection times out, continue checking the route, node and destination service response.
Change only one variable at a time when troubleshooting. For example, keep the same protocol and mode while switching nodes, or keep the same node while changing from rule mode to global mode. If you update the subscription, change the protocol, enable TUN and modify DNS simultaneously, even a successful result will not reveal which change helped, making similar problems difficult to reproduce later.