Как настроить Nginx на VPS 2026: production-конфиг по шагам

Nginx — один из самых популярных веб-серверов в мире. Почему? Потому что Nginx отлично справляется сразу с несколькими задачами:

• Быстро отдаёт статические файлы (HTML, CSS, картинки)
• Работает как обратный прокси — принимает запросы пользователей и перенаправляет их к вашему приложению (Node.js, PHP, Python)
• Обеспечивает SSL-шифрование — защищает данные между браузером и сервером
• Сжимает и кэширует контент — ускоряет загрузку страниц для посетителей

В этом руководстве пройдём весь путь: от установки Nginx на чистый VPS до рабочей конфигурации с SSL-сертификатом. Все команды для Ubuntu/Debian, все провайдеры — российские.

Nginx (произносится «энджинкс») — это программа, которая устанавливается на сервер и обрабатывает запросы от браузеров посетителей. Когда кто-то открывает ваш сайт, именно Nginx решает, какой файл или страницу отправить в ответ.

Главное отличие Nginx от классического Apache — способ обработки запросов. Apache в режиме prefork держит отдельный процесс на каждое соединение, и при большом числе посетителей памяти уходит много. Nginx обрабатывает тысячи соединений в нескольких рабочих процессах.

Nginx используют в двух основных режимах:

• Веб-сервер — напрямую отдаёт файлы сайта посетителям. Идеально для статических сайтов, лендингов, блогов
• Обратный прокси — принимает запросы и передаёт их приложению (Node.js, Django, WordPress/PHP-FPM), а ответ отправляет обратно посетителю

На одном VPS Nginx может одновременно обслуживать несколько сайтов через виртуальные хосты — каждый со своим доменом и настройками.

Nginx — один из самых легковесных веб-серверов. Но неправильно подобранный сервер снизит производительность:

Процессор: 1 ядро (минимум), 2 ядра (рекомендуется). Nginx эффективно использует все доступные ядра.

Оперативная память: 512 МБ (минимум), 1-2 ГБ (рекомендуется). При работе с PHP или проксировании приложений требуется больше.

Диск: 10 ГБ SSD (минимум), 20 ГБ NVMe (рекомендуется).

Операционная система: Ubuntu 22.04/24.04 LTS или Debian 12.

Для работы Nginx должны быть открыты порты 80 (HTTP), 443 (HTTPS) и 22 (SSH для управления).

Выбор провайдера влияет на скорость и стабильность сайта. Ниже — тарифы наших трёх провайдеров, подходящие под Nginx, с условием оплаты у каждой цены:

AdminVPS — от 349 руб/мес при помесячной оплате. Тариф Lite: 1 vCPU 3,6 ГГц, 1 ГБ RAM, 15 ГБ NVMe. Защита от DDoS уровня L2–L4 указана в описании тарифов, техподдержка 24/7; настройку веб-сервера AdminVPS берёт на себя в линейке «Всё включено», она дороже.

Timeweb Cloud — Cloud MSK 40 за 900 ₽/мес при оплате за 12 месяцев со скидкой 10 %: 2 vCPU 3,3 ГГц, 2 ГБ RAM, 40 ГБ NVMe, канал 1 Гбит/с. Биллинг у провайдера почасовой, в маркетплейсе готовые образы.

Timeweb — та же линейка Cloud MSK, 900 ₽/мес при оплате за 12 месяцев со скидкой 10 %. Локации те же: Санкт-Петербург, Москва, Новосибирск, Казахстан, Нидерланды, Германия.

Для большинства проектов оптимальный старт — тариф с 1 ГБ RAM и NVMe-диском. Сравнить все VPS-тарифы.

Все команды выполняются от имени root или через sudo на Ubuntu/Debian.

Шаг 1. Подключение и обновление

Подключитесь к серверу по SSH и обновите системные пакеты:

apt update && apt upgrade -y

Шаг 2. Установка Nginx

apt install nginx -y
systemctl enable --now nginx

Шаг 3. Проверка работы

Откройте IP-адрес сервера в браузере — должна появиться страница «Welcome to nginx!». Или проверьте из терминала:

curl -I http://localhost

Шаг 4. Настройка виртуального хоста

