Боты приходят через VPN и мобильные прокси: почему блокировка по стране больше не работает

Когда владелец сайта впервые видит в отчётах всплеск «мусорного» трафика, первая мысль почти всегда одна: «Заблокирую всех, кто заходит из-за границы, и проблема решится». Логика понятная — если сайт торгует дачными домами в Подмосковье, зачем ему посетители из Амстердама или Сингапура? Но именно на этой интуитивной, казалось бы, идее ломается большинство самодельных систем защиты. Боты давно научились приходить с российских IP, с адресов реальных мобильных операторов, а иногда и с домашнего интернета обычных людей. И блокировка по стране в такой ситуации не просто бесполезна — она вредит, потому что режет живых клиентов, а ботов пропускает.

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

Коротко

• Блокировка по стране не работает, потому что боты приходят через мобильные и резидентные прокси с «живыми» российскими IP операторов связи.
• Гео-блокировка вредит: она режет реальных клиентов (в роуминге, через VPN, из соседних регионов), а продвинутых ботов не ловит.
• Дата-центровые боты — это простой случай. Их выдаёт серверный IP при мобильном User-Agent, и они блокируются по подсети. В моём кейсе — падение мусорного трафика на 95% за час.
• Резидентные и мобильные прокси сложнее: по одному IP их не вычислить. Распознавание идёт по совокупности признаков поведения, а не по одному параметру.
• Защита должна быть многоуровневой: серверный блок известных дата-центров, поведенческий анти-бот, чистота данных в Метрике и мониторинг через Logs API.
• Cloudflare и жёсткий гео-блок для Рунета опасны — они мешают роботам Яндекса и Google, а это прямой риск выпадения из индекса.

Почему «заблокирую заграницу» — это ловушка

Идея блокировать трафик по стране родилась в те времена, когда бот действительно сидел на дешёвом зарубежном сервере и выдавал себя IP-адресом откуда-нибудь из Нидерландов или США. Тогда фильтр по гео работал: отсёк все иностранные адреса — и большая часть мусора отвалилась. Но за последние годы рынок «серых» услуг по накрутке изменился кардинально. Появились и стали массовыми мобильные и резидентные прокси — сервисы, которые дают боту не серверный IP, а адрес реального устройства реального человека.

Работает это так. Мобильный прокси — это, по сути, симка в модеме, подключённая к сети МТС, Мегафона или Билайна. Бот, который ходит через такой прокси, для вашего сайта выглядит как обычный абонент оператора связи из России. Резидентный прокси — то же самое, но через домашний интернет обычных пользователей (нередко без их ведома, через заражённые устройства или сомнительные приложения). В обоих случаях IP-адрес принадлежит российскому провайдеру и физически находится в нужном регионе. Заблокировать такого «посетителя» по стране невозможно — он и так «из России». Заблокировать по конкретному провайдеру — значит отрезать десятки тысяч живых абонентов этого же оператора.

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

Два класса ботов: их нужно различать

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

Дата-центровые боты — простая мишень

Это боты, которые ходят с IP-адресов хостингов и дата-центров. Именно с ними я столкнулся во время августовской атаки. На сайт лилось около 3000 визитов в день — до 90–92% всего трафика. User-Agent у них был грамотно подделан: «Chrome Mobile / Android 12–15», причём версии операционной системы были равномерно размазаны, чтобы имитировать разнообразие реальных телефонов. Но именно эта деталь их и выдала: реальный телефон выходит в интернет через мобильного оператора или домашний Wi-Fi, а не через сервер в дата-центре. Мобильный User-Agent плюс серверный IP — это стопроцентный признак бота, живых людей с такой комбинацией не бывает.

Определить источник помог Logs API Яндекс.Метрики — он отдаёт сырые данные, которые проходят мимо фильтра отображения в интерфейсе. Оказалось, что 99% ботов приходили всего с шести подсетей, принадлежащих известным хостингам (Miran, IMAQLIQ, Evro Telecom, TimeWeb). Такая концентрация — подарок для защитника: заблокировал несколько подсетей — и убрал почти весь мусор. Подробнее про то, что вообще можно вытащить из сырых логов, я разбирал в статье о том, что я увидел в логах 50 сайтов после апдейта.

