mirror of
https://github.com/MHSanaei/3x-ui.git
synced 2026-10-02 12:12:08 +03:00
Egor
2d7c8c77f7
* docs: add TUIC v5 to READMEs, guides, and protocol references * docs: address review feedback on TUIC architecture, external links, and i18n parity * docs(tuic): drop the Xray-routing claim and qualify Limit IP for TUIC The README feature bullet in all seven locales credited the TUIC sidecar with "seamless Xray routing". A TUIC inbound never enters the Xray config (internal/web/service/xray.go skips model.TUIC) and the generated tuic-server config carries no forwarding target, so decrypted TUIC traffic egresses from the sidecar directly and Xray routing rules never see it; docs/architecture.md in this same branch already says so. An operator reading the bullet would expect geo blocking and outbound selection to cover TUIC clients. The client field table marks Total (GB) as inbound-level for TUIC but left Limit IP at "all". The IP-limit job's only data source is Xray's online-stats API (internal/web/job/check_client_ip_job.go), which TUIC clients never reach, so a Limit IP set on a TUIC client is silently unenforced. Qualify that row the same way in en, fa, ru and zh. --------- Co-authored-by: Sanaei <ho3ein.sanaei@gmail.com>
106 lines
6.9 KiB
Plaintext
106 lines
6.9 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), обслуживаемый встроенным процессом `tuic-server`. См. [TUIC](/docs/config/tuic). |
|
|
|
|
<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>
|