qcbot: как работает бот QUIC.cloud и почему его не стоит блокировать вслепую

qcbot — официальный автоматизированный агент QUIC.cloud, принадлежащий компании QUIC Cloud Inc. Он используется облачными сервисами QUIC.cloud для взаимодействия с сайтами, подключёнными через LiteSpeed Cache и другие компоненты экосистемы.

Поэтому определять qcbot как неизвестного нежелательного краулера, который просто собирает контент или строит собственный индекс, неправильно. У него есть конкретный оператор и документированное назначение.

QUIC.cloud официально называет qcbot web crawler для Online Services, которым необходимо получать информацию с сайта или возвращать обработанные данные обратно.

Параметр	Значение
Название	qcbot / QUIC.cloud Bot
Оператор	QUIC Cloud Inc.
UA-токен	qcbot
Версия в документированных UA	qcbot/1.0
Основное назначение	Работа Online Services QUIC.cloud
Image Optimization	Да
UCSS	Да
CCSS	Да
VPI	Да
Используется CDN	Нет, qcbot используется Online Services за исключением CDN
Официальные IP	Да, QUIC.cloud поддерживает актуальный список адресов
Поисковая индексация	Нет
AI training	Не является заявленной задачей
Категория TrafficVeil	Прочие краулеры и сервисы / легитимный сервисный бот

Кому принадлежит qcbot

Оператор установлен однозначно: QUIC Cloud Inc.

В официальной документации QUIC.cloud существует отдельный раздел QUIC.cloud Bot, где агент прямо обозначен как qcbot.

Это важное отличие от User-Agent неизвестного происхождения. Для qcbot известны:

• оператор;
• назначение;
• типовые User-Agent;
• механизм работы;
• связанные Online Services;
• официальная инфраструктура IP.

Поэтому в базе TrafficVeil его правильнее рассматривать как легитимный служебный бот, а решение о блокировке связывать с тем, использует ли конкретный сайт QUIC.cloud.

Для чего QUIC.cloud нужен собственный бот

Многие функции LiteSpeed Cache выполняются не исключительно внутри WordPress. Часть задач передаётся внешней инфраструктуре QUIC.cloud.

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

Именно эту роль выполняет qcbot.

Пример: оптимизация изображений

В случае Image Optimization qcbot получает изображения с сайта и передаёт их инфраструктуре QUIC.cloud для обработки.

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

Поэтому большое количество обращений к JPG, PNG, WebP или другим графическим ресурсам на сайте с активной оптимизацией изображений может быть совершенно нормальным.

Пример: UCSS

UCSS — Unique CSS — механизм, при котором QUIC.cloud анализирует страницу и формирует CSS, необходимый конкретному представлению.

Для этого сервису требуется загрузить саму страницу. Если сайт содержит сотни или тысячи URL и обрабатывается большое количество страниц, qcbot закономерно может появляться в логах на множестве адресов.

Пример: CCSS

CCSS — Critical CSS — ещё один пример функции, для которой внешней системе необходимо получить страницу и проанализировать её содержимое.

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

Пример: VPI

VPI — Viewport Images также требует анализа страниц. QUIC.cloud прямо указывает, что UCSS, CCSS и VPI относятся к сервисам, которым необходимо обращаться ко всем обрабатываемым страницам.

Почему qcbot иногда выглядит как агрессивный crawler

Если смотреть только на access.log, поведение может показаться подозрительным:

• нет обычной пользовательской сессии;
• много URL;
• запросы идут с серверных IP;
• могут последовательно обрабатываться страницы;
• запрашиваются изображения и другие ресурсы;
• активность не сопровождается конверсиями или JavaScript-сессиями.

Но для qcbot эти признаки сами по себе не доказывают нежелательный scraping.

Если владелец только что включил UCSS, CCSS, VPI или массовую оптимизацию изображений, рост автоматического трафика может быть ожидаемым следствием работы сервиса.

