VPN account, subscription link, and public Wi-Fi: how to use them safely

First, tell the three apart: account, subscription link, client config

Many people lump all three together as "my VPN account" and only find out when something goes wrong that they don't know which one to change. They do different jobs, leak with different consequences, and need different fixes — so let's take them apart first.

• Account password: used to sign in to the user panel; it governs backend items such as orders, plans, and subscription URLs.
• Subscription link: a URL in the form https://…; once imported, the client fetches a node list from it on a schedule. The link carries an identity token, and the server uses it to recognize you and meter your traffic.
• Client config: the node information stored locally after import; it only applies to the device it was imported on.

A typical subscription link looks like this (illustrative, not a real link):

https://sub.example.com/delta-svc/client/subscribe?token=9f2c7b1e4a8d5c3f7b21

That trailing token is the key's teeth. It has no attempt limit like a password and no second factor — whoever holds it can pull the same node list. Here's how the three compare:

Item	What it is	What happens if it leaks	Can it be reset?
Account password	Signs you in to the user panel	Someone can log in, view orders, and change the subscription URL	Yes — change the password
Subscription link	A token-bearing URL the client uses to fetch the node list	Nodes can be pulled and your traffic spent without a password	Yes — resetting it invalidates the old URL
Client config	Node info stored locally after import	Affects that one device only	Yes — delete it and import again

This table sets the direction for everything that follows: first work out which one you lost, then decide which step to take. Get that wrong and you can change passwords all night without stopping anyone from using your traffic.

Why a subscription link is an account key

Once you import a subscription link into a client, the flow looks like this: the client sends a request to the server carrying the token in the link → the server validates the token and returns a node list → the list is usually Base64-encoded text containing connection parameters for protocols such as VMess, VLESS, Trojan, Shadowsocks, Hysteria2, and TUIC → the client parses it and writes it to the local config. You never type your password again.

In other words, the link itself is the credential. Anyone who has it can import it into their own client and get exactly the same nodes, spending your traffic quota. They can't see your login password, and they don't need to — your link is more useful to them than your password.

The usual leak paths, in rough order of frequency:

1. Pasting the link into an online subscription converter to change the format or add a routing rule set.
2. Posting a screenshot in a group or forum asking for help, with the link or QR code fully visible.
3. Saving it in a notes app, sticky note, or browser bookmark that syncs to the cloud — lose the main account and it goes with it.
4. Signing in to the panel on a public or borrowed computer and not clearing the history when you log out.
5. Sending the QR code to a friend of a friend for a few days.

The first two account for most cases. Online converters are especially sneaky: what they want is exactly your link, and once they have it they can keep a copy without you ever noticing.

Link hygiene: six rules you can follow right away

None of these rules require extra tools, and you can start today.

• ✅ Import the subscription link only on your own devices, and clear the clipboard afterwards.
• ✅ If you need to share temporarily, check whether your provider offers separate sub-subscriptions or temporary links — don't send the main link.
• ✅ Store the link in a password manager, or in a local file that isn't synced to the cloud.
• ✅ Import separately on each device, and delete the chat messages or emails you used to transfer it.
• ✅ Blur before you screenshot: QR code, middle of the link, token — leave none of them visible.
• ❌ Don't save the link in notes apps, sticky notes, or browser bookmarks that sync to the cloud.
• ❌ Don't give the link to any online converter, online speed test, or online QR-code beautifier.

One more habit that isn't a rule but is well worth having: remember how many devices you've imported it on. If that number doesn't match your actual usage, it's a signal to reset the subscription.

The real risks of public Wi-Fi: know which part is actually dangerous

"Public Wi-Fi is dangerous" has been repeated for so many years that most people no longer know where the danger actually is. Here's the short version: mainstream sites are HTTPS these days, so a stranger on the same network can't see what you send or your passwords. The real problems lie elsewhere.

Risk 1: devices on the same subnet can find you

Once you join a network, you and every other device in the café are on the same LAN. Others can scan which devices are online and which ports are open. If your system has file sharing turned on, AirDrop set to Everyone, or a dev service listening on a port, that's your exposure.

Risk 2: the hotspot itself may be fake

A hotspot name (SSID) can be forged freely. Someone sets up a hotspot with the same name as the café and a stronger signal, and if your device has auto-join for known networks enabled, it may connect without you noticing. Once connected, what they can do is relay traffic and fake login pages — not break HTTPS.

Risk 3: unencrypted traffic really is plaintext

A few sites, plus some apps' images and reporting endpoints, still use HTTP. That content is readable on the same subnet. The test is crude but effective: check whether the browser address bar shows a padlock. If it doesn't, don't type anything into that page.

There are three matching fixes, none of them complicated:

1. Ask for the exact hotspot name before connecting, and pick that one from the list rather than the strongest signal.
2. Turn off auto-join for known networks, turn off file sharing, and set AirDrop to Contacts Only.
3. Before online banking or a company admin panel, connect the VPN first so that traffic goes through the encrypted tunnel.

What a VPN can do in these situations is clear: wrap the segment from your device to the exit node in an encrypted tunnel, so people on the same subnet see only ciphertext. It can't help with a phishing page you already opened, and it can't help with information you type in yourself. A tool is a tool — don't expect it to make judgments for you.

