This VPN security guide starts with your credentials, then moves on to your connection. Protecting subscription links and staying safe on public Wi-Fi means keeping access out of the wrong hands and confirming that the traffic you want to protect follows the expected route. A connected status in your client confirms only that a connection is active; it does not mean every app, DNS request, or account action is protected in the same way.
Treat subscription links like access credentials
A subscription link lets your client retrieve connection profiles. It usually contains credentials that identify your subscription, so anyone with the complete URL may be able to retrieve the associated configuration without accessing your account dashboard. The exact permissions depend on how the service works, but protect the link much like a password. It is not an ordinary help-page URL.
A QR code may contain the same information. Sharing a subscription QR code in a public group or posting a screenshot of the import page on a forum can expose it to more people. Configuration files may also include server addresses, authentication details, and rule sources, so avoid sending the entire file to someone you do not know for troubleshooting.
- ✅ Import subscriptions only into clients you trust, and check where the link came from.
- ✅ Store sensitive information in a reputable password manager, not shared notes or public documents.
- ❌ Don’t paste the full subscription URL into a search box, public chat, or unfamiliar online conversion tool.
- ❌ Don’t share screenshots that reveal QR codes, authentication fields, or complete request URLs.
Take extra care with subscription converters. An online conversion service that receives your full link may be able to access its contents. The converted result may also change your rules or proxy groups. Prefer subscription formats supported natively by your client. If conversion is necessary, check the tool’s source, where your data goes, and what changes in the configuration. Don’t submit a link just because a page claims it is “secure.”
Keep account passwords and subscription access separate
Your dashboard password grants access to your account, while your subscription credentials retrieve configurations; changing one does not necessarily affect the other. Don’t assume that changing your login password invalidates an existing subscription. Check the dashboard or ask support whether you can reset a subscription and when an old configuration expires.
VPNSelf doesn’t require an email address; you can get started with a username and password. Your username doesn’t need to include your real name, employer, or other identifying details. Use a unique password, not one reused for forums, shopping, or work accounts. Sharing less personal information and using a unique password address different risks.
Go to the sign-in page from a site you’ve already verified. Don’t use a captive portal, search ad, or link from a chat message as your dashboard login page. Check the domain in your browser’s address bar and confirm HTTPS is active. If your browser shows a certificate warning, stop before entering your credentials; don’t try to get past it by clicking through repeatedly.
Avoid saving your dashboard password on shared devices. When you’re done, sign out and check whether sensitive information remains in the downloads folder, clipboard history, or client configuration. Deleting a file can’t undo information that has already been synced or copied elsewhere.
Public Wi-Fi: Verify the network, then check your connection
The risk of public Wi-Fi isn’t limited to someone “watching your traffic.” Different devices can provide hotspots with the same name, sign-in pages can be spoofed, and the network may interfere with DNS or redirect you to the wrong site. Confirm the network name and sign-in method with the venue before connecting. Don’t trust a network just because its signal is strong or its name looks familiar.
HTTPS protects data in transit between your browser and the destination website, but it doesn’t prove the site itself is trustworthy or stop you from entering a password on a fake page. A VPN or encrypted proxy can protect traffic between your device and the service within the connections it actually covers, but it cannot replace website certificate checks or device security.
- Before connecting: Turn off automatic network joining if you don’t need it, and check that your sharing and nearby-device discovery settings suit the situation.
- While signing in: Complete only the steps needed to access the network. If the page asks you to install an unknown certificate, configuration profile, or unverified app, stop and verify the request first.
- Once online: Open a trusted client and check that your selected route, proxy mode, and system permissions are working. Don’t rely on the connection icon alone.
- Before taking action: Open the destination website and check its domain and certificate status. For sensitive tasks, use a network you control whenever possible.
- When you leave: Forget the network if appropriate, so your device won’t automatically connect to another hotspot with the same name.
Split tunneling and DNS: Check what’s protected
“Connected, but one app isn’t using the proxy” is not unusual. System proxy settings mainly affect apps that follow them; virtual network adapter modes generally cover more traffic, but routing, exclusions, and client implementation still matter. A browser extension usually affects only the browser, so it can’t tell you how the rest of your device is connected.
Check system proxy settings, virtual network adapter permissions, and background services separately on Windows, macOS, and Linux. On iOS and Android, review the system’s connection configuration and check whether the client excludes specific apps. Support for protocols, rules, and DNS varies between clients, so don’t assume a guide for another platform applies step by step.
A DNS leak occurs when domain lookups don’t follow the expected protected route and are exposed to an unintended resolver. Interpret the results in light of your configuration: a local resolver may be part of your split-tunneling setup, or it may indicate that a setting isn’t working. Browser encrypted DNS, system DNS, and client DNS may each take a different route, so a change in your apparent IP address alone doesn’t prove anything.
| Symptom | Possible cause | What to check |
|---|---|---|
| Browser’s apparent IP changes, but other apps don’t | The app doesn’t follow the system proxy, or a rule excludes it | Proxy mode, app exclusions, and actual connection logs |
| Traffic exits as expected, but DNS takes a different route | The system or browser uses separate DNS settings | Client DNS, browser encrypted DNS, and direct-connection rules |
| Websites remain accessible after disconnecting from the route | A direct-connection rule is active, or direct connections aren’t blocked after disconnection | Matching rules, fallback behavior, and client blocking settings |
| A certificate warning appears on a webpage | Possible certificate issue, incorrect system time, or network interference | Stop before submitting information; check the time, domain, and network first |
Run tests on the same device and app before and after connecting, and review the client’s connection logs as well. Don’t disable all certificate checks to troubleshoot DNS, and don’t send complete diagnostic logs to public testing sites.
Encryption and routes: Separate transport, exit, and device security
A protocol name alone doesn’t determine whether a connection is secure. Shadowsocks, VMess, Trojan, VLESS, Hysteria2, and TUIC use different authentication and transport designs. Check the specific protocol and configuration to see whether encryption is provided and how TLS is used. For example, VLESS does not encrypt content on its own; assess it alongside the transport security you choose. Being able to import a configuration doesn’t mean every security setting is correct.
IEPL links, relays, and direct connections describe how a route is arranged. A dedicated link doesn’t automatically provide end-to-end encryption for app data. A relay doesn’t mean all device traffic goes through it, and a direct connection alone doesn’t determine whether traffic is secure. Check transport protection, the actual route, and HTTPS on the destination website separately.
VPNSelf’s security marketing highlights military-grade encryption. In practice, you should still check the client’s source, configuration, and certificate verification. Beyond the service’s exit point, data not protected by application-layer encryption may remain exposed in transit. Browser extensions, malware, and personal information you submit are not automatically protected just because you use a network route.
Bottom line: Security isn’t a matter of choosing one protocol or type of dedicated line. Protect your credentials first, confirm which traffic is covered, and then verify the destination website’s identity. These checks don’t replace one another.
If a link leaks: Revoke access, then clean up copies
If you find a subscription link on a public page, assume it may have been copied. Deleting the post can slow further sharing, but it won’t invalidate copies already made. If you can still access your account, sign in through a trusted route and check whether the dashboard offers subscription reset or session management. If you’re unsure, contact support through a dashboard ticket.
- Limit further sharing: Remove the public post, delete sensitive fields from shared documents and screenshots, and ask recipients not to forward them.
- Address access: Reset the subscription through the dashboard if possible, or ask support to invalidate the old credentials. If your login password may also be exposed, change it to a unique one.
- Update your devices: Refresh the subscription in your own client, remove the old configuration, and check for unexpected changes to rules or route selection.
- Check how it leaked: Look for screenshots, online converters, clipboard syncing, or shared devices as possible causes. Changing the link alone won’t fix the original exposure path.
When submitting a support ticket, include when it happened, your platform and client name, the steps you took, and the exact error text. Redact subscription links, authentication fields, and sensitive account details from screenshots. Don’t include your full password, payment credentials, or entire configuration in your first request. If more information is needed, confirm what’s necessary before sending it. Contact VPNSelf through the dashboard support ticket system.
Make everyday checks a habit: use a trusted sign-in page, keep credentials private, verify your connection route, and stop when something looks wrong. If you need to reinstall the client, get it from the dashboard. The client and subscription are available after signing in; iOS eligibility is determined by the active plan shown in the dashboard. For more help, see the beginner’s guide instead of troubleshooting with an unfamiliar installer.