MonitoRSS: что это за RSS-бот, зачем он приходит на сайт и нужно ли его блокировать

MonitoRSS — сервис и open-source бот для Discord, который отслеживает RSS/Atom и другие поддерживаемые источники и автоматически публикует новые материалы в Discord-каналы.

Официальный сайт описывает его как инструмент автоматической доставки новостей из YouTube, Reddit, новостных сайтов и других feed-источников непосредственно в Discord. На текущем сайте указано более 100 тысяч сообществ, использовавших сервис, и около 90 тысяч зарегистрированных источников.

Поэтому автоматические HTTP-запросы MonitoRSS являются не обычными пользовательскими визитами, а сервисным трафиком для проверки источников и доставки новых публикаций подписчикам Discord.

MonitoRSS — это не обычный RSS-reader

В исходном описании MonitoRSS выглядел как сервис, где пользователь просто читает RSS в приложении или браузере.

Точнее описывать его как:

RSS / Atom source
↓
MonitoRSS
↓
обнаружение новой записи
↓
формирование сообщения
↓
Discord channel

MonitoRSS предназначен именно для автоматической доставки обновлений в Discord. Официальный сайт предлагает добавить бот на Discord-сервер, выбрать feeds и канал, после чего новые статьи доставляются автоматически.

Как работает MonitoRSS

Пользователь добавляет источник в MonitoRSS.

Например:

https://example.com/feed.xml

После этого сервис периодически проверяет источник.

Если появляется новая запись:

новая RSS entry
↓
MonitoRSS обнаруживает изменение
↓
извлекает данные feed
↓
формирует сообщение или embed
↓
публикует его в Discord

Проект поддерживает фильтрацию публикаций по title, description, author, tags и другим данным feed, а также пользовательские шаблоны сообщений.

Как часто MonitoRSS проверяет feed

Для публичного сервиса интервалы документированы достаточно хорошо.

На текущем официальном сайте:

Free
→ feed checked every 20 minutes

Paid
→ feed checked as often as every 2 minutes

Эти интервалы подтверждаются и основной страницей, и текущей тарифной страницей MonitoRSS.

Поэтому повторный запрос:

12:00 GET /feed.xml
12:20 GET /feed.xml
12:40 GET /feed.xml

может полностью соответствовать обычному бесплатному polling публичного MonitoRSS.

Но 20 минут нельзя использовать как жёсткую сигнатуру

MonitoRSS поддерживает разные тарифы, а также self-hosting. Поэтому фактическая периодичность конкретного источника может отличаться.

Нельзя строить правило:

20 минут → настоящий MonitoRSS
19 минут → fake

Интервал полезен только как один behavioural signal.

MonitoRSS можно развернуть самостоятельно

Это одно из самых важных отличий MonitoRSS от полностью централизованных RSS-сервисов.

Официальный сайт прямо указывает:

MonitoRSS open-source и может быть self-hosted. Пользователь может запустить собственный экземпляр и отслеживать столько feeds, сколько позволяет его инфраструктура.

Следовательно:

MonitoRSS Public
→ инфраструктура публичного сервиса

MonitoRSS Self-hosted A
→ VPS пользователя A

MonitoRSS Self-hosted B
→ сервер пользователя B

MonitoRSS Self-hosted C
→ корпоративная инфраструктура

Почему у MonitoRSS могут быть совершенно разные IP

Для self-hosted экземпляров это нормальное поведение.

Запросы могут приходить из:

• облачного VPS;
• AWS;
• Hetzner;
• DigitalOcean;
• OVH;
• домашней сети;
• корпоративного сервера;
• любой другой инфраструктуры владельца экземпляра.

То есть большой разброс ASN сам по себе не является признаком spoofing для MonitoRSS. Это естественное следствие официально поддерживаемого self-hosting.

Почему глобальный IP allowlist MonitoRSS не работает

Даже если определить IP публичного MonitoRSS, это не позволит подтвердить все экземпляры продукта.

