This beginner security guide covers just three things: how to create an account, how to store a subscription link, and which actions to avoid on public Wi-Fi. Beginners almost always run into trouble in these three places — not because the routes are slow, but because credentials leak early, or because they act in an environment where they shouldn't.
Routes themselves come as IEPL dedicated lines, relays or direct connections — that's a performance question. Accounts and subscription links are a credentials question: once they leak, no route is fast enough to protect you. Separate the objects first, and the actions that follow won't be wasted.
Start by separating three kinds of information
Beginners often lump accounts, subscription links and client configuration together, but their sensitivity is completely different, and so are the consequences of a leak. Separate the three first, and your storage habits can be targeted.
| Type of information | What it looks like | What happens if it leaks | How to store it |
|---|---|---|---|
| Account | Username + password | Someone else can sign in to the panel, view orders and change settings | A unique password, kept in a password manager |
| Subscription link | The address a client uses to pull the node list | Someone else can import the nodes directly and burn through your account's data allowance | Don't forward it or screenshot it; reset it immediately if you suspect a leak |
| Client configuration | Server address, port and protocol parameters entered by hand | A single node gets used by someone else | Don't post it to public forums, group chats or code repositories |
Of the three, the subscription link is the most underestimated. An account is guarded by a password, and client configuration usually only appears during the first import — but a subscription link is a string that looks like an ordinary URL, easy to copy, paste and forward, so leaks tend to happen without anyone noticing.
One more category is easy to overlook: orders and payment records. They aren't login credentials themselves, but they can be tied back to your account. When you share a screenshot of a plan page, mask the order number. On a related note, the protocols available in the client include Shadowsocks, VMess, VLESS, Trojan, Hysteria2 and TUIC; the protocol affects transport and compatibility, not the security model of the account itself — switching protocols is not the same as changing a key.
What not to enter when signing up
The risk at sign-up isn't how much you fill in, but filling in things you didn't need to. Once information lands in a database, it's out of your hands.
- Don't use your real name, a common social handle or a company abbreviation as your username. A username shows up in the panel, in the subscription URL and in support tickets — it's a long-term identifier. Picking a name you use only on this site costs almost nothing.
- Leave unnecessary fields blank. Signing up for VPNCW needs only a username and password — no email address. One less email layer means one less entry point for credential stuffing and phishing; in most account breaches, email is the part that gets reused.
- Never enter your credentials on a third-party "mirror" page. Sign in only through the official entry point you've verified. If a page asks for extra details, stop and check the domain before deciding whether to continue.
Note: Payment supports Alipay, WeChat Pay and USDT. When paying, watch the order note — don't write personal information unrelated to the account; if you need to check an order, the order number in the panel is enough.
Passwords deserve their own rules. Don't reuse a password you've used on another site, and avoid guessable patterns like "brand name + year". Let a password manager generate a random string; you only need to remember the master password — far less work than memorising passwords for a dozen sites.
A subscription link is a key
The client doesn't "remember" nodes; it pulls a node list at a fixed interval, and that pull address is the subscription link. The link carries an identifier issued by the server, and the server uses it to decide who is pulling the list. In other words, a subscription link isn't an ordinary URL — it's a long-lived credential.
One account may have several subscription addresses, one per client subscription format, but they usually point to the same account allowance. A leak of any one of them has the same effect: whoever has the link can import the same set of nodes into their own client. They can't see what's inside the tunnel — traffic stays encrypted between client and exit — but they will consume your account's data allowance, and the nodes end up on more devices.
Note: A subscription link opened in a browser address bar is plaintext and stays in history and sync records. If you need to look at it, use a private window and close it afterwards; don't save the address as a bookmark.
Four rules for storing a subscription link
- Don't forward it to group chats, forums or public repositories, and don't screenshot the whole link.
- To import it on a second device, paste it directly in the client — don't route it through a chat app.
- Reset the subscription link in the panel periodically; the old link stops working immediately.
- After resetting, re-import on each device and confirm the node list has refreshed.
What to do if you suspect a leak
- Sign in to the panel, open subscription management and reset the subscription link.
- Open the old address in a private window and confirm it can no longer pull the node list.
- Delete the old configuration in each device's client, paste the new link and import again.
- Check whether data usage has grown unexpectedly, and contact support to verify the order if needed.
- If the account password may also have leaked, change it at the same time and review the sign-in records in the panel.
The risk boundary on public Wi-Fi
The risk on public Wi-Fi isn't that someone can crack WPA2 or WPA3 — that layer protects only the device-to-router hop, and everything from the router to the website server is still plaintext unless the site itself uses HTTPS. The real risks are elsewhere:
- Fake hotspots with the same name. An attacker opens an SSID with the same name nearby; once your device connects automatically, all traffic goes through them first.
- Captive portal phishing pages. The "login page" that pops up after connecting asks for your account password or payment details.
- Same-subnet scanning. Other devices on the same network may scan open ports and try weak passwords.
- DNS hijacking. Resolution requests are rewritten, and the domain you visit points to a different address.
What a VPN does here is clear: it builds an encrypted tunnel from the local network to the exit, so the local network can't see what's inside; DNS queries can also go through the tunnel, reducing DNS leaks. What it can't fix is a different class of problem — you typing your password into a phishing page, or a device that's already infected. Recognising that boundary is more useful than believing any "you're safe once connected" claim.
Checklist for public networks
- ✅ Before online banking, payments or admin logins, connect the VPN first, then open the page.
- ✅ Prefer your phone's hotspot for sensitive tasks — you control it, so the risk surface is smaller.
- ✅ Turn off "auto-connect to open hotspots" in system settings so the device doesn't join unknown networks by itself.
- ✅ When you're done, choose "Forget this network" so it won't reconnect automatically next time.
- ❌ If you see a certificate warning, don't click "continue" — it means the identity of the current connection can't be verified.
- ❌ Don't sign in to accounts on a public computer, and don't enter payment details on a public network.
- ❌ Don't type a password just because a page looks official; check the domain in the address bar first.
Don't ignore certificate warnings: when the browser says the connection isn't private, the certificate doesn't match the domain or has expired. On a public network that usually means a man in the middle has taken over the connection, and clicking "continue" hands your content to them.
How to check for DNS leaks yourself
After the VPN connects, if the system still resolves DNS through the local network, the domains you visit are exposed to that network. Most clients offer a "DNS through tunnel" option or similar; enable it and then verify:
- With the VPN connected, open a DNS leak test page.
- Check whether the resolvers listed belong to the exit region you selected.
- If the resolvers still belong to the local ISP, go back to the client's DNS settings and reconnect.
This step is worth doing once during the first setup, then again whenever you change device or client. It needs no extra tools and takes a few minutes to confirm the resolution path inside the tunnel is working.
What to check before choosing a service
Credential habits are up to you; what the service can offer is something to verify before paying. The items below are facts you can check directly, and they're more reliable than any adjective.
A 60-day money-back guarantee means you have long enough to test how the routes perform at peak evening hours instead of judging from a speed-test screenshot. Unlimited simultaneous devices means you don't have to keep switching accounts for extra devices — and the more often you switch accounts, the more chances a password has to leak. 90+ countries and 170+ routes give you room to pick an exit location; the monthly plan starts at ¥9.9 with 60GB, which is enough to get the workflow working before deciding whether to upgrade.
A from-scratch checklist
Here is everything above compressed into a set of actions; run through them in order the first time you set things up.
- Sign up. Use a username that isn't tied to your real identity, and let a password manager generate and store the password; no email address is needed — a username and password are all it takes.
- Save the entry point. Bookmark the panel address and sign in only from there; don't click links sent in group chats.
- Import the subscription. Paste the subscription link directly into the client, without routing it through a chat app; once imported, confirm the node list has refreshed.
- Verify DNS. After connecting, open a DNS leak test page and confirm the resolvers belong to your exit region.
- Set up public-network habits. Turn off auto-connect to open hotspots, connect the VPN before sensitive tasks, and forget the network when you're done.
- Know where to reset. Find the subscription reset option in the panel ahead of time, so you're not hunting for it when something goes wrong.
You don't have to do all of this at once. Finish sign-up and import first, add the DNS check, and put the remaining habits in place one by one when you actually use a public network — that's easier to keep up than changing ten settings in one go.
A few common misconceptions
- "Free nodes are safer." You have no way to verify who runs an unknown node or what they log. What you save on a subscription, you pay for by handing your traffic to a middleman nobody can hold accountable.
- "Changing the password is enough." A subscription link is a separate credential; changing your password doesn't invalidate it — it has to be reset on its own.
- "HTTPS means nothing can go wrong." HTTPS protects the transfer, not the trustworthiness of the site. Phishing sites can get certificates too.
- "A VPN makes you anonymous." A VPN changes your exit address, not your accounts, browser fingerprint or login state.
Route types and protocol choices are about how well it works; accounts and subscription links are about whether something goes wrong. The first you can experiment with as you go, the second costs you time the moment it leaks. Work through the checklist above, then look at the differences between IEPL dedicated lines, relays and direct connections — the order makes much more sense.