Полное руководство: очистка и инвалидация кеша Nginx в 2026 году

Зачем и когда нужно очищать кеш Nginx

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

Основные сценарии для очистки:

Обновление статического контента (CSS, JS, изображений) или шаблонов на сайте.
Изменение логики генерации динамических страниц или ответов API.
Обнаружение ошибки, которая была закеширована и распространилась среди пользователей.
Плановый деплой новой версии приложения.
Смена домена или структуры URL, когда старый кеш становится нерелевантным.

Как работает кеширование в Nginx и где хранятся данные

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

proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=my_cache:10m max_size=1g inactive=60m;

Директория /var/cache/nginx содержит файлы, организованные по уровням (levels) для оптимизации поиска. Каждый файл соответствует уникальному ключу кеша (proxy_cache_key), который обычно формируется из схемы запроса, метода, хоста и URI. Для детального понимания механизмов кеширования обратитесь к шпаргалке по директивам кеширования Nginx, где собраны все параметры с пояснениями.

Метод 1: Ручная очистка кеша через файловую систему

Это самый прямой способ: удалить файлы кеша из директории, указанной в proxy_cache_path. Метод универсален, не требует изменения конфигурации и работает на любой версии Nginx.

Поиск и безопасное удаление файлов кеша

Определите путь к кешу из конфигурации Nginx. Затем выполните команды для удаления. Рекомендуется сначала остановить или перезагрузить Nginx, чтобы избежать конфликтов при одновременном чтении и удалении файлов.

# Найдите путь к кешу в конфигах
nginx -T | grep proxy_cache_path

# Остановите Nginx (или перезагрузите конфиг)
systemctl stop nginx
# ИЛИ
nginx -s reload

# Удалите все файлы кеша (осторожно!)
find /var/cache/nginx -type f -delete

# Проверьте освобождение места
df -h /var/cache/nginx

# Запустите Nginx
systemctl start nginx

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

Плюсы, минусы и когда выбирать этот метод

Плюсы:

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

Минусы:

Требует прямого доступа к файловой системе сервера (обычно по SSH).
«Грубый» подход: удаляет все данные без возможности фильтрации.
Временно увеличивает нагрузку на бэкенд, так как каждый новый запрос будет обрабатываться без кеша.
Если Nginx не остановлен, могут возникнуть ошибки при одновременном удалении и чтении файлов.

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

Метод 2: Программная инвалидация через модуль ngx_cache_purge

Модуль ngx_cache_purge предоставляет программный интерфейс для очистки кеша через HTTP запросы. Это основной рекомендуемый способ для production-сред, позволяющий выполнять точечную инвалидацию и интегрировать процесс в автоматизированные пайплайны.

Установка и настройка модуля ngx_cache_purge

Для систем Ubuntu/Debian модуль часто доступен в стандартных репозиториях:

apt install nginx-module-purge

Для CentOS/RHEL или если модуль отсутствует в репозитории, потребуется компиляция Nginx из исходников с включением модуля. После установки добавьте в конфигурацию сервера или location блок для обработки запросов на очистку.

location ~ /purge(/.*) {
    # Ограничение доступа по IP - критически важно для безопасности!
    allow 192.168.1.0/24; # Ваши внутренние IP или IP CI/CD сервера
    allow 10.0.0.1;
    deny all;

    proxy_cache_purge my_cache $scheme$host$1$is_args$args;
}

Директива proxy_cache_purge принимает имя зоны кеша (my_cache) и ключ для очистки. В примере ключ формируется из схемы, хоста и URI запроса ($1 содержит часть URI после /purge). После добавления конфигурации проверьте её и перезагрузите Nginx.

nginx -t
systemctl reload nginx

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

Примеры запросов для точечной и массовой очистки

Очистка конкретного URL:

curl -X PURGE http://your-site.com/purge/https://your-site.com/api/v1/data

Очистка группы URL по маске (если модуль поддерживает):

# Очистка всех URL, начинающихся с /api/
curl -X PURGE http://your-site.com/purge/https://your-site.com/api/

Массовая очистка из файла со списком URL:

while read url; do
    curl -s -X PURGE "http://your-site.com/purge/$url"
done < urls_to_purge.txt

Модуль возвращает код 200 при успешной очистке и 404 если указанный ключ не найден в кеше.

Метод 3: Условный байпас и коммерческое решение (nginx-plus)

Помимо прямой очистки, можно управлять использованием кеша через условный байпас или использовать коммерческий продукт с расширенным API.

