Полная настройка кеширования Nginx: практическое руководство для DevOps и системных администраторов (2026)

Кеширование в Nginx - это проверенный метод ускорения веб-сайтов и API, который разгружает backend-серверы и сокращает время отклика для пользователей. Это руководство содержит готовые, безопасные конфигурации для типовых сценариев: от статических файлов до динамических страниц и API. Вы получите конкретные значения TTL, стратегии принудительной инвалидации кеша и инструкции по мониторингу эффективности через хитрейт. Все примеры проверены на практике и адаптированы под требования 2026 года.

Основы кеширования в Nginx: как это работает и зачем нужно

Nginx использует модель кеширования на основе ключей. Каждый входящий запрос анализируется, и для него генерируется уникальный ключ на основе заданных параметров (URI, заголовков). Этот ключ используется для поиска ответа в специально выделенной области памяти и на диске - кеш-зоне. Результат запроса может иметь один из статусов: HIT (найден в кеше), MISS (не найден, запрос пошел на бэкенд), BYPASS (кеширование обошли по правилу), EXPIRED (срок жизни кеша истек). Основные преимущества - снижение нагрузки на бэкенд на 70-90% для статики и до 50% для динамического контента, уменьшение времени отклика с сотен миллисекунд до единиц. Nginx учитывает HTTP-заголовки Cache-Control и Expires от бэкенда, но его директивы позволяют переопределить это поведение.

Ключевые директивы proxy_cache_path и proxy_cache: основа конфигурации

Директива proxy_cache_path определяет зону кеша. Ее параметры задают физическое расположение, структуру и политики управления.

proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=my_cache:10m max_size=1g inactive=60m use_temp_path=off loader_threshold=300 loader_files=200;

path (/var/cache/nginx): Директория для хранения файлов кеша.
levels (1:2): Уровни вложенности поддиректорий для оптимизации файловой системы при большом количестве объектов (например, 1 символ:2 символа).
keys_zone (my_cache:10m): Имя зоны и объем оперативной памяти под метаданные ключей. 10МБ хватает примерно для 80 тысяч ключей.
max_size (1g): Максимальный размер кеша на диске. При превышении активируется процесс очистки наименее востребованных данных.
inactive (60m): Время, после которого невостребованный объект удаляется с диска, даже если его TTL не истек.
use_temp_path=off: Записывает файлы напрямую в целевую директорию, минуя временную, что повышает производительность.
loader_threshold, loader_files: Параметры фонового процесса загрузки кеша при старте Nginx.

Директива proxy_cache активирует кеширование для конкретного контекста (location, server), указывая на созданную зону.

location / {
    proxy_pass http://backend;
    proxy_cache my_cache;
    proxy_cache_valid 200 302 10m;
    add_header X-Cache-Status $upstream_cache_status;
}

Это минимальная рабочая конфигурация. Она кеширует успешные ответы (код 200) и редиректы (302) на 10 минут и добавляет в ответ заголовок со статусом кеширования.

Готовые и безопасные конфигурации для типовых сценариев

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

Кеширование статического контента (CSS, JS, изображения)

Для ресурсов, которые редко меняются, применяется длительный TTL. Критически важно исключить кеширование для авторизованных пользователей.

location ~* \.(css|js|jpg|jpeg|png|gif|ico|svg|woff2)$ {
    proxy_pass http://backend;
    proxy_cache my_static_cache;
    proxy_cache_key "$scheme$proxy_host$request_uri";
    proxy_cache_valid 200 1y;
    proxy_cache_bypass $cookie_session $http_authorization;
    add_header X-Cache-Status $upstream_cache_status;
    expires max;
}

proxy_cache_key: Формирует ключ из схемы, имени проксируемого хоста и URI. Для версионированных файлов (style.v2.css) этого достаточно.
proxy_cache_valid 200 1y: Устанавливает время жизни кеша для успешных ответов в 1 год. Это допустимо при использовании версионирования имен файлов или хешей в query-параметрах.
proxy_cache_bypass: Директива обходит кеш, если присутствует кука сессии ($cookie_session) или заголовок авторизации. Это гарантирует, что персональные данные не попадут в общий кеш.
expires max: Устанавливает для браузера клиента заголовок Expires с максимально далекой датой, активируя долгосрочное браузерное кеширование.

