Администрирование Nginx на VPS

9 мин чтения·Matthieu·nginxweb-serverreverse-proxyvps|

Структурированное руководство по администрированию Nginx для владельцев VPS. Что делает Nginx, когда какая функция нужна, и ссылки на все туториалы для продакшена.

Nginx обслуживает значительную долю веба. Он раздаёт статические файлы, проксирует запросы к бэкенд-приложениям, терминирует TLS и балансирует нагрузку между несколькими серверами. Всё это — один процесс с минимальным потреблением памяти. Это руководство описывает администрирование Nginx на VPS, от установки до мониторинга в продакшене.

Эта страница — карта. Здесь описано, что делает Nginx, когда какая функция пригодится, и даны ссылки на отдельные туториалы по каждой теме. Разворачиваешь первый пет-проект или запускаешь эндпоинт AI-инференса за reverse proxy — начни здесь и выбери подходящий путь.

Что делает Nginx

Nginx (произносится «энджин-экс») — это событийно-ориентированный веб-сервер и reverse proxy. Он был создан в 2004 году для решения проблемы C10K: обработки 10 000 одновременных соединений на одном сервере. В отличие от серверов с потоком на соединение, таких как prefork-модель Apache, Nginx использует асинхронный цикл событий. Один worker-процесс обрабатывает тысячи соединений без создания нового потока для каждого.

На VPS это означает:

  • Низкое потребление памяти. Типичный worker-процесс Nginx занимает 2-10 МБ RAM. Worker Apache prefork — по 10-40 МБ каждый.
  • Высокая конкурентность. Один worker обрабатывает тысячи одновременных соединений. Узким местом обычно является ОС, а не Nginx.
  • Предсказуемая производительность под нагрузкой. Nginx не создаёт новых процессов на каждый запрос, поэтому потребление памяти остаётся стабильным при росте трафика.

Текущая стабильная версия — 1.28.x (1.28.2 по состоянию на март 2026). Ветка mainline (1.29.x) первой получает новые фичи. Стабильная ветка получает только критические исправления. Для продакшн-VPS стабильная ветка — правильный выбор.

Все туториалы в этой серии рассчитаны на Nginx, установленный из официальных репозиториев на Debian 12 или Ubuntu 24.04. Обе системы активно поддерживаются и широко используются на продакшн-серверах. Стандартные репозитории дистрибутива часто содержат устаревшие версии Nginx. Официальный репозиторий даёт последнюю стабильную версию с правильными ключами подписи.

Основные сценарии использования

Nginx выполняет четыре роли на VPS. Большинство продакшн-конфигураций используют две или больше одновременно.

Сервер статических файлов

Nginx раздаёт HTML, CSS, JavaScript, изображения и шрифты напрямую с диска. Системный вызов sendfile перемещает данные с диска в сетевой сокет без копирования через пользовательское пространство. Это избавляет от затрат на чтение содержимого файла в память приложения и обратную запись.

В сочетании со сжатием gzip или brotli и заголовками кеширования (expires, Cache-Control) Nginx отдаёт статику быстрее любого application-сервера. Процесс Node.js или Python, раздающий статические файлы, тратит циклы CPU на работу, которую Nginx выполняет на уровне ядра.

Для статических сайтов, SPA или фронтендов full-stack проектов Nginx — подходящий инструмент. Даже с динамическими бэкендами перенос статики на Nginx освобождает приложение для запросов, требующих логики.

Reverse proxy

Reverse proxy располагается между клиентами и бэкенд-приложением. Nginx принимает HTTP-запрос, пересылает его бэкенд-процессу (Node.js, Python, Go, Ruby или любому HTTP-сервису) и возвращает ответ клиенту.

Зачем не выставлять бэкенд напрямую? Несколько причин:

  • Терминация TLS в одном месте. Сертификаты настраиваются один раз в Nginx, а не в каждом приложении.
  • Проброс заголовков передаёт реальный IP клиента в бэкенд через X-Real-IP и X-Forwarded-For. Без этого приложение видит только 127.0.0.1.
  • Буферизация поглощает медленные клиентские соединения. Nginx считывает полный ответ от быстрого бэкенда, освобождает соединение и отдаёт ответ медленному клиенту в своём темпе. Бэкенд обрабатывает следующий запрос, а не ждёт.
  • Поддержка WebSocket работает через Nginx с правильными заголовками Upgrade и Connection.

Так же выставляется веб-интерфейс перед self-hosted AI-инструментами. Инстанс Ollama на localhost:11434 остаётся вне публичного интернета, а Nginx обеспечивает аутентификацию и HTTPS на фронтенде. Туториал Настройка Nginx как обратного прокси содержит полную конфигурацию Ollama с настройкой таймаутов для длительных запросов инференса.

Терминация TLS

