SOCKS5 vs SOCKS5h: где происходит DNS-разрешение?

Короткий ответ

В curl и Python Requests используйте socks5h://, если адрес сайта должен определять сервер. При socks5:// адрес сначала находит компьютер, с которого отправлен запрос.

Главное

• Если не удалось разрешить имя шлюза, запрос до него еще не дошел. Посмотрите, какое имя указано в ошибке.
• Браузер и скрипт по расписанию могут по-разному обрабатывать имена при одинаковых параметрах подключения.
• При сравнении настроек сохраняйте первую ошибку каждой попытки. Последнее сообщение о тайм-ауте часто уже не содержит самой полезной подсказки.

Какое имя не удалось найти: прокси или сайта?

Посмотрите на имя хоста в сообщении об ошибке. Оно относится к вашему провайдеру прокси или к сайту, который вы открывали? Начните с поиска адреса именно для этого имени.

Например, скрипт проверки остатков может успешно авторизоваться на прокси, но не открыть каталог поставщика. Замена сервера в таком случае способна оставить исходную проблему нерешенной. При обычной схеме socks5 в curl скрипту все еще нужно получить адрес домена поставщика со своего компьютера.

Бывает и более ранний сбой. Параметр h не поможет компьютеру найти адрес самого шлюза. Пока этот адрес неизвестен, отправлять имя каталога просто некуда.

Передайте поддержке исходное сообщение curl вместе с именем, адрес которого не удалось определить. Утилита отдельно сообщает о проблемах с разрешением имени прокси и целевого хоста. Формулировка «ошибка DNS» заставит поддержку гадать, какой участок проверять.

На какую часть запроса влияет h?

Меняется поле адреса. В нем можно указать доменное имя, IPv4-адрес или IPv6-адрес. Если передано имя, поиск адреса остается принимающей стороне.

Буква h обозначает настройку клиента. Она не меняет протокол SOCKS5 или вашу учетную запись.

Даже если адрес выбрал ваш компьютер, сам веб-запрос по-прежнему может идти через шлюз.

Слово «локальное» указывает, кто организует поиск адреса. Сам резолвер может находиться в другом месте сети. Если ответ уже есть в кэше компьютера или файле hosts, новый сетевой запрос может вообще не понадобиться.

Какая настройка приложения управляет поиском адреса?

В curl или Requests поменяйте схему в сохраненном URL прокси. При сравнении двух режимов оставьте остальные параметры подключения прежними.

Замените proxy.example:1080 адресом и портом своего сервера. Если целевой сайт попадает в исключения NO_PROXY, уберите это исключение на время сравнения. В Windows PowerShell используйте curl.exe, если имя curl вызывает другую команду.

curl --verbose --proxy socks5://proxy.example:1080 https://example.com

curl --verbose --proxy socks5h://proxy.example:1080 https://example.com

В curl этот выбор также доступен через отдельные параметры SOCKS. Подробный вывод может отмечать попытку подключения как locally resolved или remotely resolved. Читайте и следующие сообщения: из дальнейшего обмена станет понятно, принял ли сервер запрос. После строки об удаленном режиме еще может появиться ошибка. Формулировки и состав вывода зависят от установленной версии.

locally resolved
remotely resolved

В Requests проверьте значение, заданное для типа целевого URL. Ключ «https» выбирает запросы к защищенным веб-адресам, но сам по себе не включает удаленную обработку имени. Ее определяет схема внутри значения. Установите дополнение SOCKS для того интерпретатора, который запускает задачу.

python -m pip install "requests[socks]"


import requests

proxies = {
    "https": "socks5h://proxy.example:1080",
}

response = requests.get(
    "https://example.com",
    proxies=proxies,
    timeout=20,
)
response.raise_for_status()
print(response.status_code)

Для HTTP-адресов добавьте ключ «http» с соответствующим URL прокси. Для сравнения режимов замените в значении socks5h:// на socks5://.

Для сравнения можно взять Chrome. Его встроенная реализация SOCKS5 использует удаленное разрешение. При этом curl может определять адрес на вашем компьютере.

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

В обоих условных примерах ниже соединение со шлюзом и авторизация работают.

Случай 1: корпоративный сервис заработал только после добавления h

Сотрудник запускает выгрузку из дома. У сервиса отчетности внутреннее имя, а корпоративный шлюз имеет доступ и к своему DNS, и к приложению отчетности. Домашний резолвер сотрудника записи для этого имени не знает.

При клиентском поиске выгрузка не может получить адрес для подключения. Передача имени корпоративной инфраструктуре позволяет искать его там, где оно известно. Если после этого появляется ошибка соединения, следующий вопрос нужно разбирать уже внутри той сети: может ли шлюз достичь порта, который слушает приложение?

Случай 2: тестовый сайт перестал открываться после добавления h

В файле hosts разработчика домен тестового сайта сопоставлен с публичным тестовым адресом. Обычный режим может использовать эту запись и отправить полученный адрес. У шлюза тоже есть сетевой доступ к тестовому серверу.

При удаленном поиске локальная подстановка перестает участвовать в выборе адреса. Запись hosts остается на компьютере разработчика. Чтобы удаленный режим заработал, для того же имени нужна DNS-запись, доступная шлюзу. Иначе следует сохранить исходную локальную подстановку.

Для выгрузки нужна запись внутри компании, а тестовый сайт зависит от подстановки на одном компьютере.

Может ли страница выглядеть одинаково в обоих режимах?

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

Для более точной проверки изучите запрос на SOCKS-сервере, которым вы управляете. Зафиксируйте, что находится в поле назначения: IP-адрес или домен. Журнал резолвера отвечает на более узкий вопрос – появился ли поиск имени в этой точке наблюдения. Пустой журнал оставляет открытым вопрос о кэше и других источниках адресной информации.

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

Отправьте URL, на котором произошел сбой, версию приложения, выбранный режим и первую относящуюся к проблеме ошибку каждой попытки. Опишите, что менялось между запусками. Так поддержка получит более точные данные для воспроизведения, чем фраза «в браузере прокси работает».

Воспроизведите сбой в той программе, которая будет выполнять задачу. Для скрипта сохраните вместе его настройки и результат запроса. В браузере можно дополнительно запустить DNS Leak Test. Браузерный тест не подтверждает настройки отдельного процесса Python, а изменившийся выходной IP не сообщает, кто определил адрес целевого сайта.

Словарь

DNS-резолвер – служба, которая получает DNS-данные для запрошенного имени.

Шлюз – SOCKS-сервер, принимающий от приложения запрос на соединение.

Файл hosts – локальный источник соответствий между именами и адресами, который используют поддерживающие его механизмы разрешения имен.

Итог

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

Часто задаваемые вопросы

Здесь мы ответили на самые часто задаваемые вопросы. Все равно не можешь найти ответа?

Задать вопрос

Можно ли сравнить режимы, указав только IP-адрес?

У числового адреса нет имени сайта, которое могла бы искать одна из сторон. Для такого сравнения используйте домен. Подстановка IP вместо имени HTTPS-сайта также может привести к ошибке проверки сертификата или другому ответу сайта.

Добавляет ли h шифрование трафика?

Для шифрования нужен отдельный механизм. HTTPS использует TLS между клиентом и сайтом; настройка SOCKS5h дополнительного шифрования не дает.

Должны ли адрес DNS-резолвера и выходной IP совпадать?

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