MagpieRSS в логах: библиотека, а не единый сервис

Токен magpierss в access.log обманчиво выглядит как визит одного конкретного сервиса — но на самом деле за ним может стоять сколько угодно разных, никак не связанных друг с другом читалок RSS. MagpieRSS — это не компания и не единая инфраструктура, а открытая PHP-библиотека для разбора RSS- и Atom-лент, которую с 2002 года встраивали в собственный код тысячи разработчиков. В каталоге TrafficVeil бот отмечен как легитимный в категории «RSS и фиды».

Что такое MagpieRSS на самом деле

MagpieRSS — открытый PHP-парсер RSS и Atom-лент, впервые выпущенный в 2002 году под лицензией GPL. Библиотеку скачивали и встраивали в свой код сотни тысяч раз — в какой-то момент похожий на неё код использовался даже внутри самого WordPress для чтения внешних фидов. Поскольку это просто код, который любой разработчик может вставить в свой сайт, скрипт или агрегатор, у токена magpierss нет единого «оператора» в привычном смысле — за одной и той же строкой UA могут скрываться десятки не связанных друг с другом читалок.

Важная деталь: проект давно не развивается активно, а значит, визит с этим UA сегодня обычно означает, что кто-то читает вашу RSS-ленту довольно старым, местами архивным кодом — не обязательно вредоносным, но и не тем, за которым стоит современная инфраструктура с публичной документацией или списком IP.

Зачем MagpieRSS приходит на сайт

Функция простая: код на основе MagpieRSS периодически опрашивает URL вашей ленты и забирает новые записи, чтобы показать их подписчикам того сайта или приложения, где эта библиотека встроена. Трафик в норме пропорционален числу таких подписчиков — чем популярнее лента, тем чаще её могут опрашивать разные независимые агрегаторы. Зоны, которые бот затрагивает: /feed/, /rss/, /atom.xml, /blog/feed — то есть исключительно файлы самой ленты, а не сайт в целом.

Типичный кейс: маркетинг видит всплеск хитов в Метрике или GA, но реальных сессий за ними нет. Причина — MagpieRSS. Правильная реакция здесь не «выключать сайт», а точечно ограничить именно опрос ленты, если он избыточен, не трогая остальной трафик.

Нагрузка и риски именно для MagpieRSS

Отдельной строки в публичной сводке топ-ботов TrafficVeil у magpierss может не быть, но для категории «RSS и фиды» в целом характерен предсказуемый фон: лишние опросы feed URL, которые редко критичны по нагрузке сами по себе — лента обычно значительно легче полной страницы сайта. Тем не менее стоит смотреть на:

• частоту опроса — старый код без поддержки условного GET (Last-Modified/ETag) может перекачивать всю ленту заново при каждом визите, даже если контент не менялся;
• повторы запросов с разных, явно не связанных друг с другом IP — это нормально для библиотеки без единого оператора, а не признак атаки;
• отсутствие cookie и признаков сессии, типичное для любого автоматизированного fetcher-а.

Как найти MagpieRSS в логах

Ищите конкретный токен magpierss, а не общее слово «bot» — и не удивляйтесь, если запросы идут с большого числа несвязанных IP: это ожидаемо для библиотеки без единого оператора.

# Базовый поиск
grep -i "magpierss" /var/log/nginx/access.log

# Топ URL, которые вычитывает бот
grep -i "magpierss" /var/log/nginx/access.log | awk '{print $7}' | sort | uniq -c | sort -rn | head

# Топ IP за этим UA
grep -i "magpierss" /var/log/nginx/access.log | awk '{print $1}' | sort | uniq -c | sort -rn | head

# Суточная активность
grep -i "magpierss" /var/log/nginx/access.log | awk '{print $4}' | cut -d: -f1 | sort | uniq -c

Верификация здесь особенная: раз официального оператора и списка IP нет в принципе, связка UA + ASN малоинформативна — вместо неё смотрите, действительно ли запросы концентрируются на файлах ленты, а не расползаются по всему сайту. Это куда более надёжный признак подлинности, чем попытка сверить IP с несуществующим реестром.

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

robots.txt для MagpieRSS

# Жёсткий запрет
User-agent: magpierss
Disallow: /

# Разрешить всё
User-agent: magpierss
Allow: /

# Компромисс: закрыть деньги/кабинет, оставить публичную часть
User-agent: magpierss
Disallow: /admin/
Disallow: /cart/
Disallow: /checkout/
Disallow: /account/
Disallow: /api/
Allow: /

Важная оговорка: поскольку за токеном стоит множество независимых, часто устаревших скриптов, соблюдение robots.txt будет зависеть от конкретной реализации каждого из них — единой гарантии здесь нет и быть не может.

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

Nginx

if ($http_user_agent ~* "magpierss") {
    return 403;
}

limit_req_zone $binary_remote_addr zone=magpierss:10m rate=10r/m;
location / {
    if ($http_user_agent ~* "magpierss") {
        limit_req zone=magpierss burst=20 nodelay;
    }
}

Apache (.htaccess)

RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} magpierss [NC]
RewriteRule ^ - [F,L]

TrafficVeil

• найдите magpierss / MagpieRSS в ботах домена или в /system/bots;
• для нежелательного сценария — категория «запретить»; для мягкого — rate-limit;
• allow оставляйте, если распространение через RSS-читалки и агрегаторы важно для охвата аудитории;
• после изменения сверьте логи: хиты MagpieRSS должны уйти в блок/лимит, а нужные поисковики остаться нетронутыми.

С кем не путать MagpieRSS

Стратегия allow/deny для MagpieRSS

Главное, что стоит помнить про MagpieRSS: это не сервис, который можно «доверять» или «не доверять» как единому оператору — это старый код, встроенный в неизвестное число независимых сайтов. Решение allow/deny здесь разумнее принимать по тому, важно ли вам распространение через RSS в принципе, а не по попытке опознать конкретного владельца бота.