Podsync больше не облако — только личные инсталляции пользователей

Podsync стоит отдельного правила в антиботе: это не «ещё один hit», а повторяемый паттерн автоматизации в категории «Прочие краулеры и сервисы». Но прежде чем искать за ним единого оператора, стоит понять главное: Podsync — открытое ПО, которое каждый пользователь разворачивает самостоятельно, а не облачный сервис одной компании.

Podsync — open-source проект (mxpv/podsync на GitHub), написанный на Go: превращает каналы YouTube, Vimeo, SoundCloud и Twitch в стандартные подкаст-RSS-фиды, чтобы их можно было слушать в обычных подкаст-приложениях с автозагрузкой новых эпизодов, запоминанием позиции воспроизведения и офлайн-прослушиванием — функциями, которых нет в самом YouTube или Vimeo.

Что такое Podsync

Почему у Podsync больше нет единого «облачного» оператора

Изначально существовал и централизованный хостинг-сервис Podsync, но после того как YouTube заблокировал API-ключи, которые проект использовал для получения метаданных каналов, создатель официально объявил об отключении хостинга и посоветовал пользователям переходить на self-hosted CLI-версию. Это значит, что сегодня практически весь реальный трафик под этим UA — след чьей-то личной, самостоятельно развёрнутой инсталляции, а не единого сервиса.

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

Если ваш сайт публикует видео (например, встраивает YouTube-плеер, ведёт канал или является источником, на который кто-то подписался как на подкаст-контент), появление Podsync в логах, скорее всего, означает: конкретный человек настроил свой собственный экземпляр Podsync, чтобы регулярно превращать контент вашего сайта или связанного с ним канала в подкаст-фид для личного прослушивания.

• Какие зоны чаще трогает: публичные URL, иногда API и статику — конкретно те, что связаны с настроенным источником контента
• Что ищет: метаданные видео/аудио, ссылки на сами файлы — то, что нужно для генерации RSS-фида
• Чем отличается от браузерного пользователя: нет нормальной сессии, регулярные повторные обращения по расписанию обновления фида, заданному конкретным пользователем

Типичный кейс: CDN-трафик дорожает, origin CPU пилит HTML. Фильтр по podsync показывает точечные, повторяющиеся обращения к конкретным разделам — обычно объём небольшой, поскольку это персональный инструмент одного человека, а не массовый краулер.

Нагрузка и риски

Отдельной строки в публичной сводке top-bot TrafficVeil у podsync может не быть, но в категории «Прочие краулеры и сервисы» такие агенты дают характерный фон: фоновый шум в аналитике, расход CPU/bandwidth и искажение статистики «живого» трафика. Учитывая персональную, self-hosted природу инструмента, заметная нагрузка от одного источника маловероятна — если видите высокий объём, вероятно, речь о нескольких независимых пользователях одновременно.

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

# Базовый поиск
grep -i "podsync" /var/log/nginx/access.log

# Топ URL, которые вычитывает бот
grep -i "podsync" /var/log/nginx/access.log | awk '{print $7}' | sort | uniq -c | sort -rn | head

# Топ IP за этим UA
grep -i "podsync" /var/log/nginx/access.log | awk '{print $1}' | sort | uniq -c | sort -rn | head

# Суточная активность
grep -i "podsync" /var/log/nginx/access.log | awk '{print $4}' | cut -d: -f1 | sort | uniq -c

Верификация

Подделать User-Agent может любой скрипт. Для решения allow/deny смотрите связку: UA + ASN/IP + частоту + набор URL. Поскольку официального списка IP в принципе не существует, разброс адресов под этим UA — не аномалия, а норма: это разные люди с разными личными серверами.

IP="1.2.3.4"
whois -h whois.cymru.com " -v $IP"
dig +short -x "$IP"

robots.txt для Podsync

# Жёсткий запрет
User-agent: podsync
Disallow: /

# Разрешить всё
User-agent: podsync
Allow: /

# Компромисс: закрыть служебные разделы, оставить публичку
User-agent: podsync
Disallow: /admin/
Disallow: /cart/
Disallow: /checkout/
Disallow: /account/
Disallow: /api/
Allow: /

Важно: Disallow/403 для podsync, если пользы нет. Поскольку соблюдение robots.txt зависит от того, как конкретный пользователь настроил свою инсталляцию, единой гарантии здесь не существует. Если агент игнорирует robots.txt, переходите к nginx/Apache или запрету в TrafficVeil.

Блокировка вручную и через TrafficVeil

Nginx

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

limit_req_zone $binary_remote_addr zone=podsync:10m rate=10r/m;
location / {
    if ($http_user_agent ~* "podsync") {
        limit_req zone=podsync burst=20 nodelay;
    }
}

Apache (.htaccess)

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

TrafficVeil

• Найдите podsync / Podsync в ботах домена или в /system/bots
• Для нежелательного сценария — категория «запретить»; для мягкого — rate-limit
• Allow только при явной пользе от Podsync — например, если сайт сам заинтересован в том, чтобы контент попадал в подкаст-плееры пользователей
• После изменения сверьте логи: хиты Podsync должны уйти в блок/лимит, а нужные поисковики остаться

Рекомендации: что делать с Podsync

• Если пользы нет — Disallow/403 для podsync, критичных потерь для большинства сайтов не будет
• Если польза есть (аудитория конвертирует видео/аудио-контент вашего сайта в подкасты для личного прослушивания) — Allow только при явной пользе от Podsync
• Если нагрузка мешает — сначала rate-limit, затем полный запрет
• Не режьте слишком широко User-agent: *, чтобы случайно не закрыть Googlebot/YandexBot
• Что будет при блокировке: обычно ничего критичного для SEO не теряете, если это не поисковик и не ваш сервисный агент — теряется только удобство для отдельных пользователей, конвертирующих контент в подкаст-формат