VPN Privacy Guide: How to Check and Fix DNS Leaks

A VPN can change the apparent source of your web requests, but that does not automatically mean every name lookup is protected. Before a browser connects to example.com, the device normally asks a DNS resolver for the site’s address. If that question travels through the ordinary network instead of the VPN tunnel, the resolver may still learn which domains the device is requesting. A similar problem can occur with WebRTC in a browser, IPv6 traffic outside the tunnel, or an application that ignores the system proxy entirely.

That is why a privacy check should examine more than the VPN client’s “Connected” label. A useful review has four parts: establish a baseline without the VPN, connect using the intended client and mode, test DNS and WebRTC separately, and then confirm that the settings remain effective after changing networks or restarting the device. This guide explains how to perform those checks on Windows, macOS, Android, iOS, and Linux, including common third-party clients such as Clash Verge, sing-box, and Shadowrocket.

What a DNS leak actually reveals

DNS is the directory service behind a domain name. When an application needs to connect to a hostname, it usually requests one or more IP addresses from a resolver. That resolver could belong to your internet provider, a public DNS operator, a company network, a home router, or a resolver configured by a VPN client. The resolver may not see the contents of an encrypted HTTPS session, but it can still observe useful metadata such as the requested domain, request timing, and the network address making the query.

A DNS leak occurs when the DNS resolver used during a VPN session is outside the privacy boundary you intended to use. For example, the browser may send ordinary HTTPS traffic through a VPN tunnel while the operating system continues to ask the local router for domain resolution. The website sees the VPN exit address, but the local resolver sees the domain request. This is especially easy to miss when a client uses a system proxy rather than a full-device tunnel.

Not every external resolver result is automatically a leak. Some VPN services deliberately use a third-party DNS provider, and some privacy-focused configurations send encrypted DNS to a resolver that is not owned by the VPN provider. The important questions are whether the resolver is expected, whether the query is transported through the intended tunnel, and whether the provider’s privacy policy clearly explains retention and processing.

DNS leaks should also be distinguished from DNS hijacking, failed resolution, and stale cache entries. A test can show a resolver associated with your network even when the current query was served from a local cache. Conversely, a resolver may appear unfamiliar simply because its address belongs to a larger network operator. Treat a test result as evidence to investigate rather than as a complete verdict based only on a company name.

Prepare a comparable baseline

Reliable diagnosis starts with two comparable states: disconnected and connected. Use the same device, access network, browser, and test method for both. If you disconnect on home Wi-Fi and reconnect through mobile data before the second test, a changed IP or resolver may be caused by the access network rather than by the VPN. Close duplicate VPN and proxy tools first, because two applications changing routes at the same time can produce misleading results.

Before connecting, record the public exit address and the DNS resolver information reported by a reputable network testing page. You can use this site’s network test page to establish the IP baseline. For a more complete DNS check, use a recognized DNS leak testing service and select its standard or extended test according to the instructions on that site. Do not paste private account information into a diagnostic page; a DNS test normally requires only ordinary resolver requests.

On a desktop system, also note whether the device has both IPv4 and IPv6 connectivity. Some VPN clients protect IPv4 but leave IPv6 active, creating a partial leak or allowing applications to bypass the tunnel. On a phone, note whether a private DNS profile, encrypted DNS application, content filter, or enterprise management profile is active. These services may take control of DNS before the VPN client does.

• ✅ Disconnect the VPN and record the public IP, resolver names, and approximate resolver location.
• ✅ Keep the same Wi-Fi or mobile network for the connected test.
• ✅ Close browser proxy extensions and other VPN clients that may alter routing.
• ✅ Record whether IPv6, Private DNS, Secure DNS, or a local filtering service is enabled.
• ❌ Do not diagnose a leak from one cached browser result or one unfamiliar resolver label.

Run a DNS leak test step by step

Start by connecting with the official 93VPN client or with the compatible client that manages your subscription. The official applications support Windows, macOS, iOS, Android, and Linux. If you use Clash Verge or sing-box, import the subscription through the client’s supported subscription function, select the intended profile, and confirm whether the profile uses system proxy, TUN mode, or another routing method. On iPhone, Shadowrocket and similar clients may require a system VPN permission and an explicit rule or global mode before all selected traffic follows the tunnel.

1. Connect without changing the test environment. Stay on the same access network used for the baseline and wait until the client reports a completed connection rather than an unfinished handshake.
2. Open a fresh diagnostic session. Use a private browsing window or close and reopen the test page. This reduces confusion from cached page data, although it does not replace a real DNS query.
3. Check the exit IP. The address should differ from the disconnected baseline if the browser request is using the selected route. Compare the address and network owner before relying on a geographic label.
4. Run the DNS test. Start a standard test first, then an extended test if the service provides one. Multiple resolver addresses can be normal, especially when a provider uses load balancing.
5. Interpret the resolver list. Ask whether the listed networks match the VPN’s stated DNS design or a resolver you deliberately configured. A result showing only your home ISP or office network deserves further investigation.
6. Repeat after a reconnect. Disconnect and reconnect once, then test again. A configuration that works only after a particular startup order may not be reliable in daily use.

