A VPN can encrypt traffic between your device and the VPN entry point, but “connected” does not automatically mean that every privacy signal is hidden. DNS requests may still use a local resolver, IPv6 traffic may follow a different path, and browser features such as WebRTC can expose network candidates to a webpage. These issues are not proof that a VPN is useless; they are signs that the client, operating system, browser, and network need to be checked as one system.
This guide explains how to test for DNS leaks safely, interpret the result without overreacting, and fix common causes on Windows, macOS, Android, iOS, and Linux. It also covers no-log claims, Kill Switch behavior, public Wi-Fi risks, and the limits of VPN privacy. The practical goal is not to promise perfect anonymity. It is to reduce unnecessary exposure, understand what the tunnel protects, and know which settings still require your attention.
What a DNS leak can reveal
DNS, or the Domain Name System, translates a hostname such as a website address into an IP address. Whenever an application needs to reach a domain, it may send a DNS query to a configured resolver. That resolver could belong to your internet provider, a local router, a public DNS service, an enterprise network, or the VPN provider. The query can reveal which domains your device is trying to reach even when the following web connection is encrypted with HTTPS.
When a VPN is working as intended, DNS requests from applications routed through the tunnel are normally sent to a resolver available through the VPN path or to a resolver selected by the client. A DNS leak occurs when those requests instead travel outside the tunnel, often to the resolver assigned by the local network. The destination website may still see the VPN exit address, but the DNS operator or network administrator can observe the requested domain names.
A leak does not always look the same. Some tests display the resolver’s organization, while others show only an approximate location or network identity. A result that lists a familiar public DNS company is not automatically a leak: the important question is whether the request went through the VPN tunnel and whether the resolver is expected under the client’s privacy design. Compare the result with the VPN disconnected state and read the test’s explanation rather than judging only by the company name.
3
Main checks: DNS, IPv6, WebRTC
5
Supported platforms to review
120+
Countries available on SQVPN
240+
Routes available on SQVPN
DNS leaks are different from IP exposure
An IP address identifies a network endpoint or exit location, while DNS records show where name-resolution requests were sent. A VPN can change the visible exit IP while leaving DNS requests on the local connection. The reverse can also happen: DNS requests may use the VPN path while an application bypasses the tunnel and connects directly. That is why a privacy check should include the public IP, DNS resolver list, IPv6 address, and browser-specific behavior.
DNS leaks also differ from a malicious website learning information that you voluntarily provide. Logging into an account, accepting an identifying cookie, or using a device with a unique browser profile can associate activity with you even if the VPN hides the original IP address. A VPN is a transport and routing tool, not a replacement for account separation, browser permissions, secure passwords, or careful sharing of personal information.
How to test DNS, IPv6, and WebRTC
Perform the test in a controlled order. First disconnect the VPN and record the public IP, visible IPv6 address if one is present, and DNS resolver names. This gives you a baseline for the local connection. Then connect the VPN, wait until the client reports a completed connection, and repeat the same checks in the same browser. Changing the browser, network, or server between tests makes the results harder to compare.
For DNS, use a reputable DNS leak testing page or the network detection feature on the SQVPN website. A useful test displays more than a single “safe” label: it should identify the resolvers that answered the requests. If the disconnected test shows your internet provider and the connected test shows resolvers associated with the VPN path, that is generally the expected direction. If the local provider remains visible after connecting, investigate the client and operating-system configuration.
Test both a standard lookup and an extended lookup when the page offers those options. Different tests may generate different domain requests, and a split-tunnel rule may affect only selected applications. Clear the browser’s existing state only when the testing page instructs you to do so; repeatedly clearing everything can hide the conditions that caused the leak in normal use.
IPv6 requires a separate check. Some networks provide IPv6 connectivity even when the VPN tunnel handles only IPv4. In that situation, an application may connect directly over IPv6 while the user sees a changed IPv4 address. If your test reports an IPv6 address belonging to the local provider rather than the VPN path, either use a client that supports IPv6 tunneling correctly or disable IPv6 only when you understand the operating-system and network consequences.
WebRTC is a browser communication framework used by voice, video, and peer-to-peer features. During connection negotiation, a browser can discover local or public network candidates. Modern browsers have introduced controls that reduce this exposure, and VPN clients may filter or manage WebRTC traffic, but behavior varies by browser, operating system, and permission settings. Use a WebRTC-specific test in addition to a DNS test, then check whether the listed candidates correspond to local interfaces, the VPN path, or both.
Read results without false alarms
A local private address such as an address from a home router can appear in some WebRTC tests. It is not the same as exposing your public internet address, although it may still provide network information to a webpage. A resolver located in another country is not automatically evidence of security, and a resolver located near you is not automatically a leak. What matters is the route, the expected client behavior, and whether your local provider or physical connection details appear unexpectedly.
- ✅ Record the disconnected baseline before changing any VPN or browser setting.
- ✅ Repeat DNS, IPv6, and WebRTC checks after connecting to the VPN.
- ✅ Compare resolver organizations and visible addresses, not only a colored status icon.
- ✅ Test with split tunneling disabled before testing special application rules.
- ❌ Do not treat a browser WebRTC result as a complete audit of every application on the device.
- ❌ Do not conclude that a resolver is unsafe solely because its brand is different from the VPN brand.
Fix common DNS leak causes
The safest first fix is usually to update the official VPN client, reconnect, and restore its default DNS or leak-protection settings. Avoid manually entering random DNS addresses before you understand the problem. A custom resolver may improve availability in one network while creating a different routing or trust issue. The client should ideally send DNS traffic through the tunnel, prevent fallback to the local resolver, and apply the setting consistently after reconnecting.
On Windows, inspect the active adapter after the VPN connects. Physical Wi-Fi or Ethernet adapters may retain DNS servers supplied by the router, while the VPN creates a virtual adapter with its own settings. This is not by itself proof of a leak, because the client may intercept requests at a lower level. The meaningful check is whether applications can still send DNS queries outside the tunnel. If a leak appears, restart the VPN service, disable conflicting network-filtering tools, and review whether another security product is rewriting DNS settings.
On macOS, check both the active network service and any VPN configuration profile. DNS settings can be influenced by Wi-Fi, Ethernet, VPN profiles, content filters, security software, or encrypted DNS features in the browser. A client that uses system integration may behave differently from one that creates a separate tunnel interface. After changing a setting, disconnect and reconnect rather than assuming the old resolver state has been replaced immediately.
On Android, per-app VPN settings, “always-on VPN,” and “block connections without VPN” can materially change the result. Review whether selected applications are excluded from the tunnel and whether the system’s Private DNS mode is forcing a resolver outside the VPN design. An application excluded from the VPN may also be excluded from the client’s DNS handling. Battery optimization can stop a background VPN service, so check the vendor’s battery settings and confirm the connection remains active after the screen has been off.
On iOS, VPN behavior is constrained by the system’s networking model. Check the official client’s connection status, on-demand rules, and any installed configuration profile. Safari and other applications can also use privacy features that alter DNS handling. If a DNS result changes unexpectedly after switching networks, remove obsolete profiles, reconnect the client, and test again on both Wi-Fi and mobile data. Do not install an unknown profile merely because it claims to “repair” a leak.
On Linux, inspect the resolver manager used by the distribution, such as NetworkManager or systemd-resolved, along with the VPN interface and routing table. WireGuard, OpenVPN, and other clients may apply DNS settings differently. A tunnel can be established while the resolver continues using the physical interface unless the configuration explicitly handles DNS. Check the client logs for routing or handshake errors, verify that the intended DNS server is reachable through the tunnel, and ensure that a second VPN or proxy process is not competing for control.
| Possible cause | What you may observe | Safer corrective action |
|---|---|---|
| Local resolver remains active | The ISP or home-router resolver appears while connected | Enable the client’s DNS leak protection and reconnect |
| IPv6 is outside the tunnel | The local provider’s IPv6 address remains visible | Use supported IPv6 tunneling or review IPv6 handling |
| Split tunneling is enabled | Only excluded applications show different DNS behavior | Temporarily disable exclusions and test each rule |
| Another network tool is active | DNS settings change after reconnecting or switching networks | Disable competing VPN, proxy, filter, or security profiles |
| VPN service stops in the background | Leaks appear after sleep, screen lock, or network changes | Review system battery and always-on connection settings |
Configure Kill Switch and routing carefully
A Kill Switch is designed to block selected or all traffic when the VPN tunnel is unavailable. Its purpose is to prevent accidental direct connections during a reconnect, server change, sleep-wake cycle, or unstable Wi-Fi transition. It is not the same as DNS leak protection. A Kill Switch may stop packets from leaving while the tunnel is down, but it does not necessarily correct a resolver configured incorrectly while the tunnel is active.
Read the client’s exact mode before enabling the feature. Some clients block all internet traffic outside the tunnel. Others protect only specified applications, or apply the block after a connection has been established. Test the behavior by connecting the VPN, opening a normal webpage, and then using the client’s disconnect or network-switch behavior. If traffic stops as expected, confirm that reconnecting restores access. Keep a recovery path available, because a strict block can look like an internet outage when the VPN service or local network is unavailable.
Rule-based routing requires the same care. Direct rules for local printers, banking applications, corporate systems, or regional services can be useful, but every bypass becomes a separate path to evaluate. A DNS query from a direct application may follow the local network even when the browser is tunneled. For a privacy audit, begin with global routing, complete the tests, and add exceptions one by one. Record why each exception exists so that an old rule does not remain indefinitely.
Protocols also influence how the tunnel behaves, but no protocol alone guarantees privacy. WireGuard is a modern VPN protocol with a compact design and fast connection setup. OpenVPN remains widely supported and can operate over different transports. Shadowsocks is a proxy protocol rather than a complete VPN in the strict sense, while VMess and Trojan are proxy-oriented protocols commonly used by compatible clients. Hysteria2 uses a QUIC-based transport approach. The correct choice depends on the official client, network conditions, routing requirements, and the capabilities of your chosen compatible client.
How to review no-log claims
“No logs” is a broad marketing phrase, so look for a precise explanation of what is collected, why it is collected, how long it is retained, and whether it is linked to an account. A service may avoid storing browsing destinations while still retaining operational information such as connection timestamps, error reports, aggregate bandwidth, or account and payment records. Those categories are not identical, and a serious privacy review should not collapse them into one sentence.
Start with the privacy policy, terms, and application permissions. Check whether diagnostic reports are optional, whether crash logs can contain addresses or configuration details, and whether the client sends telemetry by default. Review the account model as well. SQVPN registration requires a username and password without an email address, but users should still understand that payment records, support conversations, and information they voluntarily submit can create account-level identifiers.
Look for consistency between the policy and the product. If the client offers connection history, usage charts, device lists, or detailed activity records, determine whether those records are stored locally, stored in the account, or used only for a temporary session. A policy that says “we do not monitor activity” does not necessarily mean that every operational record is discarded immediately. Clear definitions are more useful than absolute wording.
Independent audits, transparency reports, and a history of responding to legal or security requests can provide additional context, but they are not permanent guarantees. An audit may cover a particular date, infrastructure scope, or set of controls. Read what was actually examined and whether the report addresses logging, application code, infrastructure, or only a narrow process. No-log claims reduce one category of risk; they do not prevent DNS mistakes on your device or identifying activity at a destination service.
Reduce privacy risks on public Wi-Fi
Public Wi-Fi creates several risks at once: a hostile or misconfigured access point, weak network isolation, captive-portal manipulation, accidental file sharing, and connection changes that interrupt a VPN tunnel. A VPN can encrypt traffic inside its tunnel, but it cannot make a fake login page legitimate, protect a compromised device, or stop you from submitting credentials to an attacker-controlled website.
Before connecting, disable automatic joining for unfamiliar networks and confirm the network name through an independent source when possible. Keep the operating system, browser, and VPN client updated. Turn off local sharing features that are not needed, and avoid accepting unexpected certificates, configuration profiles, or browser extensions. Use HTTPS and verify the destination domain before entering passwords or payment information.
Connect the VPN before opening sensitive services, and enable Kill Switch if you need protection against brief tunnel interruptions. After the network changes from a captive portal to normal access, reconnect and repeat a basic IP and DNS check. Captive portals often require temporary direct access before the VPN can establish, so follow the client’s documented workflow rather than bypassing security warnings. When finished, forget the network if you do not plan to use it again.
- ✅ Disable automatic connection to unfamiliar public networks.
- ✅ Use the VPN with Kill Switch enabled when an interruption would expose sensitive traffic.
- ✅ Recheck the tunnel after captive-portal login, sleep, or switching between Wi-Fi and mobile data.
- ✅ Keep sharing, discovery, and unnecessary wireless features disabled on untrusted networks.
- ❌ Do not trust a Wi-Fi network merely because its name resembles a hotel, airport, or café.
- ❌ Do not enter credentials into a page reached through a certificate warning or suspicious redirect.
FAQ: DNS leak and VPN privacy checks
Is every DNS resolver shown by a test a leak?
No. A resolver may be operated by the VPN provider, a contracted network, or a public DNS service selected by the client. The important questions are whether the query used the VPN path, whether the resolver matches the client’s documented behavior, and whether your local provider appears unexpectedly. Compare connected and disconnected results and review the resolver organization rather than relying on a simple pass or fail label.
Does Kill Switch automatically fix DNS leaks?
Not necessarily. Kill Switch is primarily an outage and routing control. It can block traffic when the tunnel disappears, but it may not correct DNS requests that use the wrong resolver while the tunnel remains connected. Enable both the client’s leak-protection options and Kill Switch when available, then test DNS during normal connection, reconnect, and network-change scenarios.
Should I manually change my DNS server?
Only after identifying the cause and understanding the client’s design. Manually selecting a public resolver can change who receives your DNS requests, but it does not automatically force those requests through the VPN. It can also conflict with system profiles, encrypted DNS, split tunneling, or local network requirements. Prefer the official client’s documented settings and verify the result after every change.
Does a VPN make me anonymous?
No. It can reduce exposure of your local IP address and protect traffic between your device and the VPN entry point, but websites can still identify accounts, cookies, browser characteristics, payment activity, and information you provide directly. A VPN should be treated as one privacy layer alongside secure device settings, careful browser permissions, strong authentication, and sensible account practices.
A reliable privacy check is repeatable rather than dramatic: establish a disconnected baseline, connect the VPN, inspect IP and DNS behavior, test IPv6 and WebRTC separately, verify Kill Switch behavior, and review every bypass rule. If the results match the client’s documented design, keep records of the settings and test again after major operating-system, browser, or network changes. This approach reduces avoidable leaks without confusing privacy improvements with a promise of perfect anonymity.