Сайт стал медленным после наплыва пользователей? Разберём, как с помощью кеширования в Nginx снять нагрузку с сервера и ускорить загрузку страниц даже в часы пик.
Пока сайт молод и трафик невелик, Nginx бодро справляется с раздачей страниц, изображений и скриптов. Но одна удачная рекламная кампания или вирусный пост, и сервер превращается в кипящий котёл запросов. Вместо загрузки страниц пользователи получают 502 Bad Gateway, владелец сайта в панике, а разработчик лихорадочно думает, что делать.
Именно кеширование в Nginx способно спасти ситуацию. Оно снимает лишнюю нагрузку с VPS, ускоряет отклик и позволяет безболезненно пережить даже самый мощный наплыв трафика. В материале рассказали, как правильно настроить кеширование в Nginx, чтобы сайт работал быстро и стабильно.
Что такое кеширование и зачем оно нужно
В работе веб-сайта всё упирается во время. Пользователь ждёт, чтобы страница открылась мгновенно, поисковики ранжируют быстрее работающие ресурсы выше, а владелец бизнеса считает, сколько посетителей убежали из-за долгой загрузки. Кеширование — это суперсила, которая даёт сайту выиграть эту гонку.
Суть проста: когда пользователь заходит на сайт, его браузер или сервер Nginx обращается за файлами — картинками, стилями, скриптами, даже страницами. Если для каждого запроса сервер будет заново получать эти данные с диска или запрашивать их у бэкенда, то под нагрузкой он начнёт захлёбываться. Именно тут на помощь приходит кеш.
Кеширование в Nginx позволяет запомнить результат запроса. Например, при первом посещении пользователь загружает баннер размером в 1 МБ. Если бы не кеш, каждый следующий посетитель (а иногда и сам пользователь при повторных посещениях) снова скачивал бы этот баннер с сервера.
Представьте крупный маркетплейс, где фотографий товаров столько, что они занимают до 80% всего трафика. Если настроить кеширование изображений на 30 дней через Nginx, нагрузка на серверы снизится в два с половиной раза.
Кеширование может работать и на уровне самого сервера. Когда Nginx выступает фронтендом для бэкенд-приложения, он может сохранить сгенерированную страницу в памяти или на диск и в течение заданного времени раздавать её другим посетителям без обращения к бэкенду.
Но кеш — это не просто ускоритель. Это инструмент, который требует точной настройки. Если кешировать страницу с важным динамическим контентом слишком долго, пользователь рискует увидеть устаревшую информацию. Если же вовсе отказаться от кеширования или задать слишком короткий срок хранения, сервер снова окажется перегружен под наплывом однотипных запросов.
Настройка кеширования статического контента в Nginx
Когда сайт загружает изображения, CSS, JavaScript и шрифты, на эти файлы может приходиться до 80 % всего трафика. Именно поэтому в Nginx важно настроить кеширование, чтобы браузер пользователя не обращался к серверу за одним и тем же контентом снова и снова.
Чтобы развернуть Nginx и настроить кеширование, чаще всего используют VPS. В российских проектах популярным выбором остаются виртуальные серверы, которые позволяют быстро поднять сервер и сразу приступить к настройке сайта.
Настройка начинается с задания времени жизни файлов. Например, если картинка или скрипт не меняются, их можно сохранить в кеше браузера на 30 дней. Это сильно снижает нагрузку на сервер и ускоряет загрузку сайта.
В конфигурации Nginx это задаётся так:
location ~* \.(jpg|jpeg|png|gif|ico|css|js|woff2?|ttf|svg)$ {
expires 30d;
add_header Cache-Control "public, max-age=2592000";
}
Значения:
- expires 30d — устанавливает срок действия кеша в 30 дней.
- add_header Cache-Control "public, max-age=2592000" — добавляет заголовок, указывающий браузеру, что ресурс можно кешировать в течение 30 дней (2592000 секунд).
Если файл меняется, пользователь может продолжать видеть устаревшую версию. Чтобы избежать этого, опытные разработчики добавляют в имя файла хэш или номер версии, например: style.v3.css. Браузер считает его новым и загружает свежую копию.
В российских проектах часто делают проще: выносят изображения и другие тяжёлые файлы на отдельный поддомен, например static.site.ru, где включают долгосрочное кеширование. Основной сайт при этом остаётся свободным для быстрых обновлений. Такой приём хорошо разгружает сервер и ускоряет открытие страниц для пользователей.
Продвинутое кеширование с proxy_cache в Nginx
Статический контент — это только часть нагрузки сайта. Основную проблему часто создаёт динамический контент: карточки товаров, профили пользователей, статьи. При резком росте трафика бэкенд не успевает обслуживать все запросы, и сайт начинает тормозить.
В таких случаях помогает proxy_cache. Этот инструмент даёт Nginx возможность сохранить ответ от бэкенда и в течение заданного времени отдавать его другим пользователям без повторных запросов.
Настроить proxy_cache можно в несколько строк. В nginx.conf создаётся область хранения:
proxy_cache_path /data/nginx/cache levels=1:2 keys_zone=my_cache:100m max_size=10g inactive=60m use_temp_path=off;
Здесь /data/nginx/cache — путь к директории для хранения кеша. Убедитесь, что эта директория существует и имеет соответствующие права доступа.
А затем добавляется настройка в блоке location:
location / {
proxy_pass http://backend;
proxy_cache my_cache;
proxy_cache_valid 200 302 10m;
proxy_cache_valid 404 1m;
add_header X-Proxy-Cache $upstream_cache_status;
}
Значения:
- proxy_pass http://backend; — направляет запросы к бэкенду. Замените backend на адрес вашего бэкенд-сервера, например, http://127.0.0.1:8080;.
- proxy_cache_valid 200 302 10m; — устанавливает время жизни кеша для ответов с кодами 200 и 302 на 10 минут.
- proxy_cache_valid 404 1m; — устанавливает время жизни кеша для ответов с кодом 404 на 1 минуту.
Заголовок X-Proxy-Cache показывает, откуда пришёл ответ: HIT — из кеша, MISS — напрямую с бэкенда.
Не все данные подходят для кеширования. Страницы с личными данными пользователей (например, история заказов или корзина) не кешируют. В российских проектах часто делают отдельные правила: кешируют публичные страницы, а для персональных включают прямую работу через бэкенд.
В некоторых случаях компании добавляют Nginx с proxy_cache между CDN и backend, чтобы выдерживать пики до десятков тысяч запросов в секунду без потери скорости сайта.
Проверка и отладка кеширования в Nginx
Даже после настройки кеша нельзя считать, что всё работает идеально. На практике часто возникают проблемы: какие-то файлы не кешируются, а где-то кеш отключён из-за неправильных заголовков. Проверка и отладка — обязательный этап.
Первым делом специалисты смотрят заголовки ответа сервера. Удобнее всего сделать это через curl:
curl -I https://example.com/image.jpg
Где https://example.com/image.jpg — замените на URL ресурса, который вы хотите проверить. В ответе должны быть Cache-Control, Expires, а если используется proxy_cache — X-Proxy-Cache.
Пример ответа:
HTTP/2 200
Cache-Control: public, max-age=2592000
Expires: Mon, 12 Jun 2025 10:00:00 GMT
X-Proxy-Cache: HIT
HIT говорит, что файл пришёл из кеша, MISS — что это первый запрос. Эти значения удобно отслеживать в браузере или через Grafana-дашборды, как это делают в российских интернет-магазинах.
Кеш может не работать, если бэкенд выставляет запретные заголовки вроде Cache-Control: no-store. В таких случаях в Nginx применяют принудительное игнорирование:
location / {
proxy_pass http://backend;
proxy_cache my_cache;
proxy_ignore_headers Cache-Control Pragma;
}
Этот приём часто используют российские команды, особенно когда бэкенд и инфраструктура настраиваются разными людьми.
Некоторые компании автоматизируют очистку кеша, чтобы пользователь всегда видел актуальные данные: файлы в proxy_cache удаляются вручную или по API при публикации обновлений.
Проверка кеша — это часть постоянного мониторинга. Важно отслеживать долю HIT/MISS и корректировать стратегию по мере роста трафика.
Заключение
Скорость загрузки сайта давно стала валютой доверия и конкурентного преимущества. Без продуманного кеширования даже мощные серверы и дорогие CDN превращаются в решето, сквозь которое утекает производительность.
Опыт российских проектов показывает: вложения в стратегию кеширования всегда окупаются. При грамотной архитектуре сайт выдержит и пиковые нагрузки, и внезапные всплески трафика, оставаясь таким же быстрым, как в день запуска.
Читайте в блоге:
- Как настроить кластер Kubernetes на нескольких VPS для запуска масштабируемых приложений
- Обновление Ubuntu 22.04: установка критических обновлений и апгрейд до 24.04
- Подготовка Tilda-лендинга на VPS к пиковой нагрузке: пошаговая инструкция