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

FreshRSS — бесплатный open-source агрегатор RSS и Atom. В отличие от Inoreader или Feedspot это не единый облачный сервис: FreshRSS предназначен прежде всего для самостоятельной установки на собственном сервере.

Официальный проект описывает FreshRSS как self-hosted RSS and Atom feed aggregator. Приложение поддерживает несколько пользователей, API для клиентов, CLI, расширения и различные способы автоматического обновления feeds.

Именно self-hosted модель является главным фактором для антибот-классификации. Запросы FreshRSS не исходят из одного датацентра или одного фиксированного ASN. Они могут приходить с тысяч независимых установок по всему интернету.

Почему FreshRSS нельзя описывать как обычного централизованного бота

У Googlebot есть инфраструктура Google. У Bingbot — Microsoft. У многих SaaS feed-reader запросы также идут из серверной инфраструктуры самого оператора.

У FreshRSS всё иначе:

Пользователь A
→ FreshRSS на собственном VPS
→ ваш RSS

Пользователь B
→ FreshRSS на домашнем сервере
→ ваш RSS

Компания C
→ корпоративная установка FreshRSS
→ ваш RSS

Все три запроса могут иметь похожий User-Agent, но совершенно разные IP, ASN, страны и fingerprints.

Это нормальное следствие self-hosted архитектуры FreshRSS, а не признак spoofing.

Кто является оператором FreshRSS

Здесь полезно разделять разработчика ПО и оператора конкретного HTTP-запроса.

FreshRSS развивается как open-source проект. Но конкретный запрос к вашему feed отправляет экземпляр FreshRSS, которым управляет его владелец.

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

Software: FreshRSS
Request operator: self-hosted / unknown instance owner

а не:

Operator: FreshRSS central infrastructure

Такой центральной crawling-инфраструктуры в базовой модели продукта нет.

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

Основной сценарий — обновление RSS или Atom-подписки.

Пользователь добавляет URL feed в FreshRSS:

https://example.com/feed/

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

Официальная документация также указывает, что FreshRSS способен автоматически найти feed, если сайт объявляет его стандартным способом.

Типичная цепочка:

Сайт
↓
RSS / Atom
↓
FreshRSS instance
↓
локальная база публикаций
↓
читатель FreshRSS

Как часто FreshRSS обновляет feed

FreshRSS поддерживает автоматическое обновление через CLI/cron.

Официальная административная документация указывает важное ограничение: стандартный update script не обновляет один конкретный feed чаще одного раза примерно в 20 минут. Поэтому запускать cron существенно чаще обычно бессмысленно.

Это даёт полезный behavioural signal.

Например:

00:00 GET /feed/
00:20 GET /feed/
00:40 GET /feed/
01:00 GET /feed/

может быть абсолютно нормальной активностью одного экземпляра FreshRSS.

Но частота не является глобально одинаковой

Не стоит превращать 20 минут в жёсткое правило антибота.

FreshRSS устанавливается владельцами самостоятельно, а feeds могут иметь собственные настройки обновления. Документация проекта также показывает, что FreshRSS хранит индивидуальные параметры feed, включая refresh frequency.

Поэтому TrafficVeil может использовать частоту как behavioural signal, но не как абсолютную проверку:

21 минута → FreshRSS
19 минут → spoofing

так делать нельзя.

FreshRSS может получать не только RSS

Это одна из самых важных особенностей.

Официальный user manual прямо указывает, что FreshRSS имеет встроенный механизм scraping сайта для создания собственного feed.

В настройках feed поддерживаются XPath scraping rules, что также подтверждается официальной документацией резервного копирования FreshRSS.

Следовательно, нормальный FreshRSS может обращаться не только к:

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

но и непосредственно к:

/news/
/blog/
/articles/
/category/example

если владелец экземпляра FreshRSS настроил HTML/XPath source.

Почему это важно для TrafficVeil

Если классификатор считает:

FreshRSS + /feed/ = легитимный
FreshRSS + HTML = подозрительный

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

Правильнее различать:

FreshRSS
├── RSS/Atom fetch
└── HTML/XPath scraping

Оба сценария поддерживаются самим продуктом.

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

В реальных логах часто встречается формат:

FreshRSS/1.x.x (...; https://freshrss.org)

Сторонние базы приводят, например:

FreshRSS/1.23.1 (Linux; https://freshrss.org)

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

FreshRSS позволяет хранить и настраивать User-Agent для отдельных feeds. Это видно и из официальной документации экспорта: среди FreshRSS-specific параметров перечисляется user agent.

Почему пользователь FreshRSS может изменить UA

Некоторые сайты блокируют нестандартные HTTP-клиенты или требуют browser-like User-Agent.

В официальных обсуждениях проекта FreshRSS разработчики прямо рассматривают тестирование одного feed с разными User-Agent, а пользователи могут настроить пользовательский UA для источника.

Поэтому в access.log FreshRSS иногда может выглядеть не как:

FreshRSS/...

а как обычный:

Mozilla/5.0 ...

Из этого следует важный вывод: TrafficVeil способен уверенно обнаружить FreshRSS по UA только тогда, когда экземпляр действительно сообщает своё имя.

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

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

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

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

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

Топ URL:

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

Топ IP:

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

HTTP-коды:

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

Как выделить классические feed requests

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

Если практически вся активность приходится на такие URL, перед вами типичный RSS/Atom-fetching профиль.

Как найти HTML/XPath fetching

Можно убрать традиционные feed URL:

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

Это поможет найти обычные HTML-страницы, которые могут использоваться FreshRSS для XPath scraping.

Почему разные IP — это нормально

Для многих известных ботов действует логика:

UA Googlebot
+
не Google IP
=
spoofing

Для FreshRSS такая модель неприменима.

FreshRSS является self-hosted software. Поэтому нормальный трафик может приходить из:

• Hetzner;
• AWS;
• OVH;
• DigitalOcean;
• домашнего ISP;
• университетской сети;
• корпоративного датацентра;
• любого другого hosting provider.

Сам факт разных ASN не является аномалией для FreshRSS. Это прямое следствие self-hosted модели.

Почему официальный IP allowlist FreshRSS невозможен как концепция

Для центрального SaaS можно опубликовать:

198.51.100.0/24
203.0.113.0/25

и сказать: это инфраструктура crawler.

FreshRSS устанавливается пользователями самостоятельно.

Поэтому:

Official FreshRSS crawler IP feed

не является разумной глобальной моделью идентификации.

TrafficVeil лучше хранить:

software_identity = FreshRSS
network_identity = independent instance

Можно ли доверять UA FreshRSS

Нет безусловно.

Любой клиент может отправить:

User-Agent: FreshRSS/1.27

Поэтому совпадение UA означает:

клиент заявляет, что использует FreshRSS.

Но получить такой же высокий уровень инфраструктурной верификации, как для Googlebot, в общем случае невозможно.

Как классифицировать FreshRSS без IP verification

Здесь особенно полезно поведение.

Как выглядит явный spoofing или misuse

User-Agent: FreshRSS/1.27

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

Несмотря на название UA, это не похоже на RSS-reader.

TrafficVeil должен классифицировать источник как security scanner или suspicious automation.

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

Для FreshRSS я бы не ставил статус robots.txt: Yes.

Официальная документация подтверждает RSS/Atom fetching, пользовательские User-Agent и XPath scraping, но отдельного обещания, что все экземпляры FreshRSS перед каждым fetch проверяют и соблюдают robots.txt, я не нашёл.

К тому же это self-hosted software, которое контролируется администратором конкретной установки.

Поэтому:

robots.txt compliance: Unverified / instance-dependent

Имеет ли смысл robots.txt для FreshRSS

Объявить политику можно:

User-agent: FreshRSS
Disallow: /

Но рассчитывать на неё как на гарантированную блокировку не стоит.

После изменения необходимо проверить access.log.

Почему блокировка по User-Agent работает надёжнее robots.txt

Если задача — именно технически запретить клиентам с заявленным FreshRSS UA доступ:

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

такое правило остановит запрос на уровне веб-сервера.

Но оно не остановит FreshRSS instance, владелец которого настроил browser-like custom User-Agent. FreshRSS поддерживает индивидуальные UA для feeds.

Apache

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

Стоит ли сразу использовать Rate Limit

Обычно нет.

Для RSS traffic гораздо полезнее сначала проверить, насколько запросы действительно нагружают origin.

Например:

5000 FreshRSS requests
4900 cache HIT
100 origin requests

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

А:

300 FreshRSS requests
300 динамических XML generation
тяжёлые SQL queries

могут быть заметнее.

Какие метрики показывать в TrafficVeil

Для FreshRSS особенно полезны:

• Requests;
• Unique IP;
• Unique ASN;
• Unique URLs;
• Feed Requests;
• HTML/XPath Requests;
• RPS/RPM;
• Cache HIT Ratio;
• Origin Requests;
• Bandwidth;
• Average Response Size;
• HTTP Status.

Почему Unique IP здесь особенно интересен

Для централизованного RSS-reader большое число IP может быть подозрительным.

Для FreshRSS — наоборот, естественным.

Например:

200 FreshRSS IP
200 разных серверов
1–2 feed URL каждый

может означать просто большую аудиторию пользователей FreshRSS.

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

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

Для RSS-фидов полезно:

• кэшировать XML;
• использовать CDN;
• корректно отдавать Last-Modified;
• использовать ETag, если ваш стек поддерживает его корректно;
• не перестраивать весь feed тяжёлым запросом к БД при каждом fetch;
• ограничить размер feed разумным количеством последних записей.

В обсуждениях FreshRSS отдельно поднимался вопрос conditional HTTP caching через If-Modified-Since и ETag, поэтому поведение конкретных версий и установок лучше проверять по собственным логам, а не предполагать идеальный cache negotiation.

FreshRSS поддерживает WebSub

FreshRSS также поддерживает получение новых статей через WebSub, то есть часть источников может обновляться не только традиционным polling. Эта возможность указана в официальном руководстве пользователя.

Это ещё один аргумент не пытаться описать весь FreshRSS-трафик одним фиксированным интервалом обновления.

Что произойдёт после блокировки FreshRSS

Читатели, использующие FreshRSS и получающие ваш feed, могут перестать получать новые записи.

При этом на Google Search точечная блокировка:

FreshRSS

не влияет напрямую, поскольку FreshRSS не является Googlebot.

То же самое относится к YandexBot и Bingbot.

Есть ли бизнес-польза от FreshRSS

Да, если сайт публикует RSS.

FreshRSS — это канал дистрибуции:

ваш сайт
↓
RSS
↓
FreshRSS
↓
читатель
↓
переход на статью

Поэтому автоматически относить его к «нежелательным ботам» не стоит.

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

Сам HTTP-fetch не является человеческим визитом.

Для TrafficVeil:

Automated Traffic
→ RSS & Feed Fetchers
→ Self-hosted Readers
→ FreshRSS

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

• исключать из Human Traffic;
• не считать конверсиями;
• не считать malicious при нормальном поведении;
• учитывать отдельно как feed traffic;
• разделять RSS и HTML/XPath fetching;
• не ожидать фиксированный IP/ASN.

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

Это различие нужно учитывать при bot verification.

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

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

Почему Rate Limit лучше применять по IP, а не ко всему FreshRSS

Поскольку независимые экземпляры FreshRSS не связаны между собой, глобальный жёсткий лимит:

весь FreshRSS → 10 запросов в минуту

может искусственно объединить множество реальных подписчиков.

Гораздо логичнее:

FreshRSS + source IP → rate policy

или учитывать конкретный feed URL.

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

Вместо:

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

лучше написать:

FreshRSS — self-hosted RSS/Atom reader. Его пользователи запускают собственные экземпляры, поэтому запросы могут приходить с множества несвязанных IP и ASN. Это нормально. FreshRSS обычно получает feeds, но также поддерживает XPath scraping обычных HTML-страниц. При высокой нагрузке сначала рекомендуем проверить cache и ограничить конкретный источник, а не блокировать весь FreshRSS.

Итог

FreshRSS — легитимный self-hosted RSS/Atom агрегатор, но технически он сильно отличается от централизованных feed-reader. Нет одного оператора запросов, одного ASN или официального списка IP: каждый владелец запускает собственный экземпляр FreshRSS.

Стандартный сценарий — периодическое обновление RSS/Atom. Официальная документация указывает, что стандартный update script не обновляет один feed чаще примерно одного раза в 20 минут. Но FreshRSS также поддерживает индивидуальную refresh frequency, WebSub и XPath scraping HTML-страниц.

Поэтому TrafficVeil лучше классифицировать его как RSS & Feed Fetchers → Self-hosted Readers и использовать базовую политику Allow / Monitor.

При повышенной нагрузке сначала стоит оптимизировать кэширование feeds и применить rate limit к конкретному IP или экземпляру. А если клиент с UA FreshRSS начинает перебирать .env, backup-файлы и vulnerability paths, его нужно классифицировать по реальному поведению — название легитимного RSS-reader не должно давать автоматический trusted status.