Отметим: когда ваш веб-сервер начинает задыхаться при пиковых нагрузках, а время ответа (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;
}
}
Процесс настройки, типичные ошибки и что входит в работу
Процесс настройки
- Аудит приложения: анализ URL, cookies, сессий, частоты обновления.
- Проектирование VCL: правила кэширования, TTL, grace, ESI.
- Тестирование на staging: замер hit rate, нагрузка на backend.
- Деплой: настройка systemd, выделение памяти, мониторинг.
- Мониторинг и оптимизация: varnishstat, Prometheus, корректировка VCL.
Чек-лист аудита приложения перед настройкой Varnish
- Анализ структуры URL и параметров
- Выявление динамических и статических страниц
- Проверка использования cookies и сессий
- Определение частоты обновления контента
- Выявление узких мест в производительности backend
Типичные ошибки и рекомендации
| Ошибка | Решение |
|---|---|
| Игнорирование нормализации URL | Добавить нормализацию trailing slash в vcl_recv |
| Кэширование авторизованных страниц | Проверять cookies и Authorization header, return(pass) для персонализированного контента |
| Слишком длинный TTL для динамики | Установить разумный TTL (1–5 минут) для страниц с часто меняющимся контентом |
| Тип контента | TTL | Grace | ESI | Пример URL |
|---|---|---|---|---|
| Статика (CSS, JS, картинки) | 30 дней | 12ч | Нет | /static/css/app.css |
| Страницы каталога | 5 минут | 6ч | Да (для фильтров) | /catalog/phones/ |
| Персонализированные страницы | 0 (pass) | - | Нет | /account/ |
Что входит в работу
- Аудит текущей архитектуры и выявление узких мест
- Проектирование и написание 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.