Здрастуйте, шановні читачі блогу . Хто не чув про CloudFlare? Я чув і навіть докладно вивчав можливості сервісу років так п’ять тому, напевно (коли замислювався про прискорення сайту). Ось тільки зараз вже не скажу, що саме тоді мене зупинило від того, щоб цей сервіс спробувати (не пам’ятаю). Але це і не важливо.
Важливо те, що в перший робочий день після новорічних свят мені таки довелося підключити до CloudFlare і притому в авральному режимі (з выдиранием волосся, літрами випитої кави і биттям головою об стіл). Зробити це довелося за повного блокування доступу до сайту (швидше за все шляхом Ддос атаки — по FTP доступ був можливий).
З мене адміністратор сервера аховий і за великим рахунком я мало що розумію в тонкощах і різновидах DDos атак (ні як їх організовують, ні як від них грамотно відбиватися — крім простого блокування по IP). Коли з цим стикаєшся, то воно тобі і не треба.
Але по всьому виходить, що в перший робочий день після новорічних свят мене ддосили, і нічого ні я, ні техпідтримка хостингу з цим вдіяти не змогли. Наймати фрілансера для вирішення проблеми було стрьомно. Добре хоч по телефону хлопці з Инфобокса мені підкинули ідею підключити CloudFlare (як один з варіантів вирішення проблеми) і я за цю ідею вхопився, як за соломинку.
На успіх особливо не розраховував (за кілька годин, потрібних для скидання старих і прописування нових NC адрес встиг багато чого дізнатися по темі і навіть склав приблизний план дій). Але на мій подив буржуйський диво-сервіс допоміг! Притому навіть на безкоштовному тариф. Чудово спрацював режим захисту від DDos атаки. Чесно — не очікував. Був приємно здивований. Та ще й сайт став літати як на крилах (хоча і раніше черепахою не був).
Загалом — так не буває, але все ж трапляється…
Що таке Ддос і що таке CloudFlare?
Що таке Ddos? Ну, по-перше, це абревіатура від «distributed denial of service». По-російськи це звучить як розподілена атака, мета якої-домогтися від атакується сервера (ферми) відмови в обслуговуванні для відвідувачів сайту (сайтів). Сайт буде видавати помилку всім бажаючим на нього увійти.
Слово «распредленная» означає, що Ддос атака йде відразу з безлічі комп’ютерів в мережі. Дуже часто для цієї мети використовується так званий ботнет, тобто група заражених вірусами або іншим способом узятих під контроль комп’ютерів. Власники входять в ботнет комп’ютерів можуть при цьому навіть не догадывать про те, що вони когось атакують (все відбувається у фоновому режимі).
Фізично це означає величезну кількість запитів, які здійснюються до сервера з різних IP-адрес. Якщо адреса буде один або кілька, то його легко можна обчислити по логам або відкривши сторінку http://xxx.xxx.xxx.xxx/server-status (де x потрібно замінити на IP вашого сервера, якщо він працює під Апачем). Після чого проблем не складе підозрілі IP тимчасово заблокирвовать, наприклад, через файл .htaccess дописавши в нього рядка (Ip замініть на свої — рядків з Deny from можна додавати скільки завгодно):
Order allow,deny
allow from all
Deny from 83.149.19.177
Deny from 87.228.80.49
Deny from 178.212.72.13
Якийсь час мені це допомагало. Але справжній Ddos так ні за що не відбити — просто не встигнете виявляти повтори IP адрес, якщо будуть атакувати з десятків і/або сотень хостів. У мене так і сталося. У підсумку 7 годин повного дауна!
Перші дві години я спілкувався з техпідтримкою хостингу на предмет «допоможіть» — «не можемо». Потім за п’ять хвилин підключив до сайту CloudFlare, ще за пару хвилин змінив DNS записи у реєстратора доменних імен і години чотири чекав, поки почнеться проключение (DNS записи повинні оновитися на всіх ключових NS сервери в мережі). Повноцінно сайт запрацював тільки через добу, приблизно.
Що таке DDos? Це страшна річ насправді. Відчуваєш своє повне безсилля і безвихідь. З боку атакуючих — це спосіб заробити (на шантаж або виконуючи замовлення конкурента). Постійний захист від цього зла дуже дорога, але CloudFlare навіть на безкоштовному тариф дозволяє відбитися від слабо-середньої Ддос-атаки.
У цього сервісу є мільйони підключених сайтів (близько п’яти мільйонів) і розробники сервісу завжди чітко відстежують з яких IP зараз зазвичай атакують і таким відвідувачам, наприклад, можна показати капчу (боти навряд чи налаштовані на її розгадування) або перевірити браузер на «людяність» у таких підозрілих IP. Та й самі по собі їх розподілені по світу сервера непогано розріджують атаку на відмову — просто ці запити розподіляються на різні сервера і сильно знижують силу атаки зводячи всі зусилля «редисок» на немає.
Для більш серйозного захисту від Ддос в CloudFlare потрібно вже платити і не мало (200$). Але це все для дуже серйозного бізнесу, де Ддос могутніше (грошей вливають в це більше), але і коштів у власників багато більше. Нам з вами «за очі» вистачить тарифу PRO за 20$ або взагалі безкоштовного тарифу, на якому майже все є (про це читайте нижче).
Що таке CloudFlare? Це онлайн сервіс, ведучий свою історію з 2009 року (він ровесник мого блогу). Це ні в якому разі не хостинг, хоча з боку може здатися саме так. Це скоріше надбудова над хостингом (щось на зразок кеширующего зворотного проксі). Після підключення сайту до цього онлайн-сервісу у нього змінюється IP адреса і виникає таке відчуття, що ви змінили хостера, але це не так.
Хостинг вам буде потрібен і працювати з сайтом ви будете фактично так само, як і працювали раніше. Будуть деякі нюансики, але суть залишиться колишньою. CloudFlare ж потрібен для захисту (стабільної роботи) і прискорення роботи сайту.
До нього підключено вже більше п’яти мільйонів сайтів по всьому світу. Цей онлайн сервіс володіє розподіленою мережею дата-центрів (більше 120) по всьому світу (з минулого року і в Москві такий з’явився). Останнє особливо приємно, бо забезпечує набагато більш швидкий відгук при зверненні до сайтів з території Росії (хоча країна у нас велика і центрів треба будувати більше).
Отже, CloudFlare володіє купою розподілених серверів по всьому світу. Навіщо? Щоб додані до нього сайти вантажилися в браузерах відвідувачів як можна швидше. Вся графіка, CSS і джава скрипт коди будуть віддаватися з того дата центру, який знаходиться ближче до даного відвідувачеві вашого сайту. Відвідувач зайшов з Москви? Значить в роботу включається московський дата-центр. З США? Значить графіка та інша статика буде віддаватися відвідувачеві з найближчого до нього вузла Cloud Flare.
Одне це вже здатне підвищити середню швидкість завантаження странниц вашого сайту. Але цей сервіс має у своєму запасі ще кілька тузів і джокерів. Працюючи з мільйонами сайтів і відбиваючи щомиті атаки сервіс має базу адрес, з яких зараз найчастіше атакують сайти. Одне це може навіть на безкоштовному тариф служити першим ешелоном захисту від DDoS-атак (і на це не потрібно витрачати особливо ресурси і час).
Крім цього сервіс дозволяє включити режим «під атакою» (Under Attack Mode), коли кожне звернення до сайту переривається на 5 секунд для з’ясування типу браузера, з якого здійснювався захід. Якраз цей режим врятував мене в описаній вище безвихідній ситуації. Так, при цьому відсікаються всі боти і частина легітимних користувачів (на вскидку трафік став відсотків на двадцять менше), але це краще ніж повну відмову сервера доступу.
По закінченні Ддос-атаки цей режим можна буде відключити і вибрати відповідний рівень пильнування. При повторенні атаки його легко можна буде включити навіть з мобільника сидячи в метро (головне налаштувати моніторинг доступності вашого сайту, щоб вчасно зреагувати).
Загалом, навіть на безкоштовному тариф практично все що потрібно вже є. Навіть можна стискати на льоту файли CSS і джава скрипта (видаливши з них прогалини), щоб на капелюшечку збільшити швидкість завантаження. Не повірите — на безкоштовному тарифі у CloudFlare можна буде навіть SSL до сайту підключити (перейти на шифрований протокол передачі даних https, до чого нас останнім часом активно схиляє Гугл). Причому сервіс надає свій власний безкоштовний сертифікат.
«alt=»»>
Фантастика якась, чи не правда? Самі подивіться порівняльну таблицю тарифних планів (включаючи Free). Чума! Якщо ваш хостинг впаде (будуть проблеми), то Cloud Flare буде віддавати в цей проміжок часу сторінки сайту з свого кеша (і це працює — перевіряв зупинкою сервака, але є нюанси про які обов’язково читайте нижче, інакше не спрацює). Може чого упустив безкоштовних принад, але і цього більш ніж достатньо (за так то).
До речі, у цього сервісу немає партнерки, але в рунеті є маса конкурентів з божевільними цінниками (наприклад, захист від DDoS-атак в qrator коштує ого-го-го скільки). Тому коли будете читати на форумах або блогах відгуки про CloudFlare, то зверніть увагу на часто дуже тонку роботу цих конкурентів (можливості CloudFlare занижуються, а свого сервісу або надбудови — абсолютируются). Багато ведуться, але сервіс однозначно з розряду «такого не може бути, але все ж є».
Ні, недоліки у нього теж є. Які? Ну, часто дуже навіть значущі:
Трохи забігаючи вперед скажу, що я таки взяв платний тариф і IP змінився (тепер у мене три сусіда без особливих видимих проблем — напевно теж платники, не знаю). Перевірити сайти на одному IP з вами можна на 2IP:
Що дає перехід на тариф PRO CloudFlare?
Як я вже сказав вище, купив PRO за 20$ в місяць (дорожче хостингу вийшло в півтора рази) і мене перевели (без мого прохання — автоматом) на новий IP, де тільки три сусіда і цілком легітимні.
Крім цього на платному тариф з’явилася можливість:
Наприклад, якщо відкрити мій блог з мобільника, то при швидкій прокручуванні сторінки побачите, що замість картинок вставляються заглушки, які замінюються на реальні зображення тільки при їх попаданні в екран перегляду.
Правда гуглівський спідометр до включення Міражу показував (можна і інші сервіси вимірювання швидкості сайту використовувати):
А зараз істотно нижче дає оцінку — лається, що частина контенту на першому екрані не підвантажується вчасно. Хто його зрозуміє?
CloudFlare (не доходячи до реального хостингу). Можна ще свої правила додати, але я в цьому не сильний, тому обмежився стандартним (перевіреним часом і мільйонами сайтів) набором.
Ця Табличка на буржуйському мовою і частина відвідувачів можуть просто втекти. А ось якщо написати щось типу «Хлопців, хлопців, хлопців! Не йдіть! Буквально 5 сек і все буде!» то шанс утримати відвідувача збільшиться. Я поки все лінуюся цим зайнятися…
Тариф я оплачую через Пейпел, що дуже зручно. При налаштуванні платежів мене попросили прив’язати до рахунку в Пейпеле пластикову карту, але гроші знімалися не з карти, а безпосередньо з гаманця (я в нього виводжу доходи з мобільного додатку WhaffRewards). Прикольно, що кожний наступний місяць платіж відбувається без моєї участі — гроші автоматом списуються з Пайпаловского гаманця в день оплати, що дуже зручно.
Воно й не дивно, бо Пайпал дозволяє протягом півтора місяців опротестувати платіж, якщо що.
Як підключити свій сайт до CloudFlare?
Ну, тут, до речі, все досить просто, якщо майстер підключення зможе витягнути всі необхідні налаштування для перенесення вашого сайту (його IP, Ms запису). Однак, про все по порядку.
Заходьте на Cloud Flare і реєструєтеся (пароль бережіть як зіницю ока, бо це ключ до вашого сайту).
«alt=»»>
Відразу обмовлюся, що боятися особливо нічого, бо при невдалому підключенні вам не доведеться чекати добу, поки ДНС запису знову переписуватимуться. Просто кликніть по облачкам на сторінці налаштування DNS і ваш сайт буде працювати безпосередньо (мені довелося так вчинити з одним з другорядних проектів, який чомусь з CloudFlare перестав відкриватися — див. скріншот нижче). Але по-любому: вся відповідальність за ваші дії лежить тільки на вас і я тут буду, як би ні причому.
Відразу після реєстрації можна переходити на сторінку додавання нового сайту, де в запропоновану рядок потрібно буде просто вставити його доменне ім’я і натиснути на кнопку «Begin Scan»:
Далі буде проходити сканування протягом декількох хвилин, по закінченні якого сервіс видасть ті дані, що йому вдалося нарити про цей сайт:
Тут, як бачите, все ОК — сервіс знайшов всі основні NS записи (включаючи поштові), що є добре. Автоматично для майбутніх даних, переданих з цього сайту, включилося кешування (хмарки забарвилися). Йдемо далі.
Як вже говорив вище, для захисту від Ddos підійде навіть безкоштовний тарифний план (на ньому при бажанні ще й безкоштовний SSL сертифікат можна отримати). Відмінності плану PRO від безкоштовного я описав вище, тому вибирайте те, що вам потрібно (мені все одно). Йдемо далі.
Тепер основне. Потрібно зайти в панель вашого реєстратора доменних імен (домен де підбирали) і змінити там NS записи на ті, що запропонував на цьому кроці майстра CloudFlare. Наприклад, в Вебмані Домейнс це робиться на такий ось сторінці:
Потрібно просто замінити записи в двох рядках на те, що вам Cloud Flare дав і почекати від 4 годин до 2 діб, поки все це справа пропишеться на всіх NS інтернету. Йдемо далі, і після закінчення декількох годин після прописування нових NS серверів можна буде натиснути на кнопку «Recheck Імен»:
Зверніть увагу, що внизу приведені параметри за замовчуванням, які будуть застосовані до вашого сайту відразу після остаточного підключення до CloudFlare (середній рівень безпеки і стандартне кешування, яка передбачає попадання в кеш тільки статики — картинок, стилів і скриптів).
Якщо підключення ДНС вже пройшло, то статус після натискання на згадану кнопку зміниться:
Кнопка «Quick Actions» дозволяє швидко перейти в режим захисту від Ddos та інших видів атак, який називається «Under Attack Mode». Мені при переході на Cloud Flare довелося зробити саме так. Даний режим «Під атакою» (Under Attack Mode) у мене було включено близько 12 годин, поки атака не припинилася.
На цей час доступ до сайту обмежений і всі з’єднання перевіряються на предмет їх легетивности. Всякі роботи, у тому числі і пошукових систем пробитися на сайт не зможуть. Загалом, працювати в ньому не варто довше того, ніж необхідно (поки йде атака). Трохи докладніше про включенні і вимиканні режиму захисту від Ддос-атаки читайте в самому кінці цієї публікації.
100%-ий аптайм для сайту з допомогою CloudFlare
Під автономної роботою сайту я маю таку ситуацію, коли з якихось причин ваш хостинг «ляже», а сайт продовжить бути доступним відвідувачам. Це, як кажуть, крайній випадок. Але часто хостинг може просто-напросто не справлятися з високим навантаженням (викликаної відвідуваністю або використанням безлічі плагінів і поганий оптимізацією движка). В цьому випадку знову ж таки допоможе кешування Html сторінок в CloudFlare.
За замовчуванням, як я розумію, сервіс кешує тільки статику: картинки, CSS і JC. Всі. В принципі, і це може здорово полегшити роботу хостингу і прискорити завантаження сторінок сайту в різних точках світу. Але часто цього буває недостатньо. Та навіть не це головне. В цьому режимі не спрацьовує функція «Always Online» (Завжди онлайн), бо Cloud Flare не вміє творити чудеса і віддає сторінки з свого власного кеша, а якщо їх там немає, то відсилає до хостингу (який в даний момент може бути недоступний).
Загалом, завдання зводиться до того, щоб включити кешування вмісту веб-сторінок (коду розмітки, що включає текстове наповнення), а не тільки статики. Зробити це можна на вкладці «Page Rules» з верхнього меню (див. пояснення в хелпе). Чому це не винесли в загальні налаштування кешування? Думаю, що через великого розмаїття сайтів і движків, на яких вони працюють. Мабуть, не можливо забезпечити таким чином стабільність. Потрібно діяти більш точково, спираючись на структуру і специфіку кожного конкретного сайту. ІМХО.
На безкоштовному тариф можна створити лише три правила для сторінок, а на тарифі PRO — вже 20. Суть створення правила досить проста. Поки опустимо те, що потрібно вставити в поле з регулярним виразом, а подивимося, що нам пропонують при натисканні на «+ Add a Setting» (додати налаштування):
Тут якраз можна вибрати настройку ступеня кешування (Cache levels), де в списку допнастроек можна буде вибрати останній варіант «Cache everything» («Кешувати все»). Таким чином, ми примусово змусимо CloudFlare кешувати всю вебсторінку, а не тільки статику.
Ще бажано вказати час, що сторінка буде зберігатися в кеші CloudFlare і в кеші браузера відвідувачів сайту (це дві різні налаштування). Тут все залежить від ступеня динамічності вашого сайту в цілому і окремих його сторінок зокрема. Мене цілком влаштовує інтервал у кілька діб зберігання кеша в хмарі, а кеш браузера я вибираю різний (в залежності від типу сторінок).
Для визначення цих параметрів потрібно ще пару раз натиснути на кнопку « Add a Setting» і вибрати:
Відразу обмовлюся, що на сервісі є можливість примусово скинути кеш не тільки для всього сайту (чого робити особливо не рекомендується), але й окремих сторінок, і навіть окремих статичних файлів (зображень, файлів стилів і скриптів), коли ви внесли до них зміни і хочете, щоб вони негайно стали доступні відвідувачам вашого сайту.
Робиться це на вкладці «Caching» (з верхнього меню) шляхом натискання на кнопку «Purge Individual Files» (щоб скинути весь кеш потрібно буде натиснути на стрілочку на цій кнопці, і вибрати нижній з двох пунктів «Purge Everything»). У вікно, що відкрилося, потрібно ввести Url сторінки або сторінок (по одній на рядок), або окремих файлів (повний шлях до картинок, файлу стилів і т. п.):
Я цією опцією користуюся досить часто, наприклад, після зміни картинок, додавання коментаря до статті або при зміні дизайну сайту (скидаю кеш для файлика стилів). Файли, кеш яких ви нещодавно скидали, відображаються нижче — по ним можна просто клікнути, щоб виконати їх черговий скидання. Дуже зручно.
Але повернемося до налаштувань правил для окремих сторінок сайту — Page Rules. Трохи раніше ми натиснули на кнопку «Create Page Rule» і навчилися включати повне кешування вмісту Html сторінок, а також обмежувати час життя кешу в браузерах відвідувачів і на серверах CloudFlare. Вийти в результаті повинно щось типу цього:
Тобто ми поставили потрібні нам правила кешування. У прикладі — це кешування вмісту з терміном життя кешу в браузерах відвідувачів 4 год і терміном життя кешу на серверах сервісу 2 доби. Залишилася справа за малим — прописати в першому рядку цього спливаючого вікна формулу, за якою сервіс зрозуміє для яких саме сторінок вашого сайту ці правила застосовувати. Як це зробити, можна прочитати натиснувши на кнопку «Хелп» внизу вікна налаштувань правил.
На мій погляд, є два шляхи завдання правил:
Як налаштувати повне кешування сторінок сайту в CloudFlare
Тепер детальніше про практичної реалізації обох способів.
Почнемо з першого варіанту створення дозвільних правил кешування для всіх (або більшості) сторінок сайту, які потрібно буде зберігати в кеші серверів CloudFlare повністю (весь html код з картинками, скриптами і стилями).
Якщо сторінки зі статтями вашого сайту (як і на моєму блозі) закінчуються на .html, то для їх повного кешування вистачить одного єдиного правила для сторінок:
/*.html
Замініть моє доменне ім’я на своє і все повинно запрацювати. Досить просто — знак * замінює все, що може стояти між доменними ім’ям і суфиксом .html.
Залишиться ще тільки додати правило для повного кешування головної сторінки сайту:
/
Тут, думаю, все зрозуміло і без пояснень. Єдине, що для головної сторінки я час кешування в браузерах користувачів вибрав поменше, бо вміст цієї сторінки частіше інших змінюється, і важливо, щоб вона відображалася у більш-менш актуальному стані.
Час кешування на серверах CloudFlare залишив великим, тому що при додаванні нового запису я просто скидаю кеш для головної способом описаних трохи вище. Дуже зручно, тільки спочатку потрібно звикнути це робити.
Чудово, коли всі сторінки, окрім головної закінчуються на .html. У мене ж, наприклад, рубрики і статичні сторінки (типу «Про блог») такого індексу не мають. З рубриками особливо турбуватися не довелося, бо при налаштуванні ЧПУ у своєму блозі на Вордпресс я вибрав, як виявилося, вдалий шаблон, з обов’язковим словом (каталогом) «/category/», тому зазвичай для цього типу сторінок виглядає так:
/category/*
Ну, а зі статичними сторінками довелося поизголяться, але начебто все вийшло.
В результаті відсоток віддаються з кеша CloudFlare даних склав (за даними вбудованої в цю систему аналітики) близько 90%, що є дуже навіть добре (по суті на цю величину знизилася навантаження на сервер мого хостингу):
На окремому записі в CloudFlare (безкоштовному) я розмістив всі інші свої невеликі проекти. Т. к. правил для сторінок можна було створити лише три на безкоштовному тариф, то я вирішив піти від протилежного — дозволити повне кешування всього сайту, заборонивши потім чіпати сторінки адмінки.
Відразу скажу, що спрацювало як-то не дуже. Замість 90% завантажень з кеша, в цьому випадку я отримав менше 50%. Але тим не менш свої рішення я наведу, може ви мені підкажіть де я помилився. Отже, першим правилом я дозволив кешувати все:
А другим (цей сайт працює на Вордпресс) — для сторінок адмінки вибрав режим кешування байпас, тобто не потрапляння цих сторінок в кеш. Ніби все працює і швидкість блогу істотно зросла, але в аналітиці менше 40 відсотків трафіку йде через CloudFlare (все інше тягнеться з сервера хостингу). Чому? Для мене не дуже зрозуміло. При цьому з роботою в адмінці ніяких проблем при цьому не спостерігалося, що вже добре.
Якщо у вас сайт на joomla, то там адмінку можна забайпассить таким чином (напевно):
domen.ru/admin*
Загалом, самі дивіться, який варіант обрати.
На одному з сайтів, підключених до безкоштовного акаунту CloudFlare, раптом виникли проблеми (він перестав відкриватися), тому для нього я поки просто відключив «хмарки» на вкладці «DNS» з верхнього меню:
Після цього він почав відкриватися. Переносити NS записи на старі поки не став — може бути виникне бажання порозбиратися що до чого.
Що робити, якщо почалася DDos-атака і як її відобразити?
Якщо ви підключилися до КлоудФлэр саме через йде в даний момент Ддос-атаки (або вона почалася після підключення), то її цілком можна буде відобразити або знизити ефект від неї навіть на безкоштовному тарифі цього сервісу. Для цього достатньо лише перейти на вкладку «Overview» з верхнього меню і натиснути на кнопку «Quick Actions»:
Виберіть зі списку пункт «Under Attack Mode» і даний сервіс почне активно протидіяти Ddos-атаці.
Всі користувачі (або боти) будуть затримуватися перед зверненням до вашого сервера хостингу сервісом CloudFlare на 5 секунд, за час яких він буде намагатися визначити реальний це користувач (браузер) або бот.
Реальні користувачі будуть спостерігати таку ось картинку на своєму екрані протягом 5 секунд (до відкриття сторінки вашого сайту):
Зрозуміло, що така «незрозуміла» напис частина відвідувачів таки відлякає — я спостерігав падіння відвідуваності в режимі «Under Attack Mode» приблизно на чверть по відношенню до нормального режиму роботи. Але краще втратити чверть відвідувачів, ніж всі 100%. Погодьтеся?
До того ж на тарифі PRO (про який я писав вище) можна вигляд цієї написи поміняти і знизити відсоток відмов (наприклад, перекласти її на російську і додати трохи креативу). По-любому можливість чудова.
Однак, не варто залишати сайт в режимі «Under Attack Mode» довше того часу, поки йде атака, бо ви не тільки частина відвідувачів будете втрачати, але і всі боти пошукових систем відсікатимуться від сайту, що з часом не здорово позначиться на відвідуваності. Тому періодично вимикайте режим «Under Attack Mode» простим натисканням на кнопку «Disable» (на вкладці «Overview»- див. скріншот вище) і дивіться на результат.
Якщо сайт знову став недоступний (Ddos триває), то вмикайте Status: i’m Under Attack! взад. Так продовжуйте години через два моніторити закінчення Ддос-атаки, щоб не тримати зайвий час сайт в цьому безумовно корисний, але неоптимальному режимі «Під атакою».
На постійній основі я віддаю перевагу використовувати режим за замовчуванням «Medium». До речі, поміняти режим безпеки можна і без перемикання в «Under Attack Mode». Зробити це можна на вкладці «Конфігурація» (з верхнього меню), вибравши потрібний варіант з випадаючого меню кнопки з назвою поточного Security Level:
Ну, і «i’m Under Attack!» звідси теж можна включити.
А в цілому
Поки ніби все, що хотів і маю сказати. Полазайте ще по вкладці «Speed» і подивіться, що там можна використовувати. А взагалі, вибачте за настільки короткий опис цього безумовно примітного сервісу, але щось втомився друкувати і скріни робити (мабуть, сьогодні не в формі).
У рунеті подібного меценатства укупі з приголомшливою корисністю я поки не зустрічав. Тому не вважав для себе обтяжливим перейти на тариф PRO з щомісячним відстібанням 20$.
В принципі, можна було цього не робити, але так якось спокійніше, чи що…
CloudFlare присвячений п’ятий ролик з 6 відеоуроків по темі прискорення сайту, які, на мій погляд, має сенс подивитися, щоб сприймати картинку оптимізації в цілому (потрібний ролик можна вибрати з випадаючого списку в лівому верхньому куті вікна плеєра):
Удачі вам! До зустрічей на сторінках блогу
