Прокси для парсинга на сервере: частые ошибки и решения

MAATRIX

Прокси на сервере поднят, парсер запущен — а через час сыпятся 429, вылезает капча и данные приходят рваными кусками. Знакомая картина. Большинство проблем с прокси для парсинга — это не мистика, а десяток типовых ошибок, каждая из которых лечится за пару минут, если знать, куда смотреть. Разберём их по порядку: от самых частых к неочевидным, с конкретными командами и настройками. Важно сразу разделить два класса причин. Первый — поведение парсера: слишком частые запросы, отсутствие пауз, подозрительные заголовки. Второй — состояние самого прокси: репутация IP, утечки, нехватка ресурсов. Диагностику всегда начинайте с вопроса «что именно видит целевой сайт», потому что чаще всего блокировка приходит не из-за прокси как такового, а из-за того, как через него ходит ваш парсер. Ниже — типовые симптомы и то, что реально помогает.

Ошибка 429 и блокировка по частоте запросов

Код 429 Too Many Requests — самая частая жалоба. Сайт видит, что с одного адреса за секунду прилетает десяток обращений, и включает защиту. Проблема не в прокси, а в отсутствии пауз между запросами.

Первое решение — задержки. Добавьте случайную паузу между обращениями, чтобы поведение выглядело человеческим:

import time, random
time.sleep(random.uniform(1.5, 4.0))

Второе — снизьте параллелизм. Пять потоков через один IP почти гарантированно упрутся в лимит; начните с одного-двух и повышайте, следя за кодами ответов. Третье — уважайте заголовок Retry-After, если сайт его присылает: он прямо говорит, сколько ждать. Если 429 не уходит даже с паузами, значит, исчерпан лимит самого адреса — пора добавлять IP в пул или менять сервер. Наращивать поток бессмысленно, пока не решена базовая частота.

Капча Cloudflare и защита от ботов

Капча появляется, когда репутация IP низкая или поведение клиента похоже на бота. С общими и дешёвыми прокси это норма: адрес уже засвечен сотней чужих ботов. Лучшее лекарство — чистый выделенный IP, который принадлежит только вам и не имеет истории нарушений.

Кроме адреса, капчу провоцируют мелочи:

• Пустой или дефолтный User-Agent вроде python-requests/2.31. Подставляйте реальный UA браузера.
• Отсутствие заголовков Accept, Accept-Language, Referer, которые всегда шлёт настоящий браузер.
• Игнор cookies. Сессионные куки надо хранить и возвращать, иначе каждый запрос выглядит как первый визит.

Для сайтов на JS-рендеринге обычный HTTP-парсинг не проходит вовсе — нужен headless-браузер (Playwright, Puppeteer), пропущенный через тот же прокси. Он выполняет JavaScript и проходит проверки, которые статический запрос завалит. Учтите, что headless-браузер тяжелее HTTP-клиента и требует больше памяти, поэтому под него закладывайте хотя бы 2 ГБ RAM на сервере.

Отдельно про частоту появления капчи: она напрямую зависит от того, сколько людей делят ваш IP. На выделенном адресе, который принадлежит только вам, Cloudflare-проверка возникает в разы реже, чем на общем прокси из публичного списка, где рядом сидят десятки чужих ботов. Это не тонкая настройка, а фундамент — сначала чистый адрес, потом всё остальное.

Утечка реального IP мимо прокси

Классика: прокси настроен, но в логах целевого сайта светится реальный адрес сервера или домашний адрес. Причин обычно две.

Первая — DNS-запросы идут в обход прокси. Для SOCKS5 включайте удалённое разрешение имён: в Python это схема socks5h://, а не socks5://. Буква h означает, что DNS резолвится на стороне прокси. Вторая причина — заголовки X-Forwarded-For и Via, которые прокси добавляет по умолчанию и которые содержат исходный IP. В Squid их убирают строками:

forwarded_for delete
via off
request_header_access X-Forwarded-For deny all

Проверить утечку просто: направьте парсер на сервис, который возвращает видимый IP, и сравните с адресом VPS.

curl -x socks5h://parser:pass@127.0.0.1:1080 https://api.ipify.org

Если в ответе адрес вашего VPS, а не домашний — прокси работает честно.

Отвал соединений и таймауты

Соединения рвутся, парсер висит и падает по таймауту — обычно виноваты слишком жёсткие тайминги или нехватка ресурсов. Сначала проверьте лимит открытых файлов: каждое соединение — это файловый дескриптор, и дефолтные 1024 быстро кончаются.

ulimit -n
echo "* soft nofile 65536" >> /etc/security/limits.conf
echo "* hard nofile 65536" >> /etc/security/limits.conf

Дальше — тайм-ауты на стороне парсера. Ставьте разумные значения (10–30 секунд) и обязательно ретраи с экспоненциальной задержкой: первый повтор через 2 секунды, второй через 4, третий через 8. Это спасает от временных сбоев сети без ручного вмешательства. Если отваливается сам прокси-демон, смотрите его логи и системный журнал journalctl -u squid — часто причина в OOM-killer, который убил процесс из-за нехватки памяти при разросшемся кэше.

Медленная работа и узкие места

Парсинг ползёт, хотя канал сервера широкий. Первый подозреваемый — DNS: если резолвинг идёт на медленный или далёкий сервер, каждая новая ссылка добавляет задержку. Пропишите быстрые резолверы и включите кэш DNS в прокси. В 3proxy это nscache 65536, в системе — локальный кэширующий резолвер.

Второй подозреваемый — локация. Сервер в США, а парсите вы российский сайт: каждый запрос летит через океан и обратно, добавляя по 150–200 мс на круг. Держите прокси там, где живёт целевой ресурс, — это режет задержку в разы и заодно снижает риск гео-редиректов. Третье узкое место — избыточная параллельность без учёта пропускной способности: сотня одновременных соединений на слабом VPS упрётся в CPU при разборе TLS, и скорость просядет не из-за сети, а из-за процессора. Наращивайте потоки постепенно, наблюдая за нагрузкой в htop и трафиком в iftop, и фиксируйте потолок, за которым время ответа начинает расти.

Проблемы с оплатой и стабильностью сервера

Отдельная категория проблем — не техническая. Парсинг встал, потому что сервер отключили за неоплату, а оплатить зарубежный VPS российской картой не вышло. Для регулярных задач это критично: данные должны собираться без простоев.

MAATRIX закрывает этот вопрос — принимает карты российских банков, СБП, криптовалюту и токен MAAT, поэтому сервер под парсинг не отвалится из-за платёжки. А чистый выделенный IP в нужной локации решает большую часть проблем с капчей и блокировками ещё до того, как вы допишете первую строку парсера. Начать сбор данных без блокировок можно за пару минут после заказа.

Частые вопросы