A VPN can improve privacy, but connecting to one does not automatically make every activity private or secure. A VPN encrypts traffic between your device and the VPN server and replaces the public IP address seen by many websites. It does not remove tracking cookies, prevent phishing, repair an infected device, or make an untrusted provider trustworthy. The practical question is therefore not simply “Is a VPN safe?” but “Which traffic does it protect, what information can the provider see, and have the device and client been configured correctly?”
This guide explains how to evaluate a VPN privacy claim, what encryption protocols such as WireGuard actually do, and how to check for DNS, WebRTC, IPv4, and IPv6 leaks. It also covers kill switches, split tunneling, public Wi-Fi, payments, account logins, and the differences between official clients and compatible clients such as Clash Verge, sing-box, or Shadowrocket. The goal is a repeatable safety check rather than a promise that one tool can solve every online privacy problem.
90+
Countries covered
200+
Available routes
Unlimited
Online devices
5
Supported platforms
What a VPN protects—and what it does not
A VPN creates an encrypted connection from the client on your device to a selected server. On a public wireless network, this can reduce the risk of someone nearby casually inspecting unencrypted traffic or identifying every destination requested by your device. Your internet service provider may also see less detail about the final websites you visit, because the connection is carried inside the VPN tunnel. The destination website, however, normally sees the VPN server’s IP address instead of your original network address.
That protection has clear boundaries. The VPN provider becomes an important part of the trust chain. It can generally observe connection metadata such as the account or server being used, connection times, traffic volume, and the destination information exposed by the chosen protocol or DNS arrangement. The exact visibility depends on the client, protocol, operating system, and provider infrastructure. A “no logs” statement should therefore be read as a policy claim that needs to be checked against the provider’s terms, retention wording, support practices, and payment requirements.
A VPN also does not hide your identity from a service where you deliberately sign in. If you log in to an account, the service can associate activity with that account even when the IP address has changed. Browser cookies, mobile advertising identifiers, device fingerprints, saved sessions, and application telemetry can continue to identify a user. A VPN is a network privacy layer, not a complete anonymity system.
- ✅ Use a VPN to encrypt the path between the device and the VPN server.
- ✅ Treat the provider’s privacy policy, logging statement, and client source as part of the security model.
- ✅ Keep account separation, browser privacy, operating-system updates, and strong passwords in place.
- ❌ Assume that a changed IP address makes an account login anonymous.
- ❌ Assume that a VPN can block malware, phishing pages, malicious downloads, or tracking inside an authenticated service.
- ❌ Run two system-wide VPN or proxy clients at the same time without understanding their routing and DNS behavior.
How to read a no-log claim
Look for precise language rather than a large privacy slogan. A useful policy should distinguish between connection data, bandwidth or traffic data, account information, diagnostic reports, crash logs, and legal or abuse records. “We do not log your browsing history” is narrower than “we collect no data.” The policy should also explain whether optional analytics can be disabled, how long support tickets are retained, and whether a client sends diagnostic information by default.
Registration and payment can create a separate identity trail. An account may use a username and password without requiring an email address, while the payment processor can still retain transaction information. Alipay, WeChat Pay, and USDT are different payment methods with different privacy characteristics, so choose according to your own legal, financial, and account-security requirements. Do not send a subscription URL, access token, or payment receipt containing sensitive information to public forums.
Encryption protocols and client choice
The protocol determines how a client negotiates the tunnel, authenticates the server, encrypts packets, and handles reconnection. WireGuard is a modern tunneling protocol designed around a relatively small codebase and a simple key-based configuration model. It uses modern cryptographic primitives and is often efficient on laptops and mobile devices. Its security still depends on correct key handling, a genuine server configuration, a trusted client implementation, and the operating system’s network controls.
Shadowsocks is primarily an encrypted proxy transport rather than a full traditional VPN tunnel. Depending on the client’s system integration, some applications may use it while other traffic remains outside the proxy. VMess, VLESS, Trojan, Hysteria2, and WireGuard can appear in different subscription formats and require compatible cores. Hysteria2 and similar protocols may be useful in networks where transport characteristics matter, but a protocol name alone is not proof of privacy, speed, or safety.
| Choice | What it controls | Security question | Practical check |
|---|---|---|---|
| WireGuard | Encrypted tunnel with key-based peer configuration | Are the private keys and configuration obtained from a trustworthy source? | Use a maintained client and protect exported configuration files |
| Shadowsocks | Encrypted proxy transport | Does the client route all intended applications, or only configured proxy traffic? | Check system proxy, application rules, DNS mode, and leak results |
| VMess, VLESS, or Trojan | Protocol and proxy-core specific connection behavior | Does the selected client support the required fields and security options? | Review import logs and confirm that the active profile matches the subscription |
| Hysteria2 | Modern proxy transport with its own client and server requirements | Are the server parameters, authentication data, and client core compatible? | Use the client’s documented import method instead of manually guessing fields |
On Windows and macOS, an official client is usually the simplest choice when it supports the required protocol and provides a system-wide tunnel, kill switch, and DNS controls. On Android and iOS, the operating system may display a permission prompt before a VPN or network extension can operate. That prompt is expected when the app is trusted and installed from an appropriate source, but it should not be accepted blindly for an unknown application. On Linux, a command-line or graphical client may require separate DNS and firewall configuration, so “connected” needs to be verified at the system level.
Compatible clients are useful when a subscription format is not supported by the official application. Clash Verge and sing-box can provide rule-based routing on desktop systems, while Shadowrocket is commonly used on iOS. Their flexibility also creates more opportunities for mistakes: a rule may send DNS outside the tunnel, a direct rule may bypass the VPN, or a system proxy may remain enabled after the client is closed. Import the subscription through the client’s subscription manager, protect the URL as a credential, and update it only from the provider’s account panel or another trusted source.
DNS, WebRTC, and routing leak checks
A leak check should be performed after connecting, after changing protocol or route, and after switching between Wi-Fi and mobile data. Start by recording the normal public IP and DNS behavior with the VPN disconnected. Then connect to a server, open a private browser window, and repeat the checks. The result is meaningful only when you know which network, browser, profile, and client settings were active during the test.
DNS leak testing
DNS translates a domain name into an address. If the VPN carries web traffic through its server but DNS requests still go to the local internet provider, the resolver may learn which domains your device is requesting. A DNS leak can also produce inconsistent regional results: the website connection appears to come from the VPN location while DNS responses reflect the local network.
Check the DNS resolver list shown by a reputable leak-test page and compare it with the expected VPN behavior. A resolver belonging to the local provider may indicate that the client is not controlling DNS, although resolver ownership alone is not always definitive. Some providers use third-party resolvers or regional infrastructure. The important question is whether the DNS path matches the documented configuration and whether requests are encrypted or otherwise protected from the local network.
On desktop systems, inspect the active network adapter and DNS settings after connection. On mobile devices, remember that private DNS, encrypted DNS, ad-blocking applications, and the VPN profile can interact. Changing several of these settings at once makes troubleshooting harder. Test with one configuration, record the result, then change one setting at a time.
WebRTC, IP, and IPv6 checks
WebRTC allows browsers to support real-time audio, video, and data connections. Depending on browser behavior and permissions, WebRTC can reveal local interface information or an address that is not the one expected from the VPN route. A test should show whether the browser exposes the original public address, a local address, or only the VPN address. Do not grant camera or microphone permissions to an unfamiliar website merely to perform a network test.
IPv6 deserves a separate check. If the VPN handles IPv4 but the device continues to send IPv6 traffic directly, websites may observe a different address family outside the tunnel. A client can solve this by supporting IPv6, routing it through the tunnel, or disabling it while connected, depending on the operating system and provider design. Do not disable networking features permanently without understanding the effect on your local network. The correct result is a consistent documented policy, not a particular setting copied from someone else.
- Establish a baseline. Disconnect the VPN and note the public IP, DNS resolvers, browser WebRTC result, and whether IPv6 is available.
- Connect one client only. Close other VPN, proxy, filter, and network-acceleration tools that could install competing routes or DNS rules.
- Repeat the checks. Compare public IP, DNS, WebRTC, and IPv6 results with the expected exit location.
- Test an application. Open a browser and a separate app that matters to you, because rule-based clients may route them differently.
- Reconnect after a network change. Test again after waking the device or moving between Wi-Fi and mobile data, then confirm that the old route was removed.
If a leak appears, first disconnect and reconnect, then verify whether the client has a “block connections without VPN,” “DNS protection,” or IPv6 handling option. Check split-tunneling and rule mode before changing protocols. On Linux or advanced proxy setups, inspect the routing table, resolver service, firewall rules, and proxy environment variables. A browser extension cannot repair a system-wide DNS or routing problem, and a browser-only proxy cannot protect applications outside the browser.
Kill switch, split tunneling, and daily use
A kill switch is designed to block traffic when the VPN tunnel disappears. Without one, an application may briefly reconnect through the ordinary network during server switching, sleep recovery, or an unstable Wi-Fi transition. On a laptop, enable the setting before using a sensitive service on an unfamiliar network. Confirm its behavior with a controlled test: connect, verify normal access, disconnect or pause the VPN, and see whether the protected applications lose network access rather than silently falling back to the local connection.
Different clients implement kill switches differently. Some install firewall rules, some rely on the operating system’s VPN lockdown mode, and some only block traffic while the application is running. Read the client’s description and test after a reboot. A setting that works on Windows may not have the same name or scope on macOS, Android, iOS, or Linux.
Split tunneling sends selected applications or domains outside the VPN while sending the rest through it. This can help local banking, printers, intranet resources, or services that reject VPN addresses. It also creates a deliberate exception. Excluded applications can reveal the local IP, use local DNS, or bypass the kill switch depending on the client design. Make the exception as narrow as possible and review it after subscription updates or client upgrades.
- ✅ Enable a tested kill switch before using a laptop on public Wi-Fi.
- ✅ Keep banking, work, and other sensitive workflows in clearly understood routing rules.
- ✅ Recheck DNS and public IP behavior after changing split-tunneling rules.
- ✅ Disable automatic connection on networks where you do not want a VPN to start unexpectedly.
- ❌ Assume that a kill switch protects traffic from applications deliberately excluded from the tunnel.
- ❌ Leave an old proxy profile, VPN extension, or virtual adapter active when diagnosing a leak.
Public Wi-Fi, payments, and account logins
On public Wi-Fi, verify the network name, wait for the captive portal if one is required, and then connect the VPN. Encryption cannot make a fake hotspot trustworthy, so avoid entering credentials until you are sure that the network is genuine. Use HTTPS, keep the operating system and browser current, and turn off automatic connection to unknown wireless networks. The VPN is an additional layer, not a replacement for transport encryption used by the website or application.
For payments, check the address bar, certificate warning status, and merchant domain before submitting information. A VPN may change the detected region and trigger a fraud review or additional verification. That is a service-side decision, not necessarily a VPN failure. Do not reuse passwords, and prefer a password manager plus multifactor authentication. A VPN can protect the network path while the login itself remains vulnerable to a stolen password, malicious browser extension, or phishing page.