This VPN safety guide for beginners starts with an often-overlooked distinction: account passwords, subscription links, and client configurations are different types of information, but all should be handled as credentials. A subscription link often contains a token that identifies the subscription. Anyone with the complete link may be able to import it into a client, read the route configuration, and use the associated traffic allowance without knowing the account password.

A VPN places traffic between your device and the access node inside an encrypted tunnel, reducing the risk of direct observation or tampering by others on the same local network. But the tunnel does not replace HTTPS on websites, detect fake login pages, block malicious attachments, or validate questionable permissions. Safe use is not complete when the client says “connected”; it requires a continuous process covering credential storage, client sources, connection checks, and leak response.

The difference between account passwords and subscription credentials

An account password lets you access the service panel. Typical tasks include reviewing plans, updating a subscription, obtaining a client, or submitting a support request. A subscription link is intended for proxy clients and provides node names, server addresses, ports, protocol parameters, and authentication details. After import, the client usually stores this information locally and revisits the original link when refreshing the subscription.

Changing the account password does not necessarily invalidate a leaked subscription link immediately. The two credential types may use different authentication mechanisms. If you notice unusual traffic, unfamiliar configurations, or a link posted publicly, reset the subscription credential in the service panel, delete the old configuration, and import it again. Changing only the login password is not enough.

Information type Primary use Risk if exposed Recommended action
Account username and password Access the service panel and manage subscriptions and support requests Account settings may be viewed or changed Set a unique password and check the subscription status in the panel
Complete subscription link Let the client read and update route configuration Someone else may import the nodes and use the subscription traffic allowance Reset the subscription link and remove the old configuration from the client
Single node configuration Connect to a specific node Authentication parameters for the route may be reused Stop sharing the configuration and update the related subscription credential
Client runtime logs Troubleshoot connection, resolution, and routing issues May contain server addresses, subscription requests, or local paths Review the content before submitting and keep only the fragments needed for troubleshooting

PzVPN lets you create an account without an email address, using only a username and password. Even when registration requires little information, keep the password unique to this service. Reusing passwords links risks across services: exposure at one service may affect other accounts that use the same combination.

  • ✅ Set a unique password for the VPN service and do not reuse it on common websites.
  • ✅ Store the subscription link in a protected password manager, not an ordinary notes app.
  • ✅ Before sharing troubleshooting screenshots, hide the address bar, subscription token, and complete node configuration.
  • ❌ Do not send subscription links to public groups, forum posts, or shared documents.
  • ❌ Do not publish client logs containing authentication parameters without redaction.
Bottom line: The account password controls access to the service panel, while the subscription link controls whether a client can retrieve configuration. Handle any exposed item separately; changing one does not automatically revoke the other.

How to store and import a subscription link

A subscription link may look like an ordinary web address, but its purpose is entirely different. Its path or query parameters may contain a token used to identify the subscription. The fact that a browser can open it does not make it suitable for a public bookmark, chat history, or online conversion service. Any program or person that can read the complete link may access its authentication information.

The safer approach is to copy the link from the service panel, switch directly to a trusted client, import it, and then clear the system clipboard. If cross-device clipboard sync is enabled, remember that the link may be copied to other signed-in devices. Pasting it temporarily into a web search box, translation tool, or online note-taking service is also inappropriate: these fields are not credential storage.

What to check when importing into a client

  1. Start by verifying the client’s source. Prefer the download link provided on the service page, a trusted operating-system distribution channel, or the project’s public release page. Avoid installation files from repackaged download sites.
  2. Open the client’s subscription management feature rather than visiting the link as an ordinary webpage. Different clients may call this section subscriptions, remote configurations, configuration files, or configuration providers.
  3. After importing, check that the subscription name and node list match what you expect. Do not judge authenticity by node names alone; also confirm that the subscription still points to the original service domain.
  4. Enable automatic updates only when needed. On shared devices, consider disabling background previews and notification details so subscription names or connection information do not appear on the lock screen.
  5. After replacing a subscription link, delete the old subscription and its cached nodes before importing the new link. Adding another configuration without removing the old one leaves the previous credential in the client.

