When you're new to VPNs, start with this: a subscription provides configuration to your client, a node determines the connection destination, a protocol defines how data is transmitted, and split tunneling decides which requests take which route. Each solves a different problem. Importing a configuration doesn't mean you're connected, and a successful connection doesn't mean every app uses the proxy.
In everyday searches, “VPN” can refer broadly to tools for cross-border access, but a system-level VPN tunnel and an app proxy are not the same mechanism. Some proxy clients use the system VPN interface to handle traffic. So a VPN icon only shows that the network interface is active; it doesn't tell you which protocol is in use or how much traffic it covers.
Quick glossary: subscriptions, servers, and clients
Think of the client as the tool that applies your configuration. The service provides the configuration, the client reads it, then handles requests according to your selected node and rules. This table covers common interface terms; button names may vary between apps.
| Term | What it means | What it doesn't mean |
|---|---|---|
| Plan subscription | The billing and usage entitlements associated with your account. | It isn't a configuration URL for your client. |
| Subscription link | A URL your client uses to retrieve or update its configuration. | It isn't a website address for everyday browsing. |
| Configuration file | A file describing settings such as nodes, proxy groups, rules, or DNS. Its contents depend on the format. | It doesn't necessarily support automatic subscription updates. |
| Node | A set of connection parameters, usually including a server address, port, authentication details, and protocol settings. | A node name doesn't necessarily refer to a separate physical server. |
| Exit location | The region associated with the exit IP address seen by the destination website. | It may differ from the location of the first point you connect to. |
| Protocol | The communication method used between the client and server. | It doesn't determine connection speed on its own. |
| Route type | The network path or transport used between the entry point and the exit point. | It's a different classification from protocol. |
| Proxy group | A logical group for choosing a node, a direct connection, or another way to handle traffic. | The group name itself isn't a server-side node. |
| Routing rule | A condition, such as a domain or IP address, that determines how a request is routed. | It doesn't automatically understand everything a user intends to do. |
| DNS | The mechanism that resolves domain names to IP addresses. | A website failing to load doesn't necessarily mean the node is down. |
“Update subscription” usually means retrieving the configuration again; it doesn't renew your plan or reset your data. VPNCar monthly subscriptions reset data on the activation date each month. Data packages never expire and remain available until used. Check billing status in your account dashboard, not by whether nodes still appear in the client.
How to import a subscription link into a client
A subscription URL usually contains credentials that identify your account, so protect it like a password. Don't include the full URL in public screenshots, forum posts, or online conversion tools. When troubleshooting, describe the error and redact the credentials in the URL. If the URL has been exposed, reset it using the option in your account dashboard, then update the configuration on each device.
- Check client compatibility. Sign in to your account dashboard and check the supported platforms and configuration formats. Similar app names don't mean the apps support the same subscription formats or protocols.
- Choose the right import option. Use “Import from URL” or a similar option. Don't paste a subscription URL into a single node's server address field. To import a local file, use the file import option.
- Confirm the configuration has loaded. Check that nodes or proxy groups appear, then set the new configuration as active. Some clients let you keep multiple configurations and may not switch to the newly imported one automatically.
- Select a node and connect. Grant any network permissions requested by your system, then test access in the app you actually plan to use. Seeing a node list confirms the configuration loaded; it doesn't confirm that traffic can pass through.
- Keep useful troubleshooting details. Note your operating system, client name, selected mode, and any error message. If you need help, explain the issue on the contact page. Don't share your password or full subscription URL.
Common protocols: different names, different compatibility requirements
Shadowsocks is a widely used proxy protocol; VMess, Trojan, and VLESS are other distinct proxy protocols or approaches. They differ in authentication, transport combinations, and client support. Trojan typically uses TLS. How VLESS is protected depends on its transport and configuration, so its name alone doesn't tell you everything about the connection.
Hysteria2 and TUIC are based on QUIC and generally require a network that allows UDP traffic. If your current network restricts UDP, the client may recognize the configuration but still fail to connect. Neither protocol is inherently suited to every network, and a newer protocol doesn't automatically mean a better experience.
Keep protocol, transport, and route type separate when reading a node configuration. For example, WebSocket is a transport that can be used in combination with a protocol; it isn't a separate international route. The client must support the combination required by the configuration. Supporting a protocol name without the corresponding transport may not be enough.
Dedicated lines, relays, and direct connections: what each describes
A direct connection usually means the client connects straight to an overseas server, without an additional forwarding point set up by the service provider. The connection still passes through your ISP's network. A relay connection typically goes to an entry point first, then forwards traffic to an exit point. Performance depends on the entry point, the onward route, and the destination website. A nearby entry point doesn't prove that the full route is shorter.
IEPL is the name of an international Ethernet private line. In subscription services, “IEPL” generally describes part of the transport path used by the provider. It doesn't mean every segment between your home network and the destination website uses a dedicated line. Your local connection, wireless network, and the route from the exit point to the destination can all affect performance.
Route type alone can't tell you how well a connection will work for your needs. First confirm the exit location, then check how the target app responds, whether sessions stay connected, and how quickly content loads. A latency figure in a speed-test list usually reflects a particular probe request; it isn't a direct measure of video loading speed or file transfer performance. Check the available options in the server list, rather than choosing by name alone.
Choosing between global and rule-based mode
Rule mode handles requests according to matching conditions in the configuration—for example, routing specified domains through a proxy and local services directly. Many clients apply rules in order, so an earlier rule may determine the result. Requests that don't match a rule use the final fallback policy. In rule mode, make sure the proxy group is set to an appropriate node.
Global mode generally sends requests handled by the proxy engine through the selected policy, but it doesn't guarantee that every device connection is captured. A system proxy usually affects only apps that follow the system proxy settings; some apps use their own network settings. TUN mode captures traffic through a virtual network interface and usually covers more, but routing, exclusions, permissions, and the client implementation still matter.
Choose a mode for the situation; don't switch blindly and leave it that way
- Everyday work: Start with rule mode and check that international websites and local services take the expected routes. If internal network resources aren't accessible, check LAN bypass settings and related rules.
- One website isn't working: Temporarily switch to global mode for comparison. If access returns, check the rules, proxy group, and DNS first instead of assuming the route is broken.
- A specific app isn't using the proxy: First check whether it follows the system proxy settings. Then see if it needs another traffic-capture method supported by your client. Repeatedly toggling global mode won't fix every case.
Windows and macOS clients may offer separate system proxy and TUN controls. Mobile platforms typically connect through the system VPN interface, but their per-app routing capabilities vary. On Linux, system services, permissions, and routing settings may also be involved. When moving between platforms, check which features are available rather than relying on buttons being in the same place.
After connecting, check your exit location, DNS, and traffic routing
A DNS leak generally means a query that should have followed the expected proxy or specified DNS route instead used another route. This is separate from checking your exit IP: seeing the expected exit on a website doesn't prove that DNS queries took the same path. Conversely, a domain set to connect directly may be expected to use local DNS, so that alone isn't a leak.
Browser Secure DNS, system DNS settings, and client DNS configuration can affect one another. If a domain won't load but other sites work, check the client's DNS policy and logs first, then review your browser settings. Don't replace every resolver with the same address or change rules, DNS, and nodes all at once; doing so makes the real cause harder to find.
- ✅ Check the exit location shown for your current browser in the IP check tool and compare it with your selected node. This result only reflects that browser request.
- ✅ Open the website or app you actually want to use and check sign-in, loading, and continued use—not just whether the client says “Connected.”
- ✅ In the client's connection logs, check which rule matched the destination domain, which proxy group was used, and where the request went.
- ✅ Make sure local and internal network services still work, so requests that don't need a proxy aren't routed through one.
- ✅ When switching networks or nodes, change one thing at a time and compare what happens before and after.
Streaming services and AI tools may also consider your account region, licensing, and their own policies. Changing your exit location doesn't guarantee access. Exit checks help verify the network route; they don't replace the destination service's eligibility requirements.
Troubleshooting for beginners: from configuration to the app
If the node list is empty, first check whether the subscription was imported, the configuration is enabled, and your account is active. If nodes appear but won't connect, check client compatibility, network permissions, and your current network. If the client says it's connected but only one app has issues, check traffic coverage, matched rules, DNS, and any message from the service. Following this order helps avoid blaming every problem on a “dead node.”
For more setup instructions, find your platform in Guides. For billing, refunds, or account issues, see the FAQ. Troubleshooting a configuration and choosing a plan are separate tasks; adding more data won't fix an incompatible format or incorrect rule.