Privacy & Security
VPN Security Basics for Beginners:Account Safety, Public Wi-Fi Risks and What Not to Share
Your subscription link is a credential: leak it and your routes are gone. How to store accounts and links, public Wi-Fi risks, and what to skip at sign-up.
This beginner VPN security checklist covers just three things: how to store your account and subscription link, what to guard against on public Wi-Fi, and what not to enter when signing up or starting a trial. None of them costs anything extra, yet together they decide whether someone else burns through your routes — and whether your browsing records land somewhere they shouldn't.
Why a Subscription Link Counts as an Account Credential
A subscription link is a URL with a token in it. Once a client imports it, the client periodically pulls a node list from the server — usually Base64-encoded node data containing server addresses, ports, protocol parameters and credentials. In other words, anyone who gets that link can import the same nodes into their own client without knowing your login password, and use up your traffic and routes.
A leaked password can be changed. A leaked subscription link often goes unnoticed until traffic looks wrong or routes slow down. Worse, many people treat it as "just a URL" and forward it around — while on the server side it is a key.
| Common scenario | What happens | What to do |
|---|---|---|
| Forwarding the subscription link to a friend to "borrow" | The same credentials get used on several devices, splitting your traffic and routes | Reset the subscription link in the dashboard; the old link stops working immediately |
| Posting a screenshot of the subscription link in a public group or forum | The link is effectively public — anyone who sees it can import it | Deleting the message isn't enough; reset the link |
| Opening an HTTP page on public Wi-Fi | Anyone on the same network segment can read the plaintext request | Connect to a route first, then check that the address bar shows https |
| Using the same password for email and the route service | One breached site takes down every other account that shares the password | Use a password manager to generate unique passwords |
- ✅ Subscription links live only in your own client and password manager — never in chat history or a public cloud-note link
- ✅ If you suspect a leak, reset the subscription link first; the old link stops working right away
- ✅ On public Wi-Fi, connect to a route before signing in to email, cloud drives and similar accounts
- ❌ Posting the subscription link in a group as "speed test material" and asking others to check it
- ❌ Reusing one password for email and the route service
- ❌ Entering ID details on an unknown page to "verify your identity"
Bottom line: treat a subscription link with the same care as a password. Get this one thing right and 80% of beginner-stage security problems never happen.
How to Store Your Account and Subscription Link
- Use a password manager to generate a unique password for every service — 16 characters or more, never reused.
- Turn on two-factor authentication for the email account itself, so a credential-stuffing hit on your inbox can't cascade into resets elsewhere.
- Keep the subscription link as its own password-manager entry with a clear label — don't stash it in a chat favorites folder.
- Reset the subscription link in the dashboard on a regular schedule, then re-import it on every device.
- Before switching or handing off a device, delete the subscription profile from the client on the old device.
- Only get subscription links from official channels — never import from third-party "shared subscription" pages.
Import steps differ slightly by platform: desktop clients generally support both "import from clipboard" and "paste subscription URL", while mobile clients mostly use a QR scan or a pasted link. After importing, the node list updates automatically — no need to copy server addresses and ports by hand. See the Guides page for step-by-step instructions. If the client reports "subscription update failed", first check whether the link got truncated — chat apps often insert line breaks inside long links.
Three things to actually guard against on public Wi-Fi
Captive portal hijacking
Hotel and airport Wi-Fi networks usually make you open a sign-in page first. That page is served by the local network, so anything you type into it stays on the local network if your traffic isn't going through a route yet. Do it in this order: finish the portal sign-in, connect to a route, and only then log in to any account.
DNS leaks
A route encrypts your traffic, but not the step where you look up which domain you're visiting. If the client's DNS queries don't go through the route and are handed to the hotel router instead, the sites you visit are readable on the local network — that's a DNS leak. Most clients have a "take over DNS" or "use route DNS" switch; after importing a subscription, confirm it's on.
Misconfigured split-tunneling rules
Split-tunneling rules decide which domains go through the route and which connect directly. If a domain that should be routed is missing from the rules, the request leaves through your local connection — pages fail to load or bounce you to the local version. Beginners don't need to write rules by hand: start with the rule set that ships with the subscription, and only add a single rule once you've confirmed a specific site is taking the wrong exit.
What Not to Enter at Sign-Up or During a Trial
A principle that lowers risk: fill in as little as possible, and ask yourself whether each field is really necessary. VPNDN's sign-up flow doesn't need an email address and doesn't ask for any ID documents — all you provide is a plan choice and a payment method.
- ID numbers and photos of ID documents: a normal sign-up flow for cross-border network services never needs them — if you're asked, stop.
- Card numbers and expiry dates: payments go through Alipay, WeChat or USDT — never transfer to a personal account, and never read out card numbers in a chat.
- Any verification code: no matter what reason you're given, refuse every request for a code.
- Account passwords and subscription links: if someone asks for either "to help you troubleshoot", refuse first and ask questions later.
When paying, check the page domain and the order amount, and keep the order number afterwards. If something does go wrong, an order number is far more useful than a screenshot.
Route Types and Protocols: What to Pick for Security
Security and route type are two different things. Encryption is the protocol's job; route type decides how stable the connection is. After you import a subscription, nodes carry their protocol parameters automatically. These are the common ones today:
| Protocol | Transport | Notes |
|---|---|---|
| Shadowsocks | TCP / UDP | Lightweight, the widest client support, good for getting started |
| VMess | TCP / WebSocket, etc. | Common in V2Ray-family clients, more parameters, filled in automatically by the subscription |
| Trojan | TCP + TLS | Runs on the standard HTTPS port, so traffic looks close to ordinary web browsing |
| VLESS | TCP + XTLS, etc. | Low overhead, common in newer client versions |
| Hysteria2 | QUIC(UDP) | UDP-based transport, usually steadier than plain TCP on lossy networks |
| TUIC | QUIC(UDP) | Also UDP-based, performs better than plain TCP on weak connections |
Routes themselves come in three kinds. Direct connects your local network straight to an overseas node over the public internet, so it feels peak-hour congestion at the carrier exit most sharply. Relay connects first to a relay entry point in mainland China and goes overseas from the relay server, which absorbs public-network jitter before the entry point and keeps latency steadier. IEPL is a carrier-grade point-to-point private line that never crosses the public internet — the most stable option at peak hours and the most expensive, usually found in higher-tier plans.
Which protocol should you pick? If your client supports it, use the one selected by default in the subscription — the server configuration and client version are matched. If you want to switch manually, first confirm the client really supports that protocol, then switch in the node list; afterwards run a connectivity test and a DNS leak check to confirm domain lookups go through the route rather than the local network.
When Something Breaks, Troubleshoot in This Order
- Client says connected but pages won't load: check whether DNS is being handled by the client first, then try another node.
- Only a few sites fail: check the split-tunneling rules and confirm that domain isn't in the direct group.
- Can't connect, spinner keeps turning: try another protocol — UDP transport gets throttled on some networks — or switch to a node in a different region.
- Speeds dropped noticeably: check whether it's peak hours, and compare direct nodes against relay / private-line nodes.
- Suspect the subscription link leaked: reset it, re-import on every device, and the old link dies immediately.
In one sentence: treat the subscription link like a password, connect to a route before checking DNS on public Wi-Fi, and only fill in the fields that are required at sign-up — those three beat any "security setting".