For command-line confirmation, Linux and macOS users can inspect active resolver configuration with tools such as resolvectl status, scutil --dns, or the network settings interface. Windows users can inspect adapter details with ipconfig /all. These commands show configured resolvers, not necessarily every resolver used by every application, so compare them with an external test. A browser using its own encrypted DNS may not appear in the operating system’s ordinary resolver list.

To check whether a query is being sent through the expected interface, advanced users can examine routing and packet behavior with the platform’s network tools. This requires care: packet capture can expose requested domain names and other metadata in local files. Store diagnostic captures securely and remove them when the investigation is complete. The goal is to verify a configuration, not to collect more browsing information than necessary.

Find the source: system DNS, browser DNS, or split routing

System DNS settings

On Windows and macOS, a full-tunnel VPN generally installs a virtual adapter and changes route priority while connected. A system-proxy-only configuration may change browser HTTP and HTTPS requests without controlling every DNS request. On Linux, behavior depends on NetworkManager, systemd-resolved, the desktop environment, and whether the client creates a TUN interface. Inspect the active interface and resolver after connection rather than assuming that the client uses one universal method.

On Android, Private DNS can be set to Off, Automatic, or a specified provider hostname. A specified provider may compete with the VPN’s DNS handling, depending on the client and Android version. Test with the setting you intend to use every day. On iOS, DNS profiles, content blockers, and managed device policies can also affect name resolution. If a VPN uses an on-demand or always-on mode, check whether another profile is being disabled or restored when the VPN connects.

Browser Secure DNS and WebRTC

Modern browsers may offer Secure DNS, commonly implemented through DNS over HTTPS. This can improve transport confidentiality, but it may bypass the DNS path selected by a VPN client if the browser sends queries directly to its own provider. Whether that is acceptable depends on your threat model and the provider you trust. For a consistent VPN DNS policy, review the browser’s Secure DNS setting and either use the VPN’s documented option or configure an intentional encrypted resolver.

WebRTC is a separate browser feature used for real-time audio, video, and peer-to-peer connectivity. Its connection checks can expose local or public network candidates to a website, particularly when the browser and VPN are configured with different routing rules. WebRTC does not necessarily reveal your exact physical address, but an unexpected candidate can disclose information you did not intend to share. Test WebRTC in the browser you actually use, because behavior differs between Chromium-based browsers, Firefox, Safari, and mobile browsers.

Fix common DNS leaks by device

Windows: Prefer the official client’s leak-protection and full-tunnel options when you need device-wide coverage. If using Clash Verge or sing-box, understand whether the profile creates a TUN interface or only changes the system proxy. TUN mode can capture more application traffic, but it may require administrator permission and can interfere with local services. After changing the mode, disconnect and reconnect, flush local DNS cache if appropriate, and run both an IP and DNS test again. Do not manually overwrite every adapter’s DNS address unless you understand how the VPN client restores settings after disconnecting.

macOS: Check the VPN configuration under system network settings and look for other active profiles, security tools, or DNS filters. A browser extension may use its own proxy while command-line tools use the system route. Test both. If the client supports kill switch or block-outside-DNS behavior, enable it only after confirming that local network services you need are compatible. A strict kill switch should prevent fallback traffic when the tunnel drops, but it may also stop ordinary connectivity until the VPN reconnects.

Android: Review Private DNS, battery restrictions, and “always-on VPN” or “block connections without VPN” options where available. Battery optimization can stop a third-party client in the background, after which applications may fall back to the mobile network. Exclude the VPN application from aggressive battery management if the device manufacturer provides such a setting. Then test with the screen locked and unlocked, because background behavior can differ from an active screen session.

iOS: Confirm the VPN permission is active and identify whether another DNS, content-filter, or device-management profile is installed. With Shadowrocket, inspect whether rules send DNS through the proxy and whether the selected mode is rule-based or global. Rule-based operation is convenient for local services, but a missing domain rule can leave traffic outside the intended tunnel. Test the websites and applications that matter instead of checking only Safari’s homepage.

Linux: Verify the active resolver manager and route table after the client connects. If systemd-resolved is in use, its per-link DNS behavior may differ from the resolver shown in a static configuration file. sing-box can provide TUN-based routing, but the configuration must define DNS servers, rules, and route handling consistently. Avoid copying a configuration designed for a different distribution without checking permissions, interface names, and service startup order.

How protocols and route modes affect privacy checks

Protocol selection alone does not determine whether DNS leaks. WireGuard is a modern VPN protocol with a lightweight design, but the client still needs correct DNS and route handling. OpenVPN can also protect DNS when the client receives and applies the proper resolver and route instructions. Shadowsocks is commonly used as a proxy transport rather than a complete device VPN; unless the compatible client captures DNS and application traffic, some requests can remain outside the proxy. VMess and Trojan are likewise protocol or transport choices within compatible proxy systems, and their privacy result depends on the client’s routing mode. Hysteria2 may perform well on difficult networks, but performance does not by itself guarantee DNS or WebRTC coverage.

