DNS leak in VPN: how to check and fix it

You turned on the VPN, but the provider still sees that you are visiting YouTube or Instagram. Sounds like paranoia — until you check. A DNS leak is one of the most common reasons why a VPN offers less protection than it seems. If you are experiencing unstable access to blocked sites or just want to ensure your safety —VPN DNS leak: solution there is a solution to this problem, and it’s simpler than you think.

What is a DNS leak and why is it dangerous specifically in Russia

DNS is the phone book of the internet. When you type instagram.com, your device first asks the DNS server: “what is the IP of this domain?”. Only then does the connection occur. The problem is that the VPN encrypts the connection itself, but the DNS request can bypass the tunnel — going straight to your provider's server.

In summary: the content is encrypted, but the fact that you accessed the domain telegram.org or youtube.com is not.

How DNS requests work with VPN enabled

Ideally, it looks like this: device → encrypted VPN tunnel → VPN provider's DNS server → website. The request goes through the tunnel, and the provider in Russia sees only the encrypted stream to the IP of the VPN server and nothing else.

But if something goes wrong — the operating system sends the DNS request directly, before the tunnel has a chance to intercept it. Or in parallel with the tunnel. This is the leak.

Why DPI and the provider see domains even through VPN

Russian providers actively use DPI (Deep Packet Inspection) — a technology for deep packet inspection. The TSPU, which Roskomnadzor has mandated providers to install, analyzes traffic specifically at the level of DNS requests among other things.

If your DNS request goes in clear text to the provider's server, the DPI system sees the domain. Then comes the blocking or throttling, that very slowdown of YouTube that many people use VPNs to avoid. It creates a vicious circle: the VPN is there, but the slowdown hasn’t gone away.

What DNS leak threatens when bypassing Roskomnadzor's blocks

The provider receives a list of domains you are accessing. This is enough to apply blocking even with an active VPN. The traffic itself is encrypted — they don’t know what exactly you watched on YouTube, but they know you visited it, and they can slow down or block the connection at the DNS response level.

For those who use VPN specifically to bypass blocks on Instagram, Facebook, TikTok, Twitter/X, or Telegram — a DNS leak effectively nullifies the protection.

How to check for a DNS leak in one minute

The check takes literally a minute. Turn on the VPN, open your browser, and follow the instructions below. No special knowledge is required.

Test on dnsleaktest.com and browserleaks.com

The simplest way is to go todnsleaktest.com with an active VPN connection. The site shows which DNS servers are processing your requests right now.browserleaks.com/dns works similarly — it has a bit more detail about the browser configuration.

Another option isipleak.net. It shows the IP address, DNS, and WebRTC on one page, which is convenient for a quick comprehensive check.

What is the difference between Standard and Extended tests

On dnsleaktest.com, there are two buttons: Standard test and Extended test. The Standard test makes about 6 requests, while the Extended test makes 36. The difference is important: during the Standard test, some leaks may not manifest because the OS manages to cache the requests or the load balancer accidentally sends them through the tunnel.

Always run the Extended test. It takes about 20 seconds, but the result is reliable.

How to read the result: which IPs and countries should be present

After the test, you will see a list of DNS servers with IP addresses and geolocation. If you connected to a VPN server in Germany — the list should contain German or neutral DNS servers from your VPN provider.

If a Russian IP or a server with your provider's name (for example, dns.mts.ru or something similar in geolocation) appears in the list — you have a leak. This is direct confirmation that DNS requests are bypassing the tunnel.

Additional check for WebRTC leak

WebRTC is a separate story. Browsers like Chrome and Firefox use it for video calls, and it can reveal your real IP even with an active VPN. You can check it atbrowserleaks.com/webrtc.

If you see your real Russian IP next to the VPN IP — you need to disable WebRTC in the browser. In Firefox, this is done through about:config → media.peerconnection.enabled → false. In Chrome, it's easier to install the uBlock Origin extension with the WebRTC blocking option enabled.

How to fix DNS leaks on different devices

