Сайт лежит из-за мусорных ботов и парсеров: как заблокировать паразитный трафик в Nginx и Cloudflare без потери Яндекса и Google

Каждый владелец интернет-магазина на OpenCart, каталога на 1С-Битрикс или контентного портала на WordPress рано или поздно сталкивается с внезапным кризисом: нагрузка на процессор (CPU Load Average) взлетает до 100%, оперативная память забивается процессами PHP-FPM, база данных MySQL падает с ошибкой Too many connections, а реальные покупатели видят белый экран с кодом 502 Bad Gateway / 504 Gateway Time-out.

При этом в счетчиках Яндекс Метрики и Google Analytics — полная тишина и обычные показатели посещаемости. Причина проста: ваш сервер штурмует паразитный бот-трафик — агрессивные парсеры цен конкурентов, AI-краулеры (LLM Scrapers), обучающие нейросети на ваших текстах, и бесконечные автоматические ботнеты, сканирующие уязвимости в CMS.

Главная опасность при попытке защититься вслепую — случайно заблокировать легитимных роботов Яндекса (YandexBot) и Google (Googlebot), что приведет к мгновенному вылету страниц из индекса и потере органического поискового трафика. В этом практическом руководстве мы построим надежную эшелонированную систему фильтрации на уровнях Edge WAF, Nginx и Fail2ban.

1. Кто нагружает сервер: типы паразитных ботов и мотивы атак

Паразитный трафик в 2026 году можно разделить на четыре четкие категории:

1. AI-краулеры и сборщики датасетов (AI Scrapers): Роботы от OpenAI (GPTBot), Anthropic (ClaudeBot), TikTok/ByteDance (Bytespider), Perplexity, CCBot и PetalBot. Они не приносят вам поисковый трафик, но выкачивают весь контент сайта со скоростью сотен страниц в секунду, полностью игнорируя директивы robots.txt и Crawl-delay.
2. Коммерческие парсеры цен и остатков: Скрипты конкурентов и маркетплейсов на Python (Scrapy, Selenium, Playwright, cURL, Requests). Они регулярно перебирают фильтры каталога, пагинацию и карточки товаров, создавая тяжелейшие некэшируемые SQL-запросы к базе данных.
3. Сканеры уязвимостей и брутфорс-боты: Ботнеты, непрерывно ищущие открытые служебные файлы (.env, .git, wp-config.php.bak, phpmyadmin) и перебирающие пароли к админкам через /wp-login.php, /xmlrpc.php и /bitrix/admin/.
4. Скликиватели и накрутчики ПФ (Fake Referrers): Боты с фальшивыми Referer-заголовками, генерирующие мусор в логах и статистике для искажения поведенческих факторов.

2. Как найти ботов в access.log: анализ через awk и GoAccess

Прежде чем что-либо блокировать, необходимо точно идентифицировать источники аномальной активности в журнале веб-сервера /var/log/nginx/access.log.

1. Топ-20 самых активных IP-адресов за последние часы:

# Подсчет количества запросов с каждого IP
sudo awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -nr | head -n 20

Интерпретация: Если один IP-адрес совершает 10 000 – 50 000 запросов за пару часов к динамическим страницам — это со 100% вероятностью парсер или сканер.

2. Топ-20 самых частых User-Agent:

# Выборка User-Agent из стандартного комбинированного формата логов Nginx
sudo awk -F'"' '{print $6}' /var/log/nginx/access.log | sort | uniq -c | sort -nr | head -n 20

Ищите подозрительные сигнатуры: Bytespider, GPTBot, ClaudeBot, python-requests, curl, Go-http-client, Scrapy, Java/, Wget или пустые строки "-".

3. Просмотр URL, по которым бьет конкретный бот:

# Анализ запросов от конкретного бота (например, Bytespider)
sudo grep -i "Bytespider" /var/log/nginx/access.log | awk '{print $7}' | sort | uniq -c | sort -nr | head -n 15

4. Интерактивный мониторинг в реальном времени через GoAccess:

Установите легковесный консольный анализатор логов:

sudo apt install -y goaccess
# Запуск мониторинга в терминале
sudo goaccess /var/log/nginx/access.log -c --log-format=COMBINED

GoAccess наглядно отобразит графики запросов в секунду, статус-коды (200, 403, 404, 502), используемые хосты и User-Agent с мгновенным обновлением.

3. Блокировка в Nginx: map User-Agent и сброс соединений (444/403)

Наиболее эффективный способ отсечения ботов на веб-сервере — использование директивы Nginx map. Она компилируется в хэш-таблицу в оперативной памяти и проверяет заголовки за доли микросекунды (0.001 мс) без нагрузки на процессор.

Создайте файл со списком сигнатур /etc/nginx/conf.d/bad_bots.conf:

