Анализ логов самостоятельного сайта: как читать логи Nginx/Apache — краулеры, ошибки, трафик

От 70% до 85% запросов в серверных логах приходят от краулеров и скриптов, а реальные люди — обычно лишь 15–30%. Смотреть только на общее число визитов — значит обманывать себя. Правильный разбор идёт в три шага: сначала...

日志分析三件事:分清谁在爬、哪里在错、人在哪Reading server logs: who crawls, what errors, where the humans are 反直觉:日志里 70% 至 85% 的请求不是人,别把爬虫量当成流量增长Counter-intuitive: 70%-85% of log rows are bots, not human visits 维度Dimension 看什么What to look at 爬虫识别Bot traffic UA 字段 + IP 反查UA string + IP lookup 区分好爬与坏爬Good vs bad crawlers AI 爬虫单独统计Track AI bots separately 错误排查Errors 404 死链与 5xx 故障404s and 5xx outages 错误率阈值告警Error-rate alerting 5xx >1% 立即查5xx above 1% = act 真人流量Human traffic 去机器人后再算 PVStrip bots before PV 落地页与来源路径Landing pages and referrers 真人数常占 15% 至 30%Humans often 15%-30% 标准工具链:GoAccess 周报 + awk 按小时统计 + 每月一次全量审计Toolchain: GoAccess weekly + awk hourly + monthly full audit 日志至少保留 90 天,按月切割压缩;CDN 回源日志才是真实源站视角Keep 90+ days, rotate monthly; origin pull logs show real back-to-source traffic 动作优先级:5xx 错误 > 404 死链 > AI 爬虫读取情况 > 真人 PV 趋势Priority: 5xx > 404s > AI crawl reads > human PV trend 先读错误,再读爬虫,最后才看流量——顺序反了容易被数字误导Read errors first, then bots, then traffic; reverse order misleads
Три способа читать логи Nginx/Apache: распознать краулеров, найти ошибки и восстановить реальный трафик

Анализ логов самостоятельного сайта: как читать логи Nginx/Apache — краулеры, ошибки, трафик

Сначала вывод: От 70% до 85% запросов в серверных логах приходят от краулеров и скриптов, а реальные люди — обычно лишь 15–30%. Смотреть только на общее число визитов — значит обманывать себя. Правильный разбор идёт в три шага: сначала отсеять краулеров по User-Agent и IP, затем следить за долей ошибок 5xx (превысила 1% — сразу разбирайтесь) и битыми ссылками 404, и только потом по оставшимся запросам реальных людей считать PV, страницы входа и источники. Логи храните минимум 90 дней, раз в неделю делайте отчёт в GoAccess, раз в месяц — полный аудит.

Почему нельзя смотреть только на «общее число визитов»

Многие владельцы сайтов, открывая лог, первым делом смотрят, сколько запросов пришло за сегодня, и по этой цифре судят, как идут дела. Это первая ловушка: в стандартном access.log от Nginx одна запись — это один HTTP-запрос, а один реальный человек, открывая главную, может создать 8–15 запросов (HTML, CSS, JS и картинки считаются отдельно), тогда как вредоносный краулер за минуту делает тысячи. Общее число для решений почти бесполезно.

Вот контринтуитивный вывод:Ваши визиты «взлетели» — скорее всего, какой-то краулер начал яростно обходить ваш сайт, а не пришли клиенты. Критерий простой — сгруппируйте лог по User-Agent и посмотрите, кто входит в топ-20 источников запросов. Если больше половины — это UA из категории bot, всплеск не имеет никакого отношения к вашему бизнесу. Это совпадает с логикой анализе логов AI-краулеров: сначала разберитесь, «кто вас читает», и только потом — «сколько прочитал».

Поле лога (Nginx combined) Значение Для чего анализировать
$remote_addr IP источника Выявить IP дата-центров, вредоносное сканирование, принадлежность краулера
$request Метод запроса + путь + протокол Понять, какие URL реально посещали, какие файлы дёргали
$status HTTP-статус 200 — норма, 301 — редирект, 404 — битая ссылка, 5xx — сбой
$body_bytes_sent Число отданных байт Выявить пустые ответы и заблокированные подозрительные скачивания
$http_referer Страница-источник По какой ссылке пришёл реальный человек
$http_user_agent Идентификатор клиента Отличить браузер, поискового краулера и AI-краулера

Как читать: три типа сигналов — краулеры, ошибки, реальный трафик

Рекомендуемый порядок анализа всегда такой: «ошибки → краулеры → реальные люди», не наоборот. Причина в том, что ошибки напрямую бьют по опыту реальных людей и потому в приоритете; объём краулеров определяет ваш бюджет на обход и расходы на трафик; а реальный трафик — то, что стоит разбирать подробно в последнюю очередь. Именно поэтому в Мониторинг сайта и оповещения доступность и доля ошибок стоят на первом месте.

Не полагайтесь только на UA при распознавании краулеров: вредоносные боты подделывают UA и выдают себя за Googlebot. Стандартный подход — двусторонняя проверка: для IP, который называет себя Googlebot, делаем обратный DNS и убеждаемся, что он действительно из диапазона googlebot.com, затем делаем прямой DNS и сверяем. Поддельный краулер этот шаг не пройдёт.