There is no universal solution — each platform has its own specifics. Below are specific steps for each device.

Windows: adapter settings and the Block outside DNS parameter

In Windows, the problem is often related to the system continuing to send DNS requests through the physical network adapter alongside the VPN. There are two solutions.

First — if you have an OpenVPN client, add the lineblock-outside-dns to the config. This closes DNS outside the tunnel at the Windows Filtering Platform level. It works reliably, tested.

Second — manually specify DNS in the VPN adapter settings: Control Panel → Network Connections → VPN adapter → Properties → IPv4 → specify the VPN provider's DNS (usually indicated in the documentation). Also, in the settings of other adapters (Wi-Fi, Ethernet), remove automatic DNS so that the system does not refer to them in case of a tunnel failure.

Kill switch — mandatory. Most decent VPN clients (Mullvad, ProtonVPN, NvoVPN) have it in their settings. Without it, during a brief VPN disconnection, the system instantly switches to a direct connection, and DNS goes to the provider.

Android: Private DNS and the behavior of different VPN applications

Android 9+ added a system feature called Private DNS (DNS-over-TLS). It sounds like protection — but it often causes leaks. Private DNS operates at the system level and can bypass the VPN tunnel.

Check: Settings → Network → Advanced → Private DNS. If it is set to "Automatic" or a third-party address is specified — this is a potential leak when the VPN is active. When using a VPN application with its own DNS resolver (like most decent clients), it's better to switch Private DNS to "Off" or "Disabled."

Additionally: some Android applications like Psiphon or simple proxy clients only proxy HTTP traffic, but not DNS. The result is a classic leak. Use a full-fledged VPN client with "All traffic" mode.

iPhone/iOS: features of profiles and iCloud Private Relay

On iOS, VPN is usually configured through profiles (.mobileconfig) or through built-in clients. Most decent VPN applications on iOS handle DNS properly — they tunnel it through their server.

But there is one nuance:iCloud Private Relay. If you have an iCloud+ subscription, Private Relay may be enabled, and it will handle DNS independently of the VPN. When both are active, the results of the DNS test become unpredictable — you see either Apple servers or VPN servers.

Solution: when using a VPN, disable iCloud Private Relay. Settings → [your Apple ID] → iCloud → Private Relay → turn off. They solve similar tasks but interfere with each other.

macOS: manual DNS configuration and checking

On macOS, DNS is specified separately for each network interface. If the VPN creates a virtual interface (utun0 and similar), you need to ensure that the system DNS for Wi-Fi and Ethernet does not override it.

System Preferences → Network → select Wi-Fi → Advanced → DNS. If provider servers are specified there — replace them with your VPN service's DNS or temporarily leave it blank when the VPN is active. After making changes, restart the VPN and retest on dnsleaktest.com.

Router and Smart TV/Apple TV: DNS at the network level

Smart TV, Apple TV, PlayStation, Xbox — they do not have their own VPN clients. You cannot install an app on a Samsung TV. The only way to protect these devices is to configure VPN and DNS at the router level.

On routers with OpenWRT, DD-WRT, or Keenetic firmware (popular in Russia), you can set up a VPN client directly on the router and specify the VPN provider's DNS in the DHCP server settings. Then all devices on the network, including TVs and consoles, automatically use the protected DNS.

