Ограниченный тираж: ажиотаж, боты и честная очередь

MAATRIX

Кроссовки лимитированной серии, мерч по коллаборации, партия из 300 плат разработчика — в момент старта продаж на сервер обрушивается не просто трафик, а трафик, где живые покупатели уже проигрывают гонку скриптам. Отличие такого дропа от обычной распродажи в одном: товара физически меньше, чем желающих, и это известно заранее. Если не разделить ботов и людей на входе, весь тираж за секунды выкупят несколько скрипт-кидди, а обиженные живые клиенты останутся в комментариях под постом с воплями «опять всё смели боты».

Чем дроп отличается от обычной распродажи

На обычной распродаже цель — выдержать нагрузку и не упасть: товара в среднем достаточно, вопрос только в скорости отклика. На дропе лимитированного тиража схема иная: даже если сервер держит нагрузку идеально, 300 единиц товара физически не хватит на 50 000 одновременных запросов. Проблема не производительности, а справедливости распределения дефицита.

Это меняет набор задач:

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

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

Второй смежный случай — предзаказ, открывающийся по расписанию: там нагрузка тоже предсказуема по времени, но спрос обычно не превышает предложение в разы, и задача ближе к «выдержать пик», а не «отсеять ботов». Если ваш кейс — это открытие продаж известного количества товара без острого дефицита, смотрите его отдельно; здесь фокус именно на нехватке товара и автоматизированной скупке.

Кто и зачем скупает тираж ботами

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

• Реселлеры-скальперы. Покупают партиями через десятки аккаунтов и прокси, чтобы перепродать с наценкой. Мотивация чисто денежная, готовы вкладываться в инфраструктуру: пулы резидентных прокси, антидетект-браузеры, капча-солверы за деньги.
• Коллекционеры-фанаты с ботами «для себя». Часто просто взяли готовый скрипт с GitHub, менее изощрённые, их проще остановить базовыми мерами.
• Конкуренты или недоброжелатели. Реже, но бывает: цель не купить, а обвалить сервис или испортить репутацию дропа — это уже ближе к обычной DDoS-мотивации, и там работают меры из статьи про защиту от DDoS.

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

Rate limiting как первый, но не единственный барьер

Базовый rate limiting ограничивает число запросов с одного источника в единицу времени. Для дропа с реальным дефицитом его настраивают жёстче, чем для обычного API, потому что здесь цена одного «лишнего» запроса — упущенная позиция для живого человека.

Пример на nginx с зоной ограничения по IP для страницы добавления в корзину:

http {
    limit_req_zone $binary_remote_addr zone=drop_cart:10m rate=3r/s;
    limit_req_status 429;

    server {
        location /api/cart/add {
            limit_req zone=drop_cart burst=5 nodelay;
            proxy_pass http://backend;
        }
    }
}

Здесь rate=3r/s — три запроса в секунду с одного IP, burst=5 — короткий запас на случай двойного клика или ретрая мобильной сети, nodelay — превышающие burst запросы сразу получают 429, а не ставятся в очередь (в очереди на дропе смысла нет: пока запрос ждёт, товар уже разобрали).

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

Практический компромисс — комбинировать лимит по IP с лимитом по более узкому идентификатору (сессия, fingerprint, авторизованный аккаунт), чтобы не наказывать NAT целиком за поведение одного бота внутри него.

Капча и её реальная цена

Капча — не панацея, а фильтр стоимости: она не делает атаку невозможной, а делает её дороже. Актуальная связка на конец августа 2026 года — invisible-капча (фоновая оценка поведения без явного клика) с фолбэком на классическую задачу при подозрении, плюс серверная проверка токена перед тем, как принять запрос в очередь или корзину.

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

• Капчу нужно проверять на сервере, а не только доверять фронтенду — иначе бот просто не вызывает виджет и шлёт запрос напрямую на API.
• Капча должна стоять до записи в очередь или резервирования позиции, а не после — иначе бот успевает занять место, даже если потом не пройдёт проверку.
• Инвизбл-капча на реальном ажиотажном трафике иногда ошибочно блокирует часть живых пользователей (особенно с VPN или необычными браузерными настройками) — это не баг, а свойство поведенческой оценки под нетипичной нагрузкой. Стоит держать альтернативный путь (SMS-код, ручная модерация подозрительных заказов) для тех, кто легитимно не проходит автоматическую проверку.
• Капча-солверы (сервисы, которые за деньги решают капчу через живых людей или ML) существуют и стоят недорого для профессиональных скальперов — это ещё один довод не полагаться на капчу как на единственный барьер.

Honeypot-поля и поведенческие сигналы

Honeypot — скрытое поле формы, невидимое человеку через CSS, но видимое простому боту, который парсит DOM и заполняет все поля подряд:

<input type="text" name="middle_name" style="position:absolute;left:-9999px" tabindex="-1" autocomplete="off">

# на бэкенде: если поле заполнено — это не человек
if request.form.get("middle_name"):
    return jsonify({"error": "rejected"}), 400

Простая мера, но эффективна против массового низкоквалифицированного бота, который не рендерит CSS и не проверяет видимость. Против скальперов, использующих headless-браузеры (Puppeteer, Playwright) с полной отрисовкой страницы, honeypot почти бесполезен — такой бот видит DOM ровно как человек.

Дополняющие поведенческие сигналы, которые стоит логировать и учитывать в скоринге:

• Время до действия. Живой человек не может открыть страницу и нажать «купить» за 50 миллисекунд — это явный маркер скрипта, который бьёт по эндпоинту напрямую, минуя рендеринг.
• Движения мыши / события скролла. Отсутствие событий mousemove перед кликом — сильный сигнал, хотя продвинутые боты научились их имитировать.
• Паттерн User-Agent и TLS fingerprint. Устаревшие или нетипичные комбинации версий браузера и TLS-стека часто выдают библиотеки автоматизации (requests, curl, старые headless-сборки).
• Повторяемость fingerprint при разных IP. Если тысяча «разных» покупателей используют идентичный набор заголовков и разрешение экрана — это один скрипт за прокси-пулом.

Ни один сигнал по отдельности не доказателен — люди тоже иногда кликают быстро или используют VPN. Работает только сумма баллов по нескольким сигналам с порогом, после которого запрос уходит в дополнительную проверку, а не сразу в бан.

Честная очередь: как распределить дефицит между живыми людьми

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

1. Виртуальная приёмная (waiting room) перед основным сайтом. Пользователь попадает не сразу в корзину, а на отдельную лёгкую страницу ожидания, откуда сервис пропускает людей на основной сайт порциями, которые тот способен обработать. Технически это отдельный лёгкий сервис на VPS (может стоять на минимальной конфигурации, потому что отдаёт статику и номер очереди, а не работает с базой):

# приёмная — отдельный upstream, лёгкий и быстро масштабируемый
upstream waiting_room {
    server 127.0.0.1:8090;
}

# основной сайт — доступен только с валидным токеном очереди
server {
    location / {
        if ($cookie_queue_token = "") {
            return 302 https://queue.example.com/wait;
        }
        proxy_pass http://backend;
    }
}

Токен очереди выдаётся с ограниченным сроком действия (например, 10 минут на завершение покупки после впуска), чтобы не копился «мёртвый» резерв позиций у тех, кто зашёл и передумал.

2. Лотерея / рафл вместо гонки на скорость. Вместо «кто первый нажал», собирается пул заявок за фиксированное окно времени (например, 30 минут), затем случайным образом выбираются победители. Это полностью убирает смысл ботовой скорости — миллисекунды роли не играют, — но не убирает смысл множественных заявок с разных аккаунтов, поэтому рафл обязательно сочетают с ограничением «одна заявка на подтверждённый email/телефон/платёжный метод».

Сравнение подходов:

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

Ограничение «один покупатель — один тираж»

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

Работающие меры, от слабой к сильной:

• Привязка лимита к email и номеру телефона с верификацией (SMS-код на этапе оформления, а не только на регистрации).
• Привязка лимита к платёжному методу — один номер карты или один криптоадрес может быть использован для покупки не более N раз за окно дропа. Это сильнее email-проверки, потому что новую карту завести дороже и дольше, чем новую почту.
• Дедупликация по адресу доставки для физического товара — грубый, но действенный фильтр против явных мультиаккаунтов на один и тот же адрес.
• Логирование связок «аккаунт — устройство — платёж» и ручная модерация подозрительных кластеров после закрытия продаж, с возможностью отменить заказ и вернуть товар в пул для следующей волны.

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

Наблюдаемость: что смотреть во время дропа

В момент старта продаж важно не только держать защиту, но и видеть в реальном времени, работает ли она. Минимальный набор метрик на дашборде:

• Доля запросов, отсечённых на каждом барьере отдельно (rate limit / капча / honeypot / поведенческий скоринг) — если один барьер вдруг съедает 90% трафика, а остальные бездействуют, вероятно бот научился обходить именно его.
• Соотношение «уникальные fingerprint / уникальные IP» — резкий перекос в сторону повторяющихся fingerprint при разных IP выдаёт прокси-пул.
• Время между впуском в очередь и оформлением заказа — аномально короткое время массово у разных пользователей означает автоматизацию уже после прохождения защиты.
• Нагрузка на бэкенд заказов отдельно от нагрузки на приёмную очередь — приёмная должна принимать на себя основной пик, чтобы бэкенд с базой данных получал уже отфильтрованный и сглаженный поток.

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

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