Protopage: что это за RSS-бот и нужно ли его блокировать

Protopage — персональная стартовая страница, RSS-reader и веб-портал. Пользователь может собрать на одной странице новости, RSS-ленты, закладки, заметки и другие виджеты.

Для владельца сайта особенно интересна RSS-функция Protopage. Сервис автоматически получает новостные feeds, чтобы показывать свежие заголовки в пользовательских виджетах. Официальный сайт прямо позиционирует Protopage как RSS Reader и предлагает читать RSS-ленты блогов, новостей, подкастов и других источников.

Поэтому появление:

Protopage/3.0

в access.log обычно относится к feed-fetching, а не к обычной пользовательской сессии, webhook-проверке или tracking-коду.

Cloudflare Radar отдельно подтверждает Protopage как Verified bot категории Feed Fetcher, указывает оператором Protopage Ltd и публикует наблюдаемый User-Agent.

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

Основной сценарий — пользователь хочет получать новости сайта внутри своей персональной страницы Protopage.

Цепочка выглядит примерно так:

пользователь Protopage
↓
добавляет сайт или feed
↓
Protopage определяет RSS/Atom
↓
серверы Protopage получают feed
↓
извлекают новые записи
↓
показывают заголовки в news widget

Официальное руководство Protopage говорит, что пользователь может ввести практически любой адрес сайта, а сервис сам пытается определить, как создать для него news headline widget.

Protopage — не webhook checker

В исходном описании Protopage был представлен как сервис, который проверяет URL при установке:

widget
webhook
tracking code

Для webhook и tracking-code сценариев подтверждения не найдено.

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

• RSS-reader;
• news widgets;
• автоматическое обнаружение feeds;
• персональную start page;
• web/intranet portal.

Поэтому для TrafficVeil правильнее удалить упоминания webhook и tracking verification.

Protopage умеет автоматически находить RSS

Особенно важная функция — feed autodiscovery.

Пользователю необязательно заранее знать:

https://example.com/feed.xml

Он может добавить:

https://example.com/

а Protopage попробует автоматически определить подходящий news feed.

В официальном help прямо сказано, что пользователь может ввести адрес сайта, а Protopage автоматически определит, как создать news widget.

Почему Protopage может запросить HTML

Из feed autodiscovery следует важный вывод.

Нормальный Protopage не обязан обращаться только к:

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

Он может сначала получить:

GET /

или другую страницу сайта, чтобы определить доступные feeds.

Официальная функция Add to Protopage также позволяет владельцу сайта передать обычный адрес сайта либо прямой URL RSS/Atom feed. Если автоматическое определение feed не работает, Protopage рекомендует указывать прямой feed URL.

Это важно для антибот-классификации

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

Protopage + /feed/ = legitimate
Protopage + HTML = suspicious

HTML-запрос может быть частью нормального feed autodiscovery.

Лучше различать:

Protopage
├── Feed discovery
├── RSS/Atom fetching
└── News feed indexing

Protopage индексирует новостные feeds

В собственном блоге Protopage ранее подробно описывал развитие своей news feed indexing platform. Сервис автоматически обнаруживает и собирает headlines из большого числа сайтов и хранит историю заголовков для news widgets.

Это дополнительно подтверждает, что правильная техническая роль Protopage — RSS/news feed fetcher.

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

Cloudflare Radar фиксирует:

