Slack-ImgProxy: зачем Slack прячет изображения за отдельным прокси-ботом

Слово «прокси» в имени Slack-ImgProxy — не случайность, а суть его работы: этот бот не просто скачивает картинку для превью, а сознательно встаёт между вашим сервером и участниками Slack-канала, чтобы скрыть от них лишние детали. Slack официально документирует этого агента на странице api.slack.com/robots вместе с его напарником Slackbot-LinkExpanding — и объясняет, зачем нужна именно такая архитектура из двух отдельных ботов, а не одного.

Как устроено превью ссылки в Slack — в два шага

Когда пользователь вставляет ссылку в канал, Slack разворачивает её в rich-превью (это называется unfurling) — заголовок, описание, цветная плашка сбоку и картинка. Процесс разбит на два независимых запроса с двумя разными ботами:

• Slackbot-LinkExpanding первым обращается к самой странице — но не скачивает её полностью, а забирает минимально необходимую часть с помощью HTTP Range-заголовков, разбирая метатеги oEmbed, Twitter Card и Open Graph;
• Slack-ImgProxy отдельным запросом уже забирает конкретный файл изображения, на который указывает найденный og:image, и кеширует его на своей стороне.

По официальному объяснению Slack, разделение на два бота и проксирование изображений через отдельный компонент решает сразу три задачи: скрывает от получателя картинки детальную информацию о реферере (которая может случайно раскрыть название команды или внутреннего проекта отправителя), гарантирует, что изображение будет отдано по HTTPS даже если исходный сервер поддерживает только HTTP, и позволяет кешировать результат, чтобы не дёргать исходный сайт повторно при каждом просмотре сообщения участниками канала.

Параметры бота

Сколько трафика он создаёт

По сводке TrafficVeil, суммарная нагрузка от Slack-ImgProxy на подключённых доменах — порядка 80 запросов за отчётный период. Это ожидаемо малый объём: бот не сканирует сайт, а реагирует только на факт того, что кто-то вставил ссылку на изображение с сайта в Slack-переписку, да ещё и с получасовым кешем повторных запросов по тому же адресу.

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

Здесь стоит рассматривать Slack-ImgProxy и Slackbot-LinkExpanding как единую пару, а не по отдельности:

• если сайт заинтересован в качественных превью при обсуждении ссылок в рабочих Slack-каналах (SaaS-продукты, документация, блоги, инструменты для команд — Slack особенно активно используется именно в таких сценариях) — оба бота стоит разрешить вместе: запрет одного из них при разрешённом другом даст сломанное превью — например, заголовок и описание будут отображаться, а картинка — нет, или наоборот;
• если превью в Slack не имеют значения для сайта — можно заблокировать оба бота одним правилом, ничего не потеряв в позициях в органической выдаче Google, Bing или Яндекса, поскольку эта пара не связана с классической поисковой индексацией.

Как найти бота в логах

grep -i "Slack-ImgProxy" /var/log/nginx/access.log

Как настроить доступ

Если картинки в Slack-превью нужны — явное разрешение для обоих ботов пары:

User-agent: Slack-ImgProxy
Allow: /

User-agent: Slackbot-LinkExpanding
Allow: /

Если требуется полностью отключить Slack-unfurl на сайте — запрет вместе с дублированием на уровне сервера:

User-agent: Slack-ImgProxy
Disallow: /

User-agent: Slackbot-LinkExpanding
Disallow: /

if ($http_user_agent ~* "Slack-ImgProxy|Slackbot-LinkExpanding") {
    return 403;
}

Если задача не полная блокировка, а снижение количества повторных обращений при высокой популярности ссылки, разумная альтернатива — не резать бота вовсе, а задать заголовки кеширования на самих изображениях (например, Cache-Control: public, max-age=604800), чтобы Slack и другие подобные прокси дольше переиспользовали уже полученную копию, не обращаясь к серверу заново.