Public Wi-Fi is convenient, but convenience does not make a shared network trustworthy. Airports, hotels, cafés, libraries, conference venues, and coworking spaces may all expose your device to unfamiliar access points, captive portals, weak network configuration, or other users on the same local segment. A VPN can add an important privacy layer by encrypting traffic between your device and the VPN access server, but it is not a complete security solution. It does not automatically protect you from phishing, malware, unsafe downloads, compromised accounts, or a fraudulent website.
The practical goal is not to treat every public network as unusable. It is to understand which risks a VPN can reduce, verify that the tunnel is actually handling the traffic you expect, and combine it with ordinary security controls. This guide explains how common public Wi-Fi attacks work, what to check in DNS and WebRTC behavior, how to evaluate a provider’s privacy policy, and how to create a repeatable connection checklist for Windows, macOS, Android, iOS, and Linux.
What can go wrong on public Wi-Fi?
Public Wi-Fi risks usually come from one of three sources: the network itself, another device connected to the same network, or a malicious service pretending to be legitimate. The network name displayed on your phone or laptop is not proof that the access point belongs to the venue. An attacker can create an access point with a familiar name, use a similar spelling, or copy the name of a nearby hotel or café. If your device connects automatically, it may join the wrong network before you notice.
Fake access points and captive portals
An “evil twin” network imitates a genuine hotspot. The attacker may provide internet access normally at first, because the objective is often to collect browsing information, redirect requests, or display a fake login page. A captive portal can ask for an email address, phone number, social account, payment information, or a password. The presence of a padlock in the browser does not prove that the page is operated by the venue; HTTPS protects the connection to the displayed domain, not the truthfulness of the domain itself.
Before joining, confirm the exact network name with venue staff or printed instructions. Be cautious if the hotspot asks you to install a certificate, browser extension, configuration profile, or unknown application. A normal access portal may request acceptance of terms, but it should not require you to disable security warnings or provide credentials for unrelated services. If a page claims that your browser, VPN, or operating system must be “updated” immediately, close it and use the official update mechanism instead.
Local interception and traffic manipulation
Devices on a shared network may be able to discover one another, depending on the access point’s isolation settings. Attackers can attempt address-resolution manipulation, local traffic redirection, DNS tampering, or connection disruption. Older applications that use plain HTTP are especially exposed because their content may be readable or modified in transit. Modern websites commonly use HTTPS, which protects the session between the browser and the website, but it does not stop every form of tracking or prevent a user from entering credentials into a phishing page.
A VPN adds a separate encrypted tunnel between your device and the VPN access server. When the tunnel is active and DNS requests are handled through the tunnel, the local Wi-Fi operator has less visibility into the destinations requested by your device. The provider may also offer a kill switch that blocks selected traffic when the tunnel drops. These protections depend on the client, operating system, protocol, and configuration. A VPN icon by itself is not enough evidence that every application is using the tunnel.
90+
Countries covered
200+
Routes available
Unlimited
Online devices
5
Supported platforms
These service specifications can help with compatibility and route selection, but they do not prove that a particular public hotspot is safe or that a particular route is suitable for every task. The important question is whether the client behaves correctly on the network you are using and whether the service’s privacy practices match your expectations.
What a VPN can and cannot protect
A VPN is most useful when you want to reduce exposure on an untrusted local network. It can encrypt traffic from the device to the access server, help prevent local observers from reading traffic that would otherwise be unprotected, and provide a consistent route when a device moves between different Wi-Fi networks. It can also reduce the need to trust every café, hotel, or airport network with the contents of your connection.
However, the tunnel does not make the destination trustworthy. If you visit a fake shopping page, download a malicious file, or approve a suspicious sign-in request, the VPN does not know that your action is unsafe. It also does not guarantee anonymity. Websites can still identify you through account logins, cookies, browser characteristics, device identifiers, or information that you voluntarily submit. A VPN cannot repair a compromised device or replace endpoint security.
| Risk or control | What a VPN may help with | What you still need to do |
|---|---|---|
| Untrusted local Wi-Fi | Encrypt traffic between the device and the VPN access server | Verify the tunnel, use HTTPS, and avoid unknown downloads |
| DNS observation or manipulation | Send DNS through the encrypted route when the client supports it | Check for leaks and confirm the operating system is not using another resolver |
| Fake login pages | Not reliably prevented by the tunnel | Inspect the domain, use password managers, and enable multi-factor authentication |
| Malware and unsafe applications | Not a replacement for endpoint protection | Update the system, limit permissions, and download software from trusted sources |
| Connection drops | A kill switch may block traffic during a tunnel failure | Enable and test the feature for the applications and networks you use |
Protocols also affect behavior. OpenVPN, WireGuard, Shadowsocks, VMess, Trojan, and Hysteria2 are not interchangeable labels for exactly the same design. Some are VPN protocols, while others are proxy or transport methods used by compatible clients. A provider’s official client may expose only a subset of these choices, while Clash Verge, sing-box, or Shadowrocket may require a compatible subscription format and profile type. Do not import a profile into a client merely because the file extension looks familiar. Confirm that the protocol and client combination is supported, and avoid running two traffic-management clients at the same time.
How to check DNS and WebRTC behavior
DNS and WebRTC deserve separate attention because a browser can reveal information through paths that users do not immediately associate with the VPN tunnel. DNS translates a domain name into an address. If your device sends DNS requests to the local router or an unrelated resolver while the VPN is active, the local network or that resolver may learn which domains you request. A DNS leak does not necessarily expose the complete contents of a session, but it can weaken the privacy benefit you expected.
DNS verification steps
- Connect to the public Wi-Fi and complete its captive-portal sign-in before starting the VPN.
- Start the VPN client and confirm that it reports an active connection rather than merely showing a saved profile.
- Open a reputable DNS leak-testing service and record the displayed resolver organizations and locations.
- Compare the result with the VPN provider’s documented DNS design. A result that shows only the local network or an unexpected third-party resolver deserves investigation.
- Disconnect the VPN and repeat the check only if you need a comparison. Do not treat one test as a permanent guarantee after changing clients, protocols, or operating systems.
On Windows, check whether another VPN, security application, or manual adapter setting is taking control of DNS. On macOS and Linux, review active network services and resolver configuration after changing networks. On Android and iOS, pay attention to private DNS, configuration profiles, and any other security or filtering application. A system-wide DNS setting can interact with the VPN client in ways that differ between Wi-Fi and mobile data.
WebRTC and browser privacy
WebRTC allows browsers to support real-time audio, video, and peer-to-peer communication. Depending on browser behavior and permissions, WebRTC may expose local or route-related address information to a web page. This is not the same thing as a DNS leak, and a DNS test cannot confirm WebRTC behavior. If your privacy requirements are strict, use a browser privacy test that specifically checks WebRTC and review the browser’s WebRTC, local-network, and media permissions.
Do not install random extensions that promise to “fix” every leak. Extensions can access browsing data and may introduce a new trust problem. Prefer documented browser settings, a maintained security product, or the controls provided by your operating system and VPN client. After changing a setting, close and reopen relevant browser tabs, then test again. Remember that WebRTC is required by some meeting and calling applications, so blocking or restricting it may affect functionality.
A practical public Wi-Fi connection workflow
The safest process is simple enough to repeat. First, update the operating system, browser, VPN client, and security software before leaving home. Enable screen locking and device encryption where available. Make sure important accounts have unique passwords and multi-factor authentication. Save offline copies of travel documents or work instructions so that you are not forced to download unknown files from a portal while under time pressure.
Before joining the hotspot
Disable automatic connection to open networks if your device supports that option. Ask the venue for the official network name and whether a separate network exists for guests or staff. Avoid using a network whose name differs by a single character from the confirmed name. If the signal is unexpectedly strong in an unusual location, that is not proof of an attack, but it is a reason to verify before connecting.
Use mobile data as a fallback for sensitive account recovery, financial activity, or urgent work when the public network behaves strangely. Keep Bluetooth and file-sharing features disabled when you do not need them. On a laptop, mark the network as public rather than private when the operating system offers that choice. This can reduce local discovery and sharing exposure.
After joining and authenticating
Complete the captive portal in a normal browser window. Do not enter a password for your email, cloud storage, or work account into a page that is merely supposed to authorize Wi-Fi access. Once ordinary web access is available, start the VPN. Confirm that the client shows the expected route, protocol, and connection state. If the client supports a kill switch, enable it when uninterrupted privacy is more important than maintaining connectivity during a temporary tunnel failure.
Open a few ordinary HTTPS websites, then check DNS behavior. If you use split tunneling, understand exactly which applications bypass the VPN. Split tunneling can be useful for local printers, venue portals, or services that must use a local connection, but it also creates an intentional exception. Sensitive work applications should not be placed in the bypass list without a clear reason.
After switching networks
Moving from a hotel lobby to a meeting room, or from one airport access point to another, can silently change the route, gateway, and DNS settings. Disconnect and reconnect the VPN after a significant network change if the client does not automatically renegotiate. Check that the kill switch did not remain active in a way that blocks required traffic, and verify that the browser or work application has not returned to a direct connection.
- ✅ Confirm the exact hotspot name with the venue before connecting
- ✅ Complete captive-portal authentication before starting the VPN
- ✅ Use HTTPS and inspect the domain before entering credentials
- ✅ Verify DNS behavior after changing the network or VPN protocol
- ✅ Review split-tunnel rules instead of assuming every app uses the tunnel
- ❌ Do not install certificates, profiles, or extensions offered by an unknown portal
- ❌ Do not ignore browser certificate warnings to reach a work system
- ❌ Do not run two VPN or proxy clients that may compete for routing control
For supported devices, OJVPN offers clients for Windows, macOS, iOS, Android, and Linux. A subscription link may also be imported into compatible clients such as Clash Verge, sing-box, or Shadowrocket when the profile format and protocol are supported. The import step is not a privacy test by itself: after importing, check routing, DNS handling, kill-switch behavior, and whether the intended applications are actually covered. The official quick-start guide is the appropriate place to confirm the current import process.
How to evaluate a VPN provider’s privacy policy
A privacy policy should explain what the service collects, why it collects it, how long records are retained, and which parties may receive information. Look for clear distinctions between account information, payment records, connection metadata, diagnostic logs, and aggregated service statistics. “No logs” is not a complete answer if the document does not define what the provider means by logs.
Ask practical questions. Does the service record connection timestamps? Does it retain source IP addresses? Does it associate a user with a destination address or bandwidth record? Are crash reports optional? Can a user disable diagnostic collection? How are support conversations handled? What information is required for registration? A service that allows registration with a username and password without requiring an email address may collect less account information, but payment providers can still create their own transaction records.
Payment methods also affect the information trail. OJVPN lists Alipay, WeChat Pay, and USDT as payment options. That does not mean every method provides the same privacy characteristics, because payment processors and local regulations determine what transaction information exists. Read the applicable terms before purchase, and do not assume that a payment method makes a user anonymous.
Technical transparency matters as well. A provider may list route coverage of 90+ countries and 200+ lines, but a large route list does not automatically mean every route is suitable for public Wi-Fi, video meetings, gaming, or corporate access. Check whether the service explains supported platforms, subscription import, protocol availability, DNS handling, IPv6 behavior, and kill-switch support. If you need several devices, confirm the simultaneous-use rule; OJVPN’s stated specification is unlimited online devices.
Finally, read refund terms before paying. OJVPN states a 7-day no-questions-asked refund policy. Treat this as a purchasing condition rather than a security feature: a refund window cannot undo data already submitted to a phishing page or repair an infected device.
A compact checklist for daily use
Good public Wi-Fi security is mostly about reducing avoidable mistakes. Use the following checklist when the connection supports ordinary browsing, work, or travel tasks:
- ✅ Keep the operating system, browser, VPN client, and security tools updated
- ✅ Use a unique password and multi-factor authentication for important accounts
- ✅ Confirm the hotspot name through an independent venue source
- ✅ Treat unexpected portal requests, urgent warnings, and forced downloads as suspicious
- ✅ Start the VPN only after captive-portal authentication is complete
- ✅ Test DNS and review WebRTC settings when privacy requirements are high
- ✅ Recheck the tunnel after sleep, roaming, or a major Wi-Fi change
- ✅ Use mobile data for especially sensitive tasks when the hotspot cannot be verified
- ❌ Do not reuse a password because the portal appears familiar
- ❌ Do not assume a VPN protects files, accounts, or applications from every threat
Public Wi-Fi VPN safety FAQ
Is a VPN enough to make public Wi-Fi safe?
No. A VPN can protect the connection between your device and the VPN access server, which is useful on an untrusted local network. It does not prevent phishing, malware, unsafe browser extensions, account theft, or mistakes made on a legitimate but compromised website. Keep HTTPS, system updates, strong passwords, multi-factor authentication, and device security enabled.
Should I start the VPN before joining public Wi-Fi?
Usually, complete the venue’s captive-portal authentication first. Some portals cannot load correctly when all traffic is forced through a tunnel. After access is authorized, start the VPN and confirm that it is active. If the client supports an exception specifically for captive portals, follow its documentation rather than creating a broad permanent bypass.
How do I know whether DNS is leaking?
Connect the VPN, use a reputable DNS leak test, and compare the displayed resolvers with the provider’s documented DNS behavior. Repeat the check after changing networks, protocols, clients, or operating-system settings. A single successful test does not prove that every application will always use the same route.
Can WebRTC still reveal information when a VPN is active?
It can, depending on the browser, permissions, operating system, and VPN configuration. WebRTC is separate from ordinary DNS resolution, so test it separately if it matters to your privacy requirements. Review browser controls carefully, because aggressive blocking may affect audio, video, and real-time collaboration services.