Настройка Nginx под мобильный трафик без лишних редиректов

За 20–30 минут вы настроите Nginx так, чтобы мобильные браузеры получали сжатые ответы, статические файлы кешировались, а сайт не терял время на перенаправления между desktop- и mobile-версиями. Пример рассчитан на NGINX Open Source 1.24+ и статический сайт или приложение, которое уже умеет адаптивную вёрстку.

Что нужно иметь до начала

Подготовьте SSH-доступ с правами на изменение конфигурации, домен, установленный Nginx и каталог сайта. Проверьте версию командой:

nginx -v

Конфигурация ниже использует стандартные директивы Nginx и не зависит от сторонних модулей. Если сайт работает на WordPress, PHP или другом CMS, не заменяйте его существующий блок location / вслепую: в нём могут быть правила маршрутизации к PHP-FPM или приложению.

Правильная настройка мобильного трафика начинается не с определения телефона по User-Agent, а с уменьшения ответа и отказа от лишних перенаправлений.

Шаг 1. Сохраните текущую конфигурацию

Перед изменениями сделайте копию файла виртуального хоста. Его путь зависит от дистрибутива: часто это /etc/nginx/sites-available/example.conf или файл в /etc/nginx/conf.d/.

sudo cp /etc/nginx/sites-available/example.conf /etc/nginx/sites-available/example.conf.backup

Если путь другой, укажите фактический файл. Проверка: резервная копия существует, а команда ls показывает два файла конфигурации.

Шаг 2. Включите сжатие HTML, CSS и JavaScript

Gzip уменьшает размер текстовых ответов. Фотографии, WebP, AVIF, ZIP и шрифты обычно уже сжаты, поэтому добавлять их в список не нужно.

gzip on;
gzip_comp_level 5;
gzip_min_length 1024;
gzip_vary on;
gzip_types
    text/plain
    text/css
    text/xml
    application/json
    application/javascript
    application/xml
    application/xml+rss
    image/svg+xml;

Разместите эти директивы внутри блока http, а не внутри server, если хотите применить их ко всем сайтам. Проверка: после перезагрузки в DevTools браузера у текстового ответа появляется заголовок Content-Encoding: gzip, если клиент поддерживает gzip.

¹ Content-Encoding — HTTP-заголовок, который сообщает браузеру, каким способом сжат ответ. Он не означает, что исходный файл на диске изменился.

Шаг 3. Настройте кеш для версионированных файлов

CSS, JavaScript и изображения можно хранить в браузере дольше, если их имена меняются при каждой сборке: например, app.8f31c.js. Для таких файлов безопасен долгий кеш с признаком immutable.

server {
    listen 80;
    server_name example.com www.example.com;

    root /var/www/example;
    index index.html;

    location / {
        try_files $uri $uri/ /index.html;
    }

    location ~* \.(?:css|js|mjs|svg|png|jpg|jpeg|gif|webp|avif|woff2)$ {
        try_files $uri =404;
        expires 30d;
        add_header Cache-Control "public, max-age=2592000, immutable";
    }
}

Замените example.com и путь к корню сайта на свои значения. Строка try_files с index.html подходит для многих статических SPA, но не для каждого CMS. Проверка: запрос к существующему CSS или изображению возвращает 200, а в ответе есть Cache-Control.

Если файлы не имеют хеша в имени, удалите immutable и уменьшите срок кеша. Иначе пользователь может несколько дней видеть старый CSS после публикации.

Шаг 4. Уберите мобильные редиректы

Не отправляйте посетителя на m.example.com только потому, что в User-Agent есть слово Android или iPhone. Такая схема создаёт дополнительные запросы, усложняет кеширование и может привести к разной версии страницы для поискового робота и пользователя.

Для одного сайта используйте адаптивную вёрстку, метатег viewport и изображения подходящего размера. Nginx не заменяет корректную HTML-структуру: он может сжать ответ и отдать файл из кеша, но не уменьшит тяжёлую фотографию до нужного мобильному экрану разрешения.

Шаг 5. Если мобильная версия действительно нужна

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

Карту User-Agent размещают внутри блока http:

map $http_user_agent $mobile_request {
    default 0;
    ~*"(android|iphone|ipod|mobile)" 1;
}

Дальше переменную можно передать приложению через заголовок:

location / {
    proxy_set_header X-Mobile-Request $mobile_request;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_pass http://127.0.0.1:3000;
    add_header Vary User-Agent always;
}

Проверка: приложение получает X-Mobile-Request: 1 для мобильного User-Agent и 0 для остальных. Если перед Nginx есть CDN или proxy-cache, настройте там разделение кеша по User-Agent. Одного заголовка Vary недостаточно, если промежуточный кеш его игнорирует.

Не используйте этот вариант для простого изменения ширины колонок или размера шрифта. Это задача CSS, а не Nginx.

Шаг 6. Проверьте и примените конфигурацию

Сначала проверьте синтаксис, затем перезагрузите Nginx без остановки текущих соединений:

sudo nginx -t
sudo systemctl reload nginx

Команда проверки должна завершиться сообщением syntax is ok и test is successful. После reload откройте сайт в режиме эмуляции мобильного устройства и проверьте вкладку Network: HTML, CSS и JavaScript должны загружаться без перенаправления на отдельный домен.

Если не получилось

• «nginx: [emerg] unknown directive "gzip"». Проверьте, что запущен обычный Nginx, а не сторонний минимальный бинарник без нужного модуля. Выведите полную информацию о сборке командой nginx -V.
• «duplicate location "/"». В конфигурации уже есть такой блок. Объедините правила с существующим location /, а не добавляйте второй блок.
• Статические файлы возвращают 404. Проверьте значение root, регистр букв в имени файла и наличие файла на сервере. Директива try_files не создаёт отсутствующие файлы.
• После публикации мобильные пользователи видят старый CSS. Проверьте, меняется ли имя файла при сборке. Для файлов без хеша удалите immutable и очистите кеш CDN или браузера.
• Приложение получает только один вариант страницы. Если используется User-Agent, проверьте передачу X-Mobile-Request и правила кеша на всех промежуточных прокси.

Что измерить после настройки

Смотрите не на сам факт включённого gzip, а на размер и время загрузки реальной страницы. Сравните мобильное и обычное подключение в DevTools или Lighthouse: размер HTML, CSS и JavaScript, время до отображения основного контента и количество редиректов.

Отдельно проверьте самые тяжёлые изображения. Если они занимают большую часть ответа, настройка Nginx почти не изменит результат: нужны responsive images, современные форматы и ограничение исходного разрешения. Оптимизация изображений — отдельная тема; здесь рассматриваем только поведение Nginx.

Что делать дальше

После базовой настройки проверьте конфигурацию на тестовом домене и добавьте автоматическую проверку заголовков в процесс публикации. Затем настройте HTTPS и HTTP/2 по документации вашей версии Nginx, а для продакшена начните собирать размер ответов и долю ответов из кеша. Главный критерий успеха — не наличие переменной «mobile», а меньший ответ без лишнего редиректа и устаревших ассетов.