Protopage/3.0 (http://www.protopage.com)

Для TrafficVeil можно использовать устойчивый matcher:

Protopage/

или case-insensitive:

protopage

Cloudflare относит именно этот UA к подтверждённому Feed Fetcher Protopage.

Почему одного User-Agent всё равно недостаточно

User-Agent остаётся обычным HTTP-заголовком.

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

User-Agent: Protopage/3.0 (http://www.protopage.com)

Поэтому TrafficVeil не должен превращать:

UA match
→ unconditional allow

в универсальное trusted-правило.

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

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

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

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

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

Топ URL:

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

Топ IP:

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

HTTP-коды:

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

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

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

Так можно понять, какая доля активности приходится непосредственно на RSS/Atom endpoint.

Как найти запросы для feed autodiscovery

Уберите известные feed URL:

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

Оставшиеся HTML-запросы стоит анализировать отдельно.

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

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

Как выглядит spoofed Protopage

Например:

User-Agent: Protopage/3.0

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

Это не соответствует назначению RSS/news feed fetcher.

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

Protopage UA spoofing
/
Suspicious automation
/
Security scanning

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

Как дополнительно проверять источник

При отсутствии опубликованного официального IP feed можно учитывать:

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

Cloudflare самостоятельно классифицирует Protopage как Verified, что является сильным внешним сигналом существования реального crawler. Но собственная система TrafficVeil всё равно должна отличать заявленный UA от подтверждённого поведения.

Observed и Verified — не одно и то же

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

Cloudflare Bot Directory указывает для Protopage robots.txt-токен:

User-Agent: Protopage
Disallow: /

что подтверждает применимое имя агента для декларативной политики.

При этом отдельной официальной crawler-policy Protopage с подробным описанием robots behavior я не нашёл.

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

robots token: Protopage
robots compliance: not independently documented in detail

robots.txt для Protopage

Полный запрет:

User-agent: Protopage
Disallow: /

Если хочется оставить feeds:

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

После изменения стоит проверить фактическое поведение в access.log.

Почему robots.txt не заменяет защиту

Если URL содержит приватные данные, он должен быть защищён:

• authentication;
• authorization;
• ACL;
• WAF;
• закрытыми API;
• server-side rules.

robots.txt — декларативная crawler-policy, а не access control.

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

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

Такое правило блокирует любой HTTP-клиент, который заявляет соответствующий User-Agent.

Apache

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

Стоит ли блокировать Protopage

Для большинства сайтов с RSS автоматический Deny не нужен.

Protopage является реальным каналом распространения контента:

ваш сайт
↓
RSS/Atom
↓
Protopage
↓
news widget
↓
пользователь Protopage
↓
переход на публикацию

Официальный сервис существует именно для чтения RSS и вывода news widgets на персональных страницах пользователей.

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

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

• RSS является полезным каналом дистрибуции;
• вы не против присутствия материалов в Protopage widgets;
• нагрузка минимальна;
• поведение клиента соответствует feed fetcher.

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

Monitor — хороший default, если:

• агент идентифицирован;
• нагрузки практически нет;
• бизнес-ценность пока неизвестна;
• нет security-sensitive поведения.

Когда сначала использовать Cache

RSS/Atom идеально подходят для кэширования.

Например:

Protopage
↓
GET /feed.xml
↓
TrafficVeil cache HIT
↓
origin не вызывается

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

Какие метрики важнее количества запросов

Для Protopage полезно показывать:

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

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

Например:

8 000 Protopage requests
99% cache HIT
80 origin requests

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

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

Поэтому TrafficVeil стоит показывать Origin Impact.

Как оптимизировать RSS вместо блокировки

Если Protopage полезен, но polling создаёт нагрузку:

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

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

Rate Limit имеет смысл, если:

• источник запрашивает feed слишком часто;
• кэширование не решает проблему;
• origin получает измеримую нагрузку;
• вы хотите сохранить RSS-дистрибуцию.

Жёсткий лимит следует подбирать по фактическому Origin Impact, а не использовать случайные универсальные значения вроде 10 запросов в минуту.

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

Block разумен, если:

• RSS-дистрибуция через Protopage не нужна;
• автоматизированный доступ запрещён политикой сайта;
• конкретный источник создаёт чрезмерную нагрузку;
• UA используется для security scanning;
• поведение не соответствует feed fetching.

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

Protopage может перестать обновлять соответствующий news widget или feed пользователя.

То есть возможна потеря части RSS-дистрибуции.

При этом Protopage не является Googlebot или YandexBot, поэтому точечная блокировка его UA не является запретом для этих поисковых систем.

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

Сам запрос feed fetcher — машинное событие.

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

Protopage GET /feed.xml
→ Automated Traffic

пользователь Protopage нажал headline
→ Human Traffic / referral

Это совершенно разные события.

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

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

Automated Traffic
→ RSS & Feed Fetchers
→ Hosted Readers / Portals
→ Protopage

Запросы следует:

• исключать из Human Traffic;
• не считать конверсиями;
• не считать автоматически malicious;
• учитывать отдельно в RSS analytics;
• показывать feed discovery отдельно от RSS fetching;
• показывать Origin Impact.

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

Почему категория «Прочие краулеры» слишком общая

Для пользователя гораздо полезнее увидеть:

RSS & Feed Fetchers
→ Hosted Readers / Portals
→ Protopage

чем:

Прочие краулеры и сервисы

Так назначение трафика понятно без дополнительного исследования.

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

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

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

Вместо:

«Protopage — сервис, проверяющий интеграции, webhook и tracking-коды.»

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

Protopage — RSS-reader и персональный веб-портал. Его серверы получают RSS/Atom и новостные заголовки, чтобы обновлять пользовательские news widgets. Protopage также умеет автоматически определять feed по обычному адресу сайта. При небольшой нагрузке рекомендуем Allow или Monitor; при частом polling сначала используйте кэширование.

Итог

Protopage — не неизвестный интеграционный бот, а хорошо идентифицированный RSS/news feed fetcher.

Официальный Protopage позиционируется как RSS Reader и позволяет пользователям добавлять практически любой сайт, после чего автоматически определяет подходящий news feed и создаёт новостной виджет.

Cloudflare Radar дополнительно подтверждает Protopage как Verified Feed Fetcher, указывает оператора Protopage Ltd и User-Agent:

Protopage/3.0 (http://www.protopage.com)

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

RSS & Feed Fetchers
→ Hosted Readers / Portals
→ Protopage

Operator: Protopage Ltd
External verification: Verified
Default: Allow / Monitor

Если Protopage полезен как канал RSS-дистрибуции, блокировать его по умолчанию не стоит. Если polling создаёт нагрузку, сначала лучше оптимизировать cache и измерить Origin Impact. А если под UA Protopage начинается перебор .env, backup-файлов или других технических endpoint, TrafficVeil должен классифицировать источник по реальному поведению, а не доверять одному имени.