Nginx выполняет TLS-хендшейк и дешифрование, чтобы бэкенд-приложения получали чистый HTTP на localhost. Это централизует управление сертификатами и снимает с кода приложения CPU-ёмкие криптографические операции.

TLS-хендшейк включает асимметричную криптографию (обмен ключами RSA или ECDSA), которая на порядки дороже симметричного шифрования при передаче данных. Отдавая это Nginx, ты позволяешь бэкенд-процессам сосредоточиться на бизнес-логике.

С Let's Encrypt и Certbot получаешь бесплатные сертификаты с автоматическим продлением. Директивы Nginx ssl_certificate и ssl_certificate_key указывают на файлы сертификата. Таймер systemd запускает certbot renew автоматически. Туториал Настройка Let's Encrypt SSL/TLS для Nginx на Debian 12 и Ubuntu 24.04 покрывает полную настройку, включая OCSP stapling и редирект HTTP на HTTPS.

Для европейских развёртываний, где важен суверенитет данных, терминация TLS на собственном VPS означает, что зашифрованный трафик расшифровывается только на инфраструктуре под твоим контролем. Никакой сторонний CDN или балансировщик не видит твой трафик в открытом виде.

Балансировщик нагрузки

Когда одного бэкенда недостаточно, Nginx распределяет запросы между несколькими upstream-серверами. Поддерживаются три встроенных алгоритма:

  • Round-robin (по умолчанию): запросы идут к каждому бэкенду по очереди
  • Least connections: запросы направляются к бэкенду с наименьшим числом активных соединений
  • IP hash: запросы с одного клиентского IP всегда идут на один бэкенд (полезно для привязки сессий)

Health-чеки автоматически выводят неотвечающие бэкенды из пула. Если бэкенд возвращает ошибки или не отвечает, Nginx прекращает отправку трафика до восстановления.

Для большинства VPS-конфигураций балансировка нагрузки становится актуальной при горизонтальном масштабировании на несколько инстансов приложения или при blue-green деплоях с нулевым даунтаймом.

Что потребуется

Перед началом любого туториала из этой серии тебе понадобится:

  • VPS на Debian 12 или Ubuntu 24.04 с root или sudo-доступом. Тарифы VPS Virtua Cloud подходят для всего, что описано здесь.
  • SSH-доступ с аутентификацией по ключу. Парольная аутентификация должна быть отключена. Брутфорс-боты начинают долбить SSH в течение нескольких минут после появления сервера в сети.
  • Доменное имя с A-записью, указывающей на IP-адрес сервера. Необходимо для TLS-сертификатов. Для туториала по установке — опционально.
  • Базовое владение командной строкой Linux: навигация по директориям, редактирование файлов в vim или nano, выполнение команд через sudo.

Если ты впервые настраиваешь VPS — сначала настрой SSH-ключи и файрвол, и только потом переходи к Nginx. Сервер, выставленный в интернет без этих базовых мер, — дыра в безопасности.

Серия туториалов

Каждая статья ниже посвящена одной теме. Они выстроены последовательно, но можно перейти к любой, если предварительные требования уже выполнены.

1. Установка Nginx

Установи Nginx из официальных репозиториев. Покрывает Debian 12 и Ubuntu 24.04 с проверкой GPG-ключа, установкой через apt, управлением через systemd (start, stop, reload, status) и правилами файрвола для ufw и nftables. Включает шаги проверки с curl и ss для подтверждения, что Nginx слушает на нужных портах.

Установка Nginx на Debian 12 и Ubuntu 24.04 из официального репозитория

2. Структура конфигурационного файла

Прежде чем редактировать конфиг, разберись, как Nginx его организует. Основной контекст, блоки events, http, server и location образуют иерархию. Директивы, заданные в родительском контексте, наследуются дочерними, если не переопределены явно. Статья покрывает все основные контексты (включая stream и upstream), директиву include для модульных конфигов и паттерн sites-available/sites-enabled, используемый в Debian и Ubuntu.

Структура конфигурационных файлов Nginx

3. Настройка серверных блоков

Размести несколько доменов на одном VPS. Серверные блоки (аналог виртуальных хостов Apache в Nginx) позволяют запускать отдельные сайты с независимыми конфигурациями, access-логами, error-логами и document root. Покрывает структуру директорий, создание файлов серверных блоков, включение и отключение сайтов через симлинки, директиву default_server, порядок сопоставления server_name и логирование по vhost.

Nginx Server Blocks: несколько доменов на одном VPS

4. Настройка SSL/TLS с Let's Encrypt

Добавь HTTPS на свои сайты с помощью Certbot и Let's Encrypt. Покрывает DNS-предварительные требования, установку Certbot через snap (текущий рекомендуемый способ), выпуск сертификатов с плагином Nginx, автоматическое продление через таймеры systemd, редирект HTTP на HTTPS и OCSP stapling. Каждый шаг включает команду проверки.