Поэтому TrafficVeil лучше разделять:

Software identity: MonitoRSS
Hosting model: Public / Self-hosted
Network identity: Independent instance

Вместо:

MonitoRSS
→ fixed ASN
→ fixed IP range

Какой User-Agent использует MonitoRSS

В логах можно встречать токен:

monitorss

Однако его нельзя считать неизменным идентификатором приложения.

В официальном GitHub-репозитории проекта есть feature discussion, где прямо указано, что MonitoRSS уже позволяет изменить User-Agent для всех feeds через config; запрос обсуждает лишь возможность задавать разные UA для отдельных feeds.

Это означает, что self-hosted экземпляр способен отправлять, например:

User-Agent: MonitoRSS

или настроенную владельцем строку.

Что это означает для TrafficVeil

Matcher:

contains "monitorss"

полезен для обнаружения заявленного MonitoRSS.

Но отсутствие этого токена:

UA != monitorss

не доказывает отсутствие MonitoRSS.

И наоборот:

UA = monitorss

не доказывает, что запрос действительно создан приложением.

Какие URL обычно получает MonitoRSS

Основной профиль связан с RSS/Atom:

/feed/
/rss/
/rss.xml
/feed.xml
/atom.xml
/blog/feed/

Это самые естественные endpoint для RSS-monitoring.

Но MonitoRSS может обращаться и к обычным URL

Это важная поправка к универсальному RSS-шаблону.

На официальном сайте пользователь может вставить любой URL, после чего MonitoRSS пытается автоматически обнаружить feeds.

Кроме того, среди текущих возможностей указана функция Content Extraction: сервис может извлекать titles, images, authors и custom data из материала.

Поэтому:

MonitoRSS
→ GET /blog/

или запрос к конкретной статье не обязательно является аномалией.

Не классифицируйте любой HTML fetch как spoofing

Слишком простое правило:

MonitoRSS + RSS = legitimate
MonitoRSS + HTML = malicious

может давать ложные срабатывания.

Лучше учитывать:

• какой URL запрашивается;
• был ли обнаружен RSS;
• сколько HTML-страниц получает источник;
• есть ли связь с feed entries;
• как часто повторяются запросы.

Как найти MonitoRSS в access.log

Базовый поиск:

grep -i "monitorss" /var/log/nginx/access.log

Количество запросов:

grep -ic "monitorss" /var/log/nginx/access.log

Топ URL:

grep -i "monitorss" /var/log/nginx/access.log \
| awk '{print $7}' \
| sort \
| uniq -c \
| sort -rn \
| head -30

Топ IP:

grep -i "monitorss" /var/log/nginx/access.log \
| awk '{print $1}' \
| sort \
| uniq -c \
| sort -rn \
| head -30

HTTP-коды:

grep -i "monitorss" /var/log/nginx/access.log \
| awk '{print $9}' \
| sort \
| uniq -c \
| sort -rn

Как отдельно посмотреть классический RSS polling

grep -i "monitorss" /var/log/nginx/access.log \
| grep -iE '/feed|/rss|rss\.xml|feed\.xml|atom\.xml'

Если почти весь трафик сосредоточен на этих endpoint, профиль хорошо соответствует обычному feed-monitoring.

Как найти HTML-запросы

grep -i "monitorss" /var/log/nginx/access.log \
| grep -ivE '/feed|/rss|rss\.xml|feed\.xml|atom\.xml'

Так можно отдельно оценить запросы, связанные с feed autodiscovery, content extraction или другой функцией.

Проверьте HTTP-коды

Почему cache важнее простого количества hits

Для RSS-monitoring одинаковые URL запрашиваются регулярно.

Если TrafficVeil или CDN эффективно кэширует feed:

MonitoRSS
↓
GET /feed.xml
↓
edge cache HIT
↓
origin не используется

то даже большое число service requests может почти не создавать CPU-нагрузки.

Поэтому полезнее показывать:

