3x-ui для администратора: защита панели и резервные копии

3x-ui — веб-панель для управления Xray-core: она хранит конфигурацию, создаёт входящие подключения, ведёт учёт трафика и показывает состояние сервиса. Удобный интерфейс одновременно становится новой критической точкой: если панель открыта всему интернету, слабый пароль или устаревшая версия способны скомпрометировать весь сервер.

Правовой и этический дисклеймер. Материал посвящён администрированию собственной серверной инфраструктуры, защите панели и резервному копированию. Он не рекламирует услуги доступа, не содержит способов обхода ограничений и не призывает нарушать законодательство или правила сетей. Перед эксплуатацией самостоятельно проверьте применимые требования. Сам проект 3x-ui указывает, что предназначен для личного использования и не должен применяться незаконно или как production-система.

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

Что именно делает 3x-ui

3x-ui не заменяет Xray-core. Панель управляет его конфигурацией и жизненным циклом, а Xray обрабатывает сетевые соединения. Рядом обычно находятся системный сервис или контейнер, база SQLite либо PostgreSQL, каталог сертификатов и резервные копии.

Упрощённая схема выглядит так:

Администратор → HTTPS / закрытый контур → 3x-ui → конфигурация Xray-core
                                      ├→ база данных
                                      ├→ журналы
                                      └→ резервные копии

Это разделение важно для диагностики. Если веб-интерфейс открывается, но сетевой сервис не запускается, проблема может быть в сгенерированной конфигурации Xray. Если Xray работает, а вход в панель невозможен, нужно проверять веб-сервис, reverse proxy и базу, не меняя сразу сетевые правила.

Актуальные возможности и ограничения перечислены в официальном репозитории 3x-ui. Не используйте случайные форки и установочные скрипты из роликов или архивов.

Главный принцип: панель не должна быть публичной по умолчанию

Административный интерфейс содержит сведения о пользователях, портах, объёмах трафика и конфигурации сервера. Его публикация на случайном высоком порту не является защитой: сканеры находят такие сервисы автоматически.

Предпочтительные варианты доступа:

1. только с localhost через SSH-туннель;
2. только из собственной административной сети;
3. через reverse proxy с HTTPS и дополнительным ограничением по адресам;
4. через отдельный защищённый контур управления.

Открывать панель на всех интерфейсах стоит только при осознанной необходимости и с несколькими уровнями защиты. Смена URL-пути уменьшает шум в журнале, но не заменяет firewall, TLS и сильную аутентификацию.

Отдельные порты для разных задач

Не смешивайте административный интерфейс и рабочие входящие подключения на одном случайном наборе правил. Составьте простую таблицу:

После каждого изменения проверяйте, какие процессы действительно слушают сеть. Лишний открытый порт часто остаётся от теста, старого контейнера или временного reverse proxy.

Безопасная первичная настройка

Официальный установщик создаёт случайные данные входа и путь панели. Сохраните их в менеджере паролей и сразу проверьте несколько пунктов:

• уникальный длинный пароль администратора;
• отдельное имя пользователя без очевидных вариантов admin и root;
• HTTPS с действующим сертификатом;
• закрытый прямой порт панели;
• корректное системное время;
• включённые автоматические обновления безопасности ОС;
• резервная копия до создания первых рабочих объектов.

Не вставляйте пароль, токен API или приватный ключ в команды, которые попадут в историю shell. Для автоматизации используйте защищённые переменные окружения или хранилище секретов с минимальными правами.

Reverse proxy и TLS

Reverse proxy удобно завершает TLS, добавляет журнал запросов и позволяет ограничить административный интерфейс. Но он не делает небезопасный backend безопасным автоматически.

Проверьте четыре условия:

1. backend панели слушает localhost или отдельный внутренний интерфейс;
2. наружу опубликован только HTTPS reverse proxy;
3. заголовки реального адреса клиента принимаются только от доверенного proxy;
4. HTTP либо перенаправляется на HTTPS, либо полностью закрыт.

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

Firewall без самообмана

Начинайте с политики «запрещено всё, кроме необходимого». До применения правил убедитесь, что не потеряете SSH-доступ, и держите открытой резервную консоль провайдера или гипервизора.

Типичные ошибки:

• открыт весь диапазон портов вместо одного сервиса;
• разрешён IPv4, но забыт такой же контроль IPv6;
• Docker публикует порт в обход ожидаемой цепочки firewall;
• старое правило остаётся после смены порта;
• мониторинг доступен без пароля;
• тестовый интерфейс слушает 0.0.0.0.

