Классическая ситуация: скрипт для мониторинга цен на Wildberries или Ozon отлично отрабатывает на домашнем ноутбуке, а после переноса на VPS начинает получать 403, капчу или мгновенный бан по IP. Разработчик меняет заголовки, добавляет задержки — но результат не меняется. Проблема почти никогда в коде парсера как таком, а в окружении, из которого он делает запросы. Разбираем 7 конкретных причин и что менять, чтобы парсер стабильно работал именно на сервере.
Почему локально всё работает, а на сервере — бан
Когда вы запускаете парсер с домашнего компьютера, сайт видит запрос с обычного жилого IP-адреса вашего провайдера, из привычного региона, с реальным браузерным окружением, если вы используете Selenium или Playwright с настоящим профилем. Как только тот же скрипт переезжает на VPS в Германии, Нидерландах или США, картина меняется полностью: IP принадлежит дата-центру, TLS-отпечаток может отличаться из-за другой версии библиотек, часовой пояс сервера не совпадает с геолокацией IP, а частота запросов резко возрастает, потому что сервер работает 24/7 без перерывов.
Антибот-системы Wildberries, Ozon, Авито и большинства крупных маркетплейсов давно не смотрят только на User-Agent. Они анализируют совокупность десятков сигналов: тип IP, скорость и регулярность запросов, поведение на странице, соответствие заголовков и TLS-параметров, наличие cookies и историю сессии. Локальная машина случайно проходит проверку по большинству пунктов, сервер — почти по всем проваливается. Ниже — детальный разбор каждой причины.
Причина 1: IP дата-центра вместо жилого IP
Это причина №1 в 80% случаев. IP-адреса VPS и облачных серверов (AWS, DigitalOcean, Hetzner, обычные VDS-хостинги) находятся в базах дата-центров — ASN этих провайдеров публично известны и используются антибот-системами для мгновенной фильтрации трафика. Маркетплейсы применяют такие списки в первую очередь, потому что 95% автоматизированного парсинга идёт именно с серверных IP.
Решение — использовать IP, которые визуально не отличаются от обычного пользователя интернета. Для парсинга Wildberries, Ozon и Авито лучше всего подходят резидентные прокси: это реальные IP-адреса домашних провайдеров, выданные обычным абонентам. Antibot-системы видят такой запрос как трафик от живого пользователя, а не от сервера в дата-центре, что снимает большую часть блокировок сразу.
Причина 2: Нет ротации IP и лимита частоты запросов
На локальной машине вы делаете 20–50 запросов вручную во время тестов, и сайт этого не замечает. На сервере скрипт запущен по cron каждые 5 минут и обрабатывает тысячи товарных карточек подряд с одного IP. Такой паттерн — прямой сигнал для антибот-системы: реальный человек не может открыть 3000 страниц каталога за час без единой паузы.
Нужно вводить ротацию IP на пул прокси и лимитировать число запросов на один адрес в единицу времени. Практическое правило: не более 30–60 запросов с одного IP в минуту для карточек товара, с автоматической сменой адреса после каждой пачки запросов. Пример настройки ротации в Python через прокси-пул:
import requests
proxies_pool = [
"http://user:[email protected]:9000",
"http://user:[email protected]:9001",
"http://user:[email protected]:9002",
]
def get_page(url, session_id):
proxy = proxies_pool[session_id % len(proxies_pool)]
resp = requests.get(
url,
proxies={"http": proxy, "https": proxy},
headers={"User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64)"},
timeout=10
)
return resp.textПри сборе большого объёма карточек в сутки удобнее брать прокси с автоматической ротацией IP по запросу или по таймеру — это снимает необходимость держать список адресов вручную.
Причина 3: Заголовки и User-Agent не похожи на браузер
Многие парсеры на requests или aiohttp отправляют запрос с минимальным набором заголовков либо со стандартным User-Agent библиотеки, который сразу выдаёт скрипт (например python-requests/2.31.0). На локальной машине через браузер набор заголовков полный: Accept, Accept-Language, Accept-Encoding, Sec-Ch-Ua, Referer и другие — их совокупность выглядит естественно.
Нужно копировать полный набор заголовков реального браузера, включая порядок их отправки — некоторые антибот-системы проверяют даже это. Плюс важно ротировать User-Agent синхронно с версией TLS-отпечатка (см. следующий пункт), иначе несоответствие между заголовком браузера и реальным TLS-клиентом станет новым сигналом бота.
Причина 4: TLS/JA3-отпечаток выдаёт скрипт
Это менее известная, но крайне частая причина банов именно на сервере. Библиотеки requests, urllib, aiohttp используют свою реализацию TLS-хендшейка, которая отличается от реализации в Chrome или Firefox. Антибот-системы вычисляют JA3/JA4-отпечаток TLS-соединения — и он у python-скрипта совершенно не похож на отпечаток настоящего браузера, даже если заголовки скопированы идеально.
Решение — использовать библиотеки, которые эмулируют TLS-отпечаток браузера (например curl_cffi, tls-client в Python, или полноценный headless-браузер на базе Chromium через Playwright/Puppeteer). Второй вариант — работать не через чистый HTTP-клиент, а через управляемый браузерный движок в связке с антидетект-инструментом, где TLS и заголовки формируются реальным браузерным ядром, а не эмуляцией библиотеки.
Причина 5: Часовой пояс, локаль и DNS сервера
Если скрипт эмулирует браузер через Selenium или Playwright, антибот-система может проверять системный часовой пояс, язык интерфейса, DNS-резолвер и даже WebRTC-утечку реального IP сервера. VPS в дата-центре Франкфурта с системным часовым поясом UTC и DNS-провайдером хостера, при этом использующий прокси с IP из Москвы, создаёт явное несоответствие геоданных — это один из самых надёжных сигналов для детекта.
Все параметры окружения — часовой пояс, язык браузера, DNS, геолокация по WebRTC — должны соответствовать региону IP-адреса, который используется для запроса. Именно для решения этой задачи созданы антидетект-браузеры: Dolphin Anty, AdsPower, Multilogin, Octo Browser и GoLogin позволяют настроить отдельный «браузерный профиль» под каждый прокси, где автоматически подгоняются часовой пояс, локаль, разрешение экрана и WebRTC под геолокацию IP.
Причина 6: Паттерн запросов слишком «роботизирован»
Человек листает каталог с разными паузами, кликает по случайным товарам, иногда возвращается назад, скроллит страницу неравномерно. Серверный скрипт обычно делает запросы через равные интервалы (например строго раз в 2 секунды) и обращается только к нужным URL без «шума» вокруг — без загрузки картинок, скриптов, без посещения главной страницы перед карточкой товара.
Что менять: добавлять случайные задержки (не фиксированные 2 секунды, а рандом от 1.5 до 6 секунд), периодически заходить на промежуточные страницы (категория → карточка, а не прямой запрос к API), эмулировать скролл и движения мыши при работе через headless-браузер. Это увеличивает время сбора данных, но резко снижает количество банов.
Причина 7: Сессии и cookies не сохраняются между запросами
Часто парсер на сервере создаёт новую сессию requests для каждого запроса — без cookies, без сохранённого токена авторизации, без истории посещений. Маркетплейсы вроде Wildberries и Ozon выдают временные cookies и токены при первом заходе, и дальнейшие запросы без них выглядят подозрительно, будто каждый запрос делает новый анонимный посетитель.
Правильная схема: одна сессия (requests.Session() или контекст браузера) — на один IP из прокси-пула, с сохранением cookies на протяжении всей серии запросов к этому IP. При смене прокси нужно начинать новую сессию с чистыми cookies, имитируя нового пользователя, а не продолжать использовать старые cookies с новым IP — это тоже создаёт несоответствие и триггерит блокировку.
Чек-лист: что менять по порядку
Если парсер стабильно банится на сервере, но работает локально, проверяйте изменения в этом порядке — так вы быстрее найдёте причину:
| Шаг | Что проверить | Что менять |
|---|---|---|
| 1 | Тип IP сервера | Перейти на резидентные прокси вместо прямого IP хостинга |
| 2 | Частота запросов | Ввести ротацию IP и лимит запросов на адрес |
| 3 | Заголовки запроса | Скопировать полный набор заголовков реального браузера |
| 4 | TLS-отпечаток | Использовать curl_cffi / headless-браузер вместо чистого requests |
| 5 | Часовой пояс и локаль | Настроить профиль в Dolphin Anty / AdsPower под регион IP |
| 6 | Паттерн поведения | Рандомизировать задержки, добавить промежуточные страницы |
| 7 | Сессии и cookies | Привязать одну сессию к одному IP на весь цикл запросов |
Для высокочастотного парсинга каталогов Wildberries и Ozon, где важна скорость обхода тысяч страниц, часто комбинируют два типа прокси: прокси дата-центров для черновых технических запросов (проверка доступности, статус-коды) и резидентные — для финального сбора данных с карточек, где важна маскировка под реального пользователя. Для мобильных приложений маркетплейсов и Авито иногда эффективнее мобильные прокси, так как они реже попадают в списки автоматической блокировки по ASN.
Заключение
Бан парсера на сервере при работе локальной версии почти всегда связан не с логикой скрипта, а с окружением: тип IP, TLS-отпечаток, заголовки, часовой пояс, паттерн запросов и управление сессиями. Проверяя каждую из 7 причин по порядку — от самой частой (IP дата-центра) до самой незаметной (несовпадение часового пояса и региона IP) — можно восстановить стабильную работу парсера без изменения основной бизнес-логики сбора данных.
Если вы собираете цены и остатки на Wildberries, Ozon или Авито в промышленных объёмах, начните с замены IP: попробуйте резидентные прокси вместо стандартного адреса VPS — в большинстве случаев это устраняет до 70% блокировок ещё до того, как вы начнёте настраивать заголовки и TLS-отпечатки.