Настройка Varnish Cache для ускорения веб-приложения

Отметим: когда ваш веб-сервер начинает задыхаться при пиковых нагрузках, а время ответа (TTFB) превышает 500 мс — это сигнал, что пора внедрять HTTP-акселератор. Varnish Cache перехватывает запросы до backend и отдаёт кэшированные ответы из оперативной памяти. В результате latency снижается до 1–5 мс, а сервер выдерживает десятки тысяч запросов в секунду. Мы — команда с 5-летним опытом в настройке Varnish, реализовавшая более 100 проектов для highload-сервисов. Правильная настройка Varnish улучшает Core Web Vitals (LCP, INP) и может сэкономить до 500 000 рублей в год на серверной инфраструктуре. Типичный hit rate при корректной VCL достигает 95–99%, а время ответа сокращается в 100 раз по сравнению с прямым обращением к backend.

Проблемы, которые решает Varnish

• Высокая нагрузка на backend. Без кэширования каждый запрос обрабатывается приложением — база данных, рендеринг, бизнес-логика. Varnish снимает до 90% нагрузки, обслуживая кэшированные страницы напрямую.
• Медленные динамические страницы. Даже если страница генерируется 200 мс, при 1000 параллельных запросах время ожидания растет. Varnish с фрагментарным кэшированием (ESI) позволяет кэшировать общую часть, а персонализированные блоки подгружать асинхронно. Это сокращает время генерации страницы на 60–80%.
• Нестабильная работа при пиках трафика. Varnish выступает буфером: если backend временно недоступен, отдаётся устаревшая копия (grace mode). Это предотвращает простои и ошибки 503.

Как Varnish улучшает Core Web Vitals?

Core Web Vitals — метрики, от которых зависит ранжирование в Google. Varnish напрямую влияет на Largest Contentful Paint (LCP) и Interaction to Next Paint (INP). При кэшировании HTML-страниц LCP падает с 2–3 секунд до 200–300 мс. INP улучшается за счёт того, что сервер быстрее отдаёт контент, уменьшая задержку для скриптов. На одном из проектов hit rate вырос с 40% до 98% после корректировки VCL.

Grace mode: зачем он нужен?

Grace mode — это механизм, позволяющий отдавать устаревший кэш, если backend не ответил вовремя. Как указано в документации Varnish: Grace mode позволяет отдавать устаревший кэш, предотвращая ошибки 503. Настройка beresp.grace = 6h даёт 6 часов на восстановление, в течение которых Varnish продолжает отдавать старую копию. Это критично для highload-проектов, где каждая секунда простоя стоит денег.

Когда Varnish не нужен?

Varnish не эффективен для сайтов с полностью персонализированным контентом (личный кабинет, онлайн-банкинг), где каждый запрос требует уникальных данных. В таких случаях лучше использовать кэширование на уровне приложения (Redis, Memcached) или CDN. Однако даже для таких проектов Varnish может кэшировать статику и общие блоки.

Базовая конфигурация VCL

# Debian/Ubuntu apt install varnish # /etc/varnish/default.vcl 

