Як підключити вебсайт до Cloudflare

Як підключити вебсайт до Cloudflare

Cloudflare може працювати перед вебсайтом двома дуже різними способами. Ви можете перевести весь домен на DNS і проксування Cloudflare або залишити вузьке налаштування й увімкнути лише одну функцію за раз. Від цього залежить і порядок дій, і ризик, і план відкату.

Почніть саме з цього. Маркетинговий сайт із кількома сторінками має інші потреби, ніж корпоративний домен із великою кількістю пошти, а домен, на якому вже працює компанійський сайт, потребує обережнішої роботи з записами, ніж новий запуск. Якщо ви також думаєте про безпеку вебсайту, Cloudflare часто з’являється в розмові саме з цієї причини.

1. Визначте, чи потрібен вам повний контроль DNS, чи лише одна функція Cloudflare

Cloudflare — це не один простий перемикач. Він може керувати DNS, проксувати вебтрафік, кешувати вміст, фільтрувати запити та стояти між відвідувачами і вашим origin-сервером. Якщо вам потрібна лише одна функція, наприклад керування DNS або рівень захисту, все одно варто розуміти, що зазвичай саме nameservers домену — це точка, у якій Cloudflare бере контроль на себе.

Для простого сайту-візитівки повний контроль часто підходить без проблем. Для схеми з маршрутизацією пошти, сервісами підтвердження та кількома піддоменами рішення вже значно критичніше. Приватна мережева інфраструктура, наприклад, може вимагати, щоб певні імена хостів не проходили через проксі, тоді як вебсторінки можуть працювати через Cloudflare без ускладнень.

Поставте собі одне практичне запитання: що має працювати в перший день за будь-яких умов? Якщо у відповіді є email, API callback або платіжний процес, ви не просто “підключаєте сайт до Cloudflare”; ви змінюєте спосіб, у який домен резолвиться. Ця різниця має значення.

Коротке правило таке: не здогадуйтеся. Якщо сайт залежить від будь-якого сервісу поза вебсервером, занотуйте його ще до того, як торкнетеся nameservers. Цей список стане вашим запасним варіантом безпеки.

2. Перевірте поточну конфігурацію домену перед зміною nameservers

Перш ніж щось переносити, перевірте, де зараз керується DNS. Реєстратор і DNS-хост не завжди одна й та сама компанія, і така невідповідність призводить до зайвих помилок. Знайдіть поточні nameservers, а потім перегляньте записи зони, які там уже існують.

Вам потрібна повна картина: записи A та AAAA для сайту, CNAME для піддоменів, MX для пошти, TXT для підтвердження, а також будь-які нестандартні записи, які використовують сторонні інструменти. Відсутній TXT-запис може зламати процес входу. Неправильний MX-запис може зупинити пошту.

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

Це також момент, щоб занотувати редиректи та старі hostnames. Якщо трафік досі приходить на старий піддомен, зафіксуйте це зараз. Редирект, який працює на origin, може зламатися пізніше, якщо hostname не буде перенесено в Cloudflare.

Збережіть одну копію поточної зони поза обліковим записом реєстратора. Звичайного текстового файла достатньо. Таблиці теж підійдуть. Головне — мати можливість відновлення.

3. Додайте сайт у Cloudflare та імпортуйте наявні DNS-записи

Після аудиту додайте домен у Cloudflare. Cloudflare просканує наявні DNS-записи та спробує імпортувати їх у свою зону. Це економить час, але не гарантує, що все перенеслося без помилок. Саме тут особливо важливе налаштування DNS Cloudflare, бо від нього залежить, чи правильно працюватимуть усі записи після імпорту.

Перевірте імпортовані записи рядок за рядком. Якийсь запис може бути відсутній, піддомен — дублюватися, а значення — бути застарілим. Перший прохід має бути про точність, а не про швидкість. Якщо бачите hostname, який має вести на ваш вебсервер, але тепер вказує кудись іще, виправте це до того, як торкнетеся реєстратора.