Категория сигнала Здоровый диапазон Порог для вмешательства Действие
Доля ошибок 5xx Меньше 0,5% Больше 1% в течение 10 минут подряд Проверить PHP-FPM и логи бэкенда, немедленно
Доля 404 Меньше 3% Один URL даёт больше 100 ошибок 404 в день Поставить 301 или исправить внутренние ссылки
Доля подозрительных запросов краулеров 20–40% Больше 60% и не хватает пропускной способности Ограничить через robots или WAF
Количество сессий реальных пользователей Стабильно неделя к неделе Падение больше 20% две недели подряд Проверить индексацию и рекламу, а не сервер
Доля чтения AI-краулерами 5–15% — это норма Рост больше чем в 3 раза Проверить, не идёт ли массовый сбор данных для обучения

3. Как это делать: от одной команды до недельного отчёта

Команде из одного человека не нужна дорогая платформа для анализа логов. Минимальный набор инструментов — три вещи: GoAccess для наглядного недельного отчёта, awk для почасовой статистики и ручной полный аудит раз в месяц. Ниже два сценария, которые можно применять сразу.

Сценарий 1: найти URL с наибольшим числом ошибок за сегодня. В каталоге логов Nginx выполните: awk ‘$9 ~ /^5/ {print $7}’ access.log | sort | uniq -c | sort -rn | head -20. Команда извлекает пути всех запросов с 5xx, сортирует их по числу появлений, и первые 20 — это страницы, которые сегодня нужно чинить в первую очередь.

Сценарий 2: посмотреть, сколько раз за сегодня приходили Google и AI-краулеры. awk ‘BEGIN{IGNORECASE=1} /Googlebot|GPTBot|ClaudeBot|bingbot/ {print $http_user_agent}’ access.log | sort | uniq -c | sort -rn. Сгруппировав результат по UA, вы увидите соотношение обычного краулера Google для индексации и краулеров разных AI для чтения. Для сайтов на CDN нужно брать логи источника, а не логи edge — об этом в Глобальное ускорение CDN о разнице между источником и кэшем.

Сценарий 3: сделать для себя недельный отчёт. Запустите GoAccess и генерируйте HTML-отчёт раз в неделю. Смотрите на четыре группы цифр: сколько занимают 4xx и 5xx в распределении кодов статуса, десять самых запрашиваемых URL, кривую трафика по часам и долю краулеров в разбивке по UA. Смотрите этот отчёт каждое утро понедельника — это гораздо эффективнее, чем листать логи время от времени. Полезная привычка — записывать каждую найденную аномалию в небольшую таблицу: через три месяца, оглянувшись назад, вы увидите закономерности.

Частота Действие Результат Время
Ежедневно Беглый взгляд на панель ошибок 5xx Есть сбой или нет 2 минуты
Еженедельно GoAccess формирует отчёт за прошлую неделю Топ путей, топ краулеров, распределение кодов статуса 10 минут
Ежемесячно Полный аудит 404 и подозрительных UA Список битых ссылок, список IP для блокировки 1 час
Ежеквартально Пересмотреть политику хранения и ротации логов Убедиться, что диск не переполнится и история доступна 30 минут

4. Подводные камни: три самых частых заблуждения

Первая ловушка — считать, что код 200 всегда означает норму. Некоторые плагины атакуют вредоносные сканеры, и в ответ приходит 200 плюс поддельная страница: статус в порядке, а содержимое подменено. Такое надо выявлять по «аномально малому числу байт в ответе» или по «появлению в URL параметров, которых там быть не должно», а в серьёзных случаях действовать по После взлома сайта сценарию.

第二个坑是只看实时、不留历史。日志不按切割和保留策略管理,磁盘被打爆或者三个月后想查一次”三月那次故障到底什么时候开始的”,根本翻不到。建议按天切割、保留 90 天热数据、超期压缩归档。

Третья ловушка — принимать заходы краулеров за успехи в SEO. То, что Googlebot пришёл десять тысяч раз, не значит, что вы хорошо ранжируетесь, — это значит лишь, что он снова и снова обходит сайт. С SEO реально связано другое: «нормально ли обходятся важные страницы», и смотреть на это надо в связке с данными индексации, а не хвастаться объёмом краулинга в отрыве от всего. О связи производительности и обхода читайте в Core Web Vitals о влиянии на полноту обхода пауками.

Заблуждение Внешнее проявление Настоящая причина Как правильно проверять
Резкий рост трафика — это хорошо Число запросов выросло втрое Какой-то краулер начал активно обходить Смотреть долю реальных людей с дедупликацией по UA
Если везде 200, значит всё в порядке Все коды состояния в норме Взломщики вернули поддельную страницу Проверить выборку аномально малых ответов и подозрительных параметров
Много обходов Google = хорошие позиции Высокое число запросов от Googlebot Он снова и снова обходит низкокачественные страницы Сопоставить объём индексации с реальными позициями
404 можно игнорировать Доля выглядит невысокой Старые внешние ссылки теряют вес Для TOP 404 поставить 301 на соответствующую новую страницу

