Коротко: Утечка DNS — это когда ваши DNS-запросы (список сайтов, которые вы открываете) идут мимо VPN-туннеля напрямую к провайдеру, хотя IP-адрес при этом скрыт. Чтобы её устранить, нужен VPN, который перехватывает весь DNS-трафик, отключает IPv6- и WebRTC-утечки и держит kill switch. Проверить себя можно за минуту на сайтах вроде dnsleaktest.com и browserleaks.com: включаете VPN, запускаете расширенный тест и сверяете, чей резолвер отвечает. Если в результатах ваш провайдер, а не VPN, — утечка есть, и ниже разобрано, как её закрыть на любой платформе.
Что такое DNS и как работает разрешение имён
DNS (Domain Name System) — это «телефонная книга» интернета. Когда вы вводите limpvpn.com, устройство сначала спрашивает DNS-резолвер: «какой IP-адрес у этого домена?» — и только потом подключается к сайту. Проблема в том, что этот запрос обычно идёт открытым текстом, и тот, кто его обрабатывает, видит каждый домен, который вы открываете.
Чтобы понять, где именно происходит утечка, полезно представлять путь обычного DNS-запроса. Он короткий, но проходит через несколько узлов, и на каждом из них кто-то видит, какой домен вы запросили.
Рекурсивный и авторитетный резолвер
Ваше устройство почти никогда не общается напрямую с серверами, которые «знают» адрес домена. Сначала запрос идёт на рекурсивный резолвер — обычно это сервер вашего провайдера или публичный резолвер вроде 8.8.8.8. Именно он берёт на себя всю работу: спрашивает корневые серверы, серверы доменной зоны и, наконец, авторитетный сервер, который и хранит запись об IP домена.
Ключевой момент для приватности: рекурсивный резолвер видит абсолютно все ваши запросы. Если этот резолвер принадлежит провайдеру, то именно провайдер получает полный список открываемых вами доменов. Цель VPN — перенаправить этот шаг в зашифрованный туннель, чтобы рекурсивным резолвером стал сервер VPN, а не провайдера.
Открытый текст и порт 53
Классический DNS работает по UDP (реже TCP) на порту 53 и не шифруется. Это значит, что любой узел на пути запроса — провайдер, владелец публичного Wi-Fi, оператор магистрали — может прочитать имя домена в чистом виде. Именно эта особенность делает DNS таким удобным каналом для слежки и таким уязвимым к утечкам: даже если ваш HTTPS-трафик зашифрован, сам факт «спросил адрес такого-то домена» виден.
- Резолвер — сервер, который превращает доменное имя в IP-адрес; именно он видит ваш список сайтов.
- DNS-запрос — обращение к резолверу перед каждым новым подключением к домену.
- Порт 53 — стандартный порт классического DNS; трафик по нему идёт открытым текстом.
- Провайдер (ISP) — по умолчанию ваш DNS-резолвер принадлежит провайдеру, поэтому утечка ведёт прямо к нему.
- Туннель VPN — шифрованный канал; при правильной настройке DNS-запросы должны идти только внутри него.
- Суть утечки — скрытый IP не помогает, если домены всё равно «протекают» наружу.
Что такое утечка DNS и почему она опасна
Утечка DNS происходит, когда вы подключены к VPN, но DNS-запросы всё равно уходят к резолверу вашего интернет-провайдера, а не через зашифрованный туннель. В результате IP-адрес скрыт, а история посещённых доменов — нет. Снаружи это выглядит парадоксально: индикатор VPN горит зелёным, ваш публичный IP принадлежит другой стране, но провайдер по-прежнему ведёт полный лог ваших доменов.
Может показаться, что «ну видит провайдер домены — и что такого». Но именно список доменов — это самая показательная часть вашего цифрового профиля. По одним только доменам, без содержимого страниц, легко восстановить ваши интересы, привычки, расписание и даже чувствительные темы — здоровье, финансы, политические взгляды.
- История посещений — провайдер строит профиль интересов: какие сервисы, форумы, медицинские или финансовые сайты вы открываете.
- Логирование и хранение — во многих странах операторы обязаны хранить метаданные, и DNS-логи входят в этот объём.
- Тайминг и частота — даже без содержимого видно, когда и как часто вы заходите на конкретные ресурсы.
- Продажа данных — обезличенные (на словах) DNS-логи иногда становятся товаром для рекламных брокеров.
- Обход самой цели VPN — вы платите за приватность, но утечка сводит её к нулю на уровне метаданных.
Как именно провайдер собирает эти данные и зачем от него закрываться, разобрано в статье как VPN защищает от слежки провайдера. А базовая диагностика, которая показывает, действительно ли туннель работает целиком, описана в материале как проверить, что VPN работает.
Почему DNS утекает даже с включённым VPN
Многие уверены: «включил VPN — значит, защищён полностью». На деле есть несколько мест, где DNS-трафик умудряется обойти туннель, особенно при неаккуратной настройке клиента. Понимание этих механизмов — половина решения, потому что почти каждая утечка относится к одной из типовых причин.
- Системный резолвер ОС — Windows может отправлять параллельные DNS-запросы по всем сетевым адаптерам сразу (smart multi-homed name resolution), и часть уходит мимо VPN.
- IPv6 — если VPN туннелирует только IPv4, а у провайдера включён IPv6, то DNS и трафик по IPv6 утекают напрямую.
- WebRTC — технология в браузере для звонков и видеосвязи раскрывает реальный локальный и публичный IP в обход VPN, даже без отдельного DNS-запроса.
- Прозрачный DNS (transparent DNS proxy) — некоторые провайдеры перехватывают любой DNS-трафик на порту 53 и подменяют ответы своим резолвером, что бы вы ни прописали в настройках.
- Кривой VPN-клиент — слабое приложение не навязывает собственные DNS-серверы и оставляет системные, доставшиеся от провайдера.
- DNS-over-HTTPS в браузере — Chrome или Firefox могут использовать собственный шифрованный резолвер в обход системных настроек и туннеля VPN.
Важно понимать, что эти причины не исключают друг друга: на одном устройстве может одновременно работать и multi-homed resolution в Windows, и активный IPv6 от провайдера. Поэтому диагностику лучше вести по очереди, отключая по одному фактору и повторяя тест.
Типы утечек: причина и способ устранения
Чтобы не путаться, удобно держать перед глазами короткую сводку по основным типам утечек. Все они приводят к одному результату — провайдер или сторонний наблюдатель видит то, что должно было остаться внутри туннеля, — но причины и лечение у них разные.
| Тип утечки | Причина | Как починить |
|---|---|---|
| Утечка DNS | Системные DNS провайдера остаются активными, клиент не навязывает свои резолверы | VPN с принудительным DNS в туннеле; убрать статические DNS на адаптере |
| Утечка IPv6 | VPN туннелирует только IPv4, а провайдер раздаёт IPv6 | Туннелировать IPv6 в VPN или отключить IPv6 в настройках сети |
| Утечка WebRTC | Браузер раскрывает реальный IP через peer-to-peer API | Отключить WebRTC флагом или расширением; использовать клиент с защитой |
| Прозрачный DNS-прокси | Провайдер перехватывает порт 53 и подменяет ответы | Шифрование DNS внутри туннеля (DoH/DoT) поверх VPN |
| Multi-homed резолюция Windows | ОС опрашивает резолверы на всех адаптерах параллельно | Клиент отключает smart multi-homed resolution на время сессии |
Эта таблица — навигатор: определив по тесту, какой именно адрес или резолвер «протекает», вы сразу видите, в какую сторону копать. Дальше разберём каждый случай подробнее.
DNS-over-HTTPS и DNS-over-TLS: шифрованный DNS
Классический DNS открыт, и индустрия давно ищет, как его закрыть. Два главных ответа — DNS-over-HTTPS (DoH) и DNS-over-TLS (DoT). Оба шифруют сам DNS-запрос, чтобы провайдер не мог его прочитать или подменить. Но с VPN они взаимодействуют не всегда очевидно.
Чем отличаются DoH и DoT
DNS-over-TLS заворачивает DNS в TLS на отдельном порту 853 — провайдер видит, что вы используете шифрованный DNS, но не видит содержимого запросов. DNS-over-HTTPS прячет запросы внутри обычного HTTPS-трафика на порту 443, поэтому со стороны он почти неотличим от обычного веб-сёрфинга. Для приватности DoH выглядит привлекательнее, потому что его сложнее заблокировать или выделить.
Как шифрованный DNS взаимодействует с VPN
Здесь кроется тонкость. Если браузер использует собственный DoH-резолвер (например, Chrome с включённым «Secure DNS»), он может отправлять запросы мимо туннеля VPN — прямо к Google или Cloudflare, минуя DNS-серверы вашего VPN. Формально это шифрованный DNS, но запросы всё равно идут не туда, куда вы рассчитывали. Поэтому при диагностике утечек DoH в браузере на время теста лучше отключать.
Правильная схема такая: VPN сам гонит весь DNS через туннель к своим резолверам, а уже эти резолверы при желании могут общаться с авторитетными серверами по шифрованным протоколам. Тогда и провайдер ничего не видит, и запросы не утекают мимо туннеля. Если же DoH настроен в обход VPN, вы получаете шифрование, но теряете контроль над маршрутом.
- DoH (порт 443) — DNS прячется в HTTPS, неотличим от веб-трафика, трудно заблокировать.
- DoT (порт 853) — DNS в TLS на отдельном порту, виден как «шифрованный DNS».
- Риск с VPN — браузерный DoH может слать запросы мимо туннеля к стороннему резолверу.
- Правильная схема — DNS форсится в туннель VPN, шифрование — уже на стороне резолвера VPN.
- На время теста — отключайте Secure DNS в браузере, чтобы видеть чистую картину.
Как проверить утечку DNS, IP и WebRTC
Проверка занимает буквально пару минут и не требует никаких программ — всё делается в браузере. Главное — выполнять её при включённом VPN, иначе вы просто увидите данные провайдера. Делайте проверки по порядку: сначала IP, потом DNS, потом WebRTC и IPv6 — так проще понять, какой именно слой защиты не сработал.
- Проверка IP — откройте сервис вроде whatismyipaddress.com и убедитесь, что показан IP и страна VPN-сервера, а не ваши настоящие.
- Проверка DNS — на dnsleaktest.com запустите расширенный тест (Extended test) и посмотрите, какие резолверы отвечают.
- Проверка WebRTC — на browserleaks.com/webrtc убедитесь, что в полях Public IP нет вашего реального адреса.
- Сверка владельца — в результатах DNS-теста имя организации (ISP) должно совпадать с VPN-провайдером, а не с вашим оператором связи.
- Повтор без VPN — для контраста посмотрите те же тесты с выключенным VPN, чтобы понять, как выглядит «протёкший» результат.
- Тест IPv6 — на test-ipv6.com проверьте, не отвечает ли ваш реальный IPv6-адрес в обход туннеля.
Как читать результаты dnsleaktest.com
Результат расширенного теста — это таблица серверов, которые ответили на ваши запросы. У каждого указан IP, владелец (ISP/Organization) и страна. Здоровая картина: все строки указывают на VPN-провайдера или его DNS-партнёра, страна совпадает со страной VPN-сервера, и нигде нет имени вашего домашнего оператора связи.
Тревожные признаки: в списке появляется имя вашего реального провайдера, ваша домашняя страна или город, либо публичный резолвер (Google, Cloudflare), который вы не настраивали через VPN. Любая такая строка означает, что часть запросов ушла мимо туннеля. Один-два «чужих» сервера — это уже утечка, не нужно ждать, пока «протечёт» весь список.
Сколько серверов — это нормально
Количество строк само по себе ни о чём не говорит: VPN-провайдеры часто используют пул из нескольких DNS-серверов, и в результатах может оказаться три-четыре адреса одного владельца. Это нормально. Смотреть нужно не на число, а на владельца и страну каждой строки. Главный вопрос всегда один: есть ли здесь хоть один сервер, который относится к вашему провайдеру, а не к VPN.
Утечка IPv6 в деталях
IPv6 — частая и недооценённая причина утечек. Многие VPN исторически проектировались под IPv4, и если ваш провайдер раздаёт IPv6-адрес, то трафик и DNS по IPv6 могут уходить напрямую, в то время как IPv4 аккуратно идёт через туннель. Снаружи это выглядит как частичная утечка: IPv4 чист, а IPv6 выдаёт ваш реальный адрес.
Проблема в том, что современные сайты всё чаще доступны по IPv6, и операционная система предпочитает его IPv4, когда оба доступны. Значит, при «дырявом» IPv6 утекать будет именно основной трафик, а не редкие запросы. Поэтому тест на test-ipv6.com при включённом VPN — обязательный шаг.
- Туннелирование IPv6 — лучший вариант: VPN проводит IPv6 через туннель так же, как IPv4.
- Блокировка IPv6 — приемлемый вариант: клиент блокирует IPv6 на время сессии, чтобы он не утёк.
- Отключение в ОС — ручной вариант: выключить IPv6 на сетевом адаптере, если VPN его не покрывает.
- IPv6 на роутере — домашний роутер может раздавать IPv6 независимо; иногда проще выключить его там.
- Проверка — после правок повторите test-ipv6.com и убедитесь, что реальный IPv6 не отвечает.
Утечка WebRTC в деталях
WebRTC — это технология реального времени в браузере для звонков, видеосвязи и обмена файлами без плагинов. Чтобы установить прямое соединение между двумя браузерами, WebRTC должен узнать ваш реальный IP-адрес — и делает это через механизм ICE/STUN, который иногда обходит VPN. В результате веб-страница может на JavaScript получить ваш настоящий локальный и публичный IP, даже когда туннель работает.
Важно: WebRTC-утечка — это утечка не DNS, а IP-адреса. Отдельного DNS-запроса при ней не возникает, поэтому dnsleaktest.com её не покажет. Проверять WebRTC нужно отдельно — на browserleaks.com/webrtc, глядя на поля Public IP. Если там виден ваш реальный адрес, защита неполная.
- Флаг в браузере — в Firefox media.peerconnection.enabled=false полностью отключает WebRTC.
- Расширение — для Chrome есть расширения, ограничивающие раскрытие локального IP.
- Защита на клиенте — некоторые VPN перехватывают WebRTC-запросы на сетевом уровне.
- Проверка после правок — повторите browserleaks.com/webrtc и убедитесь, что реальный IP не виден.
- Компромисс — полное отключение WebRTC ломает звонки в браузере; взвесьте, что вам важнее.
Как устранить утечку DNS на разных платформах
Хорошая новость: почти все утечки лечатся правильной настройкой VPN и парой системных переключателей. Но конкретные шаги зависят от платформы, поэтому ниже разобраны самые частые сценарии — Windows, macOS, Android, iOS и роутер.
Windows
Главный враг на Windows — smart multi-homed name resolution: ОС опрашивает несколько резолверов параллельно, и часть запросов уходит мимо VPN. Хороший клиент отключает эту функцию сам. Дополнительно стоит проверить, что на сетевом адаптере не прописаны статические DNS (вроде 8.8.8.8), которые перебивают настройки VPN, и при необходимости выключить IPv6, если клиент его не туннелирует.
macOS
На macOS типичная причина утечки — DNS, заданные вручную в настройках сети или унаследованные от профиля Wi-Fi. Убедитесь, что VPN-клиент сам управляет DNS, а не оставляет системные. Как и на Windows, проверьте состояние IPv6 и отключите его на интерфейсе, если туннель IPv6 не покрывает.
Android и iOS
На мобильных платформах настроек меньше, и большую часть контроля берёт на себя приложение VPN. Главные риски — функция «Private DNS» в Android, которая может слать запросы стороннему резолверу мимо туннеля, и системные звонки/сервисы, использующие свои DNS. На iOS убедитесь, что профиль VPN активен постоянно, а не только для отдельных приложений. На обеих платформах основной способ защиты — выбрать клиент, который форсит DNS в туннель и закрывает IPv6.
Роутер
Если VPN поднят на роутере, туннель работает на уровне сети и DNS всех домашних устройств идёт через VPN. Но если в роутере прописан DNS провайдера, утечка возникает сразу для всей сети. Проверьте, какие DNS-серверы указаны в настройках роутера, и выключите IPv6 на самом роутере, если туннель его не покрывает. Прозрачный DNS-прокси провайдера на этом уровне особенно коварен — обойти его помогает только шифрование DNS внутри туннеля.
Общий принцип для всех платформ один: клиент должен принудительно гнать все DNS-запросы через туннель к своим резолверам, держать kill switch и закрывать IPv6 и WebRTC. После любых правок обязательно повторяйте тест.
Прозрачный DNS-прокси провайдера: самый упрямый случай
Отдельно стоит разобрать прозрачный DNS-прокси, потому что это единственная утечка, с которой не справляются обычные настройки. Идея провайдера проста: перехватывать весь трафик на порту 53 независимо от того, какой DNS-сервер вы прописали, и отвечать своим резолвером. Вы указываете 8.8.8.8 — а отвечает всё равно сервер провайдера, который тихо подменяет ответы и логирует домены.
Такая схема используется не только для слежки, но и для блокировок: подменяя DNS-ответ, провайдер перенаправляет вас на страницу-заглушку вместо запрошенного сайта. Обычная смена DNS-сервера здесь бесполезна — перехват происходит на уровне сети, до того как ваш запрос дойдёт до выбранного резолвера.
Единственное надёжное лекарство — шифрование DNS внутри туннеля. Когда DNS-запрос упакован в зашифрованный VPN-туннель (а внутри ещё и в DoH/DoT), провайдер физически не может его прочитать или подменить: он видит лишь поток шифрованных данных к VPN-серверу. Поэтому против прозрачного прокси работает именно VPN с принудительным DNS, а не ручная правка адресов резолвера.
- Перехват на порту 53 — провайдер ловит любой открытый DNS, что бы вы ни прописали.
- Подмена ответов — вместо нужного IP вы можете получить заглушку или чужой адрес.
- Смена DNS не помогает — перехват происходит до того, как запрос дойдёт до вашего резолвера.
- Решение — туннель — DNS внутри зашифрованного VPN недоступен для перехвата и подмены.
- Признак в тесте — отвечает резолвер провайдера, хотя вы его не настраивали.
DNS-утечка на мобильном интернете и в публичном Wi-Fi
Сценарий подключения тоже влияет на риск утечки. Домашний проводной интернет, мобильная сеть оператора и публичный Wi-Fi в кафе ведут себя по-разному, и понимать разницу полезно.
В публичном Wi-Fi наблюдатель — это уже не только провайдер, но и владелец точки доступа и любой, кто сидит в той же сети. Открытый DNS здесь особенно опасен: домены видны всем, кто слушает эфир. Именно поэтому проверять утечку стоит в первую очередь на чужих сетях, а не только дома.
На мобильном интернете типичная ловушка — IPv6: операторы всё чаще раздают IPv6-адреса по умолчанию, и если VPN его не туннелирует, утекает основной трафик. Плюс системные сервисы телефона иногда используют собственные DNS. Поэтому на смартфоне особенно важен клиент, который форсит весь DNS в туннель и держит постоянное соединение, а не включается лишь для отдельных приложений.
- Домашняя сеть — наблюдатель один (провайдер), но утечка ведёт прямо к нему и логируется.
- Публичный Wi-Fi — наблюдателей много; открытый DNS виден владельцу точки и соседям по сети.
- Мобильный интернет — частый IPv6 по умолчанию и системные DNS телефона повышают риск утечки.
- Always-on VPN — на смартфоне держите туннель постоянным, чтобы запросы не утекали в моменты переключения сетей.
- Проверка на месте — тестируйте утечку именно в той сети, где волнуетесь за приватность.
Где искать причину, если DNS всё ещё течёт
Если тесты показывают утечку даже после настройки, причина почти всегда в одном из нескольких мест. Полезно проверять их по очереди, а не менять всё сразу — иначе вы не поймёте, что именно помогло.
- Браузер — встроенный в Chrome или Firefox DNS-over-HTTPS может использовать свой резолвер в обход VPN; временно отключите эту опцию для чистоты теста.
- Операционная система — в Windows источником чаще всего служит multi-homed resolution и оставшиеся системные DNS на физическом адаптере.
- Сетевой адаптер — статически прописанные DNS-серверы (например, 8.8.8.8) могут перебивать настройки VPN.
- Антивирус и фаервол — некоторые «защитные» модули подменяют DNS своим фильтрующим резолвером.
- Сам VPN-клиент — если приложение давно не обновлялось, обновление часто закрывает известные утечки.
Если после правок DNS туннель вовсе перестал подниматься, поможет отдельный разбор VPN не подключается: решение проблем. А о том, как kill switch не даёт запросам утечь в момент обрыва, читайте в материале что такое kill switch в VPN.
Частые ошибки при проверке и устранении
Многие «утечки» на самом деле — ошибки самой проверки. Прежде чем менять настройки, убедитесь, что вы тестируете правильно.
- Тест без VPN — самая частая ошибка: тест запускают с выключенным туннелем и пугаются «утечки», которой нет.
- Кэш браузера и DNS — старые записи в кэше могут показать прежний резолвер; очистите кэш или проверьте в режиме инкогнито.
- Активный DoH в браузере — Secure DNS в Chrome шлёт запросы мимо туннеля и портит результат теста.
- Несколько VPN/прокси сразу — наложение туннелей и расширений-прокси даёт противоречивые результаты; оставьте что-то одно.
- Проверка только IPv4 — забыли про IPv6 и WebRTC, а именно они часто и текут.
- Старая версия клиента — известная утечка может быть уже закрыта в обновлении, которое вы не установили.
Чек-лист: проверить и устранить утечку DNS
Соберём всё в один понятный порядок действий. Пройдите пункты сверху вниз — это и есть полный цикл «проверил → починил → перепроверил».
- Шаг 1. Включите VPN и убедитесь, что туннель действительно поднят (индикатор активен).
- Шаг 2. Проверьте IP на whatismyipaddress.com — должна быть страна VPN-сервера.
- Шаг 3. Запустите Extended test на dnsleaktest.com и сверьте владельца резолверов — нигде не должно быть вашего провайдера.
- Шаг 4. Проверьте WebRTC на browserleaks.com/webrtc — в полях Public IP не должно быть вашего реального адреса.
- Шаг 5. Проверьте IPv6 на test-ipv6.com — реальный IPv6 не должен отвечать в обход туннеля.
- Шаг 6. Нашли утечку — отключите Secure DNS/DoH в браузере, уберите статические DNS на адаптере, выключите или затуннелируйте IPv6.
- Шаг 7. Убедитесь, что включён kill switch и используется современный протокол вроде WireGuard.
- Шаг 8. Перезапустите VPN и повторите все тесты — убедитесь, что утечек больше нет.
Почему хороший VPN предотвращает утечку DNS
Качественный VPN-сервис закрывает все перечисленные дыры на уровне клиента, чтобы вам не приходилось вручную править системные настройки. В идеале вы вообще не должны знать слова «multi-homed resolution» — приложение делает всё само.
- Принудительный DNS в туннеле — все запросы идут только к DNS-серверам VPN, провайдерские игнорируются.
- Защита от IPv6-утечки — клиент либо туннелирует IPv6, либо аккуратно блокирует его на время сессии.
- Kill switch по умолчанию — при обрыве туннеля трафик и DNS-запросы блокируются, а не уходят напрямую.
- Строгая политика no-logs — даже свои DNS-запросы сервис не хранит, поэтому метаданные негде утечь.
- Современный протокол — WireGuard с грамотной маршрутизацией минимизирует число мест, где запрос может «проскочить» наружу.
Подробнее о самом протоколе и о том, почему он аккуратнее обращается с DNS, — в статье протокол WireGuard простыми словами.
Почему стоит попробовать LiMP VPN
LiMP VPN построен на протоколе WireGuard и по умолчанию гонит весь DNS-трафик только через зашифрованный туннель к собственным резолверам, не оставляя ни одного запроса провайдеру. Встроенный kill switch блокирует трафик при обрыве соединения, а защита от IPv6-утечек включена сразу — без ручной правки системных настроек. Тариф простой: 100 ₽ в месяц за защиту на iOS и Android — посмотреть условия можно на странице тарифов.
- Собственный DNS в туннеле — провайдер не видит ни одного открываемого вами домена.
- Kill switch — при обрыве туннеля DNS-запросы не утекают наружу.
- Строгий no-logs — сервис не хранит ваши DNS-запросы и историю подключений.
- iOS и Android — единая защита на всех устройствах за 100 ₽ в месяц.
- WireGuard — быстрый современный протокол с аккуратной маршрутизацией DNS.
Частые вопросы
Что такое утечка DNS простыми словами?
Это ситуация, когда ваш IP-адрес скрыт VPN, но DNS-запросы (список открываемых доменов) всё равно уходят к резолверу провайдера. В итоге провайдер видит, какие сайты вы посещаете, хотя вы думаете, что защищены.
Как проверить утечку DNS бесплатно?
Включите VPN и откройте dnsleaktest.com, запустите Extended test. Если в результатах указан ваш интернет-провайдер, а не VPN-сервис, — есть утечка. Дополнительно проверьте IP и WebRTC на browserleaks.com.
Может ли DNS утекать через WebRTC?
Через WebRTC утекает не столько DNS, сколько ваш реальный IP-адрес: браузер раскрывает его для звонков и видеосвязи в обход VPN. Это отдельная утечка, и проверять её нужно вместе с DNS на странице browserleaks.com/webrtc.
Нужно ли отключать IPv6, чтобы избежать утечки?
Если ваш VPN не туннелирует IPv6, то да — иначе трафик и DNS по IPv6 уходят мимо туннеля напрямую к провайдеру. Хорошие клиенты делают это автоматически, но при ручной настройке IPv6 стоит выключить.
Почему DNS утекает именно на Windows?
Виновата функция smart multi-homed name resolution: Windows опрашивает DNS-серверы по всем адаптерам параллельно, и часть запросов уходит мимо VPN. Качественный VPN-клиент отключает эту функцию на время сессии.
Помогает ли kill switch от утечки DNS?
Да, косвенно. Kill switch блокирует весь трафик в момент обрыва туннеля, не давая запросам проскользнуть к провайдеру. Но от постоянной утечки при работающем туннеле спасает именно принудительный DNS внутри VPN.
Защищает ли DNS-over-HTTPS от утечки сам по себе?
Не всегда. DoH шифрует запрос, но если браузер настроен на сторонний DoH-резолвер в обход VPN, запросы всё равно идут мимо туннеля к чужому серверу. Надёжнее, когда DNS принудительно идёт в туннель VPN, а шифрование происходит уже на стороне его резолверов.
Заключение
Утечка DNS — коварная проблема: IP скрыт, индикатор VPN горит, а провайдер всё равно видит список ваших сайтов. К счастью, проверяется она за минуту, а лечится правильным VPN с принудительным DNS, kill switch и защитой от IPv6 и WebRTC. Проверьте себя прямо сейчас на dnsleaktest.com и browserleaks.com — и убедитесь, что приватность, за которую вы платите, действительно работает. LiMP VPN закрывает все эти дыры по умолчанию, чтобы вам не приходилось думать о настройках.