# /etc/nginx/conf.d/bad_bots.conf
# Карта сопоставления нежелательных User-Agent
map $http_user_agent $is_bad_bot {
    default 0;

    # Агрессивные AI-скраперы и сборщики датасетов
    ~*Bytespider             1;
    ~*GPTBot                 1;
    ~*ClaudeBot              1;
    ~*CCBot                  1;
    ~*PetalBot               1;
    ~*Amazonbot              1;
    ~*PerplexityBot          1;
    ~*Seekport               1;
    ~*Omgilibot              1;
    ~*SemrushBot             1;
    ~*AhrefsBot              1;
    ~*MJ12bot                1;
    ~*DotBot                 1;

    # Утилиты автоматизации и скрипты парсинга
    ~*Scrapy                 1;
    ~*python-requests        1;
    ~*python-urllib          1;
    ~*aiohttp                1;
    ~*Go-http-client         1;
    ~*curl/                  1;
    ~*Wget/                  1;
    ~*libwww-perl            1;
    ~*HttpClient             1;

    # Сканеры уязвимостей
    ~*nikto                  1;
    ~*sqlmap                 1;
    ~*WPScan                 1;
    ~*Nmap                   1;
    ~*masscan                1;

    # Запрет пустых User-Agent
    ""                       1;
    "-"                      1;
}

Подключите блокировку внутри вашего виртуального хоста в блоке server {}:

server {
    server_name example.com www.example.com;

    # Мгновенный сброс соединения без отправки HTTP-заголовков (код 444)
    # Код 444 экономит исходящий трафик и сразу закрывает TCP-сокет
    if ($is_bad_bot) {
        return 444;
    }

    # ... остальная конфигурация сайта
}

4. Ограничение частоты запросов: директива limit_req_zone

Многие современные парсеры маскируются под обычные браузеры (отправляя валидный User-Agent Chrome/Firefox). Чтобы защитить динамические страницы (каталог, поиск, корзину), необходимо ограничить максимальное количество запросов в секунду с одного IP-адреса с помощью механизма Leaky Bucket (дырявое ведро).

Добавьте зоны лимитирования в секцию http {} файла /etc/nginx/nginx.conf:

# Выделение зон памяти под трекинг IP-адресов
# 10m памяти хранит около 160 000 уникальных IP
limit_req_zone $binary_remote_addr zone=general_limit:10m rate=15r/s;
limit_req_zone $binary_remote_addr zone=search_limit:10m rate=3r/s;

# Код ответа при превышении лимита (HTTP 429 Too Many Requests)
limit_req_status 429;

Примените лимиты к критическим секциям в конфигурации виртуального хоста:

server {
    # Общий лимит для всех страниц: до 15 запр/сек с буфером всплеска (burst) до 25
    limit_req zone=general_limit burst=25 nodelay;

    # Жесткий лимит для поиска по сайту и фильтрации (до 3 запр/сек)
    location ~* /(search|catalog|filter)/ {
        limit_req zone=search_limit burst=5 nodelay;
        try_files $uri $uri/ /index.php?$args;
    }
}

Параметр nodelay гарантирует, что запросы в пределах допустимого всплеска (burst) обрабатываются мгновенно, а все превышающие лимит запросы сразу получают статус 429 Too Many Requests, защищая базу данных от перегрузки.

5. Надежные VDS-серверы с защитой от DDoS-атак

Для проектов, регулярно сталкивающихся с пиковыми нагрузками и сетевым сканированием, необходима серверная инфраструктура с аппаратной защитой от L3/L4 DDoS и скоростными NVMe дисками. Ниже представлены проверенные облачные платформы:

6. Автобан сканеров админок через Fail2ban и UFW (wp-login, xmlrpc)

Если бот продолжает долбиться в закрытые разделы или превышать лимиты limit_req, его IP-адрес необходимо заблокировать на уровне сетевого экрана Linux iptables / UFW, чтобы сервер вообще не тратил ресурсы на обработку SSL-хэндшейка и HTTP-запросов.

1. Настройка фильтра сканеров админок (/etc/fail2ban/filter.d/nginx-forbidden.conf):

[Definition]
failregex = ^ -.* "(GET|POST|HEAD) .*(wp-login.php|xmlrpc.php|wp-admin|bitrix/admin|.env|.git|phpmyadmin|setup.php) HTTP.*" (403|404|444)
ignoreregex =

2. Настройка фильтра превышения Rate Limiting (/etc/fail2ban/filter.d/nginx-req-limit.conf):

[Definition]
failregex = ^ -.* "(GET|POST|HEAD) .*" 429
ignoreregex =

3. Активация джейлов в /etc/fail2ban/jail.local:

[nginx-forbidden]
enabled  = true
port     = http,https
filter   = nginx-forbidden
logpath  = /var/log/nginx/access.log
maxretry = 3
findtime = 600
bantime  = 86400