FAQ: частые вопросы

Чем отличаются форматы логов Nginx и Apache, универсальны ли методы анализа?
В основном универсальны. Оба по умолчанию поддерживают формат combined: IP, время, строка запроса, код состояния, число байт, страница-источник и User-Agent — эти семь колонок совпадают. В Nginx код состояния берётся из $status, в Apache ему соответствует %s; расположение полей разное, поэтому при выборке колонок через awk учитывайте сдвиг на единицу. Логика анализа полностью одинаковая: сначала разбить по кодам состояния, затем по UA, в конце агрегировать по путям. Советую на обеих машинах привести логи к одному формату combined — тогда скрипты можно будет переиспользовать.
Как отличить настоящий Googlebot от поддельного краулера?
Делайте двустороннюю DNS-проверку. Сначала выполните обратное разрешение IP, который называет себя Googlebot, и посмотрите, заканчивается ли имя хоста на googlebot.com или google.com; затем выполните прямое разрешение этого имени хоста и проверьте, совпадает ли полученный IP с исходным. Только если оба шага сходятся, это настоящий краулер Google; поддельный обычно умеет менять лишь строку UA и не проходит проверку по принадлежности IP. С ИИ-краулерами то же самое: смотрите официально опубликованные диапазоны IP.
Сколько хранить логи, чтобы этого хватало?
Горячие данные храним 90 дней, по истечении срока ежемесячно сжимаем и архивируем на диск или в объектное хранилище, общий архив — минимум год. Причин три: при разборе сбоев часто нужно вернуться к их началу несколько недель назад; проблемы с индексацией в SEO обычно требуют сверки со сканированием месяц-два назад; при инцидентах безопасности нужно видеть записи о доступе за полгода. При разбивке по дням и сжатии gzip год логов обычно занимает всего несколько ГБ.
Нужно ли обрабатывать все ошибки 404?
Не разбрасывайтесь усилиями — сортируйте по числу обращений. Если один URL даёт больше 100 ошибок 404 в день, значит, есть реальные внешние ссылки или пользователи кликают, обязательно ставьте 301 на ближайшую по смыслу новую страницу; длинный хвост с парой 404 в день пока оставьте, чистите раз в месяц. Менять все 404 по всему сайту на 301 в главную — ошибка, это размывает вес.
Точны ли логи сервера после подключения CDN?
Нет, они сильно занижены и искажены. Запросы, попавшие в кэш CDN, вообще не доходят до источника, в логах источника видно только обратные запросы, а большая часть запросов реальных пользователей остаётся на граничных узлах CDN. Правильно смотреть оба лога: в консоли CDN выгружайте логи граничных запросов для полной картины посещений, в логах источника смотрите обратные запросы и ошибки бэкенда. Для анализа краулеров и живого трафика берите логи CDN, для разбора 5xx и сбоев PHP — логи источника.
Вижу в логах GPTBot и ClaudeBot — это хорошо или плохо?
Зависит от вашей цели. Если вы хотите, чтобы контент цитировали большие модели, это нормальное и даже желательное чтение, рост объёма чтения часто идёт синхронно с ростом цитирования в AI; если не хотите, чтобы его брали на обучение, закройте соответствующих краулеров через disallow в robots. Критерий не в том, много ли они собирают, а в том, нормально ли читаются важные страницы и не стала ли частота чтения аномальной настолько, что бьёт по каналу. Советую отдельно считать эти UA и смотреть их отдельно от поисковых краулеров.

В заключение

Ценность анализа логов не в том, чтобы «смотреть трафик», а в том, чтобы «разбирать ошибки и различать, кто пришёл». Для независимого сайта, которым занимается один человек, достаточно раз в неделю потратить десять минут на отчёт и раз в месяц — час на полный аудит, чтобы закрыть 90% типичных проблем: где ошибки, где битые ссылки, какие краулеры съедают ваш канал, откуда на самом деле приходят живые люди.

Три шага на практике: первый — привести формат логов к combined и хранить их по дням 90 дней; второй — сначала следить за долей ошибок 5xx и подавать сигнал при превышении 1%, затем заняться TOP 404; третий — считать краулеров и живых людей отдельно и не обманывать себя общим числом посещений. С ритмом обслуживания сайта можно сверяться по графиком обслуживания сайта— там список из шести дел на каждый месяц.

Фраза, которую стоит запомнить: логи сервера — это не панель трафика, а запись с места аварии: сначала найдите, куда врезалась машина, а потом считайте, сколько их проехало по дороге.

crater
crater Эксперт Crater

Официальный аккаунт организации · crater Crater

环形山 (Crater) — компания, которая помогает выходить на зарубежные рынки: разработка сайтов на WordPress, Google SEO и комплексный рост в GEO. Мы работаем с умными устройствами, промышленным оборудованием, SaaS и новой энергетикой.

Возможности продуктаБелая книга по методологииОтраслевые отчёты
965篇分享
78статей в базе знаний