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

Зауважте: коли ваш веб-сервер починає задихатися при пікових навантаженнях, а час відповіді (TTFB) перевищує 500 мс — це сигнал, що час впроваджувати HTTP-акселератор. Varnish Cache перехоплює запити до backend і віддає кешовані відповіді з оперативної пам'яті. В результаті затримка знижується до 1–5 мс, а сервер витримує десятки тисяч запитів на секунду. Ми — команда з 5-річним досвідом у налаштуванні Varnish, яка реалізувала понад 100 проектів для highload-сервісів. Правильне налаштування Varnish покращує Core Web Vitals (LCP, INP). Типовий 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 дні. Вартість розраховується індивідуально після аудиту.

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

Для поглибленого вивчення VCL ми рекомендуємо документацію Varnish.