Как установить и настроить Nginx как реверс-прокси на VPS

MAATRIX

Приложение крутится на localhost:3000, а наружу его нужно отдавать по 80 и 443 порту, с HTTPS и нормальными заголовками. Ставить Node или Python прямо на публичный порт — плохая идея: нет TLS, нет буферизации, любой всплеск трафика роняет процесс. Nginx как реверс-прокси на VPS решает это раз и навсегда: он принимает соединения, терминирует SSL и аккуратно передаёт запросы на ваш бэкенд.

Что делает реверс-прокси и зачем он нужен

Реверс-прокси стоит перед вашим приложением и представляется клиенту единственным сервером. Браузер видит только Nginx на 443 порту, а всё, что за ним — один процесс на Node, несколько контейнеров, PHP-FPM или Python-воркеры — остаётся скрытым во внутренней сети.

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

Для большинства проектов именно реверс-прокси — точка входа, где удобно навесить логирование, ограничение скорости, базовую защиту и балансировку. Поэтому Nginx ставят даже там, где приложение теоретически умеет слушать порт само.

Есть и практический аргумент безопасности. Когда приложение слушает только localhost, снаружи к нему нельзя подключиться напрямую в обход прокси. Значит, все правила доступа, лимиты и фильтры, которые вы настроили на Nginx, действительно применяются к каждому запросу, а не обходятся хитрым клиентом, который стучится сразу на порт бэкенда. Единственная публичная точка входа — это всегда проще контролировать, чем десяток разрозненных сервисов, каждый со своим портом.

Подготовка VPS и установка Nginx

Возьмите VPS с чистым публичным IP и root-доступом. Для роли прокси хватает минимальной конфигурации: 1 ядро и 1 ГБ RAM тянут тысячи запросов в секунду, потому что сам Nginx почти не нагружает систему. Если за прокси будут тяжёлые приложения или транскодинг, ресурсы берите под них, а не под сам Nginx.

Обновите систему и поставьте пакет:

apt update && apt upgrade -y
apt install nginx -y
systemctl enable --now nginx

Проверьте, что сервис поднялся и отвечает:

systemctl status nginx
curl -I http://127.0.0.1

Сразу откройте нужные порты в фаерволе и закройте всё лишнее:

ufw allow 22/tcp
ufw allow 80/tcp
ufw allow 443/tcp
ufw enable

Если ваш бэкенд слушает только localhost (а так и должно быть), снаружи он недоступен, и это правильно: наружу торчит только Nginx.

Базовый конфиг проксирования на бэкенд

Конфиги сайтов удобно держать в /etc/nginx/sites-available/ и включать симлинком в sites-enabled. Создайте файл /etc/nginx/sites-available/app.conf:

server {
    listen 80;
    server_name example.com;

    location / {
        proxy_pass http://127.0.0.1:3000;
        proxy_http_version 1.1;
        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;
    }
}

Включите сайт, уберите дефолтный и перечитайте конфигурацию:

ln -s /etc/nginx/sites-available/app.conf /etc/nginx/sites-enabled/
rm -f /etc/nginx/sites-enabled/default
nginx -t
systemctl reload nginx

Команда nginx -t — ваша страховка: она проверяет синтаксис до применения, и если что-то не так, старый рабочий конфиг остаётся в силе. Возьмите за правило никогда не делать reload, не прогнав тест.

Заголовки, которые нельзя забывать

Блок proxy_set_header из примера выше — не украшение. Без него приложение получит неверную информацию о клиенте. Host передаёт исходный домен, иначе бэкенд увидит 127.0.0.1. X-Real-IP и X-Forwarded-For доносят настоящий IP посетителя — без них в логах приложения будет только адрес прокси. X-Forwarded-Proto сообщает, что снаружи был HTTPS, и это критично для фреймворков, которые сами строят абсолютные ссылки.

Отдельная частая боль — таймауты и размер тела запроса. Если бэкенд отвечает долго или принимает крупные загрузки, добавьте:

proxy_connect_timeout 60s;
proxy_read_timeout 300s;
client_max_body_size 50m;

Значение client_max_body_size по умолчанию всего 1 МБ, и именно из-за него загрузка файлов обрывается с ошибкой 413. Поднимайте его осознанно до реального максимума ваших форм.

Ещё один нюанс касается буферизации. По умолчанию Nginx полностью считывает ответ бэкенда в буфер, прежде чем начать отдавать его клиенту, — это хорошо для обычных страниц, но мешает потоковым ответам и серверным событиям. Если вы отдаёте длинный поток данных или прогресс операции в реальном времени, отключите буфер для нужного location директивой proxy_buffering off;. Для всего остального буферизацию лучше оставить включённой: она снимает нагрузку с приложения, освобождая его от медленных клиентов на плохом мобильном интернете.

Настройка HTTPS через Let's Encrypt

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

apt install certbot python3-certbot-nginx -y
certbot --nginx -d example.com -d www.example.com

Certbot запросит почту, проверит домен и добавит блок listen 443 ssl с путями к сертификатам. Он же настроит редирект с 80 на 443. Автопродление уже включено таймером systemd, но убедиться не помешает:

systemctl status certbot.timer
certbot renew --dry-run

Чтобы сертификат выпустился, домен должен реально указывать A-записью на IP вашего VPS. Здесь важна и локация сервера: для аудитории в России ближе RU-площадка и меньше пинг, для доступа к зарубежным сервисам логичнее US, а для Европы — UK. Удобно, что у MAATRIX все три локации доступны с оплатой из России картой или криптой, поэтому можно выбрать по задаче, а не по способу оплаты.

Проксирование WebSocket и нескольких сервисов

Если приложение использует WebSocket (чаты, живые обновления, панели мониторинга), стандартного конфига мало — нужно пробросить заголовки апгрейда соединения:

location /ws/ {
    proxy_pass http://127.0.0.1:3000;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
    proxy_set_header Host $host;
}

Несколько сервисов за одним доменом разводятся по location. Например, фронтенд на 3000, API на 4000:

location /api/ {
    proxy_pass http://127.0.0.1:4000/;
}
location / {
    proxy_pass http://127.0.0.1:3000;
}

Обратите внимание на слэш в конце proxy_pass http://127.0.0.1:4000/ — он отрезает префикс /api/ перед передачей на бэкенд. Это тонкий, но частый источник путаницы: со слэшем и без него Nginx формирует разный путь.

Логи, безопасность и обслуживание

После запуска настройте наблюдение за прокси. Логи по умолчанию лежат в /var/log/nginx/access.log и error.log — смотрите их первыми при любой проблеме:

tail -f /var/log/nginx/error.log

Простое ограничение частоты запросов защитит бэкенд от перебора и лёгкого флуда. В блоке http объявите зону, а в location примените лимит:

limit_req_zone $binary_remote_addr zone=api:10m rate=10r/s;

Скрывайте версию Nginx строкой server_tokens off; в основном конфиге, держите порты закрытыми фаерволом и обновляйте пакет вместе с системой. Для роли прокси этого набора достаточно, чтобы сервер годами работал без сюрпризов. Если проект растёт и за прокси появляется несколько бэкендов, тот же Nginx легко превращается в балансировщик — но это уже следующий шаг, и он тоже прекрасно живёт на отдельном небольшом VPS.

Частые вопросы