Как разместить несколько сайтов на одном VPS с Nginx Proxy Manager

В этом руководстве развернём на одном VPS два демонстрационных сайта и настроим маршрутизацию к ним через Nginx Proxy Manager. Оба приложения будут работать в Docker-контейнерах и находиться в общей внутренней Docker-сети с reverse proxy.

В процессе:

• Установим Docker и Docker Compose;
• Развернём Nginx Proxy Manager и два отдельных сайта;
• Подключим контейнеры к общей Docker-сети;
• Привяжем к сайтам разные доменные имена;
• Создадим отдельный Proxy Host для каждого сайта;
• Настроим SSL-сертификаты и перенаправление HTTP → HTTPS;
• Разберём работу Access Lists для ограничения доступа;
• Объясним, почему внутренние порты приложений лучше не публиковать напрямую в интернет.

В результате один VPS сможет обслуживать несколько сайтов через единые точки входа на портах 80 и 443, а сами приложения останутся изолированными внутри Docker-сети.

Что будем разворачивать

В этом руководстве на одном VPS развернём два независимых демонстрационных сайта и настроим доступ к ним через Nginx Proxy Manager. Каждый сайт будет работать в отдельном Docker-контейнере, а Nginx Proxy Manager возьмёт на себя маршрутизацию запросов, работу с доменами и HTTPS.

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

Как будет работать схема

Внешний трафик будет приходить на один публичный IP-адрес VPS через стандартные порты 80 и 443. Nginx Proxy Manager определит нужный сервис по доменному имени (SNI) и передаст запрос соответствующему контейнеру.

Условно схема будет выглядеть так:

При этом порты самих сайтов не потребуется публиковать на интерфейсе VPS. Из интернета будут доступны только Nginx Proxy Manager и необходимые ему порты. Такой подход уменьшает количество сервисов, напрямую доступных извне, и упрощает управление маршрутизацией.

Что понадобится для развёртывания

Для выполнения руководства понадобится:

• VPS с Ubuntu 24.04 и доступом по SSH с правами sudo;
• Публичный IPv4-адрес;
• Docker Engine и Docker Compose;
• Два доменных имени или поддомена, направленных на VPS;
• Открытые TCP-порты 80 и 443 для HTTP и HTTPS;
• Порт управления Nginx Proxy Manager, который будем использовать только для первоначальной настройки;
• Два демонстрационных веб-приложения.

В примерах мы будем использовать условный публичный адрес 203.0.113.10. Это адрес из диапазона, зарезервированного для документации, поэтому при реальном развёртывании его необходимо заменить на публичный IP вашего VPS.

Подготовка VPS

Перед развёртыванием Nginx Proxy Manager установим Docker и подготовим отдельную рабочую директорию для Compose-файлов и конфигурации.

Установка Docker

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

sudo apt update

sudo apt install -y ca-certificates curl

Создадим каталог для ключей APT и импортируем официальный ключ Docker:

sudo install -m 0755 -d /etc/apt/keyrings

sudo curl -fsSL https://download.docker.com/linux/ubuntu/gpg \

  -o /etc/apt/keyrings/docker.asc

sudo chmod a+r /etc/apt/keyrings/docker.asc

Добавим официальный репозиторий Docker:

echo \

  "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] https://download.docker.com/linux/ubuntu \

  $(. /etc/os-release && echo "${UBUNTU_CODENAME:-$VERSION_CODENAME}") stable" | \

  sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

Обновим индекс пакетов и установим Docker Engine вместе с Compose Plugin:

sudo apt update

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

После установки проверим версии компонентов:

docker --version

docker compose version

Если обе команды возвращают установленные версии, Docker готов к работе.

Создание рабочей директории

Чтобы файлы Nginx Proxy Manager и демонстрационных сайтов находились в одном месте, создадим отдельный каталог проекта:

mkdir -p ~/npm-guide

cd ~/npm-guide

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

Разворачиваем Nginx Proxy Manager

Теперь развернём Nginx Proxy Manager в Docker. Он будет выступать единой точкой входа для обоих сайтов: принимать HTTP- и HTTPS-запросы, выбирать нужный Proxy Host по доменному имени и передавать трафик соответствующему контейнеру.

Создание Compose-файла

