VPN Privacy Check: Find DNS Leaks And Fix Them Safely

A VPN can show “Connected” while your device still sends DNS requests through the local network, or while a browser exposes connection details through WebRTC. These are different privacy problems, and they require different checks. A DNS leak concerns the resolver that translates domain names into IP addresses. A WebRTC leak concerns browser features that may reveal network addresses to a webpage. Neither problem is solved simply by looking at the VPN indicator in the status bar.

This guide explains how to check both conditions safely, how to interpret test results, and what to change when the results do not match your intended setup. The same principles apply whether you use an official Windows, macOS, Android, iOS, or Linux client, or import a subscription into Clash Verge, sing-box, Shadowrocket, or another compatible application. The goal is not to force every connection through one tunnel. The goal is to understand which traffic is routed, which DNS service answers requests, and whether browser permissions expose information that you did not intend to share.

What a DNS Leak Really Means

When you type a website address, an application normally needs to translate the domain name into an IP address. That translation is performed by a DNS resolver. The resolver may be supplied by your home router, internet provider, workplace, school, mobile carrier, operating system, browser, VPN client, or a custom configuration. A DNS leak occurs when the domain lookups are sent to a resolver outside the privacy path you intended to use.

For example, a VPN tunnel may carry the website connection while the operating system continues asking the local router to resolve every domain. The page may load through the VPN exit, but the resolver can still observe the names being requested. This does not necessarily reveal the full content of an encrypted website session, but it can expose browsing destinations and create an inconsistent location signal.

A DNS result also does not prove that the VPN itself is broken. The result may be caused by an intentional split-DNS policy, a browser feature, an enterprise security agent, a manually configured resolver, an old network profile, or a client that does not capture all system traffic. You must first decide what behavior you expect. A privacy-focused full-tunnel setup usually aims to send ordinary DNS requests through the VPN path. A work or home configuration may intentionally keep internal domains on a local resolver.

DNS Leak Versus DNS Mismatch

Testing pages commonly display resolver organizations or approximate locations. Seeing a resolver associated with your access provider can be a warning sign, but the label should not be interpreted in isolation. Some providers operate their own DNS infrastructure in a different region, and some VPN services use a third-party resolver that does not carry the same brand name as the VPN. A mismatch between the displayed resolver and the VPN provider is therefore a reason to investigate, not automatic proof of exposure.

Look for a consistent pattern. Disconnect the VPN and record the ordinary result. Reconnect the VPN, wait for the client to finish applying its DNS settings, then test again. If the resolver list remains unchanged when the VPN is active, check whether the client is using system proxy mode instead of a virtual tunnel, whether split tunneling excludes the browser, and whether encrypted DNS is enabled independently in the browser.

How WebRTC Can Expose Network Details

WebRTC is a collection of browser technologies used for real-time audio, video, screen sharing, and peer-to-peer communication. To establish a call, a browser may gather connection candidates and use mechanisms such as ICE and STUN to discover possible network paths. Depending on the browser, operating system, VPN mode, and permissions, a webpage may learn address information that is not visible in the normal page URL or HTTP connection.

A WebRTC test may show a local address, a VPN-related address, or an address associated with the direct network connection. The presence of a private local address is not always a serious leak because private address ranges are not normally routable across the public internet. A public address that belongs to your access provider is more relevant if you expected the browser to use only the VPN path. The result still depends on the test page and browser implementation, so compare it with the address shown by a separate connection test.

WebRTC behavior is separate from DNS behavior. Changing the DNS resolver will not necessarily change the browser’s WebRTC candidates. Likewise, blocking WebRTC candidates will not automatically prevent an operating system service from using a local DNS resolver. A complete privacy check therefore uses at least a DNS test, an external address test, and a WebRTC test while the same browser profile is active.

Browser Settings and Permissions

Review browser privacy settings before installing extensions. Chromium-based browsers may expose controls for WebRTC behavior through policy, flags, or extensions, although the available controls can change between versions. Firefox provides more visible privacy preferences, but changing advanced settings can affect legitimate video meetings and browser-based calling. Safari handles WebRTC and private-network access differently from Chromium and Firefox, so do not copy a setting from another browser without testing it.

Also review site permissions for camera, microphone, local-network access, pop-ups, and automatic downloads. A website does not need camera or microphone permission merely to perform a basic connection check. For a meeting service, grant permissions only to the service you recognize, and remove permissions that are no longer necessary. Browser extensions can also modify DNS, proxy, or WebRTC behavior. Test in a clean private window or a separate browser profile when you need to distinguish the VPN from extension behavior.

