Содержание статьи

Введение: почему прокси может быть идеальным, а вас всё равно видят

Представьте ситуацию. Вы купили качественный мобильный прокси, настроили антидетект-браузер, проверили IP на трёх разных сервисах — везде адрес сотового оператора в нужном регионе. Запускаете рекламный кабинет, прогреваете аккаунты, ведёте парсинг. А через несколько дней получаете блокировку с формулировкой о подозрительной активности. Знакомо? Одна из самых недооценённых причин таких историй — dns leak, то есть утечка DNS-запросов мимо прокси.

Парадокс в том, что IP-адрес при этом действительно подменён. Сайт видит трафик с мобильного оператора. Но перед каждым подключением ваш компьютер тихо спрашивает у своего провайдера: «где находится сервер такой-то?». И этот вопрос уходит напрямую, без участия прокси. В результате у стороны наблюдателя появляются две картинки, которые не сходятся: соединение идёт с мобильной сети одного региона, а имена разрешаются через резолвер домашнего интернет-провайдера совершенно другого города. Для антифрод-систем 2026 года такое расхождение — не мелочь, а один из самых надёжных сигналов.

По нашим наблюдениям за обращениями в поддержку, заметная доля жалоб вида «прокси не работает, гео определяется неверно, аккаунты летят без причины» при детальном разборе оказывается не проблемой прокси вообще. Это проблема DNS-слоя на стороне клиента. Причём людей, которые целенаправленно проверяют DNS перед началом работы, по-прежнему меньшинство — большинство ограничивается проверкой IP.

В этом руководстве мы разберём тему полностью. Вы узнаете, как устроено разрешение имён и в какой момент оно уходит мимо прокси. Поймёте, чем отличаются HTTP- и SOCKS-прокси с точки зрения DNS, почему одна буква в строке подключения решает всё, и как браузеры с включённым шифрованным DNS создают новую категорию утечек. Мы дадим четыре практических метода — диагностика, настройка клиентского софта, браузеры и антидетекты, системный уровень — каждый с пошаговыми инструкциями и чек-листами. Разберём типичные ошибки, кейсы с цифрами и ответим на сложные вопросы.

Важная граница: эта статья про DNS-слой. Утечки через WebRTC, отпечатки браузера, тайминги и прочие каналы деанонимизации — отдельные темы, которые разобраны в других материалах блога. Здесь мы сосредоточимся на одном, но фундаментальном канале, потому что без его понимания любая остальная настройка держится на песке.

Основы: как работает DNS и что такое dns leak

Телефонная книга интернета

Каждый раз, когда браузер или скрипт хочет подключиться к сайту, ему нужен не домен, а IP-адрес. Домен — это имя, понятное человеку. Адрес — координаты, понятные сети. Служба, которая переводит одно в другое, называется DNS (Domain Name System). Самая простая аналогия — телефонная книга: вы знаете имя, книга даёт номер. Только эта книга распределена по тысячам серверов и работает за миллисекунды.

Как выглядит разрешение имени на практике:

  1. Приложение вызывает системную функцию (в мире Unix это чаще всего getaddrinfo), передавая ей доменное имя.
  2. Операционная система проверяет локальный кеш и файл hosts.
  3. Если ответа нет, заглушка-резолвер (stub resolver) ОС отправляет запрос на адрес DNS-сервера, который прописан в сетевых настройках. Обычно это сервер вашего провайдера, выданный по DHCP, либо публичный резолвер, который вы указали вручную.
  4. Рекурсивный резолвер провайдера идёт по цепочке корневых серверов, серверов доменной зоны и авторитативных серверов домена, находит ответ и возвращает его вам.
  5. Приложение получает IP и только теперь устанавливает соединение.

Обратите внимание на порядок. Сначала DNS, потом соединение. Прокси — это инструмент, который вмешивается в соединение. А вот вмешается ли он в DNS — зависит от типа прокси, протокола и того, как именно приложение им пользуется.

Что именно называют утечкой

DNS leak — это ситуация, когда трафик приложения идёт через прокси, а запросы на разрешение имён — нет. Они уходят напрямую с вашего реального сетевого интерфейса на резолвер, который настроен в системе. Итог: сайт, к которому вы подключаетесь, видит IP прокси, но ваш провайдер и владелец резолвера видят список всех доменов, к которым вы обращались. А целевой сервис при определённых условиях может сопоставить, откуда пришло соединение и откуда пришёл DNS-запрос.

Почему это важно именно для пользователей мобильных прокси? Потому что вся ценность мобильного IP — в его правдоподобии. Адрес принадлежит сотовому оператору, за ним стоят тысячи реальных абонентов, он меняется, у него хорошая репутация. Но реальный абонент мобильной сети разрешает имена через DNS-серверы этого же оператора. Если ваш трафик выходит из мобильной сети, а имена резолвятся через кабельного провайдера в другом регионе, вы перестаёте быть похожим на реального абонента. Вы становитесь похожим на того, кто использует прокси. Собственно, так оно и есть — и вы сами об этом рассказали.

Три роли, которые видят вашу утечку

  • Ваш интернет-провайдер. Он видит запросы к своему резолверу и знает, какие домены вы посещаете, даже если само содержимое ушло через прокси.
  • Владелец резолвера. Если вы прописали публичный DNS, то полный список ваших доменов и ваш реальный IP видит его оператор.
  • Целевой сайт и его антифрод. Напрямую он DNS-запрос не получает, но у него есть косвенные каналы: география авторитативных серверов, механизм EDNS Client Subnet, CDN-маршрутизация и специальные тестовые домены, которые генерируются под конкретную сессию. Об этом подробно в следующем разделе.