В рабочей директории создадим файл compose.yaml: nano compose.yaml

Добавим конфигурацию Nginx Proxy Manager и MariaDB:

services:

  npm:

    image: jc21/nginx-proxy-manager:2.12.6

    container_name: npm

    restart: unless-stopped

    ports:

      - "80:80"

      - "81:81"

      - "443:443"

    environment:

      DB_MYSQL_HOST: db

      DB_MYSQL_PORT: 3306

      DB_MYSQL_USER: npm

      DB_MYSQL_PASSWORD: change_this_password

      DB_MYSQL_NAME: npm

    volumes:

      - npm_data:/data

      - npm_letsencrypt:/etc/letsencrypt

    depends_on:

      - db

    networks:

      - proxy

  db:

    image: mariadb:11.4

    container_name: npm-db

    restart: unless-stopped

    environment:

      MARIADB_ROOT_PASSWORD: change_root_password

      MARIADB_DATABASE: npm

      MARIADB_USER: npm

      MARIADB_PASSWORD: change_this_password

    volumes:

      - npm_db:/var/lib/mysql

    networks:

      - proxy

volumes:

  npm_data:

  npm_letsencrypt:

  npm_db:

networks:

  proxy:

    name: proxy

Здесь Nginx Proxy Manager публикует три порта:

• 80 — HTTP;
• 443 — HTTPS;
• 81 — административный веб-интерфейс.

MariaDB при этом не публикует порт 3306 на хосте и доступна только контейнерам внутри сети proxy.

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

Сохраним файл и выйдем из редактора.

Запуск контейнеров

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

После загрузки образов проверим состояние контейнеров: docker compose ps

В выводе должны присутствовать npm и npm-db со статусом Up.

Дополнительно можно проверить созданную Docker-сеть: docker network ls

Сеть proxy понадобится далее, когда мы подключим к ней оба демонстрационных сайта.

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

После запуска административный интерфейс Nginx Proxy Manager будет доступен на порту 81: http://203.0.113.10:81

В реальном окружении вместо 203.0.113.10 используйте публичный IP вашего VPS.

При первом запуске Nginx Proxy Manager используйте стандартные учётные данные:

Email: admin@example.com

Password: changeme

После первой авторизации Nginx Proxy Manager предложит изменить данные администратора. Укажите собственный адрес электронной почты и новый сложный пароль.

После авторизации откроется Dashboard. Здесь отображаются Proxy Hosts, сертификаты, Access Lists и другие объекты, которыми будем пользоваться дальше.

Порт 81 предназначен для администрирования и не должен без необходимости оставаться доступным всему интернету. В рабочем окружении доступ к нему лучше ограничить firewall, VPN или доверенными IP-адресами.

Разворачиваем два демонстрационных сайта

Теперь подготовим два простых веб-сайта. Каждый будет работать в собственном контейнере, но оба подключим к той же сети proxy, что и Nginx Proxy Manager.

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

Создание первого сайта

Создадим каталоги для сайтов: mkdir -p site1 site2

Создадим главную страницу первого сайта: nano site1/index.html

Добавим простой HTML:

<!DOCTYPE html>

<html lang="en">

<head>

  <meta charset="UTF-8">

  <title>Site One</title>

</head>

<body>

  <h1>Site One</h1>

  <p>This website is running behind Nginx Proxy Manager.</p>

</body>

</html>

Создание второго сайта

Аналогично создадим страницу второго сайта: nano site2/index.html

Добавим отличающийся контент:

<!DOCTYPE html>

<html lang="en">

<head>

  <meta charset="UTF-8">

  <title>Site Two</title>

</head>

<body>

  <h1>Site Two</h1>

  <p>This is the second website on the same VPS.</p>

</body>

</html>

Теперь дополним compose.yaml двумя новыми сервисами:

 site1:

    image: nginx:1.28-alpine

    container_name: site1

    restart: unless-stopped

    volumes:

      - ./site1:/usr/share/nginx/html:ro

    networks:

      - proxy

  site2:

    image: nginx:1.28-alpine

    container_name: site2

    restart: unless-stopped

    volumes:

      - ./site2:/usr/share/nginx/html:ro

    networks:

      - proxy