Как выглядит User-Agent qcbot

QUIC.cloud публикует примеры собственных User-Agent. Они не ограничиваются короткой строкой qcbot.

Один из документированных вариантов выглядит примерно так:

Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; qcbot/1.0; +http://quic.cloud/bot.html) Chrome/112.0.0.0 Safari/537.36

Другой вариант имитирует мобильное браузерное окружение и также содержит:

qcbot/1.0

Поэтому при детекции не следует требовать полного совпадения строки.

Практический паттерн:

qcbot

с поиском без учёта регистра.

Почему браузерная часть User-Agent не должна вводить в заблуждение

В строке присутствуют маркеры Chrome, Safari, AppleWebKit и даже параметры мобильного устройства.

Если система аналитики классифицирует клиента только по началу UA, qcbot может ошибочно попасть в статистику браузеров.

Поэтому TrafficVeil полезно анализировать не только первую часть User-Agent, но и всю строку, обнаруживая специализированный токен qcbot.

Как найти qcbot в логах Nginx

Базовый поиск:

grep -i "qcbot" /var/log/nginx/access.log

Количество запросов:

grep -ic "qcbot" /var/log/nginx/access.log

Топ IP:

grep -i "qcbot" /var/log/nginx/access.log \
| awk '{print $1}' \
| sort \
| uniq -c \
| sort -nr \
| head -20

Топ URL:

grep -i "qcbot" /var/log/nginx/access.log \
| awk '{print $7}' \
| sort \
| uniq -c \
| sort -nr \
| head -30

Распределение кодов ответа:

grep -i "qcbot" /var/log/nginx/access.log \
| awk '{print $9}' \
| sort \
| uniq -c \
| sort -nr

Какие URL особенно полезно анализировать

Одного количества запросов недостаточно. Набор путей часто позволяет сразу понять назначение активности.

Наблюдение	Возможное объяснение
Запрашиваются изображения	Image Optimization
Много публичных HTML-страниц	UCSS, CCSS или VPI
Запросы LiteSpeed REST API	Служебное взаимодействие LiteSpeed Cache и QUIC.cloud
Большое число 403	WAF или firewall блокирует QUIC.cloud
Большое число 429	Слишком строгий rate limit
Необычные пути, никак не связанные с сервисом	Требуется проверка возможного spoofing

qcbot может обращаться к WordPress REST API

Для сайтов на WordPress это особенно важный момент.

В реальных диагностических логах LiteSpeed встречаются обращения qcbot к маршрутам семейства:

/?rest_route=/litespeed/...

Например, через такие endpoint могут выполняться служебные callback-запросы QUIC.cloud.

Поэтому широкое правило вида «блокировать всех ботов на REST API» способно незаметно нарушить LiteSpeed Cache.

Проблема может выглядеть неожиданно: сам WordPress работает, посетители открывают сайт, но UCSS, CCSS, VPI или Image Optimization начинают завершаться ошибкой.

Как оценить реальную нагрузку qcbot

Для qcbot нельзя применять универсальное правило вроде «больше 10 запросов в минуту — атака».

Количество обращений зависит от того, какие Online Services активированы.

QUIC.cloud отдельно указывает, что Image Optimization работает с изображениями, тогда как UCSS, CCSS и VPI могут обращаться ко всем страницам.

Поэтому сайт из 50 страниц и интернет-каталог из 100 000 URL закономерно будут иметь совершенно разный профиль qcbot.

Что измерять

• запросы в минуту и час;
• количество уникальных URL;
• число уникальных IP;
• HTTP-методы;
• долю HTML;
• долю изображений;
• объём переданных данных;
• ответы 2xx, 4xx и 5xx;
• время ответа origin;
• изменение CPU и RAM;
• какие QUIC.cloud Services включены.

Почему высокий RPS не всегда означает проблему

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

Вместо немедленной блокировки нужно сопоставить всплеск со временем:

• активации QUIC.cloud;
• включения UCSS или CCSS;
• очистки оптимизированных данных;
• массового обновления страниц;
• запуска Image Optimization;
• изменения настроек LiteSpeed Cache.

Если события совпадают, высокая активность может иметь понятное техническое объяснение.

У QUIC.cloud есть официальный список IP

Да. Поэтому утверждение «отдельного списка IP нет» для qcbot неверно.

QUIC.cloud публикует актуальный список своей инфраструктуры и рекомендует разрешать эти адреса на origin, чтобы firewall не мешал работе сервиса.

При этом существует важная особенность: IP-лист не статичен.

QUIC.cloud предупреждает, что узлы добавляются и удаляются достаточно часто для оптимизации глобальной сети. Поэтому firewall allowlist требует регулярного обновления.

Почему не стоит копировать IP в статью

Если перечислить десятки текущих адресов прямо здесь, статья быстро устареет.

Более правильная схема для TrafficVeil:

1. хранить оператора QUIC Cloud Inc.;
2. получать или регулярно синхронизировать официальный список;
3. сопоставлять UA qcbot с IP;
4. учитывать ASN и поведение;
5. помечать несовпадения отдельно.

Так адрес, добавленный QUIC.cloud через месяц, не станет ошибочно определяться как неизвестный источник.

Можно ли доверять qcbot только по User-Agent

Нет.

User-Agent — обычный HTTP-заголовок. Любой клиент способен отправить:

User-Agent: Mozilla/5.0 (compatible; qcbot/1.0; +http://quic.cloud/bot.html)

Это ещё не делает клиента частью QUIC.cloud.

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

• UA;
• IP;
• соответствие актуальной инфраструктуре QUIC.cloud;
• ASN;
• URL;
• HTTP-методы;
• поведение;
• использование QUIC.cloud самим сайтом.

Как проверить IP вручную

IP="1.2.3.4"

whois "$IP"
dig +short -x "$IP"

ASN:

whois -h whois.cymru.com " -v $IP"

Однако принадлежность облачному или хостинговому ASN сама по себе ничего не доказывает.

Намного сильнее совпадение IP с актуальным официальным списком QUIC.cloud.

Что делать, если qcbot приходит с неизвестного IP

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

Правильный порядок:

1. обновить официальный список QUIC.cloud;
2. снова проверить IP;
3. посмотреть полный UA;
4. проверить URL и метод;
5. сравнить поведение с обычным qcbot;
6. только после этого принимать решение.

Если адрес отсутствует в актуальной инфраструктуре, а клиент выполняет нетипичное сканирование, его уже следует рассматривать как возможную подмену qcbot.

Нужно ли разрешать qcbot

Если сайт использует Online Services QUIC.cloud — да, подтверждённому qcbot необходимо обеспечить доступ.

Официальная документация говорит достаточно однозначно: qcbot должен иметь свободный и нефильтрованный доступ для нормальной работы сервисов QUIC.cloud.

Это не означает, что любой посетитель со словом qcbot должен обходить WAF. Речь идёт о подтверждённой инфраструктуре оператора.

Что произойдёт после блокировки qcbot

Блокировка не обязана полностью уронить сайт. Именно поэтому такую ошибку бывает сложно обнаружить.

Посетители могут продолжить видеть страницы, но связанные Online Services перестанут работать корректно.

Возможные симптомы:

• Image Optimization не получает изображения;
• оптимизированные изображения не возвращаются на сайт;
• UCSS не генерируется;
• CCSS остаётся в очереди или завершается ошибкой;
• VPI не обрабатывает страницы;
• REST callback получает 403;
• в LiteSpeed Cache появляются ошибки облачных сервисов.

Типичная ошибка: блокировка всех User-Agent со словом bot

Например, правило:

if ($http_user_agent ~* "bot") {
    return 403;
}

заблокирует не только неизвестных scraper, но и qcbot, Googlebot, Bingbot и множество полезных сервисных агентов.

На сайте с LiteSpeed Cache это способно привести к трудно диагностируемым проблемам оптимизации.

Фильтрация ботов должна учитывать конкретную идентичность агента, а не просто наличие слова bot.

Стоит ли блокировать qcbot через robots.txt

robots.txt не является оптимальным инструментом управления qcbot.

В данном случае агент обслуживает функции, которые владелец сайта фактически включил сам через QUIC.cloud/LiteSpeed Cache.

Даже если использовать:

User-agent: qcbot
Disallow: /

это не решает главную задачу: включённые Online Services всё ещё нуждаются в доступе к ресурсу.

Кроме того, robots.txt является декларативным протоколом и не заменяет firewall.

Как правильно уменьшить количество запросов qcbot

Это один из наиболее важных моментов.

Если подтверждённый qcbot создаёт больше активности, чем вы хотите, QUIC.cloud рекомендует не душить его случайным rate limit, а сначала проверить, какие Online Services включены.

Например, если конкретному сайту не нужен определённый механизм Page Optimization, логичнее отключить соответствующую функцию LiteSpeed Cache.

После этого исчезнет сама причина части обращений.

Можно ли поставить rate limit

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

Например:

limit_req_zone $binary_remote_addr zone=qcbot:10m rate=10r/m;

может начать возвращать 429 Too Many Requests во время законной обработки большого количества ресурсов.

В результате проблема просто переместится из CPU origin в ошибки LiteSpeed Cache.

Rate limit оправданнее применять к неподтверждённому источнику с UA qcbot, чем к верифицированной инфраструктуре используемого сервиса.

Как полностью заблокировать qcbot через Nginx

Если QUIC.cloud Online Services гарантированно не используются и требуется запретить этот UA:

if ($http_user_agent ~* "qcbot") {
    return 403;
}

Но правило проверяет только текст User-Agent и одинаково заблокирует как настоящий QUIC.cloud, так и подделку.

Блокировка через Apache

RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} qcbot [NC]
RewriteRule ^ - [F,L]