Дві невеликі перевірки ловлять багато помилок. По-перше, порівняйте імпортовані записи зі своїм списком аудиту. По-друге, переконайтеся, що apex-домен і типовий hostname “www” обидва резолвляться куди треба. Саме ці записи користувачі відкриватимуть першими.

Якщо ви керуєте сайтом, який поводиться як корпоративний вебсайт, уважно стежте за піддоменами. Портал підтримки, staging-хост і файловий хост часто існують поруч із головним сайтом, і одного відсутнього запису може бути достатньо для складного збою, який важко діагностувати.

Невелике практичне зауваження: імпорт Cloudflare корисний, але це не привід пропускати власну перевірку. Скан — це лише старт. Ваш аудит — фінальна перевірка.

4. Виберіть, які записи мають залишатися через проксі, а які — лише DNS

Cloudflare дає вам вибір для багатьох записів. Помаранчева хмарка означає, що трафік іде через проксі Cloudflare. Сіра хмарка означає лише DNS. Це не косметична різниця. Вона змінює маршрут запитів.

Вебтрафік публічного сайту часто проксується. Поштові записи — ні. Записи підтвердження — ні. Деякі піддомени, що обслуговують API або спеціалізовані інструменти, також мають залишатися DNS-only, якщо ви не протестували повний шлях дуже уважно. Якщо потрібне просте правило, проксуйте сайт, а нефункції web-рівня залишайте без змін, якщо немає вагомої причини міняти їх.

Поширена помилка — проксувати все, бо так акуратно виглядає. Надовго акуратним це не залишається. MX-запис за проксі зламається. Hostname для підтвердження може перестати розпізнаватися іншою службою. Точка передавання файлів може поводитися дивно, бо вона ніколи не мала проходити через вебпроксі.

Думайте про функцію, а не про зовнішній вигляд. Сайт можна проксувати заради продуктивності та безпеки. Пошта зазвичай має залишатися DNS-only. Якщо у вашій схемі є tracking pixels, webhook endpoints або сторонні хости підтвердження, тестуйте кожен окремо.

Трафік, який має залишатися звичайним DNS, часто є саме тим трафіком, який ви найменше хочете зламати. Пам’ятайте це, перш ніж занадто часто натискати на помаранчеву хмарку.

5. Оновіть nameservers домену у реєстратора

Cloudflare призначить для домену два nameservers. Ви замінюєте поточні nameservers у реєстратора на ці два значення. Це крок, який передає повноваження над DNS до Cloudflare, тож копіюйте їх точно так, як показано. Якщо потрібно, спочатку відкрийте коротку інструкцію про як змінити nameservers на Cloudflare, щоб не пропустити жодного поля.

У реєстратора знайдіть розділ nameserver і видаліть стару пару. Потім введіть пару, яку призначив Cloudflare. Збережіть зміни.

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

Одне коротке речення тут: будьте точними. Одна неправильна літера у записі nameserver може зламати делегування.

Також не змінюйте надто багато рухомих частин одночасно. Якщо ви перейменовуєте записи, міняєте хостинг і редагуєте nameservers за один підхід, діагностика стає значно складнішою, ніж має бути.

6. Переконайтеся, що домен активний у Cloudflare, і протестуйте реальні шляхи трафіку

Після зміни nameservers Cloudflare має показати домен як активний. Якщо цього не сталося, зазвичай проблема в одному з трьох: зміну у реєстратора не зберегли, nameservers внесли неправильно або реєстратор ще тримає кешовані дані. Перевірте це перед тим, як звинувачувати origin-сервер.

Потім тестуйте реальні шляхи, а не лише головну сторінку. Відкрийте основний домен, версію “www”, важливу підсторінку та будь-які критично важливі піддомени. Якщо на сайті є сторінка входу, протестуйте й її. Якщо є завантаження файлів або відправка форми, перевірте і ці дії. Сторінки можуть завантажуватися, поки прихована кінцева точка вже зламана.

Тут допомагає інструмент моніторингу. Якщо ви використовуєте платформу аналітики та моніторингу вебсайту, порівняйте перші живі запити після перемикання зі звичною картиною. Раптове зростання помилок на одному hostname часто є першою ознакою того, що DNS-запис або налаштування проксі потребують уваги.