[nginx-req-limit]
enabled  = true
port     = http,https
filter   = nginx-req-limit
logpath  = /var/log/nginx/access.log
maxretry = 10
findtime = 60
bantime  = 3600

Перезапустите сервис: sudo systemctl restart fail2ban. Теперь любой бот, сделавший 3 попытки обратиться к xmlrpc.php или превысивший лимит запросов, мгновенно отправляется в бан на 24 часа через Fail2ban и межсетевой экран UFW.

7. Настройка Cloudflare WAF и российских аналогов без потери поисковиков

Использование облачного WAF (Cloudflare, DDoS-Guard, Qrator или Cloud.ru) позволяет отсечь до 90% паразитного трафика на периметре глобальной CDN-сети. Однако при создании правил WAF критически важно правильно настроить исключения для легитимных поисковых систем.

Эталонное правило Cloudflare WAF Custom Rule (Защита без риска для SEO):

В панели Cloudflare перейдите в Security → WAF → Custom rules и создайте правило со следующим выражением (Expression):

(cf.client.bot and not cf.verified_bot) or
(http.user_agent contains "Bytespider") or
(http.user_agent contains "GPTBot") or
(http.user_agent contains "ClaudeBot") or
(http.user_agent contains "CCBot")

Выбор действия (Action): Выберите Managed Challenge (Интерактивная капча) или Block.

Почему это правило безопасно для SEO: Поле cf.verified_bot в Cloudflare автоматически сверяет IP-адреса и криптографические сигнатуры всех официальных поисковиков (Yandex, Google, Mail.ru, Bing). Настоящий YandexBot получит статус Verified Bot = true и беспрепятственно пройдет на сайт, а любой парсер с поддельным User-Agent будет мгновенно заблокирован капчей.

8. Как верифицировать подлинность YandexBot и Googlebot (rDNS и ASN)

Злоумышленники часто подделывают строку User-Agent, отправляя в заголовке Mozilla/5.0 (compatible; YandexBot/3.0; +http://yandex.com/bots). Чтобы проверить, действительно ли запрос пришел от Яндекса или Google, выполните двухэтапную проверку через обратный DNS (rDNS Lookup):

1. Проверка IP-адреса Яндекса через консоль:

# Шаг 1: Обратный DNS-запрос по подозрительному IP
host 5.255.253.150
# Вывод: 150.253.255.5.in-addr.arpa domain name pointer yandex-5-255-253-150.spider.yandex.com.

# Шаг 2: Прямой DNS-запрос по полученному доменному имени
host yandex-5-255-253-150.spider.yandex.com
# Вывод: yandex-5-255-253-150.spider.yandex.com has address 5.255.253.150

Если доменное имя оканчивается на .yandex.ru, .yandex.net или .yandex.com, а прямой DNS возвращает исходный IP — перед вами 100% подлинный робот Яндекса. Для Googlebot домен обязан оканчиваться строго на .googlebot.com или .google.com.

Для быстрой проверки диапазонов подсетей и номеров автономных систем (Yandex: AS13238, Google: AS15169) воспользуйтесь нашим Детектором хостинга и сетей SysKit.

9. Готовые эталонные конфигурации для Nginx и Fail2ban

Ниже собраны готовые шаблоны, которые можно сразу внедрить на сервер Ubuntu / Debian:

1. Готовый блок защиты сайта в Nginx (/etc/nginx/sites-available/site.conf):

server {
    listen 443 ssl http2;
    server_name example.com;

    # 1. Отсечение мусорных User-Agent (No Response)
    if ($is_bad_bot) {
        return 444;
    }

    # 2. Защита xmlrpc.php и wp-login от брутфорса
    location = /xmlrpc.php {
        deny all;
        access_log off;
        log_not_found off;
        return 403;
    }

    location = /wp-login.php {
        limit_req zone=search_limit burst=3 nodelay;
        include fastcgi_params;
        fastcgi_pass unix:/run/php/php8.3-fpm.sock;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    }

    # 3. Запрет скрытых файлов и служебных папок (.env, .git)
    location ~ /.(?!well-known).* {
        deny all;
        access_log off;
        log_not_found off;
        return 404;
    }

    # 4. Общее ограничение частоты запросов
    limit_req zone=general_limit burst=20 nodelay;

    location / {
        try_files $uri $uri/ /index.php?$args;
    }
}

10. Сводная матрица и чек-лист защиты сайта

11. Резюме и выводы

Защита сайта от паразитного трафика — это комплексная инженерная задача. Внедрение трехуровневой фильтрации (Cloudflare WAF → Nginx Map & Rate Limit → Fail2ban) позволяет снизить паразитную нагрузку на сервер на 85–95%, сократить среднее время отклика сайта (TTFB) до менее 100 мс и полностью исключить падения баз данных в периоды активного парсинга.