SFDC-Callout в логах: чья это Salesforce-интеграция

SFDC-Callout стоит отдельного правила в антиботе: это не «ещё один hit» от стороннего краулера, а исходящий HTTP-запрос из платформы Salesforce — но не от самой компании Salesforce как оператора, а от кого-то из десятков тысяч клиентских организаций (org), использующих Salesforce и настроивших интеграцию, которая обращается именно к вашему домену.

1. Что такое SFDC-Callout

SFDC-Callout — это буквальный User-Agent по умолчанию, который платформа Salesforce подставляет при исходящих HTTP-запросах (callouts), инициированных кодом Apex или механизмом Outbound Messaging внутри клиентской Salesforce-организации: workflow-правилом, процессом согласования, Flow или прямым Apex-callout к внешнему API. Реальный вид заголовка, зафиксированный разработчиками Salesforce: User-Agent: SFDC-Callout/18.0, где число — версия API Salesforce, с которой сделан запрос. Ключевая особенность: конкретную клиентскую организацию, которая сделала запрос, снаружи определить невозможно — платформа мультитенантная, и один и тот же UA используют одновременно тысячи независимых друг от друга компаний.

2. Зачем SFDC-Callout приходит на сайт

Появление SFDC-Callout в access.log означает, что чей-то Salesforce-инстанс настроен обращаться к вашему домену — обычно потому, что ваш URL указан как endpoint в интеграции: приём лида, синхронизация данных, вебхук после сделки или заявки. Это может быть (а) ваша собственная интеграция, если компания использует Salesforce; (б) интеграция партнёра или подрядчика, который специально настроил обращение к вашему API; либо (в) случайная или ошибочная конфигурация чужой Salesforce-организации, которая указала ваш URL по ошибке или по устаревшим данным.

• Какие зоны чаще трогает: конкретные API-эндпоинты или webhook-URL, а не публичные страницы сайта вообще — обычный сценарий для callout не предполагает обхода произвольного контента;
• Что ищет: ничего в смысле сбора контента — это исходящий вызов интеграции, обычно с полезной нагрузкой (данными) в теле запроса, а не пассивное чтение страницы;
• Чем отличается от браузерного пользователя: нет нормальной сессии, запрос обычно строго целевой — к одному заданному URL, а не к произвольным разделам сайта.

Типичный кейс: CDN-трафик дорожает, origin CPU нагружен обработкой запросов. Фильтр по sfdc-callout показывает обращения к публичным URL или API — прежде чем ограничивать бота, стоит выяснить, не ваша ли это собственная CRM-интеграция, случайно указывающая на публичный, а не приватный API-путь.

3. Нагрузка и риски именно для SFDC-Callout

Отдельной строки в публичной сводке top-bot TrafficVeil у sfdc-callout может не быть, но в категории «Прочие краулеры и сервисы» такие агенты дают характерный фон: фоновый шум в аналитике, расход CPU/bandwidth и искажение статистики «живого» трафика. Практический риск здесь специфический: поскольку это не краулер, а вызов интеграции, чаще всего с полезной нагрузкой (данными о лиде, заказе, форме), полная блокировка может незаметно сломать чью-то реальную бизнес-интеграцию — в том числе вашу собственную, если она давно настроена и о ней забыли.

4. Как найти SFDC-Callout в логах

Не ищите «просто ботов» — ищите конкретный токен sfdc-callout и обязательно смотрите, к каким именно URL идут запросы и с каким методом (GET/POST) и телом.

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

# Топ URL, к которым обращается callout
grep -i "sfdc-callout" /var/log/nginx/access.log | awk '{print $7}' | sort | uniq -c | sort -rn | head

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

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

# Проверить метод запроса — callout чаще POST с данными, а не GET
grep -i "sfdc-callout" /var/log/nginx/access.log | awk '{print $6}' | sort | uniq -c

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

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

5. robots.txt для SFDC-Callout

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

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

Важно: robots.txt здесь работает слабо по самой природе callout — это не краулер, который обходит сайт и сверяется с правилами, а прямой целевой вызов конкретного endpoint, инициированный чужой автоматизацией. Управлять доступом эффективнее через аутентификацию самого API-эндпоинта или через правила на уровне сервера/TrafficVeil, а не через robots.txt.

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

Nginx

if ($http_user_agent ~* "sfdc-callout") {
    return 403;
}

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

Apache (.htaccess)

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

TrafficVeil

• Найдите sfdc-callout в ботах домена или в /system/bots;
• Прежде чем блокировать — проверьте у команды, не используется ли Salesforce как CRM с настроенной интеграцией именно на этот URL;
• Если источник неизвестен и запросы бьют в публичные, не предназначенные для интеграций разделы — категория «запретить»;
• Если это ваша интеграция — Allow, дополнительно защитив сам endpoint аутентификацией, а не полагаясь на allow/deny по UA;
• После изменения сверьте логи и убедитесь, что ни одна реальная бизнес-интеграция не сломалась.

7. Рекомендации: что делать с SFDC-Callout

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

8. С кем не путать SFDC-Callout

9. Стратегия allow/deny для SFDC-Callout