Кастомні VCL-правила Varnish: прискорення сайту та зниження навантаження

Дефолтна конфігурація Varnish часто працює неефективно: кешує все підряд або не кешує критично важливі сторінки, ігнорує заголовки авторизації та падає на edge-кейсах з cookies. Результат — низький hit rate (30–40%) і надмірне навантаження на бекенд. Якщо ви зіткнулися з такою проблемою, замовте аудит поточної конфігурації Varnish. За 7+ років ми провели понад 50 проєктів з оптимізації та гарантуємо збільшення hit rate до 90%+ при повному збереженні бізнес-логіки. Один із клієнтів — інтернет-магазин з трафіком 500 000 запитів на годину — після впровадження кастомних правил збільшив hit rate з 35% до 93% всього за 2 дні. Це скоротило навантаження на бекенд у 8 разів і заощадило до 70% бюджету на сервери.

Varnish Cache використовує VCL для опису політик кешування.

Як кастомні VCL-правила прискорюють сайт?

Кастомні VCL-правила вирішують конкретні завдання: управління кешем за умовами, нормалізація запитів, обхід CDN для певних маршрутів, маршрутизація на різні бекенди, grace-режим при падінні origin. Розглянемо ключові аспекти.

Нормалізація запитів

Без нормалізації один і той самий ресурс зберігається під десятками ключів: /?utm_source=google, /?utm_source=facebook — це різні записи в кеші, хоча контент ідентичний. За статистикою, URL з utm-мітками займають до 30% кеш-простору марно. Нормалізація вирішує цю проблему.