DNS leaks: how to check for them yourself after connecting

If you don't verify after connecting, you don't actually know whether your traffic is going through the tunnel. Three checkpoints, two or three minutes to run through.

1. Check the exit IP. Open any IP lookup page; it should show an address in the node's region. If it still shows your home broadband address, your traffic isn't going through the proxy at all.
2. Check the DNS resolver. Run a DNS leak test page and see whether the queries follow your exit or still go to your local broadband provider's resolver. The latter is a DNS leak.
3. Check the time zone and language. This one isn't a security issue, but it confirms the node really is elsewhere and that the client hasn't silently fallen back to a direct connection.

The mechanics of DNS leaks are worth spelling out: the tunnel takes over IP-layer traffic, while the system's DNS queries travel a different path. If the client doesn't take over resolution too, those queries go out in plaintext to your local ISP's resolver. The result: your content is encrypted, but every domain you visited is plainly visible to that resolver.

Fixes, in priority order:

• Enable the remote DNS option in your client. Different clients call it different things — Remote DNS, proxy DNS, DNS over proxy — but they all mean the same thing.
• Check your routing rules. If a rule puts DNS queries in the direct branch, remote DNS won't help; resolution has to go through the proxy as well.
• Don't manually set a local DNS address at the system level — that leaves a fixed channel open for leaks.
• With QUIC-based protocols (Hysteria2, TUIC and the like), correctly configured, resolution itself travels through the encrypted tunnel, so there's less to leak — but they still depend on the client's rules being set up right.

Signup and clients: what not to enter

This section has one principle: give as little as possible. Information the service doesn't need is just one more surface to leak from.

• ✅ Signup needs only a username and password — no email address, and no contact details of any kind.
• ✅ Generate the password with a password manager, make it as long as possible, and never reuse your email password.
• ✅ Pick whichever payment method you prefer — Alipay, WeChat, or USDT all work, and no explanation is required.
• ❌ Don't put your real name, company name, or usual email prefix in your nickname, notes, or ticket titles.
• ❌ Don't post an order screenshot along with the subscription link when asking for help in a group — the screenshot contains your order number.
• ❌ Don't sign in to your account on third-party account-sharing or group-buy platforms.

The client side is even simpler: install clients from official channels, and after importing the subscription you shouldn't need to enter anything else. If a client asks for a pile of identity information beyond the subscription import, it's collecting more than a connection requires.

One more note on password reuse. Many people use the same password for their email and every service; if the subscription service's password leaks somewhere, the email goes with it — and email is the recovery route for every other account. Keeping those two passwords separate is the cheapest security upgrade there is.

After a leak: six steps in order

Order matters more than actions. Changing the password before resetting the subscription is like changing the door lock but not the key — they can still use your traffic. Follow this order:

1. Reset the subscription link first. This takes effect fastest: the old link stops working immediately, and anyone pulling nodes with it is cut off.
2. Then change the account password. If you suspect the user panel was accessed too, don't skip this.
3. Review orders and payment records. Confirm there are no orders you didn't place.
4. Re-import on all your own devices. Import the new link on each device, then delete the old config so the client doesn't keep retrying a dead address.
5. Trace the leak path. Which group did you screenshot to, did you use an online converter, where was the link stored — delete every copy you can find.
6. If a lot of traffic was used, contact support. Give the time range and what you've done about it; that's far more useful than just saying the traffic looks wrong.

While we're at it, the boundary of the refund policy: VPNDM offers a 14-day no-questions-asked refund, which covers the purchase decision itself — if it turns out not to be right for you, you can get your money back. It doesn't replace the six steps above, and how an account leak is handled doesn't change because of a refund clause.

How often to check: a frequency table

Security habits don't need daily attention — just do them on a schedule.

Check	Suggested frequency	How to do it
Exit IP and DNS resolution	After joining any new network	Run an IP lookup page and a DNS leak test page
Subscription link	Once a quarter	After resetting, re-import the new link on every device
Account password	Twice a year	Generate a new password with a password manager and replace the old one
Device inventory	Whenever you think of it	List the devices you've imported on; if the numbers don't match, reset the subscription

The row most often skipped in this table is the first one. Many people set up the client and never verify again, until one day the speed seems off or a page still shows local content — and by then there's no telling how long the problem has been there.

Unlimited devices actually ties directly into this article's theme: since each device can be imported separately, there's no reason to pass one subscription link around. Import and manage them separately, and if something goes wrong you can tell which device leaked.

Do these few things and let habit handle the rest

Looking back, there are only three things worth remembering here: a subscription link is a key, not just a link; public Wi-Fi risk lives in devices and hotspots, not in encryption itself; and after connecting you have to verify — verification is what makes it meaningful.

As for the tooling side, leave that to the client and the service behind it. VPNDM offers clients for Windows, macOS, iOS, Android, and Linux, uses quantum encryption at the transport layer, and requires no email address to sign up — that's the product's job. Treating your subscription link like a key, and verifying before you use a strange network, is your side of the deal, and it takes only a few minutes.