VPN Security Basics: Accounts, Subscription Links & Public Wi-Fi

Three things to keep separate: your account, your subscription link, and your client

When a connection fails, drops repeatedly, or reports an expired subscription, beginners usually assume the server is down. More often, the problem lies with one of three things: the account, the subscription link, or the client. This guide skips the toggle-by-toggle settings tour and instead draws clear lines between the three — who holds login access, who holds connection access, and what order to handle things in when each one is lost.

The second row is the one people underestimate most. An account at least has a password in front of it; a subscription link is itself the credential. Anyone who has the link doesn't need your username or your permission — they can import it and connect to the same servers.

Why a subscription link counts as a credential

A subscription link usually starts with http or https and looks like an ordinary URL. Open it and you get a block of encoded text; once the client decodes it, you have the full set of connection parameters: server address, port, protocol, encryption method, and the password or UUID. In other words, everything about who you connect as and which server you reach is already written into the link.

The two lines below are format examples. The address comes from the documentation-only range 203.0.113.0/24, the password is a demo value, and neither points to a working server.

ss://[email protected]:8388#Example-Node
trojan://[email protected]:443?sni=example.com#Example-Node

Different protocols carry credentials in different forms, but they share one thing: the link must contain fields that can establish a connection directly, or the client can't finish importing it. That also explains why resetting a subscription link takes effect at once — the server swaps out the credentials, and the parameters in the old link stop working.

The table makes one point: whatever the protocol, the subscription link has to contain credentials that can establish a connection directly. If the link is copied, the ability to connect is copied with it — no matter how modern the protocol is.

Why resetting the subscription works immediately

The subscription link is issued by the server, and a reset replaces those credentials on the server side. When the old link tries to pull a configuration again, the server no longer recognizes it, which makes a reset the fastest way to cut off connection access. Changing your password, by contrast, only affects sign-in to the user panel and cannot invalidate a subscription link that has already leaked. The two cover different ground and are not interchangeable.

Where the real public Wi-Fi risks are

The risk on public Wi-Fi isn't the vague idea of "your signal being intercepted" — it comes down to a few concrete points you can check one by one. They're listed below by how they happen, with a note on how far an encrypted tunnel covers each one.

Two rows in the table are beyond what a tunnel can fix. A captive portal requires you to sign in on a web page before the tunnel is allowed to come up, and whatever you submit there goes straight to the hotspot operator. So on a public network, the first thing to do is turn off "auto-join known networks" in your system settings; the second is to never reuse a password from an important account on a portal page.

Routing rules decide which traffic actually enters the tunnel

Split-tunneling rules in the client (sometimes labeled routing rules) decide which requests go through the tunnel and which connect directly. Default rules usually send LAN addresses and frequently used local sites direct, which improves speed but also means that traffic isn't protected by the tunnel. If you're unsure what the rules contain, switching to global mode is the safer choice; once you're back on a trusted network, switch back to rule mode and adjust as needed.

DNS leaks are another thing to verify separately

DNS resolution turns domain names into addresses. If the tunnel only carries web traffic and DNS requests are still handled by the local network, you get a DNS leak: the local network can see which domains you visit, and the answers it returns may be rewritten. Checking is easy — after connecting, open any DNS leak test page and see whether the region of the resolver in the results matches the server you selected. If it doesn't, DNS isn't going through the tunnel; change the client's DNS handling so the tunnel resolves queries, or simply turn on the client's "prevent leaks" option.

How clients differ across platforms

Desktop clients (Windows, macOS) generally offer full rule mode and per-app settings, with the most options to tune. Android lets you choose per app whether traffic goes through the tunnel. On iOS, system limitations mean rules come from the configuration profile, so the granularity is coarser than on desktop and you need to decide earlier whether to use global or rule mode. Linux clients are mostly command-line tools with configurations you maintain by hand; it's worth putting the subscription refresh cycle in your calendar so you don't forget to re-import after credentials rotate.

What support should never ask you for

There's only one test: is what they're asking for actually necessary to diagnose the problem? Troubleshooting needs very little information, and anything beyond that shouldn't be shared.

• ✅ Fine to share: your username (not your password), order number, what the problem looks like, client and OS versions, and the full error message.
• ✅ Fine to share: screenshots — but check first that no subscription link, QR code, or server details are visible in the image.
• ❌ Never share: your account password. Checking server status never requires it.
• ❌ Never share: the full subscription link. If a configuration needs checking, describe the symptoms instead of pasting the link.
• ❌ Never share: login credentials for a payment account, or the full card number on a receipt.
• ❌ Never share: photos of identity documents. Identity checks are not part of troubleshooting a connection.

Looked at another way, this list also helps you spot an impersonator. If someone asks for anything marked ❌ above, no matter how convincing their reason sounds, stop and re-confirm who you're talking to through the official entry point you open yourself. Signing up for this service requires only a username and password — no email address and no extra details — and that alone is a useful signal.

What to do first when credentials may have leaked

If you find your subscription link has been forwarded to a group chat, your account has been signed in from an unfamiliar device, or you simply aren't sure whether anything leaked, work through the steps below in order. The order matters, and the reason for each step follows it.

1. First, reset the subscription link in the user panel. This invalidates the leaked credentials immediately and is the only step that cuts off connection access right away.
2. Then change your account password. If the same username and password are used anywhere else, change them there too. Reusing one set of credentials turns a single leak into several.
3. Review orders and sign-in activity in the panel. Confirm there are no changes you didn't make, then decide whether anything else needs attention.
4. Delete the old configuration on every device and import the new subscription. The old configuration won't disappear on its own, but the credentials it points to are already dead — keeping it around only causes repeated connection failures.
5. Clean up any files you exported or forwarded. That includes links in chat history, clipboard contents, and any notes where you saved the configuration.

Trade security promises for checkable facts

What sways beginners most when choosing a service is sweeping language that sounds reassuring but cannot be checked. Such words have no verifiable meaning — anyone can write them. A more useful approach is to look at which checkable facts a provider is willing to publish: how many countries and regions it covers, how many servers it runs, how long the refund window is, what you must submit to sign up, and how the privacy policy describes what gets logged.

These three can be compared directly: coverage determines how much choice you have, server count affects availability at peak times, and the refund window sets the cost of trying something out. The two items that bear most directly on security, though, are different ones — whether sign-up requires an email address, and how the privacy policy describes what is logged. This service requires only a username and password to sign up, with no email address, and its privacy policy states that browsing content is not logged. Statements like these are policy claims: they can be checked, and they aren't dressed up as unverifiable guarantees.

Back to the table at the start: an account, a subscription link, and a client configuration each map to a different kind of access. Remember where the lines between them fall, and you've covered most of the mistakes beginners make. Device limits and server selection are usage-level tweaks you can deal with later.