SavePearlHarbor

Универсальный парсинг сайтов на Python: requests vs headless, токены, куки, прокси и ротация IP

—

от автора

admin

Вы когда-нибудь радовались идеальному прототипу парсера, который у вас летал на демо-странице, а в проде внезапно начал ловить 403, 429, пустые HTML и «куда-то делись карточки»? Контент отрисовывается на JS, сервер требует токен, после смены IP, старая сессия перестаёт работать.

В этой статье я подробно разберу, как собирать данные устойчиво и предсказуемо, без излишней магии и с упором на реальную эксплуатацию.

Вся статья и примеры на Python.

Что разберём в парсинге сайтов

  • когда хватает requests, а когда нужен headless-браузер;

  • как вести себя «как человек»: headers, user-agent, cookies, локаль и таймзона;

  • сессии и токены — почему «новый IP = новая сессия» и что с этим делать;

  • скорость, rate-limit и бэкоффы* без бана подсети;

  • «бесконечные списки»: скролл или перехват XHR/GraphQL;

  • отдельный практический блок про ротацию IP.

*бэкофф — стратегия повторных попыток, при которой между неудавшимися попытками делается пауза, где каждая последующая пауза длиннее.

Немного о сервисе Amvera или где деплоить парсер, чтобы не ловить 429

Amvera — облачный сервис, созданный в первую очередь для простого деплоя IT-приложений различного рода. Сервис поддерживает множество окружений, таких как Python, Node.JS, JVM, Go, C#, Docker и прочие.

Важным бонусом для нас будет являться:

  1. Ротация исходящих IP из пула. Это поможет избежать большинство блокировок по IP и 429.

  2. 111 рублей на баланс сразу после регистрации даст пространство для тестов сразу на сервере.

  3. Помимо вышесказанного, сервис предоствляет бесплатное проксирование до OpenAI, GrokAI, Gemini и множества сервисов с региональными ограничениями.

Итак, вернемся к теме.

1. Базовый случай, когда requests реально достаточно

Если страница статична или есть открытый JSON-эндпоинт — берите requests плюс HTML-парсер (lxml, BeautifulSoup, parsel). Это быстро, дёшево и легко масштабируется.

Ключевые правила парсинга в таком случае:

  • отправляйте реалистичные заголовки (headers с UA);

  • фиксируйте Accept-Language и Referer, если сайт регионозависимый;

  • на ошибках 5xx и 429 используйте бэкофф с Retry-After.

Минимальный пример:

# pip install bs4 requests lxml  import requests from bs4 import BeautifulSoup  headers = { "User-Agent": "Mozilla/5.0 ... Chrome/124.0.0.0 Safari/537.36", "Accept-Language": "ru-RU,ru;q=0.9,en;q=0.7", "Accept": "text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8", }  r = requests.get("https://какой-то.адрес", headers=headers, timeout=30) r.raise_for_status()  soup = BeautifulSoup(r.text, "lxml") titles = [t.get_text(strip=True) for t in soup.select(".title")]

Когда этого мало:

  • контент рисуется на клиенте после загрузки;

  • нужна интеракция пользователя;

  • сервер проверяет браузерные сигналы и сессии.

То есть этого вполне достаточно для простых и демо-сайтов.

2. Когда без headless-браузера никуда

Признаки:

  • пустой HTML, а в DevTools браузера видно богатый DOM;

  • множество XHR/Fetch/GraphQL после загрузки;

  • чувствительность к sec-ch-ua, WebGL, плагинам, локалям, таймзоне и прочему.

Рекомендация — Playwright с Chromium. Он даёт реалистичное окружение, нормальные sec-ch-ua.

Короткий пример загрузки страницы:

# pip install playwright   # playwright install  from playwright.sync_api import sync_playwright  with sync_playwright() as p:     browser = p.chromium.launch(headless=True)     ctx = browser.new_context(         user_agent="Mozilla/5.0 ... Chrome/124.0.0.0 Safari/537.36",         locale="ru-RU",         timezone_id="Europe/Moscow",         viewport={"width": 1280, "height": 800},     )     page = ctx.new_page()     page.goto("https://example.com/catalog", wait_until="networkidle", timeout=45000)     html = page.content()     print(html)     browser.close()     ctx.close()

