Привет!
Продолжение issue #122 про listen-адрес и версию ядра — реализация этого мастера опирается на те поля.
Ваш проект последовательно идёт по линии автоматизации (автонастройка, cron-инструмент из ноды, MCP для AI), и reverse proxy-мастер — её естественное продолжение, поэтому и предлагаю это именно как автонастройку, а не набор мануалов.
Видится так: при автонойстройке панель спрашивает, собирается ли пользователь поднять более одного инбаунда на xray tls-ноду. Если да — предлагает решение с reverse proxy с кратким описанием, зачем это вообще нужно. Пользователь соглашается и запускает автонастройку.
Дальше по шагам:
- Панель просит перевести основной инбаунд с 0.0.0.0:443 на 127.0.0.1:443 (дополнительные — на соседние локальные порты) и указать path (с проверкой: если listen ip, listen port и path не указаны/неверные — напомнить указать/исправить и продолжить после);
- Выбор источника TLS: выпуск LE на ноде, сертификат панели или свои PEM (путями к файлам + подсказка по командам прав) — по аналогии с tlsSource у xray-нод;
- Выбор ALPN, которые терминируют фронт (строкой, например «h2, http/1.1»): набор ALPN определяет, каким клиентам и пробам фронт вообще ответит — без пересечения handshake рвётся ещё до HTTP. По умолчанию — как у обычного сайта (h2 + http/1.1). Если UDP/443 на ноде занят (например, hysteria на той же машине) — HTTP/3 не объявлять, чтобы фронт не рекламировал то, что не может обслужить;
- Подгрузка .html заглушки или указание директории/директорий с собственными .html/.css/robots.txt и т.д. — фронт должен отвечать как настоящий действующий сайт, а не как фронт прокси-ноды, на любой случайный заход и активные пробы.
При автонастройке на ноду ставится caddy/nginx (на ваш выбор), собирается конфиг из указанных параметров, всё пушится на ноду — и дальше smoke-тест прямо от панели: curl с проверкой соответствия ответа и кода заглушки, залитой на ноде, плюс проверка подключения к прокси-инбаунду тестовым пользователем панели. Если проходят — результат пуша считается положительным.
И крупный дисклеймер при выборе схемы: техника продвинутая, настраивать осознанно, а не «выбрал и жду, что заработает».
Future: с развитием ТСПУ-инфраструктуры и подключением AI к анализу паттернов трафика и активным пробам по найденным серверам реалистичная заглушка и точный контроль ответов фронта станут не изысками, а базовой гигиеной — поэтому думаю об этом именно как о следующем шаге автонастройки.
Большой респект за Вашу работу!!! Celerity-panel среди 4-5 других панелей выбираю сердцем))
Привет!
Продолжение issue #122 про listen-адрес и версию ядра — реализация этого мастера опирается на те поля.
Ваш проект последовательно идёт по линии автоматизации (автонастройка, cron-инструмент из ноды, MCP для AI), и reverse proxy-мастер — её естественное продолжение, поэтому и предлагаю это именно как автонастройку, а не набор мануалов.
Видится так: при автонойстройке панель спрашивает, собирается ли пользователь поднять более одного инбаунда на xray tls-ноду. Если да — предлагает решение с reverse proxy с кратким описанием, зачем это вообще нужно. Пользователь соглашается и запускает автонастройку.
Дальше по шагам:
При автонастройке на ноду ставится caddy/nginx (на ваш выбор), собирается конфиг из указанных параметров, всё пушится на ноду — и дальше smoke-тест прямо от панели: curl с проверкой соответствия ответа и кода заглушки, залитой на ноде, плюс проверка подключения к прокси-инбаунду тестовым пользователем панели. Если проходят — результат пуша считается положительным.
И крупный дисклеймер при выборе схемы: техника продвинутая, настраивать осознанно, а не «выбрал и жду, что заработает».
Future: с развитием ТСПУ-инфраструктуры и подключением AI к анализу паттернов трафика и активным пробам по найденным серверам реалистичная заглушка и точный контроль ответов фронта станут не изысками, а базовой гигиеной — поэтому думаю об этом именно как о следующем шаге автонастройки.
Большой респект за Вашу работу!!! Celerity-panel среди 4-5 других панелей выбираю сердцем))