Глубокое погружение: анатомия утечки DNS при работе через прокси

HTTP-прокси: почему обычно не течёт, но бывают исключения

При работе через HTTP-прокси браузер отправляет ему запрос, в котором домен указан текстом. Для незашифрованного HTTP это полный URL в первой строке запроса. Для HTTPS браузер посылает команду CONNECT с именем хоста и портом, и прокси сам разрешает это имя и устанавливает туннель. В обоих случаях клиенту не нужно знать IP целевого сервера. Разрешение делает прокси, на своей стороне, своими резолверами. В случае мобильного прокси — на стороне модема или телефона, через DNS-серверы оператора. Именно так и должно быть.

Откуда же берутся утечки с HTTP-прокси? Их источники косвенные:

  • PAC-скрипты. Файл автоконфигурации прокси может содержать функцию dnsResolve, которая резолвит домен локально, чтобы решить, отправлять ли запрос через прокси. Само решение принимается уже после локального DNS-запроса.
  • Предварительное разрешение имён. Некоторые приложения проверяют доступность хоста до подключения: пингуют, резолвят, а потом уже идут через прокси. Java-приложения с InetAddress, отдельные парсеры, плагины проверки ссылок.
  • Фоновые сервисы браузера. Предзагрузка страниц, DNS-prefetch, проверки безопасного просмотра и обновлений могут работать с собственными правилами и не всегда уважают настройки прокси.

SOCKS: одна буква между чистой сессией и утечкой

Здесь начинается самое интересное. Протокол SOCKS4 в оригинальной версии умеет передавать прокси только IP-адрес назначения. Это значит, что клиент обязан разрешить имя сам, до подключения. Утечка встроена в протокол. Расширение SOCKS4a добавило возможность передавать имя хоста. SOCKS5 поддерживает три типа адреса назначения: IPv4, IPv6 и доменное имя.

Казалось бы, SOCKS5 решает проблему. Но поддержка доменного имени в протоколе не означает, что клиент им воспользуется. Многие библиотеки и программы по умолчанию резолвят имя локально и отправляют прокси уже готовый IP. Протокол это разрешает — просто утечка происходит на шаг раньше.

Отсюда знаменитая буква h. В curl и в библиотеках, которые следуют его соглашению, схема socks5:// означает локальное разрешение имён, а socks5h:// — передачу имени хоста прокси-серверу для удалённого разрешения. Одна буква. Разница между чистой сессией, где всё, включая DNS, выходит из мобильной сети оператора, и сессией, в которой каждое имя сначала утекает к вашему провайдеру.

Почему прокси-серверу лучше резолвить самому

Здесь есть неочевидный момент, который многие упускают. Дело не только в приватности. Когда имя разрешает удалённая сторона мобильного прокси, DNS-ответ формируется с учётом местоположения оператора. Крупные сервисы используют CDN и гео-DNS: на один и тот же домен разным клиентам возвращаются разные IP, ближайшие к ним. Если резолвит ваш домашний провайдер, вы получите адрес узла CDN рядом с вашим реальным местоположением. А потом подключитесь к этому узлу через мобильный прокси из другого региона. Для сервиса это выглядит странно: клиент из мобильной сети региона А почему-то пришёл на узел, предназначенный для региона Б. Это и есть косвенный канал обнаружения dns leak, который не требует никакого доступа к вашим DNS-запросам.

EDNS Client Subnet: как резолвер раздаёт вашу подсеть

Механизм EDNS Client Subnet (ECS) придуман для того, чтобы публичные резолверы могли передавать авторитативным серверам часть адреса клиента — обычно первые 24 бита для IPv4. Так CDN понимает, откуда реальный пользователь, и выдаёт ближайший узел. Это удобно для скорости. Но с точки зрения утечек это означает, что при локальном резолвинге через публичный DNS с поддержкой ECS авторитативный сервер целевого домена получает подсеть вашего реального подключения. Не полный адрес, но достаточно, чтобы понять провайдера и город. А соединение потом приходит с мобильного IP. Две подсети, два оператора, один пользователь.

Шифрованный DNS: новая категория утечек

С 2020-х годов браузеры и операционные системы массово перешли на DNS over HTTPS (DoH) и DNS over TLS (DoT), а к 2026 году добавился и DNS over QUIC. Идея благая: провайдер больше не видит ваши запросы. Но для работы через прокси возник побочный эффект. Браузер с включённым «безопасным DNS» обращается к выбранному DoH-серверу собственным клиентом, и этот трафик далеко не всегда следует настройкам прокси. То есть имена разрешаются не у мобильного оператора, а у крупного публичного резолвера, причём с вашего реального IP. Шифрование спасает от провайдера, но не от расхождения между DNS-стороной и стороной соединения.

Дополнительный слой сложности добавляет Encrypted Client Hello (ECH). Для его работы браузер запрашивает специальные HTTPS-записи в DNS. Чем больше сайтов используют ECH, тем больше DNS-запросов делает браузер — и тем больше поводов для утечки, если DNS не идёт по правильному пути.

IPv6 и Happy Eyeballs

Современные системы запрашивают одновременно записи A (IPv4) и AAAA (IPv6) и пытаются подключиться к тому, что ответит быстрее — алгоритм Happy Eyeballs. Если ваша реальная сеть поддерживает IPv6, а прокси работает только через IPv4, ряд приложений умеет уходить напрямую по IPv6, минуя прокси целиком. Строго говоря, это не dns leak, а утечка соединения, но триггером служит именно DNS-ответ с AAAA-записью. Поэтому в контексте DNS-гигиены IPv6 нужно держать в голове.

Кеш и hosts: утечка из прошлого