Практические советы:

  • не урезайте браузер излишне. Чем «натуральнее» он выглядит, тем меньше триггеров на стороне защиты;

  • фиксируйте локаль и таймзону, это влияет на цены, формат дат и сами селекторы;

  • если видите XHR с JSON — парсите JSON, а не HTML.

Заголовки и user-agent

Поддерживать актуальные User-Agent самому неудобно. Используйте библиотеки, которые держат множество UA и умеют выбирать реальные:

  • fake-useragent

  • random_user_agent

Использование:

# pip install fake-useragent  from fake_useragent import UserAgent ua = UserAgent()  headers = { "User-Agent": ua.random, "Accept-Language": "ru-RU,ru;q=0.9,en;q=0.7", "Accept": "text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8", }

Важно:

  • старые UA чаще попадают под подозрение;

  • не добавляйте экзотических заголовков, которых реальный браузер не шлёт.

4. Куки, токены и «новый IP = новая сессия»

Многие сайты жестко привязывают сессию к IP-адресу.
Если вы получили сессионную куку на IP A, а потом внезапно пошли с ней через прокси B, сервер это почти наверняка воспримет как подозрительное поведение. В лучшем случае он просто обнулит сессию, в худшем — сразу вернёт 403.

Выводы:

  • куки нужно хранить в связке ip - cookies;

  • при смене прокси создавайте новую сессию, не reuse (используя повторно) старую;

  • не делитесь одними и теми же куками между разными IP;

  • CSRF-токены и прочие «одноразовые» маркеры. Это тоже часть конкретной сессии, их нужно обновлять.

Удобный шаблон на Python

  1. Сначала «прогреваем» сессию в headless-браузере — принимаем cookies, логинимся (если нужно).

  2. Сохраняем куки в storage_state.

  3. Используем их уже в сессии requests.Session, но строго на том же IP.

Простейшая схема:

def bootstrap_session_from_browser(proxy):     # возвращаем готовую сессию  pool = {     proxy: bootstrap_session_from_browser(proxy)     for proxy in proxies }  def fetch(url):     proxy, sess = choose_proxy(pool)     r = sess.get(url, timeout=30)      # если сервер выкинул сессию - пересоздаём     if r.status_code in (401, 403):         pool[proxy] = bootstrap_session_from_browser(proxy)         r = pool[proxy].get(url, timeout=30)      r.raise_for_status()     return r.text

5. Скорость, rate-limit и бэкофф

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

  • ограничивайте частоту запросов на домен.

  • применяйте бэкофф.

  • придерживайтесь Retry-After.

  • планируйте очереди с запасом по времени.

Минимальная схема бэкоффа:

import time, random, requests def  get_with_backoff(sess, url, retries=5, base=0.5, factor=2.0): for attempt in  range(retries):         r = sess.get(url, timeout=30) if r.status_code == 429:             ra = r.headers.get("Retry-After")             wait = float(ra) if ra else base * (factor ** attempt)             time.sleep(wait + random.uniform(0, 0.5)) continue r.raise_for_status() return r.text raise RuntimeError("слишком много попыток")

6. Бесконечная прокрутка: два способа

Наверняка вы встречали сайты, где товары или посты подгружаются не сразу, а появляются по мере прокрутки вниз. Это и есть бесконечная прокрутка. Она удобна пользователям, но усложняет жизнь парсеру: страница сама по себе неполная и её нужно докручивать.

Есть два подхода, как это обойти:

Подход 1 — скроллим страницу как человек

Самый прямой и простой способ — имитировать прокрутку в headless-браузере.
Код буквально «крутит колёсико мышки», ждёт подгрузку и снова скроллит. Так можно дотянуться до самого низа страницы.

Минус: это медленно, потому что вы действительно ждёте загрузку и отрисовку элементов.

