Cloudflare `BYPASS` замість хибного `MISS`: як швидко зрозуміти, чому asset не кешується

Зачіпка

Іноді найгірше в дебагу кешу не сама проблема, а хибний сигнал. Якщо CF-Cache-Status показує щось, що виглядає як MISS, легко витратити час на не той шар і почати шукати поломку там, де її немає.

Cloudflare 2026-05-26 змінив саме це: некешовані відповіді тепер чіткіше позначаються як BYPASS. Для практичної команди це означає простішу діагностику: якщо відповідь не кешується свідомо, статус більше не маскує це під звичайний miss.

Що змінилося

CF-Cache-Status не існує для краси. Його задача - швидко показати, що відбулося з конкретною відповіддю на edge.

Після зміни Cloudflare розвів два сценарії:

• MISS - відповідь не була знайдена на edge, але може бути кешованою;
• BYPASS - Cloudflare вирішив не кешувати відповідь.

Це важливо, бо старе змішування цих двох сигналів змушувало людей думати, що “кеш не працює”, коли насправді origin або правила робили відповідь некешованою за визначенням.

На що дивитися першим

Порядок перевірки має бути дуже приземленим:

1. Подивіться на response headers

Найчастіші причини некешованої відповіді - це:

• Cache-Control: no-cache
• Cache-Control: private
• Cache-Control: max-age=0
• Set-Cookie
• Authorization

Якщо один із цих сигналів є в response, BYPASS може бути нормальним і очікуваним.

2. Перевірте розмір asset

Не кожна відповідь підходить для кешування. Якщо asset занадто великий або виходить за ліміти вашого плану чи default behavior, проблема не в “зламаному” CDN.

3. Подивіться, чи не втручаються Cache Rules

Якщо origin headers виглядають нормально, але поведінка все одно дивна, наступний шар - Cache Rules. Саме вони можуть перевизначати очікуваний результат для окремих URL.

4. Зробіть швидку перевірку через curl -I

Для першого контакту з проблемою цього часто достатньо:

curl -I https://example.com/asset.css

Після цього дивіться на CF-Cache-Status, Cache-Control, Set-Cookie і Authorization.

Як читати статуси без самообману

Найкорисніша зміна тут не в самому слові BYPASS, а в тому, що воно зменшує двозначність.

• Якщо бачите BYPASS, шукайте причину, чому відповідь не має кешуватися.
• Якщо бачите MISS, перевіряйте, чи відповідь взагалі cacheable і просто ще не була на edge.
• Якщо бачите HIT, кеш спрацював так, як очікувалося.

Тобто MISS після цієї зміни ближче до “cacheable, but not in edge yet”, а не до “Cloudflare щось зламав”.

Практичний порядок дій

Ось мінімальний набір кроків, який не витрачає час даремно:

1. Запустити curl -I для проблемного URL.
2. Перевірити Cache-Control, Set-Cookie і Authorization.
3. З’ясувати, чи asset не перевищує ліміти cacheable size.
4. Подивитися, чи є Cache Rules, що змінюють поведінку.
5. Якщо причина все ще не ясна, уже переходити до deeper debugging.

Цей порядок хороший тим, що він спочатку перевіряє найбільш імовірні причини, а не веде команду в абстрактну “CDN troubleshooting” без кінця.

Що BYPASS не робить

BYPASS не лікує кеш магічно і не означає, що Cloudflare зламався.

Він лише робить сигнал чеснішим:

• якщо відповідь некешована за правилами, це видно одразу;
• якщо response cacheable, але його немає на edge, ви побачите іншу картину;
• якщо причина в origin headers, ви знайдете її раніше.

Короткий висновок

Найкраще мислити так:

1. BYPASS = відповідь не повинна кешуватися;
2. MISS = cacheable відповідь ще не була на edge;
3. спочатку перевіряйте headers, потім size, потім Cache Rules;
4. не плутайте діагностичний сигнал з поломкою.

Саме тому зміна від Cloudflare корисна не тільки як product update, а як невеликий, але дуже практичний крок до швидшого root-cause analysis.

Джерела

• Cloudflare Changelog: https://developers.cloudflare.com/changelog/post/2026-05-26-bypass-status-for-uncacheable-responses/
• Cloudflare Docs: https://developers.cloudflare.com/cache/concepts/cache-responses/
• Cloudflare Docs: https://developers.cloudflare.com/cache/concepts/default-cache-behavior/
• Cloudflare Docs: https://developers.cloudflare.com/cache/concepts/cache-control/