ОС кеширует DNS-ответы. Если вы работали без прокси, а потом включили его, часть имён уже лежит в кеше с адресами, полученными через домашний резолвер. Новых запросов не будет, но соединения пойдут на «домашние» узлы CDN. Аналогично файл hosts: записи в нём подменяют разрешение имён полностью, и прокси об этом не узнает.

Метод 1. Диагностика: как своими руками проверить dns leak

Прежде чем что-то настраивать, нужно увидеть проблему. Хорошая новость: проверка утечки DNS — это процедура на пять минут, которую можно и нужно превратить в ритуал перед каждой рабочей сессией.

Как работают онлайн-тесты

Любой сервис проверки dns leak устроен одинаково. Страница генерирует несколько уникальных поддоменов вида случайная-строка.тестовый-домен и заставляет ваш браузер их разрешить, обычно через загрузку невидимых изображений или скриптов. Поскольку поддомены уникальны, их точно нет ни в каком кеше. Запрос обязательно дойдёт до авторитативного сервера тестового домена, который принадлежит сервису. Он записывает, с какого IP пришёл запрос — это адрес рекурсивного резолвера, который вы используете. Затем страница показывает вам два столбца: адрес, с которого пришло HTTP-соединение, и адреса резолверов. Если соединение с мобильного оператора, а резолвер принадлежит домашнему провайдеру или публичному DNS-сервису — утечка есть.

Важно понимать: точно так же может поступить любой сайт. Механизм не требует специальных полномочий. Антифрод-системы крупных платформ применяют похожие техники как часть оценки риска сессии. Это не теория заговора, а стандартная инженерия.

Пошаговая процедура проверки

  1. Зафиксируйте базовую линию. Отключите прокси, откройте тест dns leak, запишите, какие резолверы показываются. Это ваш «домашний» отпечаток. Вы должны узнавать его с одного взгляда.
  2. Очистите DNS-кеш. В Windows команда ipconfig /flushdns, в macOS перезапуск службы mDNSResponder, в Linux зависит от резолвера (например, resolvectl flush-caches для systemd-resolved). Перезапустите браузер — у него собственный кеш.
  3. Включите прокси тем способом, которым будете работать реально: через антидетект-профиль, расширение, системные настройки или код.
  4. Запустите расширенный тест, который делает не одну, а десятки проверок. Утечка бывает частичной: девять запросов из десяти уходят через прокси, а десятый — напрямую. Одиночный тест это пропустит.
  5. Сравните. Все резолверы должны принадлежать сотовому оператору, через которого работает прокси, либо инфраструктуре прокси-сервиса. Ни одного адреса из базовой линии. Ни одного публичного резолвера, который вы не выбирали осознанно.
  6. Проверьте IPv6 отдельно. Если тест показывает любой IPv6-адрес, не принадлежащий прокси, — утечка.
  7. Повторите через десять минут работы. Некоторые фоновые процессы стартуют с задержкой.

Проверка без сторонних сервисов: собственный тестовый домен

Для тех, кто работает с фермами аккаунтов или парсингом в промышленных масштабах, разумно иметь собственный инструмент. Схема такая: вы регистрируете недорогой домен и поднимаете для него авторитативный DNS-сервер на своём VPS с включённым логированием запросов. Дальше в любом проекте, при старте любой сессии, вы обращаетесь к уникальному поддомену вида идентификатор-сессии.ваш-домен. В логе DNS-сервера появляется запись: какой поддомен запрошен и с какого IP резолвера. Сопоставляете с идентификатором сессии и мгновенно видите, какая именно сессия, какой профиль, какой воркер утёк. Это превращает разовую проверку в постоянный мониторинг.

Низкоуровневая проверка: смотрим на сеть

Самый честный способ — посмотреть, что реально уходит с сетевого интерфейса. Запустите анализатор трафика (Wireshark или tcpdump) на физическом интерфейсе машины и отфильтруйте порт 53 UDP и TCP, а также порт 853 для DoT. Затем работайте через прокси пять минут. В идеальном мире фильтр останется пустым: все имена разрешаются на стороне прокси, локальных DNS-пакетов нет вообще. Если пакеты есть, вы сразу видите, какие домены и куда уходят. Для DoH фильтр сложнее, потому что это обычный HTTPS на порт 443, но подсказкой служат соединения к известным адресам публичных DoH-провайдеров, которые появляются не через прокси.

Чек-лист диагностики

  • Базовая линия без прокси записана.
  • Кеш ОС и браузера очищен перед тестом.
  • Расширенный тест на десятки запросов выполнен.
  • Все резолверы соответствуют стороне прокси.
  • IPv6-адреса чужой сети отсутствуют.
  • Повторный тест через 10 минут работы пройден.
  • Для критичных проектов: анализатор трафика на порту 53 показывает ноль пакетов.

Метод 2. Правильная конфигурация клиентского софта и кода

Вы нашли утечку. Теперь нужно понять, где именно приложение принимает решение резолвить имя локально, и переключить его на удалённое разрешение. Разберём самые распространённые окружения из практики арбитражников и разработчиков.

Принцип: имя хоста должно доехать до прокси

Правило одно, и оно универсально. Прокси должен получить от вас доменное имя, а не IP. Для HTTP-прокси это происходит естественно. Для SOCKS5 нужно явно выбрать режим удалённого DNS. Для SOCKS4 без расширения a это невозможно в принципе — такие прокси для чистой работы непригодны. Мобильные прокси современных сервисов поддерживают и HTTP, и SOCKS5 с удалённым резолвингом, поэтому ограничение здесь только на стороне клиента.

curl и командная строка

Для SOCKS5 всегда используйте схему с буквой h. Пример корректного вызова:

curl -x socks5h://user:pass@host:port https://example.com/

