Here’s the bottom line in this VPN security guide for beginners: use a unique password, treat your subscription link like a credential, and check website addresses and certificates on public Wi-Fi. A successful connection only means a network path has been established—it doesn’t mean your device, website, or payment page is trustworthy. Understand what the connection does and doesn’t protect, then check your settings. That’s more useful than relying on the client’s connection icon alone.
Where encrypted connections protect you
Common proxy clients only handle traffic covered by their rules; they don’t automatically protect every connection on your device. HTTP or SOCKS system proxies generally work only with apps configured to use them. TUN mode routes traffic through a virtual network interface, but its actual coverage still depends on routing, excluded apps, and DNS settings. A mode name alone tells you nothing about your privacy.
Encryption in a VPN connection mainly protects traffic between your device and the service’s server. When you visit an HTTPS site, TLS also protects the connection between your browser and the website. With a plain HTTP page, however, traffic may be exposed to networks beyond the proxy server. Even with HTTPS throughout, a malicious site can collect any password you enter, and encryption can’t verify that a payment recipient is legitimate.
Shadowsocks, VMess, Trojan, VLESS, Hysteria2, and TUIC differ in authentication, encryption, and transport. VLESS does not encrypt content by itself; its security depends on the specific transport and security settings. Don’t assume a connection is secure based on the protocol name alone. IEPL, relay, and direct connections describe how a route is set up—not website identity verification or a privacy audit.
Rule of thumb: Check separately where your traffic goes, whether it’s protected in transit, and whether the destination website is trustworthy. A connected status in the client can’t answer the latter two questions.
How to Protect Your Password and Subscription Link
Your dashboard password manages your account; your subscription link retrieves connection settings. The link often contains an account-identifying token. Whoever has it may be able to fetch your configuration without your dashboard password and use any connection credentials that are still valid. A subscription link isn’t an ordinary URL to share publicly, and its QR code deserves the same level of protection.
| Information | Primary purpose | How to protect it |
|---|---|---|
| Dashboard username and password | Sign in and manage your plan and settings | Use a unique password; never reuse one from another site |
| Subscription link and QR code | Retrieve or update connection settings in the client | Keep them out of public screenshots, group chats, and online conversion tools |
| Configuration file and individual server entry | Provide connection details to the client | May contain authentication credentials; check before backing up or sharing |
| Logs and troubleshooting screenshots | Diagnose import, connection, and routing issues | Hide tokens, authentication fields, account details, and sensitive order information |
A password manager can store unique, strong passwords and protected notes with essential account details. VPNWhen doesn’t require an email address: you can sign up with a username and password. Keep your login credentials safe, and don’t assume you can recover your account by email. Check the dashboard and support process for available recovery options.
After copying a subscription link, consider clipboard history and cross-device sync. When troubleshooting, don’t paste the full link into a public forum. Before sharing a screenshot of the client, check the address bar, QR codes, server settings, and logs. Hiding only your username may not conceal authentication details in the configuration.
Client import and update checklist
Get the client from the download page in the VPNWhen dashboard—not from search ads or unfamiliar attachments. The client is available after login, except on iOS; check the dashboard for iOS access requirements. You must log in to retrieve your subscription. Don’t replace your configuration with a public subscription from an unknown source.
- ✅ Check that the client supports the protocol and subscription format. If import fails, check the format and version first; don’t submit the link to an unfamiliar site to “fix” it.
- ✅ Confirm whether you imported a subscription URL or a local configuration file. Subscriptions can be updated from their source; local files may not reflect server-side changes.
- ✅ After an update, check server groups, routing rules, and DNS settings. Seeing servers in the client doesn’t mean the old rules were replaced.
- ❌ Don’t turn on “Skip certificate verification” just to clear an error. Don’t install unknown root certificates or device-management profiles based on unfamiliar instructions.
On Windows and macOS, check for conflicts between system proxy settings, virtual interfaces, and other network tools. On iOS and Android, confirm that the active network extension or VPN configuration belongs to the client you intended to use. On Linux, check that desktop proxy settings and command-line environment variables are consistent. Browser access doesn’t mean your terminal, games, or background sync apps use the same route.
There’s no fixed subscription update interval that applies to every service. Update when routes change, an import issue occurs, or the dashboard prompts you to. Repeatedly clicking update won’t fix a local certificate error or incorrect routing rules. Before reinstalling, save a redacted copy of the error so you don’t lose useful troubleshooting details.
Public Wi-Fi: What to Check Before and After Connecting
Public Wi-Fi risks go beyond eavesdropping. A lookalike network name can trick your device into joining the wrong hotspot, and a captive portal may be spoofed. Before connecting, confirm the network name with the venue’s staff. Stop your device from automatically joining similarly named hotspots, and turn off auto-join or remove the saved network when you’re done.
A captive portal may appear before the client connects. Stop and verify if it asks you to install a certificate or security plugin, or to enter a password for an unrelated account. If you need to authenticate to get online, avoid sensitive tasks until the network is available. Then connect the client and verify your route.
Don’t ignore browser warnings about expired certificates, domain mismatches, or blocked connections just to continue. HTTPS protects data in transit, but a fake domain can still have a valid certificate, so check the address too. Keep your device and browser up to date, and turn off unnecessary file sharing and network discovery on public networks. Use a trusted network for payments and important account activity whenever possible.
If the client disconnects, whether subsequent traffic goes direct depends on the client and system settings. If you need to prevent direct connections, first confirm that a kill switch or system lock feature is available and enabled, then test what happens when the connection drops. Don’t rely on the feature name alone.
How to Check for DNS Leaks and Review Routing Rules
DNS translates domain names into network addresses. If domain lookups that should go through the proxy are still sent to your local network’s resolver, that network may see the queries—a common form of DNS leak. A resolver seeing the domains you look up doesn’t mean it can decrypt the contents of HTTPS pages; these are separate things.
Start by defining what you expect: which apps and domains should use the proxy, and which can connect directly. Then review the client’s DNS mode, domain lookup logs, and rule-match records, and use a trusted DNS test page as an additional check. A test page showing a particular resolver reflects only that test’s route; it isn’t a full audit of every app. Browser-encrypted DNS may also differ from your system settings.
Check routing rules for domains, processes, and fallback behavior. Rule order can determine the final route, and overly broad direct-connection rules may let an app bypass the proxy. Also check whether IPv6 routing works as expected: verifying only the IPv4 route doesn’t prove other paths are covered. Don’t disable system features without understanding the impact. Follow the client’s documentation, then test again.
You can start by testing your browser with a page that contains no sensitive information, then test the specific apps you plan to use. The expected exit region only confirms that one request used the intended exit; it doesn’t prove there’s no DNS leak. If logs conflict with test results, note the test conditions and submit redacted details through a dashboard support ticket.
What Not to Share When Signing Up or Paying
Open the dashboard through the site’s own link, then check the domain and connection status in your browser. Never enter your account password on a fake support page or hand your subscription link to a stranger offering to “set things up” or “add credit.” Before paying, make sure the plan name, amount, and payment process match the dashboard. Pause if you’re asked for information unrelated to your order.
VPNWhen supports Alipay, WeChat Pay, and USDT. Follow the payment steps shown in your dashboard order. Payment records and network activity records are different kinds of information; don’t take any payment method as a promise of anonymity. Keep only the order records you need, and when submitting a support ticket, share only what’s needed to resolve the issue. Never send a payment account password, private key, or seed phrase.
Check the refund policy before paying. VPNWhen’s terms allow “a full refund for any reason within 14 days of your first payment.” Submit requests through the support option in the dashboard. A refund policy doesn’t remove the need to verify your account and payment details.
What to Do if You Suspect a Credential Leak
First identify what was exposed: a password, subscription link, or full configuration. Don’t stop after deleting a public post. Deletion may reduce further exposure, but it can’t retrieve copies others have saved. Revoke access first, then organize evidence, check your devices, and restore your configuration.
- Password exposed: Change it on a trusted device and network. Check whether the dashboard lets you manage sessions, and sign out of any you don’t recognize. If you reused that password on other sites, change it there too.
- Subscription link exposed: Look in the dashboard for an option to reset or revoke it. If there’s no clear option, submit a support ticket to ask how to invalidate the old link and its associated connection credentials.
- Configuration or server credentials exposed: Confirm whether the server-side credentials have been rotated. Changing the subscription URL alone may not revoke server configurations that someone has already downloaded.
- Restore access: Import a valid subscription again, remove old configurations, and recheck routing rules and DNS. Watch for unusual usage and share redacted timestamps and error details with support.
Whether changing your dashboard password also revokes your subscription depends on how the service is implemented; don’t assume it does. If you suspect malware on your device, address that and check your browser extensions first. Otherwise, a new password or link could be exposed again. Good habits include sharing credentials sparingly, getting configurations only from trusted sources, and checking the actual route after changing networks or rules.