До основного вмісту

Кешування в Cloudflare: налаштування Cache Rules та Edge TTL

Cloudflare · 19.04.2026 · 4 хв читання
Ілюстрація до статті «Кешування в Cloudflare: налаштування Cache Rules та Edge TTL»

За замовчуванням Cloudflare кешує лише статику (JS, CSS, зображення). Для кешування HTML-сторінок потрібно створити Cache Rules — це кардинально знижує навантаження на сервер.

Що кешує Cloudflare за замовчуванням

Caching → Configuration → Caching Level: Standard кешує файли з розширеннями: .jpg, .png, .gif, .css, .js, .woff2, .ico та інші статичні формати.

Cache Rule для HTML-сторінок

Caching → Cache Rules → Create rule:

# Кешувати всі HTML сторінки (виключаючи /admin, /wp-admin)
Conditions:
  - hostname equals example.com
  - AND NOT path starts with /wp-admin
  - AND NOT path starts with /admin
  - AND NOT Cookie contains wordpress_logged_in

Cache Settings:
  - Eligible for cache: Yes
  - Edge TTL: 4 hours
  - Browser TTL: 1 hour
⚠️ Не кешуйте сторінки з авторизацією, кошиком, особистим кабінетом. Використовуйте умову «Cookie NOT contains» для виключення залогінених користувачів.

Обхід кешу для WordPress

# Cache Rule — BYPASS для WordPress admin
Conditions:
  - Cookie contains: wordpress_logged_in
  OR Path starts with: /wp-admin
  OR Path starts with: /wp-login.php

Cache Settings:
  - Cache Status: Bypass

Примусове очищення кешу

Caching → Configuration → Purge Cache:

  • Purge Everything — очистити весь кеш (з обережністю)
  • Custom Purge — очистити кеш конкретного URL
  • Purge by Tag/Host/Prefix — Business і вище
✅ Налаштуйте автоматичне очищення кешу при публікації постів WordPress — плагін Cloudflare для WordPress робить це автоматично.

Cache Analytics

Caching → Cache Analytics — показує співвідношення HIT/MISS/BYPASS запитів. Мета: HIT rate > 80% для статики.

Часті проблеми з кешуванням

СимптомПричина
CF-Cache-Status: DYNAMIC замість очікуваного HITЗапит не підпадає під умови Cache Rule, або у відповіді є Set-Cookie — такі відповіді Cloudflare за замовчуванням не кешує
CF-Cache-Status: EXPIRED одразу після очищенняEdge TTL закінчився раніше очікуваного — звірте значення із заголовками Cache-Control на джерелі
Користувач бачить чужий кошик або чужі даніЗакешовано персоналізовану сторінку без виключення за Cookie — критична помилка конфігурації
Зміни на сайті не з'являються навіть після Purge EverythingВинен не Cloudflare, а кеш браузера або проміжний кеш на хостингу (наприклад, сторінка в OPcache/Redis)

Рекомендовані TTL за типом контенту

Тип контентуEdge TTLBrowser TTL
Статичні ассети (JS/CSS/зображення)1 місяць1 день
HTML публічних сторінок4 години10 хвилин
API-відповіді без персоналізації5 хвилинБез кешу (no-store)
Персоналізовані сторінкиBypassБез кешу (no-store)

Коли Cache Rules не допоможуть

  • Контент персоналізований для кожного користувача (особистий кабінет, кошик) — кешувати такі сторінки в принципі не можна без ризику витоку чужих даних
  • Сайт уже віддає коректні заголовки Cache-Control і не потребує перевизначення на рівні Cloudflare
  • Застосунок залежить від актуальності даних у реальному часі (котирування, чати) — будь-який кеш тут шкідливий
  • На тарифі Free обмежена кількість правил і типів умов — для складної логіки потрібен вищий план

Перевірка результату

Після налаштування правила переконайтеся, що кеш дійсно працює, за заголовком відповіді:

curl -sI https://example.com/ | grep -i cf-cache-status
# Перший запит зазвичай MISS, повторний протягом Edge TTL — HIT
curl -sI https://example.com/ | grep -i cf-cache-status

Якщо статус стабільно DYNAMIC — перевірте умови правила в Page Rules: старе правило з вищим пріоритетом може перебивати новий Cache Rule. Загальні рекомендації щодо прискорення віддачі — у статті про оптимізацію швидкості в Cloudflare.

Порядок застосування правил

Cache Rules у Cloudflare виконуються згори вниз, і перше правило, що підходить за умовами, перемагає — подальші правила для цього запиту вже не перевіряються. Звідси практичне правило: більш специфічні умови (конкретний шлях, конкретний піддомен) потрібно ставити вище загальних, інакше загальне правило перехопить запит раніше, ніж система дійде до точного збігу.

Ця ж поведінка пояснює часту плутанину, коли адміністратор додає нове вузьке правило, а воно ніби не працює — насправді спрацьовує більш раннє широке правило. Перевірити фактично застосоване правило можна в розділі Caching → Cache Rules за лічильником «Requests», який оновлюється в міру звернень до сайту.

Взаємодія з кешем самого хостингу

Cloudflare кешує відповіді на рівні edge-серверів по всьому світу, але це не скасовує власний кеш на стороні хостингу — наприклад, сторінковий кеш плагіна WordPress або OPcache для PHP-коду. Ці два рівні працюють незалежно: очищення кешу Cloudflare не зачіпає кеш на сервері, і навпаки. Під час відлагодження проблем із застарілим контентом завжди перевіряйте обидва рівні окремо, інакше легко витратити час на «очищення не того кешу».

Чи була стаття корисною?
← Назад до бази знань Поставити питання підтримці