Как читать логи AntiBot.Cloud: AUTO, ALLOW, FAKE и ошибки облака

С чего начать разбор

В логе ищут ответ на конкретный вопрос: почему посетитель получил капчу, как бот попал на страницу или почему поисковик не скачал документ. Один статус не отвечает на все три вопроса.

Зафиксируйте время проблемы и URL. Затем найдите обращения за этот интервал и сравните запись защиты с access log веб-сервера. В первом виден результат проверки, во втором — фактический HTTP-ответ. Если используется CDN или прокси, убедитесь, что в записи указан адрес посетителя, а не адрес промежуточного сервера.

Для разбора соберите:

• время запроса с часовым поясом;
• URL, метод запроса и HTTP-код;
• статус и причину решения в AntiBot.Cloud;
• User-Agent — строку, которой клиент представляется серверу;
• правило, по которому предоставлен или запрещён доступ, если оно отображается;
• несколько соседних обращений того же клиента.

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

AUTO: автоматический проход нужно оценивать по результату

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

4 марта 2026 года разработчик сообщил, что после обновления AUTO стало больше, а на показанных ему сайтах одновременно не обнаружилось роста роботности, отказов и необычного трафика. Он связал изменение с уменьшением ложных срабатываний. Это наблюдение по отдельным сайтам, а не правило для любого проекта. Сообщение разработчика

Проверяйте, что изменилось вместе с AUTO:

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

ALLOW: сначала найдите исключение

Если нежелательные клиенты проходят проверку, начинайте с разрешающих правил. 28 января 2026 года разработчик назвал забытые allow-правила самой частой причиной такого поведения. Сообщение об исключениях

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

Порядок проверки:

1. Найдите запись нежелательного запроса.
2. Определите, какое исключение совпало с ним.
3. Сравните условие с задачей, ради которой его добавляли.
4. На тестовой копии сузьте условие и повторите запрос.
5. Проверьте сценарий, для которого исключение действительно нужно: обмен данными, уведомление или работу интеграции.

Разрешённый бот может выполнять JavaScript и попадать в Метрику. В ноябре 2023 года разработчик отдельно напоминал, что полезный для владельца бот всё равно может оставаться ботом для аналитики. Поэтому ненулевая роботность не означает, что защита проигнорировала правило. Разрешённые боты и аналитика

FAKE: смотрите на URL и проверяйте подлинность

FAKE — повод проверить, за кого представился клиент и удалось ли подтвердить его происхождение. Запись может относиться к сканеру с поддельным User-Agent или к настоящему поисковому роботу с проблемой проверки. Решение зависит от конкретного запроса.

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

Например, серия обращений к отсутствующим конфигам и архивам резервных копий — основание изучить сканирование. Само название Googlebot или YandexBot в строке клиента ничего не подтверждает: этот заголовок можно подставить.

Если клиент заявляет, что принадлежит Яндексу, проверьте его по официальной инструкции: обратный DNS-запрос должен дать домен Яндекса, а прямой запрос по этому имени — исходный IP. В Вебмастере также есть инструмент проверки IP. Подробный разбор ложных срабатываний — в отдельной статье.

Cloud API unresponsive: облако не ответило

Сообщение Cloud API unresponsive относится к обмену с облачным сервисом. Оно не позволяет сразу определить причину: недоступен сам сервис, нарушена связь с ним или запрос прервало ограничение на вашем сервере.

2 июня 2026 года разработчик связывал такую запись с недоступностью российского дата-центра. По его сообщению, посетители могли видеть задержку 2–3 секунды перед капчей; позже в тот же день работа восстановилась. Это пример конкретного инцидента, а не ожидаемая задержка при каждом запросе. Сообщение о сбое

При повторении ошибки:

1. Сопоставьте время с новостями сервиса.
2. Проверьте доступность облачного сервера с хостинга сайта. Доступность личного кабинета из вашего браузера — отдельная проверка.
3. Уточните у хостинга ограничения исходящих соединений и DNS.
4. Посмотрите, что фактически получает посетитель: страницу, проверку или ошибку.
5. Если проблема сохраняется, передайте поддержке время, версию скрипта и текст ошибки.

Как выбирать поведение сайта при сбое, разобрано в статье об инфраструктуре.

Error MikCached (ip): учитывайте контекст сообщения

19 августа 2026 года разработчик сообщил о кратковременном появлении Error MikCached (ip) при обновлении серверов. По его описанию, запросы в этот момент приводили к показу капчи. Сообщение об обновлении

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

Как проверить, что исправление помогло

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

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