Без буквы h curl разрешит имя локально. Это касается и всех инструментов, построенных поверх libcurl. Для HTTP-прокси схема http:// в параметре -x достаточна: имя уйдёт в запросе CONNECT.

Python: requests, httpx, aiohttp

В библиотеке requests с установленным пакетом поддержки SOCKS аналогичное правило: socks5:// означает локальный резолвинг, socks5h:// — удалённый. Это самая частая ошибка в парсерах: разработчик копирует пример из документации, где стоит socks5, и годами гоняет трафик с dns leak, даже не подозревая. В httpx и aiohttp поддержка SOCKS реализуется через сторонние транспорты, и режим удалённого разрешения нужно проверять в документации конкретного транспорта — где-то это параметр rdns, где-то тоже схема с h. Проверяйте не по документации, а по факту: запустите скрипт против собственного тестового домена и посмотрите в лог, откуда пришёл запрос.

Отдельная ловушка — низкоуровневые сокет-библиотеки, которые монкипатчат стандартный модуль socket, чтобы завернуть весь трафик в SOCKS. У них есть флаг удалённого разрешения, но он по умолчанию нередко выключен. Плюс любой вызов socket.gethostbyname в вашем коде или зависимостях пройдёт мимо и разрешит имя через системный резолвер.

Node.js и headless-браузеры

В экосистеме Node.js SOCKS-агенты обычно передают имя хоста прокси, но это зависит от конкретного пакета и его версии. Для Puppeteer и Playwright прокси задаётся на уровне запуска браузера, и поведение наследуется от движка Chromium — о его особенностях с SOCKS5 мы поговорим в следующем разделе. Если вы работаете с HTTP-режимом мобильного прокси, вопрос снимается: Chromium отправит CONNECT с именем хоста.

Go, Java и другие языки

В Go стандартный пакет golang.org/x/net/proxy для SOCKS5 передаёт имя хоста удалённо, но только если вы используете его Dialer напрямую, а не резолвите заранее. В Java системные свойства для SOCKS-прокси работают, но многие HTTP-клиенты создают объект InetSocketAddress с предварительным разрешением, что и вызывает утечку. Решение — создавать неразрешённый адрес (методы вида createUnresolved) и убедиться, что клиент поддерживает передачу имени. Универсальный совет для любого языка: найдите в коде и в зависимостях все места, где домен превращается в IP, и убедитесь, что это происходит после установки соединения с прокси, а не до.

Пошаговый аудит проекта

  1. Найдите в коде все строки подключения к прокси. Проверьте схемы: socks5 без h — красный флаг.
  2. Найдите все явные вызовы разрешения имён: gethostbyname, getaddrinfo, dns.lookup, InetAddress.getByName. Каждый — потенциальная утечка.
  3. Проверьте зависимости: библиотеки проверки доступности, health-check, ретраи с предварительным пингом.
  4. Запустите проект против собственного тестового домена с уникальным поддоменом на каждый воркер. Лог DNS-сервера покажет, кто утекает.
  5. Добавьте автотест: сессия не считается валидной, пока DNS-проверка не подтвердила, что резолвер принадлежит стороне прокси.
  6. Зафиксируйте результат в документации проекта: какая библиотека, какая версия, какой режим.

Чек-лист для разработчика

  • Все SOCKS5-подключения используют удалённое разрешение.
  • Нет предварительного резолвинга перед подключением.
  • Библиотеки проверены не по документации, а по логу тестового домена.
  • Автоматическая DNS-проверка встроена в старт сессии.
  • Для HTTP-режима прокси проверено, что используется CONNECT, а не подмена на IP.

Метод 3. Браузеры и антидетект-браузеры без утечек DNS

Большая часть аудитории мобильных прокси работает не в коде, а в браузере: рекламные кабинеты, соцсети, маркетплейсы, мультиаккаунтинг. Здесь свои правила, и они отличаются от движка к движку.

Firefox и его наследники

Firefox исторически даёт самый прозрачный контроль. Ключевой параметр в about:config — network.proxy.socks_remote_dns. При значении true имена передаются SOCKS-прокси для удалённого разрешения. При false — резолвятся локально. Во многих старых сборках и профилях он выключен. Второй параметр — network.trr.mode, который управляет шифрованным DNS: значение 5 полностью отключает его, что для работы через прокси предпочтительно, потому что иначе браузер может обращаться к DoH-серверу собственным клиентом. Третий блок — предзагрузка: network.dns.disablePrefetch в true и network.predictor.enabled в false отключают спекулятивное разрешение имён для ссылок на странице, которое иначе может идти мимо прокси до реального перехода. Антидетект-браузеры на движке Firefox обычно выставляют эти параметры корректно, но проверять стоит каждый раз после обновления.

Chrome, Chromium и антидетекты на их основе

С Chromium история сложнее. Работая через HTTP-прокси, он отправляет CONNECT с именем — утечки нет. А вот при использовании SOCKS5-прокси через флаг запуска движок в ряде конфигураций разрешает имена локально, и стандартной настройки «удалённый DNS» в интерфейсе нет. Известный инженерный приём — флаг --host-resolver-rules с правилом, которое маппит все имена в состояние «не найдено», исключая сам адрес прокси. В результате локальный резолвер не может разрешить ничего, и браузер вынужден передать имена прокси. Выглядит как костыль, но работает надёжно. Второй важный пункт — настройка безопасного DNS в разделе конфиденциальности: при включённом состоянии Chromium использует DoH к выбранному провайдеру, и этот трафик не всегда следует прокси. Для работы через мобильный прокси его следует отключить либо убедиться в тестах, что он корректно туннелируется. Третье — предзагрузка страниц: в настройках производительности есть опция предварительной загрузки, которая инициирует DNS-запросы для ссылок, на которые вы ещё не нажали.

