Cloudflare перед сайтом: коли допомагає, а коли ламає

Коротка відповідь

Cloudflare - це проксі між відвідувачем і вашим сервером. Він корисний, коли треба віддати статику ближче до людини, відсіяти ботів і не світити адресу сервера. Шкодить він тоді, коли його налаштовують «на всі галочки» без розуміння, що кожна з них робить. П'ять налаштувань, які вирішують майже все:

1. Режим SSL - Full (strict). Не Flexible: з ним на сервер іде незашифрований запит і легко отримати петлю редиректів.
2. Кеш HTML - тільки з винятками. «Кешувати все» без виключення кошика, кабінету й адмінки означає, що один відвідувач побачить сторінку іншого.
3. Rocket Loader - вимкнути, поки не перевірили, що після нього працюють форми, слайдери й платіжний віджет.
4. Пошта, FTP і панель - на сірій хмарці. Проксі Cloudflare пропускає тільки веб-трафік.
5. Under Attack і Bot Fight Mode - лише на час атаки. Вони блокують не тільки ботів, а й платіжні сервіси, які стукають на сайт із підтвердженням оплати.

Що Cloudflare робить насправді

Коли запис домену в Cloudflare стоїть із помаранчевою хмаркою, браузер відвідувача з'єднується не з вашим сервером, а з найближчим вузлом Cloudflare. Той приймає HTTPS, дивиться, чи є в нього готова копія файлу, і тільки якщо немає - іде на ваш сервер. Сіра хмарка означає «лише DNS»: Cloudflare повідомляє IP, а далі відвідувач іде напряму, і жодні налаштування проксі на цей запис не діють.

Звідси головне обмеження. Cloudflare не змінює того, що відбувається на сервері. Якщо WordPress генерує сторінку за 900 мс, він генеруватиме її 900 мс і за проксі - виграш буде тільки на картинках, стилях і скриптах. Докладно про те, який фактор скільки дає, я розбирав у статті про NVMe, PHP 8.3 і кеш, тут - саме про налаштування і про те, що вони ламають.

1. Коли Cloudflare реально допомагає

Є чотири ситуації, де він окупає будь-які незручності:

• Важка статика і відвідувачі далеко від сервера. Каталог на 60 фото товарів, відкритий із Харкова, коли сервер у Франції: картинки прийдуть із вузла у Варшаві чи Відні, а не пройдуть увесь шлях.
• Сміттєвий трафік. Перебір паролів до wp-login.php, сканери вразливостей, парсери цін. Частину цього Cloudflare відсікає ще до того, як запит з'їсть процесор вашого тарифу. На тарифі Старт з 1 ядром це помітно: сотня запитів ботів на хвилину - це вже черга для живих людей.
• DDoS на рівні мережі. Флуд у кілька гігабіт один сервер не витримає фізично, Cloudflare розмазує його по своїй мережі.
• Прихована адреса сервера. Атакувати напряму важче, коли IP невідомий. Але про це - з застереженням у розділі про пошту.

Якщо ж у вас лендінг на 300 КБ, аудиторія в Україні і трафік у кілька сотень відвідувань на добу, різницю у швидкості ви навряд чи побачите. Користь буде в захисті, не в мілісекундах.

2. SSL: Flexible - перше, що ламається

У Cloudflare є три осмислені режими шифрування між його вузлом і вашим сервером:

• Flexible - відвідувач бачить https, а до сервера Cloudflare ходить по звичайному http. Дані на цьому відрізку йдуть відкритим текстом.
• Full - до сервера теж https, але сертифікат не перевіряється.
• Full (strict) - https із перевіркою, що сертифікат на сервері дійсний і виданий на ваш домен.

Flexible придумали для серверів, де SSL немає зовсім. На хостингу з безкоштовним Let's Encrypt він не потрібен і лише створює проблеми: сайт вважає, що до нього прийшли по http, і перенаправляє на https, Cloudflare знову йде по http - і браузер показує ERR_TOO_MANY_REDIRECTS. Як розплутати цю петлю в .htaccess, я показував у статті про змішаний контент.

Правильний порядок: спочатку переконатися, що на сервері є чинний сертифікат для домену і для www, потім у розділі SSL/TLS виставити Full (strict). Якщо сертифікат на сервері прострочений, Cloudflare покаже помилку 526 - це сигнал, що Let's Encrypt не поновився, а не що «Cloudflare зламався».

3. Кеш сторінок: де він віддає чуже

За замовчуванням Cloudflare кешує файли за розширенням - картинки, CSS, JS, шрифти, - а HTML щоразу бере з сервера. Це безпечно. Небезпечно стає, коли в правилах кешування (Cache Rules) вмикають кешування всього підряд, щоб отримати «зелений PageSpeed».

Що тоді відбувається на магазині: покупець додав товар у кошик, сторінку з кошиком закешовано, наступний відвідувач відкриває ту саму адресу і бачить чужий кошик. Із кабінетом гірше - там ім'я, телефон, адреса доставки. Тому якщо кешуєте HTML, в правилі мають бути винятки: адмінка (/wp-admin/, /admin/), кошик, оформлення, кабінет і всі запити з cookie авторизації. Без цих винятків таке правило не вмикайте взагалі.

