По умолчанию 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Обход кэша для 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 и выше
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 TTL | Browser 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 не затрагивает кэш на сервере, и наоборот. При отладке проблем с устаревшим контентом всегда проверяйте оба уровня по отдельности, иначе легко потратить время на «очистку не того кэша».