Как проверить прокси: воспроизводимые тесты подключения, авторизации, IP, DNS и протоколов

Надёжная проверка прокси — это короткая серия повторяемых запросов из командной строки, каждый из которых отвечает на один вопрос: доступен ли прокси, принимает ли он ваши учётные данные, проходит ли запрос через него, какой адрес видит место назначения и кто разрешил имя хоста. Выполняйте проверки в таком порядке и записывайте точный вывод каждой, чтобы сбой указывал на один уровень, а не на расплывчатое «прокси не работает».

Это руководство не привязано к конкретному провайдеру и использует curl. Результаты зависят от версии и сборки curl, поэтому проверьте, что у вас установлено, прежде чем сравнивать результаты с другими. Форматы адресов подключения, порты и поддерживаемые протоколы смотрите в документации вашего провайдера прокси.

Краткий чек-лист

1. Задайте прокси явно и исключите посторонние переменные окружения.
2. Выберите правильную схему и укажите порт.
3. Проверьте аутентификацию и прочитайте статус или результат метода.
4. Для HTTP-прокси проверьте, создаётся ли туннель для HTTPS-адресов.
5. Для SOCKS5 классифицируйте любой сбой по коду ответа.
6. Сравнение локального DNS-разрешения и разрешения на стороне прокси.
7. Выполните запрос к IP-echo адресу подключения через прокси и сравните результат с прямым запросом.

Начните с чистого теста

Настройки прокси могут браться из мест, о которых вы забыли. Согласно руководство по curl, переменные окружения прокси можно записывать в нижнем или верхнем регистре, при этом версия в нижнем регистре имеет приоритет. http_proxy является исключением: он существует только в нижнем регистре. Заголовок документация libcurl добавляет, что использование переменной окружения прокси имеет тот же эффект, что и --proxy опцию, а также то, что установка пустой строки в качестве строки прокси явно отключает использование прокси, даже если переменная задана.

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

Выберите схему и укажите порт

В руководстве curl объясняется, что при отсутствии схемы или с http://, значение --proxy рассматривается как HTTP-прокси. Префиксы позволяют выбрать конкретную версию SOCKS. Всегда указывайте порт самостоятельно. Документация libcurl не советует считать, что какой-либо один порт широко используется для прокси, поэтому не угадывайте порт для HTTP-прокси.

Схема	Что делает curl
http:// (или без схемы)	Воспринимает значение как HTTP-прокси
socks4://	Использует SOCKS4
socks4a://	Использует SOCKS4a; прокси сам разрешает имя хоста
socks5://	Обычный SOCKS5; имя хоста разрешается локально
socks5h://	SOCKS5; прокси разрешает имя хоста

Примечания по решению проблем основаны на документации libcurl, где сказано: socks4a:// и socks5h:// заставляют прокси разрешать имя хоста, а это socks5:// это обычный SOCKS5, а в руководстве по curl, где сказано --socks5 разрешает имена локально. SOCKS5 по умолчанию обычно работает на порту 1080 согласно RFC 1928, а curl по умолчанию использует 1080 для --socks5-hostname если порт не указан, но считайте это условностью и всё равно указывайте порт. Сравнение самих версий протокола см. в статье SOCKS4 и SOCKS5: сравнение аутентификации, DNS и UDP.

Первая проверка соединения; замените плейсхолдеры своими данными:

curl --proxy 'http://PROXY_HOST:PROXY_PORT' -U 'USER:PASSWORD' 'http://ECHO_URL'

Проверьте аутентификацию

Для HTTP-прокси учётные данные указываются в -U / --proxy-user как user:password. Если включить их в строку прокси, curl декодирует URL-кодирование, поэтому записывайте @ как %40 и двоеточие как %3a. A password such as p@ss становится p%40ss:

curl --proxy 'http://USER:p%40ss@PROXY_HOST:PROXY_PORT' 'http://ECHO_URL'

