Account: what you never need to fill in at sign-up
An account system for a service like international route subscriptions only needs two things in functional terms: an identifier that tells users apart, and a credential only you know. A username plus a password covers both. An email address is there for password recovery and notifications — an operational choice, not a technical requirement for the account to work.
VPNWI asks for a username and password, and no email address. The point of that choice is data minimization: what was never stored in the account system cannot be taken in a data breach, when an admin panel is exposed, or when an upstream provider is asked for records. One less field means one less path to a leak.
The username itself is worth choosing carefully. Reusing the same handle you use on other sites hands outsiders a clue that links two accounts together. Pick an identifier you use only on this service and the cost of linking them rises considerably.
Passwords have three hard requirements.
- Unique: never reuse the same credentials on a second site. Once one site is breached, credential-stuffing scripts will try them everywhere else automatically.
- Long enough: 12 characters or more, or a passphrase made of 4 to 5 unrelated words. The cracking cost that comes from length grows more reliably than anything you get from stacking symbols.
- Hand it to a password manager: let it generate, store and autofill. Writing a password into a notes app or a saved chat message hands the account to anyone who can unlock that device.
VPNWI's standing privacy position is a no-logs policy: the service side does not keep records of what users browse. That covers the service side only; password management and subscription link storage on your own devices are still up to you.
Subscription link: why it works like a password
A subscription link is an ordinary URL that the client requests on a schedule, and the server returns a node list. The usual format is a Base64-encoded list of node URIs, one per node, with a protocol field that may be Shadowsocks, VMess, Trojan, VLESS, Hysteria2 or TUIC. The client parses that list and builds the switchable route entries you see in the interface.
The key point: the URL itself is the credential. There is no second check at import time — whoever has the link can rebuild the same node list on their own device and use it right away. It is more direct than a password: a leaked password still needs a login, while a leaked link is plug and play.
There is another cost that is easy to overlook: the node list is tied to your account quota. When someone else runs traffic through your link, it comes out of your monthly allowance or data pack, not theirs.
| Leak scenario | What they get | Immediate consequence | What to do |
|---|---|---|---|
| Pasting the link into a chat group or forum for a speed test | The full node list | Traffic comes out of your quota and the routes are shared with strangers | Delete the subscription in your client and ask the provider to reset it |
| A screenshot of the subscription page with the QR code or link visible | Anyone can scan it and import | Traffic starts being consumed as soon as it is imported | Delete the subscription, request a reset, and take the image down |
| Pasting it into a third-party subscription converter site | The link and node details, possibly retained long term | The converter site can reuse your quota at any time | Request a reset immediately and stop using that link |
If you need a different subscription format, use the import feature built into your client — never a third-party online converter. Once a link leaves your device, there is no way to call it back.
There is only one test: any step that requires you to send the subscription link somewhere is worth stopping to think about. A normal import never asks you to hand the link to another person or another website.
Subscription link storage: four rules
The goal is not to hide it deeply but to reduce the number of devices and servers it passes through. Every extra device means another backup, another sync record, another clipboard history entry.
- Import only, never forward. With several devices, import once on each one; VPNWI allows unlimited simultaneous devices, so there is no need to send the link to someone else to import for you.
- Clear the clipboard after copying. iOS and Android sync clipboards across devices signed in to the same account, and desktop clipboard history keeps content around as well.
- Keep it out of cloud-synced folders. Cloud notes, file storage, code repositories and browser bookmark sync all copy the link onto third-party servers.
- If you want a backup, put it in a password manager. Use a secure note field — not a plain text file, and not a screenshot in your photo library.
A QR code is the same link in another form: scanning it grants exactly the same access as pasting it. Posting a subscription QR code in a group chat is the same as posting the link.
If the link has already leaked, the order is fixed: first delete the subscription in your client so it stops fetching; then ask the provider to reset it, which invalidates the old link; finally, confirm that no other device is still using the same link.
Public Wi-Fi: where the risk actually sits
The risk on public Wi-Fi is not whether the password can be cracked, but what someone on the same network segment can see. HTTPS on modern sites encrypts the body of the traffic, but the three kinds of information below can still be exposed in the clear on the local network.
- DNS queries: if the device still uses the resolver handed out by the network, the local gateway can see which domains you visited.
- The server name in the TLS handshake: sent in the clear unless Encrypted Client Hello is enabled.
- A small number of requests still made over http: captive portal redirects and update checks in some apps.
The more realistic risk is a fake hotspot. An attacker sets up an SSID with the same name as the venue, your device connects automatically, and all traffic leaves through their gateway. This kind of attack does not require breaking any encryption — only that you connect.
| Action | Verdict | Why |
|---|---|---|
| Visiting HTTPS sites | Fine | Page content is encrypted by TLS, so the local network cannot see it |
| Bringing up the route before signing in to email or a work dashboard | Recommended | Keeps DNS, TLS server names and other metadata off the local gateway |
| Clicking through a certificate warning | Don't | A certificate error is one of the few visible signs of a man-in-the-middle attack |
| Entering an email or social account on a portal login page | Don't | A portal page only needs you to accept the terms, not account credentials |
| Installing a certificate or profile from an unknown source | Don't | Once installed, the other side can decrypt this device's traffic |
| Turning off the system firewall to fix a connection problem | Don't | The firewall is the last line of defense on the device |
| Using a personal hotspot instead of public Wi-Fi | Fine | The cellular air interface is encrypted and does not pass through anyone else's gateway |
One more note on order: portal authentication usually requires the network to be reachable, and a client in global mode can get stuck on the login page. Connect to the Wi-Fi in rule mode, finish the portal login, then switch routes; anything that requires signing in can also wait until you are on a personal hotspot.
Public Wi-Fi is not unusable — it just means moving anything account-related later in the sequence: connect to the network first, bring up the route second, sign in last. Get the order right and all the local network can see is encrypted traffic.
Client and split tunneling: keeping risk on the device side
Once a subscription is imported, what actually decides which traffic goes through the route and which goes direct is how the client takes over traffic and what its routing rules say.
How clients differ by platform
- Windows and macOS: clients usually offer two ways to take over traffic — system proxy and TUN. A system proxy only covers apps that honor the system proxy settings; TUN mode creates a virtual network adapter and takes over all traffic including UDP, for broader coverage.
- iOS: the client runs as a system network extension and takes over traffic through a VPN configuration; system background policy may reclaim a long-running connection and force it to reconnect.
- Android: traffic is taken over through the system VpnService, and on some devices the client has to be added to the battery optimization allowlist or background networking will be restricted.
- Linux: mostly command-line clients, with a manually configured system proxy or TUN.
Routing rules and DNS leaks
In rule mode, the client decides whether traffic goes through the route or direct based on domain and IP rules. Keeping local services (banking, government, LAN devices) on the direct side cuts cross-border round trips and avoids triggering risk controls when a local service sees your exit address change. Global mode is useful for troubleshooting, not for leaving on all the time.
DNS leaks are another easy thing to miss: even when traffic goes through the route, if domain resolution still goes to a resolver on the local network, the lookup records are still visible to the local gateway. The remote DNS or proxy DNS option in desktop clients sends queries to a resolver on the route side; in TUN mode, check that the DNS settings have not been overridden by the system or another app.
Three checks after you connect
- Open the IP check page and confirm the exit IP matches the region you selected. If it does not, your routing rules or takeover mode are not taking effect.
- Run a DNS leak test and confirm the resolver is not your local network operator.
- Open a service that is only available in a specific region and confirm that domain is matching the route rules.
Once all three pass, sign in to sites that need an account. Doing it in the opposite order leaves your sign-in on the least trustworthy stretch of network.
The protocol you choose (Shadowsocks, VMess, Trojan, VLESS, Hysteria2, TUIC) affects handshake fingerprints, latency and resistance to interference — it does not change the boundaries of account security. How you store the link is the weakest link in that chain. Platform-specific import steps are in the setup guide, and if you cannot connect, start with the help center.
A checklist you can follow
The sections above, compressed into one list — run through it at sign-up, at import and when you head out.
- ✅ Sign up with a username and password only, no email address
- ✅ Use a different password on every site, generated and stored by a password manager
- ✅ Import the subscription link only in your client — never into a chat window, cloud note or third-party converter
- ✅ On public Wi-Fi, bring up the route before signing in to email, work dashboards or any site that needs an account
- ✅ Stop at a certificate warning and type nothing further on the warning page
- ❌ Sending a subscription link or a QR code screenshot to someone else for a speed test
- ❌ Entering an email or social account on a portal login page
- ❌ Installing a certificate or profile from an unknown source just to get on the Wi-Fi
- ❌ Leaving global mode on long term, so local services and LAN devices are routed too
The service's stated facts are 120+ countries and regions, 170+ routes, unlimited simultaneous devices, and a no-questions-asked refund within 14 days of first payment. Those numbers are why there is something in your account worth protecting to password standards.
Account security, subscription links and public Wi-Fi have something in common: none of them needs complicated tools, only the right order and a few habits. Import the link, never send it out; bring up the route before anything that needs an account; fill in only the fields you must at sign-up — do those three and you have avoided most of the risk a beginner faces.