Настройка кеширования в nginx: proxy_cache, fastcgi_cache, кеширование статики. Как уменьшить нагрузку на сервер и ускорить загрузку страниц в 3-5 раз. Примеры конфигурации.
nginx — это не только веб-сервер, но и мощный инструмент кеширования. Правильно настроенный кеш в nginx снижает нагрузку на сервер в разы и ускоряет загрузку страниц с сотен миллисекунд до единиц. Если ваш сайт генерирует страницы динамически (PHP, Python, Node.js), каждый запрос запускает выполнение скрипта, обращение к базе данных, формирование HTML. Это занимает 100-500 мс и более. С кешированием nginx отдаёт уже готовый HTML из памяти или диска за 10-20 мс. Разница в 10-50 раз. Для SEO это критично: скорость — фактор ранжирования. А для сервера — экономия ресурсов: один и тот же кешированный ответ может быть отдан тысяче пользователей без дополнительных вычислений. В этой статье разберём, как настроить кеширование в nginx для статики и динамики.
Какие типы кеширования есть в nginx
nginx поддерживает два основных типа кеширования: кеширование статических файлов и кеширование динамических ответов. Статические файлы — это изображения, CSS, JavaScript, шрифты. Они не меняются часто и могут кешироваться на долгий срок. Для них nginx отдаёт файлы напрямую с диска, без обращения к бэкенду. Динамические ответы — это HTML-страницы, которые генерируются скриптами. Для них nginx может использовать proxy_cache (когда nginx работает как прокси перед бэкендом) или fastcgi_cache (когда nginx общается с PHP-FPM). Оба механизма сохраняют готовый HTML и отдают его без повторной генерации. Также есть microcache — кеширование на очень короткий срок (1-10 секунд), которое сглаживает пиковые нагрузки без риска отдать устаревший контент. Правильная стратегия — использовать все типы кеширования параллельно: статику кешировать на месяцы, динамику — на часы или дни, критичные страницы — микро-кешем.
Кеширование статических файлов: базовая настройка
Для кеширования статики в nginx используется блок location с директивами expires и add_header Cache-Control. Пример конфигурации: location ~* .(jpg|jpeg|png|gif|webp|css|js|woff2)$ { expires 30d; add_header Cache-Control public, immutable; }. Эта конфигурация указывает браузеру кешировать файлы на 30 дней. Заголовок Cache-Control public, immutable означает, что файл не изменится в течение срока кеша, и браузер может не проверять его обновление. Для статики это безопасно, если имена файлов содержат версию (например, style.css?v=1.2). При изменении файла меняется версия, и браузер загружает новую версию. Важно: не кешируйте HTML-страницы статикой. HTML должен загружаться с сервера или через динамический кеш, чтобы пользователь всегда получал актуальную версию. Проверить, что статика кешируется, можно через Проверка HTTP заголовков — смотрите заголовок Cache-Control в ответе сервера для статических файлов.
Proxy_cache: кеширование ответов бэкенда
Proxy_cache используется, когда nginx работает как обратный прокси перед бэкендом (Apache, Node.js, Python). Схема работы: пользователь запрашивает страницу → nginx проверяет кеш → если есть кеш, отдаёт его → если нет, запрашивает бэкенд → сохраняет ответ в кеш → отдаёт пользователю. Настройка proxy_cache требует нескольких директив. Сначала объявите зону кеша в контексте http: proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=my_cache:10m max_size=1g inactive=60m;. Эта директива создаёт кеш на диске с зоной 10 МБ для ключей и максимальным размером 1 ГБ. Затем в location для динамических страниц: proxy_cache my_cache; proxy_cache_valid 200 1h; proxy_cache_key $scheme$request_method$host$request_uri;. Эти директивы включают кеширование для ответов 200 на 1 час. Ключ кеша — полный URL запроса. После настройки проверьте, что кеш работает: первый запрос должен быть медленным (генерация), последующие — быстрыми (из кеша). Время ответа можно проверить через Проверка TTFB.
FastCGI_cache: кеширование PHP-FPM
FastCGI_cache — это аналог proxy_cache, но для связки nginx + PHP-FPM. Если ваш сайт на WordPress, Bitrix или другой PHP-CMS, именно fastcgi_cache даст максимальное ускорение. Настройка аналогична proxy_cache. Сначала зона кеша: fastcgi_cache_path /var/cache/nginx/fastcgi levels=1:2 keys_zone=fcgi_cache:10m max_size=1g inactive=60m;. Затем в location ~ .php$ { fastcgi_cache fcgi_cache; fastcgi_cache_valid 200 30m; fastcgi_cache_key $scheme$request_method$host$request_uri; }. Важно: при использовании fastcgi_cache нужно исключить из кеша страницы, которые зависят от пользователя: корзина, личный кабинет, форма заказа. Для этого используйте fastcgi_cache_bypass $cookie_session; — если у пользователя есть кука сессии, кеш не используется. Без этого исключения один пользователь может увидеть данные другого — критическая проблема безопасности. Подробнее о настройке кеширования для PHP читайте в статье Серверное кеширование: Redis и nginx.
Микрокеширование: защита от пиковых нагрузок
Микрокеширование — это кеширование на очень короткий срок: 1-10 секунд. Смысл: если на сайт заходит 1000 пользователей одновременно, все они получают один и тот же кешированный ответ, а бэкенд обрабатывает только один запрос. Через 5 секунд кеш истекает, и следующий запрос снова генерирует страницу. Для пользователя разница незаметна: задержка в 5 секунд на обновлении контента некритична. Для сервера — спасение: вместо 1000 запросов обрабатывается 1. Настройка микрокеша: fastcgi_cache_valid 200 5s; или proxy_cache_valid 200 5s;. Микрокеш особенно полезен для главных страниц, каталогов и карточек товаров, которые получают много трафика, но редко меняются. Проверить, как быстро сервер отвечает под нагрузкой, можно через Проверка пинга и Проверка TTFB.
Кеширование и SEO: что нужно знать
Кеширование ускоряет сайт, но может создать проблемы с индексацией, если настроено неверно. Проблема первая: поисковый робот получает кешированную версию, которая устарела. Если робот пришёл через минуту после обновления контента, а кеш ещё не истёк, он увидит старую версию. Для поисковиков это не критично — они переобходят страницы регулярно, но для свежих новостей может быть проблемой. Решение: используйте короткий срок кеша для часто обновляемых страниц. Проблема вторая: кеш отдаёт ошибку. Если страница сгенерировала 404, а кеш сохранил её, все последующие запросы будут получать 404, даже если страница уже исправлена. Решение: не кешируйте ошибки (настройте proxy_cache_valid только для 200, 301, 302). Проблема третья: кеш игнорирует мобильную версию. Если сайт отдаёт разный контент для мобильных и десктопа, кеш должен учитывать User-Agent. Решение: добавьте $http_user_agent в ключ кеша или используйте директиву Vary: User-Agent. Проверить, что кеш не мешает индексации, можно через Проверка индексации сайта.
Проверка эффективности кеширования
После настройки кеша нужно убедиться, что он работает. Признак 1: TTFB резко упал. Если до кеширования TTFB был 500 мс, после должен стать 20-50 мс. Проверьте через Проверка TTFB. Признак 2: заголовок X-Cache или X-Cache-Status в ответе сервера. Если он есть и показывает HIT — кеш работает, MISS — не попал, BYPASS — обойдён. Проверьте через Проверка HTTP заголовков. Признак 3: логи nginx показывают снижение количества запросов к бэкенду. Признак 4: нагрузка на процессор снизилась — мониторьте top или htop на сервере. Признак 5: страницы открываются визуально быстрее — это субъективно, но показательно. Для объективной оценки используйте Скорость загрузки сайта и Core Web Vitals — сравните метрики до и после настройки кеша.
Типичные ошибки при настройке кеша
Ошибка первая: кеширование всего подряд, включая страницы с персональными данными. Корзина, личный кабинет, форма оформления заказа — эти страницы не должны кешироваться. Иначе пользователь может увидеть чужие данные. Ошибка вторая: слишком долгий срок кеша для часто обновляемых страниц. Если главная страница новостного сайта кешируется на сутки, пользователи не увидят свежие новости. Ошибка третья: отсутствие механизма сброса кеша. Если контент обновился, а кеш остался, пользователи видят старую версию. Нужен способ ручного или автоматического сброса кеша: через команду rm -rf /var/cache/nginx/* или через специальные плагины CMS. Ошибка четвёртая: кеш на медленном диске. Если кеш хранится на HDD, а не на SSD, отдача из кеша может быть медленнее, чем генерация страницы. Используйте SSD или tmpfs для кеша. Ошибка пятая: игнорирование мобильной версии. Если сайт имеет отдельную мобильную версию, кеш должен разделять мобильный и десктопный контент.
Часто задаваемые вопросы
Что кешировать в nginx?
Кешируйте статику (изображения, CSS, JS) на долгий срок, динамические страницы — на часы или сутки, главную и каталог — микрокешем на 5-10 секунд. Не кешируйте корзину, личный кабинет, формы заказа.
Как проверить, что nginx кеш работает?
Смотрите TTFB — он должен упасть до 20-50 мс. Смотрите заголовок X-Cache-Status — он должен показывать HIT. Смотрите логи nginx — количество запросов к бэкенду должно снизиться.
Влияет ли кеширование nginx на SEO?
Да, положительно. Кеширование ускоряет загрузку страниц, что улучшает Core Web Vitals и поведенческие факторы. Но нужно правильно настроить, чтобы поисковые роботы получали актуальный контент.
Что быстрее: кеширование в nginx или Redis?
Redis быстрее для мелких объектов и подходит для кеширования данных (сессии, запросы к БД). nginx cache лучше для целых HTML-страниц. Оптимально использовать их вместе: nginx отдаёт готовые страницы, Redis хранит промежуточные данные.