IEPL, BGP, and CN2 describe route or network characteristics, not DNS privacy features. A specialized route may provide a different path to the destination, while the local operating system still sends DNS queries to the wrong resolver. Treat route selection and leak protection as separate configuration layers. First make sure the route is stable and the intended traffic is captured; then compare resolvers, WebRTC candidates, IPv4, and IPv6 behavior.

Split tunneling requires particular attention. It can keep banking, printers, intranet resources, or local media services on the ordinary network while sending selected domains through the VPN. That is useful, but every exception is a possible source of confusion. Document which applications and domains are excluded. If a browser uses a proxy while a desktop application uses direct access, their DNS results may legitimately differ. The correct result is the one that matches your stated policy, not necessarily a result where every request uses the same resolver.

Review the provider’s privacy promises

A clean DNS test is only one part of a privacy decision. Read the provider’s no-log policy and look for specific language about connection timestamps, source IP addresses, DNS queries, bandwidth records, device identifiers, crash logs, and account activity. “No logs” can mean different things if the policy does not define what is excluded. Also check whether diagnostic or abuse-prevention data is retained, how long it remains available, and whether it is associated with an account.

Consider the account information required to use the service. 93VPN states that registration does not require an email address and can use a username and password. Available payment methods include Alipay, WeChat Pay, and USDT. These details do not make a service anonymous by themselves, but they help you understand what account and payment information may exist. Review the privacy policy, terms, and refund wording before subscribing rather than relying only on a marketing phrase.

Device security remains important even when the VPN is configured correctly. Keep the operating system, browser, and VPN client updated from official distribution channels. Protect the account with a unique password, avoid sharing subscription links, and remove old profiles from devices you no longer control. On public Wi-Fi, verify the network name, prefer HTTPS, and do not treat a VPN as protection against phishing pages, malicious downloads, browser fingerprinting, or an infected device.

These service specifications describe availability and account terms; they do not prove that a particular device is leak-free. Perform your own checks after importing a subscription, changing a route, installing a browser update, or moving between Wi-Fi and mobile data.

Use a safer routine on public networks

Public networks add uncertainty because you do not control the access point, local resolver, or captive portal. Connect to the network only long enough to complete its sign-in process, then activate the VPN and confirm the exit IP and DNS behavior. If the VPN client offers a kill switch, use it when preventing fallback traffic is more important than maintaining uninterrupted connectivity. If the network blocks the VPN handshake, do not enter sensitive credentials into a page merely because it claims to be the Wi-Fi login portal.

When leaving a public network, disconnect from it manually and disable automatic joining if the device stores the network. A later connection to a similarly named access point can expose traffic before the VPN starts. On laptops, check for local proxy settings left behind by workplace or hotel networks. On phones, review active VPN and DNS profiles after returning home, because a profile that remains enabled can change resolution behavior for every subsequent connection.

• ✅ Complete captive-portal login before starting privacy-sensitive activity.
• ✅ Connect the VPN after the network is ready and confirm the exit IP changed.
• ✅ Retest DNS when moving between public Wi-Fi, home Wi-Fi, and mobile data.
• ✅ Use a kill switch when fallback traffic would create unacceptable exposure.
• ❌ Do not trust a public network simply because it requires a password.
• ❌ Do not leave unused DNS profiles, proxy extensions, or old subscription links active.

Frequently asked questions

If my IP address changes, can I assume DNS is protected?

No. An IP test checks the route used by the specific request to the test page. DNS may still use the local resolver, a browser’s Secure DNS provider, or an application-specific path. Always run a DNS test separately and compare its result with the configuration you intended to use.

Is a public DNS provider automatically unsafe?

No. A public resolver can be a deliberate choice, especially when it supports encrypted DNS and has a clearly stated privacy policy. The concern is an unexpected resolver, an unprotected transport path, or a resolver whose retention practices do not fit your needs. Identify the provider and understand why it appears before changing settings.

Why does a third-party client pass the browser test while another app leaks?

The browser may obey a system proxy while the other application connects directly. Rule-based clients can also omit an application, domain, or DNS request type. Compare system-proxy mode with TUN or full-device mode, inspect split-tunnel exclusions, and test the application itself. Do not add every application to global routing without considering local services and compatibility.

When should I repeat a leak test?

Repeat it after installing or updating the client, importing a new subscription, changing protocol or route mode, enabling Secure DNS, changing browser privacy settings, or moving to another access network. A configuration can be correct in one environment and fail in another because of IPv6, resolver policies, startup order, or conflicting network profiles.

The practical objective is not to chase a particular resolver name or force every application into one route without a reason. Define what should use the VPN, identify which DNS and WebRTC paths are acceptable, and test that policy under the conditions in which you actually work. If a result is unexpected, disable competing tools, choose a clear proxy or TUN model, correct DNS and IPv6 handling, and verify again from a fresh session. For platform-specific setup steps, consult the setup guide; for current service terms and plan details, review the pricing page.