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

Шаг 1: разрешается ли имя шлюза

Самая частая причина, которую принимают за мёртвый прокси. У curl для этого есть отдельный код выхода: 5 означает, что имя прокси не разрешилось, 7 — что до прокси не удалось подключиться. Это два совершенно разных случая, и в графических инструментах они выглядят одинаково.

curl -sS -x http://ШЛЮЗ:ПОРТ https://example.com -o /dev/null; echo "exit=$?"

# exit=5  -> DNS не разрешил имя шлюза (опечатка, свой DNS, корпоративный шлюз)
# exit=6  -> не разрешилось имя целевого сайта
# exit=7  -> шлюз не принял TCP-соединение (порт, файрвол, шлюз лежит)
# exit=28 -> таймаут
# exit=97 -> ошибка рукопожатия с прокси

Шаг 2: принимает ли прокси ваши доступы

Здесь важно не перепутать три ответа. 407 означает, что прокси не принял учётные данные, — про этот код есть отдельная статья. 403 может прийти и от прокси, и от сайта, и различаются они не всегда. А код выхода 97 говорит, что до HTTP дело не дошло вовсе: сломалось рукопожатие с прокси.

И проверять надо тем же протоколом и портом, которым будете работать. HTTP и SOCKS5 слушают разные порты, и успешная проверка по HTTP-порту не говорит о SOCKS-порте ничего: та же пара логин-пароль, отправленная на порт другого протокола, даёт либо отказ авторизации, либо обрыв без внятного сообщения. Если в работе будут оба, проверяйте оба.

Шаг 3: какой адрес видит сайт

Единственная проверка, которая отвечает на вопрос «работает ли прокси» по существу: посмотреть, чей адрес видит удалённая сторона. Если он ваш — прокси не применился, что бы ни было написано в настройках. Наша страница «Мой IP» показывает то же, что увидит сайт, плюс страну и провайдера по базам.

Шаг 4: сходится ли гео с реальностью

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

Шаг 5: куда уходят DNS-запросы

Это тот случай, когда одна буква в схеме меняет результат. socks5h:// означает, что имена разрешает прокси; socks5:// — что их разрешает ваша машина. Во втором случае целевой домен уходит вашему провайдеру, даже если весь трафик идёт через прокси. Именно этот механизм и показывает тест утечки DNS.

# Имя разрешает прокси — утечки нет
curl -sS -x socks5h://ШЛЮЗ:ПОРТ https://example.com -o /dev/null -w '%{http_code}\n'

# Имя разрешает ваша машина — домен виден вашему провайдеру
curl -sS -x socks5://ШЛЮЗ:ПОРТ  https://example.com -o /dev/null -w '%{http_code}\n'

Шаг 6: что выдаёт браузер помимо прокси

Здесь чаще всего и расходятся результаты: curl проверку проходит, а браузер палит адрес. Причина в том, что WebRTC и системный DNS — это не HTTP, и через HTTP-прокси они не идут вовсе. Проверка анонимности смотрит именно на это: какой адрес отдаёт WebRTC, совпадает ли часовой пояс со страной выхода, что видно в заголовках.

Шаг 7: скорость и где именно она теряется

Медленно — тоже не диагноз, пока не известно, на каком участке. curl умеет разложить время по этапам, и из этого сразу видно, чей это участок: время до соединения — это хоп до шлюза, а разница между началом передачи и завершением рукопожатия — уже целевой сайт.

curl -sS -x http://ШЛЮЗ:ПОРТ https://example.com -o /dev/null \
  -w 'connect=%{time_connect} tls=%{time_appconnect} first=%{time_starttransfer} total=%{time_total}\n'

# connect большой -> проблема на пути до шлюза
# first минус tls большой -> тормозит целевой сайт, а не прокси

Чем это проверять

Все шаги выше делаются одной командой curl, но у нас есть и страницы под каждый: адрес выхода и провайдер, проверка анонимности с WebRTC и часовым поясом, тест утечки DNS, замер скорости, WHOIS по диапазону и проверка доступности сайта. Они бесплатны и не требуют регистрации — удобно, когда нужно показать результат заказчику или приложить к обращению в поддержку.

И последнее, про порядок: если сломался шаг 1, проверять шаг 5 бессмысленно. Большая часть потерянного на прокси времени — это проверки, сделанные не в том порядке.