DNS через прокси: socks5 против socks5h, удалённый резолв и утечки

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

Эта статья - исчерпывающее руководство по тому, как именно происходит преобразование доменного имени в IP-адрес, когда трафик идёт через прокси. Мы разберём, чем принципиально отличаются схемы socks5 и socks5h, кто и на каком этапе отправляет DNS-запрос, почему сайт иногда видит совсем не тот регион, который вы ожидали, и как настроить удалённый резолв в популярных клиентах и библиотеках. Тема узкая, но чертовски важная. Именно на резолве имён рушатся тысячи, казалось бы, правильно настроенных конфигураций.

Введение: почему прокси подключён, а сайт видит не тот регион

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

Причина почти всегда одна и та же. Ваш HTTP или прикладной трафик действительно идёт через прокси, но DNS-запрос - тот самый запрос, который превращает имя вроде example.com в конкретный IP-адрес - уходит мимо прокси, напрямую с вашей машины. И этот запрос выдаёт вас с головой.

Почему так происходит? Потому что резолв имени и передача данных - это два разных этапа, которые могут идти по разным маршрутам. Многие клиенты по умолчанию резолвят имя локально, а через прокси отправляют уже готовое соединение по IP. С точки зрения сети всё логично. С точки зрения приватности и геолокации - катастрофа.

К концу этого материала вы будете понимать:

• кто именно выполняет резолв имени - операционная система, библиотека приложения, браузер или сам прокси-сервер;
• чем схема socks5 отличается от socks5h на уровне протокола и почему одна буква меняет всё;
• как метод CONNECT в HTTP-прокси решает проблему резолва почти автоматически;
• по каким каналам утекает DNS даже при, казалось бы, правильной настройке;
• как включить удалённый резолв в curl, Python, Node.js, Go, Chrome, Firefox, Selenium и Playwright;
• как проверить фактический путь резолва инструментами вроде dig, nslookup и tcpdump.

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

Основы: что такое резолв имени и кто его выполняет

Чтобы понять утечки, нужно сначала твёрдо усвоить механику резолва. Разложим по полочкам.

Что такое резолв доменного имени

Компьютеры общаются по IP-адресам, а люди - по именам. Резолв (от английского resolve, разрешить) - это процесс преобразования человекочитаемого имени, например shop.example.com, в машинный IP-адрес вида 93.184.216.34. Без этого шага никакое соединение невозможно: браузер не знает, к какому серверу подключаться, пока не получит IP.

Резолв - это отдельная сетевая транзакция. Обычно она использует протокол DNS поверх UDP или TCP на порту 53. Клиент отправляет запрос резолверу, резолвер возвращает ответ. Ключевой момент: кто именно отправляет этот запрос и по какому маршруту - и есть центральный вопрос всей нашей темы.

Четыре возможных исполнителя резолва

Когда приложение хочет связаться с example.com, резолв может выполнить один из четырёх участников. Разберём каждого.

1. Операционная система

Большинство приложений не резолвят имена сами. Они обращаются к системной функции - в мире C это getaddrinfo. ОС имеет собственный резолвер (stub resolver), который знает, к какому DNS-серверу обращаться, ведёт локальный кэш и учитывает файл hosts. Это самый распространённый путь. И самый опасный с точки зрения утечек: системный резолвер по умолчанию ходит напрямую в сеть, игнорируя ваш прокси.

2. Библиотека приложения

Некоторые программы и библиотеки имеют собственную логику резолва, которая может либо делегировать задачу ОС, либо выполнять её самостоятельно, либо - и это самое важное - передавать имя прокси-серверу, чтобы резолв произошёл на удалённой стороне. Именно этот механизм реализуют схемы socks5h и proxy-хостинг.

3. Браузер

Современные браузеры - отдельная вселенная. У них своя политика резолва, собственный кэш DNS, механизмы вроде DoH (DNS over HTTPS), предзагрузка соединений и WebRTC. Браузер может резолвить имя совершенно независимо от системных настроек, что порождает целый класс утечек.

4. Сам прокси-сервер

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

Ключевая аналогия

Представьте, что вы отправляете курьера (прокси) с посылкой в другой город. Есть два способа. Первый: вы сами узнаёте точный адрес получателя по справочнику у себя дома, пишете координаты на посылке и отдаёте курьеру только координаты. Справочник в вашем городе может дать не тот адрес, что справочник в городе назначения - и вы этого не заметите. Второй способ: вы отдаёте курьеру только имя получателя, и он находит адрес уже на месте, по местному справочнику. Второй способ и есть удалённый резолв. Он гарантирует, что адрес определён из правильной точки сети.

socks5 против socks5h: где принимается решение о резолве

Теперь мы подошли к сердцу темы. Разница между socks5 и socks5h - это не косметика и не синоним. Это фундаментально разные пути резолва, хотя протокол SOCKS5 под капотом один и тот же.