• ✅ Test DNS, external address, and WebRTC behavior separately.
• ✅ Compare results with the VPN disconnected and connected.
• ✅ Review browser extensions that manage proxies, privacy, or encrypted DNS.
• ✅ Grant camera, microphone, and local-network permissions only to trusted sites.
• ❌ Do not assume a browser lock icon proves that DNS and WebRTC are private.
• ❌ Do not install several privacy extensions that control the same browser feature.

Where and How to Test Your Connection

Use a reputable public DNS leak testing page for resolver checks, a separate “what is my IP” service for the apparent exit address, and a dedicated WebRTC test page for browser candidates. Search for the service yourself or use a link from a trusted security reference rather than copying a test URL from an unknown advertisement. Avoid entering your VPN subscription link, account password, payment details, or personal information into a diagnostic page.

Before testing, close sensitive banking or work sessions. Disable automatic downloads and avoid uploading screenshots that contain account identifiers. A connection test normally needs only to load a page and read the result. If a page asks you to install software, paste a subscription link, or grant broad permissions, stop and choose another diagnostic method.

A Repeatable Test Procedure

1. Prepare the baseline. Disconnect the VPN and note the external address, resolver names, and WebRTC candidates shown by the test pages. Do not treat this baseline as a failure; it simply describes the normal network.
2. Close old sessions. Close the test tabs, restart the browser profile if necessary, and disconnect any other proxy or VPN application. Multiple tunnel tools can create overlapping routes and make the result difficult to interpret.
3. Connect one client. Use the official client or the compatible client recommended for your subscription. Wait until the node list, route mode, and DNS mode finish loading before opening the test pages again.
4. Run the external address test. Confirm whether the apparent address changes to the intended exit. If it does not change, the client may be in system-proxy mode, the tested application may be excluded by split tunneling, or the connection may not be active.
5. Run the DNS test. Check whether the resolver pattern changes as expected. Read the organization and approximate region fields, but remember that a resolver may be operated by a partner rather than carrying the VPN brand.
6. Run the WebRTC test. Compare public candidates with the baseline. If the browser reveals a direct public address while the VPN is active, review WebRTC controls, browser extensions, and whether the client provides tunnel mode rather than only application proxying.
7. Repeat after a network change. Test again after moving between home Wi-Fi, mobile data, and public Wi-Fi. A client can behave differently when the operating system changes network interfaces or restores an old DNS profile.

Keep a short record of the client name, selected route, routing mode, DNS mode, browser, and network type. This is more useful than saving only a screenshot because it allows you to identify which change caused a different result. Do not publish the complete subscription URL or configuration file. Such data may contain credentials even when it looks like an ordinary web address.

Fix DNS Leaks by Layer

Start with the VPN client rather than immediately changing the operating system’s global DNS address. Look for settings named DNS mode, remote DNS, tunnel DNS, fake-IP, redirection, or “protect DNS.” The exact names vary by client and core. A full-tunnel or TUN mode generally has more control over system traffic than a simple HTTP or SOCKS proxy, but it can also require additional operating-system permission and may affect local devices.

In Clash Verge, inspect the selected mode, TUN setting, DNS section, and rule behavior. If the browser is excluded from the active rules, its DNS and connection traffic may remain direct. In sing-box, review whether the DNS server, route rules, and TUN interface are consistent. A DNS server definition alone does not guarantee that every query is redirected to it; route and outbound behavior matter as well. In Shadowrocket, check the global or rule-based mode, DNS settings, and whether the current profile sends matching requests through the intended proxy.

For official desktop and mobile clients, enable the provider’s DNS protection or tunnel option when available. Reconnect after changing the setting, because some clients apply DNS changes only when a new tunnel is created. If the client offers split tunneling, decide whether DNS requests from excluded applications should remain local. A rule that excludes an application but sends its DNS through the tunnel can also produce confusing results, especially when the application uses its own resolver.

Clean Up Operating-System DNS State

After changing a client setting, flush stale DNS caches and reconnect the network interface. On Windows, open a terminal with appropriate permissions and run ipconfig /flushdns. On macOS, restart the connection or use the system’s DNS cache refresh procedure for your installed version. On Linux, the correct action depends on whether the system uses systemd-resolved, NetworkManager, dnsmasq, or another resolver service; resolvectl status can help identify the active resolver before you alter anything.

Android and iOS may apply Private DNS, encrypted DNS, or per-network DNS settings independently of the VPN application. Review the system setting and temporarily return it to the client-recommended mode for testing. Do not assume that a custom encrypted DNS service is always more private in combination with a VPN. It may bypass the client’s DNS handling or create a second policy that is difficult to audit.

