Інтеграція 1С-Bitrix з Cloudflare
1С-Bitrix історично розраховується на прямий зв'язок клієнта з сервером. При розташуванні за Cloudflare ломається визначення IP користувача, перестає працювати проактивний захист, композитний кеш конфліктує з CDN-кешем, а модуль security почина банити IP-адреси Cloudflare замість реальних відвідувачів. Інтеграція — це не «підключити DNS й забути», а системна настройка обох сторін.
Проблема визначення IP
Cloudflare проксирує трафік, підставляючи свій IP в REMOTE_ADDR. Реальний IP клієнта передається у заголовку CF-Connecting-IP. Bitrix використовує $_SERVER['REMOTE_ADDR'] повсюдно: у модулі security (проактивний фільтр, WAF), у модулі statistic (статистика відвідувань), у модулі sale (геолокація для доставки).
Рішення — у файлі dbconn.php (або /bitrix/.settings.php) перевизначити REMOTE_ADDR:
if (isset($_SERVER['HTTP_CF_CONNECTING_IP'])) {
$_SERVER['REMOTE_ADDR'] = $_SERVER['HTTP_CF_CONNECTING_IP'];
}
Цей код повинен виконуватися до підключення ядра Bitrix. Розташовуйте його на самому початку /bitrix/php_interface/dbconn.php.
Безпека: перевіряйте, що запит дійсно прийшов від Cloudflare. Список IP-діапазонів Cloudflare доступний за адресою https://www.cloudflare.com/ips-v4. Якщо сервер приймає прямі підключення в обхід Cloudflare, зловмисник може підробити заголовок CF-Connecting-IP. Закрийте порти 80/443 для всіх IP, крім діапазонів Cloudflare, на рівні файрвола.
Конфлікт кешів: композит vs. Cloudflare
Композитний кеш Bitrix (composite) відає HTML-знімок сторінки без виконання PHP. Cloudflare Cache теж кешує HTML. Виходить подвійне кешування з різними правилами інвалідації — сторінка оновлюється в Bitrix, але Cloudflare продовжує відавати стару версію.
Варіанти рішення:
Варіант 1: Вимкнути кешування HTML в Cloudflare. У Page Rules задайте Cache Level: Bypass для *.php та динамічних сторінок. Cloudflare буде кешувати тільки статику (JS, CSS, зображення). Композит Bitrix працює штатно. Це рекомендований підхід для більшості проектів.
Варіант 2: Вимкнути композит, кешувати в Cloudflare. Підходить для інформаційних сайтів з рідким оновленням. Настройте Edge Cache TTL у Cloudflare й використовуйте Cloudflare API для скидання кешу при оновленні контенту. Виклич POST /zones/{zone_id}/purge_cache з обробника OnAfterIBlockElementUpdate.
Варіант 3: Комбінований. Композит працює для авторизованих (не кешується в Cloudflare), Cloudflare кешує сторінки для анонімів. Розділення через Cache-Control: private для авторизованих та Cache-Control: public, max-age=300 для анонімів. Заголовки виставляються у init.php на основі $USER->IsAuthorized().
Настройка SSL
Cloudflare пропонує три режими SSL: Flexible, Full, Full (Strict). Для Bitrix єдиний правильний варіант — Full (Strict) з валідним сертифікатом на сервері.
При Flexible-режимі Cloudflare підключається до сервера по HTTP. Bitrix не знає, що клієнт прийшов по HTTPS. Заголовок X-Forwarded-Proto: https передається Cloudflare, але Bitrix його не перевіряє за замовчуванням. Результат: нескінченні редиректи при включеному «Перенаправленню на HTTPS» в налаштуваннях, або смішаний вміст, або форми відправляються по HTTP.
Якщо Full (Strict) неможливий (немає сертифікату на сервері), використовуйте Cloudflare Origin Certificate — безплатний сертифікат, що працює тільки при проксируванні через Cloudflare.
Проактивний захист та WAF
Модуль security Bitrix містить власний WAF. При роботі через Cloudflare обидва WAF активні одночасно. Конфлікти:
- Cloudflare WAF блокує запит, Bitrix пише в лог помилку 403 без деталей — незрозуміло, хто заблокував.
- Правила Cloudflare та Bitrix можуть суперечити — Cloudflare пропускає запит, Bitrix блокує, або навпаки.
Рекомендація: використовуйте Cloudflare WAF як перший рубіж (блокування ботів, DDoS, відомих атак), а проактивний фільтр Bitrix — як другий (специфічні для CMS атаки). Не вимикайте жоден з них повністю.
Терміни настройки
| Задача | Термін |
|---|---|
| DNS, SSL, базова настройка | 2–3 години |
| Перевизначення IP + файрвол | 2–3 години |
| Настройка кешування (Page Rules, композит) | 1 день |
| WAF: узгодження правил | 1–2 дні |
| Тестування (кошик, авторизація, форми, ЛК) | 2–3 дні |
| Моніторинг першу тиждень | фоново |
| Усього | 1–2 тижні |
Окремо враховуйте тестування інтеграцій: платіжні системи, callback-сповіщення від ERIP або банків, webhooks від 1С. Усі вони звертаються до сервера напрямку, й якщо порти закриті для не-Cloudflare IP — сповіщення перестану приходити. Для callback-URL додайте виключення у файрвол або використовуйте окремий поддомен без проксирування.