Для более глубокого погружения в тему кеширования статики изучите наше отдельное руководство с готовыми конфигурационными блоками.

Кеширование динамических страниц и ответов API

Кеширование динамического контента требует осторожности. Ключ должен включать уникальные идентификаторы сессий, а мутирующие запросы нужно исключать.

location /api/v1/products {
    proxy_pass http://backend_api;
    proxy_cache my_api_cache;
    proxy_cache_key "$scheme$proxy_host$request_uri$cookie_locale";
    proxy_cache_valid 200 5m;
    proxy_cache_valid 404 1m;
    proxy_no_cache $http_authorization $request_method POST;
    proxy_cache_bypass $http_cache_purge;
    add_header X-Cache-Status $upstream_cache_status;
}

proxy_cache_key: Включает локаль пользователя из куки ($cookie_locale), чтобы кешировать разные языковые версии отдельно. Добавлять куки сессии в ключ опасно - это создаст отдельный кеш для каждого пользователя.
proxy_cache_valid: Разные TTL для разных кодов ответа. Успешный ответ (200) живет 5 минут, ответ «Не найдено» (404) - 1 минуту, чтобы не засорять кеш несуществующими путями.
proxy_no_cache: Запрещает сохранение в кеш ответов, содержащих заголовок авторизации, а также ответов на все POST-запросы. Это базовая защита от кеширования персональных данных или результатов операций изменения.
proxy_cache_bypass: Обход кеша при наличии специального заголовка Cache-Purge, который можно отправлять из CI/CD при деплое.

Для сложных случаев, например, кеширования AJAX-запросов в современных SPA, обратитесь к руководству по динамической загрузке контента и настройке кеширования в Nginx.

Оптимальные значения TTL и стратегии принудительной инвалидации кеша

Рекомендации по времени жизни кеша (TTL) зависят от волатильности контента:

Статические файлы с версионированием: 1 год. Инвалидация происходит через изменение имени файла (style.v2.css).
Главная страница, статьи блога: от 5 до 30 минут.
Листинги товаров, новостные ленты: от 1 до 10 минут.
Цены, баланс пользователя: от 1 секунды до 1 минуты или полное отключение кеширования.
Ответы API: от 1 секунды (для высоковолатильных данных) до 10 минут (для справочников).

Значения задаются директивой proxy_cache_valid. Инвалидация - принудительная очистка кеша до истечения TTL - необходима при обновлении контента.

Методы инвалидации: от purge-модуля до кастомных ключей

Самый эффективный метод - использование стороннего модуля ngx_cache_purge. После его установки и компиляции настройте специальный location.

location ~ /purge(/.*) {
    allow 127.0.0.1;
    allow 10.0.0.0/8;
    deny all;
    proxy_cache_purge MYCACHE "$scheme$proxy_host$1";
}

Запрос curl -X PURGE http://example.com/purge/api/products удалит кеш для указанного URI. Метод «смены ключа» требует изменения proxy_cache_key в конфигурации (например, добавить версию $cache_version) и перезагрузки Nginx. Для экстренных случаев подходит ручное удаление файлов из директории кеша командой rm -rf /var/cache/nginx/* с последующей отправкой сигнала nginx -s reload.

Мониторинг эффективности: как анализировать хитрейт и статусы кеша

Чтобы оценить эффективность, добавьте в ответ заголовок со статусом кеширования: add_header X-Cache-Status $upstream_cache_status;. Его значения:

HIT: Ответ взят из кеша. Цель - максимизировать этот показатель.
MISS: Ответа не было в кеше, запрос ушел на бэкенд.
BYPASS: Кеш был обойден по правилу proxy_cache_bypass.
EXPIRED: Найденный в кеше объект устарел (истек TTL), запрос ушел на бэкенд для обновления.
STALE: Устаревший объект отдан клиенту, потому что бэкенд недоступен (при использовании proxy_cache_use_stale).
UPDATING: Объект устарел, и в данный момент другой запрос уже обновляет его из бэкенда.

