Мобильный Chrome с серверного IP — это бот на 100%: как я вычислил ботоферму по логам Метрики

Меня зовут Анатолий Кузнецов, я занимаюсь SEO с 2005 года, за плечами более 300 проектов и только белые методы. В августе 2026 года на мои собственные сайты пошла массированная накрутка поведенческих факторов: до 3000 визитов в день, местами до 90–92% всего трафика. Первое, что бросается в глаза в отчётах Яндекс.Метрики, — это идеальные, слишком идеальные посетители. Мобильный Chrome, Android, аккуратное время на сайте. Вот только все они пришли с адресов, с которых живой человек прийти не может физически.

Эта статья — детективный разбор одного простого, но железобетонного признака: мобильный User-Agent плюс серверный IP из дата-центра равно бот на 100%. Я покажу, что такое дата-центр против мобильного оператора, как достать сырые IP-адреса через Logs API Яндекс.Метрики мимо фильтра отображения, почему для опознания сети хватает маски /24, как по IP определить владельца сети через ASN и whois, и главное — как вы сами, без сеошника, сможете проверить, крутят вас боты или нет.

Материал рассчитан на владельцев бизнеса, а не на технарей. Все термины объясняю по ходу. Если после прочтения вы поймёте, что вас атакуют, — это уже половина решения, потому что дальше есть чёткий план действий. А если хотите системно навести порядок с трафиком и позициями, посмотрите, как устроено SEO-продвижение сайтов в моей практике.

Коротко

• Мобильный браузер не выходит в интернет через сервер. Реальный телефон подключается через МТС, Мегафон, Билайн, Yota или домашний Wi-Fi. Если UA говорит «Chrome Mobile, Android», а IP принадлежит хостингу — это бот, вероятность ошибки почти нулевая.
• Стандартный отчёт Метрики IP не показывает. Сырые адреса достаются через Logs API — это выгрузка событий мимо визуального фильтра и мимо галки «фильтровать роботов».
• Хватает маски /24. Метрика отдаёт IP с обнулённым последним октетом, но для определения сети, её владельца и ASN этого достаточно.
• Концентрация выдаёт ферму. В моём случае 99% ботов пришли всего с 6 подсетей хостингов Miran, IMAQLIQ, TimeWeb, Evro Telecom. Такую концентрацию легко заблокировать.
• Поведение подделано под идеал. Время на сайте ~15–17 секунд (чуть выше порога отказа), отказы ~9%. У живых людей на этих же страницах отказы ~30%, время ~78 секунд.
• Проверить может каждый. Нужен доступ к Метрике, токен и полчаса времени. Ниже — пошагово.

Что меня насторожило: слишком хорошие посетители

SEO-специалист с опытом смотрит на отчёты по-другому, чем владелец сайта. Владелец радуется росту посещаемости. Я же насторожился именно потому, что посещаемость выросла резко и «неправильно». За несколько дней трафик подскочил в разы, но заявок и звонков больше не стало ни на одну. Деньги на сайт приходят, а на телефон — тишина. Это классический маркер: трафик есть, людей нет.

Дальше я открыл отчёт по устройствам и увидел почти монолит: подавляющее большинство визитов — мобильные, браузер Chrome Mobile, операционка Android. Само по себе это нормально: мобильного трафика сейчас реально много. Но версии Android были размазаны неестественно ровно — от 12-й до 15-й, будто кто-то специально ротировал их по кругу, чтобы имитировать разнообразие живой аудитории. У настоящих людей распределение версий всегда неровное, с горбами на популярных моделях. Здесь же был искусственный, лабораторно-гладкий шум.

Поведение довершало картину. Глубина просмотра — почти всегда ровно одна страница. Время на сайте — кучно в районе 15–17 секунд. Отказов — смешные 9%. Так «идеально» люди себя не ведут. Живой человек либо уходит через три секунды, либо залипает на пару минут, читает, кликает, возвращается. Ботам же задали параметр «сидеть чуть дольше 15 секунд», потому что 15 секунд — это порог, ниже которого Яндекс засчитывает визит как отказ. Ферма буквально настроена не пересекать этот порог. Такую механику я подробно разбирал в материале о том, как определить накрутку поведенческих факторов на сайте.

Главная улика: телефон, который выходит в сеть через сервер

Теперь ключевая мысль всей статьи, ради которой всё затевалось. Чтобы её понять, надо разобраться, чем IP-адрес мобильного телефона отличается от IP-адреса сервера.

