Установка Nginx Proxy Manager на VPS: Управление Reverse Proxy и SSL через Web UI

Что мы настраиваем и зачем

В современном мире, где на одном сервере часто размещается множество веб-сервисов — от сайтов и блогов до API-серверов и систем управления проектами — возникает необходимость в централизованном управлении доступом к ним. Именно эту задачу решает обратный прокси-сервер. Он выступает посредником между интернетом и вашими внутренними сервисами, направляя входящие запросы к нужному приложению на основе доменного имени или пути URL.

Nginx Proxy Manager (NPM) — это мощный инструмент, который значительно упрощает настройку и управление Nginx в качестве обратного прокси. Вместо ручного редактирования сложных конфигурационных файлов Nginx, NPM предлагает интуитивно понятный веб-интерфейс. Через него вы можете легко добавлять новые прокси-хосты, управлять SSL/TLS-сертификатами (в том числе автоматически получать их от Let's Encrypt), настраивать перенаправления, управлять доступом и многое другое.

В итоге, по завершении этого туториала, вы получите полностью настроенный Nginx Proxy Manager, способный маршрутизировать трафик к вашим внутренним приложениям, обеспечивая при этом безопасное HTTPS-соединение для каждого из них. Это позволит вам легко добавлять новые сервисы на ваш VPS, не беспокоясь о ручной настройке Nginx и SSL для каждого из них. Будь то GitLab, Mattermost, Minecraft-сервер с веб-интерфейсом, нода блокчейна или ваш собственный SaaS-проект, NPM станет центральным узлом для их публикации в интернете.

Какие альтернативы есть и почему self-hosted на VPS

Существует несколько подходов к управлению обратными прокси и SSL:

• Ручная настройка Nginx/Apache: Это классический метод, требующий глубоких знаний синтаксиса конфигурационных файлов. Он дает максимальную гибкость, но отнимает много времени и подвержен ошибкам.
• Caddy: Современный веб-сервер, который автоматически управляет SSL-сертификатами. Caddy проще в настройке, чем Nginx, но может быть менее гибок в некоторых сложных сценариях проксирования.
• Cloud-managed Load Balancers (AWS ALB, Google Cloud Load Balancer, Azure Application Gateway): Эти решения предлагают высокую доступность, масштабируемость и интегрированное управление SSL. Однако они значительно дороже, привязывают вас к конкретному облачному провайдеру и могут быть избыточны для небольших и средних проектов.
• Другие Docker-based прокси (Traefik, HAProxy): Traefik особенно популярен в экосистеме Docker благодаря своей способности автоматически обнаруживать и проксировать сервисы. Однако его настройка может быть сложнее для новичков по сравнению с NPM, который ориентирован на простоту использования через GUI.

Выбор self-hosted решения, такого как Nginx Proxy Manager на VPS, имеет ряд преимуществ:

• Полный контроль: Вы полностью контролируете инфраструктуру и данные, что критически важно для конфиденциальности и безопасности.
• Экономичность: Стоимость VPS часто значительно ниже, чем ежемесячные платежи за облачные Load Balancers, особенно для проектов с умеренной нагрузкой.
• Гибкость: Вы можете размещать любые приложения и сервисы, не ограничиваясь спецификой облачных платформ.
• Универсальность: Один и тот же подход работает на любом VPS от любого провайдера.

NPM идеально подходит для тех, кто хочет получить удобство облачных решений, но сохранить контроль и экономичность self-hosted инфраструктуры. Это отличный выбор для разработчиков, соло-фаундеров, игроков и криптоэнтузиастов, управляющих собственными серверами.

Какой VPS-конфиг нужен под эту задачу

Nginx Proxy Manager сам по себе достаточно легковесен, поскольку по сути является удобной оберткой над Nginx и Certbot. Основные требования к ресурсам будут зависеть от количества проксируемых сервисов, объема трафика и сложности конфигураций Nginx. Однако для большинства задач, где NPM выступает как единая точка входа для нескольких веб-приложений, требования будут умеренными.

Минимальные требования (для 1-5 небольших сервисов, низкий трафик):

• CPU: 1 vCPU (современный процессор, 2.5+ GHz)
• RAM: 1 GB (для NPM, Docker и базовой ОС)
• Диск: 25-30 GB SSD (для ОС, Docker-образов и данных NPM)
• Сеть: 100 Mbps (минимум, с неограниченным трафиком или достаточным лимитом)

Рекомендуемый VPS-план (для 5-20 сервисов, умеренный трафик, включая легкие приложения):

• CPU: 2 vCPU
• RAM: 2-4 GB
• Диск: 50-80 GB SSD
• Сеть: 1 Gbps (с достаточным объемом трафика, например, 1-2 TB/мес)

Такой конфиг обеспечит комфортную работу NPM и нескольких контейнеров с вашими приложениями. Например, VPS с указанными характеристиками будет хорошим выбором для большинства задач, описанных в этом руководстве. При выборе провайдера обращайте внимание на возможность быстрого масштабирования ресурсов, если ваш проект начнет активно расти.

Когда нужен dedicated, а не VPS

Dedicated сервер может потребоваться, если:

• Вы планируете размещать очень большое количество сервисов (сотни) с высоким трафиком.
• Ваши приложения требуют максимальной производительности CPU или RAM, которую не может обеспечить VPS (например, высоконагруженные базы данных, игровые серверы с большим количеством игроков).
• Вам нужны специализированные аппаратные ресурсы, такие как GPU или RAID-массивы.
• Требуется полная изоляция от других клиентов провайдера для максимальной безопасности или соответствия строгим регуляторным требованиям.

Для большинства сценариев, описанных в этом гайде, VPS более чем достаточен и значительно выгоднее.

Локация: на что влияет

Выбор локации VPS влияет на:

• Задержка (Latency): Чем ближе сервер к вашей целевой аудитории, тем меньше задержка и быстрее загрузка страниц. Для европейской аудитории лучше выбирать серверы в Европе, для американской — в Северной Америке.
• Соответствие законодательству: Размещение данных в определенных юрисдикциях может быть требованием для вашего проекта (например, GDPR в ЕС).
• Стоимость: Цены на VPS могут незначительно отличаться в зависимости от региона.

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

Подготовка сервера

Перед установкой Nginx Proxy Manager необходимо провести базовую настройку и защиту вашего свежего VPS. Мы будем использовать Ubuntu 24.04 LTS, которая будет актуальна в 2026 году и является стабильной и широко поддерживаемой операционной системой.

1. Подключение по SSH

Подключитесь к вашему серверу по SSH, используя учетные данные, предоставленные провайдером (обычно логин root и пароль).

ssh root@ВАШ_IP_АДРЕС_VPS

2. Обновление системы

Первым делом обновите все пакеты до последних версий. Это обеспечит наличие всех патчей безопасности и актуальных версий программного обеспечения.

sudo apt update -y         # Обновление списка пакетов
sudo apt upgrade -y        # Обновление установленных пакетов
sudo apt autoremove -y     # Удаление неиспользуемых пакетов

3. Создание нового пользователя с правами sudo

Работа под пользователем root небезопасна. Создайте нового пользователя и предоставьте ему права sudo.

adduser ВАШЕ_ИМЯ_ПОЛЬЗОВАТЕЛЯ          # Создание нового пользователя
usermod -aG sudo ВАШЕ_ИМЯ_ПОЛЬЗОВАТЕЛЯ # Добавление пользователя в группу sudo

Выйдите из сессии root и войдите под новым пользователем:

exit
ssh ВАШЕ_ИМЯ_ПОЛЬЗОВАТЕЛЯ@ВАШ_IP_АДРЕС_VPS

4. Настройка аутентификации по SSH-ключам (рекомендуется)

Аутентификация по SSH-ключам значительно безопаснее, чем по паролю. Если у вас еще нет пары SSH-ключей, сгенерируйте их на своем локальном компьютере:

ssh-keygen -t ed25519 -b 4096 # Создание нового SSH-ключа (локально)

Затем скопируйте публичный ключ на ваш VPS. Замените ВАШ_ИМЯ_ПОЛЬЗОВАТЕЛЯ и ВАШ_IP_АДРЕС_VPS на свои данные.

ssh-copy-id ВАШЕ_ИМЯ_ПОЛЬЗОВАТЕЛЯ@ВАШ_IP_АДРЕС_VPS # Копирование публичного ключа

После этого вы можете отключить аутентификацию по паролю в файле /etc/ssh/sshd_config для повышения безопасности. Найдите строки PasswordAuthentication yes и PermitRootLogin yes и измените их на no.

sudo nano /etc/ssh/sshd_config

Измените:

#PasswordAuthentication yes
PasswordAuthentication no
PermitRootLogin no

Перезапустите SSH-сервис:

sudo systemctl restart sshd

5. Настройка брандмауэра (UFW)

UFW (Uncomplicated Firewall) — это простой интерфейс для управления iptables. Настроим его, чтобы разрешить только необходимые соединения.

sudo apt install ufw -y              # Установка UFW
sudo ufw allow OpenSSH               # Разрешить SSH (порт 22)
sudo ufw allow 'Nginx Full'          # Разрешить HTTP (80) и HTTPS (443)
sudo ufw enable                      # Включение брандмауэра
sudo ufw status verbose              # Проверка статуса брандмауэра

Вам будет предложено подтвердить включение UFW, так как это может прервать существующие SSH-соединения. Введите y и нажмите Enter.

6. Установка Fail2Ban

Fail2Ban помогает защититься от брутфорс-атак, автоматически блокируя IP-адреса, с которых совершаются неудачные попытки входа.

sudo apt install fail2ban -y         # Установка Fail2Ban
sudo systemctl enable fail2ban       # Включение автозапуска
sudo systemctl start fail2ban        # Запуск службы

По умолчанию Fail2Ban уже настроен для защиты SSH. Вы можете создать файл локальной конфигурации для тонкой настройки:

sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
sudo nano /etc/fail2ban/jail.local

В файле jail.local вы можете изменить параметры, такие как bantime (время блокировки), findtime (период для обнаружения попыток) и maxretry (максимальное количество попыток). Убедитесь, что секция [sshd] активна (enabled = true).

[sshd]
enabled = true
port = ssh
logpath = %(sshd_log)s
backend = %(sshd_backend)s
maxretry = 3
bantime = 1h

После любых изменений перезапустите Fail2Ban:

sudo systemctl restart fail2ban

Теперь ваш сервер готов к установке Docker и Nginx Proxy Manager.

Установка ПО — пошагово

Nginx Proxy Manager работает как Docker-контейнер, поэтому первым шагом будет установка Docker и Docker Compose на ваш VPS.

1. Установка Docker Engine

Удалите старые версии Docker, если они есть, чтобы избежать конфликтов:

for pkg in docker.io docker-doc docker-compose docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin; do sudo apt remove $pkg; done

Установите необходимые пакеты для установки Docker через HTTPS:

sudo apt update -y
sudo apt install ca-certificates curl gnupg -y

Добавьте официальный GPG-ключ Docker:

sudo install -m 0755 -d /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg
sudo chmod a+r /etc/apt/keyrings/docker.gpg

Добавьте репозиторий Docker в APT-источники:

echo \
  "deb [arch="$(dpkg --print-architecture)" signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu \
  "$(. /etc/os-release && echo "$VERSION_CODENAME")" stable" | \
  sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

Обновите список пакетов и установите Docker Engine (версия актуальна на 2026 год, например, 26.x):

sudo apt update -y
sudo apt install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin -y

Проверьте, что Docker установлен и работает:

sudo docker run hello-world # Запуск тестового контейнера

Добавьте вашего пользователя в группу docker, чтобы избежать использования sudo при каждой команде Docker:

sudo usermod -aG docker $USER # Добавление текущего пользователя в группу docker
newgrp docker                 # Применение изменений для текущей сессии

Теперь вы можете выполнять команды Docker без sudo.

2. Установка Nginx Proxy Manager с помощью Docker Compose

Создайте директорию для Nginx Proxy Manager и перейдите в нее:

mkdir nginx-proxy-manager
cd nginx-proxy-manager

Создайте файл docker-compose.yml. Это основной файл конфигурации для Docker Compose, который описывает сервисы, сети и тома.

nano docker-compose.yml

Вставьте следующее содержимое в файл. Обратите внимание, что мы используем актуальную версию NPM (например, 2.15.0 на 2026 год) и базу данных MariaDB. Мы также маппируем порты 80, 443 и 81 на хостовую машину, чтобы NPM мог обрабатывать HTTP/HTTPS трафик и предоставлять свой веб-интерфейс.

version: '3.8'
services:
  app:
    image: 'jc21/nginx-proxy-manager:2.15.0' # Актуальная версия NPM на 2026 год
    restart: always
    ports:
      - '80:80'    # HTTP порт
      - '443:443'  # HTTPS порт
      - '81:81'    # Порт веб-интерфейса NPM
    environment:
      DB_MYSQL_HOST: 'db'
      DB_MYSQL_PORT: 3306
      DB_MYSQL_USER: 'npm'
      DB_MYSQL_PASSWORD: 'npm_password_secure' # Замените на надежный пароль
      DB_MYSQL_NAME: 'npm'
    volumes:
      - ./data:/data # Сохранение данных конфигурации и SSL
      - ./letsencrypt:/etc/letsencrypt # Сохранение сертификатов Let's Encrypt
    depends_on:
      - db
  db:
    image: 'mariadb:11.3' # Актуальная стабильная версия MariaDB на 2026 год
    restart: always
    environment:
      MYSQL_ROOT_PASSWORD: 'root_password_secure' # Замените на надежный пароль
      MYSQL_DATABASE: 'npm'
      MYSQL_USER: 'npm'
      MYSQL_PASSWORD: 'npm_password_secure' # Должен совпадать с DB_MYSQL_PASSWORD выше
    volumes:
      - ./data/mysql:/var/lib/mysql # Сохранение данных базы данных

Важно: Обязательно замените npm_password_secure и root_password_secure на свои собственные, надежные пароли. Используйте разные пароли для пользователя NPM и пользователя root MariaDB.

3. Запуск Nginx Proxy Manager

Сохраните файл (Ctrl+O, Enter, Ctrl+X) и запустите контейнеры Docker Compose:

docker compose up -d # Запуск контейнеров в фоновом режиме

Эта команда скачает необходимые Docker-образы (Nginx Proxy Manager и MariaDB), создаст контейнеры, настроит сеть и запустит их. Процесс может занять несколько минут в зависимости от скорости вашего интернет-соединения.

4. Проверка статуса контейнеров

Убедитесь, что оба контейнера запущены и работают:

docker compose ps

Вы должны увидеть статус Up для обоих сервисов (app и db).

Теперь Nginx Proxy Manager установлен и готов к первоначальной настройке через свой веб-интерфейс.

Конфигурация

После успешной установки Nginx Proxy Manager, пришло время настроить его для управления вашими веб-сервисами и SSL-сертификатами. Весь процесс будет происходить через удобный веб-интерфейс.

1. Первый вход в Nginx Proxy Manager

Откройте ваш веб-браузер и перейдите по адресу http://ВАШ_IP_АДРЕС_VPS:81. Вы увидите страницу входа в Nginx Proxy Manager.

Стандартные учетные данные для первого входа:

• Email: [email protected]
• Password: changeme

После входа система сразу предложит вам изменить эти данные. Немедленно измените их на свои, более безопасные логин и пароль. Также укажите ваше настоящее имя.

2. Настройка первого прокси-хоста

Теперь давайте настроим ваш первый прокси-хост. Это позволит вам получить доступ к внутреннему сервису (например, веб-серверу, запущенному на порту 3000 на этом же VPS) по доменному имени с SSL-сертификатом.

Предположим, у вас есть домен example.com, и вы хотите, чтобы ваш сервис был доступен по app.example.com. Убедитесь, что DNS-запись типа A для app.example.com указывает на IP-адрес вашего VPS.

1. В веб-интерфейсе NPM перейдите в раздел "Hosts" -> "Proxy Hosts".
2. Нажмите кнопку "Add Proxy Host".
3. Вкладка "Details":
   • Domain Names: Введите app.example.com (или ваш домен/поддомен).
   • Scheme: Выберите http (если ваш внутренний сервис не использует SSL) или https (если использует).
   • Forward Hostname / IP: Введите 127.0.0.1 (если сервис на том же VPS) или внутренний IP-адрес другого сервера.
   • Forward Port: Введите порт, на котором работает ваш внутренний сервис (например, 3000).
   • Block Common Exploits: Рекомендуется включить для дополнительной безопасности.
   • Websockets Support: Включите, если ваш сервис использует вебсокеты (например, чаты, real-time приложения).
4. Вкладка "SSL":
   • SSL Certificate: Выберите "Request a new SSL Certificate".
   • Force SSL: Включите, чтобы все HTTP-запросы автоматически перенаправлялись на HTTPS.
   • Email Address for Let's Encrypt: Введите свой действующий адрес электронной почты.
   • I Agree to the Let's Encrypt Terms of Service: Отметьте этот пункт.
   • Use a DNS Challenge (optional): Если вы не можете открыть порты 80/443 для NPM или хотите использовать wildcard-сертификаты, выберите этот метод. Для большинства случаев достаточно HTTP Challenge.
5. Нажмите "Save".

NPM свяжется с Let's Encrypt, получит и установит SSL-сертификат для вашего домена. Это может занять несколько секунд. После успешной выдачи сертификата статус хоста изменится на "Online" с зеленым значком замка.

3. Проверка работоспособности

Теперь вы можете проверить ваш сервис, перейдя по адресу https://app.example.com (замените на свой домен) в браузере. Вы должны увидеть содержимое вашего внутреннего сервиса, а также зеленый замок в адресной строке, подтверждающий наличие действующего SSL-сертификата.

Вы также можете использовать curl для проверки:

curl -I https://app.example.com # Проверка HTTP-заголовков

Вы должны увидеть заголовки, указывающие на перенаправление (если включен Force SSL) и успешное соединение по HTTPS.

4. Расширенные настройки (опционально)

Custom Nginx Directives

Если вам нужны специфические настройки Nginx, которых нет в веб-интерфейсе, вы можете добавить их на вкладке "Advanced" при редактировании прокси-хоста. Например, для увеличения лимита на размер загружаемых файлов:

client_max_body_size 100M;

Эти директивы будут вставлены в блок server для данного прокси-хоста.

Access Lists

NPM позволяет создавать списки контроля доступа, чтобы ограничить доступ к вашим сервисам по IP-адресу или требовать базовую HTTP-аутентификацию. Это полезно для внутренних инструментов или тестовых сред.

1. Перейдите в "Access Lists".
2. Нажмите "Add Access List".
3. Настройте правила (например, "Allow" для конкретных IP, "Deny" для всех остальных) или добавьте "Basic Auth" учетные данные.
4. Примените список доступа к нужному прокси-хосту на вкладке "Advanced".

После настройки каждого прокси-хоста, NPM автоматически обновляет конфигурацию Nginx и перезагружает его, обеспечивая мгновенное применение изменений.

Бэкапы и обслуживание

Резервное копирование и регулярное обслуживание — критически важные аспекты для любой производственной системы, включая Nginx Proxy Manager. Потеря конфигурации или SSL-сертификатов может привести к простою всех ваших веб-сервисов.

1. Что бэкапить

Для Nginx Proxy Manager необходимо регулярно бэкапить следующие компоненты:

• Директория ./data: Содержит всю конфигурацию NPM (базу данных SQLite, если вы ее используете, или данные для подключения к внешней БД) и данные Let's Encrypt. Это самое важное.
• Директория ./letsencrypt: Содержит все ваши SSL-сертификаты. Хотя они могут быть перевыпущены, наличие бэкапа ускоряет восстановление.
• Файл docker-compose.yml: Содержит описание ваших Docker-сервисов и их конфигурацию.

В нашем случае, поскольку мы используем MariaDB в отдельном контейнере, данные базы данных хранятся в ./data/mysql. Все критически важные данные уже охватываются бэкапом директории ./data.

2. Простой скрипт автобэкапа

Создадим простой скрипт, который будет создавать архив с необходимыми данными и сохранять его.

Создайте файл backup_npm.sh в домашней директории вашего пользователя:

nano ~/backup_npm.sh

Вставьте следующее содержимое. Этот скрипт остановит контейнеры NPM (чтобы избежать повреждения БД во время бэкапа), создаст архив, а затем снова запустит их.

#!/bin/bash

# Директория, где находится ваш docker-compose.yml для NPM
NPM_DIR="/home/$USER/nginx-proxy-manager"
BACKUP_DIR="/var/backups/npm" # Директория для хранения бэкапов
DATE=$(date +%Y%m%d%H%M%S)
BACKUP_FILE="${BACKUP_DIR}/npm_backup_${DATE}.tar.gz"

echo "Starting Nginx Proxy Manager backup at ${DATE}..."

# Создаем директорию для бэкапов, если ее нет
sudo mkdir -p ${BACKUP_DIR}
sudo chown $USER:$USER ${BACKUP_DIR} # Убедитесь, что у пользователя есть права на запись

# Переходим в директорию NPM
cd ${NPM_DIR} || { echo "Error: NPM directory not found!"; exit 1; }

# Останавливаем NPM сервисы для консистентного бэкапа
echo "Stopping NPM services..."
docker compose stop

# Создаем архив с данными NPM и letsencrypt
echo "Creating backup archive..."
tar -czf ${BACKUP_FILE} data docker-compose.yml

# Запускаем NPM сервисы обратно
echo "Starting NPM services..."
docker compose start

# Удаляем старые бэкапы (например, старше 7 дней)
echo "Cleaning up old backups..."
find ${BACKUP_DIR} -type f -name "npm_backup_.tar.gz" -mtime +7 -delete

echo "Backup complete: ${BACKUP_FILE}"

chmod +x ~/backup_npm.sh

~/backup_npm.sh

crontab -e

0 3    /home/ВАШЕ_ИМЯ_ПОЛЬЗОВАТЕЛЯ/backup_npm.sh >> /var/log/npm_backup.log 2>&1

Замените ВАШЕ_ИМЯ_ПОЛЬЗОВАТЕЛЯ на имя вашего пользователя.

4. Куда складывать бэкапы (внешнее хранилище)

Хранить бэкапы на том же сервере, что и оригинальные данные, рискованно. Если сервер выйдет из строя, вы потеряете и данные, и бэкапы. Рекомендуется использовать внешнее хранилище:

• Облачное хранилище объектов (S3-совместимое): AWS S3, Backblaze B2, DigitalOcean Spaces, MinIO. Это надежные и масштабируемые решения. Вы можете использовать утилиты вроде rclone для автоматической синхронизации локальных бэкапов с облаком.
• Отдельный VPS: Вы можете настроить второй, небольшой VPS и использовать rsync или scp для копирования бэкапов туда.
• Локальный NAS/ПК: Если ваш VPS имеет публичный IP, вы можете настроить VPN-туннель и копировать бэкапы на домашний NAS или ПК.

Пример интеграции rclone в скрипт бэкапа (после строки echo "Backup complete: ${BACKUP_FILE}"):

# Синхронизация с S3-совместимым хранилищем (предполагается, что rclone уже настроен)
echo "Syncing backups to remote storage..."
rclone copy ${BACKUP_DIR} remote:npm-backups --min-age 1d

5. Обновления: rolling vs maintenance window

Регулярные обновления Docker-образов Nginx Proxy Manager и MariaDB важны для получения новых функций, исправлений ошибок и патчей безопасности.

• Rolling updates: Для NPM это не совсем "rolling", так как это один экземпляр. Но вы можете обновлять его в любое время.
• Maintenance window: Рекомендуется планировать обновления на время наименьшей активности пользователей, так как обновление повлечет за собой короткий простой (несколько секунд до минуты), пока старый контейнер останавливается и запускается новый.

Процесс обновления:

Перейдите в директорию nginx-proxy-manager:

cd ~/nginx-proxy-manager

Остановите и удалите старые контейнеры и скачайте новые образы:

docker compose down             # Останавливает и удаляет контейнеры
docker compose pull             # Скачивает последние версии образов (указанные в docker-compose.yml)
docker compose up -d            # Запускает новые контейнеры

Если вы хотите обновить только один сервис (например, NPM, но не MariaDB), вы можете указать его имя:

docker compose pull app
docker compose up -d app

Всегда делайте бэкап перед крупными обновлениями или изменениями конфигурации.

Troubleshooting + FAQ

В процессе настройки Nginx Proxy Manager могут возникнуть различные проблемы. Здесь мы рассмотрим наиболее частые из них и дадим рекомендации по их устранению.

Что делать, если веб-интерфейс Nginx Proxy Manager недоступен по порту 81?

Сначала убедитесь, что контейнер NPM запущен. Подключитесь по SSH к вашему VPS и выполните команду docker compose ps в директории nginx-proxy-manager. Если статус контейнера app не Up, проверьте логи командой docker compose logs app на наличие ошибок. Убедитесь, что порт 81 не занят другим приложением на вашем VPS и что UFW разрешает входящие соединения на этот порт (sudo ufw status verbose).

Почему не выдается SSL-сертификат от Let's Encrypt?

Наиболее частые причины:

• Неправильные DNS-записи: Убедитесь, что DNS-запись типа A для вашего домена (например, app.example.com) указывает на публичный IP-адрес вашего VPS. Проверьте это с помощью dig app.example.com.
• Брандмауэр: Порты 80 и 443 должны быть открыты на вашем VPS (UFW должен разрешать 'Nginx Full'). Let's Encrypt использует эти порты для проверки владения доменом (HTTP-01 challenge).
• NPM не может связаться с Let's Encrypt: Убедитесь, что ваш VPS имеет доступ в интернет и DNS-разрешение работает корректно.
• Превышен лимит Let's Encrypt: Если вы делали много неудачных попыток, вы могли временно превысить лимиты Let's Encrypt. Подождите несколько часов и попробуйте снова.
• Неверный email: Убедитесь, что указали действительный адрес электронной почты в настройках SSL.

Мой прокси-хост настроен, но сервис не открывается или выдает ошибку 502 Bad Gateway.

Ошибка 502 обычно означает, что Nginx Proxy Manager не смог подключиться к вашему внутреннему сервису. Проверьте следующее:

• Forward Hostname / IP и Forward Port: Убедитесь, что эти параметры в настройках прокси-хоста указаны верно. Если сервис находится на том же VPS, используйте 127.0.0.1 или имя Docker-контейнера (если они в одной Docker-сети).
• Доступность внутреннего сервиса: Убедитесь, что ваш внутренний сервис действительно запущен и слушает на указанном порту. Вы можете проверить это с VPS с помощью curl http://127.0.0.1:ПОРТ_СЕРВИСА.
• Брандмауэр на VPS: Если ваш внутренний сервис работает в отдельном Docker-контейнере или на другом порту, убедитесь, что его порт доступен для NPM (обычно Docker управляет своей внутренней сетью, но стоит проверить).

Как обновить Nginx Proxy Manager?

Для обновления NPM до последней версии, указанной в вашем docker-compose.yml, выполните следующие команды в директории nginx-proxy-manager:

docker compose down
docker compose pull
docker compose up -d

Перед обновлением всегда рекомендуется сделать бэкап!

Какой VPS-конфиг минимально подойдёт?

Для базовой установки Nginx Proxy Manager и нескольких легких сервисов (например, небольшой сайт, Mattermost для 5-10 человек, Bitcoin-нода) вам будет достаточно VPS с 1 vCPU, 1 GB RAM и 25-30 GB SSD. Этого хватит для стабильной работы NPM и обработки умеренного трафика. Однако, если вы планируете запускать более ресурсоемкие приложения или большое количество сервисов, лучше рассмотреть конфигурацию с 2 vCPU и 2-4 GB RAM.

Что выбрать — VPS или dedicated для этой задачи?

Для большинства пользователей и сценариев, описанных в этом руководстве (разработчик, соло-фаундер, игрок, криптоэнтузиаст), VPS является оптимальным выбором. Он предлагает достаточную производительность, гибкость и значительно более низкую стоимость по сравнению с dedicated сервером. Dedicated сервер стоит рассматривать только в случаях очень высокой нагрузки (сотни тысяч запросов в секунду, десятки высоконагруженных сервисов), необходимости в специализированном оборудовании (GPU, большой объем RAM или диска, RAID-массивы) или строгих требованиях к полной изоляции.

Как настроить перенаправление HTTP на HTTPS?

Nginx Proxy Manager делает это автоматически. При создании или редактировании прокси-хоста на вкладке "SSL" просто включите опцию "Force SSL". NPM добавит необходимые директивы Nginx для перенаправления всего HTTP-трафика на HTTPS.

Выводы и следующие шаги

Поздравляем! Вы успешно установили и настроили Nginx Proxy Manager на вашем VPS, а также научились управлять обратными прокси и SSL-сертификатами через удобный веб-интерфейс. Теперь ваш сервер готов к развертыванию и публикации различных веб-сервисов, будь то личные проекты, командные инструменты или коммерческие приложения, с уверенностью в безопасности и удобстве управления.

Вот несколько шагов, куда можно двигаться дальше, чтобы максимально использовать ваш новый Nginx Proxy Manager:

1. Развертывание новых сервисов: Теперь, когда у вас есть централизованный прокси, вы можете легко добавлять новые Docker-контейнеры с вашими приложениями (GitLab, Mattermost, WordPress, Nextcloud и т.д.) и быстро публиковать их в интернете, настраивая прокси-хосты в NPM.
2. Мониторинг сервера: Установите инструменты мониторинга, такие как Prometheus + Grafana, Netdata или Zabbix, чтобы отслеживать состояние вашего VPS, использование ресурсов Docker-контейнерами и производительность Nginx Proxy Manager.
3. Дополнительная безопасность: Рассмотрите возможность использования Cloudflare (или аналогичного CDN/WAF) перед Nginx Proxy Manager для дополнительной защиты от DDoS-атак, кэширования контента и улучшения производительности. Также изучите возможность использования более сложных списков контроля доступа или интеграции с системами единого входа (SSO).