VPNBasics: Understand the Terms in Your Client First
You don’t need to memorize protocol names to get started. A subscription provides connection settings to your client; a node is an available connection endpoint; a route describes how traffic reaches its exit; a protocol defines how the client and server communicate; and routing rules determine which requests use the connection.
People often use “VPN” as a catch-all term for proxy subscription services, but these services don’t always handle system traffic the same way. Some clients configure a system proxy; others route traffic through a virtual network interface. So, seeing “Connected” only means the connection process completed—it doesn’t mean every app is using it.
| Term | What it means | What to check |
|---|---|---|
| Subscription link | An address used to retrieve and update connection settings | Source, format, and update status |
| Node | A configuration entry with details such as a server address and authentication data | Exit region and how it performs in your apps |
| Route | The network path from your device to the entry point and then the exit | Path structure and day-to-day stability |
| Protocol | The communication method agreed on by the client and server | Whether the client core supports it |
| Traffic routing | Rules that send traffic through a proxy, directly, or block it | Whether the intended rule matches the app or destination |
A subscription link is not the same as a paid plan
“Subscription” can mean two different things. A plan subscription refers to billing; in a client, a subscription usually means the source of connection settings. Importing a link downloads settings to the client—it doesn’t activate another plan. Updating a subscription link doesn’t renew your account either.
When a service updates server addresses, node names, or configuration parameters, the client usually needs to refresh its settings to get the changes. A successful update only confirms that the settings downloaded; it doesn’t prove that every node can connect. Likewise, an old node working for now doesn’t mean the subscription link is still valid.
The subscription format needs to work with your client. Some links return a single node, others provide a list of nodes, and some supply a complete configuration with rules and policy groups. Don’t judge compatibility by the file extension alone; use the client instructions provided in the service dashboard. Third-party conversion tools may access credentials in the link, so consider that before importing it.
Understanding node locations and route paths
The region shown in a node list usually indicates its exit location, but check the service documentation for the exact meaning. A node name alone can’t prove the server’s physical location or guarantee that a platform will accept that exit. Websites may also consider your account region, payment region, and risk signals when determining access.
Direct, Relay, and IEPL Routes
A direct route usually means your device connects to an overseas server without an additional domestic relay arranged by the provider. Performance depends on your local ISP, international egress, and the remote network. “Direct” describes the route; it doesn’t guarantee higher speeds or mean the connection isn’t encrypted.
A relay route usually adds a forwarding point between your client and the exit. Traffic first reaches the relay, which then forwards it to another server. This may improve routing for some ISPs, but it adds another component to maintain. The relay label doesn’t tell you whether the next link is congested, so test it under real-world conditions.
IEPL is an international Ethernet private line service provided by a carrier. In subscription services, the term usually refers to this type of transport between an entry point and some overseas nodes. It describes one segment of the route—not the entire path from your device to a website—and doesn’t automatically grant access to streaming services.
When choosing a route, start with the region you need, then test the apps you use. Web browsing depends on responsive interactions, video on sustained throughput, and calls on low jitter and packet loss. A client’s latency test may only measure a handshake with one address; it isn’t a full download performance test.
Protocol names and client compatibility
Shadowsocks, VMess, Trojan, VLESS, Hysteria2, and TUIC aren’t different plan tiers; they’re different communication protocols. A node appearing in your client doesn’t mean its current core supports every setting it uses. If importing fails, check the format and client version before considering a protocol change.
- Shadowsocks: An encrypted proxy protocol. Your client must support the encryption method specified in the configuration. If a plugin is involved, check that the client supports it too.
- VMess: A proxy protocol with authentication and encryption. The configuration may also specify an additional transport method; an incorrect device clock can affect authentication.
- Trojan: Typically carries proxy traffic over TLS. Server name handling and certificate verification must be configured correctly.
- VLESS: The protocol itself doesn’t provide transport encryption. Assess security based on the specific security layer and transport settings; the protocol name alone doesn’t tell you whether a connection is secure.
- Hysteria2 and TUIC: QUIC-based proxy protocols that depend on UDP network conditions. UDP restrictions on your network may affect performance.
A protocol’s age alone doesn’t determine its speed. Exit load, network path, device performance, and configuration all affect results. If you see a certificate error, don’t disable verification just to connect. Check your system clock, server name, and configuration source first, and contact support if needed.
VPNAct’s core security messaging describes its encryption as military-grade. Follow the dashboard and client instructions for your specific connection. This claim doesn’t imply that a particular protocol is available, or that encryption guarantees a destination website will grant access.
Routing rules, global mode, and traffic coverage
Rule-based mode directs traffic according to domains, destination addresses, processes, or other criteria. Common actions include proxy, direct, and reject. Available match conditions and rule order depend on the client. Before changing rules, check the connection log to see which rule actually matched the request.
Global mode usually sends requests that have already entered the client through the selected proxy policy, but it may not capture every app on your device. Apps that ignore the system proxy may still connect directly. Some clients also separate mode selection from the virtual network interface toggle, so don’t assume everything is routed just because the interface says “Global.”
TUN mode receives traffic through a virtual network interface and usually covers more apps, but routing, app exclusions, DNS settings, and system permissions still matter. There’s no need to enable it right away. For your first connection, start with the setup recommended by the service, confirm it works, and then adjust settings if needed.
Steps from importing a configuration to connecting
Client interfaces vary, but the basic workflow is much the same. Change one thing at a time; switching nodes, protocols, and DNS settings together makes it hard to identify what helped. These steps don’t require manually entering server settings and work with subscription configurations from the service dashboard.
- Get a client. Check the instructions for your operating system in the dashboard’s client download section, and make sure the client supports your subscription format. Availability depends on the dashboard.
- Import the configuration. In your client, find the subscription, configuration, or profile option and use the link from the dashboard. After importing, check that a node list appears and that there are no clear error messages.
- Grant system permissions. Your operating system may ask to allow a proxy or network interface configuration. Confirm which app is requesting permission, then follow the client’s instructions.
- Choose a node and mode. Select a node for your target region and start with the recommended rules. If the configuration includes policy groups, check which node the selected group is actually using.
- Test the apps you use. Open your browser and everyday apps separately. A webpage loading successfully doesn’t mean background apps or meeting software are using the same route.
On Windows and macOS, some apps follow the system proxy while others need separate settings or broader traffic routing. Mobile operating systems typically connect through their built-in network extension mechanisms; battery-saving settings may also interrupt background connections. On Linux, you may need to configure your desktop environment, terminal, or service process separately—don’t assume every app shares the same proxy settings.
For more on using the client, see the Guides. If you run into import or permission errors, work through the complete troubleshooting guide instead of layering on unfamiliar settings.
How to verify your exit IP and DNS
Your exit IP is the source address a destination service sees. Before and after connecting, compare results in the same browser using the same test page. In rule-based mode, the page may match a direct-connection rule, so an unchanged address doesn’t necessarily mean the connection failed. Check the client logs too.
DNS translates domain names into addresses. A DNS leak usually means lookup requests are taking a path other than the one you intended, potentially sending queries to a resolver on your local network. A test page shows the DNS behavior it can observe; it isn’t a complete record of all network activity on your device.
Seeing a local resolver doesn’t always mean something is wrong: routing rules may intentionally use local DNS for local websites. The more useful question is whether domains meant to use the proxy are still being resolved through an unwanted path. Browser encrypted DNS, the system’s DNS cache, and client settings can all affect the results.
- ✅ Check the client connection log to confirm that requests for the target domain reach the client and match the expected policy.
- ✅ Compare your exit IP with the expected region, keeping in mind that geolocation databases may disagree.
- ✅ Check the DNS configuration and resolution path; don’t assume the resolver’s location is the same as the exit region.
- ✅ If your browser works but an app doesn’t, check whether the app bypasses the system proxy.
- ❌ Don’t treat low latency, a connected icon, or one page loading as proof that every app is working properly.
If only one platform reports a region mismatch, first distinguish network connectivity from the platform’s access policies. Trying an exit in the matching region can help with troubleshooting, but it won’t necessarily resolve account-region or risk-control restrictions. For support, share your operating system, client, error, and what you were doing. Remember to hide your subscription link and authentication details.
Choose a plan once you understand the terminology
Plan data determines your available allowance; nodes and protocols determine how you connect. Don’t confuse the two. VPNAct monthly plans are ¥9.9/month for 60GB, ¥18/month for 250GB, and ¥28/month for 500GB. Data resets monthly on your activation date; mid-cycle upgrades are prorated based on the remaining days.
Data packs cost ¥158 for 300GB, ¥358 for 1000GB, and ¥658 for 3000GB, and never expire. A monthly plan may suit regular, ongoing use; if you connect less often, compare the data packs. Never expiring doesn’t mean unlimited data, and the lowest price per gigabyte may not suit your actual usage.
VPNAct allows unlimited simultaneous devices and requires no email address. You can create an account with a username and password. Refund policy: request a full, no-questions-asked refund within 30 days of your first payment. Read the full plan details before choosing. For personal assistance, use a support ticket in the dashboard rather than sharing sensitive settings publicly.