Как в интернет выходит реальный телефон

Когда вы открываете сайт со смартфона, ваш трафик идёт через оператора связи. По мобильной сети — это МТС, Мегафон, Билайн, Tele2, Yota. По Wi-Fi дома — это ваш домашний провайдер: Ростелеком, Дом.ру, местный кабельный оператор. IP-адрес, который видит сайт, принадлежит одной из этих компаний. Эти сети называются «клиентскими» или «широкополосными»: они спроектированы для того, чтобы через них в интернет выходили живые люди со своих устройств.

Как в интернет выходит сервер

Сервер стоит в дата-центре — это здание, набитое стойками с вычислительным железом. Его задача — раздавать сайты, гонять базы данных, крутить приложения. IP-адреса дата-центров принадлежат хостинг-компаниям: в моём кейсе это были Miran, IMAQLIQ, TimeWeb, Evro Telecom. Через такие адреса в интернет выходят другие серверы, а не смартфоны в руках людей. У обычного человека нет и не может быть телефона, подключённого к сети напрямую через стойку в дата-центре.

Отсюда вывод, который не имеет исключений в реальной жизни: если User-Agent заявляет мобильный Chrome на Android, а IP-адрес принадлежит хостинг-провайдеру — перед вами программа, а не человек. Настоящий Android-смартфон не выходит в сеть через сервер Miran. Он выходит через Мегафон. Совпадение «мобильный UA + серверный IP» встречается только у автоматизированных скриптов, которые притворяются телефонами. Вероятность ошибки я оцениваю как нулевую в практическом смысле — за все годы ни разу не видел живого пользователя из дата-центра.

Почему обычный отчёт Метрики вам этого не покажет

Возникает резонный вопрос: если всё так очевидно по IP, почему я не увидел это сразу в интерфейсе Метрики? Ответ простой и неприятный. Яндекс.Метрика в стандартных отчётах не показывает IP-адреса посетителей. Это сделано ради приватности, и в целом правильно. Но для расследования атаки это связывает руки.

Хуже того, в настройках счётчика есть галка «Фильтровать роботов по поведению». Многие включают её и успокаиваются: роботы отфильтрованы, в отчётах чисто. Но это ловушка. Фильтр всего лишь прячет ботов из отчётов — он не мешает им грузить ваш сайт и не мешает им портить поведенческие факторы, которые Яндекс всё равно учитывает при ранжировании. То есть галка маскирует масштаб атаки, создавая иллюзию порядка. Вы смотрите на чистенький график и не понимаете, почему позиции проседают. Об этой и других обманчивых цифрах я писал в статье про то, почему 80% владельцев сайтов смотрят не те цифры в Яндекс.Метрике.

Значит, нужен способ достать сырые данные — до фильтрации, до агрегации, с настоящими IP. И такой способ есть.

Как достать сырые IP через Logs API Яндекс.Метрики

Logs API — это отдельный интерфейс Метрики, который отдаёт «сырые» логи: строчку на каждый визит или просмотр, со всеми техническими полями, которые в обычных отчётах скрыты или усреднены. В том числе — IP-адрес. Причём эта выгрузка идёт мимо визуального фильтра и мимо галки «фильтровать роботов». Именно поэтому боты, спрятанные в интерфейсе, в логах видны как на ладони.

Общая логика работы такая:

1. В настройках Яндекса создаёте OAuth-токен с доступом к Метрике. Это ключ, который подтверждает, что запрос делаете именно вы, владелец счётчика.
2. Отправляете запрос на создание «лог-реквеста»: указываете номер счётчика, диапазон дат, источник (визиты или просмотры) и список нужных полей — среди них ym:s:clientIP (IP-адрес), ym:s:browser, ym:s:operatingSystem, ym:s:pageViews (глубина), ym:s:visitDuration (время на сайте).
3. Метрика готовит выгрузку — на это уходит от секунд до минут. Проверяете статус, дожидаетесь готовности.
4. Скачиваете результат в виде таблицы (TSV) и открываете хоть в Excel, хоть в Google Таблицах.

Дальше начинается самое интересное: вы сортируете таблицу по IP и сразу видите, что тысячи «мобильных» визитов приходят с горстки адресов. Это невозможно для живой аудитории, где IP размазаны по всей стране. Похожий разбор сырых логов я делал в материале о том, что я увидел в логах 50 сайтов после последнего апдейта.

