VPN terms make more sense when you follow the connection flow: a subscription provides configuration, a node is a connection endpoint, a protocol defines how data is exchanged, and routing rules decide where requests go. These are not interchangeable options. Understand how they fit together, and you can tell the difference between a configuration that hasn't been imported, a route that won't connect, and a rule that didn't match.
A quick glossary: what each term does
In everyday conversation, VPN often refers broadly to tools for cross-border network access. But products may use a system VPN tunnel, proxy protocols and a rule engine in different combinations. Seeing “VPN connected” in a client doesn't mean it uses a traditional VPN protocol—or that every app is routed through the same exit.
| Term | What it does | Common point of confusion |
|---|---|---|
| Subscription link | Lets a client fetch and update connection settings | It's neither a bookmark nor the billing period itself |
| Node | Contains settings such as server address, port, authentication and protocol | The region in its name doesn't reveal the full route |
| Route type | Describes the network path, such as direct, relayed or dedicated | It's not the name of an application-layer protocol like Shadowsocks |
| Protocol | Defines how the client and server communicate | The protocol name alone can't tell you the actual speed |
| Routing rule | Selects how to handle traffic based on a domain, address or other condition | Rule mode doesn't mean all international websites use a proxy |
| DNS | Resolves a domain name to an address the client can connect to | The DNS lookup path may differ from the subsequent connection path |
Requests typically enter the client first, pass through rule matching, then go direct, through a proxy or get blocked according to the result. If a proxy is selected, the client uses the corresponding node and protocol to connect. A subscription supplies these settings and may also include rules and policy groups.
Subscription links: a configuration source, not a payment button
“Subscription” has two meanings: billing and configuration. On a plan page, a monthly subscription refers to how the service is billed. In a client, a subscription URL usually points to configuration data. Users with a data package may also import nodes through a subscription link; a plan that isn't billed monthly may still require one.
A subscription link may return a node list or a complete configuration with policy groups, DNS settings and routing rules. Clients accept different formats, so the same link may not work in every app. If import fails, check the client type and the provider's import instructions instead of repeatedly pasting the same content.
The first import and later updates are different steps. Importing adds a configuration source; updating fetches its latest contents. An update may change the node list without replacing local settings, depending on the client. If plan details change, update the subscription first, then check that the account status and client display match.
Nodes and routes: a region label isn't the whole path
A node is usually a set of connection settings, named in the interface by region, city or purpose. Its name helps you choose, but isn't technical proof. A node labeled Tokyo may describe the exit location, while the first endpoint the client connects to could be elsewhere. To check the exit a website sees, look at the actual exit address rather than relying on the node name.
A direct route usually means the device connects to an overseas endpoint without an additional relay arranged by the service; traffic still travels across the carrier network and internet routes. With a relay, traffic first reaches one endpoint, which forwards it to another server. A relay may improve some network conditions, but it can also add hops, so it doesn't automatically mean a faster connection.
IEPL usually refers to an international Ethernet private line. In subscription service descriptions, it often means that part of the route uses a dedicated link; it doesn't mean every segment from your home router to the destination website is dedicated. Local access quality, endpoint load, the exit and the destination website can all affect performance.
So “Japan node,” “IEPL route” and “a particular protocol” can all describe the same connection: the region indicates the exit, the route type describes the path, and the protocol defines how data is exchanged. Choose a region that suits your needs, then test it on your own network and at your usual times. Labels don't guarantee access to a streaming service or work platform.
Protocol names: check compatibility, then network conditions
Shadowsocks, VMess, Trojan, VLESS, Hysteria2 and TUIC are common proxy protocols or related implementation ecosystems, not plan tiers. The client must support the protocol and configuration format, and the server must be set up to match. Changing the protocol name in a client won't make the original node work with a different protocol.
- Shadowsocks: A widely used encrypted proxy protocol. Both ends need matching encryption settings and authentication details. Capabilities vary by implementation and version.
- VMess and VLESS: Both are common in the proxy tools ecosystem, but they're different protocols. VLESS doesn't encrypt content by itself and is often used with secure transports such as TLS. The name alone doesn't tell you how a connection is protected.
- Trojan: Typically uses TLS to protect data in transit. Certificate validation and server name settings matter; don't leave verification disabled just to get past an error.
- Hysteria2 and TUIC: Both use UDP-based QUIC technology, but they're different protocols and their configurations aren't interchangeable. Network restrictions on UDP can affect connectivity.
A newer protocol isn't necessarily faster in every environment. Client core support, network restrictions on the transport, server load and the destination's response all affect performance. This article explains the terminology; check the control panel and user guides for the protocols and clients CitiVPN actually supports.
Split tunneling and global mode: first check whether traffic reaches the client
Rule mode handles requests according to conditions such as domain, destination address or process. Rules are usually evaluated in order; a match triggers an action such as direct connection, proxying or blocking, while unmatched requests follow a fallback rule. If a work app has trouble connecting, its domain may be missing from the rules—or the app may not be routed through the proxy at all.
Global mode generally sends traffic that has already entered the proxy engine through the selected proxy policy. It doesn't guarantee that every app is captured or that all UDP and DNS requests are included. A system proxy usually affects apps that follow the system proxy settings; programs that ignore them may still connect directly.
TUN mode uses a virtual network interface to capture traffic, so it can cover more apps that don't follow system proxy settings. Its reach still depends on routing, exclusions, permissions and the client implementation. TUN describes how traffic is captured; global and rule modes describe how it's handled. They operate at different levels.
Windows, macOS and Linux clients may offer system proxy and virtual network interface options, with support varying by app and core. iOS and Android typically route traffic through the system VPN interface, but a VPN indicator in the interface doesn't replace checking the rules. Whether per-app routing is available on Android depends on the client; don't assume desktop platforms offer the same feature.
DNS and exit routes: verify after connecting
DNS lookups find the address for a domain, while the website connection carries the content that follows; they may take different routes. If DNS queries are expected to use a particular resolver but are sent over the local network instead, this may be what people call a DNS leak. Assess it against the intended configuration; an unfamiliar region on a test page alone isn't enough to draw a conclusion.
Encrypted DNS in the browser, system DNS, the client's built-in resolver and enterprise network policies can all interact. If a website won't load but other apps work, check whether the browser uses its own DNS settings. Clients using Fake-IP may first return a virtual address, then map it to the destination themselves; that address isn't the website's actual exit.
Use What's my IP? to check the exit your browser sees, then review client logs to confirm rule matching and DNS handling. A matching exit only shows that the test request took the expected route; it doesn't prove that other apps do too. A network connection configuration doesn't replace website login checks, account permissions or a platform's own regional policies.
Beginner checklist: troubleshoot by layer
When getting started, don't change the protocol, DNS and rules all at once. Keep a restorable copy of the original settings, change only what relates to the problem, then retry the same destination. That way you can tell what caused the change and give support a clearer description of the issue.
- ✅ Check your account and plan status, then get the client and subscription instructions for your platform from the control panel.
- ✅ Import the subscription as directed by your client and confirm that the node list appears. If an update fails, check the format, link validity and error message.
- ✅ Choose a region that suits your needs and connect with the recommended default settings. Don't edit protocol parameters you don't understand.
- ✅ Open the target app and check the exit and connection logs to tell “the node won't connect” apart from “the request isn't being proxied.”
- ✅ If one website has a problem, check the rules, DNS and platform requirements. If every app has a problem, check your local network and client connection status.
- ✅ When reporting an issue, include your platform, client name, selected node and what happened. Hide subscription links and authentication credentials before sharing logs.
CitiVPN doesn't require an email address; create an account with a username and password. Download clients from the download page in the control panel; sign in to get your subscription. Client downloads are available after signing in on Windows, Android, macOS and Linux; iOS requires an active plan. For step-by-step import instructions, see the getting started guide. For configuration questions, visit the Help Center.
Keep this troubleshooting order in mind: did the subscription fetch the configuration, can the node connect, is the app's traffic being captured, and do the rules and DNS behave as expected? Investigating the right layer is more effective than repeatedly switching nodes.