Назад к блогу

Параллельные и последовательные запросы через прокси: как выбрать метод без блокировок

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

📅8 февраля 2026 г.

При парсинге маркетплейсов, автоматизации работы с соцсетями или сборе данных через API критически важно правильно выбрать стратегию отправки запросов. Неправильная настройка приводит к блокировкам IP, капчам и потере времени. В этом руководстве разберём, когда использовать параллельные запросы для максимальной скорости, а когда последовательные — для безопасности.

Чем отличаются параллельные и последовательные запросы

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

Параллельные запросы — это когда одновременно отправляется несколько запросов (5, 10, 50 или даже сотни), не дожидаясь ответов на предыдущие. Это в разы быстрее, но создаёт нагрузку на сервер и может вызвать подозрения антифрод-систем.

Представьте парсинг цен с 10 000 товаров на Wildberries. Последовательно с задержкой 2 секунды между запросами — это 20 000 секунд или 5,5 часов. Если запустить 20 параллельных потоков — всего 16 минут. Разница очевидна, но есть нюансы.

Важно: Параллельные запросы не означают «отправить 1000 запросов одновременно». Это контролируемая параллельность — например, 10-50 активных потоков, каждый с задержками. Без контроля вы моментально получите бан.

Сравнение методов

Параметр Последовательные Параллельные
Скорость Медленно (1 запрос в момент) Быстро (10-100+ одновременно)
Риск блокировки Низкий Средний-высокий
Нагрузка на прокси Минимальная Высокая
Сложность настройки Простая Требует опыта
Потребление памяти Низкое Высокое
Обработка ошибок Проще отслеживать Сложнее логировать

Когда использовать параллельные запросы

Параллельные запросы — это выбор, когда скорость критична, а объём данных большой. Но важно понимать: это работает только при правильной настройке прокси и контроле нагрузки.

Идеальные сценарии для параллельных запросов

1. Парсинг маркетплейсов с большим каталогом
Если вам нужно собрать цены с 50 000 товаров на Wildberries или Ozon, последовательный парсинг займёт дни. С 20-30 параллельными потоками и прокси дата-центров задача решается за несколько часов.

Настройка: 20-30 потоков, каждый с отдельным IP, задержка 1-3 секунды между запросами внутри потока. Ротация IP каждые 100-200 запросов.

2. Сбор данных из публичных API
Многие API (например, погодные сервисы, базы данных компаний, геолокационные сервисы) имеют лимиты на запросы с одного IP: 100-1000 в день. Параллельные запросы через пул прокси позволяют обойти лимиты.

Пример: Вам нужно собрать данные о 10 000 компаний через API. Лимит — 500 запросов/день с IP. Используете 20 прокси параллельно = 10 000 запросов за день вместо 20 дней.

3. Проверка доступности ресурсов
Если вы проверяете доступность сайтов, работу зеркал или мониторите статус серверов — параллельные запросы экономят часы. Здесь не нужна имитация поведения человека, важна только скорость.

4. Массовая проверка прокси
При покупке больших пулов прокси (1000+ IP) нужно быстро проверить их работоспособность, скорость, геолокацию. Последовательная проверка займёт часы, параллельная — минуты.

Внимание: Параллельные запросы НЕ подходят для работы с защищёнными платформами (Facebook Ads, Instagram API, Google Ads), где важна имитация поведения реального пользователя. Там используйте последовательные запросы.

Ключевые требования для параллельных запросов

  • Большой пул прокси (минимум 10-20 IP, лучше 50-100+)
  • Автоматическая ротация IP при ошибках
  • Контроль количества одновременных потоков (не более 50-100)
  • Задержки между запросами даже внутри потоков (0.5-2 сек)
  • Логирование ошибок для анализа причин блокировок
  • Система retry (повторных попыток) при таймаутах

Когда использовать последовательные запросы

Последовательные запросы — это выбор безопасности и надёжности над скоростью. Они имитируют поведение реального пользователя и минимизируют риск блокировок на защищённых платформах.

Обязательные сценарии для последовательных запросов

1. Работа с рекламными кабинетами
Facebook Ads, TikTok Ads, Google Ads отслеживают не только IP, но и паттерны поведения. Параллельные запросы с одного аккаунта моментально вызовут подозрения. Один аккаунт = один поток = последовательные действия с задержками 5-15 секунд.

Пример: Вы управляете 20 рекламными кабинетами Facebook через антидетект-браузер Dolphin Anty. Каждый кабинет работает в отдельном профиле с мобильным прокси, действия строго последовательны: вход → проверка статистики → корректировка ставок → выход. Задержки 7-12 секунд между действиями.

