← Cloudflare Cache / cache / concepts

Кеширование ответов Cloudflare

CF-Cache-Status заголовок показывает, кешируется ли ресурс. Чтобы изучить ответы кеша, возвращаемые этим заголовком, используйте такие сервисы, как Redbot ↗, webpagetest.org ↗, или визуальный инструмент вроде Плагин Cloudflare Optics ↗.

Ниже приведён подробный разбор статусов ответа кэша Cloudflare.

Ресурс был найден в кеше Cloudflare.

Ответ подходит для кеширования, но на момент запроса отсутствовал в кеше Cloudflare, поэтому он был отдан с исходного веб-сервера. Для ответов, которые Cloudflare решает не кешировать, возвращается BYPASS вместо MISS.

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

• Worker сформировал ответ, не отправляя дополнительных подзапросов. В этом случае ответ поступил не из кеша, поэтому статус кеша будет none/unknown.

• Запрос Worker выполнил подзапрос (fetch). В этом случае подзапрос будет зафиксирован в журнале со статусом кэша, а основной запрос будет зафиксирован со статусом none/unknown статус (основной запрос не был обслужен из кеша, так как Workers работает перед кешем).

• Сработало пользовательское правило WAF, заблокировавшее запрос. Ответ поступит из глобальной сети Cloudflare до обращения к кешу. Поскольку статус кеша в этом случае отсутствует, Cloudflare зафиксирует значение none/unknown.

• правило перенаправления или Always Use HTTPS привёл к тому, что глобальная сеть ответила перенаправлением на другой ресурс или URL. Это происходит до того, как запрос достигает кеша, поэтому статус кеша none/unknown.

Ресурс был найден в кеше Cloudflare, но срок его действия истёк, поэтому он был отдан с исходного веб-сервера.

Ресурс был отдан из кеша Cloudflare, но срок его действия истёк. Cloudflare не смог связаться с исходным веб-сервером, чтобы получить обновлённую версию ресурса.

Cloudflare счёл ресурс подлежащим кешированию на момент запроса: либо потому что он соответствует расширения файлов, кешируемые по умолчанию, или потому что Cache Rule включили для него кеширование, однако ответ источника в итоге не подлежал кешированию.

Распространённые причины, по которым ответ источника считается непригодным для кеширования, включают:

• Ответ превышает максимальный размер файла, который можно кешировать для вашего плана.
• Источник вернул 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. Cache Rule с Edge Cache TTL настройка, игнорирующая cache-control источника, переопределяет эти директивы так же, как и для Cache-Control: no-store. no-cache, max-age=0, или s-maxage=0 в этих заголовках не приводят к BYPASS. Они создают MISS при первом запросе, тогда REVALIDATED или EXPIRED. См. CDN-Cache-Control с правилами приоритета.
• Источник вернул Cache-Control: no-store или private. Эти директивы предотвращают кеширование как в Origin Cache Control режим.
• Источник вернул 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 заголовок. См. Взаимодействие Set-Cookie заголовок ответа с Cache для конкретных конфигураций, которые приводят к BYPASS.
• Источник вернул Vary: * заголовок ответа, который всегда обходит кеш.
• Запрос содержал Authorization заголовок и Origin Cache Control включен (значение по умолчанию для тарифов Free, Pro и Business). В этом режиме ответ можно кешировать только если Cache-Control также включает public, s-maxage, или must-revalidate. На планах Enterprise с отключённым Origin Cache Control Authorization сам по себе не запрещает кеширование.

BYPASS означает, что решение не кэшировать было принято на время отклика запрос изначально подлежал кэшированию, но ответ источника или его заголовки предписали Cloudflare не кэшировать его. Например, правило кэширования, которое задаёт "cache": true включает кеширование во время запроса, но если источник возвращает Cache-Control: no-store, ответ будет иметь статус BYPASS.

Если ожидалось, что URL-адрес будет кеширован, но вы видите BYPASS, см. Анализ некешируемых ответов для пошаговой диагностики.

Источник подтвердил, что кешированный ресурс не изменился, с помощью условного запроса (If-Modified-Since или If-None-Match), и ответ отдаётся из кэша Cloudflare. Этот статус отражает синхронный путь проверки: запрос ожидает ответа от источника, прежде чем быть отданным.

С асинхронный stale-while-revalidate, большинство повторных проверок теперь возвращают UPDATING или HIT вместо этого. REVALIDATED наблюдается в следующих ситуациях: stale-while-revalidate не задан; либо такие директивы, как must-revalidate или no-cache (с Origin Cache Control включена) не позволяют отдавать устаревшее содержимое.

Срок действия ресурса истёк, но он был отдан из кеша Cloudflare, пока источник обновлял его в фоновом режиме. UPDATING это ожидаемый статус во время асинхронный stale-while-revalidate ревалидации: все запросы в течение окна ревалидации получают UPDATING или HIT вместо ожидания ответа от источника.

Cloudflare определил на момент запроса, что ресурс не подлежит кешированию, поэтому запрос был направлен на исходный веб-сервер без обращения к кешу.

Обычно это происходит, когда:

• Запрошенный ресурс не относится к расширения файлов, кешируемые по умолчанию (например, HTML или JSON) и ни одно правило не предписывает Cloudflare кэшировать его.
• Cache Rule на Bypass cache настройка соответствует запросу. Устаревший Cache Level: Bypass параметр в Configuration Rules или Page Rules ведёт себя так же.
• Development Mode включен для зоны, что приостанавливает кеширование на три часа.

Используйте Cache Rules чтобы изменить, какой контент кеширует Cloudflare. После того как запрос признан пригодным для кеширования, CF-Cache-Status заголовок будет отражать решение о кэшировании, принятое во время ответа (HIT, MISS, EXPIRED, REVALIDATED, BYPASS, и так далее): обратитесь к BYPASS на случай, если ответ источника в итоге окажется некешируемым.

Если ожидалось, что запрос будет подходить для кеширования, но вы видите DYNAMIC, см. Анализ некешируемых ответов.