Что должен уметь антидетект-браузер

Хороший антидетект берёт на себя всю эту рутину. Но качество реализации сильно различается. Вот что проверять при выборе и после каждого обновления:

  • Режим удалённого DNS для SOCKS5 включён по умолчанию для каждого профиля, а не глобально.
  • Изоляция DNS между профилями. Кеш разрешённых имён не должен быть общим: иначе профиль на мобильном прокси одного региона получит IP, закешированный профилем на прокси другого региона.
  • Отключённый или туннелируемый шифрованный DNS. Спросите у поддержки прямо: как ведёт себя встроенный DoH при работе через прокси.
  • Отключённый prefetch. Спекулятивное разрешение не должно жить в профиле, который притворяется обычным мобильным пользователем.
  • Встроенная проверка dns leak при старте профиля или хотя бы удобный переход к тесту.
  • Поведение при разрыве прокси. Что делает браузер, если прокси недоступен: блокирует соединения или уходит напрямую? Второе — катастрофа не только для DNS.

Расширения-прокси: тонкий лёд

Браузерные расширения, которые переключают прокси, работают через API браузера. Они умеют задавать прокси для соединений, но контроль над DNS у них ограничен возможностями движка. Расширение не может заставить Chromium использовать удалённый DNS для SOCKS5, если сам движок этого не делает в данной конфигурации. Плюс расширение не управляет фоновыми сервисами браузера. Поэтому расширения — приемлемый вариант для HTTP-режима мобильного прокси и быстрых проверок, но не для серьёзной работы с чувствительными аккаунтами.

Пошаговая настройка профиля

  1. Создайте профиль и укажите мобильный прокси. Предпочтите HTTP-режим, если антидетект не гарантирует удалённый DNS для SOCKS5.
  2. Отключите шифрованный DNS в настройках движка или профиля.
  3. Отключите предзагрузку страниц и DNS-prefetch.
  4. Если это Firefox-подобный движок — проверьте socks_remote_dns вручную.
  5. Запустите профиль, очистите кеш и пройдите расширенный тест dns leak.
  6. Прогуляйтесь по нескольким сайтам с активной аналитикой и повторите тест: появились ли новые резолверы.
  7. Сохраните результат как эталон для этого профиля.

Метод 4. Системный уровень и инфраструктура: закрываем утечки принудительно

Все предыдущие методы работают по принципу доверия: мы настраиваем приложение и надеемся, что оно ведёт себя правильно. Инженерный подход другой: сделать утечку технически невозможной. Даже если приложение попытается отправить DNS-запрос напрямую, он не должен уйти.

Принцип «запрещено всё, что не через прокси»

На рабочей машине или сервере фермы настраивается межсетевой экран, который блокирует исходящий трафик на порт 53 (UDP и TCP) и порт 853 для всех процессов, кроме явно разрешённых. В Windows это правила исходящих подключений в брандмауэре, в Linux — nftables или iptables, в macOS — pf. Смысл: если браузер или скрипт попробует резолвить имя локально, он получит ошибку, а не тихую утечку. Ошибка заметна сразу — вы её увидите и исправите конфигурацию приложения. Тихая утечка может жить месяцами.

Тонкость с DoH: он идёт на порт 443, блокировать который целиком нельзя. Решение — блокировать не порт, а адреса известных публичных DoH-резолверов для процессов, которые должны ходить только через прокси. Это требует поддержания списка, но список меняется редко.

Изоляция через контейнеры и сетевые пространства имён

Для разработчиков и владельцев ферм на Linux мощнейший инструмент — сетевые пространства имён (network namespaces) и контейнеры. Идея: каждый воркер, каждый браузерный профиль или группа профилей живёт в собственном сетевом пространстве, в котором нет маршрута по умолчанию в интернет вообще. Единственный путь наружу — адрес прокси. Что бы приложение ни пыталось сделать — резолвить имя, уйти по IPv6, открыть прямое соединение — у него физически нет маршрута. Это самый надёжный способ гарантировать отсутствие dns leak в масштабе. В Docker это достигается пользовательской сетью без внешнего шлюза плюс явное разрешение доступа только к адресу прокси. Дополнительно в конфигурации резолвера контейнера можно указать заведомо недоступный адрес, чтобы любая попытка локального разрешения падала мгновенно, а не висела на таймауте.

IPv6 на системном уровне

Если ваш мобильный прокси работает через IPv4, а машина имеет IPv6-подключение, самое простое и надёжное решение — отключить IPv6 на интерфейсе, с которого работают прокси-профили, либо запретить исходящий IPv6 файрволом. Да, это грубо. Но это исключает целый класс проблем, при которых AAAA-запись в DNS-ответе уводит соединение напрямую.

Системный резолвер и его особенности

Современные ОС имеют многослойные резолверы. В Windows 11 есть поддержка DoH на уровне системы, и если она включена для вашего адаптера, все локальные разрешения будут идти к выбранному DoH-серверу. Для рабочей машины с прокси это нужно осознавать: включённый системный DoH меняет картину утечки, но не устраняет её. Android использует функцию Private DNS — аналогичная история для тех, кто работает с прокси на мобильных устройствах или эмуляторах. В Linux с systemd-resolved стоит проверить, какие DNS-серверы назначены каждому интерфейсу, потому что резолвер умеет маршрутизировать запросы по доменным суффиксам между интерфейсами, и это создаёт неожиданные пути.

Мониторинг как процесс