Для чистого тесту використовуйте інший браузер або приватне вікно. Кешовані дані можуть приховати проблеми. Так само як і стара сесія входу.

Якщо щось не працює, перевіряйте шлях від домену назовні: DNS, edge-відповідь, відповідь origin, а потім логіку застосунку. Така послідовність економить час.

7. Увімкніть перші безпечні налаштування Cloudflare для нового підключення

Коли домен стане активним, залишайте перші налаштування консервативними. Оберіть режим SSL/TLS, який відповідає тому, що ваш origin реально підтримує, і не здогадуйтеся. Якщо сертифікат на origin ще не готовий, браузер може показувати помилки або Cloudflare може відмовити в з’єднанні. На день запуску це дуже поганий сюрприз.

Наступним кроком мають бути базові налаштування безпеки. Якщо для вас уже важлива безпека вебсайту, саме тут Cloudflare починає допомагати не лише на рівні DNS. Почніть із очевидних контролів, а потім знову протестуйте сайт. Агресивні зміни можуть почекати, доки ви не переконаєтеся, що базова схема працює правильно.

Поведінка кешу теж заслуговує на обережний перший погляд. Сторінка, яка часто змінюється, не повинна оброблятися так само, як сторінка, що майже не змінюється. Якщо не впевнені, спочатку залиште стандартну поведінку, поспостерігайте, як реагує сайт, а потім вносьте зміни по одному.

Корисна звичка — розділяти “безпечне зараз” і “корисне пізніше”. Безпечне зараз — це правильно налаштувати SSL-шлях і переконатися, що сайт усе ще відкривається. Корисне пізніше — це налаштування cache headers або посилення правил, коли у вас уже є логи для аналізу. Така послідовність запобігає збоям, які ви створили самі.

На цьому етапі тримайте все маленьким. Невеликі зміни легше відкотити.

8. Перевірте крайові випадки: email, піддомени, редиректи та проблеми змішаного вмісту

Саме тут багато сайтів спотикаються. Пошта зазвичай залежить від DNS-записів, які мають залишатися лише DNS-only. Переконайтеся, що MX-записи все ще вказують на правильний поштовий хост і що TXT-записи SPF, DKIM або DMARC збережено. Якщо пошта зупиниться, сайт може виглядати нормально, поки бізнес-повідомлення зникають.

Піддомени заслуговують на окремий чеклист. Staging-хост, хост для зображень і endpoint для завантаження можуть потребувати різного підходу. Якщо один із них помилково проксовано, дивна поведінка може з’явитися лише на цьому єдиному hostname. Такий баг марнує час, бо головна сторінка працює.

Редиректи теж можуть виявити помилки. Якщо старий сайт пересилав відвідувачів з одного hostname на інший, перевірте цей шлях ще раз після перемикання. Ланцюжок редиректів, який раніше працював, тепер може вести на hostname, якого ніколи не додавали в Cloudflare. Один відсутній запис може зламати весь шлях.

Проблеми змішаного вмісту виникають, коли сайт завантажує частину ресурсів через HTTP, тоді як сама сторінка віддається через HTTPS. Браузери не люблять таке поєднання. Зображення можуть зникати, скрипти — ламатися, а форма — перестати надсилатися. Виправляйте джерела URL на рівні застосунку, а не лише в браузері.

Якщо ваш домен забезпечує робочий процес підтримки сайту після запуску, тримайте короткий список найбільш крихких хостів: пошта, staging, завантаження, редиректи та сторонні перевірки. Саме в цих п’яти зонах зазвичай з’являються перші звернення.

Ще одна практична перевірка: відкрийте сайт із мережі, якою ви зазвичай не користуєтеся. Мобільне з’єднання може виявити проблему кешу або затримку DNS, яку ваша офісна мережа приховує. Різні шляхи показують різні проблеми.

І якщо ви підключаєте сайт, який уже має жорсткі операційні вимоги, задокументуйте кожен DNS-запис, який ви чіпали. Не пізніше. Зараз.