Резидентные и мобильные прокси — сложный случай

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

Реальный кейс: как блок по подсетям убрал 95% мусора

Расскажу, как выглядела победа над дата-центровой частью атаки, потому что цифры здесь показательны. Разобравшись через Logs API, что 99% ботов сидят всего на шести подсетях, я добавил их в блокировку на уровне сервера — через файл .htaccess на Apache (директивы Require not ip и Deny from). Вот эти сети, если интересно: 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.

Показатель	До блокировки	После блокировки
Визитов в час	~250	~13
Доля ботов в трафике	90–92%	близко к нулю
Время реакции	—	около часа

Трафик упал с примерно 250 до 13 визитов в час — это минус 95% за один час. И, что важно, риск задеть живых посетителей был нулевым: реальные люди с IP-адресов дата-центров на коммерческий сайт просто не заходят. Поисковые роботы в этих сетях тоже не работают — YandexBot ходит с адресов 77.88.*, Googlebot с 66.249.*, ни один из них не пересекается с заблокированными подсетями. Индексация не пострадала. Это ключевой момент: правильный серверный блок точечно бьёт по ботам и не трогает ни клиентов, ни поисковики.

Как распознать бота через мобильный прокси: не по одному признаку

С резидентными и мобильными прокси фокус «посмотрел на IP — заблокировал» не проходит. IP чистый, User-Agent правдоподобный, страна правильная. Единственный способ — смотреть на совокупность поведенческих сигналов. По отдельности каждый из них может встретиться и у живого человека, но когда они сходятся вместе и повторяются массово — это бот.

• Неестественно ровное время на сайте. В моём кейсе боты сидели около 15–17 секунд — чуть выше порога отказа в 15 секунд, чтобы формально не считаться отказом. Живые люди ведут себя куда более рвано: кто-то уходит через 3 секунды, кто-то читает 5 минут. Средняя у реальной аудитории была около 78 секунд.
• Подозрительно низкий процент отказов. У ботов он был около 9% — «идеальная» вовлечённость, которой в природе не бывает. У живых посетителей отказы держались в районе 30%.
• Глубина ровно одна страница. Бот заходит, «досиживает» нужные секунды и уходит, не переходя дальше.
• Ровный, равномерный поток визитов. Живой трафик пульсирует по часам суток и дням недели. Ботовый идёт монотонно, как по метроному.
• Странные страницы входа. Массовые заходы на второстепенные или технические URL, которые в обычной жизни почти не получают трафика.
• Полное отсутствие конверсий. Сотни и тысячи «вовлечённых» визитов и ноль заявок, звонков, добавлений в корзину. Настоящая заинтересованная аудитория так себя не ведёт.

Именно связка этих признаков и есть ваш детектор. Я подробно разбирал методику в отдельном материале — как определить накрутку поведенческих факторов на сайте. А про то, почему в стандартных отчётах Метрики так легко обмануться, есть текст о том, что 80% владельцев сайтов смотрят не те цифры.

Многоуровневая защита: как это устроено правильно

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

Уровень 1. Серверный блок известных дата-центров

Это первая линия и самый дешёвый по усилиям слой. Списки подсетей крупных хостингов и дата-центров известны, их можно закрыть на уровне .htaccess (Apache) или конфигурации nginx. Как показал мой кейс, именно этот слой снимает основную массу — до 90%+ грубого ботового трафика, — потому что большинство накрутчиков экономят и льют с дешёвых серверов.

Уровень 2. Поведенческий анти-бот

Против ботов на резидентных и мобильных прокси нужен сервис, который анализирует поведение в реальном времени и отделяет автоматизированные запросы от человеческих. Для Рунета это российские решения — Qrator, DDoS-Guard, Variti. Они умеют выдавать челлендж подозрительному трафику, не выбрасывая при этом поисковых роботов, что критично (об этом ниже).