Basic — метод curl по умолчанию при работе с прокси. --proxy-anyauth позволяет curl выбрать подходящий метод для HTTP-прокси, но в руководстве отмечено, что это может стоить дополнительного цикла запрос/ответ.

RFC 9110 предлагает способ разделить две ситуации:

Ответ	Что описывает RFC	Что проверить
407 с Proxy-Authenticate	Прокси, требующий аутентификации, должен отвечать так, когда учётные данные отсутствуют, неверны или переданы не полностью	Имя пользователя, пароль, кодировка, предлагаемая схема
403	Действительные учётные данные, которых недостаточно для доступа, должны получать этот ответ	Какой компонент его вернул, затем правила доступа

Каждый ответ 407, который формирует прокси, должен содержать как минимум один Proxy-Authenticate заголовок, по которому можно прочитать предлагаемую схему.

Ошибка 403 требует одного дополнительного шага. В режиме пересылки ответ может прийти от целевого сервера, а не от прокси. Прежде чем делать выводы, убедитесь, какая сторона его вернула. Для HTTPS-цели строка статуса ответа на CONNECT приходит от прокси. Если сам прокси вернул 403 после принятия ваших учётных данных, смотрите на его правила доступа, а не на опечатку в пароле. Ошибка 407 указывает на сами учётные данные.

В SOCKS5 аутентификация проходит в два этапа. Клиент отправляет сообщение с выбором метода, и если сервер отвечает методом X'FF', ни один из предложенных методов не подходит, и клиент должен закрыть соединение. Определены следующие методы: X'00' без аутентификации, X'01' GSSAPI и X'02' имя пользователя/пароль. RFC 1928 указывает, что реализации должны поддерживать аутентификацию по имени пользователя и паролю, поэтому этот метод является рекомендацией, а не гарантией для каждого сервера. В curl, --socks5-basic выбирает имя пользователя/пароль и включён по умолчанию.

На шаге ввода имени пользователя и пароля, определённом в RFC 1929, статус X'00' означает успех; любой другой статус — это сбой, и сервер должен закрыть соединение. Тот же RFC также указывает, что пароль передаётся открытым текстом, поэтому этот шаг не рекомендуется там, где возможен и практичен перехват трафика. Аутентификация такого рода контролирует доступ к прокси; это не шифрование вашего трафика.

HTTP-прокси: пересылка и CONNECT

Для http:// цель, клиент отправляет прокси HTTP-запрос, цель которого совпадает с URI назначения; это режим пересылки. Для HTTPS-целей запрос CONNECT просит прокси открыть туннель. Согласно RFC 9110, целью CONNECT является только host:port и порта по умолчанию нет, поэтому клиент всегда должен его передавать. Любой ответ 2xx означает, что туннель создан и обе стороны переходят в режим туннеля сразу после заголовков ответа. Любой другой ответ означает, что туннеля нет.

Два практических следствия:

• Проверьте и http:// и https:// URL через прокси и запишите статус, который прокси вернул для CONNECT. Успех при обычном HTTP ничего не говорит о туннелировании.
• Отказ в CONNECT не всегда означает неисправность. RFC 9110 говорит, что прокси, поддерживающие CONNECT, должны ограничивать его ограниченным набором известных портов или настраиваемым списком безопасных целей, поэтому отказ для нестандартного веб-порта может быть результатом политики.

В руководстве curl также отмечено, что операции через HTTP-прокси преобразуются в HTTP, поэтому некоторые операции, специфичные для протокола, могут быть недоступны, если не использовать туннель через прокси. Дополнительную информацию о HTTPS-прокси см. в Что такое HTTPS-прокси и как работают SSL-прокси?.

SOCKS5: классифицируйте сбои по коду ответа

Когда запрос SOCKS5 завершается ошибкой, причину указывает поле REP в ответе. RFC 1928 определяет, среди прочего, следующие значения:

