Купил пачку прокси, вставил в скрипт, запустил парсер - 40% ошибок. Или хуже: настройки вроде живые, запросы уходят, а на выходе пусто. То ли прокси сдохли, то ли конфиг сам сломал. Знакомая ситуация.
Проблема в том, что большинство проверяет прокси неправильно. Вставляет адрес в первый попавшийся чекер, видит зеленую галочку и успокаивается. А потом удивляется, почему через час ничего не работает. Правильный порядок действий - от быстрой онлайн-проверки до тестов, которые не покажет ни один чекер.
Сначала отдели мух от котлет: умер прокси или умер твой запрос
Первое, что я делаю, когда «прокси не работает» - проверяю, а работает ли интернет без него. Третья часть обращений в моей практике заканчивалась фразой «а у вас Wi-Fi отвалился». Смешно, но факт.
Второй шаг - понять, на каком уровне отвалилось. Прокси может быть живым, но конкретный сайт его не пускает. Или пускает, но отдает капчу. Или соединение устанавливается, а ответ идет 12 секунд, и скрипт по таймауту уже всё бросил. Это три разные проблемы, и лечатся они по-разному.
Перед любой проверкой ответь себе на два вопроса. Прокси вообще принимает соединение? И если принимает, то что именно ломается дальше. После этого подбираем инструмент.
Онлайн-чекер: самый быстрый способ, но с нюансами
Онлайн-чекер - первая проба пушечки. Открыл страницу, вбил данные, получил результат за пару секунд. Сервисы тестируют прокси на нескольких сайтах, чтобы результат был честным, а не «повезло с одним доменом».
Три способа ввода данных. Люди постоянно путают второй с третьим.
Первый - по полям. IP в одно окно, порт в другое, логин и пароль в третье и четвертое, если прокси приватный. Самый надежный: ничего не перепутаешь.
Второй - по маске, одной строкой. Формат: адрес, двоеточие, порт. Авторизация через двоеточие: логин и пароль. Многие чекеры понимают вариант с собакой. Главное - не перепутать порядок: сначала логин, потом пароль, потом адрес. Перепутал - получишь «невалид» на живом прокси и полчаса будешь искать проблему не там.
Третий - по номеру заказа. Работает только у продавца, где брал прокси: выбираешь сервер из списка, чекер сам подставляет данные. Удобно, когда серверов десятки.
Что показывает результат и какие цифры считать нормой
Хороший чекер отдает не просто «работает / не работает». Смотри на четыре вещи.
Время отклика. Пинг до 300 мс для парсинга - нормально. До 800 мс - терпимо, если не гонишься за скоростью. Выше секунды: прокси технически живой, но для массовых задач почти бесполезен. Один такой сервер на 50 запросов в минуту превратит скрипт в черепаху.
Тип прокси. HTTP, HTTPS, SOCKS4, SOCKS5 - чекер должен определить сам. Купил SOCKS5, а сервис рапортует HTTP: либо порт не туда вставили, либо продавец выдал не то, что обещал. Оба варианта неприятные, но лучше узнать сразу.
Уровень анонимности. Три категории: прозрачный, анонимный, элитный. Прозрачный палит настоящий адрес в заголовках - для рабочих задач это мусор. Анонимный скрывает тебя, но сообщает, что ты через прокси. Элитный ничего не выдает. Если чекер показывает прозрачность, а платил за приватность - разбирайся с продавцом.
Геолокация. Этот пункт чаще всего расходится с ожиданиями. Заказал Германию, чекер показывает Нидерланды. Иногда нормально: крупные провайдеры маршрутизируют через соседнюю страну. Но если гео скачет при каждом запросе - подсунули ротацию, которую не просили.
Проверка без сторонних сервисов: curl и браузер
Онлайн-чекер хорош для быстрой оценки, но не расскажет, как прокси поведет себя в реальном сценарии. Второй этап - проверка своими руками.
Самый честный способ - один запрос через curl с указанием прокси. Види код ответа, время и IP, который вернул сервер. Код 200, IP не твой - прокси работает. Код 407 - проблема с авторизацией, логин или пароль не подошли. Соединение висит и отваливается по таймауту - сервер недоступен или порт закрыт. Код 403 от конкретного сайта: прокси живой, но тебя не пускают именно туда.
Второй способ - через браузер. Заходишь в настройки сети, прописываешь прокси, открываешь сайт проверки IP. Заодно видишь, не ломается ли HTTPS, не вылезает ли капча, не рвется соединение на тяжелых страницах. Чекер такое не покажет.
Третий, который многие пропускают: проверить прокси под нагрузкой. Не один запрос, а двадцать подряд. Половина дешевых серверов отлично проходит одиночную проверку и умирает на пятом запросе. Это не баг чекера. Это реальность, в которой тебе работать.
Telegram и WhatsApp: куда нажимать и что смотреть
Если прокси нужен для мессенджера, проверять его онлайн-чекером почти бессмысленно. Тут другой протокол и другая логика. Разберем по шагам, без магии.
Telegram. Настройки - «Данные и память» - «Прокси». «Добавить прокси», тип - SOCKS5 или MTProto, адрес, порт, логин и пароль при необходимости. Сохраняешь, включаешь. Если соединение установилось, в списке появится значок с пингом. Пинг обновится через несколько секунд - это и есть проверка. Нет пинга: прокси не отвечает, даже если чекер в браузере показывал зеленый.
У MTProto и SOCKS5 разные порты и разные требования. Вставил MTProto-данные в SOCKS5 - получил вечное «соединение». Проверяй, что тип совпадает с тем, что выдали.
WhatsApp. Настройки - «Хранилища и данные» - «Использовать прокси» - «Настроить прокси». Вводишь хост и порт, сохраняешь. Приложение попробует подключиться и покажет статус. «Не удалось подключиться»: либо прокси мертв, либо не тот порт, либо сервер не пускает по этому протоколу.
Общее правило для обоих мессенджеров: проверяй на мобильном интернете, а не только на Wi-Fi. Часть корпоративных и публичных сетей режет нестандартные порты, и прокси тут ни при чем.
SOCKS5 и MTProto: что реально проверять на уровне архитектуры
«Работает / не работает» - слишком грубая линейка.
SOCKS5 работает на уровне сессии, а не отдельного запроса. Он не понимает HTTP-заголовки. Передавай хоть API-запрос, хоть бинарный поток. При проверке смотри не только на «отвечает», но и на стабильность удержания соединения. Если прокси рвет сессию через 30 секунд, скрипт с длинными запросами будет падать постоянно, хотя чекер скажет «ок».
Задержка на установку соединения у SOCKS5 обычно выше, чем у HTTP. Рукопожатие длиннее. 500 мс на коннект и 50 мс на запрос - нормально. Если на коннект уходит две секунды, а запрос летит мгновенно - сервер перегружен, ты стоишь в очереди.
MTProto - про шифрование пакетов и работу внутри протокола Telegram. Проверять сторонним чекером бессмысленно, он не поймет формат. Единственная честная проверка: подключиться клиентом и посмотреть, обновляется ли пинг. Все остальное - гадание.
Отдельная история - балансировка. Если пул из нескольких узлов, проверяй не только каждый по отдельности, но и то, как они переключаются. Один медленный узел в пуле из десяти замедлит всю работу: балансировщик будет на него натыкаться снова и снова.
Массовая проверка: когда серверов десятки
Вставлять пятьдесят прокси по одному в веб-форму - час жизни в пустую. Для пачек нужен другой подход.
Онлайн-чекеры с поддержкой списков принимают несколько строк в формате с маской. Прогнал, получил таблицу, выгрузил в CSV или TXT, отсортировал по пингу - видно, кто в топе, а кто в помойку. Самый быстрый путь, если не хочется писать код.
Если хочется - напиши простой скрипт: цикл по списку, по каждому адресу один запрос с таймаутом 5-7 секунд, запись результата в файл. Двадцать строк кода экономят часы ручной работы. Главное - не ставить таймаут в 30 секунд: проверка сотни мертвых прокси займет вечность.
Еще момент про массовую проверку: не гоняй ее через один и тот же сайт. Некоторые ресурсы начинают отдавать капчу после десятка запросов с одного IP, и получишь ложные «невалид» на живых прокси. Меняй целевые домены.
Почему бесплатные прокси умирают быстрее, чем ты успеваешь их проверить
На бесплатные списки ловятся почти все новички. Логика простая: сервер в открытом доступе за сутки проходит через сотни рук. Кто-то качает торренты, кто-то гоняет ботов. К моменту, когда ты его нашел, он уже перегружен или забанен на половине сайтов.
Проверить такой прокси чекером можно, он даже покажет «работает». Вот только через двадцать минут он умрет, и ты снова пойдешь ищешь. Если задача разовая - сойдет. Если это рабочий процесс - ты просто тратишь время на бесконечную ротацию.
Поэтому нормальный порядок: сначала смотришь на каталог, где серверы выдаются с гарантией и понятным сроком жизни. Например, на платформе 3seller видно протокол, гео и назначение узла сразу, до покупки. Экономит тот самый час, который иначе уходит на перебор.
Живой сценарий: парсинг маркетплейса и что я проверяю перед запуском
Так выглядит, когда я запускаю сбор данных с площадки, которая не любит автоматизацию.
Первый шаг - онлайн-чекер, пачкой. Отсеиваю все, что не отвечает или показывает пинг выше 800 мс. Остается 60-70% исходного списка.
Второй шаг - curl на целевой домен. Не на абстрактный сайт проверки IP, а на тот, с которого буду собирать данные. Тут выясняется неприятное: часть прокси отлично работает с обычными сайтами, а маркетплейс их уже знает и отдает капчу. Такие в работу не идут, хотя формально живые.
Третий шаг - нагрузочная проверка. Десять запросов подряд на каждый оставшийся прокси, смотрю на стабильность. Все, что отвалилось хотя бы раз, в резерв.
Четвертый - проверка гео и анонимности. Если задача требует конкретной страны, а чекер показывает другую, лучше узнать об этом до запуска, а не после того, как данные пришли не те.
После четырех шагов остается примерно треть исходного списка. И эти ребята работают неделями, а не часами. Разница в том, что я не поверил одной зеленой галочке.
Что делать, если прокси прошел проверку, но не работает
Такое бывает чаще, чем кажется. Причина почти всегда не в прокси.
Проверь авторизацию. Многие серверы пускают по IP-адресу, а не по логину с паролем. Если твой адрес не в белом списке - соединение устанавливается и сразу рвется. Чекер с сервера продавца этого не увидит.
Проверь протокол. HTTP-прокси не поймет SOCKS5-запрос и наоборот. Звучит очевидно, но путаница случается постоянно, особенно когда копируешь данные из разных источников.
Проверь таймауты в коде. Прокси отвечает за 900 мс, а в скрипте лимит 500. Формально все работает, фактически ты сам себе создал проблему.
И проверь DNS. Если прокси не резолвит домены, а ты передаешь ему имена, запрос упадет до соединения. Лечится настройкой, но искать причину можно долго.
Короткий чек-лист, который стоит держать под рукой
Перед любой рабочей задачей прогоняю прокси по пяти пунктам. Онлайн-чекер на доступность и пинг. Проверка типа и уровня анонимности. Один запрос curl на целевой домен. Серия из десяти запросов на стабильность. Сверка гео с ожиданиями.
Пять минут работы. Зато потом не приходится на ходу переписывать скрипт, потому что половина пула оказалась тыквой.
Не проверяй прокси один раз и навсегда. Сервер, который был идеален утром, к вечеру может быть перегружен. Если процесс постоянный, сделай проверку регулярной - раз в сутки хотя бы. Сложное отличает стабильный пайплайн от бесконечной борьбы с ошибками.
Начни с малого: возьми текущий список, прогони через чекер пачкой, отсеки все с пингом выше секунды и проверь оставшиеся на реальном целевом сайте. Уже на этом этапе станет видно, сколько рабочих узлов на самом деле. Результат обычно отрезвляет. А если хочешь сразу брать серверы с понятными характеристиками - загляни в каталог 3seller. Там видно, что покупаешь.