Обратите внимание: у этих контейнеров нет секции ports. Это сделано намеренно — сайты будут доступны только внутри Docker-сети и получать внешний трафик исключительно через Nginx Proxy Manager.

Применим изменения: docker compose up -d

Подключение контейнеров к общей Docker-сети

Все четыре контейнера — npm, npm-db, site1 и site2 — подключены к сети proxy.

Проверим её содержимое: docker network inspect proxy

В разделе Containers должны отображаться контейнеры Nginx Proxy Manager, базы данных и обоих сайтов.

Благодаря встроенному DNS Docker Nginx Proxy Manager сможет обращаться к сайтам просто по именам:

site1:80

site2:80

Использовать внутренние IP контейнеров вручную не требуется.

Почему внутренние порты приложений не нужно открывать в интернет

При публикации порта Docker создаёт прямой путь от сетевого интерфейса VPS к контейнеру. Например:

ports:

  - "8081:80"

сделал бы первый сайт доступным напрямую по адресу: http://203.0.113.10:8081

В нашей схеме это не требуется. Nginx Proxy Manager уже принимает внешний трафик и передаёт его нужному сервису внутри сети proxy.

Поэтому наружу публикуются только порты reverse proxy:

80/tcp

443/tcp

а внутренние сайты остаются доступны только контейнерам в Docker-сети.

Это даёт несколько преимуществ:

• Уменьшается количество сервисов, напрямую доступных из интернета;
• Пользователи не могут обойти reverse proxy и обратиться к приложению по внутреннему порту;
• SSL, перенаправления и правила доступа применяются централизованно;
• Конфигурация остаётся понятнее при добавлении новых сайтов.

Именно поэтому для контейнерных приложений за reverse proxy обычно нет необходимости публиковать каждый внутренний порт отдельно.

Привязываем домены к VPS

Чтобы Nginx Proxy Manager мог определять, какому контейнеру передавать запрос, каждому сайту понадобится отдельное доменное имя или поддомен. Оба имени при этом могут указывать на один публичный IP VPS: разделение трафика будет происходить уже на уровне reverse proxy.

В примерах используем условные домены:

site1.example.com

site2.example.com

а вместо реального адреса VPS — документационный IP 203.0.113.10.

DNS-записи для первого и второго сайта

В панели управления DNS создадим две записи типа A:

В реальной конфигурации вместо 203.0.113.10 необходимо указать публичный IPv4-адрес вашего VPS.

Обе записи ведут на один сервер. Это нормально: после получения запроса Nginx Proxy Manager посмотрит на доменное имя внутри него и выберет соответствующий Proxy Host.

Если DNS управляется через Cloudflare, на этапе первоначальной настройки и выпуска сертификатов удобнее временно отключить проксирование записи и использовать режим DNS only. После завершения настройки его при необходимости можно включить обратно.

Изменения DNS могут применяться не мгновенно. Скорость обновления зависит от DNS-провайдера, TTL записи и кешей резолверов.

Проверка DNS

Перед созданием Proxy Hosts убедимся, что оба имени разрешаются в адрес VPS.

Проверить записи можно командами:

getent ahostsv4 site1.example.com

getent ahostsv4 site2.example.com

или:

dig +short A site1.example.com

dig +short A site2.example.com

Для реальной конфигурации обе команды должны вернуть публичный IPv4-адрес сервера.

В нашем примере ожидаемый результат условно выглядит так:

203.0.113.10

203.0.113.10

Если возвращается другой адрес или запись ещё не разрешается, переходить к выпуску SSL-сертификата пока не стоит. Сначала необходимо дождаться обновления DNS или проверить правильность созданных записей.

Настраиваем первый Proxy Host

После настройки DNS можно связать первый домен с контейнером site1. Для этого в Nginx Proxy Manager создадим Proxy Host — правило, которое определяет, куда передавать запросы для конкретного доменного имени.

Добавление домена и адреса контейнера

Откроем Hosts → Proxy Hosts и нажмём Add Proxy Host.

Для первого сайта укажем:

Domain Names: site1.example.com

Scheme: http

Forward Hostname / IP: site1

Forward Port: 80

При необходимости можно также включить параметры Block Common Exploits и Websockets Support. Для нашего простого статического сайта WebSocket не требуется, однако для приложений, которые его используют, эту настройку необходимо включить.