На уровне инфраструктуры проверка dns leak превращается из разовой в непрерывную. Что имеет смысл внедрить:

  • Логирование заблокированных DNS-попыток файрволом. Каждая запись в логе — приложение, которое пытается резолвить локально. Это ваш список на исправление.
  • Собственный тестовый домен с уникальными поддоменами на сессию и автоматический алерт при появлении чужого резолвера.
  • Периодический снимок сетевого трафика на порту 53 с физического интерфейса — раз в день, автоматически, с алертом при ненулевом счётчике.
  • Проверка после каждого обновления браузера, антидетекта, библиотек. Обновления — главный источник регрессий: разработчики меняют дефолты, включают новые фичи предзагрузки, добавляют шифрованный DNS.

Чек-лист системного уровня

  • Исходящий трафик на порты 53 и 853 заблокирован для рабочих процессов.
  • Известные публичные DoH-адреса заблокированы для тех же процессов.
  • IPv6 отключён или заблокирован на рабочих интерфейсах.
  • Критичные воркеры изолированы в сетевых пространствах без прямого маршрута.
  • Логи файрвола по DNS собираются и просматриваются.
  • Тестовый домен и алертинг настроены.

Типичные ошибки: что не нужно делать

Ошибка 1. Проверять только IP

Самая массовая. Человек видит адрес мобильного оператора на странице проверки IP и считает задачу решённой. Но проверка IP отвечает только на вопрос «откуда пришло соединение», а не «откуда пришли DNS-запросы». Это разные вопросы с разными ответами.

Ошибка 2. Прописать публичный DNS и успокоиться

Логика понятна: раз провайдер видит мои запросы, укажу публичный резолвер. Но для работы через прокси это не решение, а замена одной утечки на другую. Запросы всё равно уходят с вашего реального IP, теперь к другому наблюдателю. И к тому же публичные резолверы активно используют ECS и передают вашу подсеть авторитативным серверам. Расхождение между стороной DNS и стороной соединения остаётся.

Ошибка 3. Использовать SOCKS5 без удалённого DNS

Схема socks5 вместо socks5h в коде, выключенный socks_remote_dns в браузере, антидетект с дефолтным локальным резолвингом. Тысячи проектов живут с этой ошибкой годами.

Ошибка 4. Считать шифрованный DNS решением проблемы

DoH защищает содержимое запросов от провайдера. Но при работе через прокси он создаёт отдельный канал, который идёт не через прокси. Шифрование не равно правильная маршрутизация.

Ошибка 5. Игнорировать предзагрузку и фоновые сервисы

Браузер резолвит имена ссылок, которые вы ещё не открыли. Антивирус проверяет URL. Обновлятор ищет сервер обновлений. Всё это DNS-запросы, которые могут идти в обход. Проверка одиночным тестом такие вещи не ловит.

Ошибка 6. Общий DNS-кеш между профилями

Если два профиля на прокси разных регионов делят кеш, второй профиль подключится к CDN-узлу, который выбран для первого региона. Изоляция профилей должна включать DNS.

Ошибка 7. Не тестировать после обновлений

Новая версия браузера включила безопасный DNS по умолчанию. Обновлённая библиотека сменила поведение SOCKS. Обновление антидетекта сбросило настройки движка. Всё это реальные сценарии, которые вскрываются только повторной проверкой.

Ошибка 8. Разрешать прямой выход при недоступности прокси

Настройки вида «если прокси не отвечает, идти напрямую» превращают любой сбой в полную деанонимизацию сессии, начиная с DNS. Правильное поведение — блокировка соединений до восстановления прокси.

Ошибка 9. Ручной резолвинг «для скорости»

Некоторые парсеры резолвят домен один раз и дальше ходят по IP, чтобы экономить на DNS. Помимо утечки самого запроса, они получают IP, выбранный гео-DNS для их реального региона, и потом гоняют трафик через мобильный прокси на «чужой» узел CDN. Экономия миллисекунд оборачивается неконсистентным профилем.

Инструменты и ресурсы

Онлайн-тесты утечек

Сервисы проверки dns leak делятся на базовые и расширенные. Базовые делают один-два запроса и годятся для быстрой прикидки. Расширенные генерируют десятки уникальных поддоменов и выявляют частичные утечки. Для работы выбирайте те, что показывают не только IP резолвера, но и его принадлежность: организацию, автономную систему, страну. Хороший тест также отдельно показывает IPv4 и IPv6 и умеет проверять поведение при повторных запросах.

Анализаторы трафика

Wireshark — графический анализатор с фильтрами вида dns или udp.port == 53. tcpdump — консольный аналог для серверов и Linux-машин. Оба позволяют увидеть истину: что реально покидает сетевой интерфейс. Для DoH дополнительно смотрите TLS-соединения к адресам публичных резолверов.

Собственный авторитативный DNS

Для мониторинга в масштабе: любой лёгкий DNS-сервер с логированием запросов (CoreDNS, Unbound в авторитативном режиме, BIND, компактные серверы на Go или Python) плюс собственный домен. Затраты минимальные, а результат — постоянный надзор за всеми воркерами и профилями.

Инструменты командной строки

dig и nslookup показывают, к какому резолверу обращается система и что он отвечает. resolvectl в Linux с systemd-resolved показывает конфигурацию DNS по интерфейсам. curl с флагом подробного вывода показывает, передаёт ли он имя прокси или резолвит сам. В Windows ipconfig /displaydns покажет содержимое кеша, а Get-DnsClientServerAddress в PowerShell — назначенные серверы по адаптерам.

Межсетевые экраны

Встроенный брандмауэр Windows с правилами по программам, nftables и iptables в Linux, pf в macOS. Для удобства управления правилами по приложениям существуют графические надстройки. Ключевое требование — возможность блокировать порты для конкретных процессов и вести лог блокировок.

