Интеграция 1С-Битрикс с DDoS-Guard

Интеграция 1С-Битрикс с DDoS-Guard

DDoS-Guard — CDN и anti-DDoS-сервис, популярный в СНГ из-за серверов в Москве и приемлемой цены. Как и любой reverse proxy, он ломает стандартное поведение Битрикс: IP-адреса, SSL-терминацию, работу модулей security и statistic. Отличие от Cloudflare — в деталях: другой заголовок для реального IP, другие IP-диапазоны, другая логика кэширования. Разберём специфику.

Определение реального IP клиента

DDoS-Guard передаёт IP клиента в заголовке X-Forwarded-For. В отличие от Cloudflare (который шлёт CF-Connecting-IP — один IP), X-Forwarded-For может содержать цепочку адресов: клиент, прокси1, прокси2. Реальный IP — первый в списке.

В /bitrix/php_interface/dbconn.php добавьте до подключения ядра:

if (isset($_SERVER['HTTP_X_FORWARDED_FOR'])) {
    $ips = array_map('trim', explode(',', $_SERVER['HTTP_X_FORWARDED_FOR']));
    $_SERVER['REMOTE_ADDR'] = $ips[0];
}

Проблема подмены: заголовок X-Forwarded-For может быть подделан, если сервер принимает подключения в обход DDoS-Guard. Обязательно закройте прямой доступ к серверу — только IP-диапазоны DDoS-Guard в файрволе. Актуальные диапазоны публикуются в документации DDoS-Guard и через DNS-запрос к _origin.ddos-guard.net.

SSL и редиректы

DDoS-Guard терминирует SSL на своей стороне и может подключаться к origin-серверу по HTTP (режим «Гибкий SSL») или HTTPS (режим «Полный SSL»).

При гибком SSL Битрикс не знает, что клиент пришёл по HTTPS. Заголовок X-Forwarded-Proto: https передаётся DDoS-Guard, но Битрикс его не проверяет по умолчанию. Добавьте в dbconn.php:

if (isset($_SERVER['HTTP_X_FORWARDED_PROTO'])
    && $_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https') {
    $_SERVER['HTTPS'] = 'on';
}

Без этой настройки: бесконечный цикл редиректов при включённом «Перенаправлении на HTTPS» в админке, mixed content на страницах, формы отправляются по HTTP.

Кэширование: отличия от Cloudflare

DDoS-Guard кэширует статику (JS, CSS, изображения) автоматически. HTML по умолчанию не кэшируется — в отличие от Cloudflare, где нужно явно отключать кэш для PHP.

Это упрощает интеграцию: композитный кэш Битрикс работает штатно, двойного кэширования не возникает. Но есть нюанс — DDoS-Guard кэширует статику агрессивно, и после обновления JS/CSS-файлов пользователи могут получать старые версии.

Решения:

• Версионирование файлов — Битрикс добавляет ?v=timestamp к подключаемым файлам автоматически, если используется \Bitrix\Main\Page\Asset. Проверьте, что кастомные шаблоны тоже это делают.
• Purge-кэш через API DDoS-Guard — после деплоя вызывайте API для сброса кэша конкретных ресурсов или всего домена.

Проактивная защита и Web Application Firewall

DDoS-Guard фильтрует L3/L4-атаки (SYN-flood, UDP-flood) и часть L7-атак (HTTP-flood). Но WAF-правила DDoS-Guard менее гранулярные, чем у Cloudflare. Проактивный фильтр Битрикс остаётся важным рубежом.

Типичная проблема: DDoS-Guard при сильной атаке включает JavaScript Challenge — страницу-проверку, которая отсеивает ботов. Если на сайт обращается 1С (обмен данными по HTTP) или платёжная система (callback) — они не пройдут JS Challenge. Исключите IP-адреса 1С-сервера и платёжных шлюзов из проверки через настройки DDoS-Guard («Белый список IP»).

Модуль статистики и геолокация

Модуль statistic определяет геолокацию по IP. Если REMOTE_ADDR не переопределён — все посетители будут геолоцированы по IP DDoS-Guard (Москва или Ростов-на-Дону). После корректной настройки заголовков геолокация работает штатно.

Модуль sale использует геолокацию для автоматического определения города доставки. Без исправления IP дилер из Бреста увидит «Москва» в поле города при оформлении заказа.

Мониторинг и отладка

После подключения DDoS-Guard добавьте проверки:

Сроки