Как установить и настроить кеширование Nginx на VPS

MAATRIX

Каждый одинаковый запрос, который ваш сервер обрабатывает заново, — это лишняя работа для бэкенда и лишние миллисекунды ожидания для пользователя. Кеширование Nginx на VPS убирает эту трату: готовый ответ сохраняется и отдаётся мгновенно, минуя приложение и базу. Разберём, как настроить кеш проксирования и кеш FastCGI, задать разумные сроки жизни и не отдавать посетителям устаревшие страницы.

Зачем нужно кеширование и как оно работает

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

Выгода здесь двойная. Во-первых, резко падает время ответа: отдать файл с диска на порядок быстрее, чем прогнать запрос через PHP и SQL. Во-вторых, снимается нагрузка с бэкенда: под наплывом трафика приложение обслуживает лишь уникальные запросы, а массу повторяющихся берёт на себя Nginx. Это позволяет тому же серверу держать в разы больше посетителей.

Кеширование особенно выгодно для контента, который одинаков для всех: статьи, каталоги, посадочные страницы, ответы API, не зависящие от пользователя. А вот персонализированные страницы — личный кабинет, корзина, лента с учётом входа — кешировать нужно осторожно или не кешировать вовсе, иначе один пользователь увидит данные другого. Понимание этой границы — половина успеха при настройке.

Полезно различать кеш на стороне сервера и кеш в браузере. Заголовки Cache-Control и Expires управляют тем, как долго ответ хранит браузер клиента, — это разгружает канал и ускоряет повторные визиты конкретного пользователя. Кеш Nginx, о котором идёт речь здесь, работает иначе: он общий для всех посетителей и живёт на вашем сервере, снимая нагрузку именно с бэкенда. Две эти техники дополняют друг друга: браузерный кеш экономит трафик, серверный — ресурсы приложения. В идеале настраивают оба, но начинают обычно с серверного, потому что именно он спасает бэкенд под наплывом трафика.

Подготовка VPS и выбор типа кеша

Кеш почти не требует процессора, но любит быстрый диск и немного памяти под метаданные. Для типового сайта хватает VPS с 2 ГБ RAM, а вот диск лучше NVMe: кеш активно читается и пишется, и на медленном HDD выигрыш будет скромнее. Если проект серьёзный и кеш большой, стоит заложить запас по диску под его объём.

В Nginx есть два основных механизма, и выбор зависит от того, как устроено приложение. proxy_cache кеширует ответы бэкенда, к которому Nginx ходит как реверс-прокси, — это универсальный вариант для приложений на Node, Python, любых upstream. fastcgi_cache кеширует ответы PHP-FPM напрямую и используется для PHP-сайтов, включая WordPress и другие CMS. Механика у них одинаковая, различаются лишь директивы.

Локация сервера влияет на итоговую скорость: кеш ускоряет отдачу, но физическое расстояние до пользователя всё равно добавляет пинг. Для российской аудитории ближе RU-площадка, для зарубежной — US или UK. У MAATRIX доступны все три с оплатой из России картой, СБП или криптой, так что можно поставить кеширующий сервер рядом с посетителями.

Настройка proxy_cache

Кеш проксирования настраивается в два приёма. Сначала в блоке http объявляется зона кеша — место на диске и в памяти, где он будет жить:

proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=site_cache:20m
                 max_size=2g inactive=60m use_temp_path=off;

Здесь keys_zone=site_cache:20m резервирует 20 МБ памяти под ключи (этого хватает примерно на 160 тысяч объектов), max_size=2g ограничивает кеш двумя гигабайтами на диске, а inactive=60m удаляет то, к чему не обращались час. Затем в нужном location кеш включается:

location / {
    proxy_pass http://127.0.0.1:3000;
    proxy_cache site_cache;
    proxy_cache_valid 200 302 10m;
    proxy_cache_valid 404 1m;
    add_header X-Cache-Status $upstream_cache_status;
}

proxy_cache_valid 200 302 10m хранит успешные ответы десять минут, а заголовок X-Cache-Status — ваш главный диагностический инструмент: он показывает HIT, MISS или BYPASS для каждого запроса. Проверьте конфиг и перезагрузите:

nginx -t && systemctl reload nginx

Настройка fastcgi_cache для PHP

Для PHP-сайтов схема аналогична, но с директивами FastCGI. Зона объявляется так же в блоке http:

fastcgi_cache_path /var/cache/nginx/fcgi levels=1:2 keys_zone=php_cache:20m
                   max_size=2g inactive=60m use_temp_path=off;
fastcgi_cache_key "$scheme$request_method$host$request_uri";

Ключ кеша fastcgi_cache_key определяет, что считать одинаковым запросом: схему, метод, хост и путь. В блоке обработки PHP кеш включается директивами:

location ~ \.php$ {
    include fastcgi_params;
    fastcgi_pass unix:/run/php/php8.3-fpm.sock;
    fastcgi_cache php_cache;
    fastcgi_cache_valid 200 10m;
    fastcgi_no_cache $cookie_logged_in;
    add_header X-Cache-Status $upstream_cache_status;
}

Ключевая деталь — fastcgi_no_cache $cookie_logged_in: она отключает кеш для залогиненных пользователей, чтобы админ и авторизованный посетитель всегда получали свежую персональную страницу, а не общую копию из кеша. Это тот самый предохранитель, без которого кеш на динамическом сайте опасен.

Обход кеша и правильные исключения

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

set $skip_cache 0;
if ($request_method = POST) { set $skip_cache 1; }
if ($request_uri ~* "/(cart|checkout|my-account)") { set $skip_cache 1; }
if ($http_cookie ~* "session|logged_in") { set $skip_cache 1; }

location / {
    proxy_cache_bypass $skip_cache;
    proxy_no_cache $skip_cache;
    proxy_cache site_cache;
    proxy_pass http://127.0.0.1:3000;
}

proxy_cache_bypass заставляет обойти кеш при чтении, а proxy_no_cache — не сохранять такой ответ. Оба нужны вместе: без второго вы обойдёте кеш, но всё равно запишете персональную страницу, которую потом отдадите чужому. Продумайте список исключений заранее — именно ошибки в нём приводят к утечкам данных между пользователями.

Проверка, очистка и обслуживание кеша

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

curl -sI https://example.com | grep X-Cache-Status
curl -sI https://example.com | grep X-Cache-Status

Смена MISS на HIT означает, что ответ закешировался и теперь отдаётся с диска. Сбросить кеш целиком проще всего очисткой каталога с последующей перезагрузкой:

rm -rf /var/cache/nginx/*
systemctl reload nginx

Точечная очистка отдельных страниц в открытой версии Nginx недоступна из коробки — для неё используют сторонний модуль или полностью сбрасывают кеш при публикации нового контента. На практике для большинства сайтов хватает разумного TTL: страница живёт в кеше десять минут и сама обновляется, а при срочной правке достаточно очистить каталог. Следите за размером кеша, чтобы он не съел весь диск, и держите его на быстром носителе. При правильной настройке кеширование даёт самый дешёвый прирост скорости из возможных: тот же VPS начинает держать кратно больше трафика без апгрейда железа.

Частые вопросы