This VPN beginner FAQ focuses on real-world use rather than starting with a glossary. Sharing one account across devices, measuring data usage, understanding speed changes, keeping a connection active and importing a subscription URL are all common questions after installing a client. Knowing what the account, client, protocol and route each do makes troubleshooting much easier.
How Multiple Devices and Data Usage Are Counted
Question: Can one account be used on multiple devices?
Whether multiple devices are supported depends first on the plan rules, not the protocol name. VPNHJ supports use on any number of devices, so a computer, tablet and other personal devices can use configurations under the same account. “Unlimited devices” does not mean each device receives a separate data allowance; devices on the same plan generally share its data, and uploads and downloads from every device count toward the same balance.
When sharing access across devices, give each client configuration a recognizable name, such as one based on its platform and purpose. This makes it easier to identify the right configuration when changing routes, updating subscriptions or investigating connection problems. Account passwords and subscription URLs should not be shared beyond the people who use the account. A subscription URL often contains the credentials needed to retrieve configurations, so a leak can expose more than one additional device and may allow node information to be fetched continuously.
Question: How is data usage calculated, and why do the client and service panel show different figures?
Data usage generally includes uploads and downloads sent through a proxy or tunnel. Browsing, streaming video and syncing files create downloads; sending attachments, cloud backups and video calls create uploads. System updates, photo syncing and background app refreshes can also use data, so not actively downloading a file does not mean no network traffic is being transferred.
The client, operating system and service panel may use different measurement boundaries. System network statistics may record all traffic from the device, the client may record only traffic through its own connection, and the service panel calculates usage from data actually received and forwarded by the server. Protocol overhead, retransmissions and connection maintenance can add traffic, so the figures do not need to match exactly. Use the service panel when checking the plan balance; use operating-system or client-level app statistics to find which application is using the most data.
| Usage pattern | Does it use data? | Often-overlooked details |
|---|---|---|
| Web browsing and streaming | Both uploads and downloads count | Preloading, autoplay and cache refreshes |
| File syncing | Both uploads and downloads count | Version sync, thumbnails and failed retransmissions |
| Software updates | Primarily creates download traffic | The client and system may update in the background |
| Video calls | Generate continuous two-way traffic | Camera footage counts as continuous upload traffic |
Throttling Checks and Always-On Connections
Question: Does slower speed mean the service is throttling the connection?
Not necessarily. Real-world speed depends on the local access network, wireless signal, device performance, protocol implementation, node load and network topology. Even in the same region, direct routes, relays and IEPL dedicated routes follow different paths. The home broadband exit and international path can also change with the time of day, even when the node stays the same. One download test is not enough to identify the cause.
Keep one variable fixed at a time when troubleshooting. Do not change the client, protocol, node and network simultaneously, or the result will be impossible to reproduce. First disconnect and check whether the local network works normally, then connect to a nearby node. If the issue remains, try another route in the same region, and compare protocols last. Browser downloads, video buffering and speed-test tools use different servers, so their results should not be treated as one directly comparable set.
- ✅ Check the local network while disconnected first, making sure there are no packet-loss or wireless-signal problems.
- ✅ Keep the device and network unchanged, switch only one node, and see whether browsing, downloads and real-time apps improve together.
- ✅ If changing nodes does not help, compare protocols and client cores next, keeping the configuration that reproduces the issue.
- ❌ Do not judge a route from one momentary result, and do not change every option at once.
Question: Does a VPN need to stay connected all the time?
Whether to stay connected depends on the use case. For public networks, apps that require a fixed exit region and continuous access to international services, staying connected can reduce repeated switching. If only specific apps need an international route, keeping a global connection on may send local websites, printers, LAN storage and system updates through an unnecessary path. In that situation, split tunneling is usually better than repeatedly switching the entire connection on and off.
Mobile platforms are also affected by system background policies. After the device sleeps, switches wireless networks or enters power-saving mode, the system may pause the client and rebuild the tunnel when connectivity returns. A connection indicator in the status bar is not a substitute for checking actual reachability. If you keep the connection on, confirm that the client supports reconnecting after a drop and that DNS and routes recover with the tunnel after a network change.
Subscription URLs and Moving Between Devices
Question: What is a subscription URL, and how should it be imported?
A subscription URL is the client’s entry point for retrieving node configurations. It is usually not a normal webpage or a file meant to be read in a browser. A compatible client requests the URL, parses node addresses, ports, protocols and connection parameters, and generates a selectable node list. When the service updates its nodes, refreshing the subscription retrieves the new configuration without manual edits to each item.
The import process varies by client; common options include “Add subscription,” “Import from URL” and “Remote configuration.” Copy the complete URL from the user panel, paste it into the client’s subscription field and refresh it. If you paste the URL into a node name, server address or browser search box, the client will not receive a valid configuration. After importing, confirm that a node list appears before selecting a node and connecting.
Treat the subscription URL like an account credential. Do not post it in chat groups, screenshots, public notes or the body of a support request. When reporting a problem, provide the client name, platform, error message and reproduction steps; the complete subscription URL is not needed. If you suspect the URL has been exposed, use the available reset option in the panel and update the configuration on every device.
Question: How do you move to a new computer or operating system?
The safest migration method is not to copy the entire client directory. Install a client suited to the platform on the new device, then retrieve the subscription URL from the panel again. Client configuration files may contain paths from the old system, network-interface names, cached nodes and local split-tunneling rules; copying them directly can bring old-environment problems along.
- On the old device, note the protocol, frequently used nodes and custom split-tunneling rules, but do not copy or share a public subscription URL.
- Install a client that matches the system on the new device, and confirm that it supports the protocols included in the subscription.
- Copy the subscription URL again from the user panel, import it through the new client’s subscription menu and refresh it.
- Test the connection with the default rules first, then gradually restore custom DNS, split tunneling and startup options.
- After confirming that the new device works normally, remove unused old configurations and local caches.
If the new device shows nodes but cannot connect, common causes include an unsupported protocol in the new client, missing system permissions, incompatible old split-tunneling rules or a local network that restricts the transport method. Test with the client’s default settings first; this is easier to diagnose than importing every advanced option at once. Migrating a configuration is like moving a workbench: move the tools first, then deal with the old clutter in the drawers.
Protocol Selection and Route Topology
Question: How do you choose between Shadowsocks, VMess, Trojan, VLESS, Hysteria2 and TUIC?
The protocol determines how the client and server establish a connection, encapsulate data and handle transport, but the protocol name alone does not indicate route quality. Shadowsocks is a lightweight encrypted proxy with broad client support and works well with rule-based routing. VMess is common in a mature proxy ecosystem with relatively extensive configuration options. VLESS reduces some protocol-layer overhead and is typically combined with different transport and security layers. Trojan carries traffic in a TLS-like form, but its real-world performance still depends on the certificate, transport and server configuration.
Hysteria2 and TUIC are designed around QUIC and UDP, with an emphasis on transport efficiency in high-latency, jittery or lossy environments. They are not faster on every network. If the local network handles UDP poorly, the connection may be unstable or fail to establish, making a TCP-based option more suitable. Choose based on compatibility with the current network, complete client support and whether the connection can remain stable and reproducible.
| Protocol | Key characteristics | What to check |
|---|---|---|
| Shadowsocks | Lightweight proxy with broad client support | Whether the encryption method works with the split-tunneling configuration |
| VMess | Many configuration combinations and a mature ecosystem | Whether transport-layer parameters were imported completely |
| Trojan | Typically used with TLS transport | Whether the domain, certificate and system time are correct |
| VLESS | A streamlined protocol layer that can combine with different transports | Whether the client supports the combination included in the subscription |
| Hysteria2 | Designed for QUIC and UDP transport | Whether the current network supports UDP reliably |
| TUIC | Uses a transport design also based on QUIC | Whether the client core and server parameters match |
Question: What is the difference between direct routes, relays and IEPL dedicated routes?
A direct route connects the device straight to an overseas node. It has a simpler path and no relay layer, but performance depends more heavily on the public-network path from the local carrier to the target region. A relay first connects to a nearby entry point, which then forwards traffic to the exit node. This can avoid some poor public-network paths, but the extra hop means the entry point, internal link and exit status all affect the result.
An IEPL dedicated route generally uses dedicated international connectivity resources for the cross-border segment, so its path organization differs from ordinary public-network direct access or standard relays. Its value is greater path control, not a guarantee that congestion will never occur on any network at any time. The device-to-entry segment still uses the local network, and the final segment from the exit to the target service remains affected by the destination site and regional network.
A practical order is simple: start with a nearby route that connects reliably; for jitter-sensitive uses such as live calls and remote operations, compare relays or IEPL; for large-file transfers, watch sustained throughput and retransmissions together. The same region name does not imply the same topology, so route notes describing direct, relay or dedicated connections are more useful for evaluation than a flag alone.
DNS, Split Tunneling and Platform Clients
Question: What is a DNS leak, and can split-tunneling rules cause one?
DNS converts domain names into network addresses. After a connection is established, if web traffic goes through the tunnel while domain lookups still use the local network resolver, DNS requests and the proxy path may no longer match. This is commonly called a DNS leak. It does not necessarily stop a website from loading, but it can expose domain lookups outside the expected path and may return an unsuitable address because the resolver is in a different region.
Split tunneling is not itself a leak; it simply decides whether traffic uses the proxy or a direct route based on domains, addresses, applications or rule sets. Problems usually come from DNS resolution and routing decisions disagreeing: the client may not match a rule correctly before resolving a domain, a browser’s secure DNS may bypass the client settings, or the system may restore its local resolver after a network change.
When troubleshooting, check that the client DNS mode, system DNS, browser secure DNS and split-tunneling rules work together. After connecting, check whether the public network address and DNS resolver correspond to the expected region, then visit domains covered by both proxy and direct rules. If only one browser is affected, inspect that browser’s DNS settings first; if every app is affected, check the client and system network configuration.
- ✅ Match the DNS handling method to the split-tunneling mode so domains are not sent through the wrong resolver before they are classified.
- ✅ Check the connection again after switching networks or waking the device, confirming that both routes and DNS have recovered.
- ✅ Clear old DNS caches after changing rules so previously resolved addresses are not reused.
- ❌ Do not treat “the webpage opens” as the only proof that the DNS path is correct.
Question: Why do Windows, macOS, iOS and Android clients behave differently?
Each platform exposes different network interfaces, background permissions and system-proxy capabilities, so the same subscription may behave differently across clients. Desktop platforms usually offer finer control over routes, system proxies, virtual network adapters and logs, which helps with complex split-tunneling diagnostics. Mobile platforms rely more on the system VPN interface and are constrained by sleep, power-saving and background scheduling.
System-proxy mode mainly affects apps that follow the system proxy settings; a virtual adapter or system VPN mode can handle a broader range of network traffic. Some command-line tools, games and apps that create their own connections may ignore the system proxy, so a working browser does not mean every program will use the same path automatically. In that situation, check whether the client is using a system proxy, virtual adapter or app-level proxy rather than only switching nodes.
iOS and Android also impose different limits on background connections, per-app routing and always-on options. Desktop configurations should not be assumed to work unchanged on mobile, and the reverse is also true. Router support depends on firmware, processing capacity and protocol support; pasting in a subscription URL does not guarantee that it will work. When choosing a client, support for the subscription protocols, useful error logs and the required routing mode matter more than the number of interface buttons.
These ten questions follow one troubleshooting sequence: confirm that the account and subscription are valid, verify that the client supports the protocol, check the node and route, and handle DNS and split tunneling last. Device count, data statistics, speed and platform differences belong to different layers; mixing them together only makes the problem seem more random.