2. Автоматизация действий в соцсетях
Instagram, TikTok, VK имеют жёсткие лимиты на действия: лайки, подписки, комментарии. Превышение лимитов или слишком быстрые действия = shadowban или полная блокировка. Только последовательные запросы с рандомными задержками 20-60 секунд.

Настройка для Instagram: Один аккаунт делает максимум 60 лайков/час. Это 1 лайк в минуту с задержками 45-75 секунд (рандомизация важна!). Используете отдельный прокси на каждый аккаунт.

3. Авторизация и работа с личными кабинетами
Любые действия, требующие входа в аккаунт (email-сервисы, банки, маркетплейсы как продавец) должны выполняться последовательно. Параллельные попытки входа с разных IP в один аккаунт — прямой путь к блокировке.

4. Сайты с жёсткой антибот-защитой
Платформы с Cloudflare, Akamai, PerimeterX анализируют не только частоту запросов, но и их паттерны. Если с одного IP или User-Agent приходит 10 запросов одновременно — это явный признак бота. Последовательные запросы с задержками 3-10 секунд выглядят естественно.

5. Небольшой объём данных
Если вам нужно спарсить 50-100 страниц, разница во времени между последовательным и параллельным парсингом несущественна (5 минут против 1 минуты). Зато последовательный метод гарантирует отсутствие проблем.

Правильные задержки для последовательных запросов

Платформа/задача Задержка между запросами Рандомизация
Facebook Ads (действия в кабинете) 7-15 секунд ±30%
Instagram (лайки, подписки) 45-90 секунд ±40%
TikTok (просмотры, лайки) 30-60 секунд ±35%
Google Ads (API запросы) 5-10 секунд ±25%
Парсинг с Cloudflare 3-7 секунд ±30%
Обычные сайты без защиты 1-3 секунды ±20%

Совет: Рандомизация задержек критически важна. Если ваш скрипт делает запрос ровно каждые 5.00 секунд — это паттерн бота. Используйте random от 4 до 7 секунд, чтобы имитировать человека.

Риски блокировок при разных методах

Понимание рисков помогает выбрать правильную стратегию и настроить защиту. Блокировки происходят не только из-за частоты запросов, но и из-за их паттернов.

Что отслеживают антифрод-системы

1. Частота запросов с одного IP
Если с одного IP приходит 100 запросов в минуту — это очевидный бот. Лимиты различаются: обычные сайты терпят 10-30 запросов/минуту, защищённые платформы — 2-5 запросов/минуту.

Решение для параллельных запросов: Распределяйте запросы по большому пулу IP. Например, 1000 запросов/минуту = 50 IP по 20 запросов каждый. Это выглядит как 50 обычных пользователей.

2. Одинаковые интервалы между запросами
Запросы ровно каждые 2.00 секунды — признак автоматизации. Человек кликает с разными интервалами: 1.8 сек, 3.2 сек, 2.1 сек.

Решение: Добавляйте рандомизацию ±30-50% от базовой задержки. Вместо фиксированных 5 секунд используйте random(3.5, 7.5).

3. Отсутствие типичного поведения пользователя
Реальный пользователь не переходит прямо на страницу товара — он сначала заходит на главную, ищет категорию, кликает на товар. Бот сразу запрашивает конкретный URL.

Решение для критичных платформ: Имитируйте полный путь пользователя. Перед парсингом товара сделайте 2-3 запроса: главная → категория → товар. Это замедляет работу, но снижает риск блокировки на 70-80%.

4. Подозрительные User-Agent и заголовки
Устаревшие User-Agent (например, Chrome 95 в 2024 году), отсутствие заголовков Accept-Language, Referer — признаки бота.

Решение: Используйте актуальные User-Agent (Chrome 120+, Firefox 120+), добавляйте полный набор заголовков как у реального браузера. Ротируйте User-Agent вместе с IP.

Сравнение рисков блокировок

Сценарий Риск при последовательных Риск при параллельных
Парсинг маркетплейса (10К запросов) Низкий (5-10%) Средний (20-30%)
Работа с Facebook Ads Низкий (2-5%) Критический (80-95%)
Instagram-автоматизация Средний (15-25%) Высокий (60-80%)
Публичные API (в пределах лимитов) Очень низкий (1-3%) Низкий (5-10%)
Сайты с Cloudflare Средний (10-20%) Высокий (40-60%)

Какие прокси подходят для каждого метода

