← Cloudflare Cache / cache / troubleshooting

Анализ некешируемых ответов

Если URL-адрес, который должен был кешироваться, каждый раз обслуживается с источника, cf-cache-status заголовок ответа показывает, какое решение о кешировании принял Cloudflare. Запросите URL-адрес, проверьте заголовок и перейдите к разделу, соответствующему увиденному значению:

• DYNAMIC Cloudflare определил, что запрос не подлежал кэшированию, ещё до обращения к кэшу. См. DYNAMIC: запрос не подлежит кешированию.
• BYPASS Cloudflare был готов закэшировать ответ, но ответ источника или конфигурация этому помешали. См. BYPASS: ответ исходного сервера не подлежит кэшированию.
• MISS при нескольких последовательных запросах от одного и того же клиента: ответ можно кешировать, но кеш продолжает давать промах. См. Повторный MISS: подлежит кешированию, но отсутствует в кеше.

Для любого другого статуса см. Кеширование ответов с полным списком.

Недавний Полная очистка, очистка по URL, очистка по префиксу, очистка по тегу, или очистка по имени хоста очищает кеш. Следующий запрос в каждом дата-центре заново наполняет кеш и возвращает MISS прежде чем последующие запросы начнут возвращать HIT. Если очистка кеша выполнялась недавно, подождите, пока кеш заново наполнится, прежде чем продолжать.

Cloudflare принял решение «не кешировать» ещё на этапе запроса, до обращения к кешу. Частые причины:

• Расширение файла отсутствует в расширения файлов, кешируемые по умолчанию список например, .html или ответ JSON API, и ни одно правило не включает для него кеширование. Добавьте Cache Rule с Подлежит кешированию имеет значение Да.
• Правило указывает Cloudflare обходить кеш. Проверьте, есть ли Cache Rule с Bypass cache настройку либо устаревшую Cache Level: Bypass Configuration Rule или Page Rule, совпадает с URL. Используйте Трассировка правила чтобы убедиться, какие правила применяются.
• Метод запроса не является GET или HEAD. Cloudflare кэширует только эти два метода.
• Development Mode включен для зоны. Development Mode приостанавливает кэширование на три часа и возвращает DYNAMIC для каждого ответа.

Как только запрос становится подходящим, последующие ответы отражают решение, принятое во время обработки запроса (HIT, MISS, BYPASS, и так далее).

Запрос подходил для кеширования, но ответ источника или настройки конфигурации помешали Cloudflare сохранить его. Наиболее частые причины:

• Ответ превышает лимит размера кешируемого контента для вашего плана. Разделите объект на более мелкие ресурсы или перейдите на план с более высоким лимитом. R2 является альтернативой хранилищу на источнике: он не увеличивает предельный размер объекта, кэшируемого CDN.

• Источник вернул no-store или без private в Cloudflare-CDN-Cache-Control или CDN-Cache-Control заголовок. Cloudflare оценивает эти заголовки перед Cache-Control, в порядке приоритета Cloudflare-CDN-Cache-Control > CDN-Cache-Control > Cache-Control. Источник, возвращающий Cache-Control: public, max-age=3600 вместе с CDN-Cache-Control: no-store приводит к BYPASS. Cloudflare не передаёт Cloudflare-CDN-Cache-Control клиенту, поэтому он не виден в ответе. Если вы видите BYPASS без CDN-Cache-Control заголовок, проверьте, что именно отправил источник, либо отключите заголовок на источнике и повторите тест. Cache Rule с Edge Cache TTL настройка, игнорирующая cache-control источника, переопределяет обе директивы. См. CDN-Cache-Control с правилами приоритета.

• no-cache, max-age=0, или s-maxage=0 в Cloudflare-CDN-Cache-Control или CDN-Cache-Control не создают BYPASS. Они приводят к MISS при первом запросе, тогда REVALIDATED или EXPIRED при последующих запросах.

• Источник вернул Cache-Control: no-store или без private. Эти директивы блокируют кэширование либо в Origin Cache Control режим по умолчанию. Два исключения: Cache-Control: private="<header>" с именами полей остаётся кэшируемым: Cloudflare удаляет только указанные заголовки. А Cache Rule с Edge TTL, который игнорирует cache-control источника (Edge TTL → Ignore cache-control header and use this TTL или Status code TTL) имеет приоритет над обеими директивами, поэтому ответ с no-store плюс на это время действует настройка Edge TTL, и ресурс кешируется.

• Источник вернул Cache-Control: no-cache, max-age=0, или s-maxage=0, а также Origin Cache Control отключён (значение по умолчанию для плана Enterprise). При включенном Origin Cache Control (значение по умолчанию для планов Free, Pro и Business) эти директивы заставляют Cloudflare вместо этого кэшировать и повторно проверять ответ, что приводит к REVALIDATED или EXPIRED. См. Изучите no-store и no-cache директивы и Условия в таблице.

• Источник вернул Set-Cookie заголовок. По умолчанию Cloudflare не кэширует ответы, которые включают Set-Cookie. Чтобы кешировать ответ, используйте один из следующих вариантов:

  • Задайте явный Edge TTL для Cache Rule с помощью Edge TTL → Ignore cache-control header and use this TTL или Status code TTL. Cloudflare игнорирует директивы источника, удаляет Set-Cookie, и кеширует ответ.
  • Настройте отдачу источником Cache-Control: private="Set-Cookie" или no-cache="Set-Cookie". Cloudflare удаляет указанный заголовок и кеширует остальное.
  • Удаление Set-Cookie до принятия решения о кешировании, используя Response Header Modification Transform Rule.
  • На тарифных планах Enterprise с Origin Cache Control отключено, Cloudflare удаляет Set-Cookie и кэширует ответ на уровне кэширования по умолчанию. Cache Level: Cache Everything Page Rule или правило кеширования с Подлежит кешированию имеет значение Да (если не задан явный Edge TTL) переопределяет это значение и возвращает BYPASS.

  См. Взаимодействие Set-Cookie заголовок ответа с Cache с полной матрицей.

