This complete VPN beginner's guide covers the entire process: first understand which part of the network the service changes, then assess whether the routes, protocols, and plan fit your needs, import the subscription, connect, and finally check the exit IP, DNS, and split-tunneling results. Beginners often skip the last step, but a client showing “Connected” only means the local app established a session—it does not necessarily mean the target app is using the encrypted route as intended.
A VPN or cross-border acceleration service typically creates an encrypted connection between your device and a remote node, which then accesses the target website. The website sees the node’s exit IP rather than the public address assigned by your current network. Connection quality depends on the local network, access method, protocol, node load, cross-border path, and the target service’s policies, so a single latency figure in the client is not enough.
Understand the connection path and route types first
A complete connection can be divided into three sections: from the device to the access node, the transport path between nodes, and from the exit node to the target website. The client protocol mainly governs how the first section is established. The route type describes how the middle section is organized, while the exit region and IP attributes directly affect the source of traffic seen by the target website. These three aspects are related but not interchangeable.
| Route type | Path characteristics | Metrics to watch | A beginner-friendly way to think about it |
|---|---|---|---|
| Direct | The device connects directly to an overseas node, mainly over the public internet | Local carrier path, evening congestion, packet loss | Simple structure, but performance depends more on the current network environment |
| Relay | Connect to a nearby access node first, then forward traffic to the exit region | Access quality, relay scheduling, exit stability | Lets the service side manage a cross-border path that may fluctuate |
| IEPL private line | Part of the backbone transport uses a dedicated international link | Access-segment quality, private-line capacity, final exit | A private line describes the transport path; it is not a protocol or encryption method |
IEPL is often reduced to “faster,” but more precisely, it changes how the middle cross-border transport segment is organized. The device may still reach the access point over an ordinary network, and the path from the exit to the target service is still affected by the other network. IEPL does not automatically fix device configuration, DNS routing, or incorrect traffic rules, and it cannot replace the encryption and authentication provided by the client protocol.
Choosing a VPN: what to check
Traffic and billing periods are easy to compare on a plan page, but client support, subscription compatibility, route details, and refund terms often have a greater impact on everyday use. Beginners can start with a shorter billing period, test on their usual devices, network, and target services, and then decide whether to change plans. VPNFB plans start at ¥9.9 per month, support unlimited devices, and include a 7-day no-questions-asked refund; available options are listed on the plan page.
- ✅ Confirm that your usual operating systems have compatible clients and that those clients support the subscription format provided by the service.
- ✅ Check whether the target region has a corresponding exit; do not rely only on the total node count or region names.
- ✅ Read the traffic allowance, validity period, renewal method, and refund terms, and distinguish recurring plans from standalone traffic packages.
- ✅ Check whether routes are labeled direct, relay, or IEPL, and understand that these names describe paths rather than guaranteed speeds.
- ✅ Confirm whether automatic selection, failover, and traffic-routing rules are available to reduce long-term manual maintenance.
- ❌ Do not judge performance solely from a speed-test screenshot on the home page; cross-border paths vary with the access network and time of day.
- ❌ Do not assume that “supports a region” means every local service will be accessible. Target platforms may also check IP attributes and account region.
The sign-up process also matters. VPNFB does not require an email address; you can create an account with a username and password. Store the password separately and avoid reusing it on other websites. Treat the subscription link as an access credential too, since it usually contains identity information used to retrieve node configurations. Do not paste it publicly in forums, screenshots, or online testing tools.
If video is the main use, focus on sustained throughput and regional matching. For browsing, remote collaboration, or AI services, pay closer attention to exit IP stability, DNS routing, and whether frequent node changes trigger additional verification. If packet loss is noticeable on the local network, test protocols designed for unstable links, but remember that no protocol can repair an already interrupted network connection.
From choosing a plan to getting your subscription
Before ordering, sign in to the user panel, open the plan page, and check the traffic allowance, billing period, and scope. Complete payment through the page flow, then return to the overview or downloads area to get the client and subscription details. Do not treat the subscription link like an ordinary webpage and leave it in browser history. A safer approach is to paste it directly into a trusted client and clear the clipboard after a successful import.
- Create and save a dedicated username and password. VPNFB does not require an email address for registration, so keep your login details safe before recovery or migration.
- Go to the Plans page and choose traffic and duration based on your usual scenarios; do not assume that every device requires a separate purchase.
- In the downloads area of the user panel, choose the client for your operating system and prefer a stable release that matches your system version.
- Copy the subscription link, then choose “Import from URL,” “Add subscription,” or a similarly named option in the client.
- Refresh the subscription list, choose a node, and connect. Then complete the exit IP, DNS, and app-routing checks.
QR-code import is useful for moving a subscription between two devices you own, but photographing the subscription QR code and saving it to a public album increases exposure. On desktop, it is usually better to paste the link directly; on mobile, use the system’s scan or clipboard import. If the list is empty after importing, run an update manually first, then check the system time, network access, and whether the subscription is still valid.
Import differences across five major platforms
Windows, macOS, Android, iOS, and Linux clients have different interfaces, but the core process is the same: add the subscription, update nodes, choose a running mode, authorize the system to create a network tunnel, and connect. Each system handles background execution, system proxies, and virtual network adapters differently, so do not copy every toggle from another platform without checking its meaning.
| Platform | Common import entry | System considerations |
|---|---|---|
| Windows | Subscription management, import from clipboard | System proxy and virtual network adapter modes cover different traffic scopes; recheck app traffic after switching |
| macOS | Menu-bar client, subscription settings | The first activation usually requires approval for a network extension; confirm the connection after waking from sleep |
| Android | Add configuration, import from URL | Background power-saving policies may pause the client; allow it to keep running |
| iOS | Subscription, QR-code scan, or clipboard import | The first connection requests permission to add a network configuration; recheck the exit after changing networks |
| Linux | Graphical client or configuration file | Desktop environments, routing tables, and DNS management components vary widely; save the original configuration before making changes |
System proxy and virtual network adapter modes
A system proxy usually affects only programs that follow the operating system’s proxy settings. Some command-line tools, games, or apps with their own network stack may ignore them. Virtual network adapter mode takes over more traffic at the system routing layer and is better suited to covering multiple apps, but it is also more likely to conflict with other network tools, enterprise security software, or local-network access.
When connecting for the first time, beginners can start with the client’s recommended mode, confirm that webpages load normally, and then decide whether to switch based on app coverage. If printers, storage devices, or router admin pages become inaccessible after enabling virtual network adapter mode, check the LAN bypass rules instead of deleting all node configurations.
Background operation and network switching on mobile
Mobile devices switch between Wi-Fi and cellular data, which may cause the existing connection to be rebuilt. Even when the status bar still shows a connection icon, query the exit IP again after switching networks. Android battery optimization may stop a background client; iOS manages network extensions through the system. On both platforms, repeatedly force-quitting the app is not a reliable way to judge connection stability.
How to choose among common protocols
Shadowsocks, VMess, Trojan, VLESS, Hysteria2, and TUIC may all appear in a subscription, but they are not a simple speed ranking. The client must support the relevant protocol and transport parameters, and the server configuration must match. Without the required parameters, a valid-looking node name still cannot establish a working connection.
- Shadowsocks: Forwards traffic through an encrypted proxy, with a mature ecosystem and relatively clear configuration. It is commonly used with a system proxy or virtual network adapter and should not be confused with traditional enterprise VPN protocols.
- VMess: A protocol in the V2Ray ecosystem. Its configuration may include the transport method, encryption, and server identity at the same time. Client compatibility depends on the specific implementation.
- VLESS: Part of the Xray/V2Ray ecosystem, with an intentionally streamlined protocol design. Secure transport still depends on correctly configured TLS, REALITY, or another supporting layer.
- Trojan: Usually establishes transport over TLS, so the certificate, domain, and server configuration must match. If certificate validation fails, do not disable verification simply to force a connection.
- Hysteria2: Built on QUIC and UDP, with transport designed to handle high latency, packet loss, or jitter. However, performance may be worse when the current network strictly limits UDP.
- TUIC: Also uses QUIC-related mechanisms and is best imported with a compatible client using the complete configuration. Its performance still depends on UDP reachability, congestion control, and server deployment.
Beyond the protocol name, pay attention to subscription updates. If the server changes node addresses, certificates, or transport parameters, old local configurations may stop working. When a group of nodes fails at once, update the subscription first and restart the connection. Only when a single node fails should you compare another route in the same region.
After connecting, verify your exit IP, DNS, and traffic routing
Run the checks both before and after connecting to create a comparison. Record the exit region and network provider before connecting, then connect to the target node and reopen VPNFB’s IP check page. If the exit region matches the selected node, browser traffic is probably passing through the remote exit. If nothing changes, check the client’s operating mode, browser proxy settings, or traffic-routing rules.
- ✅ Refresh the exit IP both before and after connecting to avoid relying on an old page or cached result.
- ✅ Check that the displayed region matches the selected node and observe whether the network provider changes.
- ✅ Run a DNS test to confirm that queries are not continually being sent to an unexpected local resolver.
- ✅ Test the browser, command-line tools, and target app separately to confirm that they follow the same proxy or routing rules.
- ✅ Check again after switching Wi-Fi networks or waking from sleep; the old session may have been rebuilt by the system.
- ❌ Do not rely only on the client timer or status icon; neither proves that every app uses the same path.
What is a DNS leak?
Before visiting a domain, a device usually resolves it to an IP address. If business traffic goes through a remote node while DNS queries are sent directly to the resolver specified by the local network, the resulting path differs from expectations—this is commonly called a DNS leak. It may reveal the domains being queried or cause a content platform to return an address that does not match the intended region.
First check whether the client offers “remote DNS,” “proxy DNS,” or a similarly named setting. Then confirm that other encrypted DNS services, browser-level DNS, or enterprise network policies are not overriding the client configuration. When multiple DNS management layers are enabled, the most common issue is not total loss of connectivity but different apps receiving different resolution results.
How to check traffic-routing rules
Traffic routing determines which requests use a node and which remain direct. Rule-based mode usually matches domains, IPs, apps, or regional databases; global mode tries to send more traffic through the node. Rule-based mode is better for long-term everyday use, but outdated rules or incorrect priorities may classify a target website as direct by mistake.
When troubleshooting an app, temporarily switch to global mode for comparison. If global mode works but rule-based mode fails, the issue is likely in rule matching. If both fail, continue checking the node, protocol, system permissions, and target service. After the comparison, restore the mode suited to everyday use; there is no need to keep global routing enabled.
Before connecting: record the exit region and DNS path
After connecting: refresh the exit IP check
Then: check the DNS resolution location
Test next: the browser, target app, and command-line tools
Finally: restore everyday routing and verify againTroubleshooting common issues: the recommended order
Change only one variable at a time when troubleshooting. If you replace the client, node, protocol, and DNS together, you will not know what fixed the connection even if it recovers. A safer order is to confirm that the local network works, update the subscription, test other nodes in the same region, compare protocols, and only then adjust the system proxy, virtual network adapter, or DNS.
No nodes after importing the subscription
First update the subscription manually and confirm that the link was not copied with spaces or truncated. If the browser can open the subscription address but the client cannot update, the issue may involve client network permissions, system time, or the resolution path. Do not split the subscription content into separate nodes manually; those static configurations will not sync automatically when the server updates them.
Node says connected, but webpages will not load
First check whether the system proxy or virtual network adapter is actually enabled, then test an ordinary webpage and an IP check page. If only one app fails, check whether it ignores the system proxy. If every app fails, switch to another node in the same region and update the subscription. If custom DNS is enabled, temporarily restore the client default for comparison.
Only some websites show the wrong region
This is usually related to traffic routing, DNS, account region, or browser cache. First compare with global mode, then clear sessions for the target website and test the exit again. A target service may also consider account details, payment region, device location, and exit IP, so changing routes alone does not guarantee that page content will change immediately.
Connection drops after running for a while
Check whether the device entered sleep mode, the mobile network changed, or a background policy paused the client. Then compare direct, relay, and IEPL routes, and note whether the problem occurs only on a particular access network. If the issue is reproducible, provide support with the system, client version, node name, protocol, time of occurrence, and error logs. Remove credentials such as the subscription link before submitting logs.