Контейнеризация

Docker и Podman с пользовательскими сетями, сетевые пространства имён Linux через ip netns, а для браузерных ферм — оркестраторы профилей, поддерживающие изоляцию сети на уровне профиля. Они превращают правило «только через прокси» из настройки в архитектурную гарантию.

Возможности на стороне прокси-сервиса

Обращайте внимание на то, что предлагает сам поставщик мобильных прокси: поддержку SOCKS5 с удалённым разрешением имён, HTTP-режим с корректной обработкой CONNECT, стабильность DNS на стороне оператора, отсутствие подмены DNS-ответов на стороне инфраструктуры. Полезно уточнить у поддержки, через какие резолверы разрешаются имена при удалённом резолвинге — правильный ответ: через резолверы мобильного оператора, к сети которого подключён модем.

Кейсы и результаты

Кейс 1. Ферма рекламных аккаунтов и невидимая причина банов

Команда арбитражников вела около 120 рекламных аккаунтов на мобильных прокси через популярный антидетект. Средний срок жизни аккаунта до блокировки держался на уровне 9–12 дней при внешне безупречной настройке: мобильные IP нужного региона, аккуратные отпечатки, прогрев. Аудит показал, что после очередного обновления антидетекта в движке оказался включён шифрованный DNS, и все профили разрешали имена через один и тот же публичный DoH-резолвер с реального IP офиса. 120 «независимых» пользователей из разных городов разрешали имена из одной точки. После отключения DoH, включения удалённого DNS и блокировки порта 53 файрволом средний срок жизни аккаунтов вырос до 30+ дней, а доля ранних блокировок на первой неделе снизилась примерно втрое. Стоимость исправления — два часа работы одного специалиста.

Кейс 2. Парсер маркетплейса и загадочные гео-цены

Разработчик собирал цены с крупного маркетплейса по регионам через мобильные прокси разных городов. Данные не сходились с тем, что видели реальные пользователи в этих регионах: часть цен и наличия соответствовала совсем другому городу. Причина оказалась в строке подключения: библиотека requests с схемой socks5 без h. Имена резолвились локально в городе разработчика, гео-DNS маркетплейса выдавал узел его региона, и дальше запросы через мобильный прокси другого города приходили на «чужой» узел, который отдавал региональную выдачу по своей логике. Замена одной буквы в конфигурации и добавление автоматической DNS-проверки при старте каждого воркера восстановили корректность данных. Побочный эффект: снизилась доля запросов, на которые маркетплейс отвечал капчей — сессии стали консистентнее.

Кейс 3. Тестирование рекламы под региональные аудитории

Маркетинговое агентство проверяло, как отображаются рекламные объявления и лендинги пользователям разных регионов, работая через мобильные прокси и Chromium-браузер с SOCKS5-подключением. Часть проверок показывала контент не того региона. В логах собственного тестового домена агентства резолверы принадлежали провайдеру офиса. Переход на HTTP-режим тех же мобильных прокси, при котором Chromium передаёт имена через CONNECT, плюс отключение предзагрузки страниц устранили расхождение. Дополнительный бонус — стабильные результаты проверок без повторных прогонов сэкономили команде порядка 15 процентов времени на регулярных аудитах.

Кейс 4. Мультиаккаунтинг в соцсети и общий кеш

Оператор десятков аккаунтов в соцсети заметил, что аккаунты, работающие в один день, стали блокироваться группами. Разбор показал два фактора на DNS-слое: антидетект использовал общий DNS-кеш между профилями, а часть профилей была на SOCKS5 без удалённого разрешения. В итоге профили на прокси разных регионов подключались к одним и тем же узлам CDN, а часть из них ещё и резолвила имена с одного реального IP. После включения изоляции кеша по профилям и перевода всех подключений на удалённый DNS групповые блокировки прекратились; за следующие два месяца потери аккаунтов вернулись к уровню, характерному для аккуратной ручной работы.

Общий вывод из кейсов

Во всех четырёх историях прокси были исправны. Проблема жила на стороне клиента и стоила недель работы, бюджетов и аккаунтов. Исправление каждый раз занимало часы. Такое соотношение — характерная черта именно dns leak: проблема невидима без специальной проверки, но исправляется просто, если знаешь, куда смотреть.

FAQ: сложные вопросы об утечках DNS

Если сайт не получает мои DNS-запросы, как он вообще узнаёт об утечке?

Тремя косвенными путями. Первый — уникальные тестовые поддомены: сайт может заставить ваш браузер разрешить домен, который контролирует сам, и посмотреть, с какого резолвера пришёл запрос. Второй — гео-DNS и CDN: если вы приходите на узел, предназначенный для другого региона, это расхождение с вашим IP видно на стороне инфраструктуры. Третий — EDNS Client Subnet: публичные резолверы передают подсеть клиента авторитативным серверам, и она не совпадает с подсетью соединения. Ни один из этих путей не требует доступа к вашему провайдеру.

Мобильный прокси резолвит имена через оператора. Это хорошо или плохо?

Это идеально для правдоподобия. Реальный абонент сотовой сети разрешает имена через резолверы оператора, и его соединения приходят с адресов того же оператора. Когда ваш прокси делает то же самое, DNS-сторона и сторона соединения принадлежат одной сети. Именно это состояние вы и должны видеть в тестах: резолверы оператора, IP оператора, один регион.

Чем HTTP-режим мобильного прокси лучше SOCKS5 с точки зрения DNS?