Перед установкой такого правила убедитесь, что на сайте не используются функции LiteSpeed Cache, которым требуется QUIC.cloud.

qcbot и TrafficVeil

В TrafficVeil qcbot правильнее хранить как известного легитимного сервисного агента QUIC Cloud Inc.

Оптимальная модель идентификации:

1. обнаружить токен qcbot;
2. определить оператора QUIC Cloud Inc.;
3. проверить исходный IP;
4. сопоставить его с актуальной инфраструктурой QUIC.cloud;
5. проверить ASN;
6. проанализировать URL и HTTP-метод;
7. определить, использует ли сайт QUIC.cloud;
8. после этого применить политику.

Почему здесь полезна динамическая верификация

QUIC.cloud прямо предупреждает, что IP-адреса инфраструктуры меняются.

Для TrafficVeil это хороший пример бота, для которого статический справочник недостаточен.

Если база обновляется редко, возникает два типа ошибок:

• false negative: новый настоящий адрес QUIC.cloud определяется как неизвестный;
• false positive: старый адрес продолжает считаться доверенным после ухода из инфраструктуры оператора.

Периодическая синхронизация с официальным IP-фидом уменьшает обе проблемы.

Как TrafficVeil может показывать qcbot пользователю

Поле	Рекомендуемое значение
Название	QUIC.cloud Bot (qcbot)
Оператор	QUIC Cloud Inc.
Категория	Прочие краулеры и сервисы
Статус	Легитимный
Назначение	Online Services QUIC.cloud
Рекомендация при активном QUIC.cloud	Allow после проверки происхождения
Рекомендация без QUIC.cloud	Отдельное доверенное исключение не требуется
Проверка	User-Agent + актуальный QUIC.cloud IP + поведение

Как понять, что WAF уже мешает qcbot

Посмотрите распределение кодов ответа.

Если для qcbot много:

