Налаштування DDoS-Guard для 1С-Бітрікс: реальний IP, SSL, кеш

Налаштування DDoS-Guard для магазину на Бітрікс: уникаємо помилок

Після підключення DDoS-Guard до магазину на 1С-Бітрікс клієнти з регіонів раптом почали бачити Москву як місто доставки, а обмін з 1С перестав проходити. SSL редиректи зациклюються, статистика показує всіх відвідувачів з однієї IP, а композитний кеш працює нестабільно. Типова картина, яку ми бачимо у нових клієнтів. Тільки за останні пів року до нас звернулися 18 компаній з такими симптомами. Без коректного налаштування заголовків X-Forwarded-For та X-Forwarded-Proto втрата точності геолокації досягає 100%, а помилки обміну з 1С обходяться бізнесу в середньому 25 000 гривень на місяць. За кілька років ми провели понад 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 — перший у списку.

1. Відредагуйте /bitrix/php_interface/dbconn.php.
2. Додайте код перед підключенням ядра:

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

3. Закрийте прямий доступ до сервера — дозвольте тільки IP-діапазони DDoS-Guard у фаєрволі. Актуальні діапазони публікуються в документації DDoS-Guard та через DNS-запит до _origin.ddos-guard.net. — Документація DDoS-Guard
4. Перевірте, що заголовок 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»).

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

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

Модуль sale використовує геолокацію для автоматичного визначення міста доставки. Без виправлення IP дилер із Бреста побачить «Москва» в полі міста при оформленні замовлення. За нашими даними, це призводить до помилок доставки в 30% замовлень — після налаштування точність міста досягає 95%.

Моніторинг та налагодження

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

Що входить у нашу роботу

Під ключ: аудит поточної конфігурації, налаштування визначення реального IP, SSL, фаєрвола, виключення IP 1С та платіжних систем, тестування, документація, навчання адміністратора. Досвід — 5+ років, понад 80 проектів на Бітрікс. Гарантуємо стабільну роботу після інтеграції.

Строки

Потрібна допомога? Зв'яжіться з нами, щоб обговорити ваш проект.