Проверяйте результат с другой машины, а не только командой на самом сервере. Локальный тест не показывает, что реально доступно извне.

Обновления: стабильная версия вместо dev-latest

У 3x-ui есть стабильные релизы и непрерывная development-сборка. Для обычного сервера выбирайте стабильный тег, читайте примечания к выпуску и не обновляйте панель непосредственно перед поездкой или важным событием.

Рабочий порядок:

1. сохранить базу, конфигурацию и сертификаты;
2. записать текущую версию панели и Xray-core;
3. проверить свободное место и состояние диска;
4. обновить в запланированное окно;
5. проверить вход в панель, запуск Xray и журналы;
6. сохранить новую контрольную копию после успешной проверки.

Официальные релизы публикуются на странице 3x-ui Releases. Rolling dev build предназначен для проверки свежих изменений, а не для сервера, от которого требуется предсказуемость.

Что включать в резервную копию

Скриншоты интерфейса не являются резервной копией. Нужны данные, из которых можно восстановить работающий экземпляр:

• база 3x-ui;
• конфигурация и параметры запуска;
• сертификаты и ключи, если они не выпускаются заново;
• конфигурация reverse proxy;
• правила firewall в документированном виде;
• версия панели и образа контейнера;
• отдельная инструкция восстановления.

Храните минимум одну копию вне сервера. Архив на том же диске исчезнет вместе с виртуальной машиной. Шифруйте резервные копии, потому что в них могут находиться секреты и идентификаторы клиентов.

Главная проверка — пробное восстановление на изолированной машине. Непроверенный архив даёт уверенность, но не гарантирует результат.

SQLite или PostgreSQL

SQLite проще и подходит для небольшого личного экземпляра: меньше компонентов, понятное копирование, лёгкое восстановление. Но файл базы нельзя бездумно копировать во время активной записи — используйте штатный экспорт или согласованный снимок.

PostgreSQL оправдан, когда требуется отдельный сервер БД, регулярные транзакционные копии или более крупная инсталляция. Он добавляет обслуживание: обновления, роли, сеть, мониторинг, резервное копирование и проверку восстановления.

Не переходите на PostgreSQL только потому, что он выглядит «профессиональнее». Выбирайте хранилище по реальной нагрузке и способности обслуживать ещё один критический компонент.

Журналы и минимальный мониторинг

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

• работает ли сервис панели;
• запущен ли Xray-core;
• не растёт ли число ошибок конфигурации;
• хватает ли места на диске;
• были ли неудачные входы;
• не изменились ли неожидаемо открытые порты;
• создана ли свежая резервная копия.

Настройте ротацию журналов. Бесконечный debug-лог способен заполнить диск и остановить сервис. Не отправляйте полные конфигурации и секреты во внешнюю систему мониторинга.

Для общего понимания Xray и сетевых туннелей без привязки к конкретной панели можно прочитать материал VLESS как туннель между своими проектами.

3x-ui и Remnawave — разные модели управления

3x-ui удобен как компактная панель для одного или нескольких управляемых серверов. Remnawave строится вокруг отдельной панели, базы и нод, поэтому сильнее разделяет управляющий и рабочий контуры. Сравнивать их только по количеству кнопок неправильно.

Если важны централизованные ноды, отдельные компоненты и более сложная эксплуатационная модель, читайте разбор архитектуры Remnawave. Для небольшого личного стенда лишняя распределённость может лишь увеличить число точек отказа.

Чек-лист администратора

Перед тем как считать установку законченной, проверьте:

• панель недоступна напрямую из произвольной сети;
• используется HTTPS без предупреждений браузера;
• пароль уникален и сохранён безопасно;
• API выключен либо защищён отдельным ограниченным токеном;
• SSH работает по ключам;
• IPv4 и IPv6 проверены одинаково;
• выбран стабильный релиз;
• резервная копия хранится вне сервера;
• восстановление хотя бы один раз протестировано;
• журнал не содержит секретов и регулярно ротируется.

Итог

3x-ui следует воспринимать не как «кнопку для настройки сети», а как административную систему с доступом к критической конфигурации Xray-core. Главные меры защиты скучны и поэтому эффективны: закрытый интерфейс, HTTPS, минимальные порты, стабильные обновления, ограниченные токены и проверенные резервные копии.

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