Почему маска /24 — это не проблема, а подсказка

Есть нюанс: в целях приватности Метрика отдаёт IP не полностью. Последний из четырёх блоков адреса обнулён. Вместо условного 91.142.85.207 вы увидите 91.142.85.0. Такой формат называется «маска /24» — это значит, что известны первые три блока, а последний может быть любым из 256 значений.

Казалось бы, потеря данных. На деле — наоборот. Для расследования нам не нужен конкретный компьютер, нам нужна сеть, из которой идёт атака. А сеть /24 — это как раз блок из 256 адресов, который целиком принадлежит одному владельцу. Зная три первых блока, я точно знаю, чья это сеть, какой хостинг за ней стоит и к какому провайдеру она относится. Для блокировки этого более чем достаточно: я блокирую не один адрес, а всю подсеть целиком, и ферма теряет сразу сотни адресов, с которых могла бы стучаться.

То есть Яндекс, скрывая последний октет ради приватности живых людей, никак не мешает вычислять и блокировать ботоферму. Маска /24 — это ровно тот уровень детализации, который нужен для боевой работы.

Определяем владельца сети: ASN и whois простыми словами

Когда у меня на руках список подсетей вида 91.142.85.0/24, следующий шаг — понять, кому они принадлежат. Для этого есть два инструмента.

Whois — «паспортный стол» для IP

Whois — это публичная база, где по IP-адресу или домену можно узнать, на кого он зарегистрирован. Вбиваете адрес на любом whois-сервисе (их десятки, бесплатные) и получаете название организации-владельца, страну, диапазон адресов и контакты. Именно так я увидел за своими подсетями названия хостингов, а не операторов связи. Это и был приговор: живой мобильный трафик не приходит из адресного пространства хостинга.

ASN — «номер автономной сети»

ASN (Autonomous System Number) — это уникальный номер, который присваивается крупной сети в интернете: провайдеру, хостингу, оператору. Грубо говоря, весь интернет поделён на такие «автономные системы», и у каждой свой номер. Зная ASN, вы понимаете, к какому типу относится сеть. У МТС, Мегафона и Ростелекома свои ASN, помеченные как сети операторов связи и широкополосного доступа. У хостингов — свои, помеченные как дата-центры и хостинг-провайдеры. Когда мобильный трафик валит из ASN, принадлежащего хостингу, диагноз ставится за минуту.

Полезно ещё держать в голове, что поисковые роботы — тоже автоматика, но легальная и с известными адресами. YandexBot ходит из сетей 77.88.*, Googlebot — из 66.249.*. В подсетях моей ботофермы этих роботов не было и близко. Значит, блокировка подсетей никак не заденет индексацию — поисковики просто ходят другими маршрутами. Как вообще устроен обход сайта поисковиками, я разбирал в статье про то, как работают поисковые роботы.

Цифры из реального расследования

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

Параметр	Боты (ферма)	Живые посетители
Объём	~3000 визитов/день, до 90–92% трафика	остаток ~8–10%
User-Agent	Chrome Mobile, Android 12–15 (ровная ротация)	разнобой устройств и браузеров
Источник IP	дата-центры: Miran, IMAQLIQ, TimeWeb, Evro Telecom	операторы связи и домашние провайдеры
Глубина	1 страница	несколько страниц
Время на сайте	~15–17 сек (чуть выше порога отказа)	~78 сек
Отказы	~9% (подделка «идеала»)	~30%

И самое показательное: 99% всех ботов пришли всего с шести подсетей. Вот они, без прикрас:

• 91.142.85.0/24
• 45.135.94.0/24
• 81.29.135.0/24
• 81.29.136.0/24
• 109.248.57.0/24
• 37.77.107.0/24
• плюс диапазон IPv6 2a00:f2a0::/32

Такая концентрация — это подарок для защиты. Когда 99% атаки идёт из шести сетей, вам не нужно ловить каждый адрес по отдельности. Достаточно закрыть эти шесть подсетей — и ферма отваливается почти целиком.

Что делать: блокировка на сервере, а не Cloudflare

Когда враг известен поимённо, лечение простое и быстрое. Я закрыл выявленные подсети прямо на сервере через файл .htaccess (для Apache — директивы Require not ip или Deny from; для nginx это делается блоком deny). Результат: трафик рухнул с ~250 до ~13 визитов в час, минус 95%, буквально за час. И это именно тот случай, когда падение трафика — отличная новость: ушёл мусор, остались живые люди.

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

