Here’s a quick guide to VPN terminology, starting with how the pieces fit together: a subscription provides configuration, a node determines where you connect, a protocol defines how data is exchanged, and routing decides which requests take which path. These are separate settings, and none can replace another. Once you understand how they relate, you can troubleshoot issues like “connected, but websites won’t load” step by step instead of repeatedly switching clients.
How subscriptions, nodes, and clients work together
In everyday conversation, “VPN” is often used as a catch-all term for network proxy services, but a system-level VPN tunnel and an application proxy aren’t exactly the same thing. A client may configure a system proxy, or it may route traffic through a virtual network interface. A “Connected” status only confirms that one part of the connection is established; it doesn’t mean every app is using it.
| Term | What it means | Common misconception |
|---|---|---|
| Client | Software that reads configuration, establishes connections, and applies routing rules. | Installing the software automatically gives you a working route. |
| Subscription link | An address the client uses to retrieve or update connection settings. | The link itself is a node. |
| Node | A connection profile, typically containing an address, port, authentication details, and transport settings. | A node’s name proves its actual exit location and route quality. |
| Protocol | The communication and authentication method agreed on by the client and server. | Switching to a particular protocol will always make the connection faster. |
| Proxy group | A selection group for nodes, direct connections, or other policies. | Once you select a proxy group, there’s no need to check which option is selected inside it. |
| Routing rule | A rule that directs requests based on criteria such as domain, destination address, or process. | Every app automatically follows the system proxy. |
“Subscription” can also refer to billing. A monthly subscription describes a payment and data allowance cycle; a subscription link describes how configuration is distributed. They’re not the same thing. Data-package users may also use a subscription link to retrieve settings. And while a client can update its configuration, that doesn’t mean the plan still has data remaining or is active.
A node’s region label usually indicates its exit region, but the entry point, relay server, and final exit can all be in different locations. To check the region, consider both an exit-location test and the destination service’s assessment rather than relying on the node label alone. See the route list for an overview. For specific available configurations, check the dashboard and your client.
How to import and protect a subscription link
Subscription links often contain account-linked access credentials and should be treated as sensitive information. Sharing a link could let someone else view your configuration or use your account’s data. Hide the full address and QR code in screenshots, and don’t paste the link into online conversion tools from unknown sources, even when troubleshooting an import.
- Get your configuration from the service dashboard. VPNCoast subscription details are available in the dashboard. You’ll need to log in to download the client, and an active plan is required for the iOS download. Check your platform, then follow the relevant quick start guide.
- Check which formats your client supports. Some clients read full configuration files, while others accept only specific subscription formats. A link opening in your browser doesn’t mean its contents are compatible with your client.
- Use the import subscription or add configuration option. You can label the profile yourself, but don’t change authentication details, server addresses, or transport settings. After importing, update the configuration and make sure the list isn’t empty.
- Select the configuration and the actual node. Some clients let you save multiple configurations. After importing, you still need to enable the right one; in a proxy group, you also need to select a target node or policy.
- Check the route after connecting. Open the app you want to use and verify the exit region and access result. If only one app fails, check whether it’s using the proxy.
Direct, relayed, and dedicated routes: what’s the difference?
Route types describe the network path; protocols describe how data is exchanged. These are separate dimensions: the same protocol can run over different paths, and the same route type can carry different protocols. A label like “dedicated line” or a protocol name alone doesn’t tell you the speed, latency, or streaming performance.
Direct and relayed routes
In route descriptions, “direct” usually means connecting to an overseas server without a provider-operated relay entry point. Data still travels through carrier networks and routing equipment. A relayed route first connects to an entry point, which forwards traffic to another server. Both the entry point and the onward route affect performance; a relay isn’t necessarily slower or more stable.
IEPL dedicated lines
IEPL usually refers to an international Ethernet private line, a dedicated Ethernet connectivity service. When a proxy route uses this type of link, it’s often just one segment of the end-to-end path. The connection from you to the entry point, and from the exit to the destination website, may still use other networks. So “IEPL” doesn’t mean the entire route is exclusively dedicated end to end, nor does it confirm that this service has any configuration that hasn’t been published.
There’s another easily confused use of “direct”: in routing rules, DIRECT usually means a request bypasses the proxy and accesses the internet over your local network. That’s not the same meaning as “direct route” in a node list. When troubleshooting, first check whether the term appears on a rules page or in a route description.
What common protocols mean
The client and server must both support a protocol. Changing the protocol name locally won’t change the server, and the connection will usually fail. The table below explains industry terms; it doesn’t mean VPNCoast offers every protocol listed. Check the client and dashboard for currently supported options.
| Protocol | Key features | What beginners should know |
|---|---|---|
| Shadowsocks | An encrypted proxy protocol that uses the encryption and authentication methods specified in its configuration. | The encryption method supported by the client must match the server’s. |
| VMess | A proxy protocol with its own authentication and encryption, compatible with different transport methods. | The transport method and settings such as TLS must also match. |
| Trojan | Typically uses TLS to protect proxy traffic and password-based authentication. | Verify certificates correctly; don’t leave verification disabled as a long-term troubleshooting workaround. |
| VLESS | A lightweight proxy protocol that doesn’t encrypt payloads on its own. | Protection depends on accompanying settings such as TLS or REALITY, so the protocol name alone isn’t enough. |
| Hysteria2 | A QUIC-based proxy protocol that relies on UDP for transport. | Local network restrictions on UDP can affect the connection. |
| TUIC | A QUIC-based proxy protocol that can carry proxy traffic. | Compatibility depends on the client implementation, protocol version, and network conditions. |
Protocols aren’t a speed ranking. Network congestion, the route to the entry point, exit quality, device performance, and server configuration can all matter more than the protocol name. If an import reports an unsupported format, first check your client version and configuration format instead of deleting fields you don’t recognize. For certificate errors, check the system clock, server name, and configuration source; don’t simply disable verification.
Global mode and rule-based routing
Rule-based mode routes requests according to criteria—for example, sending local services directly while routing destinations that need an international connection through a proxy group. Rules are usually matched in order, though the exact process depends on the client. A broad rule near the top may prevent a more specific rule below it from taking effect. Unmatched requests follow the fallback policy.
In proxy clients, global mode usually sends requests already handled by the client to a single policy. It doesn’t guarantee that all traffic on the device is captured. An app that ignores the system proxy may still use your local network, even when the client is in global mode.
TUN mode captures traffic that meets routing conditions through a virtual network interface. It can cover some apps that don’t use the system proxy, but it’s still affected by permissions, route exclusions, DNS settings, and app behavior. TUN, system proxy, and global mode describe different ways of handling traffic and making routing decisions; they aren’t interchangeable terms.
Understand the rules for everyday use; compare modes when troubleshooting. If a destination fails in rule-based mode but works in global mode, check which rule matched and what the proxy group selected. If both modes fail, continue by checking the node, DNS, plan, and destination service restrictions. Global mode can help narrow down an issue, but a single successful connection doesn’t prove its cause.
Automatic selection and failover are also proxy group behaviors. Automatic selection may choose a candidate node based on the client’s test results; failover switches after a node is judged unavailable. The test destination may differ from the website you want to visit, so verify the selected node in the actual app you’re using.
Checking DNS leaks and exit IPs
An exit IP is the source address a destination service sees for your connection. DNS translates domain names into addresses that can be reached. A changed web exit IP doesn’t mean DNS queries are using the expected route too. If queries still go through an unexpected local resolver, the domains you look up may be exposed, or the apparent DNS region may not match your connection’s exit region.
However, seeing a particular DNS provider on a test page doesn’t, by itself, prove there’s a leak. Remote resolution, encrypted DNS, browser Secure DNS, caching, and how the test tool determines locations can all affect the result. Check your client’s DNS settings, browser settings, and routing rules together rather than relying only on the region label shown by a test page.
- ✅ Compare your exit IP before and after connecting with the same test method, then try the destination in the app you actually use. Don’t assume a browser test reflects every app.
- ✅ Check how your client handles DNS and whether your browser has its own Secure DNS setting. Save the original settings before making changes so you can restore them.
- ✅ After changing routes or DNS settings, reconnect the app. If needed, clear relevant caches so old connections and DNS results don’t affect your assessment.
- ❌ Don’t repeatedly disable encryption, certificate checks, or other safeguards just because a displayed region looks wrong. That usually won’t identify the underlying routing issue.
Streaming and AI tools may also consider account region, licensing, and exit IP reputation. If the exit region looks right but access is still restricted, that doesn’t necessarily mean there’s a DNS leak. Route coverage alone can’t guarantee access.
Common terms in different platforms and billing screens
Windows and macOS clients often have system proxy and TUN switches; TUN may require extra permissions. Android clients commonly use the system VPN interface to handle traffic, and some support per-app routing. iOS typically relies on a system network extension to connect. Linux may require a combination of desktop proxy settings, environment variables, or routing configuration. Check the specific client to see what it supports rather than relying on the operating system name alone.
Browser extensions generally affect only requests from browsers they support; they shouldn’t be treated as system-level connections. Running multiple traffic-handling tools at once can also cause routing and DNS conflicts. When troubleshooting, keep one clear connection method active and restore other tools one at a time. It’s easier to find the cause than changing several settings at once.
Keep technical settings and billing status separate. VPNCoast monthly plans are ¥9.9/month for 60GB, ¥18/month for 250GB, and ¥28/month for 500GB. Data resets monthly on the activation date, and mid-cycle upgrades are prorated by the remaining days. Data packages are ¥158/300GB, ¥358/1000GB, and ¥658/3000GB; they remain valid until used and never expire. Requests routed directly by your rules take a different path from those forwarded through the service. Check the dashboard and service details for how data usage is counted.
Unlimited devices doesn’t mean unlimited data, and a valid configuration in your client doesn’t mean your plan is active. Check the plans and pricing for usage and billing details, or see the Help Center for troubleshooting. You can request a full refund for any reason within 14 days of your first payment.
Troubleshooting order for beginners: configuration, connection, traffic capture, routing, verification. First confirm that your subscription updates and your plan is active. Then check that the node connects, that app traffic reaches the client, and that the right route is selected. Finally, test the destination service. Change one thing at a time so you can identify which setting made a difference.