• Источник вернул Vary: *. Это значение всегда обходит кэш, независимо от прочих настроек.

• Запрос содержал Authorization заголовок и Origin Cache Control включён (значение по умолчанию для планов Free, Pro и Business). В этом режиме ответ подлежит кэшированию только если Cache-Control также включает public, s-maxage, или must-revalidate. На планах Enterprise с отключённым Origin Cache Control Authorization сам по себе не запрещает кеширование.

См. BYPASS со справочным определением этого статуса.

MISS при первом запросе в каждом дата-центре ожидаем: этот запрос заполняет кеш. Если один и тот же URL продолжает возвращать MISS в последовательных запросах, происходит одно из следующего.

По умолчанию Cloudflare формирует ключ кеша на основе схемы, хоста, пути и строки запроса к источнику. При соответствующей настройке в него также могут входить cookie, заголовки и тип устройства. Схемой в ключе кеша Cloudflare считает ту схему, которую он использует для обращения к источнику, а не ту, которую использовал клиент, поэтому зона с единственной схемой подключения к источнику обслуживает запросы HTTP и HTTPS от клиентов из одной и той же записи кеша.

Если каждый реальный запрос клиента формирует свой ключ, кеш никогда не видит повторов и каждый запрос становится MISS. Типичные шаблоны:

• Параметры запроса, которые меняются при каждом запросе идентификаторы сессий, временные метки или маркетинговые теги, такие как utm_*. По умолчанию каждая уникальная строка запроса образует отдельную запись кеша. Настройте Cache Rules или Настройки Cache Key чтобы исключить или игнорировать параметры, значение которых меняется от запроса к запросу. Сортировка лишь приводит порядок параметров к единому виду: используйте её, когда запросы отличаются только порядком параметров, а не когда отличаются сами значения.
• пользовательский ключ кеша содержит cookie или заголовок со значением, которое меняется для каждого пользователя. Заголовок Создание пользовательских ключей кеша раздел предупреждает, что пользовательские ключи «могут снизить долю попаданий в кеш и привести к фрагментации кеша»: это то же самое поведение.
• Кеширование по типу устройства классифицирует клиентов не так, как ожидалось, особенно для ботов или клиентов с нестандартными User-Agent значения.
• Vary в Cache Rules настроен для заголовка, источник указывает этот заголовок в своём Vary заголовок ответа, а действие: normalize или passthrough. Каждый вариант ответа хранится под отдельным ключом. Если у заголовка высокая кардинальность, например ненормализованный Accept-Language значение или заголовок для конкретного пользователя, практический процент попаданий в кеш снижается. Значение bypass действие полностью предотвращает кэширование.

Два идентичных запроса дают одинаковый ключ кеша и не позволяют выявить различия. Для диагностики используйте Трассировка правила чтобы увидеть применённую конфигурацию ключа кеша и действие Vary для URL, а затем сравнить их с атрибутами запроса (строка запроса, куки, заголовки, тип устройства), которые различаются в реальных запросах клиентов.

Ресурсы с низким трафиком могут быть вытеснены из кеша до поступления следующего запроса. Если два последовательных запроса к одному и тому же URL из одного и того же дата-центра возвращают MISS, включите Tiered Cache или Cache Reserve чтобы дольше хранить редко запрашиваемый контент.

Если ваши запросы попадают в разные дата-центры Cloudflare, в каждом из них формируется собственный первый запрос MISS. Сравните код дата-центра: последние три символа cf-ray заголовок, чтобы подтвердить, что оба ответа поступили из одного дата-центра. Разные клиентские сети могут обращаться к одному и тому же дата-центру, поэтому смена сети не гарантирует смену местоположения.

После изменения конфигурации дважды запросите URL с того же клиента и проверьте, что результат соответствует ожидаемому для вашей конфигурации:

• Актуальный положительный Edge TTL: cf-cache-status: HIT и Age заголовок, значение которого увеличивается при последующих запросах. Age отсутствует при первом запросе, который заполняет кэш локального дата-центра с вышестоящего уровня через Tiered Cache HIT отражает верхний уровень, но локальный дата-центр еще не обслужил запрос из кеша. Последующие запросы включают Age, а при использовании Tiered Cache это значение может быть уже большим, поскольку отражает возраст объекта в общесетевом кеше Cloudflare.
• Источник возвращает Cache-Control: no-cache с Origin Cache Control включено: cf-cache-status: REVALIDATED когда источник подтверждает, что кэшированная копия не изменилась, или EXPIRED когда источник возвращает новое содержимое. Оба варианта означают, что ответ кэширован. must-revalidate сам по себе не заставляет выполнять повторную проверку при каждом запросе: он лишь предотвращает выдачу устаревшего содержимого после истечения TTL актуальности.

Если ответ по-прежнему MISS или BYPASS после этих проверок сделайте два полных снимка ответа (заголовки запроса и ответа, включая cf-ray значений) и создайте обращение в поддержку. Значение cf-ray значения необходимы, чтобы отследить запрос в сети Cloudflare.

• Кеширование ответов справочная информация по каждому cf-cache-status значение.
• Поведение кеша по умолчанию когда Cloudflare по умолчанию успешно кэширует.
• Cache Rules настройка Edge TTL, применимости кэширования и ключа кэша.
• Cache Analytics измеряйте коэффициент попаданий в кэш и выявляйте URL с низкой эффективностью.