Друга типова скарга - «я змінив сторінку, а на сайті стара». Cloudflare віддає свою копію, поки не мине її термін. Лікується кнопкою Purge Everything у розділі Caching або режимом Development Mode: він на 3 години вимикає кеш для всієї зони і сам вимикається.

4. Rocket Loader і оптимізації, які ламають скрипти

Rocket Loader переписує порядок завантаження JavaScript: відкладає всі скрипти на потім. На простому блозі це дає кілька балів у PageSpeed Insights. На сайті, де скрипт форми, слайдера чи платіжного віджета чекає jQuery, він регулярно ламає поведінку: кнопка «Купити» не реагує, форма зворотного зв'язку не відправляється, банер cookie не закривається. Помилки при цьому видно лише в консолі браузера, тож власник дізнається від клієнтів.

Моє правило: Rocket Loader вимкнений, поки ви вручну не пройшли з ним ключові сценарії - замовлення, форму, логін. У старих інструкціях ще радять Auto Minify, але Cloudflare прибрав цю функцію у 2024 році, шукати її в панелі немає сенсу.

5. Пошта, FTP і панель: що не проходить через проксі

Проксі Cloudflare пропускає тільки HTTP і HTTPS на певних портах: 80 і 443, плюс кілька службових на кшталт 8443 і 2083. Усе інше через помаранчеву хмарку не пройде. На практиці це означає:

• запис mail, на який вказує MX, має бути сірим - інакше пошта на домен перестане приходити;
• FTP-клієнт, налаштований на ім'я домену, не з'єднається - потрібен сірий запис для FTP або підключення за IP;
• DirectAdmin на порту 2222 через проксійований домен не відкриється - заходьте за адресою з листа про замовлення.

І застереження про приховану адресу: якщо поштовий запис сірий і вказує на той самий сервер, IP видно в DNS кожному. Для звичайного сайту це нормально, для проєкту, який реально атакують, пошту варто винести на окремий сервіс.

6. Реальний IP відвідувача і захист, який б'є по своїх

За проксі сервер бачить не адресу відвідувача, а адресу вузла Cloudflare. Якщо це не врахувати, в логах будуть одні й ті самі IP, а захист від перебору паролів заблокує вузол Cloudflare - тобто разом із ботом усіх відвідувачів із того регіону. На моїх серверах це вирішено на рівні Apache: прописані всі 22 діапазони адрес Cloudflare, і з них сервер бере справжній IP із заголовка. У логах і в плагінах безпеки ви бачите адресу людини, а не проксі.

Другий бік - режими Under Attack і Bot Fight Mode. Перший показує кожному відвідувачу перевірку в браузері, другий відсікає автоматичні запити. Людина перевірку пройде, а сервер платіжної системи - ні. Результат: гроші списані, а замовлення висить «очікує оплати», бо підтвердження від LiqPay, WayForPay чи Monobank не дійшло до сайту. Bot Fight Mode на безкоштовному плані не можна вимкнути для окремої адреси, тому на магазині з онлайн-оплатою я його не вмикаю, а Under Attack тримаю лише поки йде атака.

7. Налаштування, з яких варто почати

Для типового сайту на WordPress, OpenCart чи PrestaShop на хостингу з Let's Encrypt:

Кеш HTML у цьому списку свідомо відсутній. Для WordPress правильніше поставити плагін кешування на самому сайті: він знає, хто залогінений, а Cloudflare - ні.

Якщо після Cloudflare щось зламалось

Більшість проблем впізнається за першим симптомом. Звірте з таблицею, перш ніж вимикати Cloudflare повністю:

Швидкий тест, чи домен узагалі йде через Cloudflare: curl -sI https://ваш-домен | grep -i server. Якщо у відповіді server: cloudflare - проксі працює. Якщо симптом не з таблиці або кілька збіглися одночасно, напишіть у підтримку в Telegram з адресою сторінки і часом, коли почалось: по логах сервера видно, чи запит узагалі дійшов від Cloudflare.

Як це влаштовано в Hosturm

Cloudflare заявлений у всіх шести планах, від Старту за 142 грн/міс при річній оплаті (479 грн/міс помісячно) до виділеного VPS Максимум за 1990 грн/міс. Чесно про межі: це безкоштовний план Cloudflare, платних функцій на кшталт APO для WordPress чи розширених правил фаєрвола в тарифі немає. Те, що залежить від сервера, вже зроблено: справжній IP відвідувача відновлюється, Let's Encrypt видається для кожного домену, тож Full (strict) можна вмикати одразу, статика віддається стисненою з кешем на рік. Решту - кеш HTML, Rocket Loader, режими захисту - ви вмикаєте свідомо під свій сайт. Ресурси всіх планів поруч зібрані на сторінці хостингу, а замовлення починається з тарифів на головній.

Коротко

Cloudflare - корисний шар захисту і доставки статики, але не прискорювач повільного сайту. Ламає він сайт майже завжди одними й тими самими налаштуваннями: Flexible замість Full (strict), кеш HTML без винятків, Rocket Loader і режими захисту, увімкнені «про всяк випадок». Якщо тримати ці чотири речі під контролем, а пошту й FTP - на сірій хмарці, Cloudflare перед сайтом працює непомітно, як і має. А якщо сайт повільний і за Cloudflare, причину варто шукати на сервері - з цього починається перевірка за 20 хвилин.