This practical VPN glossary explains the differences between subscriptions, servers, routes, protocols, and routing modes. A subscription provides configuration; a server is the connection endpoint; a route describes how traffic travels; a protocol defines how it is transmitted; and a routing mode determines which requests use the proxy. Knowing the difference is more useful for choosing a plan and troubleshooting than relying on plan names alone.
In everyday conversation, “VPN” is sometimes used as a catch-all term for proxy services. Strictly speaking, a system-level VPN tunnel and an app-level proxy are different technologies. A client’s VPN permission prompt may simply mean it uses the system’s virtual network interface to handle traffic; it doesn’t tell you which protocol is running underneath.
Subscriptions, plans & configurations: know what each one provides
A plan defines billing and usage limits; a subscription link is how you retrieve a configuration. After purchasing a plan, your account receives the corresponding benefits. The client uses the subscription link to fetch server addresses, authentication details, and related settings. The two are connected, but a successful subscription update doesn’t necessarily mean the plan is active or a connection has been established.
Subscription links usually contain credentials that identify your account, so protect them like passwords. Don’t post the full link in public forums or submit it to random online conversion sites. If a link is exposed, look for a reset option in your account panel and update the saved address in your client.
“Update subscription” usually means fetching the configuration again. It doesn’t renew your plan or reset your used data. Some clients only accept particular configuration formats: a link that works in one client may not be readable by another. Use the compatible link provided in your account panel instead of repeatedly editing it by hand.
- Get the subscription link for your client from the account panel. Make sure you haven’t copied extra spaces or missed any characters.
- Choose the import or add-configuration option in your client, then check whether the server list appears—not just whether an import confirmation is shown.
- Select a configuration and server, enable the appropriate traffic-handling mode, and test it with the website you want to access.
- Update the subscription when routes change. If authentication fails, check both your plan status and subscription credentials.
Servers, entry points & exit locations: what region names refer to
A server is a connection profile you can select in your client. It usually includes an address, port, protocol, and authentication details. The entry point is the server your client connects to first; the exit location is where traffic leaves the proxy network to reach its destination. They can be in different places, and a region name shown in the client may refer mainly to the exit location.
Websites usually see the exit address, not the label in your server list. So after selecting a server labeled Japan, check how the exit location is actually identified. Location databases can place the same address in different regions, and websites may also use your account region, billing details, or session history to determine content access.
More servers don’t necessarily mean more distinct exit locations. Multiple servers may share an exit or use different entry points and transport methods. “Number of routes” and “number of countries” describe different things and can’t be converted into one another. For streaming, check whether the platform recognizes the exit. For long-term account access, avoiding frequent exit changes is often more important than having a long server list.
Direct connections, relays & IEPL dedicated lines
These terms describe how a route is organized, not which encryption protocol it uses. A direct connection generally means the client connects straight to an overseas server. A relay adds a forwarding server between the client and the exit. IEPL usually refers to an international Ethernet private line provided by a carrier, which may be part of a service’s transport route.
| Term | What it means | What else to check |
|---|---|---|
| Direct connection | The client connects directly to an overseas server, usually over public internet routes. | The actual route from your local carrier to the server, and whether it’s congested. |
| Relay | Connect to a forwarding entry point first, then continue along another route to the exit. | Entry-point quality, the onward route, and exit-server load. |
| IEPL dedicated line | Traffic travels over an international Ethernet private line for part of the route. | Which part of the route it covers, and whether access or exit traffic still uses the public internet. |
A relay adds a forwarding step but may improve performance through a better route. A direct route may look shorter yet still be affected by public internet congestion. Fewer forwarding steps don’t automatically mean faster speeds, and a dedicated line doesn’t mean your entire connection—from your device to the destination website—uses a private network exclusively for you.
A dedicated line doesn’t automatically mean encryption, either. Transport routes and encryption are separate layers; HTTPS on the website and authentication and encryption in the proxy protocol each serve their own purpose. This article explains industry terminology and doesn’t imply that all VPNMC routes use any particular transport method.
Common protocols: compatibility matters more than the name
A protocol defines how the client and server authenticate, encapsulate, and transmit data. A protocol isn’t the same as a client: one client may support several protocols, and different clients may implement the same protocol. The following is a conceptual overview, not a list of protocols supported by VPNMC.
| Protocol | Core idea | What to check |
|---|---|---|
| Shadowsocks | An encrypted proxy protocol, not a system-level VPN. | Check that both sides support the same encryption method, authentication parameters, and plugin. |
| VMess | A proxy protocol with authentication and encryption mechanisms. | Check the client implementation, authentication settings, and system clock. |
| Trojan | Typically protects proxy traffic with TLS. | Check that certificate validation, domain name, and server settings match. |
| VLESS | A lightweight proxy protocol that doesn’t encrypt traffic on its own. | Check which secure transport is paired with it; the protocol label alone isn’t enough. |
| Hysteria2 | A QUIC-based proxy protocol that relies on UDP. | Check whether your local network supports UDP and whether your client version is compatible. |
| TUIC | A QUIC-based proxy protocol that also relies on UDP. | Check the protocol version, authentication parameters, and network restrictions. |
A newer protocol doesn’t automatically mean faster connections on every network. If your network restricts UDP, connections that depend on it may fail. And if the configuration lacks required secure transport settings, the protocol name alone won’t tell you what’s protected. Start with a compatible configuration, then test it on your actual network.
Rules, global mode & TUN: where routing happens
Rule mode routes requests according to criteria such as domain, destination address, or app. Common actions include connecting directly, using a proxy, or rejecting the request. Rule order matters: an earlier match may determine what happens. Some rules pass requests to a policy group, which then selects a specific server.
Global mode usually sends traffic handled by the client through a specified proxy, but it doesn’t guarantee that every app on the device is covered. System proxy settings mainly affect apps that honor them; some apps ignore them. TUN uses a virtual network interface to handle IP traffic, offering a different kind of coverage, but exclusions and system restrictions may still apply.
So “global” and “TUN” aren’t mutually exclusive options in the same category: global mode is usually a routing decision mode, while TUN is a traffic-handling method. Some clients can use rule mode while running TUN. If a website still connects directly, first check whether the request reaches the client, then see which rule it matches.
- ✅ Check how traffic is handled: is the system proxy in use, or is a virtual network interface enabled?
- ✅ Check the matching rule: is the destination domain assigned to direct access or the wrong policy group?
- ✅ Check the policy selection: even if the rule points to the right group, make sure that group has the expected server selected.
- ❌ Don’t rely on global mode indefinitely to hide rule problems. Find out where the specific request is going.
DNS leaks & connection checks
DNS translates domain names into destination addresses. A DNS leak generally means that, in a situation where DNS queries are expected to be protected, they’re still sent through an unintended resolver—for example, one on the local network. A website loading successfully doesn’t mean its DNS queries and web traffic took the same route.
Encrypted DNS protects the transmission of queries, but doesn’t automatically mean those queries go through a proxy. Conversely, a difference between the resolver’s reported region and the exit region on a test page isn’t enough by itself to prove a leak: public DNS services may use distributed infrastructure, and geolocation can be inaccurate.
For a useful check, compare the client’s DNS settings, connection logs, and test results. First confirm that the exit matches your expectations, then check which rule handled the destination request, and finally find out which resolver handled the DNS query and which route it took. Your browser’s secure DNS settings may also change the resolution path expected by the client.
Latency tests in a client usually measure a specific destination or connection stage. They don’t show sustained download speeds or prove that a streaming platform will work. A proper check includes signing in to the target website, loading pages, and testing the actual features you need—not just looking at a test icon.
Platform differences & troubleshooting steps
Windows and macOS clients often offer system proxy and virtual network interface options; enabling the latter may require extra permissions. iOS and Android often handle traffic through the system VPN interface, with background activity managed by the operating system. On Linux, pay special attention to routing, DNS management services, and background process status. Menu names vary between clients.
If you’re connected but websites won’t load, troubleshoot in this order: account and configuration, connection setup, traffic coverage, routing rules, DNS, and the destination website. First make sure your plan is active and the subscription updated successfully, then check whether the server is reachable. If the connection is established but things still fail, check whether the request entered the proxy and whether the destination accepts the exit.
Change one category of setting at a time and keep the original configuration. Switching protocols, servers, and DNS settings all at once makes results hard to compare. If you need help, share the client name, operating system, and error details with sensitive information removed. Never send your subscription credentials or full configuration.
Use these terms to compare plans
When comparing plans, check data allowances, reset rules, device limits, and route descriptions separately. VPNMC monthly plans include ¥9.9/month for 60GB, ¥18/month for 250GB, and ¥28/month for 500GB. Data resets monthly on the activation date; if you upgrade mid-cycle, the price difference is prorated for the remaining days.
Data add-ons cost ¥158/300GB, ¥358/1000GB, and ¥658/3000GB. They expire only when used up and never expire by date. “Never expires” refers to the validity period of the data add-on, not unlimited data. VPNMC offers 90+ countries and 240+ routes, with no device limit. No device limit doesn’t change the data allowance included in your plan.
VPNMC supports Windows, macOS, iOS, Android, and Linux. No email address is required; create an account with a username and password. Anonymous, no-logs service is a privacy commitment, not a guarantee that a website can’t identify visitors through a signed-in account, browser state, or other signals. Refund policy: request a full refund for any reason within 14 days of your first payment.