mirror of
https://github.com/MHSanaei/3x-ui.git
synced 2026-09-16 03:12:10 +03:00
Fold the standalone 3x-ui-docs project (Next.js 16 + Fumadocs, deployed to docs.sanaei.dev) into docs/ so the panel and its documentation share a single source of truth, the way sing-box keeps its docs in-tree. The old repo becomes redundant and can be retired. - Import the full site under docs/ (app, components, content, lib, public, scripts, config). The self-contained pnpm project sits alongside the existing engineering notes with no filename collisions. - Re-point "Edit on GitHub" links from MHSanaei/3x-ui-docs to this repo's docs/content/docs path (docs/lib/shared.ts, docs/app/.../page.tsx). - Add docs-ci.yml and docs-deploy.yml under .github/workflows/, scoped to docs/** and run with working-directory: docs, since GitHub only runs workflows from the repo-root .github/. deploy-static.yml's GitHub Pages publish (CNAME docs.sanaei.dev) carries over unchanged. Follow-up (outside this commit): attach the docs.sanaei.dev custom domain to this repository's Pages (or set the Vercel project's root directory to docs), confirm the site is live from the monorepo, then delete MHSanaei/3x-ui-docs.
103 lines
6.7 KiB
Plaintext
103 lines
6.7 KiB
Plaintext
---
|
||
title: Несколько узлов и управляемые хосты
|
||
description: Управляйте несколькими панелями 3x-ui из одной главной панели — с доверием на основе API-токена или mTLS, heartbeat-сигналами и переопределением хостов для отдельных inbound-соединений в подписках.
|
||
icon: Boxes
|
||
---
|
||
|
||
3x-ui может управлять **несколькими серверами** из одной главной панели и
|
||
переопределять то, как каждое inbound-соединение объявляется в подписках, с
|
||
помощью **управляемых хостов**.
|
||
|
||
## Узлы
|
||
|
||
**Узел** — это другая панель 3x-ui, которой ваша главная панель управляет через
|
||
API этого узла. Главная панель опрашивает каждый узел и в одном месте показывает
|
||
его статус, версии, загрузку CPU/памяти, время работы и трафик.
|
||
|
||
### Добавление узла
|
||
|
||
Укажите данные подключения к узлу:
|
||
|
||
| Поле | Примечания |
|
||
| ----------------- | --------------------------------------------------------------------- |
|
||
| **Имя** | Уникальная метка (например, `de-fra-1`). |
|
||
| **Схема** | `https` (по умолчанию) или `http`. |
|
||
| **Адрес / Порт** | Хост и порт панели узла. |
|
||
| **Базовый путь** | Веб-базовый путь узла. |
|
||
| **API-токен** | Bearer-токен, созданный на узле (не нужен в режиме mTLS). |
|
||
| **Проверка TLS** | `verify` (по умолчанию), `skip`, `pin` (закрепить SHA-256 сертификата) или `mtls`. |
|
||
| **Синхронизация inbound** | `all` (все) inbound-соединения или `selected` (выбранные) по тегу. |
|
||
| **Тег исходящего**| При необходимости обращаться к узлу **через** именованное исходящее соединение (мост исходящего трафика). |
|
||
|
||
Главная панель проверяет доступность при добавлении или тестировании узла. Затем
|
||
она каждые несколько секунд отправляет **heartbeat**, обновляя статус узла
|
||
(`online` / `offline`) и генерируя события `node.up` / `node.down` (см.
|
||
[Telegram-бот](/docs/operations/telegram-bot)).
|
||
|
||
<Callout type="info">
|
||
Узлы идентифицируются по стабильному GUID, уникальному для каждой панели,
|
||
поэтому узел сохраняет свою идентичность между перезапусками. Узел сам может
|
||
управлять другими узлами — главная панель отображает их как доступные только
|
||
для чтения **транзитивные** подузлы (Узел 1 → Узел 2 → Узел 3).
|
||
</Callout>
|
||
|
||
### Взаимный TLS (mTLS) между главной панелью и узлом
|
||
|
||
Для максимально надёжного доверия используйте `tlsVerifyMode = mtls` (требуется
|
||
`https`):
|
||
|
||
<Steps>
|
||
|
||
<Step>
|
||
### Получите CA главной панели
|
||
|
||
На главной панели получите её CA-сертификат для аутентификации узлов (приватный
|
||
ключ CA никогда не покидает панель).
|
||
</Step>
|
||
|
||
<Step>
|
||
### Доверьте ему на узле
|
||
|
||
Вставьте этот CA в настройку «доверенный CA» на узле. Изменения вступят в силу
|
||
при следующем перезапуске узла.
|
||
</Step>
|
||
|
||
<Step>
|
||
### Переключите узел на mTLS
|
||
|
||
Задайте на узле режим проверки TLS `mtls`. Теперь главная панель предъявляет
|
||
клиентский сертификат вместо API-токена.
|
||
</Step>
|
||
|
||
</Steps>
|
||
|
||
## Управляемые хосты
|
||
|
||
**Управляемый хост** — это переопределяющая конечная точка, привязанная к
|
||
inbound-соединению. Во время формирования подписки каждый включённый хост
|
||
добавляет дополнительную ссылку-share / прокси со своим адресом, портом, TLS,
|
||
SNI, заголовком host, путём и другими параметрами — заменяя устаревший список
|
||
«внешних прокси». Используйте их, чтобы:
|
||
|
||
- проксировать inbound через **CDN** (Cloudflare) с другим адресом/SNI,
|
||
- объявлять для одного inbound **несколько доменов** или конечные точки для
|
||
разных регионов,
|
||
- настраивать ALPN, fingerprint, ECH или mux для каждой конечной точки.
|
||
|
||
У каждого хоста есть примечание (которое поддерживает те же
|
||
[шаблонные переменные](/docs/config/share-links#remark-template-variables)),
|
||
переключатель включения, порядок сортировки, и он может быть **исключён из
|
||
определённых форматов подписки** или **ограничен конкретными узлами**.
|
||
|
||
<Callout type="info">
|
||
Хосты, чей адрес/порт указывают на CDN, позволяют держать реальный адрес
|
||
сервера в секрете, пока клиенты подключаются через граничные узлы CDN.
|
||
</Callout>
|
||
|
||
## Связанное
|
||
|
||
<Cards>
|
||
<Card title="Исходящие соединения и маршрутизация" href="/docs/operations/outbounds-routing" description="WARP, NordVPN, подписки на исходящие соединения и маршрутизация." />
|
||
<Card title="Подписка" href="/docs/config/subscription" description="Как хосты формируют вывод подписки." />
|
||
</Cards>
|