wget — утилита GNU wget для скачивания файлов по HTTP(S). В логах это автоматизация, не поисковый бот. Оператора «wget Inc.» не существует — это открытый инструмент командной строки, которым пользуется кто угодно: от разработчиков и системных администраторов до скраперов.
Параметры
| Параметр | Значение |
|---|---|
| UA | Wget/1.x / wget/1.x |
| Оператор | Не фиксирован (клиент — open-source утилита, а не сервис одной компании) |
| robots.txt | Смотрите отдельный раздел ниже — распространённое «обычно игнорируется» неточно |
| IP | ❌ Нет «официального» списка — это локальный инструмент, запускаемый где угодно |
На самом деле про robots.txt: не так однозначно, как кажется
Официальное руководство GNU Wget прямо говорит: утилита соблюдает Robots Exclusion Standard (RES) **при рекурсивном скачивании** (флаг -r) — то есть именно тогда, когда wget ведёт себя как настоящий краулер, обходя сайт по ссылкам. Перед этим wget сам запрашивает robots.txt и учитывает его директивы по умолчанию. Для одиночной загрузки конкретного файла (самый частый сценарий: просто wget https://example.com/file.pdf без -r) robots.txt вообще не запрашивается — это не обход в смысле стандарта, а разовый fetch одного URL, к которому правило неприменимо по определению. Игнорирование robots.txt при рекурсивном обходе — не поведение по умолчанию, а осознанный выбор оператора, который явно передал флаг -e robots=off (или прописал robots = off в своём .wgetrc). Так что если в логах видна плотная рекурсивная выкачка сайта с явным нарушением директив — это, скорее всего, намеренное действие, а не «баг» или дефолтное поведение инструмента.
Зачем wget оказывается в логах
За этим UA может стоять что угодно — от легитимного мониторинга и внутренних интеграций до простого скрипта разработчика, тестирующего доступность страницы, до чужого скрапера, который просто не потрудился подделать UA под браузер. В отличие от многих ботов с одним конкретным назначением, wget — это универсальный инструмент без единого «типичного» сценария использования.
Подключите домен и посмотрите живую ленту: кто пришёл, с какой сети, что запрашивал и по какому правилу был пропущен или заблокирован.
Нагрузка
По сводке TrafficVeil — порядка 35 тысяч запросов. Смотрите, свои ли это IP — при таком общем, generic-инструменте важнее понять, кто именно его запускает, чем сам факт присутствия в логах.
Контроль
grep -i "wget" /var/log/nginx/access.logif ($http_user_agent ~* "wget") {
return 403;
}Рекомендации
- Свои скрипты используют wget для мониторинга или интеграций — allowlist по IP, а не по UA (строку легко подделать в обе стороны)
- Чужой wget без понятной цели — deny или rate-limit
- Не путать с Googlebot и другими именованными поисковыми ботами — это универсальный инструмент, а не сервис одной компании
- Если решаете судить бота по «нарушению» robots.txt — помните, что для нерекурсивных запросов файл вообще не запрашивается по умолчанию, так что само по себе отсутствие обращения к robots.txt в логах — не доказательство злого умысла
Частые вопросы
Правда ли, что wget по умолчанию игнорирует robots.txt?
Почему тогда в логах кажется, что wget обходит правила?
Как оператор осознанно отключает соблюдение robots.txt?
Есть ли официальный список IP для верификации трафика wget?
Как лучше всего разрешить доступ своим легитимным скриптам на wget?
Означает ли отсутствие запроса к robots.txt в логах злой умысел?
Команда TrafficVeil разрабатывает инструменты защиты сайтов от ботов, DDoS и веб-атак. Разборы ботов пишем по логам подключённых доменов и открытым данным операторов.