Agent в логах: почему это не бот, а слово

Если фильтровать access.log по agent, часто всплывает целый пласт машинных хитов — но здесь важнее всего не «кто это», а технический факт, который меняет весь подход: токен agent — это не различающее имя бота, а слово, которое буквально входит в название HTTP-заголовка User-Agent и встречается в подавляющем большинстве реальных строк UA (браузеров, ботов, приложений). Прежде чем применять любую политику allow/deny по этому токену, нужно понимать, что стандартный поиск и правило robots.txt для него работают не так, как для остальных ботов в этой энциклопедии.

1. Что такое Agent — и почему это не обычный бот-токен

«Agent» — не уникальный идентификатор конкретного оператора, а фрагмент, который естественным образом присутствует в огромном количестве строк User-Agent: в самом названии заголовка, в словах вроде «user agent», «HTTP agent», в названиях множества легитимных и вредоносных ботов (например, уже в соседнем списке «не путать» есть AgentReadinessScanner — и обычный grep -i "agent" совпадёт и с ним тоже). Это делает токен принципиально непригодным для точечной фильтрации: правило по нему либо ничего не поймает избирательно, либо, наоборот, случайно затронет огромный и разнородный пласт трафика, включая часть легитимных пользователей и ботов, к которым политика вообще не должна была применяться.

2. Зачем «Agent» встречается в access.log

Правильный вопрос — не «зачем бот Agent приходит на сайт», а «что именно совпало с этой подстрокой». Кандидаты: часть строки настоящего браузера или мобильного приложения (многие корректно оформленные UA содержат слово user agent целиком или частично в комментариях), реальные боты с более длинным именем, включающим «agent» (AgentReadinessScanner и подобные), скрипты на базе HTTP-библиотек с UA по умолчанию вроде «Java/1.8 (agent)» или похожих, и, наконец, действительно узкоспециализированные клиенты, которые по какой-то причине идентифицируют себя буквально одним этим словом — что само по себе большая редкость и повод для отдельной проверки, а не типовой случай.

• Какие зоны чаще трогает: зависит от того, что именно совпало — обобщать по одному токену бессмысленно;
• Что ищет: неопределимо без разбора полной строки UA каждого конкретного хита;
• Чем отличается от браузерного пользователя: не всегда отличается вообще — часть совпадений может быть обычными пользователями с нестандартным, но легитимным UA.

Приведённая в исходных данных динамика (0 в марте, 34 в апреле, 122 в мае, 0 в июне) сама по себе подсказывает, что это не стабильно работающий сервис с постоянным паттерном, а, вероятнее всего, разовый всплеск от одного конкретного источника в мае — возможно, вообще не связанного с остальными редкими совпадениями в другие месяцы.

3. Нагрузка и риски именно для «Agent»

156 срабатываний за четыре месяца (#145 по объёму в сводке) — само по себе немного, и это ожидаемо для токена, который скорее собирает редкие случайные совпадения, чем отражает активность одного постоянного источника. Главный риск здесь не нагрузка, а неправильное управленческое решение: если применить широкое правило по слову agent, велик шанс случайно задеть легитимный трафик, который к маю никак не относится и с майским всплеском не связан.

4. Как на самом деле искать это в логах

Не применяйте здесь тот же шаблон grep, что и для остальных ботов в этой энциклопедии — общий поиск по подстроке agent даст практически бесполезную по объёму и разнородную выдачу. Правильный подход — сузить именно до майского всплеска и посмотреть полные строки UA целиком.

# НЕ используйте одиночный grep -i "agent" — он совпадёт с огромным числом посторонних строк.
# Вместо этого выгрузите полные UA-строки и оцените, что реально совпадает:
awk -F'"' '{print $6}' /var/log/nginx/access.log | grep -i "agent" | sort | uniq -c | sort -rn | head -50

# Сфокусируйтесь на майском окне, где зафиксирован основной всплеск (~122 хита)
awk -v start="01/May/2026" -v end="31/May/2026" '$4 >= "["start && $4 <= "["end"]"' /var/log/nginx/access.log | grep -i "agent" | awk -F'"' '{print $6}' | sort | uniq -c | sort -rn

# После того как выделите конкретную полную строку UA — ищите уже по ней, не по голому слову agent
grep -F "ТОЧНАЯ_СТРОКА_UA_ИЗ_ПРЕДЫДУЩЕГО_ШАГА" /var/log/nginx/access.log

Верификация. Для этого токена верификация — не про IP или ASN, а про то, чтобы вообще выяснить, с какой конкретно полной строкой UA вы имеете дело. Только после того как вы вычленили точную, длинную, специфическую строку (а не голое слово agent), к ней уже можно применять обычные методы: whois по IP, обратный DNS, сопоставление с известными семействами ботов.

IP="1.2.3.4"
whois -h whois.cymru.com " -v $IP"
dig +short -x "$IP"

5. robots.txt для «Agent» — почему стандартное правило не работает

# Такое правило технически валидно, но практически бессмысленно:
# ни один настоящий бот не называет себя в robots.txt ровно "agent"
User-agent: agent
Disallow: /

Важно: не тратьте время на универсальное правило по этому токену. Вместо этого сначала выясните через полную строку UA (см. раздел 4), с чем вы реально имеете дело, и уже тогда пишите точное правило под конкретное, длинное имя реального бота или клиента.

6. Блокировка вручную и через TrafficVeil

Nginx

# Регулярное выражение по одному слову "agent" крайне рискованно —
# оно способно случайно заблокировать легитимных пользователей и полезные боты.
# Сузьте правило до конкретной, найденной в разделе 4 полной строки UA:
if ($http_user_agent ~* "ТОЧНАЯ_СТРОКА_UA") {
    return 403;
}

TrafficVeil

• Не создавайте в TrafficVeil правило по голому токену agent — сначала откройте карточку конкретных хитов за май 2026 года и посмотрите полные UA;
• Заведите правило под ту конкретную строку, которая реально стоит за всплеском, а не под общее слово;
• После изменения обязательно сверьте, что легитимные посетители и известные боты (включая соседей вроде AgentReadinessScanner) не попали под блокировку случайно.

7. Рекомендации: что делать с «Agent»

• Не применяйте политику allow/deny к голому слову agent — это не идентификатор конкретного оператора;
• Сначала расследуйте майский всплеск (~122 хита) через полные строки UA — вероятно, за ним стоит один конкретный, куда более длинный и специфический UA;
• Заведите отдельную, точную запись под найденный реальный токен, если он окажется отдельным ботом, достойным собственной статьи;
• Категорически не используйте User-agent: * с широкими намерениями «заблокировать всё похожее на agent» — так можно случайно закрыть доступ Googlebot, YandexBot и любому боту, чьё полное имя содержит это слово;
• Что будет при неверном широком блоке: непредсказуемая потеря легитимного трафika, включая часть настоящих пользователей и полезных ботов.

8. С кем не путать «Agent»

9. Стратегия allow/deny для «Agent»