Files
3x-ui/docs/content/docs/fa/config/inbounds.mdx
T
Egor 2d7c8c77f7 docs: add TUIC v5 to READMEs, guides, and protocol references (#6511)
* 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>
2026-09-14 11:36:59 +02:00

103 lines
6.1 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 نسخه ۵ که توسط فرایند `tuic-server` ارائه می‌شود. مشاهده [TUIC](/docs/config/tuic). |
<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>