Вчера снова прилетел вопрос в личку: купил прокси, вставил в антидетект, половина аккаунтов отвалилась за сутки. Чекер выдал «живой». В этом «вроде живого» и живёт вся проблема: трафик шёл напрямую, узел отвечал через раз, а настоящий адрес светился в заголовках запроса.
Ниже - четыре независимых теста плюс браузер, терминал, Telegram и WhatsApp. Каждый показывает своё, и вместе они дают честную картину вместо гадания на кофейной гуще.
Чекер проверяет базу репутации, а не ваш узел
Самая частая путаница. Онлайн-чекер принимает адрес и порт, лезет во внешнюю базу репутации и возвращает вердикт: знает ли система этот адрес как прокси. К самому серверу он часто вообще не подключается. Отсюда два следствия, которые ломают голову новичкам.
Свежий домашний или мобильный адрес почти всегда получает «нет в базе». Не потому что мёртвый, а потому что база про него ещё не знает. Узел при этом прекрасно работает, и люди зря выбрасывают нормальные прокси. На Reddit в тредах по парсингу этот сценарий всплывает регулярно: человек берёт мобильный узел, чекер пишет «нет в базе», и рабочий прокси летит в мусорку.
И наоборот. Старый публичный прокси может годами светиться в базе, но быть уже убитым. Чекер скажет «прокси», а коннекта не будет. Вердикт «есть в базе» или «нет в базе» отвечает на вопрос репутации, а не работоспособности.
Ещё нюанс: такие базы используют антифрод-системы. Узел, засвеченный как публичный прокси, часть сервисов встречает настороженно. Для парсинга это часто неважно, для работы с аккаунтами - критично.
Рабочий прокси это четыре отдельных теста
Когда спрашивают, как проверить прокси на работоспособность, я уточняю: что именно проверяем? Слово «работает» распадается на четыре независимые вещи, и провал любой ломает задачу по-своему.
Первое - доступность. Сервер принимает соединение на указанном порту и отвечает на запрос. Проверяется за секунды, и именно тут выясняется, что прокси продан, а порт закрыт.
Второе - подмена адреса. Сайт должен видеть адрес узла, а не ваш домашний. Банально, но треть проблем именно здесь: настройки применились не в том профиле, расширение перехватило трафик, система взяла прокси из другого места.
Третье - анонимность. Даже с подменённым адресом узел может добавлять заголовки вида X-Forwarded-For или Via и сдавать ваш настоящий адрес. Прозрачный прокси честно передаёт, что за ним стоит живой человек с конкретным IP.
Четвёртое - стабильность и скорость. Один удачный ответ не значит, что узел выдержит сотню запросов подряд. Мобильные прокси любят отваливаться на переключении вышки, серверные - умирать под нагрузкой. Один удачный пинг ничего не доказывает.
Проверка через браузер: куда нажимать
Самый быстрый способ убедиться, что трафик реально идёт через узел. Берём отдельный профиль браузера, чтобы не сломать основной.
В Chrome идём в настройки, дальше «Система», затем «Настройки прокси компьютера». Откроется системное окно Windows. Вкладка «Подключения», кнопка «Настройка сети». Ставим галочку на ручную настройку, вписываем адрес и порт для HTTP и HTTPS. Для SOCKS5 отдельное поле ниже, там же версия протокола.
В Firefox проще: настройки, раздел «Основные», самый низ, «Настройки сети», кнопка «Настроить». В открывшемся окне выбираем ручную настройку и заполняем поля. Firefox удобен тем, что настройки живут внутри профиля и не трогают систему.
Дальше открываем любой сервис, который показывает ваш IP. Видите адрес узла и его гео - прокси работает. Видите свой домашний - не работает, что бы там ни говорил чекер. Отдельно проверьте сайт, который показывает заголовки запроса: если в них есть ваш настоящий адрес, узел прозрачный.
И маленькая хитрость, которая экономит нервы. Откройте две вкладки: одну через прокси, вторую в обычном профиле. Сравните адреса. Расхождение - есть, совпадение - прокси не применился.
Командная строка показывает то, что скрывает браузер
Браузер врёт чаще, чем кажется. Кэш, Service Worker, предзагруженные соединения, расширения - всё это может увести часть трафика мимо. Терминал лишён этих сюрпризов.
Достаточно одного запроса с указанием прокси. У curl это флаг -x, дальше адрес узла с логином и паролем, потом адрес сервиса, который возвращает ваш IP. Ответ должен совпасть с адресом прокси. Если запрос висит дольше десяти секунд и падает с ошибкой соединения - узел не отвечает, и никакие настройки тут не помогут.
Полезно прогнать тот же запрос трижды подряд. Первый ответ может быть быстрым, а второй и третий упадут. Так вы сразу увидите нестабильный узел, который в браузере выглядит рабочим, потому что там всё закэшировано.
Для SOCKS5 в curl используется отдельный префикс схемы. Разница важна: HTTP-прокси работает только с веб-трафиком, SOCKS5 тянет любые TCP-соединения. Проверили HTTP-порт, а приложение потом стучится по SOCKS5 - результаты будут противоположными.
Telegram: где включать и на что смотреть
В десктопной версии заходим в настройки, раздел «Продвинутые», пункт «Тип подключения». Дальше «Добавить прокси». Выбираем SOCKS5, вписываем хост, порт, логин и пароль, сохраняем и включаем переключатель.
На Android путь такой: настройки, «Данные и память», «Тип подключения», «Добавить прокси». На iOS аналогично, через настройки и раздел с данными.
Как понять, что работает. В списке прокси Telegram сам показывает пинг до узла - это уже неплохой индикатор. Дальше открываете чат с медиа: фото и видео должны грузиться без зависания на крутящемся кружке. Если статус соединения мигает и возвращается к исходному, узел либо медленный, либо режет часть трафика.
Важный момент по архитектуре. MTProto в Telegram работает поверх собственного протокола, и SOCKS5 тут выступает просто транспортом: шифрование остаётся на стороне приложения, прокси видит только поток байтов. Поэтому проверять его нужно на живом трафике, а не только пингом.
WhatsApp и другие мессенджеры: системный уровень
В WhatsApp отдельной настройки прокси нет. Приложение ходит через то, что настроено в системе. На Android: настройки Wi-Fi, долгое нажатие на сеть, «Изменить сеть», «Дополнительные параметры», «Прокси», режим «Вручную». На iOS: настройки Wi-Fi, значок информации рядом с сетью, самый низ, «Настроить прокси», «Вручную».
Проверка простая: отправляете себе сообщение с другого устройства и смотрите на время доставки. Плюс индикатор «онлайн» должен обновляться. Если сообщения уходят, но медиа не грузится, скорее всего узел режет часть портов.
Учтите, что системный прокси в мобильной ОС действует на всё сразу. Настроили ради одного приложения, а через узел пошёл весь телефон, включая банковские приложения. Для тестов лучше отдельное устройство или эмулятор.
Почему скорость в чекере не имеет отношения к делу
Онлайн-чекер меряет время отклика на один запрос со своей стороны. Это число зависит от расстояния между сервером проверки и узлом, от текущей загрузки и от того, насколько удачно совпал момент. К реальной работе оно относится примерно никак.
Нужна настоящая скорость - гоняйте реальную задачу. Скачайте файл мегабайт на десять через прокси и замерьте время. Или прогоните сотню параллельных запросов и посмотрите, сколько из них вернулись с ошибкой. Вот это уже похоже на правду.
С задержкой отдельная история. Для парсинга важна пропускная способность, для работы с интерфейсами - пинг. Мобильный прокси с пингом 200 мс может быть вполне комфортным, а серверный с пингом 40 мс - валиться на каждом десятом запросе.
Проверка парка из сотни узлов
Ручками такое не делают. Логика простая: список узлов, параллельные запросы с таймаутом, запись результатов в таблицу. На выходе получаете три колонки - отвечает, не отвечает, отвечает нестабильно. Последняя самая коварная, и именно её обычно игнорируют.
В проверку стоит добавить ещё пару условий. Совпадение гео с ожидаемым: купили немецкий узел, а он светится как нидерландский, значит база рассинхронизирована. И проверку утечек на уровне браузера: WebRTC умеет отдавать локальный адрес мимо прокси, и с этим надо разбираться отдельно, через настройки самого браузера или антидетекта.
Для регулярного мониторинга удобно держать простой скрипт на cron, который раз в час прогоняет список и складывает результаты в лог. Тогда вы видите динамику, а не разовый снимок. Прокси, который стабильно держится неделю, стоит дороже, чем три, которые сыпятся каждый день.
Пять ошибок, которые я вижу чаще всего
- Проверять прокси чекером и считать вердикт финальным. Чекер смотрит базу, а не узел.
- Тестировать один раз. Узел, который ответил утром, к вечеру может быть мёртв, а вы уже залили на него рабочую сессию.
- Проверять HTTP-порт, а работать через SOCKS5. Разные протоколы, разные результаты.
- Забывать про заголовки. Адрес подменён, а настоящий утекает в X-Forwarded-For, и весь смысл теста теряется.
- Не сверять гео. Адрес рабочий, но из другой страны, и локальный сервис ведёт себя странно.
Где брать узлы, которые не придётся перепроверять каждые полчаса
Половина проблем с проверкой уходит, когда прокси изначально нормальные. В каталоге 3seller.com/proxy есть фильтры по гео, протоколу и типу узла: серверные, резидентские, мобильные. Разница принципиальная. Мобильные живут на реальных операторских адресах и почти не светятся в базах репутации, серверные дешевле и быстрее, но заметнее для антифрода.
Практический смысл каталога в том, что параметры видны до покупки, а не после. Выбрали страну, протокол, срок аренды - получили доступ. Дальше те самые четыре теста, и вы уже понимаете, годится узел под вашу задачу или нет. Сравнить условия по разным типам можно там же: https://3seller.com/proxy.
Мой обычный порядок действий выглядит так. Беру минимальный объём, прогоняю через терминал на доступность, потом через браузер на подмену адреса и заголовки, потом даю реальную нагрузку в течение часа. Держится - докупаю объём. Сыпется на втором шаге - меняю, а не пытаюсь починить настройками.
Проверка прокси - не разовая акция перед запуском, а часть рабочего процесса. Держите под рукой три инструмента: терминал для быстрой проверки доступности, браузер с отдельным профилем для подмены и утечек, скрипт для мониторинга парка. Тогда вопрос «а работает ли он» перестанет всплывать в самый неподходящий момент.