Бесплатные прокси чаще выходят из строя, чем работают. Публичный список перебирает десятки тысяч кандидатов, и ваша задача — найти небольшое подмножество, которое в данный момент живо, достаточно быстро и не является активно вредоносным. Пять тестов, каждый дешёвый, выполняются по порядку.
Тест 1: Доступность по TCP
curl --connect-timeout 5 --proxy http://1.2.3.4:8080 \
-s -o /dev/null -w "%{http_code}\n" \
https://api.ipify.orgНенулевой код возврата или пустой ответ означают, что прокси мёртв. Около 60–80% любого бесплатного списка в любой момент времени не пройдут этот тест. Пропустите сразу и не повторяйте.
Тест 2: Проверка исходящего IP
Тот же вызов возвращает публичный IP, с которого исходил запрос. Если он равен 1.2.3.4 — адресу прокси — прокси правильно перенаправляет трафик. Если он равен вашему локальному IP, прокси сломан или прозрачен: он принял соединение, но на самом деле не ретранслировал через себя. Считайте это ошибкой, даже если TCP прошёл успешно.
Тест 3: Прозрачность заголовков
curl --proxy http://1.2.3.4:8080 https://httpbin.org/headersОтвет возвращает заголовки, которые получил целевой сервер. Ищите X-Forwarded-For, Via или Forwarded с вашим реальным IP. Если вы их найдёте, прокси работает в прозрачном или анонимном режиме, а не в элитном. Для HTTPS через CONNECT это не имеет значения — целевой сервер видит только рукопожатие TLS, никаких заголовков приложения — но для обычного HTTP это определяет, подходит ли прокси для поставленной задачи.
Тест 4: Задержка под нагрузкой
Однократное измерение времени шумное. Выполните десять последовательных запросов через прокси и возьмите медиану. Всё, что выше двух секунд, непригодно для интерактивной работы. Менее 500 миллисекунд — конкурентоспособно с отсутствием прокси. Между этими значениями прокси подходит для пакетного сбора данных, но не для просмотра веб-страниц.
Тест 5: Целостность отпечатка TLS
Подключитесь через прокси к известному TLS-конечному узлу и проверьте, что цепочка сертификатов совпадает с той, что вы получаете без прокси. Несовпадение означает, что прокси перехватывает TLS — выполняет атаку «человек посередине», и ваш «зашифрованный» трафик на самом деле не шифруется после прокси. Это редко встречается на правильно настроенных SOCKS-прокси (они не видят TLS), но появляется на неправильно настроенных корпоративных HTTPS-прокси и на некоторых вредоносных публичных узлах. openssl s_client -proxy 1.2.3.4:8080 -connect example.com:443 выводит цепочку.
Практический рабочий процесс
Загрузите список, отфильтруйте по стране и протоколу, распределите пять тестов по параллельному пулу из примерно 50 рабочих и сохраните выжившие. Из 100 сырых кандидатов типичный запуск даёт 5–15 пригодных записей. Скорость устаревания составляет примерно 30–60 минут для HTTP и HTTPS, немного дольше для SOCKS — запланируйте обновление с такой периодичностью и передайте выживший набор в ваш скрапер или конфигурацию браузера. Кэшируйте результаты тестов на время жизни одного пакета и повторно тестируйте на следующем.