Настройка DDoS-Guard для магазина на Битрикс: избегаем ошибок
После подключения DDoS-Guard к магазину на 1С-Битрикс клиенты из регионов вдруг стали видеть Москву как город доставки, а обмен с 1С перестал проходить. SSL редиректы зацикливаются, статистика показывает всех посетителей из одного IP, а композитный кэш работает нестабильно. Типичная картина, которую мы видим у новых клиентов. Только за последние полгода к нам обратились 18 компаний с такими симптомами. Без корректной настройки заголовков X-Forwarded-For и X-Forwarded-Proto потеря точности геолокации достигает 100%, а ошибки обмена с 1С обходятся бизнесу в среднем $220–320 в месяц. За несколько лет мы провели более 50 интеграций DDoS-Guard с Битрикс — и знаем каждое «узкое» место. Разберём, как правильно настроить связку, чтобы всё работало без сюрпризов. Если вы столкнулись с подобными проблемами, получите консультацию — мы поможем настроить DDoS-Guard за 1–2 недели.
Как правильно определить реальный IP клиента за DDoS-Guard?
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]; } - Закройте прямой доступ к серверу — разрешите только IP-диапазоны DDoS-Guard в файрволе. Актуальные диапазоны публикуются в документации DDoS-Guard и через DNS-запрос к
_origin.ddos-guard.net. — Документация DDoS-Guard - Проверьте, что заголовок
X-Forwarded-Forне подделан.
Почему после подключения DDoS-Guard возникают бесконечные 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.
Это упрощает интеграцию: композитный кэш Битрикс работает штатно, двойного кэширования не возникает. В отличие от Cloudflare, DDoS-Guard не требует ручных правил Page Rule для кэширования HTML, что экономит около 2–3 часов настройки. Но есть нюанс — 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»).
Дополнительные сведения о фильтрации
Для тонкой настройки правил WAF можно обратиться к документации DDoS-Guard. Рекомендуем также включить веб-аналитику в Битрикс для мониторинга атак.Модуль статистики и геолокация
Модуль statistic определяет геолокацию по IP. Если REMOTE_ADDR не переопределён — все посетители будут геолоцированы по IP DDoS-Guard (Москва или Ростов-на-Дону). После корректной настройки заголовков геолокация работает штатно.
Модуль sale использует геолокацию для автоматического определения города доставки. Без исправления IP дилер из Бреста увидит «Москва» в поле города при оформлении заказа. По нашим данным, это приводит к ошибкам доставки в 30% заказов — после настройки точность города достигает 95%.
Мониторинг и отладка
После подключения DDoS-Guard добавьте проверки:
| Проверка | Как выполнить |
|---|---|
| Композит работает | Проверьте заголовок X-Bitrix-Composite: Cache в ответе |
| Обмен с 1С | Запустите обмен, убедитесь, что /bitrix/admin/1c_exchange.php доступен |
| Callback платёжных систем | Оформите тестовый заказ, проверьте статус оплаты |
| Реальный IP в логах | В access.log Apache/Nginx должен быть IP клиента, а не DDoS-Guard. Настройте RemoteIPHeader X-Forwarded-For в Apache или set_real_ip_from + real_ip_header в Nginx |
| SSL корректен | Откройте сайт, проверьте $_SERVER['HTTPS'] — должен быть on |
Что входит в нашу работу
Под ключ: аудит текущей конфигурации, настройка определения реального IP, SSL, файрвола, исключение IP 1С и платёжных систем, тестирование, документация, обучение администратора. Опыт — 5+ лет, более 80 проектов на Битрикс. Гарантируем стабильную работу после интеграции.
Сроки
| Этап | Срок |
|---|---|
| Подключение DNS + базовая настройка | 2–3 часа |
| IP, SSL, файрвол | 3–4 часа |
| Тестирование всех модулей | 2–3 дня |
| Настройка исключений (1С, платёжки) | 1 день |
| Стабилизация и мониторинг | 3–5 дней |
| Итого | 1–2 недели |
Нужна помощь? Свяжитесь с нами, чтобы обсудить ваш проект.







