The hardest part of getting started with a VPN is often not installation, but understanding subscriptions, nodes, protocols, rule modes, and latency tests in the client. Each answers a different question: where the configuration comes from, where traffic travels, how data is transmitted, and which requests use a proxy. Once these layers are separated, importing a subscription, choosing a route, and troubleshooting become much clearer.

In everyday discussions, “VPN” is often used as a catch-all term for network acceleration, encrypted tunnels, and proxy subscription services. Strictly speaking, a client may use a traditional VPN protocol or a proxy protocol such as Shadowsocks, VMess, Trojan, VLESS, Hysteria2, or TUIC. Their configuration formats, transport methods, and network compatibility differ, so a broad label alone cannot predict performance.

What Are Subscriptions, Subscription Links, and Clients?

A subscription is a continuously updated set of configurations

A subscription is a configuration list published by the service. It typically includes node names, server addresses, ports, protocol parameters, authentication details, and transport settings. Instead of entering every field manually, you can import the subscription into a compatible client, which then reads the currently available configurations.

A subscription is not the client itself. A client is software installed on Windows, macOS, Android, iOS, or another operating system; it parses configurations, establishes connections, and applies routing rules. The subscription is the data source the client uses. Whether one subscription works across platforms depends on each client’s support for its protocols and fields.

Treat subscription links like credentials

Subscription links usually contain an access token used to identify an account. Anyone who obtains the link may be able to read the configurations, so do not post it in public groups, screenshots, or public code repositories. If you suspect the link has been exposed, reset the subscription in the service dashboard instead of simply deleting it from the local client.

“Update subscription” in a client means fetching the configuration list again. When the service changes node names, route entry points, or supported protocols, the old local list does not update by itself. Updating synchronizes it. It usually does not switch the current node automatically, so check the selected route afterward.

Quick takeaway: The client is the execution tool, the subscription is the configuration list, and the subscription link is the credential used to retrieve it. If importing fails, first check whether the client supports the subscription format, then verify that the link is complete. Do not immediately blame the node.

How to Distinguish Nodes, Entry Points, Exit Points, and Route Names

A “node” is one of the most common choices in a client, but a node name may combine a region, entry point, exit point, protocol, and provider label. The name is only an identification label; it does not mean all traffic passes through one physical server. After the entry point, the service may relay traffic, balance loads, or switch exits.

The entry point is the first location the client connects to, determining the first leg from the local network to the service network. The exit point is the public source location seen by the destination website, usually affecting content regions, search results, and service availability. Entry and exit points may be in the same place or separated by a relay route.

Node latency does not equal overall access speed

The latency shown by a client usually comes from a lightweight probe and only describes the round-trip response between the device and the test endpoint. It does not fully reflect the quality from the exit point to the destination website, nor does it directly represent video loading, large-file transfers, or evening congestion. Some nodes may not respond to the client’s probe method while remaining usable; conversely, a quick probe does not guarantee stable sustained transfers.

Term What it actually means Common misconception What to check in practice
Node An optional connection configuration in the client The same as one fixed physical server Region, protocol, route labels, and actual connectivity
Entry point The location where the device first connects to the service network Always the location seen by the website Route quality from the local network to the entry point
Exit point The public exit used when connecting to a destination website Always in the same region as the entry point Target region, exit quality, and website policies
Latency The round-trip time of a probe request A standalone measure of bandwidth and stability Judge it alongside real webpages, downloads, and sustained connections

When choosing a route, filter by the target region first, then compare connectivity on the local network. For ordinary webpages, connection setup and packet loss are easy to notice. For streaming, also check whether the exit suits the target region and whether sustained transfers remain stable. Remote collaboration places more emphasis on long-connection drops and route fluctuations. There is no single “fastest node” outside a specific use case.

Path Differences Between Direct, Relay, and IEPL Routes

Direct: From the local network straight to a remote entry point

A direct route connects the client to a remote server over the public internet. Its structure is simple and involves fewer intermediate control points, but quality is affected by the local carrier, international gateways, interconnection, and peak congestion. A direct route may be stable on one network and behave very differently in another region or access network.

Relay: Reach a nearby entry point first, then continue to the exit

A relay route first connects to an entry point relatively close to the user, then the service network sends traffic to the target exit. Its value lies in controlling cross-region paths that are more prone to fluctuation; it does not necessarily shorten the physical distance. Relay quality depends on the complete path from the local network to the entry point, from entry to exit, and from exit to the destination site.

IEPL: International Ethernet private-line capacity provided by carriers

IEPL stands for International Ethernet Private Line and generally refers to an international Ethernet private-line service provided by a carrier. For subscribers, an IEPL label usually means the provider uses private-line resources on parts of the intermediate path, not that each user’s device connects directly to a dedicated private line.

A private line can reduce some uncertainty on public international segments, but local access, entry-point load, the exit network, and the destination website still affect the final experience. “Private line” should therefore be understood as route-topology information, not a fixed speed promise for every situation. Troubleshooting still requires checking the device, client, protocol, and destination service.