На этом этапе SSL пока можно не настраивать — сертификат добавим отдельно после создания обоих Proxy Hosts.

После сохранения правило будет направлять запросы к site1.example.com на порт 80 контейнера первого сайта.

Как Nginx Proxy Manager обращается к контейнеру по имени

В поле Forward Hostname / IP мы указали не IP контейнера, а имя site1. Это возможно благодаря общей Docker-сети proxy.

Docker предоставляет встроенный DNS для контейнеров, находящихся в одной пользовательской сети. Когда Nginx Proxy Manager обращается к: http://site1:80

Docker самостоятельно разрешает имя site1 во внутренний адрес соответствующего контейнера.

Это предпочтительнее ручного указания внутреннего IP. Адрес контейнера может измениться после его пересоздания или обновления, тогда как имя сервиса остаётся прежним.

В результате маршрут выглядит следующим образом:

Публичный адрес получает только VPS, а непосредственная связь между reverse proxy и сайтом происходит внутри Docker-сети. 

Настраиваем второй Proxy Host

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

Создание второго маршрута

Перейдём в Hosts → Proxy Hosts и снова нажмём Add Proxy Host.

Для второго сайта укажем:

Domain Names: site2.example.com

Scheme: http

Forward Hostname / IP: site2

Forward Port: 80

Как и в случае с первым сайтом, можно включить Block Common Exploits. Опция Websockets Support для нашего статического сайта не требуется.

После сохранения Nginx Proxy Manager получит второй маршрут:

site2.example.com

        ↓

Nginx Proxy Manager

        ↓

site2:80

Теперь один экземпляр reverse proxy обслуживает два независимых сайта. Оба используют одинаковые внешние порты 80 и 443, а выбор нужного контейнера происходит по доменному имени из HTTP-запроса.

Проверка списка Proxy Hosts

Вернёмся в Hosts → Proxy Hosts. В списке должны отображаться два правила:

site1.example.com → site1:80

site2.example.com → site2:80

Если оба Proxy Host отображаются как активные, базовая маршрутизация настроена. При обращении к разным доменам Nginx Proxy Manager будет направлять запросы в разные контейнеры, хотя физически оба сайта находятся на одном VPS.

Настраиваем HTTPS и перенаправление HTTP → HTTPS

На этом этапе оба сайта уже связаны с Proxy Hosts. Теперь включим HTTPS, чтобы соединение между браузером пользователя и Nginx Proxy Manager было зашифровано.

Для каждого домена потребуется отдельный сертификат либо сертификат, охватывающий сразу несколько имён. В нашем примере настроим сертификаты через встроенную интеграцию Nginx Proxy Manager с Let's Encrypt.

Получение сертификата Let's Encrypt

Откроем настройки первого Proxy Host и перейдём на вкладку SSL.

В поле SSL Certificate выберем: Request a new SSL Certificate

После этого укажем адрес электронной почты для Let's Encrypt, примем условия обслуживания и отправим запрос на выпуск сертификата.

Перед выпуском важно убедиться, что:

• Домен уже разрешается в публичный IP VPS;
• Порты 80 и 443 доступны из интернета;
• Запросы к домену действительно доходят до Nginx Proxy Manager;
• Другой веб-сервер на VPS не занимает эти порты.

После успешного выпуска сертификат будет сохранён Nginx Proxy Manager и привязан к выбранному Proxy Host.

Аналогичную операцию выполняем для второго сайта.

Включение Force SSL

После выбора сертификата активируем параметр Force SSL.

Он заставляет Nginx Proxy Manager перенаправлять обычные HTTP-запросы на защищённую HTTPS-версию сайта.

Для Proxy Host итоговые настройки будут выглядеть примерно так:

SSL Certificate: Let's Encrypt

Force SSL: Enabled

HTTP/2 Support: Enabled

Опцию HTTP/2 можно включить вместе с HTTPS, если она доступна в используемой версии Nginx Proxy Manager.

Повторим настройку для второго Proxy Host.

Как работает перенаправление на HTTPS

После включения Force SSL пользователь может ввести обычный адрес http://site1.example.com но Nginx Proxy Manager автоматически перенаправит его на https://site1.example.com