page.mouse.wheel(0, 2400) page.wait_for_timeout(800) # подождать, пока успеет подгрузиться

Подход 2 — ищем API

Более «хакерский» и быстрый вариант: открыть DevTools и посмотреть, откуда страница тянет данные. Обычно карточки товаров или постов прилетают отдельным XHR/GraphQL запросом — например, на /api/catalog. Если найти этот запрос и повторить его напрямую в коде, то вы сразу получите весь JSON со списком карточек, минуя сам скролл.

Сценарий будет выглядеть примерно так:

  • открыть страницу через Playwright.

  • подписаться на события page.on("response", ...).

  • отфильтровать ответы по адресу (например, /api/catalog).

  • читать JSON и вытаскивать нужные данные.

Итог: если нужно быстро и надёжно — ищите API и «бейте» в него.
Если API спрятано или слишком заморочено — придётся скроллить страницу.

7. Важный бонус: пул IP в Amvera для обхода 429

Если вы деплоите парсер в Amvera, то получите важный бонус: исходящий трафик ходит через пул IP. На практике это помогает «рассредоточить» нагрузку и снизить вероятность 429 на адрес, потому что ваши запросы выходят не всегда с одного и того же IP. Чем это удобно:

  • отдельные платные прокси не требуются.

  • частота с одного конкретного IP для внешнего сайта ниже.

  • как побочный эффект — ниже шанс моментального rate-limit по адресу.

И, что важно, при регистрации в Amvera вам сразу будет доступен бонус с виде 111 рублей на баланс для тестов. Этого будет более чем достаточно, чтобы успеть настроить парсер и даже некоторое время покрутить своё приложение совершенно бесплатно.

Но есть особенности архитектуры, которые обязательно учтите:

  • нет явной кнопки или API, чтобы самостоятельно и мгновенно переключить исходящий IP. Ротация происходит без чёткого правила, рандомно под капотом инфраструктуры.

  • нельзя гарантировать, что запрос уйдет именно с нового IP.

  • если цель привязывает сессию к IP, то рандомная смена источника может порвать сессию.

  • можно настроить уведомления в бота Amvera об ошибках в логе, к примеру, о 429. Так, вы сразу узнаете, если с парсингом что-то не так.

Даже с IP-пулом не отказывайтесь от бэкоффов и разумного лимитирования. Это по-прежнему лучшая защита от 429. Ещё один практический совет: делайте задания идемпотентными, чтобы неожиданный разрыв сессии на середине не порождал дублей и мусора в хранилище.

8. Частые поломки парсинга и короткие рецепты

  • 403 сразу — проверьте свежесть UA, Accept-Language, Referer, попробуйте Playwright и реалистичный контекст

  • 429 периодически — снизьте RPS, попробуйте деплоить на Amvera.

  • Пустой HTML — страница на JS, перехватывайте XHR/GraphQL или используйте headless.

  • разный язык/валюта — фиксируйте локаль и таймзону в контексте и заголовках.

Итог

  • Начинаем с requests — дёшево и быстро.

  • Если страница живёт на JS — берём Playwright.

  • Сессии и токены часто привязаны к IP — не переносите куки между адресами.

  • User-Agent-ом рандомизируем библиотекой, заголовки делаем реалистичными.

  • Бэкофф, Retry-After и ограничение частоты — основа долговременной работы парсера.

  • В Amvera исходящий трафик может идти через пул IP — это помогает избегать 429 без явных прокси.

  • Всё это легко собрать на Python и поддерживать в проде.

Вопрос для обсуждения: с какими подводными камнями вы чаще всего сталкивались в боевых парсерах на Python — сессии, привязанные к IP, внезапные 429, неустойчивые прокси, GraphQL-запросы вместо HTML, проблемы локали или что-то ещё? И какие библиотеки для рандомизации user-agent показали себя надёжнее у вас на проде? Опишите свой опыт в комментариях — соберём практики.


ссылка на оригинал статьи https://habr.com/ru/articles/940688/

Комментарии

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *