Why a subscription link counts as a password
Mainstream proxy protocols use only a handful of authentication fields. Shadowsocks uses a cipher plus a password, Trojan a password with TLS, VMess and VLESS a UUID, and Hysteria2 and TUIC run over QUIC with a password or a UUID plus password. All of these fields end up written into a single node link, and whoever gets the link gets the fields.
A subscription link takes this one step further: it is a URL with a long token that returns a Base64-encoded node list, or a YAML config for Clash / Mihomo. No username or password is entered at any point, because the link itself is the pass. That is why, once it leaks, changing your password does not stop anyone from connecting.
A subscription link is a credential. Pasting it into a group chat, letting it appear in a screenshot, or handing it to a third-party conversion site has the same effect as giving away your password. The difference: a password can be changed, while a link stays valid until you actively reset it.
| Credential type | What someone can do with it | How to invalidate it |
|---|---|---|
| Account password | Sign in to the user panel, view orders and usage, re-pull the subscription | Change the panel password |
| Subscription link | Pull every node with any client; usage is billed to the same plan | Reset the subscription in the panel |
| Single node link | Uses one node only, but still consumes plan data | Voided along with the subscription reset |
| Client config file | Contains every node and routing rule; importable on any device | Reset the subscription and re-import |
This service allows unlimited simultaneous devices. That design is good for convenience but means something else for security: when a subscription link is used by someone else, no device-limit warning appears, so nothing surfaces on its own. Anomalies can only be caught through usage records and proactive rotation. Monthly subscriptions start at ¥9.9 with 60GB, data packs at ¥158 / 300GB, so a leaked link translates directly into lost data.
Sign-up: what not to enter
VPNZM sign-up needs only a username and a password, with no email address. One less field means one less surface: if your email is breached elsewhere, attackers will use it to try other sites, including your VPN account. With these two fields, how you fill them matters more than what you fill in.
- ✅ Use a string unrelated to your real name or usual social handles, so it cannot be traced back to a specific person.
- ✅ Let a password manager generate the password, 16 characters or more, never reused from email, cloud storage or payment accounts.
- ✅ Pay through the on-site Alipay / WeChat / USDT channels so the order stays tied to your account; never transfer to an address a stranger gives you.
- ❌ Don't put your real name, employer or home city in a nickname or note.
- ❌ Don't build a username or password from a birthday, name pinyin or a common English name.
- ❌ Don't keep the subscription link in saved chat messages, a public cloud note link, or browser bookmark sync.
Storing and rotating a subscription link
There is only one goal: the link should exist nowhere but inside the client. That takes no special tooling, because three habits are enough: don't share it, don't screenshot it, don't route it through third-party sites. When you switch devices, copy it fresh from the panel instead of digging the old one out of a chat history.
- Reset the subscription in the user panel; the old link stops working immediately.
- In the client, delete the old profile rather than disabling it, then import the new link.
- Re-import on each device one by one, and any device that fails to connect doubles as an inventory check.
- Watch the plan's usage records for a few days; an unexpected rise means the old link was used.
Rotation frequency follows risk: if the link has only ever been imported on your own devices, once every six months is enough. After group sharing, an outgoing screenshot, third-party conversion or a lost device, reset it right away.
Third-party subscription converter, online speed test and node checker pages ask you to paste your subscription link into a form. Once the link leaves your machine, you cannot confirm whether it was retained. If you need a different format, use the parser built into your local client, or run the conversion on your own machine.
Bottom line: a leaked link and a leaked password are two different problems. Changing the password fixes the second; resetting the subscription fixes the first. Do only one and the other channel stays open.
The real risks on public Wi-Fi
The risk on public Wi-Fi is not a broken cipher but the few minutes around connecting: a fake hotspot with the same name, a captive portal served over HTTP, DNS resolution that has been hijacked. None of these needs advanced tools, because they rely on you tapping Connect.
| Scenario | What happens | What to do |
|---|---|---|
| Fake hotspot (same SSID) | You join the other party's device and your traffic passes through it first | Turn off auto-connect and confirm the hotspot name manually |
| Captive portal login page | The page runs over HTTP and can be swapped for a lookalike form | Never enter credentials on a portal page; connect first, then start the client |
| DNS hijacking | A domain resolves to an impersonation site | Run the client in TUN mode so it takes over DNS resolution |
| Same-subnet sniffing | A neighbour can scan the open ports and services on your device | Keep the system firewall on and turn off file sharing |
DNS leaks deserve their own paragraph. Even when traffic already goes through the proxy, if the system still asks the local network to resolve domains, the sites you visit are exposed to the Wi-Fi provider and may be answered with forged addresses. The check is simple: after connecting, open the site's IP lookup page and see whether the exit address and region match the route you selected; then check in the client whether DNS queries leave through the same exit. If they don't, switch to TUN mode and let the client take over port 53.
HTTPS still holds. On a site whose certificate validates, other devices on the same subnet cannot read the content. What you really need to avoid is dismissing a certificate warning or typing credentials on an HTTP page. If the browser throws a certificate error, disconnect from that network first and investigate.
Order of steps after a lost device
The order matters: cut the channel first, then the entrance. The link is the channel, the account is the entrance. When a device is lost you do both; when only the link has leaked, the first step is enough.
- Reset the subscription link. The old link dies immediately, so the client on the lost device cannot connect even if the profile is still there.
- Change the panel password. Sign in from another trusted device, then review orders and usage again.
- Audit usage. Compare the plan's data records for growth in hours when you were not online.
- Re-import the new link on your remaining devices, and delete the profiles of old devices you no longer use.
- Watch for a week. If the anomalies stop, the response was complete; if connections continue, there was more than one leak point.
Bottom line: reset the subscription first, then change the password. Do it the other way round and the link stays usable for the whole gap.
Client differences and daily habits
Clients differ from platform to platform in where they store configs, and that determines the exposure on a shared machine.
- Windows: configs are usually plain-text files under the user directory, readable by other accounts on the same machine.
- macOS: clients run as a network extension, need system authorisation on first install, and keep the config locally as well.
- Android: the tunnel is built through VpnService, per-app routing is supported, and configs live in the app's private directory.
- iOS: NetworkExtension is used, configs sit inside the app sandbox, and deleting the app clears them.
- Linux: mostly command-line clients; set config file permissions to owner-read only.
Routing rules decide which traffic goes through the proxy. Get the order wrong and internal addresses or payment domains get sent out too. When troubleshooting a connection, check rule order first, then whether DNS is being taken over. Import steps for each system are covered separately in Quick start; if an import fails, first confirm the subscription format matches the client.
Three daily rules: never import the subscription on a public or borrowed device; never sync the config directory to cloud storage; when changing devices, reset before importing instead of sharing one link between two devices long term.