Shadowsocks, VMess, Trojan, VLESS, Hysteria2, and TUIC are different protocols or configuration types that clients may recognize. They differ in authentication, transport encapsulation, congestion control, and client support. Names alone cannot show which option is safer or faster on every network. Check whether the client correctly supports the protocol, whether transport encryption is enabled as configured, and whether the subscription parameters come from a trusted source.

The client’s “export configuration” feature also requires care. Exported text, QR codes, or backup files may contain complete authentication parameters. A QR code is not a redacted format; it is simply an encoding that machines can read more easily. When sharing a screen, recording a tutorial, or submitting a screenshot, treat QR codes and complete links as equally sensitive.

Rule of thumb: Any information that lets another device establish a connection directly must not be treated like an ordinary link, image, or configuration file.

The real risks of Public Wi-Fi

The main risks of public Wi-Fi are that the access point’s identity can be difficult to verify, other devices on the local network may not be trustworthy, and the connection process may pass through a captive portal. Similar network names may belong to different devices, while automatic connection can join a previously saved network with the same name. At airports, hotels, conference venues, or cafés, do not judge an access point by its name alone.

After joining a public network, the system often visits a connectivity-check address and opens a captive portal. The VPN tunnel may not yet be established, so portal interaction takes place over the ordinary network path. Complete the required network access first, then start the VPN and confirm that the client reports a successful connection. If the portal requests sensitive information unrelated to internet access, stop and verify the request with the venue.

  • ✅ Confirm the network name with the venue before connecting, and disable automatic joining when it is not needed.
  • ✅ Complete captive-portal access before starting the VPN, then wait for the connection status to stabilize.
  • ✅ Stop browsing when the browser shows a certificate warning; do not ignore it and continue signing in.
  • ✅ After leaving the venue, make the device forget the network to prevent automatic reconnection to a similarly named access point.
  • ❌ Do not open unknown attachments or approve unusual permissions just because the VPN is connected.
  • ❌ Do not treat an HTTP page as suitable for entering account credentials.

A VPN tunnel can reduce the chance that someone on the local network directly reads your traffic, but websites can still see information your browser actively submits, and signed-in services can still identify account activity. HTTPS encrypts the connection between your browser and the website and verifies the site’s identity. VPN and HTTPS protect different paths; neither replaces the other.

A sensible order on public networks is: verify the access point, complete any required portal steps, establish the VPN connection, check DNS and routing status, and only then begin tasks that require signing in.

If the VPN disconnects during a network change, the client may restore the system’s default route. Clients with connection protection or network-lock features can restrict traffic from going out directly when the tunnel fails, but implementation and scope vary by platform. After enabling such a feature, test what happens when the connection drops, the network changes, and the device sleeps. Do not rely on the feature name alone.

How to check DNS leaks and split-tunneling rules

DNS converts domain names into network addresses. When a VPN is connected, if DNS queries are still handled by a resolver provided by the local network, that network may learn which domains the device has queried. This is commonly called a DNS leak. It does not mean the page contents are directly exposed, but it can reveal some access metadata and may cause DNS results to point to a different region from the proxy exit.

Common causes include the system retaining DNS settings from the original network, the client proxying only application traffic, the browser enabling its own encrypted DNS, or split-tunneling rules sending DNS queries outside the tunnel. Avoid changing several system, browser, and client settings at once; otherwise it becomes difficult to tell which layer caused the change.

Run connection checks in order

  1. Before connecting, record the current network’s exit and DNS resolution status for comparison during this session only. Do not publish complete network identifiers.
  2. Establish the VPN connection and wait for the client to finish applying routing and DNS settings. Do not start testing while the status is still changing.
  3. Check whether the exit now matches the region of the selected route, then check whether the DNS resolver still clearly comes from the local access network.
  4. If the results do not match, first review the client’s DNS and split-tunneling modes, then check whether the browser is overriding resolution settings independently.
  5. After making corrections, disconnect and reconnect, then repeat the same process so cached results are not mistaken for an effective configuration.

Split-tunneling rules determine which traffic enters the tunnel and which remains direct. Global mode usually sends more traffic through the proxy route, while rule mode classifies traffic by domain, address, or application. Rule mode can keep local services on a direct connection, but outdated or incorrect rules may send traffic that should be proxied directly, or send DNS queries and webpage connections along different paths.