Тем, что в HTTP-режиме имя хоста передаётся прокси по определению протокола — в CONNECT для HTTPS и в URL для HTTP. Клиент не может случайно разрешить имя локально, кроме экзотических случаев вроде PAC-скриптов. В SOCKS5 удалённое разрешение — опция, которую клиент должен выбрать явно, и многие клиенты этого не делают по умолчанию. Если вы не уверены в поведении конкретного браузера или библиотеки, HTTP-режим безопаснее. SOCKS5 удобнее для не-HTTP протоколов, но требует контроля.

Достаточно ли просто отключить безопасный DNS в браузере?

Нет. Это закрывает один канал — DoH браузера. Остаются локальное разрешение для SOCKS5, предзагрузка, фоновые сервисы, системный DoH в ОС и IPv6. Отключение безопасного DNS — необходимый, но не достаточный шаг. Достаточным является только подтверждение расширенным тестом и, в идеале, блокировка прямого DNS на уровне системы.

Что делать, если в тесте появляются резолверы, которые не принадлежат ни мне, ни оператору?

Разбираться по цепочке. Сначала определите организацию по IP: если это публичный DNS-сервис, ищите включённый DoH в браузере или системе. Если это неизвестный хостинг, возможно, прокси-инфраструктура использует собственные резолверы вместо операторских — уточните у поставщика. Если это ваш провайдер, но не тот резолвер, который вы видели в базовой линии, — возможно, IPv6 или другой адаптер. Каждый неожиданный резолвер имеет объяснение, и его нужно найти, а не игнорировать.

Влияет ли dns leak на скорость работы через прокси?

Влияет, и часто в неожиданную сторону. При локальном разрешении гео-DNS выбирает узел CDN рядом с вашим реальным местоположением, а трафик потом идёт через мобильную сеть другого региона к этому узлу — маршрут получается длиннее оптимального. При удалённом разрешении узел выбирается рядом с выходом прокси, и путь от прокси до сервера короче. Так что правильная настройка DNS обычно не замедляет, а в ряде случаев ускоряет загрузку.

Как тестировать dns leak в автоматизированных сценариях без браузера?

Самый надёжный путь — собственный тестовый домен. При старте каждого воркера скрипт обращается через прокси к уникальному поддомену, а ваш авторитативный DNS-сервер логирует, с какого резолвера пришёл запрос. Скрипт затем читает лог по API и сравнивает адрес резолвера с ожидаемым диапазоном оператора. Если совпадения нет, сессия не запускается. Это превращает проверку из ручной в контрактную: воркер не имеет права работать, пока не доказал чистоту DNS.

Как меняется картина с распространением ECH и шифрованного DNS в 2026 году?

Ландшафт движется в сторону «DNS становится важнее». ECH зависит от DNS-записей типа HTTPS, браузеры включают шифрованный DNS по умолчанию, операционные системы добавляют системный DoH и DoQ. Для обычного пользователя это плюс к приватности. Для тех, кто работает через прокси, это означает больше DNS-трафика, больше независимых DNS-клиентов внутри системы и больше точек, где запрос может уйти мимо прокси. Антифрод-системы, в свою очередь, всё активнее используют консистентность между DNS-стороной и стороной соединения как сигнал. Вывод: дисциплина в работе с DNS из «желательно» превращается в «обязательно».

Можно ли доверять антидетект-браузеру, который заявляет защиту от dns leak?

Доверять — да, проверять — обязательно. Заявление в маркетинге не отменяет регрессий после обновлений, различий между движками и специфики вашей конфигурации прокси. Проверяйте каждый профиль после создания и после каждого обновления браузера. Один расширенный тест занимает минуту, а восстановление сгоревшей фермы — недели.

Заключение: DNS как фундамент чистой сессии

Давайте подведём итоги. Прокси меняет адрес, с которого приходит соединение, но не гарантирует, что разрешение имён идёт тем же путём. DNS-запрос выполняется раньше соединения, и именно в этом зазоре рождается dns leak. Для пользователей мобильных прокси это особенно критично: вся ценность мобильного IP — в его сходстве с реальным абонентом, а реальный абонент разрешает имена через своего оператора. Расхождение между DNS-стороной и стороной соединения выдаёт использование прокси надёжнее многих других признаков.

Мы разобрали, как течёт DNS в разных сценариях: SOCKS без удалённого разрешения, шифрованный DNS в браузерах и системах, предзагрузка, общий кеш, IPv6, PAC-скрипты и предварительный резолвинг в коде. Мы дали четыре метода, которые работают вместе: диагностика с базовой линией и расширенным тестом, правильная конфигурация клиентов и библиотек, настройка браузеров и антидетектов, и наконец принудительная защита на уровне файрвола и изоляции сети. Каждый метод сам по себе закрывает часть проблемы. Все вместе — делают утечку технически невозможной.

Ваши следующие шаги

  1. Сегодня: снимите базовую линию без прокси, затем пройдите расширенный тест dns leak в каждом рабочем профиле и каждом скрипте. Запишите результаты.
  2. На этой неделе: проверьте все строки подключения в коде на socks5 без h, отключите шифрованный DNS и предзагрузку в браузерах, убедитесь в изоляции кеша между профилями.
  3. В этом месяце: заблокируйте прямой DNS на уровне системы для рабочих процессов, отключите или заблокируйте IPv6 на рабочих интерфейсах, поднимите собственный тестовый домен с логированием.
  4. Постоянно: повторяйте проверку после каждого обновления браузера, антидетекта и библиотек. Превратите её в ритуал, как проверку IP.

Хороший мобильный прокси даёт вам правдоподобный адрес и правдоподобные резолверы оператора. Ваша задача — не растерять это преимущество на последнем метре, внутри собственной системы. Настройте DNS один раз правильно, сделайте проверку привычкой, и целая категория необъяснимых блокировок просто исчезнет из вашей практики. Разве не за этим вы читали это руководство до конца?