Строка substackcontentfetch в логах обычно описывают максимально общо — «инфраструктура в рамках штатной работы платформы». На деле полная строка агента подтверждена реальными наблюдениями в открытых источниках: SubstackContentFetch/1.0 (https://substack.com/). Это бот платформы подписных рассылок Substack, и заходит он не системно, а в ответ на конкретное действие автора.
Что такое SubstackContentFetch на самом деле
Substack — американская платформа для публикации подписных рассылок, подкастов и видео, основанная в 2017 году в Сан-Франциско. Наблюдения владельцев сайтов (включая обсуждение на Hacker News, куда этот бот тоже заходил) показывают, что SubstackContentFetch обращается к внешним, не связанным с Substack сайтам — это указывает на функцию генерации превью или встраивания ссылки, когда автор рассылки на Substack публикует материал со ссылкой на внешний источник.
| Параметр | Значение |
| Название | SubstackContentFetch |
| User-Agent / паттерн | SubstackContentFetch/1.0 (https://substack.com/) |
| Оператор | Substack Inc., Сан-Франциско, с 2017 года |
| Категория TrafficVeil | Вероятный фетчер превью-ссылок для рассылок Substack (не системная инфраструктура) |
| Наиболее вероятная причина визита | Автор Substack-рассылки сослался на вашу страницу в своём материале, и платформа забрала контент для превью/встраивания |
| Список IP | ❌ Публичного списка нет; проверяйте ASN и поведение |
| robots.txt | Отдельной официальной документации по краулеру компания не публикует |
| Пометка TrafficVeil | Легитимный, но с оговоркой — официального подтверждения точного назначения от Substack нет |
Честная оговорка: у Substack, в отличие от Slack или Snap, нет публичной страницы, прямо документирующей поведение этого краулера. «Наиболее вероятная причина» — обоснованный вывод из зафиксированного поведения (обращения к внешним сайтам, не относящимся к самой платформе) и общей логики похожих ботов для превью ссылок, а не подтверждённый факт от оператора.
Почему это похоже на фетчер превью, а не на системный краулер
Механика напоминает Slackbot-LinkExpanding, Mediumbot-MetaTagFetcher или Snap URL Preview Service: триггер — не расписание, а конкретное действие автора рассылки, который сослался на вашу страницу. Бот забирает контент этой одной страницы, чтобы платформа могла показать читателям превью или корректно встроить ссылку — а не чтобы систематически обходить сайт целиком.
Как найти SubstackContentFetch в логах
# Базовый поиск
grep -i "substackcontentfetch" /var/log/nginx/access.log
# Какие именно страницы упоминали в рассылках Substack
grep -i "substackcontentfetch" /var/log/nginx/access.log | awk '{print $7}' | sort | uniq -c | sort -rn | head
# Топ IP
grep -i "substackcontentfetch" /var/log/nginx/access.log | awk '{print $1}' | sort | uniq -c | sort -rn | headДля верификации сверяйте IP через ASN — единичные точечные визиты к конкретной странице характерны для такого фетчера, а не для спуфинга:
IP="1.2.3.4"
whois -h whois.cymru.com " -v $IP"robots.txt и настройка через TrafficVeil
# Разрешить (стандартный вариант — не мешать корректным превью)
User-agent: SubstackContentFetch
Allow: /
# Закрыть только чувствительные разделы
User-agent: SubstackContentFetch
Disallow: /admin/
Disallow: /account/
Allow: /TrafficVeil: для этого бота разумный вариант по умолчанию — «легитимный» без rate-limit: нагрузка минимальна и точечна, а польза (корректное отображение ссылки при упоминании в чужой рассылке на Substack) перевешивает риски. Переключать на «запретить» стоит только если аудитория Substack-рассылок заведомо не релевантна бизнесу.
Что в итоге делать с SubstackContentFetch
| Ситуация | Действие |
| Стандартный случай | Allow без rate-limit — визитов мало, а превью в рассылках полезны |
| Аудитория Substack не релевантна бизнесу | Disallow / запрет в TrafficVeil — потери минимальны |
| Подозрение на спуфинг (высокая частота, обход многих URL) | Сверять по ASN — настоящий фетчер так себя не ведёт |