Что говорит протокол SOCKS5

Протокол SOCKS5 сам по себе гибок. В команде установки соединения клиент указывает тип адреса назначения. Возможны три варианта:

• IPv4-адрес - клиент передаёт готовый IP;
• IPv6-адрес - то же, но для IPv6;
• доменное имя - клиент передаёт строку имени, и тогда резолв обязан выполнить прокси-сервер.

То есть сам протокол умеет и локальный, и удалённый резолв. Вопрос лишь в том, какой тип адреса пошлёт клиент. И вот тут вступает в игру соглашение об именовании схем.

Схема socks5: локальный резолв

Когда клиент использует схему socks5 (без буквы h), это по устоявшейся конвенции означает: резолвить имя локально. Клиент сначала спрашивает у своего резолвера (обычно системного), какой IP у example.com, получает адрес, а затем передаёт прокси-серверу уже готовый IPv4 или IPv6.

Что видит целевой сайт? Он видит соединение от прокси - это верно. Но DNS-запрос ушёл из вашей сети, с вашей стороны, через ваш локальный резолвер. Если ваш резолвер географически или логически привязан к вашему региону, целевая инфраструктура через CDN и геолокацию DNS может определить именно ваш регион, а не регион прокси. Отсюда и симптом из введения.

Схема socks5h: удалённый резолв

Буква h в socks5h означает hostname - имя хоста. Эта схема говорит клиенту: не резолвь сам, передай имя прокси-серверу. Клиент отправляет команду с типом адреса доменное имя, и прокси-сервер выполняет резолв на своей стороне.

Что видит целевой сайт теперь? DNS-запрос приходит от резолвера, которым пользуется прокси, то есть из сети прокси. Геолокация по DNS указывает на регион прокси. Ваш локальный резолвер вообще не задействован и ничего не знает о том, куда вы ходите. Это правильный, чистый путь для большинства задач.

Сравнительная таблица механики

Соберём различия в компактном виде:

• socks5: резолв выполняет клиент (ОС/библиотека). Прокси получает IP. DNS-запрос уходит из вашей сети. Возможна географическая рассинхронизация и утечка.
• socks5h: резолв выполняет прокси. Прокси получает имя. DNS-запрос уходит из сети прокси. Регион консистентен, утечки нет.

Запомните простое правило: если приватность и корректность геолокации важны - всегда socks5h. Одна буква экономит часы отладки.

Почему конвенция именно такая

Историческая справка полезна для понимания. Изначально клиенты SOCKS резолвили сами, потому что ранние версии протокола (SOCKS4) не умели передавать имена. SOCKS5 добавил поддержку доменных имён, но экосистема инструментов ввела суффикс h, чтобы явно отличать поведение. Так родилась пара socks5 / socks5h, которую сегодня понимают curl, Python, множество HTTP-клиентов. Это де-факто стандарт именования, а не часть RFC.

HTTP и HTTPS-прокси: почему метод CONNECT резолвит на прокси

SOCKS - не единственный тип прокси. Огромная доля рабочих задач использует HTTP-прокси. И здесь механика резолва устроена иначе, причём во многих случаях удачнее.

Обычный HTTP-запрос через прокси

Когда вы ходите на HTTP-ресурс (без шифрования) через HTTP-прокси, клиент отправляет прокси полный запрос с абсолютным URL. Строка запроса содержит имя хоста. Прокси видит имя, сам его резолвит и подключается к серверу. То есть при обычном HTTP-проксировании резолв естественным образом происходит на стороне прокси. Клиенту незачем знать IP.

Метод CONNECT для HTTPS

С HTTPS всё интереснее. Зашифрованный трафик прокси не может читать - и не должен. Поэтому для HTTPS используется специальный метод CONNECT. Клиент отправляет прокси команду вида CONNECT example.com:443. Обратите внимание - здесь передаётся имя хоста, а не IP.

Что происходит дальше? Прокси-сервер получает имя, резолвит его на своей стороне, открывает TCP-туннель к целевому IP и превращается в прозрачную трубу. Внутри этой трубы уже идёт полноценное TLS-рукопожатие между вашим клиентом и целевым сервером - прокси его не расшифровывает.

Ключевой вывод: при правильной реализации HTTP-прокси с методом CONNECT резолв по умолчанию удалённый. Имя уходит на прокси, прокси резолвит сам. Это одна из причин, почему HTTP-прокси для HTTPS-трафика часто ведут себя корректнее из коробки, чем неправильно настроенный SOCKS.

Оговорка про клиентскую оптимизацию

