Here’s the short version: a subscription provides configuration, a node determines which server endpoint you connect to, a protocol defines how the client communicates with the server, and routing rules decide which requests use the proxy. If something won’t load, identify which layer is causing the problem and adjust the relevant setting instead of repeatedly switching nodes.
Terms at a glance: configuration vs. connection
People often use “VPN” as a catch-all for international network services, but that doesn’t mean every client uses the same tunneling technology. A proxy client may only route apps that follow the system proxy settings, or it may use a virtual network interface to handle more traffic. “Connected” confirms that one part of the connection is established; it doesn’t mean every app uses the same exit.
| Term | What it means | Common misconception / what to check |
|---|---|---|
| Subscription link | An address the client uses to retrieve nodes or configuration; the contents depend on the subscription format. | It’s not a website login URL. Before importing it, make sure the client supports its format. |
| Node | A server connection configuration, usually including an address, port, protocol, and authentication details. | The region in a node’s name may not be where its entry point is. Check the actual exit location. |
| Route type | The network path from entry point to exit, such as direct routing, relay, or a dedicated link. | It describes the network path—not the proxy protocol or a guarantee of speed. |
| Proxy protocol | The agreed method for transmitting, authenticating, and encapsulating data between client and server. | A client supporting a protocol doesn’t mean the server offers a matching configuration. |
| Routing rule | A condition based on a domain, address, or other criteria that determines whether traffic connects directly, uses a proxy, or is blocked. | Rule order and the default policy can affect the final route. |
| DNS | The process of resolving a domain name to a network address. | A web page using the proxy doesn’t mean its DNS queries take the same route. |
Think of the process as “configuration source → connection entry point → transport method → request destination.” Subscription updates relate to the configuration source; node authentication failures are connection-configuration issues; and an app unaffected by the proxy may point to traffic handling or routing rules. These problems can’t all be fixed with the same switch.
Subscription links vs. monthly subscriptions: same word, different meanings
A subscription link is a technical entry point; a monthly subscription is a billing option. A monthly plan may provide a subscription link, and a data pack may also use one to import configuration. The word “subscription” alone doesn’t tell you whether you’re paying monthly, and importing a configuration doesn’t mean your plan is active.
A link may return a list of nodes or include proxy groups and rules. Clients support different formats: being able to read a single share link doesn’t necessarily mean a client can parse a full configuration file. If no nodes appear after importing, first check that the link was copied in full, the account is active, and the link hasn’t expired or been reset; then check format compatibility.
- Open the download page from the service dashboard, get a client for your operating system, and follow its import instructions.
- Import the link from the client’s subscription or configuration settings, and make sure the import method matches the format provided by the service.
- Update the subscription and check whether a node list appears. Keep the specific error message rather than just noting that it “doesn’t work.”
- Choose a node and connect, then check the exit region and the app you want to use. Don’t treat the node name as proof of the actual result.
Subscription links may contain access credentials. Don’t post them publicly in comments or screenshots, or paste them into unfamiliar online conversion tools. If you suspect a link has been exposed, check the dashboard for a reset option, then update the configuration on each device.
Updating a subscription in the client fetches configuration again; it does not reset your plan’s data allowance. VPNTC monthly plans reset data each month on the activation date. Data packs remain valid until used and never expire. To check your balance, look at usage and the billing period in the dashboard—not the time of the client’s last update.
Nodes and routes: direct connections, relays, and IEPL
A node is closer to a connection configuration; a route is closer to a network path. The same exit region can have different entry points and transport routes, and one entry point may connect to different exits. When choosing a region for international websites, focus on the exit location seen by the service—not the city listed in the node name.
Direct connections and relays
In common subscription terminology, a direct connection usually means the client connects straight to a server outside mainland China, with the cross-border route relying more on the local carrier’s international routing. A relay connects first to an entry point, then forwards traffic to the exit. Relays can change part of the route, but the entry point, forwarding network, and exit load still affect performance. More relay hops don’t necessarily mean a faster connection.
IEPL dedicated links
IEPL generally refers to an international Ethernet private line, a dedicated connection service provided by a carrier. In a subscription service, an “IEPL route” usually means that one segment uses this type of link; it doesn’t mean the entire path from your home network to the destination website is dedicated. Hotel Wi-Fi, local access, and the destination service itself can still cause slowdowns.
Test web page loading, file transfers, and persistent app connections separately when comparing routes. A single latency test only samples part of the path; it doesn’t show sustained throughput or evening congestion. A streaming label also doesn’t guarantee access to every platform in every region—platform detection policies can change.
Common protocols: compatibility matters more than the name
A protocol defines how the two sides authenticate and transmit data; transport and encryption settings also affect the connection. The server and client configurations must match. Changing a protocol name to a different option usually won’t add capabilities—it will just prevent the connection. These are industry concepts, not a list of protocols available from VPNTC.
- Shadowsocks: An encrypted proxy protocol. The client must match the server’s encryption method and authentication details; extensions in different implementations aren’t necessarily interchangeable.
- VMess: A proxy protocol with authentication and encryption mechanisms, often used with different transport methods. A mismatch in the underlying transport parameters can prevent a connection even when the authentication details are correct.
- Trojan: Typically uses TLS to establish a protected connection. Check the domain, certificate validation, and server configuration. Don’t leave certificate validation disabled as a long-term troubleshooting measure.
- VLESS: A lightweight proxy protocol that doesn’t provide encryption by itself. Whether the transport is confidential depends on additional mechanisms such as TLS; the VLESS label alone isn’t enough.
- Hysteria2: A QUIC-based proxy protocol that relies on UDP. It may fail to connect on restricted networks that block or limit UDP traffic.
- TUIC: Also based on QUIC, but it isn’t another name for Hysteria2. Their configurations and implementations aren’t interchangeable, and clients must support each one separately.
QUIC runs over UDP, but that doesn’t mean every UDP app will automatically use the proxy. Whether an app’s traffic is captured depends on the client’s features, node capabilities, and operating mode. If meeting audio is glitchy or an app won’t connect, check the actual traffic route instead of simply blaming a protocol for being “slow.”
Beginners are better off using configurations supported by the service. Before making manual changes, back up the original configuration and check the client version, server requirements, and specific error messages in the logs. You can save error details for troubleshooting, but redact credentials, subscription URLs, and personal information before sharing them.
Rule-based vs. global mode: where does split tunneling apply?
Rule-based mode uses matching conditions to decide where requests go. Common actions are direct, proxy, and reject. For example, local network resources can connect directly, selected international websites can use the proxy, and other requests can follow the default policy. Rules are often checked in order, but behavior can vary by core, so consult the client’s documentation.
Global mode usually sends all requests already captured by the client through the proxy policy. The key phrase is “already captured”: with system proxy enabled alone, apps that ignore the system proxy settings may still connect directly. So global mode doesn’t mean all device traffic goes through the server, nor does it automatically fix DNS or app compatibility issues.
System proxy and TUN
A system proxy tells apps that support the setting to use a local proxy endpoint. TUN captures more IP traffic through a virtual network interface, often requiring extra permissions and relying on routing and DNS configuration. TUN is a traffic-capture method, not a proxy protocol. Rule-based and global modes can work with different traffic-capture methods.
Suppose a browser can access international websites, but desktop collaboration software stays offline. First check whether the app follows the system proxy settings, then see if a rule sends it direct. If the client supports TUN, you can test it according to the official instructions, but watch for route conflicts with a company VPN, local network access, or other networking tools.
Global mode can help isolate a split-tunneling problem. If switching to it gets the target app working, investigate the matching rules instead of assuming the original node is faulty. Once you’ve finished troubleshooting, restore the policy that suits your needs.
DNS checks and platform differences: verify the connection after it connects
DNS resolves domain names to addresses. A DNS leak generally means queries that should be protected by a specified tunnel or proxy are sent over an unexpected path, such as the local network. In rule-based mode, intentionally resolving local domains directly isn’t necessarily a leak. First determine which queries should take which route, then compare that with what actually happens.
Browsers may use their own encrypted DNS, apps may cache old addresses, and clients may use separate resolvers. These settings can change what a test shows. Seeing an unfamiliar DNS provider on a test page isn’t, by itself, proof of a leak or a security issue. Interpret the result alongside the client’s DNS settings, browser settings, and expected exit.
- ✅ First, confirm the local network can access regular websites, and rule out an incomplete Wi-Fi sign-in or a network outage.
- ✅ Confirm the configuration is up to date and the node is connected in the client, then check your current browser exit using network diagnostics.
- ✅ Open the app you actually want to use and test page loading, sign-in, and persistent connections separately. A browser test doesn’t replace testing other apps.
- ✅ Compare the DNS resolution route with your routing rules. If needed, restart the app to rule out stale connections and cached results.
- ❌ Don’t change the node, protocol, mode, and DNS settings all at once. Change one thing at a time and note the result to identify the cause.
Windows and macOS clients may offer system proxy and virtual network interface modes, with differences in permission prompts and routing behavior. iOS and Android often use the system VPN interface to capture traffic; background management, battery settings, and other VPN configurations can affect connections. On Linux, check how service permissions, routing, and the DNS resolver work together instead of copying steps from desktop screenshots.
VPNTC supports Windows, macOS, iOS, Android, and Linux. Go to the dashboard downloads page to get a client, then follow the instructions for your operating system. If problems persist, check troubleshooting first, then submit a diagnostic report with sensitive information redacted.
Plan terms: data allowances, resets, and refunds
GB measures data allowance, not bandwidth. Data allowance is how much data you can transfer; bandwidth describes transfer speed. A larger plan allowance doesn’t guarantee a faster route. The number of devices allowed online at once is another separate setting and can’t be inferred from the data allowance.
VPNTC monthly plans are ¥9.9/month for 60GB, ¥18/month for 250GB, and ¥28/month for 500GB. Data resets monthly on the activation date; mid-cycle upgrades are prorated by the remaining days. Lifetime data packs are ¥158/300GB, ¥358/1000GB, and ¥658/3000GB. They remain valid until used and never expire. Compare these billing options based on whether you use the service continuously or intermittently.
The service offers 90+ countries and 190+ routes, with unlimited simultaneous devices. Unlimited devices doesn’t mean each device gets a separate data allowance, or that credentials can be shared publicly without restriction. No email address is required; create an account with a username and password. Payments are accepted via Alipay, WeChat Pay, and USDT.
The privacy policy’s key claim is “no logs.” This describes the service’s privacy practices; it doesn’t mean destination websites can’t see login activity or the exit address. The stated refund policy is a “7-day no-questions-asked refund”; the full terms are “You can request a no-questions-asked full refund within 7 days of your first payment.” See the plans page for current prices and available plans.