В три часа ночи парсер встал. В логах пусто, задача не выполнена, а утром сдавать отчёт. У меня так было раз пять, пока я не перестал верить слову «работает» от поставщика и не начал проверять каждый узел руками. Проверить работоспособность прокси сервера можно за две минуты, если знать, куда смотреть. Ниже мой рабочий порядок действий: от проверки в браузере до анализа кодов ответа и тестов SOCKS5.
Сначала отделяем «умер» от «неправильно настроен»
Половина обращений в поддержку по прокси заканчивается фразой «у меня не работает». В девяти случаях из десяти сервер живой, просто в настройках перепутан порт, логин или тип протокола. Второй частый вариант: прокси жив, но конкретный сайт его режет. Третий: узел отвечает, но с задержкой в восемь секунд, и парсер отваливается по таймауту.
Проверка идёт слоями. Сначала соединение, потом авторизация, потом реальный запрос к целевому ресурсу, потом стабильность. Прыгать сразу к последнему пункту смысла нет, будете чинить не ту проблему.
Бесплатные списки из телеграм-каналов проверяйте дважды. Половина адресов мертва ещё до того, как вы их скопировали. Живые узлы дешевле добрать в каталоге прокси, чем тратить вечер на реанимацию случайных IP.
Браузер: сорок секунд, чтобы увидеть картину
Самый быстрый способ понять, дышит ли прокси вообще. Берём Firefox или Chrome, открываем настройки сети. В Firefox это «Настройки» → «Основные» → «Настройки сети» → «Ручная настройка прокси». В Chrome настройки прокси живут в системе, поэтому на Windows это «Параметры» → «Сеть и Интернет» → «Прокси».
Вбиваем адрес и порт. Если есть авторизация, ставим галочку и вводим логин с паролем. Сохраняем, открываем любой сайт. Страница не грузится? Смотрим на текст ошибки. Браузер честно скажет, что не может подключиться к прокси или что прокси отклонил соединение. Разница принципиальная.
Если сайт открылся, но показывает капчу или урезанную версию, прокси работает, а вот IP попал в чёрный список. Такое часто бывает с дешёвыми пулами, где сотни людей сидят на одном адресе. Для парсинга это приговор, для разовой проверки гео, возможно, и нормально.
curl: одна команда, которая не врёт
Браузер удобен, но не даёт деталей. Мне нужны код ответа, время соединения и понимание, на каком этапе всё сломалось. Тут в игру вступает curl. Он есть в Linux и macOS из коробки, на Windows ставится за минуту.
Базовый синтаксис: curl -x http://host:port -I https://site.com. Если нужна авторизация, добавляем -U user:pass. Флаг -I просит только заголовки, этого достаточно, чтобы увидеть статус. Для диагностики я добавляю -v, чтобы читать рукопожатие, и --connect-timeout 5, чтобы не ждать вечность.
Что смотреть в ответе. Код 200 или 301 означает, что прокси пропустил запрос. Код 407 говорит о проблеме с логином или паролем. 403 значит, что прокси жив, но целевой сайт не пускает. 502 и 504 почти всегда вина самого прокси или его апстрима. Ошибка Connection timed out означает, что порт закрыт или адрес недоступен.
Для SOCKS5 команда чуть другая: curl --socks5-hostname user:pass@host:port -I https://site.com. Приставка hostname важна. С ней DNS-запрос уходит через прокси, а не решается на вашей машине. В парсинге это критично: локальный DNS может выдать вас с головой, даже если IP подменён.
Люблю добавлять в конец -w "%{http_code} %{time_total}\n". На выходе получаю код и полное время запроса. Пять секунд на ответ это уже звоночек, десять это почти наверняка мёртвый узел для серьёзной нагрузки.
Онлайн-чекеры: три способа ввода и проверка на нескольких сайтах
Когда под рукой нет терминала или нужно быстро прогнать десяток адресов, выручают онлайн-инструменты. Нормальный прокси-чекер принимает данные тремя способами. Первый: адрес, порт, логин и пароль в отдельные поля. Второй: всё одной строкой через разделитель, например 123.123.123:4200:log:pass. Если авторизации нет, хватает IP и порта. Третий: выбор из списка, если вы покупали узлы у этого же провайдера.
Хороший чекер не ограничивается одним запросом. Он проверяет соединение на нескольких сайтах, чтобы отсечь ситуацию, когда конкретный ресурс лежит или режет конкретную подсеть. Результат по одному домену всегда приблизительный.
Онлайн-сервис видит ваш IP и данные прокси. Для тестовых узлов это не проблема, для корпоративных лучше гонять проверки со своей машины через curl или внутренний скрипт. И не устанавливайте ради проверки сомнительные расширения. Приличному чекеру хватает браузера, никакого дополнительного софта не нужно.
Проверяем не только «жив», но и «пригоден»
Рабочий прокси и пригодный прокси это разные вещи. Узел может отвечать кодом 200 и при этом быть бесполезным для задачи. Смотрю на четыре параметра.
Скорость. Для парсинга комфортно до двух секунд на запрос. Для работы в браузере до пяти. Всё, что выше, превращает автоматизацию в лотерею с таймаутами.
Стабильность. Один удачный запрос ничего не значит. Прогоняю пять-десять запросов подряд и смотрю на разброс времени и количество ошибок. Если из десяти два упали, узел будет сыпаться и дальше.
Геолокация и ASN. Открываю сервис, который показывает IP, страну и провайдера. Если заявлена Германия, а по факту Нидерланды, продавец лукавит. Для тестирования рекламы и проверки выдачи по регионам это критично.
DNS и заголовки. Проверяю, не протекает ли DNS мимо прокси, и смотрю, не подменяются ли заголовки. Некоторые пулы добавляют свои X-Forwarded-For, и сайт сразу понимает, что вы за прокси. Для чувствительных задач такой узел бесполезен.
Telegram и WhatsApp: где смотреть настройки в приложении
С мессенджерами отдельная история. В Telegram прокси настраивается внутри приложения. Открываете «Настройки» → «Продвинутые настройки» → «Тип соединения» → «Прокси» → «Добавить прокси». Дальше выбираете тип, SOCKS5 или MTProto, вводите адрес, порт и секрет для MTProto. Приложение само покажет статус подключения и задержку в миллисекундах.
Если статус «Подключено», но сообщения не уходят, проблема не в прокси, а в самом узле или в секрете. Для MTProto секрет это часть ключа, одна опечатка и соединения не будет. Для SOCKS5 проверьте логин и пароль, если они есть.
В WhatsApp на Android настройка живёт в разделе «Хранилище и данные» → «Прокси». На iOS чаще используют системный прокси через настройки Wi-Fi: «Настройки» → «Wi-Fi» → значок информации рядом с сетью → «Настройка прокси» → «Вручную». Это удобно, когда вы сидите в публичной сети отеля или кафе и хотите завернуть трафик через свой корпоративный узел. Тот же принцип работает для любого приложения, которое ходит через системные настройки.
Проверка простая: отправляете сообщение себе или в тестовый чат, смотрите на скорость доставки. Задержка больше трёх секунд это повод искать узел ближе.
SOCKS5 и MTProto: что именно проверять в архитектуре
С точки зрения архитектуры SOCKS5 работает на пятом уровне и не понимает, что именно вы передаёте. Он просто устанавливает TCP-соединение и пересылает байты. Проверять там особо нечего, кроме рукопожатия, авторизации и DNS. Если рукопожатие прошло, дальше всё зависит от целевого сервера.
MTProto устроен сложнее. Это не просто туннель, а протокол с шифрованием и мультиплексированием. При проверке смотрят на установку соединения, стабильность под нагрузкой и задержку. В корпоративной среде MTProto часто ставят на собственный VPS, чтобы не зависеть от сторонних узлов и держать трафик внутри своей инфраструктуры.
Для балансировки нескольких узлов проверяйте каждый отдельно. Один медленный прокси в пуле может тянуть вниз всю очередь запросов, если балансировщик не умеет выкидывать плохие соединения. Простой health check раз в минуту решает половину проблем с парсингом.
Чек-лист, который экономит день
Собрал порядок проверки, которым пользуюсь сам. Занимает минут десять на пул из двадцати адресов, если автоматизировать.
- Соединение: telnet или curl с таймаутом пять секунд. Порт открыт?
- Авторизация: код 407 значит неверный логин или пароль. Код 200 значит доступ есть.
- Реальный запрос: проверка на двух-трёх разных сайтах, а не на одном.
- Скорость и стабильность: пять запросов подряд, смотрим разброс времени.
- Гео и DNS: страна, провайдер, отсутствие утечек.
Если узел прошёл все пять пунктов, ему можно доверять. Если сыпется на третьем, не тратьте время на четвёртый.
Когда проще заменить пул, чем чинить каждый узел
Я сторонник проверки, но не мазохизма. Если из тридцати бесплатных адресов живых пять и те с задержкой в шесть секунд, экономия сомнительная. Время дороже. В каталоге прокси можно отфильтровать узлы по стране, типу и количеству, а не собирать их по форумам. Для парсинга и тестов гео это заметно спокойнее.
Проверка купленного пула всё равно нужна. Даже хороший провайдер выдаёт узлы, которые стоит прогнать через curl перед боевым запуском. Но хотя бы не приходится гадать, почему половина адресов не отвечает.
Начните с одной команды. Возьмите свой текущий прокси, подставьте адрес и порт в curl с таймаутом пять секунд и посмотрите на код ответа. Дальше станет понятно, чинить настройки или менять узел. Две минуты проверки экономят часы ночной отладки, проверено на себе.