Есть важный нюанс. Некоторые клиенты, стремясь оптимизировать соединение, всё равно резолвят имя локально перед отправкой CONNECT, а затем передают в CONNECT уже IP-адрес вместо имени. Формально это допустимо, но убивает всю пользу удалённого резолва. Поэтому даже с HTTP-прокси нельзя слепо полагаться на поведение - его нужно проверять. О методах проверки мы поговорим в отдельном разделе.

HTTPS-прокси как отдельный термин

Не путайте два значения. Иногда HTTPS-прокси означает прокси, который проксирует HTTPS-трафик (через CONNECT). А иногда - прокси, соединение с которым само зашифровано по TLS (то есть канал клиент-прокси защищён). Это разные вещи. С точки зрения резолва важнее первое: как передаётся имя назначения. Шифрование канала до прокси на путь резолва напрямую не влияет, хотя и защищает сам факт передачи имени от наблюдателя между вами и прокси.

Утечки DNS: механика возникновения и типовые сценарии

Теперь самое интересное - анатомия утечек. Утечка DNS - это ситуация, когда DNS-запрос уходит в обход прокси, раскрывая ваш реальный резолвер, регион или сам факт обращения к конкретному домену. Разберём сценарии по одному, потому что каждый требует своего лечения.

Сценарий 1: системный резолвер в обход прокси

Самый частый случай. Вы настроили приложение на socks5 (без h), либо клиент вообще не умеет удалённый резолв. Приложение вызывает системный getaddrinfo, ОС отправляет DNS-запрос своему резолверу напрямую по сети, минуя прокси. Данные потом идут через прокси, а имя уже утекло.

Как распознать: на прокси приходят соединения по IP, а не по имени. В сетевом дампе вашей машины видны исходящие пакеты на порт 53, не завёрнутые в туннель прокси.

Лечение: перейти на socks5h, включить удалённый резолв в клиенте, либо изолировать приложение так, чтобы у него не было прямого доступа к сети для DNS.

Сценарий 2: WebRTC в браузере

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

Лечение: контроль политики WebRTC в браузере, отключение или ограничение обработки ICE-кандидатов, использование браузерных настроек, которые заставляют весь трафик, включая WebRTC, идти через прокси.

Сценарий 3: встроенный DoH в браузере

Современные браузеры умеют DNS over HTTPS - резолв через зашифрованный HTTPS-запрос к своему DoH-провайдеру. Проблема в том, что этот запрос может идти в обход вашей SOCKS-схемы, напрямую с машины, если браузер настроен резолвить через собственный DoH и при этом не заворачивает этот трафик в прокси. Получается парадокс: имя резолвится зашифрованно и приватно от провайдера, но при этом мимо вашего прокси, что для задач геолокации хуже всего. Подробно этот механизм разберём в разделе про DoH.

Сценарий 4: параллельный IPv6-путь

Коварнейший сценарий. Ваш прокси работает по IPv4, вы настроили удалённый резолв. Но у машины есть рабочий IPv6, и клиент, следуя алгоритму Happy Eyeballs (одновременные попытки по IPv4 и IPv6), пытается резолвить AAAA-записи и подключаться по IPv6 напрямую, минуя прокси. Часть трафика и DNS уходит мимо. Регион разъезжается, соединение частично идёт не туда.

Лечение: отключить IPv6 для проксируемого приложения либо убедиться, что прокси поддерживает IPv6 и весь трафик, включая AAAA-резолв, идёт через него. Для многих задач проще принудительно ограничить клиент только IPv4.

Сценарий 5: кэш и предзагрузка

Браузеры и ОС агрессивно кэшируют DNS и заранее устанавливают соединения (preconnect, prefetch). Если до настройки прокси кэш заполнился, приложение может использовать старые записи или предустановленные соединения в обход новой конфигурации. Мелочь, но при отладке способна свести с ума.

Лечение: очистка DNS-кэша ОС и браузера, перезапуск, отключение агрессивной предзагрузки на время диагностики.

Общая закономерность утечек

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

Практика по инструментам: как включить удалённый резолв

Переходим к делу. Разберём конкретные клиенты и покажем, как включить удалённый резолв и не допустить локального. Это самый прикладной раздел - держите его под рукой.

curl: socks5 против socks5-hostname

curl - эталонный инструмент для понимания разницы. Он предоставляет явный выбор.

• --socks5 host:port - локальный резолв. curl сам определяет IP, потом идёт через прокси.
• --socks5-hostname host:port - удалённый резолв. curl передаёт имя прокси-серверу.

Через опцию --proxy тоже можно управлять схемой: socks5://... даёт локальный резолв, а socks5h://... - удалённый. Пример правильного вызова для удалённого резолва: curl --proxy socks5h://user:pass@proxyhost:1080 https://example.com. Для HTTP-прокси схема http://... с методом CONNECT по умолчанию резолвит на прокси, но и здесь стоит проверять реальное поведение.

Python: requests и httpx

В экосистеме Python схема socks5h - золотой стандарт для удалённого резолва.

