Серверное кэширование: как разделить слои HTTP и данных (FastCGI, Redis, OPcache)

Высокое время отклика сервера (TTFB) и внезапные падения сайтов под наплывом трафика чаще всего вызваны хаотичной настройкой кэширования. Установка случайных плагинов для CMS без понимания серверного стека приводит к переполнению RAM, утечке приватных данных между пользователями и эффекту лавинного запроса (Cache Stampede).

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

Решение проблемы — кэширование на самом сервере. Но главная ошибка при его настройке — пытаться выбрать «победителя» между Varnish, Redis и Memcached. Это инструменты для разных слоев архитектуры.

4-уровневая пирамида кэширования: где экономить ресурсы

Каждый уровень кэширования отсекает до 70–90% входящих запросов до того, как они дойдут до дисковой подсистемы или базы данных:

[opcache]
; Включение модуля
opcache.enable = 1
opcache.enable_cli = 0

; Выделенный объем оперативной памяти под опкоды (в МБ)
opcache.memory_consumption = 256

; Объем памяти под интернированные строки (ключи массивов, имена функций)
opcache.interned_strings_buffer = 64

; Максимальное количество кэшируемых PHP-файлов
opcache.max_accelerated_files = 20000

; Проверка изменений файлов на диске (0 для Production, 1 для разработки)
opcache.validate_timestamps = 0
opcache.revalidate_freq = 60

; Оптимизация системных вызовов
opcache.save_comments = 1
opcache.fast_shutdown = 1

# Ограничение максимального объема RAM под кэш
maxmemory 512mb

# Политика вытеснения: удалять наименее используемые ключи при заполнении памяти
maxmemory-policy allkeys-lru

# Переход на локальный UNIX-сокет вместо TCP для снижения latency
unixsocket /var/run/redis/redis.sock
unixsocketperm 770

http {
    # Путь к кэшу, структура папок, имя зоны, лимит RAM под ключи и лимит на диске
    fastcgi_cache_path /var/run/nginx-cache levels=1:2 keys_zone=PAGE_CACHE:100m inactive=60m max_size=1g;
    fastcgi_cache_key "$scheme$request_method$host$request_uri";
    
    # Исключение типовых сценариев из кэширования
    map $request_uri $no_cache {
        default 0;
        ~*/wp-admin/ 1;
        ~*/cart/ 1;
        ~*/checkout/ 1;
        ~*/xmlrpc.php 1;
    }
}

server {
    listen 443 ssl http2;
    server_name domain.com;

    set $skip_cache 0;

    # Не кэшировать POST-запросы
    if ($request_method = POST) {
        set $skip_cache 1;
    }
    
    # Не кэшировать запросы с GET-параметрами (поисковые запросы)
    if ($query_string != "") {
        set $skip_cache 1;
    }

    # Не кэшировать авторизованных пользователей и корзину
    if ($http_cookie ~* "comment_author|wordpress_[a-f0-9]+|wp-postpass|wordpress_logged_in|woocommerce_items_in_cart") {
        set $skip_cache 1;
    }

    # Проверка условий из глобального блока map
    if ($no_cache = 1) {
        set $skip_cache 1;
    }

    location ~ \.php$ {
        include snippets/fastcgi-php.conf;
        fastcgi_pass unix:/var/run/php/php8.2-fpm.sock;

        fastcgi_cache PAGE_CACHE;
        fastcgi_cache_valid 200 301 302 60m;
        fastcgi_cache_use_stale error timeout updating invalid_header http_500;
        fastcgi_cache_bypass $skip_cache;
        fastcgi_no_cache $skip_cache;

        # Служебный заголовок для проверки статуса кэша (HIT / MISS / BYPASS)
        add_header X-FastCGI-Cache $upstream_cache_status;
    }
}

Взаимосвязь локального кэша и глобального Edge CDN

Локальные слои кэширования (OPcache, Redis, Nginx) формируют ответ за минимальное время (2–10 мс). Однако для доставки контента удаленным пользователям без сетевых задержек необходима синхронизация с пограничной сетью CDN.

[ Бэкенд генерирует HTTP-заголовок ] ──► Cache-Control: public, max-age=604800, s-maxage=2592000
                                                        │
                                                        ▼
[ Cloudflare Edge CDN ] ──► Сохраняет HTML на 30 дней в 200+ городах мира

• Через директиву s-maxage в заголовке Cache-Control бэкенд сообщает серверам Cloudflare, сколько времени удерживать динамическую страницу в глобальном кэше.

• Локальный Nginx FastCGI Cache обрабатывает запросы только тогда, когда на пограничных серверах Cloudflare происходит промах кэша (Cache MISS).

Пошаговая настройка кэширования динамического HTML на стороне CDN разобрана в руководстве «Тонкая настройка Cloudflare: как ускорить сайт для зарубежной аудитории».

Автоматизировать установку веб-сервера Nginx, PHP-FPM и настройку виртуальных хостов на пуле серверов позволяет готовый Ansible-плейбук для массового развертывания LEMP.

Чек-лист: аудит слоев кэширования сервера

• Модуль PHP OPcache активирован, объем memory_consumption соответствует размеру кодовой базы, а параметр validate_timestamps переведен в режим 0 на production-сервере.

• Служба Redis настроена с политикой вытеснения maxmemory-policy allkeys-lru и подключена через локальный UNIX-сокет.

• Настроен полностраничный кэш Nginx FastCGI Cache с условиями обхода для авторизованных пользователей и страниц оформления заказа.

• В конфигурации Nginx включены директивы fastcgi_cache_lock on; и fastcgi_cache_use_stale updating; для защиты от лавинных нагрузок (Cache Stampede).

• Проверен статус ответа сервера через заголовок X-FastCGI-Cache: HIT при повторном гостевом запросе.

• Настроены заголовки Cache-Control для синхронизации локального кэша с пограничной сетью Edge CDN.

Что делать дальше: следующие шаги

• Для настройки пограничного кэширования страниц на серверах CDN ➔ изучите руководство «Тонкая настройка Cloudflare: правила Cache Rules и WAF».

• Для автоматизации развертывания веб-стека на новых серверах ➔ используйте «Ansible-playbook для массовой настройки 50+ VPS».

• Для базовой защиты операционной системы и блокировки брутфорса ➔ выполните чек-лист «Харденинг Ubuntu: настройка ed25519-ключей, UFW и Fail2ban».