REP	Значение	Куда смотреть в первую очередь
X'00'	Успешно	Путь через прокси работает для этого запроса
X'02'	Подключение запрещено набором правил	Правила, применяемые прокси
X'03'	Сеть недоступна	Доступность сети за пределами прокси
X'04'	Хост недоступен	Доступность целевого хоста
X'05'	Соединение отклонено	Целевой адрес и порт
X'07'	Команда не поддерживается	Реализует ли сервер эту команду
X'08'	Тип адреса не поддерживается	Принимает ли он имя хоста или IP в таком виде

Запрос содержит команду (CONNECT X'01', BIND X'02', UDP ASSOCIATE X'03') и тип адреса (IPv4 X'01', доменное имя X'03' или IPv6 X'04'), поэтому клиент может отправлять либо имя хоста, либо IP-адрес. Если одна из форм отклонена с X'08', попробуйте другой.

Сравнение DNS-разрешения

Воспроизводимый способ увидеть, где разрешается имя хоста, — выполнить один и тот же запрос с обеими схемами и сравнить результаты:

curl --proxy 'socks5://PROXY_HOST:PROXY_PORT' -U 'USER:PASSWORD' 'http://ECHO_URL'
curl --proxy 'socks5h://PROXY_HOST:PROXY_PORT' -U 'USER:PASSWORD' 'http://ECHO_URL'

С socks5:// curl разрешает имя на вашем компьютере; при socks5h:// делает прокси. Если работает только один вариант, одной из возможных причин может быть разрешение имён, но не единственной: socks5h:// отправляет имя хоста, поэтому обработка прокси такого типа адреса тоже может иметь значение. Проверьте код ответа SOCKS5, например X'08' по типу адреса, прежде чем делать вывод. Совпадающий результат не доказывает, что ничто другое в вашей системе не допускает утечки запросов; этот тест лишь различает эти два режима curl.

Используйте актуальную версию curl для socks5h:// тесты. Рекомендательный CVE-2023-38545 касается имён хостов, передаваемых прокси SOCKS5 для удалённого разрешения, длина которых не должна превышать 255 байт, и рекомендует curl 8.4.0 или новее. Проверьте установленную версию и сборку, а не предполагайте.

Измерьте исходящий IP

Выберите IP-echo адрес подключения, которому вы доверяете, запросите его один раз напрямую и один раз через прокси и сравните два адреса. Именно этот запрос и является измерением. Не берите адрес из ответа SOCKS: в ответе на CONNECT поля BND.ADDR и BND.PORT описывают адрес, который сервер назначил для соединения с целевым узлом, а BND.ADDR часто отличается от IP, который вы использовали для подключения к SOCKS-серверу, поэтому он не заменяет то, что видит целевой сервер. Рассматривайте результат как наблюдение только по этому одному запросу.

Что эти проверки не могут показать

• Ping и traceroute. SOCKS5 — это прослойка между прикладным и транспортным уровнями, и он не пересылает ICMP, поэтому эти инструменты не измеряют путь через SOCKS5.
• UDP и WebRTC. UDP ASSOCIATE — это команда, которую конкретный сервер может как поддерживать, так и не поддерживать; он может ответить X'07'. RFC 8828 отмечает, что HTTP-прокси и большинство SOCKS-прокси не поддерживают UDP, поэтому WebRTC переключается на TCP через прокси. Проверяйте поведение, зависящее от UDP, отдельно.
• Ваша сборка curl. Какие опции и типы подключения прокси доступны, зависит от версии и сборки, которую вы используете.

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

FAQ

Что использовать: socks5:// или socks5h://?

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

Почему мой прокси отклоняет подключение к нестандартному (не веб) порту?

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

Шифруется ли пароль прокси?

Шагом SOCKS5 с именем пользователя и паролем — нет: по RFC 1929 они передаются открытым текстом. Защищено ли соединение чем-то ещё, зависит от используемой настройки.

Следующий шаг

Когда ваши проверки дали чёткие результаты и вы хотите выбрать прокси-сервис, Открыть Proxyca в Telegram.