Создайте файл конфигурации для вашего домена:

nano /etc/nginx/sites-available/your-site.conf

Пример базовой конфигурации:

server {
    listen 80;
    server_name your-domain.ru www.your-domain.ru;
    root /var/www/your-site;
    index index.html;

    location / {
        try_files $uri $uri/ =404;
    }

    access_log /var/log/nginx/your-site.access.log;
    error_log /var/log/nginx/your-site.error.log;
}

Каталог сайта Nginx сам не создаёт. Без него домен ответит 404 — при проверке 11.10.2026 так и вышло. Создайте каталог и первую страницу:

mkdir -p /var/www/your-site
echo '<h1>Работает</h1>' > /var/www/your-site/index.html

Шаг 5. Активация и проверка

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

ln -s /etc/nginx/sites-available/your-site.conf /etc/nginx/sites-enabled/
nginx -t
systemctl reload nginx

Для защиты данных между браузером и сервером необходим SSL-сертификат. Бесплатный сертификат от Let's Encrypt устанавливается двумя командами.

Установите Certbot:

apt install certbot python3-certbot-nginx -y

Получите сертификат и автоматически настройте HTTPS:

certbot --nginx -d your-domain.ru

Certbot автоматически добавит перенаправление с HTTP на HTTPS а автопродление уже запланировал пакет certbot (сертификат сейчас действует 90 дней).

Проверьте что конфигурация корректна:

nginx -t && systemctl reload nginx

Один VPS обслуживает столько доменов, сколько потянет по памяти: каждому сайту заводится свой блок server. Документация nginx называет их server blocks; в мире Apache то же самое зовут виртуальными хостами.

Файл на каждый сайт кладут отдельно и включают ссылкой:

nano /etc/nginx/sites-available/pervyj.ru
ln -s /etc/nginx/sites-available/pervyj.ru /etc/nginx/sites-enabled/

Минимальный блок для статического сайта выглядит так:

server {
    listen 80;
    server_name pervyj.ru www.pervyj.ru;
    root /var/www/pervyj.ru;
    index index.html;
}

Второй сайт — такой же файл со своим server_name и своим root. Перезагружать сервер целиком не нужно: проверка конфигурации и мягкая перезагрузка делают это без обрыва соединений.

nginx -t && systemctl reload nginx

Как nginx выбирает, какой блок ответит

Порядок задан документацией (nginx.org, «Server names»), и знать его стоит: именно тут сайты начинают показываться друг вместо друга.

• точное совпадение имени — pervyj.ru
• самое длинное имя со звёздочкой в начале — *.pervyj.ru
• самое длинное имя со звёздочкой в конце — mail.*
• первое подходящее регулярное выражение в порядке записи в файле

Запрос, не подошедший ни одному блоку, попадёт в блок с пометкой default_server, а если её нет — в первый по порядку. Отсюда частая жалоба «открывается чужой сайт»: домен ещё не описан, и его забирает сосед по серверу. Лечится явным блоком-заглушкой:

Но сначала уберите стандартный сайт Ubuntu: в нём уже стоит listen 80 default_server, и второй такой блок nginx -t не пропустит — «a duplicate default server for 0.0.0.0:80», при проверке 11.10.2026 так и было:

rm /etc/nginx/sites-enabled/default

server {
    listen 80 default_server;
    server_name _;
    return 444;
}

Сертификаты у каждого домена свои — Certbot выпускает их по одному и сам дописывает нужные строки в тот блок, где нашёл server_name.

Отдавать файлы — только половина работы. Чаще Nginx ставят ПЕРЕД приложением: Node.js, Python, контейнером Docker. Приложение слушает локальный порт и наружу не смотрит, а Nginx принимает запросы из интернета, держит SSL и передаёт их дальше.

Так это выглядит для приложения на порту 3000:

server {
    listen 80;
    server_name pervyj.ru;

    location / {
        proxy_pass http://127.0.0.1:3000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

Этот блок заменяет блок статического сайта pervyj.ru, а не ставится рядом: два блока с одним server_name nginx примет с предупреждением «conflicting server name … ignored» и один из них молча отбросит — какой, решит порядок файлов.

Зачем четыре строки с заголовками

Без них приложение видит все запросы как пришедшие с 127.0.0.1 и по протоколу http. Документация nginx (модуль ngx_http_proxy_module) показывает Host и X-Real-IP в самом базовом примере, остальные два заголовка добавляют, когда приложению нужен исходный адрес и понимание, что снаружи был HTTPS.

• Host — приложение узнаёт, какой домен запрашивали
• X-Real-IP — адрес посетителя, а не сервера
• X-Forwarded-For — цепочка адресов, если прокси не один
• X-Forwarded-Proto — был ли снаружи https; без него фреймворки строят ссылки на http

Приложение слушать наружу не должно

Порт приложения привязывают к 127.0.0.1, а не к 0.0.0.0. Иначе к нему можно постучаться напрямую по адресу сервера, минуя Nginx и его SSL. Проверить, что порт закрыт снаружи, можно с самого сервера:

ss -tlnp | grep 3000

В выводе должно стоять 127.0.0.1:3000. Если там 0.0.0.0:3000 — правьте настройку приложения либо закрывайте порт файрволом.

Для контейнеров порядок тот же, только адресом служит имя сервиса в сети Docker. Подробности — в руководстве по Docker-хостингу.

Даже опытные администраторы допускают эти ошибки:

1. Не проверять конфигурацию перед перезагрузкой

Всегда запускайте проверку перед reload или restart. С опечаткой в конфиге restart уронит сайт, а reload просто не применит правку — Nginx продолжит работать на старой конфигурации:

nginx -t

2. Забыть про firewall

Если порты 80 и 443 не открыты, сайт не будет доступен. Проверьте:

ufw status
# или
iptables -L

3. Не настроить логирование

Без логов невозможно диагностировать проблемы. Настройте access_log и error_log для каждого виртуального хоста.

4. Игнорировать обновления безопасности

Регулярно обновляйте Nginx и ОС:

apt update && apt upgrade -y

5. Не включить сжатие

Без gzip страницы загружаются медленнее. В Ubuntu строка gzip on; в /etc/nginx/nginx.conf уже есть — вторая такая в том же блоке http уронит проверку («"gzip" directive is duplicate»). Добавьте в блок http только типы файлов (там эта строка закомментирована):

gzip_types text/plain text/css application/json application/javascript text/xml;

Наш замер 11.10.2026. Команды этой инструкции выполнены по шагам на чистом сервере Timeweb Cloud: 2 vCPU, 2 ГБ памяти, Ubuntu 24.04.5, Nginx 1.24.0 из пакетов Ubuntu. Установка Nginx заняла 9 секунд, три процесса Nginx после настройки занимали 16 МБ памяти; файл в 3 000 байт после включения сжатия ушёл 49 байтами.

Четыре места, где инструкция в прежнем виде ломалась, — все исправлены выше:

• без каталога /var/www/your-site сайт отвечал 404;
• заглушка default_server рядом со стандартным сайтом Ubuntu — nginx -t с ошибкой «a duplicate default server»;
• «gzip on» в основном конфиге — ошибка «directive is duplicate»: в Ubuntu сжатие уже включено;
• прокси рядом с блоком сайта того же имени — предупреждение «conflicting server name», один блок отброшен.

Чего проверка не показывает: выпуск сертификата (шаг SSL) — для него нужен свой домен; работу под нагрузкой и с вашим приложением. Один сервер, один день.

Правильно настроенный Nginx превращает даже бюджетный VPS в надёжный сервер для ваших проектов. Ключевые моменты:

• Включите HTTPS через Let's Encrypt — это бесплатно, а сайты на HTTP браузеры помечают как небезопасные
• Настройте gzip-сжатие и кэширование для ускорения загрузки
• Всегда проверяйте конфигурацию командой nginx -t перед применением изменений
• Настройте логирование для диагностики проблем

Выбрать VPS: каталог провайдеров. Подробнее о выборе: полное руководство по VPS 2026.

Docker хостинг — Nginx + Docker через обратный прокси

VPN-сервер WireGuard на VPS — VPN вместе с Nginx

Бэкап VPS — резервное копирование сервера

Как выбрать VPS хостинг 2026 — критерии выбора

Дешёвый VPS: сколько стоит на самом деле — бюджетные серверы