• 403 — скорее всего, запрос запрещает firewall или WAF;
• 429 — срабатывает rate limit;
• 5xx — запрос достигает origin, но приложение обрабатывает его с ошибкой;
• redirect на CAPTCHA — bot protection вмешивается в служебный обмен.

Последний вариант особенно коварен. Вместо ожидаемого JSON или изображения QUIC.cloud может получить HTML CAPTCHA, после чего связанная операция завершится ошибкой.

Что делать при ошибках UCSS, CCSS, VPI или Image Optimization

1. Найдите qcbot в логах за время возникновения ошибки.
2. Проверьте HTTP-статусы.
3. Посмотрите, не выдаётся ли CAPTCHA.
4. Проверьте IP источника по актуальному списку QUIC.cloud.
5. Посмотрите правила GeoIP, ASN и bot protection.
6. Проверьте rate limit.
7. Разрешите подтверждённую инфраструктуру QUIC.cloud.
8. Повторите операцию и снова проверьте журнал запросов.

Когда qcbot действительно стоит заблокировать

Главный сценарий — сайт вообще не использует QUIC.cloud Online Services и не нуждается в этом агенте.

Также отдельного внимания требует ситуация, когда клиент:

• заявляет UA qcbot;
• не принадлежит актуальной инфраструктуре QUIC.cloud;
• ищет уязвимости;
• перебирает административные пути;
• пытается открыть .env, .git или backup-файлы;
• создаёт аномальный RPS;
• не соответствует поведению сервисного агента.

В таком случае известное название User-Agent не должно давать клиенту никаких привилегий.

Когда qcbot следует разрешить

Ситуация	Рекомендация
Активны QUIC.cloud Online Services	Allow подтверждённому qcbot
Работает Image Optimization	Не блокировать получение изображений
Используются UCSS/CCSS/VPI	Разрешить необходимый обход страниц
Получаются 403/429	Проверить WAF и rate limit
UA корректный, но IP не подтверждён	Не предоставлять автоматический bypass
QUIC.cloud не используется	Специальный Allow не нужен
Поведение явно вредоносное	Deny независимо от заявленного UA

Практический чек-лист для администратора

1. Установите владельца. qcbot принадлежит QUIC Cloud Inc.
2. Проверьте конфигурацию сайта. Используется ли LiteSpeed Cache и подключены ли Online Services.
3. Посмотрите полный User-Agent. Ищите устойчивый токен qcbot.
4. Проверьте IP. Сопоставьте его с актуальным списком QUIC.cloud.
5. Посмотрите URL. Изображения и массовая обработка страниц могут быть ожидаемыми.
6. Изучите HTTP-коды. 403 и 429 часто означают конфликт с защитой.
7. Не устанавливайте случайный rate limit. Сначала проверьте активные Online Services.
8. Не создавайте bypass только по UA. Строка легко подделывается.
9. Если сервисы не нужны — отключите их. Это предпочтительнее борьбы со следствием на уровне firewall.

Итог

qcbot — официальный и документированный служебный crawler QUIC.cloud, а не неизвестный нежелательный бот. Он используется Online Services QUIC.cloud для получения страниц, изображений и других данных, необходимых Image Optimization, UCSS, CCSS, VPI и связанным функциям.

Поэтому высокая активность qcbot не должна автоматически классифицироваться как scraping или L7-атака. Сначала необходимо проверить, какие сервисы LiteSpeed Cache и QUIC.cloud включены на сайте.

Одновременно нельзя доверять одному User-Agent: название qcbot может подделать любой HTTP-клиент. Для TrafficVeil оптимальный вариант — связывать UA с актуальными IP QUIC.cloud, ASN, запрашиваемыми URL и поведением.

Если QUIC.cloud используется, подтверждённый qcbot обычно следует разрешить. Если сервис не нужен, лучше отключить соответствующие Online Services. А если неизвестный источник только представляется qcbot и ведёт себя как сканер, известное имя не должно позволять ему обходить защиту.