У вас є VPS із п'ятьма чи шістьма службами Docker на ньому: Nextcloud, Uptime Kuma, блог Ghost, можливо, Vaultwarden. Одна публічна IP-адреса. І ви хочете, щоб кожна з них була на власному субдомені з HTTPS, без ручного редагування конфігураційних файлів Nginx щоразу, коли ви додаєте контейнер. Це саме та проблема, для розв'язання якої існує Nginx Proxy Manager.
Це огляд і повне налаштування Nginx Proxy Manager на VPS в одному посібнику. Nginx Proxy Manager (NPM) — це застосунок Docker, який огортає Nginx у вебінтерфейс: ви спрямовуєте субдомени на бекенд-контейнери та запитуєте сертифікати Let's Encrypt через панель керування замість того, щоб писати директиви вручну. Посібник призначений для тих, хто хостить самостійно, і системних адміністраторів, які вже запускають Docker і тепер потребують зворотного проксі, що не вимагає торкатися nginx.conf.
Наприкінці ви знатимете, чи підходить NPM для вашого випадку, матимете його запущеним з HTTPS на вашому VPS та знатимете критерії переходу на Caddy чи Traefik, коли NPM перестає бути правильним інструментом.
Коротко
- Що таке NPM: застосунок Docker, який додає вебінтерфейс поверх Nginx для керування проксі-хостами та автоматичним HTTPS від Let's Encrypt. Він підходить для людей, які хочуть GUI і запускають невеликий, доволі статичний стек служб.
- Компроміси: конфігурація зберігається в базі даних SQLite, тому вона не підлягає контролю версій і не порівнюється (diff), як конфігураційний файл. Станом на 12 липня 2026 року останній тегований реліз уражений CVE-2026-40519, тож нові розгортання мають дочекатися тегованого релізу з виправленням. Його адмінпанель на порту 81 — це головне, що вам потрібно захистити.
- Підбір ресурсів: Сам NPM у стані спокою споживає близько 50 MB RAM. VPS із 1 GB — це практичний базовий рівень; 2 GB комфортні, коли ви додаєте служби позаду нього.
- Коли переходити: залишайтеся на NPM для невеликого, здебільшого статичного стеку, де важливий GUI. Використовуйте Caddy, коли ви хочете конфігурацію як код і менший слід. Використовуйте Traefik, коли часті зміни контейнерів роблять автовиявлення Docker ціннішим за ручну реєстрацію хостів.
Що цей посібник не охоплює
Це посібник із розгортання на VPS, а не довідковий посібник. Щоб зберегти його зосередженість, наступне виходить за межі теми:
- Глибоке налаштування директив Nginx (власні блоки location поза межами того, що надає інтерфейс NPM).
- Архітектура балансування навантаження у великих масштабах.
- Порівняння ingress у Kubernetes.
- NPM на Windows.
- Шлях через Cloudflare Tunnel для конфігурацій без статичної IP-адреси.
Що робить Nginx Proxy Manager (і де він вас підводить)
Nginx Proxy Manager — це застосунок Docker, який запускає Nginx усередині та додає вебпанель керування зверху. Ви створюєте проксі-хости (субдомен до бекенд-контейнера та порту) і запитуєте сертифікати Let's Encrypt через форми замість конфігураційних файлів. Він підходить для невеликого, доволі статичного стеку самостійно розміщуваних застосунків на одному VPS.
Окрім базових речей, панель керування також обробляє списки доступу та переспрямування необроблених потоків TCP/UDP. Для стеку застосунків на одному VPS це справжня зручність: ви додаєте контейнер, відкриваєте панель керування, спрямовуєте на нього субдомен, клацаєте для видачі сертифіката. Готово.
Головний компроміс полягає в тому, що еталонна конфігурація NPM за замовчуванням зберігається в базі даних SQLite. NPM справді генерує читабельні файли Nginx у /data/nginx/proxy_host/, але ці файли є згенерованими артефактами, а не декларативною конфігурацією, яку ви редагуєте та контролюєте за версіями. Ви можете оглядати їх, але вони не є чистою заміною для Caddyfile чи міток Traefik, і надійний спосіб відтворити розгортання — це відновити томи даних та сертифікатів NPM. Для невеликого статичного стеку це може бути прийнятним. Для інфраструктурного робочого процесу на основі Git це справжнє обмеження.
Станом на 12 липня 2026 року останній тегований реліз — це v2.15.1, опублікований 3 червня 2026 року. Проєкт залишається активним і ліцензованим за MIT, але його поточний стан безпеки потребує важливого застереження: NVD перелічує версії від 2.9.14 до 2.15.1 як уражені CVE-2026-40519, автентифікованою вразливістю ін'єкції команд, виправленою в коміті a5db5ed , але ще не включеною до новішого тегованого релізу. Перед розгортанням перевірте сторінку релізів і використовуйте першу теговану версію, що містить це виправлення. NPM підтримується, але v2.15.1 наразі не слід описувати як повністю виправлений.
Щодо сліду, NPM у стані спокою споживає приблизно 50 MB RAM згідно з порівнянням зворотних проксі від byte-guard. Це достатньо легко, щоб NPM майже ніколи не був тим, що навантажує ваш VPS. Навантажують служби позаду нього.
Моя думка: NPM — розумний вибір для 2026 року, якщо ви хочете GUI і запускаєте невеликий стек Docker. Якщо ви живете в системі контролю версій і хочете, щоб ваша конфігурація проксі була в Git, натомість подивіться на Caddy. Вирішальним чинником є конфігурація на основі SQLite, а не щось не так із самим проксіюванням.
NPM обмінює переносимість конфігурації на GUI. Цей обмін прийнятний для невеликого статичного стеку та дратівливий для робочого процесу на основі Git.
NPM проти Caddy проти Traefik: який зворотний проксі підходить вашому VPS
Три інструменти розходяться за чотирма осями, що визначають вибір: як ви їх налаштовуєте, як вони обробляють HTTPS, як вони масштабуються з кількістю служб і скільки RAM вони споживають у стані спокою. Ось порівняння.
| Атрибут | Менеджер проксі Nginx | Caddy | Traefik |
|---|---|---|---|
| Модель конфігурації | Вебінтерфейс, зберігається в SQLite | Caddyfile (текст, контрольований за версіями) | Мітки Docker / YAML |
| Автоматичний HTTPS | Так, запит для кожного хоста в інтерфейсі | Так, за замовчуванням, без налаштування | Так, потребує конфігурації розв'язувача ACME |
| Автовиявлення Docker | No | No | Так, через мітки контейнерів |
| RAM у стані спокою | ~50 MB | ~30 MB | ~80 MB |
| Найкращий випадок застосування | Користувачі GUI, невеликі/статичні стеки | Конфігурація як код, найменший слід | Динамічні стеки Docker із частими змінами контейнерів |
Показники RAM у стані спокою є приблизними спостереженнями з одного порівняння 2026 року, а не фіксованими вимогами. Фактичне використання залежить від версії образу, увімкнених функцій, трафіку та журналювання.
Критерії переходу випливають безпосередньо з цієї таблиці. Якщо ви хочете панель керування і запускаєте кілька служб, що змінюються нечасто, NPM — правильний інструмент. Якщо ви віддаєте перевагу конфігурації як коду, хочете найменший слід або цінуєте автоматичне надання та поновлення HTTPS від Caddy без жодного налаштування ACME, використовуйте Caddy. Я сам звертаюся до Caddy для розгортань одного сайту, тому що обробка SSL автоматична, а Caddyfile короткий. Якщо ви часто додаєте, видаляєте чи повторно розгортаєте контейнери, автовиявлення Traefik на основі міток означає, що ви припиняєте вручну реєструвати кожен новий хост.
Є також «голий» Nginx із Certbot, якому деякі адміністратори віддають перевагу для точного контролю чи розгортань без Docker. Certbot може автоматизувати поновлення сертифікатів, але ви все одно самостійно керуєте маршрутизацією віртуальних хостів і конфігурацією Nginx. Якщо ваша головна причина розглядати NPM — уникнення ручного налаштування проксі, «голий» Nginx навряд чи буде кращим варіантом.
Одне зауваження щодо вибору: порівняння byte-guard визначає Caddy як найлегший варіант у цьому порівнянні, і для нового налаштування одного хоста у 2026 році це розумний вибір. Caddy виграє тим, що легший за NPM, але якщо ви конкретно хочете GUI, це не найкращий варіант для вас.
Для глибшого порівняння базових рушіїв дивіться порівняння Caddy проти Nginx на VPS.
Попередні умови: що вам знадобиться
Перед розгортанням підготуйте наступне. Це короткий список, але пропустіть будь-який пункт, і крок із сертифікатом згодом провалиться.
- VPS зі встановленими Docker та Docker Compose (Ubuntu 22.04 LTS або Debian 12 підійдуть).
- Доменне ім'я з DNS-записом A (та AAAA, якщо ви використовуєте IPv6), що вказує на публічну IP-адресу вашого VPS.
- SSH-доступ до VPS.
- Порти 80 і 443, відкриті для інтернету на вашому фаєрволі.
- Порт 81, доступний лише вам, не відкритий для публіки (розглянуто в розділі про безпеку).
Налаштування Nginx Proxy Manager на вашому VPS за допомогою Docker Compose
Цей розділ розгортає NPM за допомогою Docker Compose. Щойно ваші DNS-записи розв'язуються на VPS, налаштування самого контейнера відбувається швидко, хоча поширення DNS та видача сертифіката можуть тривати довше.
Налаштування використовує один файл Docker Compose та одноразову команду для створення спільної мережі Docker. Створіть каталог, створіть мережу, додайте docker-compose.yml файл нижче та запустіть контейнер.
Спершу створіть спільну мережу Docker:
docker network create proxyПотім створіть наступний docker-compose.yml файл:
# docker-compose.yml
services:
npm:
image: 'jc21/nginx-proxy-manager:<PATCHED_VERSION>'
restart: unless-stopped
ports:
- '80:80' # public HTTP
- '443:443' # public HTTPS
- '127.0.0.1:81:81' # admin UI, reachable only from the VPS itself
volumes:
- ./data:/data
- ./letsencrypt:/etc/letsencrypt
networks:
- proxy
networks:
proxy:
external: trueПриєднайте кожен бекенд-контейнер, до якого NPM має звертатися за іменем служби, до тієї самої зовнішньої proxy мережі. Це дозволяє NPM розв'язувати контейнер за іменем його служби без публікації порту бекенд-застосунку на VPS.
Створіть резервні копії обох ./data та ./letsencrypt перед оновленнями. Каталог даних містить базу даних NPM та згенеровану конфігурацію, тоді як каталог Let's Encrypt містить його матеріал сертифікатів.
Кілька речей про цей файл. Образ за замовчуванням використовує базу даних SQLite, що зберігається в томі ./data . Це типовий бекенд, і він правильний для більшості розгортань на одному VPS. Якщо вам потрібна зовнішня база даних, NPM підтримує MariaDB/MySQL та PostgreSQL, що означає додавання служби бази даних та відповідних змінних середовища. Для одного VPS SQLite усе ще є найпростішим варіантом за замовчуванням, якщо у вас немає чіткої причини винести базу даних за межі тому даних. Політика restart: unless-stopped означає, що NPM знову запуститься, якщо VPS перезавантажиться, а це саме те, що вам потрібно для служби, яка стоїть перед усім іншим.
Запустіть його та переконайтеся, що він працює:
docker compose up -d
docker compose psОчікуваний вивід: контейнер npm зі станом Up, порти 80 і 443 публічно зіставлені, а порт 81 прив'язаний лише до 127.0.0.1. Перший запуск триває кілька хвилин, поки NPM генерує ключ JWT, ініціалізує базу даних і створює типового користувача-адміністратора. офіційна документація з налаштування описує цю послідовність першого запуску.
Створіть SSH-тунель зі свого локального комп'ютера перед відкриттям адміністративного інтерфейсу:
ssh -L 8181:127.0.0.1:81 user@your-vpsПотім відкрийте http://127.0.0.1:8181 у вашому браузері. На новому встановленні увійдіть за допомогою [email protected] та changeme, потім негайно замініть типові електронну пошту та пароль. Не робіть панель керування публічно доступною, поки типові облікові дані активні.
Щойно ви змінили облікові дані адміністратора, додайте свій перший проксі-хост:
- У панелі керування перейдіть до Hosts, потім Proxy Hosts, потім Add Proxy Host.
- Встановити Domain Name на ваш субдомен (наприклад,
cloud.example.com). - Встановити Forward Hostname / IP на ім'я чи IP бекенд-контейнера, а Forward Port на порт, який він слухає.
- Збережіть. Проксі-хост з'являється у списку, і трафік до цього субдомену тепер досягає вашого контейнера.
Якщо ви запускаєте інтерфейс керування Docker разом із цим, застосовується той самий шаблон: так само спрямуйте субдомен на інструмент керування контейнерами і зробіть те саме для стеком моніторингу Prometheus і Grafana , який ви хочете розмістити за проксі.
Налаштування автоматичного HTTPS для субдомену
Цей розділ дає вам дійсний сертифікат Let's Encrypt із автоматичним поновленням для вашого субдомену. Передумова, яка підводить людей, така: DNS-запис A для цього субдомену вже має вказувати на ваш VPS, а порт 80 має бути доступним з інтернету, оскільки Let's Encrypt перевіряє домен, під'єднуючись назад до нього.
Після створення проксі-хоста запитайте сертифікат:
- Відредагуйте проксі-хост, відкрийте вкладку SSL вкладка.
- Під Сертифікат SSLвиберіть Request a new SSL Certificate.
- Увімкнути Force SSL та HTTP/2 Support. Вмикайте HSTS лише після підтвердження того, що HTTPS працює правильно, оскільки браузери можуть кешувати політику й ускладнити відновлення після помилки конфігурації сертифіката чи проксі.
- Погодьтеся з умовами Let's Encrypt та збережіть.
За замовчуванням NPM використовує виклик HTTP-01 для не-wildcard імен, перевіряючи кожне запитуване ім'я хоста через порт 80. Сертифікат може містити кілька не-wildcard імен, але HTTP-01 не може видавати wildcard-сертифікати. Wildcard-імена, як-от *.example.com потребують виклику DNS-01 із підтримуваним DNS-провайдером. Для звичайного налаштування «один субдомен на службу» HTTP-01 — це все, що вам потрібно, і поновлення відбуваються автоматично.
Якщо запит сертифіката провалюється, спершу перевірте порт 80. Поширені причини включають недоступний порт 80, неправильне правило хмарного фаєрвола чи групи безпеки та DNS, що не завершив поширення. Let's Encrypt не може перевірити домен, до якого не може дістатися.
Захист адмінпанелі NPM на VPS
Адміністративний інтерфейс на порту 81 — це основна вразливість розгортання NPM, і цей розділ його захищає. Це операційне зміцнення, а не аудит безпеки: три речі, зроблені один раз, і профіль ризику різко знижується.
По-перше, і найважливіше, тримайте порт 81 прив'язаним до 127.0.0.1 , як показано у файлі Docker Compose. Отримуйте доступ до панелі керування через SSH-тунель, описаний раніше. Якщо вам потрібен постійний віддалений доступ, зробіть адміністративний інтерфейс доступним лише через приватний VPN. Не публікуйте порт 81 на публічній IP-адресі VPS.
По-друге, увімкніть двофакторну автентифікацію TOTP на вашому обліковому записі адміністратора. NPM додав 2FA на основі TOTP у версії 2.13.6, тож будь-яке поточне встановлення її має. Увімкніть її.
По-третє, тримайте NPM оновленим і перевіряйте точний реліз, а не припускайте, що тег latest безпечний. CVE-2026-40519 уражає версії від 2.9.14 до 2.15.1 і може дозволити автентифіковане віддалене виконання коду через шкідливі облікові дані DNS-провайдера. CVE-2026-50892 уражає v2.14.0 і може дозволити автентифікованому зловмиснику отримати матеріал приватного ключа Let's Encrypt. Раніша проблема, CVE-2025-50579, уражала v2.12.3 через ваду CORS, що могла розкрити токени JWT. Практичне правило просте: тримайте порт 81 приватним, увімкніть двофакторну автентифікацію, закріпіть відому виправлену версію та перевіряйте рекомендації з безпеки перед оновленням.
Порт 81 залишається приватним, а NPM залишається оновленим. Зробіть ці дві речі, і основними відомими ризиками стає набагато легше керувати для звичайного налаштування на одному VPS.
Підбір ресурсів вашого VPS для Nginx Proxy Manager
Сам NPM легкий; питання підбору ресурсів насправді стосується NPM плюс служб, що стоять позаду нього. Слід проксі у стані спокою рідко є обмеженням. Екземпляр Nextcloud чи блог Ghost використовуватимуть більше ресурсів, ніж сам проксі.
Ось як рівні працюють на практиці:
- Мінімальний практичний базовий рівень: 1 GB RAM, 1 vCPU та 10 GB сховища. Один сторонній посібник із підбору ресурсів використовує той самий базовий рівень, але розглядайте його як рекомендацію для планування, а не як офіційну вимогу NPM. Цього достатньо для NPM, операційної системи та кількох легких служб, але залишається обмежений запас.
- Комфортно: 2 GB RAM, 1 vCPU, 20 GB сховища. NPM плюс три-п'ять служб із простором для маневру. Це оптимальний варіант для більшості тих, хто хостить самостійно.
- Наступний рівень: 4 GB RAM, 2 vCPU. Для восьми-дванадцяти служб або конфігурації зі значним трафіком, де ви хочете запас CPU для завершення TLS.
Число, під яке ви підбираєте ресурси, — це сума проксійованих застосунків, а не NPM. Складіть сліди RAM служб, які ви маєте намір запускати, додайте зверху невеликі накладні витрати проксі у стані спокою та оберіть рівень із запасом.
Підбір ресурсів сервера — це проста частина. Запуск NPM усе одно означає провізіонування VPS, встановлення Docker, завантаження образу та проходження налаштування першого запуску. Якщо ви волієте пропустити кроки провізіонування, маркетплейс Cloudzy має розгортання в один клік Nginx Proxy Manager на VPS із NVMe. Воно піднімає контейнер на новому сервері, тож ви одразу переходите до панелі керування та вашого першого проксі-хоста. У будь-якому разі, наведені вище рівні ресурсів — це те, під що ви провізіонуєте.
Часті запитання
Яка різниця між Nginx та Nginx Proxy Manager?
Nginx — це сам вебсервер і рушій зворотного проксі, який ви налаштовуєте, редагуючи текстові файли. Nginx Proxy Manager — це застосунок Docker, який запускає Nginx усередині та додає вебінтерфейс зверху, тож ви керуєте проксі-хостами та сертифікатами Let's Encrypt через панель керування замість написання конфігураційних файлів. NPM — це шар GUI; Nginx — це рушій, що виконує роботу.
Чи все ще варто використовувати Nginx Proxy Manager у 2026 році?
Так, для користувачів, які віддають перевагу GUI і запускають невеликий стек Docker, але лише після того, як ви перевірите, що образ, який ви розгортаєте, містить останні виправлення безпеки. Станом на 12 липня 2026 року v2.15.1 є останнім тегованим релізом, і NVD перелічує його як уражений CVE-2026-40519. Якщо ви віддаєте перевагу конфігурації як коду, Caddy залишається кращим варіантом; конфігурація NPM на основі SQLite є його головним операційним обмеженням.
Який мінімальний обсяг RAM для Nginx Proxy Manager?
Сам NPM у стані спокою споживає приблизно 50 MB RAM. VPS із 1 GB — це практичний базовий рівень, достатній для NPM плюс кількох легких служб. 2 GB комфортні, коли ви додаєте більше проксійованих застосунків. Реальна вимога до RAM визначається службами позаду NPM, а не самим NPM.
Чи слід відкривати порт 81 в інтернет?
Ні. Тримайте порт 81 прив'язаним до localhost і отримуйте доступ до нього через SSH-тунель або зробіть його доступним лише через приватний VPN. Не публікуйте адміністративний інтерфейс на публічній IP-адресі VPS.
Чи можна запустити Nginx Proxy Manager без Docker?
Ні. NPM розповсюджується та розроблений як контейнер Docker, і немає підтримуваного встановлення без Docker. Якщо ви не можете або не хочете запускати Docker, натомість використовуйте «голий» Nginx із Certbot або Caddy як єдиний бінарний файл.
Чи підтримує Nginx Proxy Manager wildcard-сертифікати?
Так, через виклик DNS-01 із налаштованим підтримуваним DNS-провайдером. Стандартні сертифікати для одного імені хоста використовують виклик HTTP-01 через порт 80; wildcard-сертифікати (*.example.com) потребують DNS-01, оскільки центр сертифікації перевіряє контроль шляхом запису DNS-запису, а не звертанням до одного хоста.
