When setting up a network accelerator for the first time, the hardest part is often not finding the buttons but understanding what “subscription,” “node,” and “protocol” mean. In simple terms, a subscription delivers configuration to the client, a node is a selectable connection entry point, and a protocol defines how the client communicates with the server. IEPL dedicated lines, relays, direct connections, rule mode, and DNS settings further determine the route data takes, which requests are handled, and where domains are resolved.
These concepts are related, but they are not interchangeable. A successful subscription import does not mean every node can connect, identical node names do not guarantee identical routing, and a newer-looking protocol is not necessarily better for every network environment. Understanding where each term fits is far more effective than repeatedly switching clients or changing settings blindly.
Where subscriptions, nodes, and protocols fit
Think of a connection as a process that starts with obtaining configuration, moves on to choosing an entry point, and then transmits data according to an agreed method. Subscriptions, nodes, and protocols correspond to these stages. The client applies the configuration, while the route is the network path the data actually follows.
| Term | What it means | Common misconception | What to check |
|---|---|---|---|
| Subscription | A collection of configurations provided by the service. The client reads nodes and related parameters from the subscription URL. | Mistaking a subscription for a transport protocol. | Whether the URL is correct, can be updated, and is stored securely. |
| Node | A selectable connection profile in the client, usually containing a server address, port, protocol, and authentication details. | Assuming the node name is the server’s complete physical location. | Target region, route type, and connection performance on the current network. |
| Protocol | The communication method and authentication rules used between the client and the remote service. | Judging speed and stability from the protocol name alone. | Client support, network compatibility, transport-layer settings, and security configuration. |
| Route | The actual routing and transport path between the local network and the remote exit. | Treating a route and a node as exactly the same thing. | Direct, relay, or dedicated-line structure, plus evening congestion and route changes. |
| Client | A local application that reads configuration, establishes connections, applies routing rules, and handles DNS. | Assuming every client uses identical option names and default behavior. | System permissions, core support, rule mode, and update methods. |
How to import and update a subscription link
A subscription link is usually a dedicated URL generated by the service. After accessing it, the client retrieves a node list, protocol parameters, and group information, then converts them into selectable profiles. It is closer to a “configuration source” than to an ordinary webpage meant for people to read.
A subscription URL often contains credentials used to identify an account configuration, so it should not be posted publicly in forums, screenshots, or shared documents. Anyone who obtains the link may be able to read its node information. When using it on another device, transfer it through a trusted channel and delete the old configuration from clients no longer in use.
Import steps vary by client. Common options include “Import from URL,” “Add remote configuration,” “Subscription management,” and “Import from clipboard.” If the service provides a QR code, make sure the client is scanning a subscription configuration rather than a single node. A single-node import usually will not receive later route changes automatically, while a subscription update can sync changes released by the server.
- ✅ Copy the complete subscription URL from the service dashboard, making sure the beginning, parameters, and final characters are included.
- ✅ In the client, choose remote subscription or URL import instead of manually creating an incomplete node.
- ✅ Run an update after importing and confirm that selectable regions and routes appear in the list.
- ✅ Select a node and start the connection, then use a regular webpage to verify basic access.
- ✅ When server-side routes change, refresh the subscription first instead of repeatedly changing the port in an old profile.
- ❌ Do not publish the subscription URL on a public page or submit it to an online conversion tool from an unknown source.
Keep in mind that refreshing a subscription may overwrite local changes made under that subscription with remote content. If you only need to adjust routing rules, use the client’s local overrides, rule sets, or separate configuration features where available. Direct edits to parameters generated by a subscription often disappear after the next update.
Why nodes and routes are not the same thing
Each entry in a client’s list is generally called a node. A node configuration needs, at minimum, a remote address, port, protocol, and authentication details. It may also include a transport method, TLS domain, server name indication, congestion control, or UDP options. The node name is simply a label for identification, not a complete technical description.
A route refers to the network path. The same region may offer nodes using different paths, and an entry point may forward traffic to another exit after it reaches the service. Therefore, “choosing a node for a region” only indicates the expected exit or the region shown by the service; its name alone cannot reveal which carriers or networks the traffic crosses in between.
When choosing a node, start with the region where the target service is located, then consider connection stability. Web browsing depends more on successful handshakes and consistent responses; video playback depends on sustained throughput and jitter; voice, meetings, and real-time interaction are more sensitive to packet loss, jitter, and route detours. A single latency reading is only a reference and cannot replace performance during sustained use.
Why a low latency reading can still feel slow
A client’s latency test usually checks only one probe address or a single handshake. It may not cover the target website, DNS resolution, actual transfer load, or long-lived connection maintenance. A route may respond quickly during a short probe but become congested during sustained transfer. Conversely, an average probe result may lead to a more stable route to the target service.
The recommended selection order is therefore: choose a region that fits the task, confirm that the connection establishes reliably, verify that the target app remains usable, and only then compare the displayed latency. Chasing the smallest number in the list can lead to frequent switches to nodes that are not suited to the task at hand.
How to understand Shadowsocks, VMess, Trojan, VLESS, Hysteria2, and TUIC
A protocol determines how the client and server authenticate, encapsulate, and transmit data. The resulting experience is also affected by server load, route quality, the transport layer, client implementation, and the local network. A protocol name cannot be equated directly with “faster” or “more secure,” and protocol fields should not be replaced without understanding the server-side configuration.
| Protocol | Main characteristics | Configuration details to check | When it is commonly suitable |
|---|---|---|---|
| Shadowsocks | A relatively simple structure that uses a pre-shared key and a specified encryption method to transmit proxy traffic. | The encryption method, password, server address, and port must match the server. | Widely supported by clients and suitable for environments with clear configuration and normal network compatibility. |
| VMess | Supports identity authentication and a broad range of transport combinations, often appearing with WebSocket, TCP, or TLS settings. | The user ID, transport method, path, hostname, and TLS settings must match completely. | Can be stable when a mature server-side configuration is available; do not copy only part of the parameters. |
| Trojan | Usually built on TLS and authenticated with a password; certificate and domain verification are important parts of the connection. | The server name, certificate validity, password, and port must be correct. | Suitable where the network has good compatibility with standard TLS connections. |
| VLESS | Uses a lightweight authentication and protocol structure; security typically depends on correctly pairing TLS, REALITY, or another transport security layer. | The user ID, flow control, transport layer, security layer, and server name must not be mixed between profiles. | Suitable for modern client environments where the server provides a complete set of parameters. |
| Hysteria2 | Built on QUIC and UDP, with congestion-control design intended for unstable links. | Whether the local network permits stable UDP, along with authentication details, the TLS domain, and bandwidth policy. | May perform well when the UDP path is good, but may fail to connect on restricted networks. |
| TUIC | Also based on QUIC, designed for low-latency concurrent transport, and dependent on UDP reachability. | Client core version, authentication parameters, certificate verification, and the UDP environment. | Suitable when both the server and client fully support it and the UDP path is stable. |
Protocols cannot be converted simply by renaming them. For example, changing a VLESS node’s type to Trojan does not make the server accept a different handshake, and disabling TLS verification is not a universal troubleshooting method. When parameters are delivered by a subscription, they should generally be left unchanged. Manual node creation or editing is appropriate only when you understand the server-side configuration.
Hysteria2 and TUIC both depend on UDP, but “UDP support” does not mean every network can carry it reliably. Office networks, public networks, or certain routing devices may restrict UDP sessions; in those cases, nodes based on TCP and TLS may establish connections more easily. Choose a protocol based on actual network compatibility.
What is the difference between IEPL dedicated lines, relays, and direct connections?
A direct connection usually means the client connects straight to the remote node, with the intervening path determined mainly by public routing. The structure is simple, but routes across carriers or regions may detour and are more exposed to public-network congestion and route changes. Direct does not necessarily mean short; it only means no additional server-side relay entry point has been configured.
A relay route typically connects first to a nearby or better-positioned entry point, which then forwards traffic to the target exit. A relay can optimize parts of the public-network path and improve consistency across different carriers. It also adds a processing stage, so an issue at either the entry or exit can affect the connection.
IEPL is a common term for international Ethernet private-line services, emphasizing controlled dedicated-line transport and point-to-point connectivity. An “IEPL dedicated-line node” usually means that part of the cross-border backbone uses dedicated-line resources, while local access from the device to the entry point and the final path from the exit to the target website may still use ordinary networks. A dedicated line should therefore not be understood as an exclusive physical path from the device to every website.
| Route type | Typical path | Main characteristics | How to choose |
|---|---|---|---|
| Direct | Local network directly to the remote entry point | A straightforward structure whose performance is noticeably affected by public routing. | Test it first when the current carrier has a good route to the target region. |
| Relay | Local network to an access point, then forwarded to the exit | Can optimize some cross-network paths, but depends on both the access point and exit remaining stable. | Try it when direct routes detour, jitter is pronounced, or performance varies across carriers. |
| IEPL dedicated line | After local access, through a controlled dedicated-line segment to the remote network | The backbone path is generally more controllable, but local access and the final path to the target website remain important variables. | Compare it with other routes when sustained connections and path stability matter. |
How to choose between global mode, rule mode, and direct mode
Global mode usually sends most traffic the client can take over through the current proxy node. It is useful for checking whether an app works only through a node, but it may also send local services, LAN devices, or sites that need no proxy through a remote route. It is not always the best long-term default.
Rule mode decides whether a request uses a node, connects directly, or is blocked based on its domain, IP, app, or rule set. Common logic includes direct connections for local and LAN addresses, routing selected international services through a node, blocking advertising or risky domains, and sending unmatched requests to a default policy. Rule mode is better suited to everyday use, but depends on rule quality and DNS coordination.
Direct mode usually means that requests do not pass through a proxy node. It can be used to access local-network resources and to check whether the client is affecting the original network. Direct mode does not necessarily mean the client has exited: some clients may retain a virtual network adapter, DNS takeover, or system proxy settings. To disable it completely, use the client’s stop-connection function.
Why rules can match incorrectly
Domain rules need to evaluate a domain while it is still visible; IP rules depend on resolution results and address databases. Modern websites often load a main domain, content delivery network, login domain, and API domain at the same time. If rules cover only the main page, the page may open while images, login, or video fail.
For this type of problem, temporarily switch to global mode for comparison. If global mode works but rule mode fails, focus on rule matches, DNS resolution, and related domains. If both modes fail, continue checking the node connection, protocol parameters, or the target service itself.
What do DNS leaks and resolution errors actually mean?
DNS converts domain names into network addresses. A DNS leak generally means that domain queries expected to be handled through the proxy route or a designated resolver are instead sent through another path on the local network. This may expose domain-resolution activity or cause regional detection errors, route detours, or failed resource loads when local and remote resolvers return different results.
DNS problems do not always mean a site is completely unreachable. More commonly, the main page works while an API, image, or login domain resolves to an unsuitable address; switching nodes does not change the result because it remains cached by the system; or an app resolves a request to an IP before domain-based rules can evaluate it, so the expected rule never matches.
Options such as “remote DNS,” “proxy DNS,” “local DNS,” “system DNS,” and “Fake IP” behave differently depending on the client. Remote DNS generally means queries are sent through the proxy or handled remotely; local DNS follows a path closer to the current network; Fake IP mode first returns a mapped address, then lets the client restore the domain and apply rules. It helps preserve domain information but may be incompatible with some LAN services or specialized apps.
- ✅ Check that the system proxy, virtual network adapter, and client DNS mode match the goal of the current configuration.
- ✅ After switching nodes, clear the client’s connection state and, if necessary, refresh the system DNS cache.
- ✅ If some page resources fail, check whether related domains were assigned the wrong policy.
- ✅ If LAN devices cannot be reached, confirm that private addresses and local-domain rules remain direct.
- ❌ Do not run multiple network tools that take over system DNS or virtual network adapters at the same time.
- ❌ Do not leave certificate verification disabled for troubleshooting or use resolver addresses from unknown sources.
Why clients on different platforms are not configured exactly the same
Windows and macOS clients often provide both system-proxy and virtual-network-adapter modes. A system proxy mainly affects apps that follow the operating system’s proxy settings, while some programs may bypass it. A virtual network adapter can take over a broader range of traffic but requires the relevant system permissions and is more likely to conflict with other network software over routing or DNS.
Android usually uses the system VPN interface to take over traffic, and clients may offer per-app routing. Battery-saving policies, background restrictions, and network changes can affect long-lived connections. If the connection drops after the screen locks, check the client’s background-running permission before assuming the node is at fault.
Apple mobile platforms likewise rely on the networking extension capabilities provided by the system. Supported protocol cores, rule formats, and subscription conversion methods vary between clients, so a configuration imported on desktop may not be fully recognized on mobile. If nodes are missing after import, first check whether the client supports the relevant protocol and transport method.
On Linux, graphical clients, command-line cores, proxy environment variables, and transparent proxies can coexist. If a browser works but terminal commands do not, they are usually reading different proxy settings. Conversely, setting proxy environment variables for the command line does not automatically make every desktop app use the same route.
When moving between platforms, the safest approach is to import the subscription again rather than copy a client’s internal database. Rules, certificate storage, virtual-network permissions, and core versions differ by platform. Read the quick start guide first, then choose the connection method for your system.
What order should you follow when a connection fails?
Start troubleshooting with basic reachability and narrow the scope step by step. Changing several options at once removes a useful point of comparison and can damage a subscription that was working correctly. After each action, retest the same target so you can identify what caused the change.
- Check the local network: Pause the client and see whether ordinary websites are accessible. If the underlying network is already failing, switching protocols usually will not help.
- Refresh the subscription: Confirm that the subscription can update and check whether the node list is complete. If the update fails, make sure the link was copied in full and the system time is correct.
- Try another node of the same type: Stay within the same protocol and switch to another region or route to determine whether the issue affects one node or the entire protocol type.
- Compare protocols: If a UDP-based configuration cannot establish a connection, test another compatible protocol provided by the server. Do not manually convert the existing node to a different protocol.
- Change routing mode: Temporarily use global mode for comparison when rule mode behaves abnormally. If only global mode works, the rules or DNS usually need review.
- Check system takeover: Close duplicate proxies, virtual-network adapters, or network-filtering tools to prevent routing and DNS from being modified in multiple places.
- Keep the error details: Review client logs for timeouts, authentication failures, certificate errors, DNS failures, or unreachable UDP. When contacting support, provide the error type, platform, and node name; this is easier to diagnose than simply saying “it won’t connect.”
Once these terms are clear, setup becomes much easier to follow: import and update the subscription, choose a route for the target region from the node list, let the client establish the connection with the protocol parameters supplied by the server, and use rule mode and DNS settings to determine how traffic is handled. When something goes wrong, check subscriptions, nodes, protocols, routes, routing rules, and DNS in that order—it is usually more effective than repeatedly reinstalling the client.