Reverse proxy кеш — компонент архитектуры веб-приложения, расположенный перед серверами приложений. Принимает HTTP-запросы от клиентов, проверяет наличие ответа в кеше: при попадании (cache hit) отдаёт ответ напрямую из памяти без обращения к бэкенду, при промахе (cache miss) запрашивает бэкенд, сохраняет ответ в кеш и отдаёт клиенту. Для статических страниц cache hit rate 90–99% — типичный результат.
Как работает
nginx proxy_cache — встроенный кеш nginx для проксируемых запросов. Настраивается директивами proxy_cache_path (путь и размер) и proxy_cache (включение). Кешируются ответы бэкенда на GET/HEAD запросы с кодом 200. Время хранения — из заголовка Cache-Control бэкенда или из директивы proxy_cache_valid. nginx хранит кеш на диске с индексом в памяти: операция «отдать закешированный ответ» занимает 1–5 мс вместо 50–500 мс для динамической генерации.
Varnish Cache — специализированный HTTP-акселератор. Хранит весь кеш в RAM (не на диске), что даёт задержку отдачи от 0,1 до 1 мс. Конфигурируется через VCL (Varnish Configuration Language) — мощный и гибкий способ описать правила кеширования, инвалидации, маршрутизации. Varnish ускоряет сайт в 300–1000 раз по сравнению с динамической генерацией. Используется крупными новостными сайтами (Wikipedia использовала Varnish для кеширования миллиардов запросов).
Инвалидация кеша — обновление или удаление устаревших записей. Стратегии: TTL (автоматическое истечение по времени), PURGE (принудительное удаление конкретного URL), BAN (паттерн-инвалидация группы URL). В nginx инвалидация через curl-запрос с методом PURGE (требует модуля ngx_cache_purge). В Varnish — встроенный механизм PURGE/BAN.
Ключи кеша (cache key) — уникальный идентификатор ответа. По умолчанию — Host + URI. Параметры запроса (query string) обычно включаются в ключ. Cookie и заголовок Authorization делают ответы некешируемыми — авторизованный контент индивидуален для каждого пользователя. Это главное ограничение: персонализированные страницы (личный кабинет, корзина) нельзя кешировать стандартным образом.
История
Концепция HTTP-кеширования заложена в RFC 2616 (HTTP/1.1, 1999) — заголовки Cache-Control, ETag, Last-Modified. Varnish разработал Пол-Хеннинг Камп для норвежского VG (Verdens Gang) в 2005 году и выпустил как open-source в 2006-м. nginx добавил модуль proxy_cache в версии 0.7.48 (2008). CDN — глобально распределённая сеть reverse proxy кешей — к 2024 году обрабатывает более 60% мирового веб-трафика.
На что обращать внимание
Включение reverse proxy кеша на VPS — первый шаг оптимизации для WordPress и Bitrix. W3 Total Cache, WP Rocket, LiteSpeed Cache генерируют статические HTML-файлы, которые nginx отдаёт напрямую. Cache hit ratio ниже 50% сигнализирует о проблеме: много уникальных URL-параметров, высокая доля авторизованных запросов, слишком короткий TTL. Для корректной работы с cookies настройте proxy_no_cache и proxy_cache_bypass для запросов с сессионными cookie.
Кэширование в reverse proxy
Nginx proxy_cache: хранит ответы upstream на диске или в памяти. Ключ кэша = URL + заголовки (настраивается). Cache-Control: no-store/private — не кэшировать. Условный сброс кэша: proxy_cache_bypass $cookie_session — не отдавать кэш авторизованным.
Конфигурация Nginx proxy_cache
proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=main:10m max_size=1g inactive=60m. В server block: proxy_cache main; proxy_cache_valid 200 302 10m; proxy_cache_valid 404 1m. Заголовок X-Cache-Status показывает HIT/MISS/BYPASS.
Varnish как специализированный кэш
Varnish Cache — HTTP-ускоритель, хранит кэш в RAM. VCL (Varnish Configuration Language) — гибкая логика кэширования. Стандарт для высоконагруженных CMS: Magento 2 поддерживает Varnish нативно. Nginx — для средних нагрузок; Varnish — когда нужно 10 000+ RPS на кэш.
Reverse proxy кэш в Nginx снижает нагрузку на backend. Работает перед WordPress, Битриксом, Strapi. Redis для кэша объектов дополняет proxy cache. CDN — распределённый reverse proxy cache. Varnish Cache: специализированный для высоконагруженных CMS.