Mastodon — необычный случай даже среди превью-ботов: у него нет единого оператора и единого IP-диапазона в принципе, потому что сама платформа децентрализована. Тысячи независимо управляемых серверов («инстансов») — mastodon.social, infosec.exchange, mastodon.mit.edu и множество других — каждый самостоятельно фетчит превью ссылок со своей инфраструктуры. Черновая формулировка «оператор не указан публично» здесь не столько неточна, сколько отражает фундаментальное устройство платформы, а не пробел в данных.
1. Что такое Mastodon на самом деле
Это fetcher превью-ссылок: когда пользователь публикует ссылку в посте («toot»), его домашний инстанс Mastodon делает запрос к этому URL, чтобы собрать данные для карточки — предпочтительно через OEmbed-теги, затем JSON-LD, затем Open Graph, и в последнюю очередь — обычные HTML-теги. Разработчик Mastodon в 2020 году сознательно добавил слово «Bot» в строку User-Agent сервиса превью именно для прозрачности — чтобы сайты могли однозначно идентифицировать этот трафик как автоматический, а не браузерный.
Ключевая особенность федеративной архитектуры: когда пост «федерируется» (репостится/расшаривается) на другой инстанс, тот инстанс независимо повторяет тот же процесс — сам заново фетчит ссылку и строит собственную копию карточки. Это значит, что одна популярная ссылка может получить не один запрос, а несколько — от разных, никак не связанных между собой серверов по всему миру.
| Параметр | Значение |
| Название | Mastodon (fetcher превью-ссылок) |
| Оператор | Отсутствует в привычном смысле — федеративная сеть из тысяч независимо администрируемых инстансов, у каждого своя инфраструктура |
| Роль | Fetcher метаданных (OEmbed → JSON-LD → Open Graph → HTML) для построения превью-карточки при публикации ссылки в посте |
| User-Agent / паттерн | Содержит слово «Bot» (добавлено разработчиками сознательно для прозрачности с 2020 года); конкретная строка зависит от версии и настроек конкретного инстанса |
| robots.txt | Намеренно НЕ соблюдается по замыслу разработчиков — обоснование: запрос выполняется как агент конкретного пользователя, разово фетчащего конкретную ссылку, а не как системный обход (та же логика, что у PageSpeed Insights/WebPageTest, тоже игнорирующих robots.txt для user-triggered фетчей) |
| Паттерн поведения | Разовый запрос к конкретной странице при шеринге; не обходит сайт дальше, не имеет доступа к приватному контенту сверх того, что доступно по самой ссылке |
| Пометка TrafficVeil | Легитимный / Прочие краулеры и сервисы |
2. Зачем Mastodon приходит на сайт
- пользователь одного из тысяч независимых Mastodon-инстансов опубликовал ссылку на вашу страницу в посте, и домашний сервер этого пользователя запрашивает метаданные для построения карточки;
- если пост репостнут («boosted») на другие инстансы или получил ответы с той же ссылкой, каждый вовлечённый инстанс может независимо повторить запрос — отсюда возможен неожиданный «многоголосый» паттерн от разных IP на одну и ту же популярную ссылку;
- отдельный нюанс, который стоит знать при диагностике: если у страницы есть валидные Open Graph-теги, но указанное в них изображение недоступно, сервис карточек Mastodon может повторно и настойчиво пытаться получить это изображение при каждом новом упоминании поста, обходя обычное кэширование — в отдельных случаях это описывалось как поведение, напоминающее слабую DDoS-волну именно на конкретный битый URL изображения.
Типичный кейс: разовый или редкий запрос к конкретной странице сразу после того, как на неё кто-то сослался в посте — стандартное поведение fetcher-а, ничем принципиально не отличающееся от Facebook External Hit или Twitterbot, за исключением множественности источников из-за федерации.
3. Нагрузка и риски
Нагрузка обычно минимальна и коррелирует с тем, насколько часто ссылку на ваш сайт публикуют и репостят на платформе — «вирусная» ссылка может дать заметный, но краткий всплеск запросов сразу с нескольких инстансов. Практический риск при блокировке стандартный: пользователи, делящиеся вашей ссылкой на Mastodon, получат карточку без изображения и описания, что снижает вовлечённость и переходы.
Отдельный, специфичный именно для Mastodon риск нагрузки — уже упомянутый паттерн повторных запросов к отсутствующему og:image при каждом новом упоминании поста. Если в логах фиксируется необычно частый, повторяющийся обход одного и того же URL изображения именно с Mastodon-подобным UA — вероятная причина не атака, а битая или недоступная ссылка на изображение в метатегах страницы, которую стоит исправить на своей стороне.
4. Как найти Mastodon в логах
# Базовый поиск
grep -i "mastodon" /var/log/nginx/access.log
# Топ URL, которые запрашивает fetcher
grep -i "mastodon" /var/log/nginx/access.log | awk '{print $7}' | sort | uniq -c | sort -rn | head
# Топ IP — из-за федерации ожидаемо много разных, не связанных между собой источников
grep -i "mastodon" /var/log/nginx/access.log | awk '{print $1}' | sort | uniq -c | sort -rn | head
# Суточная активность
grep -i "mastodon" /var/log/nginx/access.log | awk '{print $4}' | cut -d: -f1 | sort | uniq -c
# Признак повторяющихся запросов к одному URL изображения — вероятный сигнал недоступного og:image
grep -i "mastodon" /var/log/nginx/access.log | grep -iE "\.(jpg|png|webp)" | awk '{print $7}' | sort | uniq -c | sort -rn | head
Верификация. Здесь стандартная логика «сверьте с официальным ASN» не работает: единого оператора и диапазона IP нет по самой природе федеративной платформы — легитимный запрос может прийти буквально с любого из тысяч независимо администрируемых серверов по всему миру. Строку UA подделать может любой скрипт, но при отсутствии единого оператора имеет смысл в первую очередь смотреть на поведенческий паттерн (разовый запрос к конкретной, недавно опубликованной странице), а не пытаться сверить IP с каким-либо официальным списком:
IP="1.2.3.4"
whois -h whois.cymru.com " -v $IP"
dig +short -x "$IP"
# Полезно смотреть организацию/ASN хостинга — многие инстансы размещены на узнаваемых облачных/VPS-провайдерах,
# но единого «правильного» ASN для всей платформы не существует
5. robots.txt для Mastodon
# Технически можно прописать, но по замыслу платформы соблюдаться не будет
User-agent: Mastodon
Disallow: /
# Разрешить всё — рекомендуемый вариант по умолчанию
User-agent: Mastodon
Allow: /
Важно понимать: даже жёсткий Disallow здесь скорее декларативный — Mastodon сознательно не следует этой директиве для fetcher-запросов по той же логике, что PageSpeed Insights или WebPageTest: запрос совершается от имени конкретного пользователя, разово поделившегося ссылкой, а не как системный обход.
6. Блокировка вручную и через TrafficVeil
Nginx:
if ($http_user_agent ~* "mastodon") {
return 403;
}
Apache (.htaccess):
RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} mastodon [NC]
RewriteRule ^ - [F,L]
TrafficVeil:
- найдите mastodon в разделе ботов домена или в /system/bots;
- для подавляющего большинства сайтов — allow обоснован по умолчанию, поскольку нагрузка минимальна, а блокировка портит отображение ссылок на растущей платформе;
- если наблюдается аномально частый, повторяющийся обход одного и того же изображения — проверьте валидность og:image на затронутой странице, прежде чем воспринимать это как нежелательный трафик;
- полная техническая блокировка через серверные правила (в отличие от robots.txt) будет эффективна, поскольку не зависит от добровольного соблюдения бота.
7. Что делать: короткий алгоритм
- Стандартная рекомендация — allow: нагрузка минимальна, а польза (корректное превью при шеринге) реальна и растёт вместе с популярностью платформы;
- Заметен необычно частый обход одного и того же URL изображения — почините og:image на странице, а не боритесь с ботом;
- Помните о федеративной природе: сверка с «официальным ASN» здесь невозможна в принципе, решение стоит принимать по поведенческому паттерну;
- Специально блокировать имеет смысл только в редких, осознанных сценариях — например, принципиальный отказ фигурировать на децентрализованных соцплатформах;
- Не блокируйте по маске
User-agent: *, чтобы не задеть Googlebot/YandexBot заодно.
8. С кем не путать Mastodon
| Бот / сосед | Кластер | Комментарий |
| Facebook External Hit | Превью ссылок в соцсетях | Та же функция unfurl, но с единым централизованным оператором и публикуемым списком IP — в отличие от федеративного Mastodon |
| Twitterbot | Превью ссылок в соцсетях | Тоже централизованный оператор (X), хотя официального IP-списка тоже не публикует — см. отдельную статью |
| ArenaUnfurlBot | Превью ссылок в соцсетях | легитимный, централизованная платформа |
| KeybaseBot | Не в базе TrafficVeil, но стоит знать | Похожий по функции fetcher для мессенджера Keybase — тоже присылает IP отправителя ссылки, но у сервиса единая инфраструктура, в отличие от Mastodon |
9. Стратегия allow/deny для Mastodon
| Ситуация | Действие |
| Стандартный сайт без особых ограничений | Allow — минимальная нагрузка, реальная польза от корректного превью |
| Необычно частые повторные запросы к одному og:image | Исправить сам мета-тег изображения на странице, а не блокировать бота |
| Принципиальный отказ от присутствия на децентрализованных соцплатформах | Disallow технически возможен, но полагайтесь на серверную блокировку, а не на robots.txt |
| Нагрузка от «вирусной» ссылки создаёт заметный краткий всплеск | Это ожидаемо из-за федерации — rate-limit, а не полный запрет |
| Подозрение на spoofing UA | Единого ASN для сверки нет по природе платформы — смотреть поведенческий паттерн (разовый запрос к недавно опубликованной странице) |