Route type Typical path Main characteristics Scenarios to test first
Direct Device to a remote entry point over the public internet A direct path, strongly affected by public-internet routing changes The local route to the target region is stable
Relay Device to a nearby entry point, then to a remote exit The service network controls part of the cross-region path Direct routes fluctuate or interconnection is unstable
IEPL Private-line resources used between the entry and exit points Reduces some uncertainty on public international segments Sustained connections, cross-region transfers, and peak periods

What Common Protocols Do

A protocol defines how the client and service establish a connection, authenticate identities, encapsulate data, and transmit it over the network. A protocol does not determine speed by itself; actual performance is also affected by the route, congestion control, encryption implementation, device performance, and local network limits. The client must support the protocol published by the service. Otherwise, a subscription may import successfully while the connection still fails.

Shadowsocks

Shadowsocks is an encrypted proxy protocol. Its configuration typically includes a server address, port, password, and encryption method. It is mature and relatively lightweight, making it common for web access and general network acceleration. The encryption method must match on the client and service; an older client that lacks support for the method used by the subscription may show the configuration while failing to connect.

VMess and VLESS

VMess is common in configurations based on the V2Ray ecosystem and includes a user identifier, transport layer, and security parameters. VLESS separates authentication from the encryption layer and usually works with TLS, REALITY, or another secure transport method. With VLESS, checking only the server address is not enough; verify that the transport type, server name, path, and security options all match.

Trojan

Trojan usually runs over a TLS connection, so its authentication details and certificate settings must be correct. A significantly incorrect client clock, a mismatched server name, or failed certificate validation can prevent the connection from being established. Do not disable certificate verification casually; first check that the subscription is current and the system time is correct.

Hysteria2 and TUIC

Hysteria2 and TUIC both rely heavily on QUIC and UDP transport, aiming to maintain efficient transfers on networks with jitter, packet loss, or long distances. They are not necessarily faster in every environment: if the access network restricts UDP, the router handles UDP sessions poorly, or the client implementation is incompatible, performance may be worse than with a TCP-based configuration.

Protocol Transport focus Configuration checks Common troubleshooting direction
Shadowsocks Encrypted proxy and lightweight transport Encryption method, password, and port Whether the client supports the encryption method
VMess Combination of authentication, transport, and security parameters User identifier, transport method, and host parameters Whether the subscription fields were fully parsed by the client
VLESS Authentication working with external secure transport TLS or REALITY, server name, and transport type Whether security parameters or public-key information match
Trojan TLS-based connection Password, server name, and certificate validation Whether the system time and certificate chain are correct
Hysteria2 QUIC- and UDP-based transport Authentication, TLS, and bandwidth parameters Whether the current network allows stable UDP communication
TUIC QUIC-based proxy transport User authentication, TLS, and congestion-control settings Whether the client core and configuration format are compatible
Protocol takeaway: Prefer a configuration recommended by the service and natively supported by the client. When the route is stable, there is no need to switch protocols repeatedly for the name alone. If UDP is restricted, certificates fail, or the client is incompatible, testing another protocol is more effective.

Choosing Between Global, Rule, and Direct Modes

A successful connection only means that a channel has been established between the client and node. Which apps and domains enter that channel is determined by the operating mode and routing rules. A common beginner issue—“the client says connected, but a website still will not open”—is often caused by a rule sending the request direct or by system traffic not being routed through the client, rather than by a failed node.

Global mode

Global mode generally sends every request the client can take over through the current node. It is useful for temporarily verifying a node and finding missing rules. If global mode works while rule mode does not, the issue is usually rule matching, DNS resolution, or an app bypass setting rather than the node itself.

Rule mode

Rule mode uses domains, IPs, apps, or rule sets to decide whether traffic is proxied, sent direct, or rejected. It is better suited to everyday use, keeping local services direct while sending cross-border requests through the appropriate node. Rules have priorities, and an earlier match usually runs first; an overly broad direct rule can override later proxy rules.

Direct mode

Direct mode sends requests without using a proxy node and is commonly used to pause the service or test the local network. If the client remains running in the background, switching to direct mode is not necessarily the same as fully exiting, because DNS, a virtual network adapter, or system proxy settings may still be managed by the client. When troubleshooting system networking, confirm both the operating mode and the client’s traffic-capture status.

  1. Reproduce the issue in rule mode and record the specific app, domain, and selected node.
  2. Temporarily switch to global mode and visit the same destination.
  3. If global mode restores access, check rule-hit records, domain categories, and DNS policy.
  4. If global mode still fails, compare a node in the same region or a compatible protocol.
  5. After testing, restore the rule mode suited to everyday use instead of leaving the proxy scope expanded.

System Proxy, Virtual Network Adapters, and App Proxies

After a client establishes a connection, it still needs a way to capture device traffic. Common options include the system proxy, virtual network adapter mode, and a proxy configured separately inside an app. They cover different traffic scopes, which is why a browser may work while other software does not.

System proxy