При этом схема взаимодействия становится следующей:

Важно, что HTTPS в этой конфигурации терминируется на Nginx Proxy Manager. Между reverse proxy и демонстрационным контейнером используется обычный HTTP внутри Docker-сети.

Для многих приложений на одном VPS этого достаточно: внутренний сервис не публикуется в интернет, а весь внешний трафик проходит через единую HTTPS-точку входа.

Та же схема работает и для второго сайта: https://site2.example.com → Nginx Proxy Manager → site2:80

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

Настраиваем Access Lists

Nginx Proxy Manager позволяет не только маршрутизировать трафик, но и ограничивать доступ к отдельным Proxy Hosts. Для этого используются Access Lists.

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

Для чего нужны Access Lists

Access List можно привязать к конкретному Proxy Host и определить, кто сможет обращаться к нему.

В зависимости от задачи можно использовать:

• Авторизацию по имени пользователя и паролю;
• Разрешение доступа только с определённых IP-адресов или сетей;
• Запрет доступа для отдельных адресов;
• Сочетание нескольких правил.

Например, публичный сайт можно оставить доступным всем, а административную панель разрешить только из корпоративной сети или через VPN.

При этом Access Lists работают на уровне Nginx Proxy Manager. Сам контейнер приложения по-прежнему остаётся внутри Docker-сети и не публикует собственный порт наружу.

Создание списка доступа

Откроем раздел Access Lists в интерфейсе Nginx Proxy Manager и создадим новый список.

В качестве примера назовём его: Admin Only

На вкладке Authorization можно добавить пользователя и пароль для HTTP Basic Authentication.

Например:

Username: admin

Password: используйте сложный пароль

На вкладке Access можно задать сетевые правила. Например, разрешить доступ только из определённой подсети: 192.0.2.0/24

или с конкретного публичного IP: 192.0.2.10

Адреса выше приведены только как примеры из документационных диапазонов. В рабочей конфигурации следует использовать реальные доверенные адреса или подсети.

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

Привязка Access List к Proxy Host

После сохранения списка вернёмся в Hosts → Proxy Hosts, откроем нужный Proxy Host и выберем созданный список в поле Access List.

Например:

Proxy Host: site2.example.com

Access List: Admin Only

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

Для обычного публичного сайта Access List можно оставить в состоянии Publicly Accessible. Ограничения имеет смысл включать только там, где они действительно нужны.

Проверяем работу нескольких сайтов

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

Проверка первого сайта

Откроем в браузере первый домен: https://site1.example.com

Должна загрузиться страница первого контейнера:

Site One

This website is running behind Nginx Proxy Manager.

Это означает, что цепочка работает полностью:

Далее идёт проверка второго сайта.

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

Теперь откроем второй домен: https://site2.example.com

На этот раз должна отображаться другая страница:

Site Two

This is the second website on the same VPS.

Несмотря на одинаковый публичный IP и одни внешние порты 80 и 443, Nginx Proxy Manager определяет нужный контейнер по доменному имени.

Таким же образом на один VPS можно добавлять дополнительные сайты и приложения: для каждого нового сервиса достаточно подключить контейнер к общей proxy-сети, создать DNS-запись и настроить отдельный Proxy Host.

Проверка HTTPS и изоляции внутренних портов

Для начала попробуем открыть первый сайт по HTTP: http://site1.example.com

При включённом Force SSL браузер должен автоматически перейти на: https://site1.example.com

То же самое проверим для второго сайта.

Дополнительно можно убедиться, что контейнеры приложений не публикуют свои порты на VPS: docker compose ps

Для site1 и site2 в столбце портов не должно быть привязок вида:

0.0.0.0:8081->80/tcp

0.0.0.0:8082->80/tcp

При этом Nginx Proxy Manager должен иметь опубликованные порты 80, 81 и 443.

Для дополнительной проверки можно выполнить: docker ps --format "table {{.Names}}\t{{.Ports}}"

Ожидаемая логика вывода будет следующей:

Записи 80/tcp и 3306/tcp без привязки вида 0.0.0.0:порт->порт означают, что соответствующие порты существуют внутри контейнерной сети, но не опубликованы непосредственно на сетевых интерфейсах VPS.