Настройка Let's Encrypt SSL/TLS для Nginx на Debian 12 и Ubuntu 24.04

5. Настройка reverse proxy

Поставь Nginx перед бэкенд-приложениями. Покрывает синтаксис proxy_pass, проброс заголовков (X-Real-IP, X-Forwarded-For, X-Forwarded-Proto), проксирование WebSocket с заголовками Upgrade, управление буферизацией (proxy_buffering, proxy_buffer_size) и настройку таймаутов (proxy_connect_timeout, proxy_read_timeout). Включает рабочий пример проксирования к локальному инстансу Ollama с увеличенными таймаутами для запросов инференса длительностью 30 секунд и более.

Настройка Nginx как обратного прокси

6. Усиление безопасности

Закрой Nginx сверх настроек по умолчанию. Каждая директива связана с конкретной угрозой, которую она нейтрализует. Покрывает заголовки безопасности (CSP, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy), скрытие серверных токенов, отключение неиспользуемых HTTP-методов, ограничение доступа по IP, выбор TLS cipher suite по профилю Mozilla Modern и HSTS с учётом preload. Проверка через securityheaders.com и SSL Labs.

Укрепление безопасности Nginx на Ubuntu и Debian

7. Оптимизация производительности

Оптимизируй Nginx для продакшн-трафика. Покрывает worker_processes auto и подбор worker_connections, epoll и multi_accept, тюнинг keepalive, настройку gzip (уровни сжатия, MIME-типы, минимальная длина), установку модуля brotli, кеширование статических файлов с expires и Cache-Control, open_file_cache для снижения дискового I/O, подбор размера proxy-буферов и активацию HTTP/2. Включает методологию бенчмаркинга с wrk для измерения эффекта каждого изменения.

Для сайтов с высоким трафиком VPS с высокой производительностью даёт больше запаса для TLS-хендшейков и сжатия.

Тюнинг производительности Nginx на VPS

8. Rate limiting и защита от DDoS

Защити эндпоинты от злоупотреблений и объёмных атак. Покрывает limit_req_zone и limit_req с параметрами burst и nodelay, limit_conn для ограничения соединений, кастомные страницы ошибки 429, режим dry_run для безопасного тестирования без блокировки реального трафика и интеграцию с fail2ban с рабочим фильтром и конфигурацией jail для бана повторных нарушителей на уровне файрвола.

Rate limiting в Nginx и защита от DDoS

9. Логирование и мониторинг

Настрой наблюдаемость продакшн-уровня. Покрывает кастомные определения log_format, включая структурированный JSON-формат с escape=json (готов для лог-шипперов вроде Filebeat или Vector), условное логирование с map для фильтрации health-чеков и статики, ротацию логов с конфигурацией logrotate, анализ в реальном времени с GoAccess и метрики Prometheus через модуль stub_status и prometheus-nginxlog-exporter.

10. Шпаргалка по Nginx

Быстрый справочник для повседневных операций. Команды systemd, типовые сниппеты конфигурации (редирект, proxy_pass, SSL-блок, rate limit, gzip), расположение файлов логов, отладка с nginx -T (вывод полной объединённой конфигурации) и curl -I (проверка заголовков ответа), а также частые коды ошибок (502, 504, 413, 403) с их причинами и решениями, специфичными для Nginx.

Шпаргалка по Nginx: команды, фрагменты конфигурации и исправление ошибок

Когда передать управление

Управление Nginx в продакшене — это слежение за патчами безопасности, продлением сертификатов, дрейфом конфигурации и ротацией логов. Если хочешь сосредоточиться на коде приложения и переложить инфраструктуру на кого-то другого, управляемый хостинг серверов берёт это на себя. Вся гибкость Nginx остаётся, без нагрузки по обслуживанию.

С чего начать

Разворачиваешь первый сайт? Начни с туториала по установке (Установка Nginx на Debian 12 и Ubuntu 24.04 из официального репозитория) и проходи серию по порядку.

Nginx уже работает? Переходи к нужной теме. Статья о структуре конфигурации (Структура конфигурационных файлов Nginx) заполнит пробелы, если до этого ты копировал конфиги не разбираясь в иерархии.

Запускаешь AI-нагрузки? Иди прямо в туториал по reverse proxy (Настройка Nginx как обратного прокси) за настройкой reverse proxy для Ollama. Затем закрой всё гайдом по усилению безопасности (Укрепление безопасности Nginx на Ubuntu и Debian) и туториалом по rate limiting (Rate limiting в Nginx и защита от DDoS).

Нужна только быстрая команда? Шпаргалка (Шпаргалка по Nginx: команды, фрагменты конфигурации и исправление ошибок) — всё на одной странице.