Caching стратегия: Varnish, Cloudflare и NGINX — где какой слой реально нужен

Caching стратегия: Varnish, Cloudflare и NGINX — где какой слой реально нужен

Если сайт на WordPress или лендингах, не ставьте кэш «везде сразу». Типовая схема: Cloudflare на краю, NGINX как reverse proxy, Varnish только там, где много однотипных HTML-запросов и есть смысл держать отдельный слой перед приложением.

— Cloudflare хорош для статики, TLS, HTTP/2-3, защиты и edge-кеша. Он снимает нагрузку на origin, но не заменяет серверный кэш для персонализированного HTML.
— NGINX cache проще в поддержке: один сервер, один конфиг, быстрый purge через правила. Для небольших проектов это часто достаточно.
— Varnish сильнее на HTML-кэше и гибких правилах, но требует аккуратной инвалидации и дисциплины с cookies, иначе получите «кэш есть, а страниц нет».

Главная ошибка — кэшировать всё подряд без разделения по ролям. Логика такая: публичные страницы — кэшируются агрессивно; админка, корзина, личный кабинет, формы — мимо кэша; AJAX и API — отдельно. Если есть логин, UTM и A/B-тесты, сразу проверьте Vary, cookies и bypass-правила.

Рабочий порядок настройки: сначала включаете edge-кеш на Cloudflare для статики, потом server cache на NGINX или Varnish для HTML, потом уже тюните purge и исключения. Если после этого TTFB почти не падает — проблема не в кэше, а в бэкенде, БД или тяжёлом плагине. Выигрывает не самый сложный стек, а тот, где кэшируемые и не кэшируемые ответы разведены по правилам.