В результате один VPS обслуживает сразу несколько сайтов через единый reverse proxy. Nginx Proxy Manager централизованно управляет доменами, HTTPS и правилами доступа, а внутренние сервисы остаются изолированными в Docker-сети.

Заключение

Nginx Proxy Manager позволяет разместить несколько сайтов и веб-приложений на одном VPS, не создавая вручную отдельные конфигурации Nginx для каждого проекта. Reverse proxy принимает внешний трафик на портах 80 и 443, определяет нужный Proxy Host по доменному имени и передаёт запрос соответствующему контейнеру.

В рассмотренной конфигурации два демонстрационных сайта работают независимо друг от друга, но используют одну общую Docker-сеть и единый Nginx Proxy Manager. Внутренние порты приложений не публикуются на интерфейсе VPS, поэтому обратиться к ним напрямую из интернета нельзя. Для каждого сайта можно отдельно управлять доменом, SSL-сертификатом, перенаправлением на HTTPS и правилами доступа.

Такую схему можно масштабировать дальше: при добавлении нового проекта достаточно подключить его контейнер к общей proxy-сети, создать DNS-запись и новый Proxy Host. При этом важно контролировать доступ к административному интерфейсу Nginx Proxy Manager и не публиковать внутренние порты без необходимости.

FAQ

Можно ли разместить на одном VPS больше двух сайтов?

Да. Два сайта в руководстве используются только для демонстрации. Один экземпляр Nginx Proxy Manager может обслуживать множество Proxy Hosts, если ресурсов VPS достаточно для работы самого reverse proxy и размещённых приложений.

Нужен ли отдельный публичный IP для каждого сайта?

Нет. Несколько доменных имён могут указывать на один публичный IP. Nginx Proxy Manager определяет нужный Proxy Host по имени домена и направляет запрос в соответствующий контейнер.

Нужно ли открывать порты Docker-контейнеров в интернет?

Обычно нет, если приложение находится за reverse proxy. Контейнер достаточно подключить к общей пользовательской Docker-сети с Nginx Proxy Manager. Docker позволяет контейнерам в такой сети обращаться друг к другу по именам, поэтому приложение может оставаться недоступным напрямую извне.

Для чего нужен порт 81?

По умолчанию Nginx Proxy Manager использует порт 81 для административного веб-интерфейса. Сам HTTP-трафик обслуживается через порт 80, а HTTPS — через 443.

Можно ли закрыть административный интерфейс Nginx Proxy Manager от интернета?

Да, и для рабочего окружения это желательно. Доступ к порту 81 можно ограничить firewall, разрешить только для доверенных IP или организовать через VPN.

Что произойдёт после включения Force SSL?

HTTP-запросы к соответствующему Proxy Host будут перенаправляться на HTTPS. При этом TLS завершается на Nginx Proxy Manager, а до внутреннего контейнера запрос может передаваться по HTTP внутри Docker-сети.

Зачем нужны Access Lists?

Access Lists позволяют дополнительно ограничить доступ к Proxy Host, например с помощью HTTP Basic Authentication или правил по IP-адресам. Это удобно для административных панелей, тестовых сред и других сервисов, которые не должны быть полностью публичными. Nginx Proxy Manager поддерживает Access Lists и базовую HTTP-аутентификацию.

Обязательно ли использовать Nginx Proxy Manager при публикации нескольких сайтов?

Нет, это не обязательно. По большому счёту это административная панель с удобным интерфейсом над Nginx, выступающим в роли reverse proxy. Использовать вместо этого "голый" Nginx с текстовыми конфигами безопасней - но требует более глубокого изучения механизмов его работы.

Почему Let's Encrypt может не выпустить сертификат?

Одна из частых причин — домен ещё не указывает на нужный сервер или проверка не может достучаться до него. При HTTP-01 проверке Let's Encrypt обращается к специальному ресурсу на домене по HTTP, поэтому домен должен корректно разрешаться, а сервер — быть доступен для проверки по 80 порту.

Список источников

1. Nginx Proxy Manager — Full Setup Instructions
2. Nginx Proxy Manager — Guide
3. Docker Docs — Bridge network driver
4. Let's Encrypt — Challenge Types