Уровень 3. Чистота данных в Метрике

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

Уровень 4. Мониторинг через Logs API

Последний, но незаменимый слой — постоянное наблюдение за сырыми данными. Logs API отдаёт то, что интерфейс скрывает: реальные IP (пусть и с маской последнего октета — /24, этого достаточно для определения сети и ASN), User-Agent, страницы входа. Именно на этом уровне вы вовремя замечаете новую волну и понимаете, какой из предыдущих слоёв её пропустил.

Почему Cloudflare и гео-блок — плохая идея для Рунета

Отдельно предостерегу от популярного «универсального» совета — поставить Cloudflare и включить жёсткий гео-фильтр. Для западных проектов это может быть разумно, но для сайта, который продвигается в Яндексе, это игра с огнём.

Cloudflare часто отдаёт подозрительному трафику JavaScript-челлендж. Проблема в том, что под него легко попадают YandexBot и Googlebot — они не всегда исполняют JS так, как ожидает защита, и в итоге получают заглушку вместо страницы. Результат — сайт перестаёт нормально индексироваться и проседает в выдаче. Плюс сама архитектура Cloudflare гонит трафик через зарубежные узлы, что для российского поиска скорее минус, чем плюс.

Жёсткий гео-блок опасен по той же причине, что мы обсуждали в начале: он режет живых клиентов и не ловит ботов на резидентных прокси. Поэтому мой совет прост: блокировать на своём сервере (.htaccess или nginx) и, если нужен поведенческий слой, брать российские анти-бот-сервисы, которые дружат с поисковыми роботами Рунета. Важно помнить, что краулеры Яндекса и Google — это тоже «роботы», но их отсекать нельзя ни в коем случае: без них сайт просто выпадет из индекса.

Вторая, невидимая атака: накрутка CTR в выдаче

Есть тип накрутки, который вообще нельзя заблокировать на сервере, — и о нём важно знать, потому что владельцы часто путают его с ботами на сайте. Это накрутка CTR через поиск: боты кликают по вашему сайту прямо в выдаче Яндекса по специальным запросам-конструкторам вида «услуга + бренд» или «услуга + домен», создавая невозможный показатель кликабельности — 50–84% на позициях 5–12.

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

Негативное SEO: зачем вообще вас крутят

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

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

Что делать прямо сейчас: пошаговый план

1. Снимите сырые данные через Logs API. Посмотрите реальные IP, ASN и страницы входа. Не доверяйте одному только интерфейсу Метрики — он показывает уже отфильтрованную картину.
2. Найдите концентрацию. Если 90% мусора приходит с нескольких подсетей дата-центров — это ваш быстрый выигрыш.
3. Заблокируйте эти подсети на сервере через .htaccess или nginx. Проверьте, что не задели YandexBot (77.88.*) и Googlebot (66.249.*).
4. Оцените остаток по поведению. То, что осталось после блока подсетей и ведёт себя «слишком идеально», — кандидаты в боты на резидентных прокси. Здесь подключайте поведенческий анти-бот.
5. Проверьте Вебмастер отдельно. Если там аномальный CTR при малом трафике в Метрике — это накрутка кликов в выдаче, лечится жалобой в Платон.
6. Не включайте гео-блок и Cloudflare «на всякий случай». Для Рунета это чаще вредит, чем помогает.

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

Вывод

Главная ошибка в борьбе с ботами — вера в простое решение. «Заблокирую заграницу», «поставлю Cloudflare», «включу фильтр в Метрике» — каждый из этих шагов либо не работает, либо создаёт новые проблемы. Реальность 2026 года такова: боты приходят с чистых российских IP через мобильные и резидентные прокси, их не отличить от живых по одному параметру. Работает только связка — точечный серверный блок дата-центров там, где боты сконцентрированы, поведенческий анализ там, где IP чистые, честная работа с данными и постоянный мониторинг сырых логов. Это не разовая настройка, а процесс. Но именно он защищает и позиции, и нервы, и деньги, которые вы вкладываете в продвижение.