Тип прокси напрямую влияет на возможность использования параллельных или последовательных запросов. Неправильный выбор приведёт к блокировкам или переплате.

Прокси для параллельных запросов

Прокси дата-центров — оптимальный выбор для массового парсинга и параллельных запросов. Они дешёвые (от $1-3 за IP/месяц), быстрые (пинг 20-50 мс) и доступны в больших объёмах. Минус — легко определяются как прокси, поэтому не подходят для защищённых платформ.

Когда использовать: Парсинг маркетплейсов, сбор данных из публичных источников, проверка доступности ресурсов, массовые API-запросы к сервисам без жёсткой защиты.

Настройка: Покупаете пул 50-100 IP, настраиваете 20-30 параллельных потоков, каждый поток использует свой IP. Ротация каждые 100-200 запросов или при ошибке.

Резидентные прокси — более дорогие (от $3-7 за 1 GB трафика), но выглядят как реальные пользователи. Подходят для параллельных запросов к защищённым платформам, если нужна скорость, но с осторожностью.

Когда использовать: Парсинг соцсетей (без авторизации), сбор данных с сайтов с Cloudflare, работа с платформами, которые блокируют дата-центры. Для параллельных запросов нужен большой пул IP с автоматической ротацией.

Важно: При параллельных запросах через резидентные прокси контролируйте расход трафика. 10 000 запросов могут «съесть» 5-10 GB, что обойдётся в $20-50. Дата-центры дешевле: безлимитный трафик за $100-200/месяц на 100 IP.

Прокси для последовательных запросов

Мобильные прокси — самый надёжный тип для работы с защищёнными платформами. IP выглядят как реальные мобильные устройства (4G/5G операторов), что минимизирует риск блокировок. Минус — дорогие (от $50-150 за IP/месяц).

Когда использовать: Facebook Ads, Instagram, TikTok, Google Ads — всё, где нужна максимальная безопасность и имитация реального пользователя. Один аккаунт = один мобильный прокси = последовательные действия.

Настройка: Каждый рекламный кабинет или соцсеть-аккаунт привязан к отдельному мобильному IP. Действия строго последовательны с задержками 10-60 секунд. IP не ротируется (один аккаунт всегда работает с одного IP).

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

Когда использовать: Управление аккаунтами маркетплейсов (Wildberries, Ozon как продавец), автоматизация постинга в соцсети (не массовая), парсинг данных, требующих авторизации.

Рекомендации по выбору прокси

Задача Тип прокси Метод запросов Количество IP
Парсинг маркетплейсов (большой объём) Дата-центры Параллельные 50-100+
Facebook Ads (мультиаккаунтинг) Мобильные Последовательные 1 IP на аккаунт
Instagram-автоматизация Мобильные/резидентные Последовательные 1 IP на аккаунт
Парсинг с Cloudflare Резидентные Параллельные (осторожно) 20-50
Публичные API (массовый сбор) Дата-центры Параллельные 10-30
Маркетплейсы (личный кабинет продавца) Резидентные Последовательные 1 IP на аккаунт

Оптимальные настройки: задержки, потоки, таймауты

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

Настройка параллельных запросов

Количество одновременных потоков (concurrency)
Это ключевой параметр. Слишком много потоков = перегрузка прокси и целевого сервера. Слишком мало = низкая скорость.

Рекомендации:

  • Парсинг маркетплейсов: 20-50 потоков при пуле 50+ прокси
  • Публичные API: 10-30 потоков, ориентируйтесь на лимиты API
  • Сайты с защитой: 5-15 потоков, больше — риск блокировки
  • Проверка прокси: 50-100 потоков (здесь скорость важнее)

Задержки внутри потоков
Даже при параллельной работе каждый поток должен делать паузы между своими запросами. Это снижает нагрузку на один IP и уменьшает риск блокировки.

Рекомендации:

  • Простые сайты: 0.5-2 секунды между запросами в одном потоке
  • Маркетплейсы: 1-3 секунды с рандомизацией ±30%
  • Сайты с Cloudflare: 2-5 секунд с рандомизацией ±40%
  • API с лимитами: рассчитывайте исходя из лимита (например, 100 запросов/минуту = 0.6 сек/запрос, делайте 1 сек для запаса)

Таймауты (timeout)
Время ожидания ответа от сервера. Слишком короткий таймаут = потеря данных из-за медленных ответов. Слишком длинный = зависание потоков.

Рекомендации:

  • Быстрые сайты: 10-15 секунд
  • Медленные сайты/API: 20-30 секунд
  • Через резидентные прокси: +5-10 секунд (они медленнее дата-центров)
  • Connection timeout: 5-10 секунд (время установки соединения)

