Короткий ответ
Access-лог помогает увидеть, кто и как обращается к сайту: какие URL повторяются, как часто идут запросы, сколько ресурсов они расходуют и чем заканчиваются. Чтобы найти вредных ботов, анализируйте серию событий и последствия для origin, а не блокируйте посетителя только по IP или User-Agent.
Когда сайт замедляется, растёт нагрузка на базу данных или в каталоге появляются подозрительные обращения, первым делом хочется найти «виноватый IP». Такой поиск редко даёт надёжный ответ: один адрес может представлять офисную сеть, мобильного оператора или прокси, а автоматизация часто распределена между множеством адресов. Практичнее начать с access log — журнала HTTP-запросов веб-сервера или прокси — и восстановить последовательность событий.
В этой инструкции разберём, как анализировать логи сайта и находить признаки парсинга, перебора форм и чрезмерной нагрузки, не путая их с обычными посетителями и поисковыми системами. Для общей методики классификации автоматического трафика смотрите также материал как отличить полезного бота от вредного.
Какие поля access-лога нужны для анализа
Состав полей задаётся конфигурацией Nginx, Apache, CDN или reverse proxy. Для первого прохода достаточно времени запроса, адреса клиента, метода, URI, статуса ответа, объёма ответа, времени обработки и User-Agent. Если прокси стоит перед приложением, выясните, какой адрес записывается: реальный клиентский адрес должен извлекаться только из доверенной цепочки прокси.
| Поле | Что показывает | Ограничение интерпретации |
|---|---|---|
| Время и интервал | Частоту и серии запросов | Пики могут совпасть с рассылкой или кампанией |
| Метод, URI и параметры | Маршруты, обход каталога, повторяемые запросы | Параметры иногда содержат персональные данные: маскируйте их |
| Статус и размер ответа | Ошибки, отказы и объём отдаваемого контента | Ответ 200 не означает, что визит полезен или человеческий |
| Длительность обработки | Маршруты с высокой стоимостью для origin | Нужна проверка методики измерения на вашем стеке |
| IP и User-Agent | Сетевой и клиентский контекст | Заголовок подделывается, а адрес может быть общим |
Пошаговый разбор подозрительного трафика
1. Зафиксируйте период и исходную нагрузку
Возьмите интервал, в котором проблема заметна, и сопоставимый спокойный период. Запишите обращения в секунду, задержки ответа, загрузку CPU и базы данных, долю ошибок и состояние заказов или заявок. Это позволит проверить, совпадает ли активность в журнале с реальным эффектом, а не просто с большим числом строк.
2. Сгруппируйте запросы по маршруту и контексту
Отдельно изучите карточки товаров, поиск, фильтры, страницы входа, формы и API. Высокая частота на тяжёлом поиске обычно важнее такого же количества дешёвых запросов к статическому файлу. Проверьте повторяющиеся параметры, последовательный обход страниц, одинаковые интервалы и рост времени обработки.
3. Сопоставьте журнал с аналитикой и бизнес-результатом
Access log описывает HTTP-запросы, но не объясняет намерение. Сверьте время и маршруты с веб-аналитикой, CRM, заявками, заказами и мониторингом инфраструктуры. Боты могут не выполнять JavaScript, а аналитика может не видеть часть запросов; поэтому расхождение источников — повод исследовать, а не автоматическое доказательство атаки.
| Наблюдение | Что проверить | Первый шаг |
|---|---|---|
| Много параметризованных страниц | Повторяемость фильтров и стоимость запросов | Проверить кеширование и отдельный лимит маршрута |
| Повторные отправки формы | CRM, валидацию и время между отправками | Сохранить заявки и добавить серверные сигналы |
| Последовательный обход каталога | Шаблон URL, интервал и объём выгрузки | Наблюдать и оценить риск для origin |
| Частые ответы 4xx/5xx | Ошибки приложения и сканирование неизвестных путей | Разделить ошибки посетителей и серверную деградацию |
| Заявленный поисковый робот | Официальную проверку робота и коды ответа | Не блокировать по одному User-Agent |
4. Проверьте поисковых роботов до изменения правил
Перед ограничением трафика убедитесь, что Googlebot и Яндекс.Бот сохраняют доступ к индексируемым страницам. Сверьте robots.txt, sitemap, ответы сервера и подтверждение подлинности робота. Подробные проверки собраны в руководстве как проверить Googlebot и Яндекс.Бота и не закрыть индексацию. Не считайте строку User-Agent доказательством личности: её легко скопировать.
5. Вводите защиту постепенно и измеряйте результат
Сначала сохраните исходную конфигурацию и включите наблюдение. Затем протестируйте узкое правило на дорогом маршруте: например, ограничьте частоту повторяющихся запросов поиска, не меняя доступ ко всему сайту. Проверьте загрузку origin, долю ответов 429/403, конверсию, ошибки оплаты и обращения поддержки; заранее определите условие отката.
Если проблема проявляется в заявках, пригодится отдельная инструкция по спаму в Contact Form 7; для магазина — разбору фальшивых заказов WooCommerce. Более широкий план внедрения описан в статье о защите интернет-магазина от ботов.
Частые ошибки при чтении access-логов
- Блокировать только по User-Agent. Заголовок подделывается, а один и тот же клиентский сценарий может иметь разные строки.
- Считать каждый IP отдельным пользователем. NAT, мобильные сети и прокси объединяют посетителей; распределённая автоматизация, наоборот, использует много адресов.
- Судить только по числу строк. Сотня дорогих запросов к поиску может быть заметнее тысяч кешированных статических файлов.
- Забывать о приватности. Не публикуйте сырые журналы и удаляйте токены, идентификаторы и персональные параметры перед передачей на анализ.
- Не проверять откат. Любое правило нужно сопроводить мониторингом ошибок, контрольным сценарием пользователя и понятным способом отмены.
Чек-лист диагностики
- Сохраните копию журнала и укажите часовой пояс и период.
- Проверьте формат полей, доверенные прокси и маскирование чувствительных данных.
- Сгруппируйте запросы по маршрутам, частоте, статусам и времени обработки.
- Сверьте подозрительные серии с аналитикой, CRM и мониторингом сервера.
- Отдельно проверьте поисковых роботов, robots.txt и sitemap.
- Начните с узкого правила, измерьте эффект и подтвердите безопасный откат.
Для первичного разбора строки User-Agent можно использовать анализатор User-Agent. Если нагрузка затрагивает всю инфраструктуру или трафик смешанный, сначала изучите методику проверки бот-трафика без потери клиентов, а затем выбирайте действие по подтверждённым сигналам.
Главный вывод
Access-лог — источник наблюдений, а не готовый классификатор ботов. Надёжное решение соединяет последовательность запросов, стоимость для сайта, проверку полезных роботов и бизнес-результат; после изменения правил нужно контролировать и защиту, и доступность для клиентов.