mirror of
https://github.com/MHSanaei/3x-ui.git
synced 2026-10-22 22:05:02 +03:00
MHSanaei
b04039c2bd
xray-core v26.10.10 serves MASQUE: CONNECT-IP over HTTP/3 or HTTP/2, always behind TLS, as an inbound and an outbound protocol riding a dedicated "masque" transport. The panel could not create either. Inbound: MASQUE is a multi-user protocol whose users log in with their email and password over Basic auth. The panel keeps the client's "password" like trojan and GenXrayInboundConfig hands it to the core as "pass", so the full-config path, the live AddInbound path and node pushes all emit what the core reads; one user with an empty pass makes the core refuse the whole inbound. Live user adds build a masque.Account from either key, client-only changes diff per user so a new client does not drop every connected tunnel, and client creation, copy, validation and edits key on the password. The address pool and MTU get form fields, TLS is mandatory, and the port check follows the core's listener choice: HTTP/2 on TCP when the ALPN offers h2, HTTP/3 on UDP when it offers h3 or not h2. Nodes may host MASQUE from v3.9.1, the first panel release that knows to rename the password. MASQUE has no share-link format, so links and Clash skip it; the JSON subscription builds the client's masque outbound with its email and password, and the subscription allowlist now lets a subId see MASQUE inbounds at all. The IP-limit job, client pages and traffic tracking list the protocol. Outbound: the form edits the server, remote DNS, and the transport's host, path, Basic credentials, headers and WARP block (enrolled key, endpoint public key, tunnel addresses), which xray-core refuses next to user/pass. The outbound test probes it through the core, since its default HTTP/3 dial is UDP.
107 lines
7.1 KiB
Plaintext
107 lines
7.1 KiB
Plaintext
---
|
|
title: Входящие подключения и протоколы
|
|
description: Создание входящих подключений в 3x-ui — протоколы, транспорты, сброс трафика и срок действия, а также fallback-правила, обслуживающие несколько протоколов на одном порту.
|
|
icon: ArrowDownToLine
|
|
---
|
|
|
|
**Входящее подключение** (inbound) — это слушатель, который принимает клиентские
|
|
соединения на порту, используя определённый протокол и транспорт. Большая часть
|
|
повседневной работы состоит в создании и управлении входящими подключениями и
|
|
клиентами внутри них.
|
|
|
|
## Создание входящего подключения
|
|
|
|
<Steps>
|
|
|
|
<Step>
|
|
### Добавьте входящее подключение
|
|
|
|
Откройте **Inbounds → Add**, задайте примечание, выберите **протокол**, а также
|
|
**порт** и адрес прослушивания.
|
|
</Step>
|
|
|
|
<Step>
|
|
### Выберите транспорт и безопасность
|
|
|
|
Выберите транспорт (TCP, WebSocket, gRPC, HTTPUpgrade, XHTTP, …) и уровень
|
|
безопасности (без шифрования, TLS или REALITY). См. [Транспорты](/docs/config/transports) и
|
|
[REALITY](/docs/config/reality).
|
|
</Step>
|
|
|
|
<Step>
|
|
### Добавьте клиентов
|
|
|
|
Добавьте одного или нескольких клиентов, у каждого со своими учётными данными,
|
|
ограничениями и ссылкой для подключения. См. [Клиенты](/docs/config/clients).
|
|
</Step>
|
|
|
|
<Step>
|
|
### Задайте лимит трафика, срок действия и сброс
|
|
|
|
При необходимости ограничьте общий объём трафика и установите дату истечения для
|
|
входящего подключения, а также выберите расписание периодического **сброса трафика**:
|
|
`never` (по умолчанию), `hourly`, `daily`, `weekly` или `monthly`.
|
|
|
|
Для сброса `monthly` выберите день от 1 до 31. Если выбранного дня нет в более
|
|
коротком месяце, сброс выполняется в последний день этого месяца.
|
|
</Step>
|
|
|
|
</Steps>
|
|
|
|
## Поддерживаемые протоколы
|
|
|
|
Редактор входящих подключений принимает следующие протоколы:
|
|
|
|
| Протокол | Примечания |
|
|
| ---------------------- | ------------------------------------------------------------------------ |
|
|
| **VLESS** | Лёгкий; основа для REALITY + XTLS-Vision. Рекомендуется. |
|
|
| **VMess** | Более старый, но очень широко поддерживается клиентами. |
|
|
| **Trojan** | На основе TLS; поддерживает XTLS и fallback-правила. |
|
|
| **Shadowsocks** | Включает шифры Shadowsocks-2022 (`2022-blake3-*`). |
|
|
| **WireGuard** | Современный туннель. |
|
|
| **AmneziaWG** | Форк WireGuard с обфускацией, встроенный в процесс панели. См. [AmneziaWG](/docs/config/amneziawg). |
|
|
| **Hysteria2** | Выбирается как `hysteria`; панель создаёт ссылки `hysteria2://`. |
|
|
| **HTTP** | HTTP-прокси. |
|
|
| **Mixed (SOCKS/HTTP)** | Совмещённый слушатель SOCKS + HTTP. |
|
|
| **Dokodemo-door / Tunnel** | Перенаправление портов / перенаправление трафика. |
|
|
| **MTProto** | Прокси Telegram MTProto, обслуживаемый встроенным процессом `mtg` (не Xray). |
|
|
| **TUIC** | Протокол проксирования на базе QUIC (v5), обслуживаемый встроенным сервером на Go. См. [TUIC](/docs/config/tuic). |
|
|
| **MASQUE** | Туннель CONNECT-IP поверх HTTP/3 или HTTP/2, всегда за TLS; клиенты получают его через JSON-подписку. См. [MASQUE](/docs/config/masque). |
|
|
|
|
<Callout type="info">
|
|
Hysteria2 внутренне не является отдельным протоколом — это протокол `hysteria`
|
|
с версией транспорта, установленной в 2, и панель генерирует для него ссылки
|
|
`hysteria2://` для подключения.
|
|
</Callout>
|
|
|
|
## Fallback-правила — несколько протоколов на одном порту
|
|
|
|
Fallback-правила позволяют одному TLS-порту (например, `443`) обслуживать более
|
|
одного протокола — например, VLESS **и** Trojan — направляя несовпавшие
|
|
рукопожатия на дочернее входящее подключение. В 3x-ui fallback-правила
|
|
управляются в панели (список **Fallbacks** у главного входящего подключения), а
|
|
не прописываются вручную в JSON.
|
|
|
|
Fallback-правила доступны только тогда, когда главное входящее подключение:
|
|
|
|
- использует **VLESS** или **Trojan**,
|
|
- работает на «сыром» транспорте **TCP**,
|
|
- с безопасностью **TLS** или **REALITY**.
|
|
|
|
Каждое fallback-правило указывает на дочернее входящее подключение и может
|
|
сопоставляться по `path`, `alpn` и `dest`. Клиентские ссылки для дочернего
|
|
fallback-подключения автоматически переписываются так, чтобы указывать адрес,
|
|
порт и TLS главного подключения.
|
|
|
|
## Не уверены, что выбрать?
|
|
|
|
Воспользуйтесь мастером, чтобы получить рекомендацию исходя из ваших целей и клиентов:
|
|
|
|
<ProtocolWizard />
|
|
|
|
<Callout type="info">
|
|
Для устойчивости к цензуре с современными клиентами **VLESS + REALITY +
|
|
XTLS-Vision** обычно является лучшим выбором — перейдите к
|
|
[REALITY](/docs/config/reality).
|
|
</Callout>
|