Retry (повторные попытки)
При ошибках (таймаут, 503, блокировка прокси) нужно повторить запрос с другим IP. Без retry вы потеряете часть данных.

Настройка: 2-3 попытки на запрос, смена прокси после каждой неудачной попытки, пауза 3-5 секунд перед retry.

Настройка последовательных запросов

Базовая задержка между запросами
Зависит от платформы и типа действий. Главное правило: имитировать реального пользователя.

Рекомендации по платформам:

  • Facebook Ads (переходы между разделами кабинета): 7-15 секунд
  • Instagram (лайки): 45-90 секунд, максимум 60 лайков/час
  • Instagram (подписки): 60-120 секунд, максимум 30 подписок/час
  • TikTok (просмотры): 30-60 секунд
  • Парсинг с авторизацией: 3-7 секунд
  • Маркетплейсы (действия в кабинете продавца): 5-10 секунд

Рандомизация
Обязательна для всех последовательных запросов. Используйте отклонение ±30-50% от базовой задержки.

Пример: Базовая задержка 10 секунд, рандомизация ±40% → фактические задержки будут 6-14 секунд (случайное значение каждый раз).

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

Рекомендации: 30-60 секунд для защищённых платформ (Facebook, Instagram), 15-30 секунд для обычных сайтов.

Практический совет: Начинайте с консервативных настроек (меньше потоков, больше задержки), постепенно увеличивайте агрессивность, отслеживая процент ошибок. Если ошибок >5-10% — вернитесь на шаг назад.

Инструменты для реализации обоих методов

Выбор инструмента зависит от вашей задачи и технических навыков. Для бизнес-задач (арбитраж, SMM, e-commerce) используйте готовые решения без кода. Для технических задач — библиотеки и фреймворки.

Готовые решения без кода (для бизнеса)

Антидетект-браузеры для мультиаккаунтинга
Если вы работаете с рекламными кабинетами или соцсетями, антидетект-браузеры — это стандарт индустрии. Они автоматически управляют прокси, отпечатками браузера и изолируют аккаунты.

Популярные решения:

  • Dolphin Anty: лидер для арбитражников Facebook/TikTok, бесплатный тариф на 10 профилей, простая настройка прокси
  • AdsPower: хорош для e-commerce (Amazon, eBay), есть автоматизация через RPA (без кода)
  • Multilogin: самый дорогой ($100+/мес), но максимальная защита для серьёзного арбитража
  • GoLogin: бюджетная альтернатива ($25/мес), подходит для SMM и небольших команд

Как они работают с прокси: Создаёте профиль браузера → привязываете прокси → все действия в этом профиле идут через этот IP. Один профиль = один аккаунт = последовательные действия. Для параллельной работы открываете несколько профилей одновременно (каждый со своим прокси).

Парсеры и скраперы (готовые)
Для сбора данных с маркетплейсов и сайтов существуют готовые инструменты с GUI, не требующие программирования.

  • Octoparse: визуальный конструктор парсеров, поддержка прокси, можно настроить параллельные потоки через интерфейс
  • ParseHub: аналог Octoparse, бесплатный тариф на 200 страниц, настройка задержек через GUI
  • Scrapy Cloud: облачный сервис для запуска Scrapy-пауков (требует минимальных знаний Python)

Автоматизация SMM (без кода)
Для управления соцсетями есть сервисы с автоматизацией через интерфейс.

  • Jarvee: автоматизация Instagram, TikTok, Twitter, встроенная поддержка прокси, настройка задержек через GUI (осторожно: агрессивная автоматизация приводит к банам)
  • Ingramer (Inflact): безопасная автоматизация Instagram, работает через их прокси
  • Combin: таргетированные подписки/лайки в Instagram, поддержка внешних прокси

Технические инструменты (для разработчиков)

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

Python (самый популярный для парсинга):

  • Requests + threading/asyncio: для простых параллельных запросов, легко настроить прокси
  • aiohttp: асинхронная библиотека для высокопараллельных запросов (1000+ одновременно)
  • Scrapy: фреймворк для парсинга, встроенная поддержка прокси-ротации, middleware для задержек
  • Selenium: для сайтов с JavaScript, медленнее, но обходит многие защиты
  • Playwright: современная альтернатива Selenium, быстрее и удобнее

JavaScript/Node.js:

  • Axios: популярная библиотека для HTTP-запросов, простая настройка прокси
  • Pupp