• Requests;
• Cache HIT Ratio;
• Origin Requests;
• Average Response Size;
• Bandwidth;
• TTFB.

Пример

10 000 MonitoRSS requests
99% cache HIT
100 origin requests

могут быть дешевле:

500 requests
0% cache HIT
500 динамических feed renders

Как снизить нагрузку без блокировки

Для RSS/Atom endpoint полезно:

• включить edge caching;
• кэшировать XML;
• корректно отдавать ETag;
• использовать Last-Modified;
• поддерживать conditional requests;
• не выполнять тяжёлые SQL-запросы при каждом обращении;
• ограничивать feed разумным количеством последних записей.

Как выглядит нормальный MonitoRSS

Как выглядит подозрительный клиент под UA MonitoRSS

Например:

User-Agent: MonitoRSS

GET /.env
GET /.git/config
GET /wp-config.php.bak
GET /backup.sql
GET /vendor/phpunit/
GET /phpmyadmin/

Это уже не похоже на RSS-monitoring или content extraction.

TrafficVeil должен классифицировать источник как:

Suspicious automation
или
UA spoofing

независимо от названия.

Почему ASN не подтверждает MonitoRSS

Для централизованного crawler ASN оператора может быть сильным сигналом.

Для MonitoRSS это намного слабее.

Self-hosted экземпляры могут работать практически где угодно.

Поэтому:

MonitoRSS + неизвестный ASN

не означает:

fake MonitoRSS

Какие поля стоит хранить TrafficVeil

asn
asn_org
network_type
is_datacenter
is_proxy
is_vpn
is_tor

ua
source_ip
top_urls
polling_interval
feed_ratio
html_ratio
origin_impact

Для self-hosted RSS-reader поведенческий профиль зачастую важнее принадлежности сети.

Какой identity status использовать

Глобальный статус:

Verified MonitoRSS by IP

для всех экземпляров продукта технически не подходит из-за self-hosting.

Соблюдает ли MonitoRSS robots.txt

Отдельной современной официальной crawler-policy MonitoRSS, обещающей соблюдение robots.txt всеми публичными и self-hosted экземплярами, при проверке найти не удалось.

Кроме того, владельцы self-hosted установок контролируют собственную конфигурацию, включая User-Agent.

Поэтому для TrafficVeil лучше:

robots.txt compliance: Unverified / instance-dependent

robots.txt для MonitoRSS

Как декларативную политику можно использовать:

User-agent: MonitoRSS
Disallow: /

Но нельзя считать это гарантированным техническим запретом.

Если блокировка обязательна, используйте server-side policy.

Блокировка через Nginx

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

Такое правило остановит клиента, только если он действительно сообщает UA с токеном monitorss.

Поскольку self-hosted MonitoRSS позволяет менять User-Agent, универсальной блокировкой всех экземпляров это не является.

Apache

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

Нужно ли блокировать MonitoRSS

Автоматический Deny обычно не нужен.

MonitoRSS может быть реальным каналом распространения публикаций:

ваш сайт
↓
RSS
↓
MonitoRSS
↓
Discord community
↓
читатель
↓
переход на сайт

Официальный продукт создан именно для автоматической доставки новых материалов в Discord-сообщества.

Когда использовать Allow

Allow подходит, если:

• RSS является важным каналом распространения;
• публикации могут распространяться через Discord;
• нагрузка минимальна;
• источник ведёт себя как обычный feed-fetcher.

Когда использовать Monitor

Это оптимальный default, если:

• обнаружен MonitoRSS UA;
• трафика немного;
• источник получает только публичные страницы;
• нагрузка на origin мала;
• нет причин немедленно разрешать или запрещать.

Когда нужен Rate Limit

Rate Limit можно использовать, если конкретный экземпляр:

• опрашивает feed слишком часто;
• создаёт заметную нагрузку;
• постоянно получает тяжёлые HTML-страницы;
• вызывает большой bandwidth.

