Here’s how the pieces fit together: your plan determines your usage allowance, a subscription link delivers configuration to your client, a node provides a connection point, a route describes the data path, a protocol defines how data is exchanged, and routing rules decide where requests go. Understanding this flow is more useful than changing advanced settings one by one.
In everyday usage, a “VPN client” may actually be a proxy client and may not handle all traffic on your device. The sections below explain general concepts. Check the service dashboard and client documentation for supported protocols and configuration options; this glossary is not a list of K7VPN features.
Subscription: Your plan and configuration link are different things
A plan subscription is an account entitlement; a subscription link is a credential for retrieving configuration. The plan covers usage, billing, and reset cycles. The link is usually a URL containing a unique token. A client uses it to fetch node settings and sometimes policy groups or rules, depending on the configuration format.
Copying a subscription link won’t connect you automatically. You’ll generally need to import it into a compatible client, update the configuration, choose a route, and enable the proxy or tunnel. Some dedicated clients handle these steps after you sign in, so you may never see a link.
“Update subscription” usually means downloading the configuration again—not renewing your plan or resetting your data allowance. For example, K7VPN monthly subscriptions reset each month on the activation date, while data packages never expire. These are billing rules and can’t be changed by refreshing the configuration.
Nodes and routes: Distinguish the entry point, path, and exit
A node is usually a connection profile containing a server address, port, authentication details, and protocol settings. A region name in the client is a label for identification; it doesn’t necessarily indicate where the connection enters the network or reveal the full route.
A route describes the path data takes. For example, your device may connect to an entry point, pass through a relay or dedicated line, then exit in the destination region before reaching a website. If you’re outside China and accessing services in mainland China, check for a suitable exit in mainland China rather than choosing a node solely because it’s nearby.
Websites typically see the exit IP address, but a service may also use account region, content licensing, and device location to determine availability. A successful connection doesn’t guarantee access to all content. Test the target app directly instead of relying on the node icon.
| Term | What it usually means | What to keep in mind |
|---|---|---|
| Direct route | The device connects directly to the service node, with no additional service-side relay entry point | Performance depends more on the public network path from your local carrier to the node; “direct” doesn’t mean “bypassing every router” |
| Relayed route | Traffic first reaches a relay entry point, then gets forwarded to another node or exit | Both the entry point and the onward link matter; an extra hop doesn’t necessarily make a connection slower |
| IEPL dedicated line | Usually a carrier-provided international Ethernet private line used for a specific section of a route | Traffic from your device to the entry point may still use the public internet; a dedicated line doesn’t mean an end-to-end exclusive connection or built-in encryption |
“Direct” can also appear in routing rules, where it means a request doesn’t use a proxy. That’s different from a “direct route” in the table. Check whether the term describes the node’s path or how a request is handled.
Protocols: How data is exchanged, not a speed ranking
A protocol defines how a client and server authenticate, encapsulate, and transmit data. Both ends must be compatible, and the client must support the relevant implementation. Changing a protocol’s name doesn’t turn a node into a different protocol or enable features the server doesn’t support.
- Shadowsocks: An encrypted proxy protocol. The encryption method and authentication details must match; it isn’t the same as a system-level VPN tunnel.
- VMess: An authenticated proxy protocol. The client and server identifiers and transport settings need to match.
- Trojan: Typically uses TLS for transport. The domain, certificate validation, and authentication details can all affect the connection.
- VLESS: A lightweight authentication and proxy protocol. It doesn’t encrypt data on its own, so it needs a suitable secure transport layer. The name alone doesn’t tell you how traffic is encrypted.
- Hysteria2 and TUIC: Both use QUIC-based transport and depend on UDP connectivity. They may not work properly on networks that restrict UDP.
There’s no universal ranking of these protocols independent of the network environment. Performance depends on congestion, packet loss, transport settings, device capabilities, and server configuration. When getting started, import a compatible configuration from your provider and keep its authentication, transport, and certificate-validation settings. Don’t disable validation just to try to get more speed.
Split tunneling: Rule-based, global, and traffic coverage modes
Split tunneling assigns a route to each request. A client can use the domain, destination address, or app process to send requests through a proxy, connect directly, or block them. Rules are generally checked in order; the final behavior also depends on the fallback action when no rule matches.
Rule mode applies the configured rules and works well for everyday mixed use. If you’re outside China and accessing services in mainland China, you can route services that need an exit in mainland China through a suitable route while keeping other requests on your local network. This only works if the configuration includes the relevant rules—don’t judge by the mode’s name alone.
Global mode generally sends all requests handled by the client through the selected proxy. It can help you check whether a problem is related to routing rules, but it doesn’t guarantee that every app on your device is covered or resolve content licensing restrictions.
How do system proxy settings differ from TUN mode?
A system proxy provides a proxy address to apps that follow the system settings. Apps that ignore those settings may still connect directly. TUN mode routes traffic through a virtual network interface and typically covers more traffic, but its scope still depends on routing, exclusions, permissions, and the client’s implementation.
Windows, macOS, and Linux clients handle system proxies, virtual interfaces, and permissions differently. iOS and Android clients often use system-provided tunneling features, and the interface may show a VPN indicator. That indicator only means the relevant system connection feature is enabled; it doesn’t prove that every request uses the intended exit.
DNS and leaks: Check the DNS resolution path too
DNS translates domain names into IP addresses. Apps usually look up a domain before connecting to a website, so a DNS request may take a different route even when the web request goes through a proxy. A DNS leak generally means DNS traffic isn’t handled as intended and reaches an unexpected resolver or network.
DNS results also affect which content delivery server an app selects. If the apparent DNS location doesn’t align with the actual exit, the app may connect to an unsuitable server. But slow loading can also be caused by route congestion, an app cache, or the destination service—don’t assume DNS is to blame.
Beginners can leave the DNS settings from their subscription configuration in place and avoid enabling multiple conflicting proxy or DNS tools at once. Encrypted DNS in your browser, system DNS, and DNS handling in the client may all be active independently, so check each one when troubleshooting.
From import to testing: A beginner’s checklist
For your first connection, follow a repeatable baseline process. K7VPN clients and subscriptions are available through the dashboard after you sign in; check the dashboard for iOS access requirements. Don’t assume installation steps for another platform apply to your device.
- Get a compatible client. Check the instructions for your platform at the dashboard download page, and make sure the client supports the configuration format provided by the dashboard.
- Import and update the configuration. Follow the instructions to sync after signing in, use a subscription link, or import a configuration file. Confirm that nodes or policy groups appear in the client. If you get a format error, first check that you copied everything and chose the right import type.
- Choose an appropriate exit. Select a route suitable for the target service, then check which node the active policy group actually selected. Don’t assume changing the highlighted item in a list changed the route.
- Enable connectivity. Follow the client’s instructions to enable the system proxy or tunnel and grant any required permissions. Keep the recommended rules, DNS settings, and security checks.
- Test the target app. Use My IP to help check your exit, then test the service you need directly. If an existing connection is still using its previous route, close and reopen the app to compare.
- ✅ Leave these at their defaults to start: the service’s protocol settings, certificate validation, routing rules, and DNS configuration.
- ✅ Understand these before changing them: policy groups, system proxy settings, TUN coverage, and app exclusions.
- ❌ Don’t share publicly: subscription links, node authentication details, or logs containing account credentials.
- ❌ Don’t change everything at once: nodes, protocols, DNS, and routing mode. Otherwise, it’s hard to tell which change made a difference.
When a connection fails, troubleshoot layer by layer instead of reinstalling repeatedly
Import failed: First check that the link is complete, the configuration is still valid, and the client is compatible. No connection has been established yet, so changing routing rules usually won’t help.
Can’t connect to a node: Check your local network, account status, and whether the configuration is up to date, then compare with another suitable route. If only nodes that rely on UDP are failing, the network may be restricting UDP—but don’t draw conclusions from a single failed attempt.
Connected, but the app isn’t working: First check whether the app’s traffic is being handled by the client, then check the matching rule and exit. If a browser works but another app doesn’t, the client may be covering different traffic—not necessarily experiencing a node failure.
The exit looks right, but content is still unavailable: Check the service’s regional licensing, account requirements, and app cache. A route provides network connectivity but can’t override a content platform’s own access rules.
Need help? Check the Help Center or provide your device platform, client name, error message, and steps to reproduce the issue. Hide credentials in screenshots, and check logs for sensitive information before sharing them.