Все статьи
Как настроить Nginx для фронтенда и бэкенда с нуля
7 октября 2026 г.120 просмотровРазработка

Как настроить Nginx для фронтенда и бэкенда с нуля

Универсальный пример для Ubuntu: проксирование фронтенда и API, подключение HTTPS и проверка ошибок.

Nginx

На одном сервере часто работают два приложения: фронтенд показывает страницы, бэкенд отвечает на запросы API. У каждого свой локальный порт, но посетителю нужен один адрес. Nginx принимает запросы на домене и передаёт их нужному процессу. Разберём настройку с нуля на условном примере.

Во всех командах ниже example.com — пример домена, 127.0.0.1:3000 — пример адреса фронтенда, 127.0.0.1:3001 — пример адреса API. Перед применением замените их на свои значения. Предполагается Ubuntu и два уже запущенных приложения.

1. Подготовьте домен и приложения

Создайте A-запись домена с публичным IPv4 сервера. Если используете IPv6, настройте AAAA-запись на рабочий IPv6. Убедитесь, что приложения отвечают на локальных портах:

curl -I http://127.0.0.1:3000/
curl -I http://127.0.0.1:3001/health

Путь /health здесь пример. Если у вашего API нет такого маршрута, подставьте существующий. Ответ 404 показывает, что процесс доступен, хотя выбранного маршрута нет. Ошибка Connection refused означает, что на указанном адресе никто не слушает. Проверьте порт и запуск приложения до настройки Nginx.

2. Установите Nginx

sudo apt update
sudo apt install -y nginx
sudo systemctl enable --now nginx
sudo nginx -t

Если на сервере включён UFW, разрешите SSH и веб-трафик:

sudo ufw allow OpenSSH
sudo ufw allow 'Nginx Full'
sudo ufw status

Профиль Nginx Full открывает порты 80 и 443. Внешний доступ к локальным портам приложений обычно не требуется.

3. Создайте конфигурацию сайта

На Ubuntu конфиги сайтов обычно лежат в /etc/nginx/sites-available/. Откройте новый файл:

sudo nano /etc/nginx/sites-available/example.com

Добавьте конфигурацию. На этом этапе она работает по HTTP: сертификат подключим позже.

server {
    listen 80;
    server_name example.com;

    # При загрузке файлов подберите лимит под своё приложение.
    client_max_body_size 20m;

    # Запрос /api/users попадёт в API как /api/users.
    location /api/ {
        proxy_pass http://127.0.0.1:3001;
        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;
    }

    # Остальные адреса обслуживает фронтенд.
    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;
    }
}

В proxy_pass намеренно нет завершающего слеша: Nginx передаёт путь приложению без изменения. Если ваш API ожидает /users вместо /api/users, потребуется другая схема маршрутов. Дополнительные пути, например /uploads/ или собственные маршруты фронтенда под /api/, добавляйте отдельными location после того, как определите, как их обрабатывает приложение.

4. Включите конфиг и проверьте его

sudo ln -s /etc/nginx/sites-available/example.com /etc/nginx/sites-enabled/example.com
sudo nginx -t
sudo systemctl reload nginx
curl -I http://example.com/
curl -I http://example.com/api/health

Символическую ссылку создают один раз. Если файл с таким именем уже есть, проверьте его вместо повторного создания. При ошибке nginx -t исправьте конфигурацию до перезагрузки. Если на сервере несколько сайтов, у каждого должен быть свой server_name.

5. Выпустите сертификат HTTPS

После того как домен указывает на сервер и HTTP-сайт доступен извне, установите Certbot:

sudo apt install -y certbot python3-certbot-nginx
sudo certbot --nginx -d example.com
sudo nginx -t
sudo systemctl reload nginx
sudo certbot renew --dry-run

Certbot предложит настроить перенаправление HTTP на HTTPS. Выберите его, если хотите, чтобы посетители всегда открывали защищённую версию. Проверьте оба маршрута уже по HTTPS:

curl -I https://example.com/
curl -I https://example.com/api/health

Если возникла ошибка

502 Bad Gateway означает, что Nginx не получил корректный ответ от приложения. Сначала повторите локальные запросы к портам 3000 и 3001, затем посмотрите журнал:

sudo nginx -t
sudo tail -n 50 /var/log/nginx/error.log
sudo journalctl -u nginx -n 50 --no-pager

Если запрос к API показывает страницу фронтенда, проверьте путь URL и блок location /api/. Если приложение ожидает другой префикс, согласуйте маршруты бэкенда и правило Nginx. Проверяйте всю цепочку по порядку: приложение на локальном порту, ответ Nginx по HTTP, затем HTTPS. Так причина ошибки находится намного быстрее.