Хитрейт (Hit Ratio) рассчитывается как HIT / (HIT + MISS + EXPIRED) * 100%. Для статики хороший показатель - выше 90%, для динамики - 50-80%. Логируйте переменную $upstream_cache_status для детального анализа в системах типа ELK.

Интеграция с заголовками бэкенда (Cache-Control) и приоритет директив

Nginx обрабатывает заголовки кеширования от бэкенда по четкому приоритету:

X-Accel-Expires: Заголовок, отправляемый бэкендом специально для Nginx. Имеет наивысший приоритет. Значение 0 отключает кеширование, отрицательное - кеширует навсегда.
proxy_cache_valid: Директива Nginx. Используется, если X-Accel-Expires не установлен или равен 0.
Cache-Control и Expires: Стандартные HTTP-заголовки. Учитываются, если предыдущие два способа не задали TTL.

Чтобы полностью контролировать TTL со стороны Nginx и игнорировать заголовки приложения, используйте директиву proxy_ignore_headers.

proxy_ignore_headers Cache-Control Expires Set-Cookie;
proxy_cache_valid 200 10m;

Эта конфигурация заставит Nginx кешировать успешные ответы на 10 минут, даже если бэкенд отправил Cache-Control: no-store. Используйте эту настройку осторожно и только при полном понимании логики работы приложения.

Тонкая настройка производительности и надежности кеш-зоны

Для высоконагруженных проектов параметры proxy_cache_path требуют детальной настройки.

levels=1:2: Для кеша в миллионы объектов используйте levels=2:2:2 для лучшего распределения по директориям.
inactive: Установите значение чуть больше максимального ожидаемого TTL для динамического контента, чтобы избежать преждевременного удаления. Например, при TTL=1h установите inactive=70m.
max_size: Контролируйте, чтобы занятое место на диске не превышало 80-90% от раздела. Используйте мониторинг.
proxy_cache_lock on: Включает блокировку. При одновременных запросах на один MISS-ключ только первый запрос пойдет на бэкенд, остальные будут ждать его результата. Это предотвращает «толпу запросов» (thundering herd).
proxy_cache_use_stale: Позволяет отдавать устаревший кеш при ошибках бэкенда, обновлении или таймаутах: proxy_cache_use_stale error timeout updating http_500 http_502 http_503 http_504;.

Для экстремальных нагрузок и работы с миллионами объектов изучите руководство по тонкой настройке Nginx Cache для высоких нагрузок.

Диагностика частых проблем и проверка работоспособности

Типичные ошибки конфигурации:

Кеширование авторизованных страниц. Решение: Добавьте proxy_no_cache $http_authorization $cookie_session; и proxy_cache_bypass для тех же условий.
Кеширование POST-запросов. Решение: Явно укажите proxy_cache_methods GET HEAD; или используйте proxy_no_cache $request_method POST.
Нулевой хитрейт. Причины: Неправильный proxy_cache_key (ключи всегда разные), заголовки Set-Cookie или Vary: * от бэкенда (их можно игнорировать через proxy_ignore_headers), отсутствие прав на запись в директорию кеша.

Методы проверки:

Используйте curl -I http://example.com/page и ищите заголовок X-Cache-Status.
В Chrome DevTools на вкладке Network проверяйте заголовки ответа и размер transferred (при HIT он будет значительно меньше).
Проверьте логи ошибок Nginx: tail -f /var/log/nginx/error.log на наличие сообщений о кеше.
Убедитесь, что у рабочего процесса Nginx есть права на запись в proxy_cache_path.

Если ваше приложение работает с загрузкой больших файлов, убедитесь, что настройки кеширования не конфликтуют с лимитами. В этом поможет статья по оптимизации работы с большими файлами в Nginx.

Выбор технологии кеширования - критичное решение. Чтобы сравнить proxy_cache с альтернативами, такими как FastCGI Cache или Varnish, и принять взвешенное решение, изучите сравнение технологий кеширования для Nginx на основе реальных тестов 2026 года.

Для автоматизации работы с множеством AI-моделей через единый API, что может быть полезно при создании интеллектуальных систем мониторинга или анализа логов, рассмотрите сервис AiTunnel. Он агрегирует более 200 моделей, включая GPT и Claude, и позволяет управлять бюджетами в рублях без необходимости использования VPN.