Для requests нужен пакет поддержки SOCKS. Прокси задаётся словарём: указывайте схему socks5h://user:pass@host:port для https и http. Схема socks5:// без h означает локальный резолв - именно она чаще всего становится причиной утечек у новичков. Одна буква решает.

Для httpx логика аналогична: передавайте прокси со схемой socks5h:// для удалённого резолва. httpx строг к схемам и хорошо документирует поведение, но принцип тот же - буква h переключает резолв на сторону прокси.

Важное наблюдение: даже указав socks5h, проверьте, что не сработал системный прокси из переменных окружения (HTTP_PROXY, ALL_PROXY) с другой схемой. Переменные окружения способны переопределить ваши намерения.

Node.js

В Node.js прямой поддержки SOCKS в стандартном http нет. Используются агенты SOCKS, которые создают соединение через прокси. Ключевой параметр таких агентов - опция, определяющая, резолвить ли имя локально. В популярных SOCKS-агентах есть флаг, обычно называемый чем-то вроде lookup или опция, отвечающая за DNS: при значении, отключающем локальный lookup, имя передаётся прокси. Убедитесь, что агент сконфигурирован на передачу hostname, а не предварительно резолвит через dns.lookup.

Практический совет: в Node особенно внимательно проверяйте, не вызывается ли dns.resolve или dns.lookup где-то в коде до установки соединения. Такой преждевременный резолв обнуляет удалённый путь.

Go

В Go стандартная библиотека предоставляет пакет для работы с прокси. Через golang.org/x/net/proxy можно создать SOCKS5-диалер. По умолчанию поведение зависит от того, передаёте ли вы в Dial имя или уже резолвленный адрес. Ключ - использовать диалер так, чтобы в него уходило именно доменное имя, а не результат net.LookupHost. Если вы сами вызвали резолв и передали IP - это локальный резолв со всеми последствиями. Правильный подход: передавать диалеру строку host:port с именем и не резолвить заранее.

Chrome: флаги запуска

Chrome управляется через флаги командной строки и политику. Для указания прокси используется флаг proxy-server. Критично то, что при работе через SOCKS5 Chrome по умолчанию может резолвить локально. Существует флаг, отвечающий за то, чтобы резолв для проксируемых соединений выполнялся на стороне прокси - его имя связано с host-resolver-rules и настройкой, заставляющей все хосты идти через прокси. Также важен контроль встроенного DoH: если Secure DNS в браузере активен и настроен на собственного провайдера, он способен обойти вашу схему. Для чистоты эксперимента Secure DNS на время диагностики обычно отключают, а WebRTC-политику ужесточают.

Firefox: настройки about:config

Firefox исторически удобнее для контроля резолва. Ключевая настройка - network.proxy.socks_remote_dns. Установите её в значение true, и Firefox будет отправлять имена хостов на SOCKS-прокси для удалённого резолва вместо локального. Это одна из самых важных настроек во всём материале. Дополнительно контролируйте:

• network.trr.mode - режим DoH (TRR, Trusted Recursive Resolver). Значение, отключающее принудительный DoH, важно, если вы хотите, чтобы резолв шёл только через прокси.
• media.peerconnection.enabled - управление WebRTC, чтобы исключить утечку через ICE.
• настройки, отключающие IPv6 или предзагрузку, если наблюдается параллельный путь.

Selenium

Selenium управляет реальным браузером, поэтому логика резолва наследуется от Chrome или Firefox. Для Chrome вы передаёте те же флаги через опции запуска (аргументы proxy-server и связанные с резолвом). Для Firefox вы задаёте профиль с включённым network.proxy.socks_remote_dns через объект настроек профиля. Секрет успеха: не полагайтесь на дефолты драйвера - явно прописывайте настройку удалённого резолва в профиле или флагах и затем обязательно проверяйте фактический путь.

Playwright

