mirror of
https://github.com/MHSanaei/3x-ui.git
synced 2026-10-23 22:35:03 +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.
104 lines
4.2 KiB
Plaintext
104 lines
4.2 KiB
Plaintext
---
|
|
title: Inbounds & Protocols
|
|
description: Create inbounds in 3x-ui — protocols, transports, traffic reset and expiry, and fallbacks that serve multiple protocols on one port.
|
|
icon: ArrowDownToLine
|
|
---
|
|
|
|
An **inbound** is a listener that accepts client connections on a port using a
|
|
particular protocol and transport. Most of your day-to-day work is creating and
|
|
managing inbounds and the clients inside them.
|
|
|
|
## Create an inbound
|
|
|
|
<Steps>
|
|
|
|
<Step>
|
|
### Add an inbound
|
|
|
|
Open **Inbounds → Add**, give it a remark, pick a **protocol**, and choose a
|
|
**port** and listen address.
|
|
</Step>
|
|
|
|
<Step>
|
|
### Choose a transport and security
|
|
|
|
Pick the transport (TCP, WebSocket, gRPC, HTTPUpgrade, XHTTP, …) and the security
|
|
layer (none, TLS, or REALITY). See [Transports](/docs/config/transports) and
|
|
[REALITY](/docs/config/reality).
|
|
</Step>
|
|
|
|
<Step>
|
|
### Add clients
|
|
|
|
Add one or more clients, each with its own credential, limits, and share link.
|
|
See [Clients](/docs/config/clients).
|
|
</Step>
|
|
|
|
<Step>
|
|
### Set traffic limit, expiry, and reset
|
|
|
|
Optionally cap total traffic and set an expiry date for the inbound, and choose a
|
|
periodic **traffic reset** schedule: `never` (default), `hourly`, `daily`,
|
|
`weekly`, or `monthly`.
|
|
|
|
For `monthly` resets, select a day from 1 to 31. If the selected day does not
|
|
exist in a shorter month, the reset runs on that month's last day.
|
|
</Step>
|
|
|
|
</Steps>
|
|
|
|
## Supported protocols
|
|
|
|
The inbound editor accepts these protocols:
|
|
|
|
| Protocol | Notes |
|
|
| ---------------------- | ------------------------------------------------------------------------ |
|
|
| **VLESS** | Lightweight; the basis for REALITY + XTLS-Vision. Recommended. |
|
|
| **VMess** | Older but very widely supported by clients. |
|
|
| **Trojan** | TLS-based; supports XTLS and fallbacks. |
|
|
| **Shadowsocks** | Includes Shadowsocks-2022 (`2022-blake3-*`) ciphers. |
|
|
| **WireGuard** | Modern tunnel. |
|
|
| **AmneziaWG** | Obfuscated WireGuard fork, embedded in the panel process. See [AmneziaWG](/docs/config/amneziawg). |
|
|
| **Hysteria2** | Selected as `hysteria`; the panel emits `hysteria2://` links. |
|
|
| **HTTP** | HTTP proxy. |
|
|
| **Mixed (SOCKS/HTTP)** | A combined SOCKS + HTTP listener. |
|
|
| **Dokodemo-door / Tunnel** | Port forwarding / traffic redirect. |
|
|
| **MTProto** | Telegram MTProto proxy, served by a bundled `mtg` process (not Xray). |
|
|
| **TUIC** | QUIC-based proxy protocol (v5), served by an in-process native Go server. See [TUIC](/docs/config/tuic). |
|
|
| **MASQUE** | CONNECT-IP tunnel over HTTP/3 or HTTP/2, always behind TLS; delivered to clients through the JSON subscription. See [MASQUE](/docs/config/masque). |
|
|
|
|
<Callout type="info">
|
|
Hysteria2 isn't a separate protocol internally — it's the `hysteria` protocol
|
|
with the transport version set to 2, and the panel generates `hysteria2://`
|
|
share links for it.
|
|
</Callout>
|
|
|
|
## Fallbacks — multiple protocols on one port
|
|
|
|
Fallbacks let a single TLS port (e.g. `443`) serve more than one protocol — for
|
|
example VLESS **and** Trojan — by routing unmatched handshakes to a child
|
|
inbound. In 3x-ui, fallbacks are managed in the panel (a master inbound's
|
|
**Fallbacks** list) rather than hand-written into JSON.
|
|
|
|
Fallbacks are available only when the master inbound is:
|
|
|
|
- **VLESS** or **Trojan**,
|
|
- on the raw **TCP** transport,
|
|
- with **TLS** or **REALITY** security.
|
|
|
|
Each fallback rule targets a child inbound and can match on `path`, `alpn`, and
|
|
`dest`. Client share links for a fallback child are automatically rewritten to
|
|
advertise the master's address, port, and TLS.
|
|
|
|
## Not sure which to pick?
|
|
|
|
Use the wizard to get a recommendation based on your goals and clients:
|
|
|
|
<ProtocolWizard />
|
|
|
|
<Callout type="info">
|
|
For censorship resistance with modern clients, **VLESS + REALITY +
|
|
XTLS-Vision** is the usual best choice — continue to
|
|
[REALITY](/docs/config/reality).
|
|
</Callout>
|