vcl 4.1; import std; backend default { .host = "127.0.0.1"; .port = "8080"; .first_byte_timeout = 60s; .connect_timeout = 5s; .between_bytes_timeout = 10s; } # Несколько бэкендов с балансировкой import directors; backend app1 { .host = "10.0.0.1"; .port = "8080"; } backend app2 { .host = "10.0.0.2"; .port = "8080"; } sub vcl_init { new cluster = directors.round_robin(); cluster.add_backend(app1); cluster.add_backend(app2); } sub vcl_recv { set req.backend_hint = cluster.backend(); # Нормализация URL (удалить trailing slash кроме корня) if (req.url ~ "^(/[^?]+)/$") { set req.url = regsub(req.url, "/$", ""); } # Не кэшировать admin-панель if (req.url ~ "^/admin") { return (pass); } # Не кэшировать авторизованных пользователей (если контент персонализирован) if (req.http.Authorization || req.http.Cookie ~ "session_id|auth_token") { return (pass); } # Удалить маркетинговые параметры из ключа кэша set req.url = regsuball(req.url, "(\\?|&)(utm_source|utm_medium|utm_campaign|utm_content|fbclid|gclid)=[^&]+", ""); set req.url = regsub(req.url, "\\?&", "?"); set req.url = regsub(req.url, "\\?$", ""); # Нормализовать Accept-Encoding if (req.http.Accept-Encoding) { if (req.url ~ "\\.(gif|jpg|jpeg|png|webp|avif|ico|zip|gz|mp4)$") { unset req.http.Accept-Encoding; } elsif (req.http.Accept-Encoding ~ "br") { set req.http.Accept-Encoding = "br"; } elsif (req.http.Accept-Encoding ~ "gzip") { set req.http.Accept-Encoding = "gzip"; } else { unset req.http.Accept-Encoding; } } } sub vcl_backend_response { # Кэшировать 404 ненадолго if (beresp.status == 404) { set beresp.ttl = 30s; return (deliver); } # Кэшировать только успешные ответы if (beresp.status != 200 && beresp.status != 301 && beresp.status != 302) { set beresp.uncacheable = true; return (deliver); } # Если backend не прислал Cache-Control — установить по умолчанию if (!beresp.http.Cache-Control) { if (bereq.url ~ "\\.(css|js|woff2|png|jpg|svg)$") { set beresp.ttl = 30d; } else { set beresp.ttl = 5m; } } # Grace period: отдавать устаревший кэш при backend сбое set beresp.grace = 6h; # Сжатие if (beresp.http.content-type ~ "text/(html|css|javascript|xml|plain)" || beresp.http.content-type ~ "application/(json|javascript)") { set beresp.do_gzip = true; } # Не хранить Set-Cookie в кэше unset beresp.http.Set-Cookie; } sub vcl_deliver { # Debug заголовок (отключить в production) if (obj.hits > 0) { set resp.http.X-Cache = "HIT " + obj.hits; } else { set resp.http.X-Cache = "MISS"; } # Скрыть внутренние заголовки от клиента unset resp.http.X-Varnish; unset resp.http.Via; unset resp.http.X-Powered-By; } sub vcl_hit { if (obj.ttl >= 0s) { return (deliver); } # Grace: отдать устаревший объект if (obj.ttl + obj.grace > 0s) { return (deliver); } return (restart); } 

Инвалидация кэша: PURGE, BAN, ESI

acl purge_acl { "127.0.0.1"; "10.0.0.0"/8; } sub vcl_recv { if (req.method == "PURGE") { if (!client.ip ~ purge_acl) { return (synth(405, "Not allowed")); } return (purge); } if (req.method == "BAN") { if (!client.ip ~ purge_acl) { return (synth(405, "Not allowed")); } ban("req.http.host == " + req.http.host + " && req.url ~ " + req.url); return (synth(200, "Ban added")); } } 

Использование из приложения:

# Инвалидировать конкретный URL curl -X PURGE http://localhost/page/about # Инвалидировать по паттерну (BAN) curl -X BAN -H "Host: company.com" http://localhost/category/ 

ESI (Edge Side Includes)

sub vcl_backend_response { if (beresp.http.Surrogate-Control ~ "ESI/1.0") { set beresp.do_esi = true; } } 

Процесс настройки, типичные ошибки и что входит в работу

Процесс настройки

1. Аудит приложения: анализ URL, cookies, сессий, частоты обновления.
2. Проектирование VCL: правила кэширования, TTL, grace, ESI.
3. Тестирование на staging: замер hit rate, нагрузка на backend.
4. Деплой: настройка systemd, выделение памяти, мониторинг.
5. Мониторинг и оптимизация: varnishstat, Prometheus, корректировка VCL.

Типичные ошибки и рекомендации

Что входит в работу

• Аудит текущей архитектуры и выявление узких мест
• Проектирование и написание VCL-конфигурации с учётом специфики проекта
• Настройка балансировки и grace mode
• Реализация PURGE/BAN-инвалидации и ESI при необходимости
• Тестирование на staging и замер производительности
• Деплой в production и настройка мониторинга (Prometheus + Grafana)
• Документация и обучение команды
• Гарантийная поддержка после внедрения

Сроки и стоимость

Базовая настройка Varnish с типовой VCL занимает 1–2 рабочих дня. Для проектов с нестандартной архитектурой, ESI или сложными правилами инвалидации — 2–3 дня. Стоимость рассчитывается индивидуально после аудита. Средняя экономия серверных ресурсов — 30-40%, что снижает расходы на хостинг на 200 000-400 000 руб. в год.

Закажите настройку Varnish и получите консультацию — мы поможем увеличить производительность вашего сайта. Свяжитесь с нами, чтобы обсудить ваш проект.

Для углублённого изучения VCL мы рекомендуем документацию Varnish.