Nginx или Caddy: что выбрать для панели

3 мин чтенияОбновлено 02.09.2026

Панель Remnawave обязана стоять за reverse-proxy. Разбираю, чем выбор веб-сервера для панели отличается от выбора для selfsteal-ноды, и почему сам всё равно ставлю Nginx - но уже по другим причинам.

Бесплатный материал · можно читать без регистрации

Содержание (7)

Оглавление

Про какую именно роль эта статья

Когда устанавливаешь панель Remnawave (backend и frontend - одно NestJS-приложение на порту 3000), она по документации обязана стоять за reverse-proxy на 127.0.0.1, на корневом пути домена - голой наружу она не выставляется никогда. Тут тоже встаёт вопрос Nginx или Caddy, но это другая роль, чем на selfsteal-ноде.

Панель не участвует в Reality-хендшейке, PROXY protocol ей не нужен, а порт 443 на этом сервере никем больше не занят - Xray на машине с панелью обычно не крутится вообще, панель в проде стоит отдельно от нод. Поэтому часть моих аргументов из статьи про selfsteal-ноды тут просто не применима, и я это сразу проговариваю, а не переиспользую старые доводы под новый повод.

Что вообще нужно от веб-сервера перед панелью

Reverse-proxy на localhost:3000 (APP_PORT) - это база. Дальше по вкусу: TLS-сертификат на домен из FRONT_END_DOMAIN, часто отдельный проброс на METRICS_PORT (3001) с базовой авторизацией для Prometheus, и нередко ещё один сервис - subscription-page (свой контейнер, порт 3010 по умолчанию), который в итоге тоже хочется повесить на тот же домен, на отдельном поддомене или пути.

Caddy для панели: здесь ему проще

На selfsteal-ноде у Caddy есть конкретные, задокументированные ловушки: пустой блок servers без адреса, ломающий ACME на порту 80; обязательный порядок proxy_protocol перед tls в listener_wrappers; необходимость явно отключать TLS-ALPN-01, потому что порт 443 занят Xray. Ни одной из этих проблем в роли фронта для панели нет - 443 свободен, PROXY protocol не нужен, ACME-challenge ничему не мешает. Здесь Caddyfile в три строки работает так же гладко, как про него рассказывают.

Код

panel.example.com {
    reverse_proxy 127.0.0.1:3000
}

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

Nginx для панели

У Nginx ручной настройки формально больше, но плагин certbot --nginx умеет сам дописать нужные блоки в конфиг - разрыв в удобстве с Caddy не такой большой, как кажется на первый взгляд.

Код

server {
    listen 443 ssl;
    server_name panel.example.com;

    ssl_certificate     /etc/letsencrypt/live/panel.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/panel.example.com/privkey.pem;

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

Код

certbot --nginx -d panel.example.com

Почему я лично всё равно ставлю Nginx и на панель тоже

Если на нодах уже стоит Nginx в роли selfsteal (см. отдельную статью про эту связку), держать тот же инструмент и на сервере с панелью означает один синтаксис конфигов и один набор привычек на весь парк серверов - особенно когда нод больше одной.

Метрики панели (/metrics на METRICS_PORT) обычно вешаются на тот же домен отдельным location с базовой авторизацией для Prometheus - в Nginx это одна директива auth_basic плюс auth_basic_user_file, паттерн, знакомый любому, кто хоть раз закрывал служебный эндпоинт паролем.

По мере роста часто добавляется subscription-page - отдельный сервис на своём порту, который в итоге тоже нужно завести на тот же домен, на своём пути или поддомене. Модель Nginx с несколькими location-блоками на разные upstream'ы под одним хостом обкатана десятилетиями именно под такой сценарий постепенного роста числа сервисов на одном домене.

И отдельно - rate limiting на публичном эндпоинте логина. limit_req_zone и limit_req - часть ядра Nginx, работают из коробки без дополнительной сборки. У Caddy аналогичного ограничения скорости в основной сборке нет: есть сторонний модуль caddy-ratelimit, но для него нужно собирать собственный бинарник через xcaddy, а не поставить готовый пакет. Для публичной админки с логином, которую в теории может брутфорсить кто угодно, разница ощутимая.

Когда я бы сам без колебаний взял Caddy

Если сервер с панелью ровно один, ни одна нода не работает на Nginx и не хочется вообще трогать certbot руками - Caddy для панели не требует ни единого компромисса, только плюсы. Здесь, в отличие от selfsteal-ноды, я бы никого не переубеждал.

Итог

На selfsteal-ноде мой выбор Nginx продиктован конкретными граблями Caddy именно в этой роли. На панели таких граблей нет вообще: Caddy здесь работает ровно так же гладко, как о нём рассказывают. Я всё равно ставлю Nginx и туда - но уже по другой причине, единообразие инфраструктуры и rate limiting на логине из коробки, а не потому что у Caddy тут что-то не так. Если решаешь для панели отдельно от нод - Caddy для панели вполне можно брать без колебаний.

← Все материалы