Corporate security software, parental-control tools, antivirus web filters, and browser extensions can install local resolvers or certificates. If a leak appears only on one device, compare the installed network filters with a clean device. If the result appears only on one network, inspect the router’s DNS interception or captive-portal behavior. On public Wi-Fi, complete the captive-portal sign-in first, then reconnect the VPN and repeat the tests.

Fix WebRTC Exposure Safely

First determine whether the displayed address is private or public and whether it belongs to the direct connection or intended VPN exit. Do not disable every browser real-time feature automatically if you rely on video meetings, customer support calls, or screen sharing. Instead, prefer the least disruptive control that prevents unwanted public candidate exposure while preserving WebRTC for trusted sites.

Review the browser’s privacy controls and update it through its normal trusted update channel. If you use an extension designed to limit WebRTC exposure, install only one reputable extension and read which permissions it requests. An extension that controls all websites can inspect or alter more browsing activity than necessary. Test after installation because an extension may block a meeting service, change media negotiation, or behave differently in private windows.

For high-sensitivity activities, use a separate browser profile with limited extensions and no unnecessary site permissions. Keep banking and everyday browsing separate from experimental WebRTC settings. A dedicated profile makes it easier to understand whether a result comes from the browser configuration rather than from the VPN. It also reduces the chance that a meeting site’s required permissions are accidentally granted to unrelated sites.

Privacy Checks for Common Scenarios

Public Wi-Fi

Public Wi-Fi often introduces a captive portal, changing DNS behavior before authentication is complete. Connect to the network, complete the portal step using a trusted page, and then start the VPN. Confirm that the VPN client has permission to create a tunnel and that the system has not returned to a direct route after the network changes. Disable automatic connection to unfamiliar open networks and avoid entering sensitive credentials while the connection state is uncertain.

Online Banking

Banking sites may react to a changing exit region, a new device signal, or an interrupted session. If the bank already works normally on your local network, routing it directly may be less disruptive than changing regions repeatedly. If you use the VPN for a specific reason, choose one stable route, confirm the address and DNS behavior beforehand, and do not switch nodes during a payment or transfer. Always check the page address and certificate through the browser before entering credentials.

Browser Permissions

Remove camera, microphone, notification, location, and local-network permissions from sites that do not need them. A VPN does not replace browser permission management. Location access may use device sensors or operating-system services, while WebRTC may use browser network candidates. Review permissions separately and test the browser profile you actually use, not only a clean browser that has different extensions and settings.

VPN Settings

Keep one clear baseline configuration. Record whether the client uses global routing, rules, system proxy mode, or TUN mode; record the DNS mode and the selected protocol; then test. Shadowsocks, VMess, Trojan, VLESS, Hysteria2, and WireGuard differ in implementation and transport, but a protocol change alone does not prove that DNS or WebRTC exposure has been fixed. If a client supports several route types, compare the route only after the privacy settings are stable.

• ✅ Reconnect the tunnel after changing DNS or TUN settings.
• ✅ Keep local banking, intranet, and device-discovery rules intentional.
• ✅ Use one browser profile for controlled testing and document the settings.
• ✅ Recheck after switching between Wi-Fi and mobile networks.
• ❌ Do not publish subscription URLs, access tokens, or full configuration files.
• ❌ Do not use several VPN clients at the same time while troubleshooting.

When a Leak Test Still Looks Wrong

If the external address changes but DNS does not, focus on DNS routing, browser encrypted-DNS settings, system services, and split tunneling. If DNS changes but the external address does not, focus on the client’s operating mode, the selected outbound, and whether the test browser is excluded. If both change but WebRTC still shows a direct public candidate, focus on browser policy, extensions, and the difference between a system proxy and a virtual tunnel.

If only one website reports a problem, clear its cached permissions, close existing tabs, and repeat in a clean profile. Some pages cache an earlier result or display a resolver from a previous request. If every browser reports the same result, inspect the operating system and network equipment. A router may redirect DNS requests, while a security product may deliberately intercept them. On a managed work device, do not remove company controls without authorization; ask the administrator how the policy is intended to work.

When support is needed, provide the client platform, client version, protocol name, route mode, DNS mode, browser, and a description of the test result. Redact public addresses if they are not required for diagnosis, and always remove subscription URLs, usernames, passwords, and tokens. A useful report describes what changed between the disconnected and connected states without exposing private configuration data.

Frequently Asked Questions