Check Expected behavior Warning signs Check first
Exit routing Matches the currently selected route Still shows the local access network’s exit System proxy, tunnel permissions, and client connection mode
DNS resolution Resolution path matches the client settings Still uses the local network resolver after connection Client DNS, browser-specific resolution, and system cache
Split-tunneling rules The target application is routed directly or through the proxy as expected Requests from the same service take inconsistent paths Rule priority, domain matching, and application bypass lists
Network changes The tunnel is re-established after switching networks The client shows connected, but traffic has returned to a direct route Automatic reconnect, connection protection, and system sleep behavior

Windows, macOS, Linux, Android, and iOS impose different limits on system proxies, virtual network adapters, background operation, and DNS interception. Desktop clients may offer system-proxy and tunnel modes, while mobile platforms rely more heavily on the VPN interfaces provided by the operating system. The same configuration name on different platforms does not guarantee the same routing scope. When troubleshooting, record the operating system, client name, connection mode, and protocol type instead of simply saying “the VPN won’t connect.”

What to do after credential exposure

If a subscription link appears in a public place, a QR code shows up in a screenshot, client traffic looks unusual, or a configuration was imported into an untrusted tool, treat the credential as exposed. Do not wait to confirm whether someone used it; as long as the old link remains valid, the risk remains.

  1. Open the service panel and reset the subscription link so the old credential can no longer retrieve configuration.
  2. Delete the old subscription, cached nodes, and exported configuration files from all devices you own.
  3. Import the new link, verify its source and node list, and then test the connection.
  4. If the account password also appeared in the same screenshot, file, or shared record, change the account password as well.
  5. Delete the original credential from public posts and shared files. Deletion cannot undo copies that have already been made, so the reset is still necessary.
  6. Review troubleshooting logs and backups to confirm that the old link or complete authentication parameters are not still being stored.

If only one node fails to connect, do not immediately assume that credentials have leaked. Route maintenance, local network restrictions, client-version differences, an incorrect system clock, and incomplete protocol support can all cause connection errors. Credential exposure is more commonly associated with public sharing, unusual traffic, configurations on unknown devices, or an untrusted import process; assess it using the available evidence.

When submitting a support request, describe the stage where the error occurs: the subscription cannot refresh, the node handshake fails, domains cannot be resolved after connection, or only a specific application is unreachable. Attach checked error excerpts only; do not proactively submit the complete subscription link. If support truly needs to identify the subscription, use the account information in the service panel rather than pasting credentials into a public discussion.

Key point: Deleting public content only removes the visible trace; resetting the subscription credential is what revokes the old link at the authorization level. Then clear client caches and backups so the old configuration cannot be used accidentally.

Everyday security habits matter more than emergency fixes

Using a VPN safely does not require constantly adjusting complex parameters. Consistent, verifiable habits matter more: obtain the client only from trusted sources; keep the account password unique; move the subscription link only between the service panel, a password manager, and the client that needs it; verify public-network access points before establishing the tunnel; and test after changing DNS or split-tunneling rules.

A service’s anonymous, no-logs policy describes its position on handling usage records on the server side, but browser history, downloaded files, system logs, and client configurations on your local device remain your responsibility. Shared computers, remote assistance, and screen recordings require particular care: check whether notifications, the clipboard, QR codes, or configuration windows expose sensitive information.

  • ✅ Periodically check whether the client retains duplicate, expired, or unfamiliar subscriptions.
  • ✅ Verify the release source before updating the client, then recheck connection and split-tunneling status afterward.
  • ✅ When changing devices, first remove subscriptions and exported files from the old device.
  • ✅ Before sharing logs, search for the subscription domain, authentication parameters, and local file paths.
  • ❌ Do not treat “connected” as proof that a website or file is trustworthy or that an authorization request is appropriate.
  • ❌ Do not keep a complete subscription in a publicly synced document just for convenience.

For beginners, the most useful test is simple: first ask who can see the information, then ask what they can do with it. If a piece of text, a QR code, or a file lets another device establish a connection, it is a credential. If a setting changes where traffic goes, verify the result after changing it. If you cannot confirm who operates a network, treat it as an untrusted access environment.

Managing accounts, subscription links, clients, and public Wi-Fi within these boundaries covers most common mistakes. A VPN is one security tool in the network path, not a master switch that replaces password management, HTTPS verification, system updates, or careful authorization. Separating these responsibilities makes problems easier to locate and responses more effective.