Inoreader: что это за бот, зачем он опрашивает RSS и нужно ли его блокировать

Inoreader — облачный RSS-ридер и сервис агрегации контента компании Innologica Ltd. Он позволяет пользователям подписываться на сайты, блоги, подкасты, newsletters и другие источники, а затем получать их обновления в единой ленте.

Чтобы новые публикации появлялись у подписчиков, серверы Inoreader автоматически получают RSS/Atom feeds. Поэтому в access.log такие запросы выглядят как машинный трафик и не должны считаться обычными пользовательскими визитами.

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

Inoreader получает источники на своих серверах и показывает найденные обновления подписчикам.

Типичный процесс выглядит так:

Сайт
↓
RSS / Atom feed
↓
Inoreader fetcher
↓
обнаружение новой публикации
↓
лента подписчиков Inoreader

Именно поэтому автоматические запросы чаще всего приходятся на:

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

Но конкретный URL зависит от того, какой feed был добавлен пользователями сервиса.

Inoreader не делает отдельный запрос для каждого читателя

Это важное исправление исходного описания.

Нельзя считать, что:

100 подписчиков
=
100 отдельных запросов к feed

Inoreader централизованно получает источник на своей стороне.

Официальное описание функции Boost показывает эту модель особенно хорошо: если один пользователь уже ускорил обновление feed, остальные подписчики также получают преимущество от более частого обновления — повторно «ускорять» источник им не требуется.

Следовательно, количество HTTP-запросов определяется прежде всего политикой polling Inoreader, а не линейно количеством подписчиков.

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

Inoreader самостоятельно рассчитывает update interval для разных feeds. Компания объясняет, что старается балансировать скорость появления новых публикаций, стабильность своей инфраструктуры и отсутствие лишних polling requests к издателям.

Для некоторых подписок пользователь может включить Boost.

Официально Inoreader указывал:

Boosted feed → примерно 10-минутный polling interval

При этом feeds с realtime-доставкой через соответствующий push-механизм не нуждаются в таком polling.

Почему Inoreader может регулярно появляться в access.log

Повторяемость является нормальным свойством RSS-fetcher.

Например:

12:00 GET /feed/
12:10 GET /feed/
12:20 GET /feed/
12:30 GET /feed/

сама по себе не означает DDoS или scraping.

Это может быть обычный polling популярного или boosted feed.

Как выглядит User-Agent Inoreader

В независимых каталогах наблюдаются варианты:

Inoreader/1.0 ( http://www.inoreader.com/feed-fetcher; 51 subscribers; )

или:

Mozilla/5.0 (compatible; inoreader.com; 2 subscribers)

Также встречаются варианты с другим числом subscribers.

Для TrafficVeil поэтому разумно распознавать несколько устойчивых сигналов:

Inoreader/1.0
inoreader.com
/feed-fetcher

При этом слишком широкое совпадение только по слову inoreader следует дополнительно проверять по контексту.

Что означает subscribers в User-Agent

Некоторые наблюдаемые строки Inoreader содержат количество subscribers.

Например:

Inoreader/1.0 (...; 51 subscribers;)

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

Причины:

• один пользователь может быть неактивным;
• подписка не означает переход на сайт;
• Inoreader централизует polling;
• формат UA может меняться;
• не все наблюдаемые UA обязаны содержать subscriber count.

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

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

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

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

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

Топ URL:

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

Топ IP:

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

HTTP-коды:

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

Как отдельно найти RSS/Atom-запросы

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

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

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

Для RSS-сервисов особенно информативны:

Почему 304 особенно полезен для RSS

Если сервер поддерживает conditional requests, Inoreader и другие feed-reader могут проверять обновления без повторной передачи полного документа.

Для этого полезны:

ETag
Last-Modified
If-None-Match
If-Modified-Since

Если feed не изменился, сервер может вернуть:

304 Not Modified

без полной передачи XML.

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

Для RSS-fetcher оптимизация часто лучше полного запрета.

Стоит:

• кэшировать RSS/Atom;
• использовать ETag;
• корректно выставлять Last-Modified;
• поддерживать conditional GET;
• отдавать feed через CDN;
• не генерировать XML тяжёлым SQL-запросом при каждом polling;
• считать Cache HIT Ratio.

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

Например:

10 000 Inoreader requests
99% cache HIT
100 origin requests

могут практически не влиять на приложение.

А:

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

могут оказаться существенно дороже.

Поэтому TrafficVeil должен показывать не только Requests, но и:

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

Как выглядит нормальное поведение Inoreader

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

Сам User-Agent легко подделать.

Например:

User-Agent: Inoreader/1.0

GET /.env
GET /.git/config
GET /wp-login.php
GET /backup.zip
GET /phpmyadmin/
GET /vendor/phpunit/

такое поведение не соответствует обычной задаче RSS-reader.

TrafficVeil должен классифицировать такой источник по фактическому поведению, а не автоматически считать его Inoreader.

Почему UA недостаточно для Trusted Allow

Правило:

contains "inoreader"
→ Allow

создаёт потенциальный bypass.

Для дополнительной проверки стоит использовать:

• IP;
• ASN;
• ASN organization;
• network type;
• reverse DNS;
• TLS/HTTP fingerprint;
• периодичность;
• целевые URL;
• историю активности.

Как проверить ASN и PTR

IP="1.2.3.4"

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

Но эти сведения следует использовать как дополнительные сигналы. Публичного официального IP-feed Inoreader для верификации crawler при проверке обнаружить не удалось.

Observed IP и Verified IP

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

Современной официальной crawler-страницы Inoreader, где оператор однозначно обещает соблюдение robots.txt всеми своими fetcher, при проверке обнаружить не удалось.

Поэтому TrafficVeil лучше хранить:

robots.txt compliance: Unverified

Сторонние bot-базы по историческим UA также дают неодинаковую информацию, поэтому полагаться на них как на официальную политику сервиса не стоит.

robots.txt для Inoreader

Если владелец хочет объявить полный запрет:

User-agent: Inoreader
Disallow: /

Для наблюдаемого варианта с доменным токеном может потребоваться отдельная политика:

User-agent: inoreader.com
Disallow: /

После изменения необходимо проверить access.log и убедиться, какое правило фактически учитывает конкретный fetcher.

Частичная политика

Если нужно оставить RSS, но ограничить остальные зоны:

User-agent: Inoreader
Allow: /feed/
Allow: /rss/
Disallow: /admin/
Disallow: /account/
Disallow: /checkout/
Disallow: /internal/

Однако robots.txt не является системой авторизации. Приватные страницы должны быть закрыты независимо от поведения RSS-reader.

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

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

Это простой UA-фильтр. Он остановит любой клиент, который использует соответствующее имя, включая поддельный UA.

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

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

Нужен ли Rate Limit

Если Inoreader нужен, но feed polling оказывает заметную нагрузку, Rate Limit возможен, однако это не всегда лучший первый шаг.

Сначала проверьте:

1. работает ли CDN cache;
2. есть ли ETag;
3. есть ли Last-Modified;
4. сколько запросов реально приходит на origin;
5. какой response size;
6. не генерируется ли feed динамически при каждом запросе.

Если проблема устраняется caching, пользовательские RSS-подписки сохраняются без необходимости блокировать агрегатор.

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

Если Inoreader больше не сможет получать feed, новые публикации могут перестать нормально обновляться у подписчиков этого источника в Inoreader.

Это означает потенциальную потерю дополнительного канала распространения контента.

Inoreader официально строит продукт вокруг подписки на сайты и получения их обновлений в одном интерфейсе.

Повлияет ли блокировка Inoreader на Google или Яндекс

Нет прямой связи.

Inoreader не является Googlebot или YandexBot.

Точечное правило:

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

не является запретом для:

Googlebot
Googlebot-Image
YandexBot
Bingbot

Как учитывать Inoreader в аналитике

Запросы feed-fetcher не являются посещениями пользователей браузером.

Для TrafficVeil правильная структура:

Automated Traffic
→ RSS & Feed Fetchers
→ Inoreader

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

• исключать запросы из Human Traffic;
• не считать их конверсиями;
• не относить нормальный Inoreader к malicious bots;
• учитывать отдельно в RSS/service analytics;
• показывать polling frequency;
• показывать Cache HIT Ratio;
• показывать Origin Impact.

Полезно ли показывать subscriber count

Если UA содержит:

51 subscribers

TrafficVeil может сохранить это как дополнительное поле:

reported_subscribers = 51

Но в интерфейсе обязательно стоит написать:

Количество подписчиков сообщено User-Agent и не является независимо подтверждённой метрикой TrafficVeil.

Это позволит использовать полезные данные без ложной точности.

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

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

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

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

Вместо общего:

«Легитимный RSS-бот. Разрешайте по бизнес-пользе.»

лучше показать:

Inoreader — облачный RSS-reader компании Innologica. Он централизованно проверяет feed на новые публикации и распространяет обновления подписчикам. Частые обращения к одному RSS URL могут быть нормальным polling. При высокой нагрузке сначала рекомендуем проверить caching, ETag и Origin Impact, а не блокировать сервис сразу.

Итог

Inoreader — легитимный облачный RSS/content reader, а не поисковый crawler. Его серверы периодически получают feeds, чтобы новые публикации появлялись у подписчиков. Оператор сервиса — Innologica Ltd.

Одна из самых важных особенностей — polling централизован. Количество запросов нельзя считать линейно пропорциональным числу читателей: Inoreader получает feed на своей стороне, а результат используется для подписчиков сервиса. Механизм Boost дополнительно показывает, что ускорение одного feed может одновременно приносить пользу другим подписчикам.

Поэтому для TrafficVeil оптимальная политика — Allow / Monitor, а при повышенной активности первым шагом должны быть cache, conditional requests и анализ Origin Impact.

Если же клиент использует UA Inoreader, но вместо feed начинает сканировать конфигурационные файлы, админки и уязвимые endpoint, его нужно классифицировать по фактическому поведению и не выдавать trusted-статус только по имени.