Использование proxy_cache_bypass для контроля кеширования

Директива proxy_cache_bypass не удаляет данные из кеша, но указывает Nginx игнорировать кешированный ответ для конкретного запроса и обратиться к бэкенду. Это полезно для разработчиков или для обновления контента для определенных пользователей.

location / {
    proxy_cache my_cache;
    proxy_cache_bypass $http_cache_purge; # Обход кеша если заголовок "Cache-Purge" равен 1
    ...
}

Теперь запрос с заголовком Cache-Purge: 1 получит свежий ответ от бэкенда, минуя кеш. Этот метод часто комбинируется с стратегиями кеширования динамического контента для тонкого контроля.

Краткий обзор возможностей nginx-plus для purge

Коммерческая версия Nginx, nginx-plus, включает полнофункциональный API управления кешем. Через REST API можно выполнять точечную очистку, получать статистику и управлять несколькими зонами кеша.

# Пример запроса к API nginx-plus для очистки кеша
curl -X DELETE "https://nginx-plus-api/api/6/http/caches/my_cache" \
     -H "Authorization: Bearer "

API позволяет фильтровать объекты для очистки по различным критериям, что невозможно в базовом модуле purge. Это решение подходит для корпоративных сред с высокой нагрузкой и сложными требованиями к управлению.

Автоматизация очистки кеша в CI/CD пайплайнах

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

Пример: Интеграция purge в GitHub Actions

Вот пример job для GitHub Actions, который отправляет запрос на очистку кеша после деплоя.

jobs:
  deploy-and-purge:
    runs-on: ubuntu-latest
    steps:
      - name: Deploy to production
        # Ваши шаги деплоя...

      - name: Purge Nginx cache
        run: |
          PURGE_URL="${{ secrets.PURGE_URL }}"
          # Очистка главной страницы и ключевых API endpoints
          curl -f -X PURGE "$PURGE_URL/https://your-site.com/"
          curl -f -X PURGE "$PURGE_URL/https://your-site.com/api/v1/"
          echo "Cache purge completed"

URL для очистки хранится в Secrets проекта для безопасности. Флаг -f в curl заставляет команду завершиться с ошибкой если запрос не удался, что важно для обработки ошибок в пайплайне.

Безопасность и надежность автоматического сценария

Ключевые риски автоматизации:

Несанкционированный доступ к endpoint очистки. Решение: строгое ограничение по IP (allow/deny в конфиге Nginx) и использование токенов аутентификации если возможно.
Сбой очистки, приводящий к остаточному старым данным в кеше. Решение: реализация плана «Б» - отправка alert в мониторинг и возможность запустить ручную очистку.
Очистка нерелевантных данных или слишком широкой области. Решение: точное определение списка URL для очистки, тестирование сценария на staging-окружении.

Для Jenkins или GitLab CI логика аналогична: отдельный шаг в пайплайне, который выполняет curl запросы к защищенному endpoint purge.

Сводная таблица: Какой метод выбрать для вашей задачи

Метод	Сложность настройки	Точность (точечная/массовая)	Подходит для автоматизации	Безопасность	Рекомендуемый сценарий
Ручная очистка через ФС	Низкая	Массовая (все)	Нет	Средняя (риск удалить лишнее)	Аварийная ситуация, разовая полная очистка, отсутствие других методов
Модуль ngx_cache_purge	Средняя	Точечная и массовая	Да	Высокая (при правильном ограничении IP)	Production-среда, регулярные деплои, автоматизация в CI/CD
proxy_cache_bypass	Низкая	Условная (для запроса)	Да (через заголовки)	Высокая	Контроль кеша для разработчиков, обновление контента для сегмента пользователей
nginx-plus API	Высокая (стоимость, интеграция)	Точечная с фильтрацией	Да	Высокая (API с аутентификацией)	Корпоративные среды с высокими требованиями к управлению и мониторингу

Для большинства production-сред оптимальным выбором является модуль ngx_cache_purge с правильно настроенными ограничениями доступа. Он обеспечивает баланс между точностью, безопасностью и возможностью автоматизации. Ручная очистка остается аварийным инструментом. Метод proxy_cache_bypass дополняет purge для тонкого контроля. Nginx-plus - решение для enterprise, где критичны расширенный мониторинг и фильтрация.

Выбор технологии кеширования также влияет на стратегии инвалидации. Для комплексного сравнения подходов ознакомьтесь с сравнением технологий кеширования для Nginx.