Client and access scope

Цель документа

Зафиксировать, что клиентский delivery/access layer не является частью install baseline.

Что входит в baseline

В baseline этого пакета docs входит только следующее:

установка Hysteria2
установка HY2XS admin
базовая настройка systemd / firewall / hy2xs.env / post-install.env
подготовка рабочего серверного окружения

Что не входит в baseline

В baseline не входят:

Telegram-бот
backend выдачи профилей
remote profile publishing
deep links
billing / подписки / тарифные планы
отдельный user-access API

Что допускается как вспомогательный слой

Для smoke/manual testing могут существовать:

тестовый клиентский конфиг
тестовый URI
отдельные примеры импортируемых клиентских артефактов

Но это не делает access layer частью install baseline.

Публичный endpoint

В клиентской части используется только public_host/public_port.

В runtime-обозначениях HY2XS это эквивалентно:

HY2XS_PUBLIC_HOST
HY2XS_PUBLIC_PORT

Инварианты:

listen и public endpoint разделены;
в клиентских URL не используется 0.0.0.0;
проект остаётся IPv4-only.
если у домена есть AAAA, HY2XS его не обслуживает (IPv6 out of scope).

Почему это важно

Если смешать install baseline и delivery layer, документация начинает неверно обещать лишнее:

будто оркестратор обязан выдавать ключи пользователям
будто сервер после установки автоматически включает пользовательский backend
будто Telegram-бот является обязательной частью системы

Это неверно.

Правильная формулировка

После выполнения install flow система должна быть готова как серверное окружение HY2XS.
Как именно оператор потом выдаёт доступ клиентам — отдельный продуктовый контур и отдельная документация.

2.7 KiB Raw Blame History Unescape Escape