mirror of
https://github.com/MHSanaei/3x-ui.git
synced 2026-10-26 07:44:59 +03:00
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
6.4 KiB
Plaintext
104 lines
6.4 KiB
Plaintext
---
|
|
title: ورودیها و پروتکلها
|
|
description: ساخت ورودیها در 3x-ui — پروتکلها، انتقالها، بازنشانی و انقضای ترافیک، و fallbackهایی که چند پروتکل را روی یک پورت سرویس میدهند.
|
|
icon: ArrowDownToLine
|
|
---
|
|
|
|
یک **ورودی (inbound)** شنوندهای است که اتصالهای کلاینت را روی یک پورت با
|
|
پروتکل و انتقال مشخصی میپذیرد. بیشتر کارهای روزمره شما ساخت و مدیریت ورودیها و
|
|
کلاینتهای درون آنهاست.
|
|
|
|
## ساخت یک ورودی
|
|
|
|
<Steps>
|
|
|
|
<Step>
|
|
### افزودن یک ورودی
|
|
|
|
به **Inbounds → Add** بروید، یک توضیح (remark) برای آن بگذارید، یک **پروتکل**
|
|
انتخاب کنید، و یک **پورت** و آدرس شنود انتخاب کنید.
|
|
</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`، روزی از ۱ تا ۳۱ انتخاب کنید. اگر آن روز در ماهی کوتاهتر
|
|
وجود نداشته باشد، بازنشانی در آخرین روز همان ماه انجام میشود.
|
|
</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** | پراکسی MTProto تلگرام که توسط یک فرایند همراه `mtg` سرویس میشود (نه Xray). |
|
|
| **TUIC** | پروتکل پراکسی مبتنی بر QUIC نسخه ۵ که به صورت سرور بومی Go درون فرایند ارائه میشود. مشاهده [TUIC](/docs/config/tuic). |
|
|
| **MASQUE** | تونل CONNECT-IP روی HTTP/3 یا HTTP/2، همیشه پشت TLS؛ از طریق اشتراک JSON به کلاینتها تحویل داده میشود. مشاهده [MASQUE](/docs/config/masque). |
|
|
|
|
<Callout type="info">
|
|
Hysteria2 در سطح داخلی یک پروتکل جداگانه نیست — همان پروتکل `hysteria` است که
|
|
نسخه انتقال آن روی ۲ تنظیم شده، و پنل برای آن لینکهای اشتراک `hysteria2://`
|
|
تولید میکند.
|
|
</Callout>
|
|
|
|
## Fallbackها — چند پروتکل روی یک پورت
|
|
|
|
Fallbackها به یک پورت TLS واحد (مثلاً `443`) اجازه میدهند بیش از یک پروتکل را
|
|
سرویس دهد — برای مثال VLESS **و** Trojan — با هدایت دستدادنهای (handshake)
|
|
ناهماهنگ به یک ورودی فرزند. در 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>
|