vcl 4.1; import std; import directors; backend default { .host = "127.0.0.1"; .port = "8080"; .connect_timeout = 2s; .first_byte_timeout = 60s; .between_bytes_timeout = 10s; .probe = { .url = "/healthz"; .timeout = 1s; .interval = 5s; .window = 5; .threshold = 3; } } backend api { .host = "127.0.0.1"; .port = "8081"; .connect_timeout = 1s; .first_byte_timeout = 30s; } sub vcl_recv { # Видаляємо маркетингові параметри if (req.url ~ "(\\?|&)(utm_source|utm_medium|utm_campaign|utm_term|utm_content|fbclid|gclid|yclid|_ga|mc_eid)=") { set req.url = regsuball(req.url, "&(utm_source|utm_medium|utm_campaign|utm_term|utm_content|fbclid|gclid|yclid|_ga|mc_eid)=[^&]*", ""); set req.url = regsuball(req.url, "\\?(utm_source|utm_medium|utm_campaign|utm_term|utm_content|fbclid|gclid|yclid|_ga|mc_eid)=[^&]*&", "?"); set req.url = regsub(req.url, "\\?$", ""); } # Нормалізуємо Accept-Encoding if (req.http.Accept-Encoding) { if (req.url ~ "\\.(jpg|jpeg|png|gif|webp|gz|tgz|bz2|tbz|mp3|ogg|swf|flv|mp4|woff2?)$") { unset req.http.Accept-Encoding; } else if (req.http.Accept-Encoding ~ "br") { set req.http.Accept-Encoding = "br"; } else if (req.http.Accept-Encoding ~ "gzip") { set req.http.Accept-Encoding = "gzip"; } else { unset req.http.Accept-Encoding; } } # Нормалізуємо cookies if (req.http.Cookie) { set req.http.Cookie = ";" + req.http.Cookie; set req.http.Cookie = regsuball(req.http.Cookie, "; +", ";"); set req.http.Cookie = regsuball(req.http.Cookie, ";(session|auth_token|XSRF-TOKEN)=", "; \\1="); set req.http.Cookie = regsuball(req.http.Cookie, ";[^ ][^;]*", ""); set req.http.Cookie = regsuball(req.http.Cookie, "^[; ]+|[; ]+$", ""); if (req.http.Cookie == "") { unset req.http.Cookie; } } # Визначення типу пристрою для адаптивного кешу if (req.http.User-Agent ~ "(?i)mobile|android|iphone|ipod|blackberry|opera mini|iemobile") { set req.http.X-Device-Type = "mobile"; } else { set req.http.X-Device-Type = "desktop"; } # Маршрутизація за типом контенту if (req.url ~ "^/api/") { return(pass); } if (req.http.Authorization || req.http.Cookie ~ "auth_token=") { return(pass); } if (req.method != "GET" && req.method != "HEAD") { return(pass); } if (req.url ~ "\\.(css|js|jpg|jpeg|png|gif|ico|svg|woff|woff2|ttf|eot|webp|avif)(\\?.*)?$") { unset req.http.Cookie; return(hash); } return(hash); } sub vcl_hash { hash_data(req.url); if (req.http.host) { hash_data(req.http.host); } hash_data(req.http.X-Device-Type); return(lookup); } 

Що таке grace-режим і як він працює?

Grace-режим дозволяє віддавати застарілий кеш, поки бекенд перевантажений або тимчасово недоступний. Це критично важливо для високонавантажених сайтів.

sub vcl_backend_response { set beresp.grace = 24h; if (beresp.status >= 500) { set beresp.ttl = 0s; set beresp.grace = 60s; return(deliver); } # Кастомний TTL за типом контенту if (bereq.url ~ "^/news/") { set beresp.ttl = 10m; } else if (bereq.url ~ "^/static/") { set beresp.ttl = 30d; unset beresp.http.Set-Cookie; } else if (bereq.url ~ "^/product/") { set beresp.ttl = 1h; } else { set beresp.ttl = 5m; } if (beresp.http.Cache-Control ~ "no-store|private") { set beresp.uncacheable = true; return(deliver); } } sub vcl_hit { if (obj.ttl >= 0s) { return(deliver); } if (obj.ttl + obj.grace > 0s) { return(deliver); } return(restart); } 

Як реалізувати інвалідацію кешу через VCL?

Purge за тегами (через xkey) — правильний підхід для CMS з залежностями між об'єктами.

import xkey; acl purge_acl { "127.0.0.1"; } sub vcl_recv { if (req.method == "PURGE") { if (!client.ip ~ purge_acl) { return(synth(405, "Not allowed")); } return(purge); } if (req.method == "XKEY-PURGE") { if (!client.ip ~ purge_acl) { return(synth(405, "Not allowed")); } set req.http.n-gone = xkey.softpurge(req.http.xkey-purge); return(synth(200, "Purged " + req.http.n-gone + " objects")); } } sub vcl_backend_response { if (beresp.http.Surrogate-Key) { set beresp.http.xkey = beresp.http.Surrogate-Key; } } 

Порівняння методів інвалідації:

Налагодження та моніторинг

sub vcl_deliver { if (obj.hits > 0) { set resp.http.X-Cache = "HIT"; set resp.http.X-Cache-Hits = obj.hits; } else { set resp.http.X-Cache = "MISS"; } set resp.http.X-Served-By = server.hostname; unset resp.http.X-Powered-By; unset resp.http.Server; unset resp.http.X-Varnish; unset resp.http.Via; } 

# Поточний hit rate varnishstat -f MAIN.cache_hit,MAIN.cache_miss # Живий лог з фільтрацією за URL varnishlog -q 'ReqURL ~ "^/news/"' -g request # Топ cache miss за URL varnishtop -i ReqURL -q 'VCL_call eq "MISS"' 

Чому нормалізація запитів критична для hit rate?

Нормалізація запитів — основа ефективного кешування. Без неї hit rate може бути нижче 50% навіть при правильно налаштованому TTL. Наприклад, URL з utm-мітками займають до 30% кеш-простору марно. Нормалізація також запобігає проблемам з cookie-залежним контентом і невірним кешуванням динамічних сторінок. Кастомні VCL-правила підвищують hit rate в 2-3 рази порівняно з дефолтною конфігурацією, що підтверджується нашими проєктами.

Як налаштувати нормалізацію запитів?

1. Визначте параметри, які потрібно видалити (utm, fbclid, gclid тощо).
2. Напишіть vcl_recv, який очищає ці параметри з req.url.
3. Нормалізуйте Accept-Encoding — пріоритет віддайте br, потім gzip.
4. Обробіть cookies: видаліть всі, крім необхідних для сесії.
5. Додайте device-aware хеш для розділення mobile/desktop.
6. Протестуйте за допомогою varnishtest та моніторингу.

Процес впровадження

Типовий проєкт впровадження кастомних VCL-правил включає етапи:

• Аналітика (1–2 дні): аудит поточного трафіку, аналіз заголовків відповідей бекенду, виявлення некешованих патернів (cookies, Cache-Control: private).
• Проєктування (1 день): розробка архітектури VCL-правил, визначення кеш-ключів, grace-періодів, маршрутизації.
• Реалізація (2–3 дні): написання VCL-скриптів, налаштування health checks, інтеграція з CDN.
• Тестування (1 день): перевірка на стейджингу з varnishtest, заміри hit rate, порівняння з базовою конфігурацією.
• Деплой (1 день): викатка на прод, налаштування моніторингу, документація.

Складні кейси (A/B тестування через Varnish, ESI-включення, багаторівневе кешування з Nginx) додають 3–5 днів.

Що входить в роботу

• Кастомні VCL-правила з урахуванням архітектури проєкту.
• Нормалізація URL, cookies, Accept-Encoding.
• Grace-режим та stale-while-revalidate.
• Інвалідація кешу через PURGE/xkey.
• Інтеграція з CDN та системами деплою.
• Навантажувальне тестування та налаштування моніторингу (varnishstat, metrics).
• Документація щодо впроваджених правил та процесу інвалідації.

Порівняння: дефолтна конфігурація vs кастомні VCL

Замовте аудит поточної конфігурації Varnish — ми визначимо вузькі місця та запропонуємо кастомні рішення. Зв'яжіться з нами для отримання індивідуальної пропозиції.