Из-за self-hosting ограничение лучше применять per source IP / instance, а не к глобальному классу MonitoRSS.

Почему глобальный Rate Limit может быть ошибкой

Представим:

100 разных MonitoRSS instances
×
1 запрос / 20 минут

Если TrafficVeil объединит их в один общий bucket:

all monitorss → 10 requests/min

нормальные независимые пользователи начнут мешать друг другу.

Поэтому лучше:

MonitoRSS
+
Source IP
+
Feed URL
→ rate policy

Когда Block оправдан

Block имеет смысл, если:

• RSS/Discord distribution сайту не нужна;
• конкретный экземпляр создаёт excessive polling;
• автоматический fetch запрещён политикой сайта;
• источник получает чувствительные или странные URL;
• UA используется для vulnerability scanning.

Что будет после блокировки

Если конкретный MonitoRSS больше не может получить feed, связанный Discord-канал может перестать получать новые записи из этого источника.

Это не является блокировкой Googlebot, YandexBot или Bingbot.

Но вы можете потерять часть распространения контента через Discord-сообщества, где ваш feed отслеживается через MonitoRSS.

MonitoRSS не нужно считать человеческим трафиком

Сам fetch является машинным событием.

Правильная аналитика:

MonitoRSS GET /feed.xml
→ Automated Traffic

человек в Discord нажал опубликованную ссылку
→ Human Traffic / Discord referral

Это две разные сущности.

Как учитывать MonitoRSS в TrafficVeil

Рекомендуемая структура:

Automated Traffic
→ RSS & Feed Fetchers
→ Discord Feed Bots
→ MonitoRSS

Запросы стоит:

• исключать из Human Traffic;
• не считать конверсиями;
• не считать автоматически malicious;
• учитывать отдельно в RSS/service analytics;
• показывать polling frequency;
• показывать Feed vs HTML Requests;
• показывать Origin Impact.

MonitoRSS и Inoreader — не одно и то же

MonitoRSS и FreshRSS

Оба продукта могут быть self-hosted, но решают немного разные задачи.

Рекомендуемая карточка TrafficVeil

Стратегия Allow / Cache / Rate Limit / Block

Что показывать пользователю TrafficVeil

Вместо:

«MonitoRSS — легитимный RSS-агрегатор. Проверяйте IP/ASN оператора.»

лучше:

MonitoRSS — RSS/Atom-бот для Discord. Он периодически проверяет feeds и публикует новые материалы в Discord-каналы. MonitoRSS поддерживает self-hosting, поэтому запросы могут приходить с множества несвязанных IP и ASN. При повышенной активности сначала проверьте cache и конкретный источник, а не блокируйте весь класс MonitoRSS.

Итог

MonitoRSS — легитимный Discord RSS-monitoring bot, но его нельзя описывать как обычный централизованный feed-reader. Проект работает как публичный сервис и одновременно доступен для self-hosting.

Публичный MonitoRSS сейчас проверяет feeds примерно каждые 20 минут на бесплатном плане и вплоть до каждых 2 минут на платных вариантах.

Кроме классического RSS/Atom polling, сервис умеет автоматически обнаруживать feeds по обычному URL и заявляет функции извлечения title, images, authors и других данных из материалов. Поэтому HTML-fetch не должен автоматически считаться spoofing.

Из-за self-hosted архитектуры нет смысла ожидать единый официальный IP/ASN для всех экземпляров, а User-Agent тоже может быть изменён в конфигурации.

Поэтому для TrafficVeil оптимальная классификация:

RSS & Feed Fetchers
→ Discord Feed Bots
→ MonitoRSS

Hosting: Public + Self-hosted
Identity: Observed / Behavioral
Default: Allow / Monitor

При высокой нагрузке лучший порядок действий — сначала проверить Cache HIT и Origin Impact, затем ограничить конкретный IP/instance. Глобальный Deny стоит применять только если распространение через MonitoRSS действительно не нужно.