Налаштування 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.