А теперь важное предупреждение. Многие в такой ситуации бросаются подключать Cloudflare. Для Рунета это опасно. JS-челлендж Cloudflare (та самая проверка «подождите, проверяем ваш браузер») нередко ловит YandexBot и Googlebot, из-за чего страницы вылетают из индекса и позиции проседают. Плюс Cloudflare гонит трафик через зарубежные узлы, что для российского поиска тоже не плюс. Если базовой блокировки на сервере мало и нужна серьёзная защита — смотрите в сторону российских анти-бот решений: Qrator, DDoS-Guard, Variti. Подробный разбор рисков есть в моей статье о том, как уменьшить роботность в Яндекс.Метрике.

Вторая накрутка, которую не видно в Метрике

Пока я разбирался с ботофермой в Метрике, всплыла вторая, отдельная атака — накрутка CTR через поиск. Механика другая. Боты не заходят на сайт вообще. Они кликают по вашему сниппету прямо в выдаче Яндекса по запросам-конструкторам вида «услуга + бренд» или «услуга + домен», раздувая кликабельность до невозможных значений — 50–84% на позициях с пятой по двенадцатую. В реальной жизни такого CTR на этих позициях не бывает.

Коварство в том, что на сайт эти боты не переходят, значит, в Метрике их нет вообще: ни визита, ни IP, ни строчки в логах. Блокировать на сервере нечего — некого. Увидеть эту накрутку можно только в Яндекс.Вебмастере: там тысячи кликов по запросам при десятках реальных визитов в Метрике. Лечится это не блокировкой, а жалобой в службу Яндекс.Платон и, если накрутку заказали через какой-то сервис «продвижения», отказом от этой услуги. Тему стороннего давления я разбирал в статье про то, как конкуренты пытаются выдавить сайт из топ-1.

Зачем это конкурентам: негативное SEO

Логичный вопрос владельца: кому вообще надо тратить деньги, чтобы гнать мне ботов? Ответ — негативное SEO. Схема такая: конкурент «крутит вас в минус». Он либо портит вам поведенческие факторы фермой ботов с идеально-фальшивым поведением, либо раздувает CTR по мусорным запросам, чтобы алгоритмы Яндекса заподозрили вас в накрутке. Дальше Яндекс накладывает фильтр за накрутку поведенческих — уже на ваш сайт. Вы проседаете, а конкурент в это время спокойно продвигается честными методами и занимает освободившиеся места.

Именно поэтому так важно уметь отличать свою честную работу от подстроенной атаки и вовремя её фиксировать документально — выгрузками из логов и скриншотами из Вебмастера. Про сам механизм санкций я писал отдельно: бан за накрутку поведенческих — как Яндекс загнал себя в ловушку.

Как проверить свой сайт самому: пошагово

Теперь самое ценное — инструкция, которую вы можете выполнить сами или отдать своему специалисту с конкретным ТЗ.

1. Оцените картину в Метрике. Резкий рост трафика без роста заявок — первый звонок. Откройте отчёт по устройствам и версиям ОС: неестественно ровное распределение версий Android — подозрительно.
2. Посмотрите поведение. Массовое время на сайте около 15–17 секунд при глубине в одну страницу и аномально низких отказах — это подделка под идеал, а не живые люди.
3. Создайте OAuth-токен с доступом к Метрике в кабинете Яндекса для разработчиков.
4. Сделайте выгрузку через Logs API за проблемный период с полями IP, браузер, ОС, глубина, время визита.
5. Отсортируйте по IP. Если тысячи «мобильных» визитов приходят с горстки подсетей — это ферма.
6. Пробейте подсети через whois и ASN. Название хостинга вместо оператора связи — приговор.
7. Закройте подсети на сервере через .htaccess или nginx. Наблюдайте за падением мусорного трафика.
8. Проверьте Вебмастер на предмет второй атаки — раздутого CTR по запросам-конструкторам. Если есть — пишите в Платон.

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

Главный вывод

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

Хорошая новость в том, что вычислить и обезвредить ферму реально своими силами: сырые IP через Logs API, whois и ASN для опознания сетей, блокировка подсетей на сервере. А галка «фильтровать роботов» и Cloudflare — это не защита, а в лучшем случае косметика, в худшем — вред для индексации. Смотрите на данные, а не на приглаженные графики, и ваш сайт скажет вам правду.