The system proxy changes the proxy settings provided by the operating system. Browsers and apps that follow system settings usually use it automatically, but some games, command-line tools, store apps, or software with its own network stack may ignore it. If the system proxy is not restored before closing the client, apps may continue trying to connect to a local proxy port that is no longer running.

Virtual network adapter mode

Virtual network adapter mode captures more system traffic by creating a virtual network interface. Its coverage is usually broader than that of the system proxy, making it useful for apps that do not support proxy settings. It requires the relevant system permissions and may conflict with other network-filtering software, enterprise endpoint policies, or existing virtual adapters. If the network goes offline, check the routing table, virtual adapter status, and whether DNS settings have been restored.

In-app proxy

Some browsers, development tools, and download tools let you specify a local proxy address separately. This provides precise control without automatically affecting other apps, but the client’s local listening port must match the app configuration. After the client resets its configuration, the local port may change and the old app setting will stop working.

DNS Leaks, Resolution Failures, and Routing Rules

DNS translates domain names into network addresses. After a proxy connection is established, if domain lookups are still sent directly to a resolver on the local network while access requests use the proxy exit, the resolution path and access path may be separated. This is commonly called a DNS leak. It may expose the resolver network in use or cause the domain to return results unsuitable for the proxy exit.

DNS issues are not only a privacy concern; they can directly affect availability. The same domain may return different addresses depending on the resolver, local caches may retain old results, and a rule system may need to resolve a domain before deciding whether a request should go direct or through the proxy. A working node therefore does not guarantee that domain resolution is working correctly.

Common client DNS strategies include sending queries through the proxy channel, resolving them separately according to routing rules, and using virtual addresses to assist rule matching. Field names and behavior vary by implementation, so do not copy one client’s configuration unchanged into another. After switching clients, reread its DNS and virtual-adapter documentation.

  1. Determine whether all websites are inaccessible or only a specific domain fails.
  2. Update the subscription and rules to rule out resolution-category errors caused by an old configuration.
  3. Test the same domain in global mode to determine whether routing rules are involved.
  4. Clear the operating system and browser DNS caches, then test again.
  5. Check the client’s DNS logs to confirm that the query path matches the access rules.
DNS troubleshooting takeaway: If the node connects but a domain will not open, do not run only a latency test. Check the resolution path, rule matches, and cache state together, especially whether DNS queries and actual access use compatible exit policies.

Windows, macOS, Android, and iOS Client Differences

The same subscription can produce different results on different platforms. The cause is usually not an account difference but variations in the client core, system permissions, background policies, and protocol support. When choosing a client, start with the service’s recommended list, then confirm that the required protocols and modes are supported.

Desktop systems

Windows clients commonly provide both a system proxy and virtual network adapter mode, but adapter drivers, permissions, and security software may affect installation. macOS centralizes network extensions and system permissions more tightly, so the first activation may require approval of the network configuration. Desktop troubleshooting can usually inspect connection logs, rule hits, and local ports, which tend to provide more detail.

Mobile systems

Android clients generally capture traffic through the system VPN interface and may support per-app routing. Device makers’ background power-saving policies can affect long-running connections, and suspending the client may trigger reconnects. iOS likewise depends on the network-extension capabilities provided by the system; background behavior and supported protocols depend on the client implementation and system restrictions.

A connection indicator in a mobile status bar only shows that the system network extension is running. It does not confirm that the current node, DNS, and rules are behaving as expected. If one app cannot connect, check whether it is excluded, whether a rule matched direct access, and whether background policies stopped the client from refreshing the subscription.

Platform Common traffic-capture methods What to watch for Troubleshooting entry points
Windows System proxy, virtual network adapter Drivers, permissions, and other network software Connection logs, system proxy, and route status
macOS System proxy, network extension Network-configuration approval and system permissions Network settings and client logs
Android System VPN interface, per-app routing Background power saving and app-exclusion rules Per-app routing, background permissions, and connection logs
iOS System network extension Client protocol support and background status Connection configuration, rules, and client logs

A Complete Beginner’s Workflow: From Import to Troubleshooting

When faced with a list of unfamiliar terms, the most effective approach is not to toggle settings at random but to check the network path in order. First confirm that the subscription can be read, then that the protocol can establish a connection, followed by traffic capture, rule decisions, DNS resolution, and the destination site. This prevents repeated routing changes before the node is connected and avoids mistaking a DNS issue for a protocol issue.

Also distinguish between a connection failure and an access failure. A connection failure usually occurs between the client and node; logs may show a timeout, authentication error, TLS error, or unreachable UDP. An access failure occurs after the connection is established and may be caused by routing, DNS, the exit region, destination-site policies, or an app that is not using the proxy. The two cases require different layers of investigation.

When contacting support, provide the operating system, client name, protocol, node region, operating mode, time of the error, and the comparison tests already completed. If logs contain a subscription token, authentication details, or complete server credentials, redact them first. A clear record of variables is more useful for troubleshooting than simply saying “the node does not work.”