An important nuance: if you have double NAT (for example, provider's router + your router) — the DNS specified on the provider's router may override your settings. Make sure your router is operating in router mode, not bridge mode, and that it is the one distributing DHCP to the devices on the network.

Leak dependency on the protocol: WireGuard, OpenVPN, IKEv2, VLESS

The protocol matters — and not all handle DNS the same way. Let's break it down honestly, without marketing.

Why WireGuard and OpenVPN behave differently

OpenVPN when configured correctly (theblock-outside-dns parameter on Windows, the redirect-gateway def1 option in the config) tunnels all traffic including DNS. A tested option, it works predictably.

WireGuard is slightly different in architecture — it does not natively support block-outside-dns. But most WireGuard clients (Mullvad App, official WireGuard for Windows) implement this protection at the application level. In the WireGuard config, there is a parameterDNS = in the [Interface] section — if specified, the client uses the specified DNS and blocks the system one. If not specified — a leak is almost guaranteed.

IKEv2 normally tunnels DNS when using native clients on Windows and iOS. On Android, it's a bit more complicated — it depends on the implementation.

Shadowsocks and VLESS/XRay: DNS outside the main tunnel

This is where most articles are silent. Shadowsocks and VLESS/XRay are proxy protocols, not full-fledged VPNs. They bypass DPI and Roskomnadzor blocks excellently, especially when combined with obfuscation. But by default, they proxy application traffic (TCP/UDP), while DNS queries go directly through the system resolver.

If you are using clients like v2rayN, Nekobox, or sing-box with VLESS/XRay — you need to configure DNS rules separately. In sing-box, this is done in the dns section of the config: you specify the server (for example, 1.1.1.1 via proxy) and the DNS routing rules. Without this — a classic leak, even if all HTTP traffic goes through the proxy.

Amnezia and obfuscation: what it affects in the context of DNS

AmneziaVPN and other obfuscation tools (obfs4, Cloak, GoodbyeDPI) hide the signature of VPN traffic from DPI. This helps bypass the blocking of the VPN protocol itself, but does not solve the DNS leak problem.

Amnezia is built on top of WireGuard or OpenVPN — which means everything said about these protocols applies here as well. Obfuscation works at the transport layer, DNS is a separate layer. If the base protocol is configured correctly, DNS will go through the tunnel. If not — it will go around, and obfuscation won't help here.

What to choose if protection against leaks is important

For maximum DNS protection — classic VPN protocols with a properly configured client. WireGuard with a specified DNS in the config or OpenVPN with block-outside-dns — both work well. Some services, including NvoVPN, provide their own DNS inside the tunnel, eliminating the need to configure this manually.

If you are using VLESS/XRay — don't forget to configure DNS routing in sing-box or v2ray. It's not difficult, but requires one additional step in the config.

What DOES NOT work and common mistakes

Over the years, several persistent myths have accumulated. Here’s what really doesn’t work — and why.

Changing DNS to 8.8.8.8 does not close the leak

This is probably the most common advice on the internet. "Set Google DNS 8.8.8.8 or Cloudflare 1.1.1.1 — and there will be no leaks." This is incorrect.

Changing the DNS server only changeswho receives your request. But if the request goes outside the tunnel — it still passes through the provider's network in clear text, and DPI sees it. You just changed the recipient from dns.provider.ru to 8.8.8.8, but the route still goes through the provider. This is not a solution.

Browser extensions instead of a system VPN

Extensions like "VPN for Chrome" or "Proxy for Firefox" only protect the traffic of the browser itself. System DNS queries, requests from other applications, messengers — all of this goes around. The extension gives a false sense of protection.

The same applies to WebRTC blockers — they only close one specific leak in the browser, but do not affect the system DNS at all.

Disabled kill switch and connection drops

Kill switch is not an optional feature. It is a critically important element of protection. In the event of a brief VPN drop (network switch, unstable Wi-Fi signal, IP change), the operating system instantly switches to a direct connection. The DNS request goes to the provider — that's it, the leak is recorded.

The drop can last 2-3 seconds. Enough for the DNS request for the opened site to go directly. If your client has a kill switch — enable it. If the client does not provide a kill switch — look for another one. This is howDNS leak looks: solution at the settings level.

And one more underrated situation: a corporate DNS filter or parental control set on the device. Such tools often override the system DNS and work independently of the VPN. If there is an MDM profile or parental control application with its own DNS on the device — it will intercept requests regardless of VPN settings.

If you have dealt with the settings, launched the Extended test, and confirmed that the DNS servers belong to your VPN provider, not a Russian operator —DNS leak: solution found and the problem is closed. Check this periodically, especially after updating applications or the system.