Playwright предоставляет параметр proxy при запуске контекста или браузера. Вы указываете server со схемой (например, socks5://host:port) и учётные данные. Здесь есть тонкость: поведение резолва зависит от движка (Chromium, Firefox, WebKit) и от того, как реализован проксинг. Для гарантии удалённого резолва в Chromium-движке комбинируйте настройку прокси с соответствующими аргументами запуска, а в Firefox-движке - с настройкой профиля socks_remote_dns. Всегда завершайте настройку проверкой утечки.

Сводная таблица: клиент, как включить удалённый резолв, как проверить

Держите главную практическую таблицу материала:

• curl - включить: использовать --socks5-hostname или схему socks5h:// в --proxy - проверить: curl с verbose и наблюдение, что передаётся имя; дамп трафика на отсутствие прямых запросов на порт 53.
• Python requests - включить: схема socks5h:// в словаре proxies - проверить: запрос к сервису, показывающему источник резолва; контроль переменных окружения.
• Python httpx - включить: прокси со схемой socks5h:// - проверить: тест утечки, анализ, какой резолвер виден.
• Node.js - включить: SOCKS-агент с передачей hostname, без предварительного dns.lookup - проверить: отсутствие вызовов dns.resolve до соединения; дамп на порт 53.
• Go - включить: SOCKS5-диалер, передача host:port с именем, без net.LookupHost заранее - проверить: логирование того, что уходит в диалер; tcpdump.
• Chrome - включить: proxy-server с SOCKS5, host-resolver-rules на прокси, отключить Secure DNS на диагностику - проверить: онлайн-тест утечки, сравнение региона IP и региона DNS.
• Firefox - включить: network.proxy.socks_remote_dns в true, контроль network.trr.mode - проверить: about:networking, онлайн-тест утечки.
• Selenium - включить: те же флаги Chrome или профиль Firefox с socks_remote_dns - проверить: запуск теста утечки внутри управляемого браузера.
• Playwright - включить: параметр proxy плюс аргументы движка для удалённого резолва - проверить: переход на тест утечки в автоматизированной сессии.

DoH и DoT: как они взаимодействуют с прокси

DNS over HTTPS (DoH) и DNS over TLS (DoT) - это шифрование DNS-запросов. Сами по себе они прекрасны для защиты содержимого запроса от наблюдателя. Но в контексте прокси они порождают тонкие эффекты, которые надо понимать.

Что такое DoH и DoT в двух словах

DoT оборачивает DNS в TLS на выделенном порту. DoH прячет DNS-запрос внутрь обычного HTTPS-трафика, что делает его неотличимым от веб-сёрфинга. Оба протокола шифруют запрос. Но - и это критично - шифрование запроса не равно маршрутизации через прокси. Это разные измерения.

Ключевой конфликт: браузерный DoH мимо прокси

Вот главный инсайт раздела. Когда браузер включает собственный DoH и настроен резолвить через своего провайдера, он устанавливает HTTPS-соединение к DoH-эндпоинту. Вопрос: идёт ли это соединение через ваш прокси? Часто - нет. Браузер может открыть DoH-канал напрямую, потому что резолв воспринимается как служебная операция, отдельная от пользовательской навигации.

Результат парадоксален. С одной стороны, DNS-запрос зашифрован и провайдер не видит, какой домен вы запрашиваете. С другой - этот запрос уходит с вашей реальной машины, из вашей сети, мимо прокси. Для геолокации это провал: целевая инфраструктура видит резолв из вашего региона, а не из региона прокси. Ваша красиво настроенная схема socks5h обходится стороной, потому что браузер вообще не пошёл через SOCKS для резолва - он пошёл своим DoH-путём.

Когда браузерный DoH ломает вашу схему целиком

Конкретизируем ситуации, в которых DoH обходит прокси:

• браузер настроен на принудительный DoH через своего провайдера, а прокси задан только для обычного трафика, не для служебного резолва;
• операционная система или приложение имеет включённый DoH на уровне ОС, и он не заворачивается в туннель;
• DoH-эндпоинт закэширован и соединение к нему установлено до применения прокси-настроек.

Практический вывод: для задач, где важна консистентность региона, при работе через прокси браузерный и системный DoH нужно либо отключать, либо явно направлять через тот же прокси. Идеальная картина - весь резолв, зашифрованный он или нет, идёт через прокси-сервер (удалённый резолв), а не в обход него.

DoT и прокси

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

Золотое правило DoH в контексте прокси

Запомните: шифрование резолва и его маршрутизация через прокси - независимые свойства. Можно иметь зашифрованный резолв, который при этом полностью выдаёт ваш регион, потому что идёт мимо прокси. Для консистентности всегда добивайтесь удалённого резолва на прокси, а вопрос шифрования решайте отдельно и осознанно.

Как проверить: dig, nslookup, tcpdump и онлайн-тесты

Настроить - половина дела. Инженер обязан проверить, что резолв действительно ушёл туда, куда задумано. Разберём инструменты диагностики от простых к серьёзным.

dig и nslookup через прокси

dig и nslookup - классические утилиты для ручного резолва. Тонкость в том, что обычный DNS работает по UDP, а SOCKS-прокси нативно проксирует TCP. Поэтому проверка резолва через прокси требует, чтобы DNS-запрос шёл по TCP, и чтобы утилита была направлена через прокси-обёртку. На практике для наблюдения за поведением удобнее оборачивать инструменты через программы, заворачивающие TCP-трафик в SOCKS. Смысл проверки: убедиться, что при удалённом резолве ваша локальная машина не отправляет DNS-запросы сама, а видит только результат, пришедший через прокси-канал.

nslookup полезен для быстрой проверки, какой резолвер отвечает и какой IP возвращается. Сравнивайте IP, полученный локально, с IP, к которому реально идёт соединение через прокси. Расхождение - индикатор того, что резолв идёт разными путями.

tcpdump по 53 порту - самый честный тест

Это мой любимый метод, потому что он не врёт. Запустите на своей машине захват трафика с фильтром по порту 53 (и по 443 для DoH-подозрений). Затем выполните проксируемый запрос. Логика простая:

• если при удалённом резолве вы видите исходящие DNS-пакеты на порт 53 напрямую с вашей машины - у вас утечка, резолв идёт локально;
• если порт 53 молчит, а весь трафик уходит в туннель прокси - удалённый резолв работает корректно;
• если порт 53 молчит, но есть подозрительные HTTPS-соединения к известным DoH-эндпоинтам мимо прокси - у вас утечка через DoH.

tcpdump показывает физическую реальность сети, а не декларации конфигов. Именно поэтому он незаменим при финальной верификации.

Онлайн-тест утечки: как правильно читать результат

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

• ваш видимый IP - это IP, с которого пришло HTTP-соединение, то есть IP прокси;
• резолвер DNS - это адрес и регион того, кто фактически выполнил резолв.

Правильная картина при удалённом резолве: и видимый IP, и резолвер указывают на регион прокси. Тревожный признак: видимый IP - регион прокси, а резолвер - ваш реальный регион. Это классическая утечка через локальный резолв. Ещё один вариант утечки: резолвер принадлежит крупному DoH-провайдеру, но соединение к нему шло мимо прокси - тогда регион резолвера может быть нейтральным, но сам путь всё равно не проходит через прокси, что видно уже по tcpdump.

Чек-лист верификации резолва

Проходите по пунктам последовательно:

1. Очистите DNS-кэш ОС и браузера, перезапустите приложение.
2. Убедитесь, что схема - socks5h или включён удалённый резолв в клиенте.
3. Проверьте переменные окружения прокси на конфликтующие схемы.
4. Запустите tcpdump с фильтром по портам 53 и 443.
5. Выполните проксируемый запрос к тестовому ресурсу.
6. Убедитесь, что прямых DNS-пакетов на порт 53 нет.
7. Проверьте отсутствие независимых HTTPS-соединений к DoH-эндпоинтам.
8. Откройте онлайн-тест утечки и сравните регион IP с регионом резолвера.
9. Проверьте IPv6-путь: нет ли параллельных AAAA-запросов и соединений.
10. Зафиксируйте эталонную конфигурацию в документации команды.

Типичные ошибки, которые допускают почти все

За годы работы с прокси накапливается коллекция граблей. Разберём самые частые, чтобы вы на них не наступили.

Ошибка 1: путать socks5 и socks5h

Абсолютный лидер. Человек пишет socks5:// и уверен, что резолв удалённый. А он локальный. Одна отсутствующая буква h - и весь регион разъезжается. Всегда явно указывайте socks5h, если вам нужен удалённый резолв, и проверяйте это дампом.

Ошибка 2: настроить прокси, но забыть про DoH

Классика для браузеров. Прокси задан, но встроенный Secure DNS / DoH активен и идёт мимо. Пользователь видит правильный IP и успокаивается, а резолв тем временем утекает. Всегда синхронизируйте политику DoH с прокси.

Ошибка 3: игнорировать IPv6

Прокси на IPv4, а машина живёт двойным стеком. Happy Eyeballs делает своё дело, и часть соединений уходит по IPv6 напрямую. Либо отключайте IPv6 для приложения, либо убеждайтесь, что прокси полноценно обслуживает IPv6.

Ошибка 4: предварительный локальный резолв в коде

Частая беда в Node.js и Go. Разработчик из лучших побуждений вызывает резолв заранее (для проверки, для логирования) и передаёт прокси уже IP. Удалённый резолв мёртв. Не резолвьте имя до передачи в прокси-диалер.

Ошибка 5: доверять переменным окружения

HTTP_PROXY, HTTPS_PROXY, ALL_PROXY, NO_PROXY - тихие диверсанты. Они переопределяют настройки в коде или конфликтуют со схемой. Проверяйте окружение перед запуском и очищайте лишнее.

Ошибка 6: верить конфигу вместо проверки

Написали правильную строку и пошли дальше. Но конфиг - это намерение, а не факт. Реальное поведение проверяется только дампом трафика и тестом утечки. Никогда не завершайте настройку без верификации.

Ошибка 7: забытый DNS-кэш

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

Ошибка 8: смешивать типы прокси в одном пайплайне

В одном месте HTTP-прокси с CONNECT, в другом SOCKS с локальным резолвом. Поведение резолва различается, и часть запросов утекает. Унифицируйте подход по всему пайплайну.

Ошибка 9: не учитывать кэш приложения

Некоторые приложения держат собственный DNS-кэш и пул соединений, переживающий смену настроек. Перезапуск процесса иногда обязателен.

Ошибка 10: игнорировать WebRTC в автоматизации

При автоматизации браузеров WebRTC часто забывают. Управляемый браузер спокойно инициирует ICE и раскрывает пути в обход прокси. Всегда контролируйте WebRTC-политику в автоматизированных сессиях.

Инструменты и ресурсы для работы с резолвом через прокси

Соберём арсенал, который стоит держать под рукой. Разделим по назначению.

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

• tcpdump - захват сетевого трафика, главный судья истины по путям резолва.
• Wireshark - графический анализ пакетов, удобен для разбора сложных случаев с DoH и IPv6.
• dig и nslookup - ручной резолв, быстрая проверка ответов резолвера.
• онлайн-тесты утечки DNS - показывают резолвер и его регион, дают быстрый вердикт.
• about:networking в Firefox - встроенная диагностика соединений и DNS браузера.

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

• curl - эталон для проверки поведения socks5 и socks5-hostname, идеален для отладки.
• SOCKS-обёртки TCP-трафика - позволяют завернуть произвольное приложение в SOCKS для тестов резолва.
• библиотеки SOCKS для языков - пакеты поддержки SOCKS в Python, SOCKS-агенты в Node.js, пакет proxy в Go.
• инструменты автоматизации браузеров - Selenium и Playwright с явной настройкой прокси и резолва.

Ресурсы знаний

• официальная документация curl по опциям прокси - лучший первоисточник по семантике socks5 против socks5h;
• документация HTTP-клиентов Python по работе с прокси и схемами;
• справочники about:config Firefox по параметрам сети и резолва;
• документация выбранного вами провайдера прокси, в частности сервиса MobileProxy.space, где описаны поддерживаемые схемы и рекомендации по удалённому резолву для мобильных прокси.

Мини-фреймворк выбора подхода

Чтобы не теряться, держите простую логику принятия решения:

1. Нужен HTTPS-трафик и удалённый резолв? HTTP-прокси с CONNECT или SOCKS5 со схемой socks5h.
2. Работаете из библиотеки или CLI? Явно указывайте socks5h или флаг удалённого резолва.
3. Работаете из браузера? Включите удалённый резолв, отключите или направьте DoH через прокси, ограничьте WebRTC и IPv6.
4. Всегда завершайте настройку дампом трафика и онлайн-тестом.

Кейсы и результаты: как это выглядит на практике

Теория без практики мертва. Разберём обобщённые кейсы, отражающие типичные ситуации. Цифры условны, но пропорции и логика взяты из реальной инженерной практики.

Кейс 1: рассинхрон региона у аналитика данных

Команда собирала данные через Python-скрипт с прокси нужного региона. Результаты приходили с локализацией другой страны примерно в сорока процентах случаев. Диагностика показала схему socks5:// в словаре proxies - локальный резолв. Замена на socks5h:// устранила рассинхрон полностью. tcpdump подтвердил: прямые запросы на порт 53 исчезли. Урок: одна буква решила проблему, на которую до этого потратили два дня.

Кейс 2: утечка через браузерный DoH в автоматизации

При автоматизации Chromium через Playwright регион IP был корректным, но целевой ресурс упорно определял другой регион. Онлайн-тест показал резолвер, не совпадающий с регионом прокси. Wireshark выявил независимые HTTPS-соединения к DoH-эндпоинту в обход прокси. Решение: отключение Secure DNS в конфигурации запуска и принудительный удалённый резолв. После правки регион резолвера совпал с регионом IP, ложные срабатывания антифрода снизились в разы.

Кейс 3: параллельный IPv6 в микросервисе

Go-сервис ходил через SOCKS5, но периодически часть запросов уходила напрямую. Причина - двойной стек и попытки по IPv6 мимо прокси. Ограничение клиента только IPv4 и корректная передача имени в диалер устранили утечку. tcpdump перестал показывать прямые AAAA-запросы. Стабильность региона выросла до почти стопроцентной.

Кейс 4: переменные окружения-диверсанты

Скрипт вёл себя по-разному на двух машинах при идентичном коде. На одной работал удалённый резолв, на другой - нет. Разгадка: на проблемной машине была выставлена переменная ALL_PROXY со схемой без h, переопределявшая настройки. После очистки окружения поведение стало консистентным. Урок: окружение - часть конфигурации, его нужно контролировать так же строго, как код.

Общий вывод по кейсам

Заметьте закономерность. Во всех случаях симптом был схожим - неверный регион или срабатывание защиты, - а причины разными: схема, DoH, IPv6, окружение. Именно поэтому диагностика по чек-листу важнее интуиции. Систематический подход находит корень быстрее, чем гадание.

FAQ: часто задаваемые вопросы

Чем socks5 отличается от socks5h простыми словами?

socks5 резолвит доменное имя на вашей стороне и отправляет прокси готовый IP. socks5h отправляет прокси само имя, и резолв выполняет прокси. Для приватности и корректной геолокации почти всегда нужен socks5h. Буква h означает hostname - имя хоста передаётся удалённо.

Если я использую HTTP-прокси, нужно ли беспокоиться о резолве?

При HTTPS через метод CONNECT имя обычно уходит на прокси, и он резолвит сам - это хорошо. Но некоторые клиенты предварительно резолвят локально и передают в CONNECT уже IP. Поэтому даже с HTTP-прокси проверяйте фактическое поведение дампом трафика.

Почему IP правильный, а сайт видит другой регион?

Почти наверняка ваш DNS-запрос идёт мимо прокси - через локальный резолвер или браузерный DoH. Целевая инфраструктура через геолокацию DNS и CDN определяет регион вашего резолвера, а не прокси. Лечение - удалённый резолв и контроль DoH.

Как WebRTC связан с резолвом и утечками?

WebRTC для установления соединений собирает сетевых кандидатов и может инициировать запросы, идущие мимо прокси. Это способно раскрыть пути и адреса. При работе через прокси, особенно в автоматизации браузеров, WebRTC-политику нужно контролировать или ограничивать.

Ломает ли DoH мою настройку прокси?

Может ломать. Шифрование резолва и его маршрутизация через прокси - разные вещи. Браузерный или системный DoH способен уходить напрямую, мимо прокси, выдавая ваш регион. Для консистентности отключайте такой DoH или направляйте резолв через прокси.

Как быстро проверить, есть ли утечка?

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

Что делать с IPv6, если прокси только на IPv4?

Либо отключить IPv6 для проксируемого приложения, либо убедиться, что прокси обслуживает IPv6 и весь трафик, включая AAAA-резолв, идёт через него. Иначе алгоритм Happy Eyeballs отправит часть соединений напрямую, мимо прокси.

Почему одинаковый код ведёт себя по-разному на двух машинах?

Частая причина - переменные окружения прокси (HTTP_PROXY, ALL_PROXY и подобные). Они переопределяют настройки в коде или задают другую схему. Проверьте и очистите окружение, чтобы поведение стало консистентным.

Достаточно ли указать socks5h, чтобы утечек точно не было?

Для самого приложения - большой шаг вперёд, но не гарантия для всей системы. Остаются каналы вроде браузерного DoH, WebRTC и IPv6. Полная защита - это удалённый резолв плюс контроль всех обходных каналов плюс обязательная проверка дампом.

Можно ли резолвить через прокси в командной строке для теста?

Да. curl с опцией --socks5-hostname или схемой socks5h - самый простой способ проверить удалённый резолв. Для утилит вроде dig удобно оборачивать TCP-трафик в SOCKS, помня, что классический DNS по UDP через SOCKS нативно не проксируется.

Заключение: резюме и следующие шаги

Мы прошли путь от симптома до глубокого понимания. Давайте соберём главное в компактный смысловой каркас, который останется с вами.

Резолв доменного имени - отдельная сетевая транзакция, которая может идти по маршруту, отличному от вашего основного трафика. Именно эта независимость и порождает большинство проблем. Выполнять резолв способны четверо: операционная система, библиотека приложения, браузер и сам прокси. Ваша цель почти всегда - отдать резолв прокси-серверу, чтобы имя определялось из правильной точки сети.

Разница между socks5 и socks5h - фундаментальная. socks5 - локальный резолв, socks5h - удалённый. Одна буква меняет всё: регион, приватность, консистентность. HTTP-прокси с методом CONNECT по природе передают имя на прокси, но и здесь нельзя доверять слепо - проверяйте.

Утечки сводятся к одному принципу: существует канал, по которому имя уходит не через прокси. Системный резолвер, WebRTC, браузерный DoH, параллельный IPv6, кэш - вот главные подозреваемые. И помните ключевой инсайт: шифрование резолва не равно его маршрутизации через прокси. Можно иметь зашифрованный DoH, который при этом полностью выдаёт ваш регион.

Что делать прямо сейчас? Вот ваш план действий:

1. Пройдитесь по своим текущим конфигурациям и замените socks5 на socks5h там, где нужен удалённый резолв.
2. Проверьте браузеры: включите удалённый резолв, разберитесь с политикой DoH и WebRTC.
3. Убедитесь, что IPv6 не создаёт параллельного пути мимо прокси.
4. Очистите переменные окружения прокси от конфликтующих значений.
5. Проведите верификацию через tcpdump и онлайн-тест по чек-листу из статьи.
6. Зафиксируйте эталонную рабочую конфигурацию в документации, чтобы команда не изобретала велосипед заново.

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