mirror of
https://github.com/MHSanaei/3x-ui.git
synced 2026-10-14 09:55:01 +03:00
MHSanaei
c5e1e54c75
xray-core opens an XDRIVE stream's storage only when the inbound starts listening, so a Google Drive inbound saved with the form's defaults (no folder, no secrets), a local one without a folder, or a template one whose template xray cannot use stopped xray and every other inbound with it. validateXDriveStorage applies the core's storage rules at save, on inbound add/update and on the xray template's inbounds and outbounds: the service must be local, Google Drive or template; local and Google Drive need a remoteFolder; Google Drive needs its three non-empty secrets; a template must pass newTemplateStorage's checks (put, get, list and delete urls, and a list namesRegex with one capture group). A VLESS client kept its xtls-rprx-vision flow when its inbound moved to a transport that cannot carry it, and GetXrayConfig only honoured DisableFlow, so the server demanded Vision there and refused every client. GetXrayConfig and the outbound form now apply the Vision gate, and that gate now follows the core in the backend, the subscription service and the frontend: TLS/REALITY on raw TCP, or VLESS encryption on any transport (xray runs Vision inside encryption.CommonConn whatever the transport, not only on XHTTP). The outbound modal passes the VLESS encryption into the gate and gates Mux on the effective flow.
233 lines
20 KiB
Plaintext
233 lines
20 KiB
Plaintext
---
|
||
title: انتقال‌ها و امنیت
|
||
description: هر انتقالی که 3x-ui ارائه می‌دهد — TCP، mKCP، WebSocket، gRPC، HTTPUpgrade، XHTTP، Hysteria، XDRIVE، MASQUE — به‌همراه تنظیماتشان، و نیز مبهم‌سازی FinalMask، sockopt، TLS/REALITY، XTLS-Vision و رمزنگاری VLESS.
|
||
icon: Network
|
||
---
|
||
|
||
یک **انتقال** تعیین می‌کند که بسته‌ها چگونه میان کلاینت و سرور حمل شوند، یک
|
||
لایه **امنیتی** تعیین می‌کند که چگونه رمزنگاری و استتار شوند، و **FinalMask**
|
||
می‌تواند آنچه باقی مانده را مبهم کند. پنل تنها ترکیب‌های معتبر را ارائه می‌دهد؛ این
|
||
صفحه تنظیمات هر انتقال و قواعدی را که پنل اعمال می‌کند فهرست می‌کند.
|
||
|
||
## انتقال‌ها
|
||
|
||
انتقال (مقدار `network` مربوط به inbound) را در فرم inbound/outbound انتخاب کنید. هر
|
||
شبکه کلید تنظیمات خود را روی سیم می‌نویسد (`tcpSettings`، `kcpSettings`، …).
|
||
|
||
| انتقال | کلید تنظیمات | چه زمانی از آن استفاده کنید |
|
||
| --------------- | --------------------- | ---------------------------------------------------------------------- |
|
||
| **TCP (Raw)** | `tcpSettings` | کمترین سربار. پایه‌ای برای REALITY + XTLS-Vision و fallbackها؛ استتار اختیاری هدر HTTP/1.1. |
|
||
| **mKCP** | `kcpSettings` | پروتکل قابل‌اعتماد روی **UDP** — پهنای باند را با تأخیر کمتر روی لینک‌های پُرافت معاوضه می‌کند. هیچ TLS/REALITY حمل نمی‌کند. |
|
||
| **WebSocket** | `wsSettings` | از طریق CDNها و پراکسی‌های معکوس HTTP کار می‌کند؛ بسیار سازگار است. |
|
||
| **gRPC** | `grpcSettings` | مبتنی بر HTTP/2؛ مالتی‌پلکس خوبی دارد و به‌خوبی از طریق Nginx پراکسی می‌شود. |
|
||
| **HTTPUpgrade** | `httpupgradeSettings` | `Upgrade` مربوط به HTTP/1.1 و سازگار با CDN؛ سبک‌تر از WebSocket کامل. |
|
||
| **XHTTP** | `xhttpSettings` | انتقال HTTP مدرن با مالتی‌پلکس جریانی؛ سازگار با CDN و توانمند برای REALITY. |
|
||
| **Hysteria** | `hysteriaSettings` | انتقال مبتنی بر QUIC — تنها برای پروتکل **Hysteria2**. |
|
||
| **XDRIVE** | `xdriveSettings` | جریان را از طریق فایل‌ها در یک فضای ذخیره‌سازی ابری مشترک (Google Drive، یک پوشهٔ محلی یا هر API ذخیره‌سازی HTTP) تونل می‌کند. |
|
||
| **MASQUE** | `masqueSettings` | CONNECT-IP روی HTTP/3 یا HTTP/2 — تنها برای پروتکل **MASQUE**. مشاهده [MASQUE](/docs/config/masque). |
|
||
|
||
<Callout type="info">
|
||
inboundهای **WireGuard** و **Tunnel** (dokodemo-door) هیچ انتخابگر انتقالی
|
||
نمایش نمی‌دهند — جریان آن‌ها تنها security/sockopt را حمل می‌کند. پنل‌های قدیمی‌تر
|
||
یک انتقال خام **HTTP/2 (`http`)** نیز نمایش می‌دادند؛ این انتقال جای خود را به
|
||
**XHTTP** داده و دیگر قابل انتخاب نیست.
|
||
</Callout>
|
||
|
||
### TCP (Raw) — `tcpSettings`
|
||
|
||
| فیلد | پیش‌فرض | معنی |
|
||
| ------------------------------ | ------- | ----------------------------------------------------------------------- |
|
||
| `acceptProxyProtocol` | `false` | پذیرش پروتکل PROXY از یک پراکسی بالادست تا IP واقعی کلاینت حفظ شود. |
|
||
| `header.type` | `none` | `none`، یا `http` برای استتار HTTP/1.1. |
|
||
| `header.request` / `response` | — | هنگام `type: http`: متد، مسیر، نسخه و یک نگاشت هدر که یک تبادل HTTP معمولی را تقلید می‌کنند. |
|
||
|
||
### mKCP — `kcpSettings`
|
||
|
||
| فیلد | پیش‌فرض | معنی |
|
||
| ------------------ | ----------- | ---------------------------------------------------------------- |
|
||
| `mtu` | `1350` | بیشینه واحد انتقال، بر حسب بایت (576–1460). |
|
||
| `tti` | `20` | بازه زمانی انتقال، بر حسب میلی‌ثانیه (10–100). کمتر = پاسخگوتر، سربار بیشتر. |
|
||
| `uplinkCapacity` | `5` | بودجه پهنای باند آپلود، بر حسب **MB/s**. |
|
||
| `downlinkCapacity` | `20` | بودجه پهنای باند دانلود، بر حسب **MB/s**. |
|
||
| `cwndMultiplier` | `1` | ضریب پنجره ازدحام؛ برای فشار بیشتر روی لینک‌های خوب آن را بالا ببرید. |
|
||
| `maxSendingWindow` | `2097152` | کران بالای بسته‌های در حال پرواز. |
|
||
|
||
<Callout type="info">
|
||
mKCP نمی‌تواند TLS یا REALITY حمل کند. برای استتار آن، یک ماسک UDP از نوع
|
||
**FinalMask** اضافه کنید — ماسک `mkcp-legacy` همان مبهم‌سازی کلاسیک هدر را
|
||
بازتولید می‌کند که Xray قدیمی‌تر در `kcpSettings.header`/`seed` ذخیره می‌کرد
|
||
(آن فیلدها دیگر اینجا وجود ندارند).
|
||
</Callout>
|
||
|
||
### WebSocket — `wsSettings`
|
||
|
||
| فیلد | پیش‌فرض | معنی |
|
||
| --------------------- | ------- | ---------------------------------------------------------------- |
|
||
| `path` | `/` | مسیر درخواست — وقتی چند سرویس یک میزبان را به اشتراک می‌گذارند، بر اساس آن مسیریابی کنید. |
|
||
| `host` | _(none)_| بازنویسی هدر `Host` (پشت یک CDN مفید است). |
|
||
| `headers` | `{}` | هدرهای درخواست اضافی. |
|
||
| `heartbeatPeriod` | `0` | ثانیه‌های بین پینگ‌های keepalive؛ `0` آن‌ها را غیرفعال می‌کند. |
|
||
| `acceptProxyProtocol` | `false` | پذیرش پروتکل PROXY از یک بالادست. |
|
||
|
||
### gRPC — `grpcSettings`
|
||
|
||
| فیلد | پیش‌فرض | معنی |
|
||
| ------------- | ------- | --------------------------------------------------------- |
|
||
| `serviceName` | _(none)_| مسیر سرویس gRPC؛ مانند یک مسیر مخفی عمل می‌کند. |
|
||
| `authority` | _(none)_| بازنویسی شبه‌هدر `:authority`. |
|
||
| `multiMode` | `false` | مالتی‌پلکس چند جریان روی یک اتصال. |
|
||
|
||
### HTTPUpgrade — `httpupgradeSettings`
|
||
|
||
| فیلد | پیش‌فرض | معنی |
|
||
| --------------------- | ------- | --------------------------------------------- |
|
||
| `path` | `/` | مسیر درخواست. |
|
||
| `host` | _(none)_| بازنویسی هدر `Host`. |
|
||
| `headers` | `{}` | هدرهای درخواست اضافی. |
|
||
| `acceptProxyProtocol` | `false` | پذیرش پروتکل PROXY از یک بالادست. |
|
||
|
||
HTTPUpgrade یک `Upgrade` تک‌مرحله‌ای HTTP/1.1 بدون قاب‌بندی WebSocket است — هیچ
|
||
فیلد heartbeat ندارد.
|
||
|
||
### XHTTP — `xhttpSettings`
|
||
|
||
XHTTP (SplitHTTP) مجموعه فیلد بزرگی دارد؛ پنل پیش‌فرض‌های معقولی را پر می‌کند.
|
||
آن‌هایی که معمولاً سراغشان می‌روید:
|
||
|
||
| فیلد | پیش‌فرض | معنی |
|
||
| ---------------------- | ----------- | ---------------------------------------------------------------------- |
|
||
| `path` | `/` | مسیر درخواست. |
|
||
| `host` | _(none)_ | بازنویسی هدر `Host`. |
|
||
| `mode` | `auto` | `auto`، `packet-up`، `stream-up` یا `stream-one`. `packet-up` بیشترین سازگاری با CDN را دارد؛ `stream-*` تأخیر کمتری دارند. |
|
||
| `xPaddingBytes` | `100-1000` | بازه padding تصادفی که اندازه بسته‌ها را محو می‌کند. |
|
||
| `scMaxBufferedPosts` | `30` | بافر سمت سرور برای POSTهای آپلودشده. |
|
||
| `scStreamUpServerSecs` | `20-80` | پنجره stream-up سمت سرور (بازه با خط تیره). |
|
||
| `xmux` (`enableXmux`) | _(off)_ | مالتی‌پلکس اتصال — `maxConcurrency` `16-32`، `maxConnections` `6`، … برای همزمانی بالا روشن کنید. |
|
||
|
||
فیلدهای Session-ID (`sessionIDPlacement`، `sessionIDKey`، `sessionIDTable`،
|
||
`sessionIDLength`) و کلیدهای `scMin/MaxEachPostBytes` پیشرفته‌اند؛ آن‌ها را خالی
|
||
بگذارید مگر آنکه با یک بالادست مشخص هماهنگ می‌شوید.
|
||
|
||
### Hysteria — `hysteriaSettings`
|
||
|
||
تنها زمانی معتبر است که پروتکل **Hysteria2** باشد.
|
||
|
||
| فیلد | پیش‌فرض | معنی |
|
||
| ---------------- | ------- | ----------------------------------------------------------------------- |
|
||
| `version` | `2` | نسخه پروتکل Hysteria. |
|
||
| `auth` | _(none)_| رشته احراز هویت مشترک. |
|
||
| `udpIdleTimeout` | `60` | ثانیه (2–600) پیش از حذف نشست‌های بی‌کار UDP. |
|
||
| `masquerade` | — | استتار به‌عنوان یک سرور HTTP/3: `type` با مقدار `proxy`/`file`/`string` و `url`/`dir`/`content`، به‌علاوه `headers` و `statusCode`. |
|
||
|
||
### XDRIVE — `xdriveSettings`
|
||
|
||
XDRIVE جریان را به‌صورت فایل‌هایی در پوشه‌ای که هر دو طرف به آن دسترسی دارند حمل می‌کند:
|
||
سرور به‌جای پذیرش اتصال روی پورتش، آن پوشه را بررسی می‌کند. هر دو طرف باید سرویس، پوشه
|
||
و مقادیر محرمانهٔ **یکسان** داشته باشند، بنابراین اشتراک JSON آن‌ها را به همهٔ کلاینت‌ها
|
||
می‌فرستد؛ inboundهای XDRIVE لینک اشتراک‌گذاری یا ورودی Clash ندارند.
|
||
|
||
| فیلد | پیش‌فرض | معنا |
|
||
| -------------- | -------------- | ---- |
|
||
| `service` | `Google Drive` | `Google Drive`، `local` (پوشه‌ای روی دیسک) یا `template` (هر API ذخیره‌سازی HTTP). |
|
||
| `remoteFolder` | — | پوشه‌ای که فایل‌های نشست در آن قرار می‌گیرند. |
|
||
| `secrets` | — | Google Drive: دقیقاً سه مقدار ClientID، ClientSecret و RefreshToken به همین ترتیب. Template: مقادیری که با `{secret0}`، `{secret1}`، … خوانده می‌شوند. |
|
||
| `template` | — | فقط برای سرویس template: عملیات `auth`، `put`، `get`، `list` و `delete` در API ذخیره‌ساز. |
|
||
| تنظیمات دقیق | پیش‌فرض هسته | `segmentBytes` (512 KiB)، `flushIntervalMs` (20)، `pollIntervalMs`/`maxPollIntervalMs` (50/500)، `eagerWindowMs` (2000)، `holeTimeoutMs` (30000)، `sessionTtlSeconds` (300)، `concurrency` (8). |
|
||
|
||
**آدرس/پورت Front** اختیاری (کلیدهای `address`/`port` در سطح stream) یک domain front
|
||
است که API ذخیره‌ساز از طریق آن وصل می‌شود؛ نام TLS همچنان میزبان API است. XDRIVE لایهٔ
|
||
TLS/REALITY جداگانه‌ای ندارد — ترافیکش همان HTTPS خود API ذخیره‌ساز است. در اوت‌باند،
|
||
امنیت **TLS** همین اتصال HTTPS را شکل می‌دهد: API ذخیره‌ساز همان SNI، اثرانگشت uTLS و
|
||
ALPN آن را می‌بیند.
|
||
|
||
## FinalMask — مبهم‌سازی لایه پایانی
|
||
|
||
**FinalMask** ترافیک را **پس از** لایه‌های انتقال و امنیت می‌پیچد، بنابراین می‌تواند
|
||
انتقال‌هایی را که TLS حمل نمی‌کنند (مانند mKCP) استتار کند یا پوسته‌ای دوم روی TLS
|
||
بیفزاید. ماسک‌ها برای هر جهت پیکربندی می‌شوند:
|
||
|
||
- **ماسک‌های TCP** — `fragment`، `sudoku`، `header-custom`، `xmc` (ترافیک را به شکل
|
||
پروتکل Minecraft استتار می‌کند؛ گذرواژه الزامی است و نام میزبان و نام‌های بازیکن
|
||
اختیاری‌اند).
|
||
- **ماسک‌های UDP** — `salamander`، `mkcp-legacy`، `header-custom`، `xdns`، `xicmp`،
|
||
`noise`، `sudoku`، `realm` و `udphop` که فقط سمت کلاینت است. (`mkcp-legacy`
|
||
همان مبهم‌سازی قدیمی هدر mKCP را بازتولید می‌کند؛ `udphop` پورت مقصد — و در صورت
|
||
نیاز IP مقصد — را در فواصل زمانی یا به‌ازای هر اتصال عوض می‌کند تا مسدودسازی پورت
|
||
دور زده شود.)
|
||
- **پارامترهای QUIC** — کنترل ازدحام (`reno`، `bbr`، `brutal`، `force-brutal`)،
|
||
نرخ‌های آپلود/دانلود Brutal، و تنظیم پنجره دریافت. در اینباند، **UDP Hop** بازه‌ی
|
||
پورتی را تعیین می‌کند که به کلاینت‌ها اعلام می‌شود (`mport` در لینک اشتراک و ماسک
|
||
`udphop` در اشتراک JSON)؛ خود سرور همچنان روی پورت خودش گوش می‌دهد. از Xray
|
||
26.9.9 کلاینت فقط با ماسک `udphop` پورت عوض می‌کند، برای همین پنل `quicParams.udpHop`
|
||
قدیمی کلاینت را به آن تبدیل می‌کند.
|
||
|
||
FinalMask جایگزین مبهم‌سازی `header`/`seed` به‌ازای هر انتقال می‌شود که بیلدهای
|
||
قدیمی‌تر Xray نمایش می‌دادند.
|
||
|
||
## sockopt — گزینه‌های سطح پایین سوکت
|
||
|
||
`sockopt` در کنار هر انتقالی سوار می‌شود و سوکت زیرین را تنظیم می‌کند. مفیدترین
|
||
فیلدها:
|
||
|
||
| فیلد | پیش‌فرض | معنی |
|
||
| --------------------- | ------- | ---------------------------------------------------------------- |
|
||
| `tcpFastOpen` | `false` | فعال‌سازی TCP Fast Open. |
|
||
| `tcpcongestion` | `bbr` | کنترل ازدحام: `bbr`، `cubic` یا `reno`. |
|
||
| `tproxy` | `off` | حالت پراکسی شفاف: `off`، `redirect` یا `tproxy`. |
|
||
| `domainStrategy` | `AsIs` | نحوه تفکیک نشانی‌ها (`UseIP`، `ForceIPv4`، …). |
|
||
| `dialerProxy` | _(none)_| زنجیر کردن شماره‌گیری این outbound از طریق یک تگ outbound دیگر. |
|
||
| `interface` | _(none)_| اتصال به یک رابط شبکه مشخص. |
|
||
| `mark` | `0` | SO_MARK برای مسیریابی سیاستی (`0` = تنظیم‌نشده). |
|
||
|
||
فیلدهای عددی که روی `0` رها شوند روی سیم حذف می‌شوند تا Xray پیش‌فرض‌های سیستم‌عامل
|
||
را حفظ کند. ورودی‌های پیشرفته (`happyEyeballs`، `customSockopt[]`، تایمرهای
|
||
keepalive) برای موارد خاص در دسترس‌اند.
|
||
|
||
## امنیت
|
||
|
||
لایه امنیتی یکی از **`none`**، **`tls`** یا **`reality`** است، با این
|
||
قواعد واجد شرایط بودن:
|
||
|
||
| امنیت | انتقال‌های واجد شرایط | پروتکل‌های واجد شرایط |
|
||
| ----------- | -------------------------------------------- | --------------------------------------------------- |
|
||
| **TLS** | `tcp`، `ws`، `grpc`، `httpupgrade`، `xhttp` | VLESS، VMess، Trojan، Shadowsocks (Hysteria2 همیشه TLS است) |
|
||
| **REALITY** | `tcp`، `grpc`، `xhttp` | VLESS، Trojan |
|
||
|
||
mKCP و Hysteria لایه TLS/REALITY جداگانه‌ای نمی‌گیرند — mKCP به‌صورت متن ساده اجرا
|
||
می‌شود (با FinalMask استتارش کنید)، و Hysteria به‌طور ذاتی QUIC/TLS است. REALITY
|
||
سرور شما را به‌عنوان یک سایت واقعی TLS استتار می‌کند و به هیچ گواهی نیازی ندارد — به
|
||
[REALITY](/docs/config/reality) مراجعه کنید.
|
||
|
||
## جریان XTLS-Vision
|
||
|
||
جریان `xtls-rprx-vision` سریع و مقاوم در برابر DPI است. این جریان برای
|
||
**VLESS** در یکی از این دو حالت در دسترس است:
|
||
|
||
- انتقال، **TCP** خام با امنیت **TLS** یا **REALITY** باشد (XTLS-Vision
|
||
کلاسیک)، یا
|
||
- رمزنگاری VLESS فعال باشد، روی هر انتقالی (به ادامه مراجعه کنید).
|
||
|
||
جریان را روی **کلاینت** VLESS تنظیم کنید، نه روی inbound. با Vision کلاسیک روی
|
||
TCP، پنل می‌تواند پس از آنکه یک کلاینت از جریان استفاده کرد، یک **Vision seed** نیز
|
||
ارائه دهد.
|
||
|
||
## رمزنگاری VLESS (ML-KEM)
|
||
|
||
VLESS از **رمزنگاری** پساکوانتومی (ML-KEM / `mlkem768x25519`) پشتیبانی می‌کند که در
|
||
`decryption` مربوط به inbound (سمت سرور) و `encryption` کلاینت‌ها (برای تولید
|
||
لینک) ذخیره می‌شود. وقتی فعال باشد، جریان Vision را روی هر انتقالی باز می‌کند. کلیدها
|
||
را از تنظیمات VLESS در پنل تولید کنید.
|
||
|
||
## رمزهای Shadowsocks
|
||
|
||
inboundهای Shadowsocks هم از رمزهای کلاسیک و هم از **Shadowsocks-2022**
|
||
پشتیبانی می‌کنند (نام روش‌هایی که با `2022-blake3-` آغاز می‌شوند). روش
|
||
`2022-blake3-chacha20-poly1305` برای inbound ارائه نمی‌شود: Xray-core آن را فقط بدون کاربر پشتیبانی می‌کند
|
||
و هر inbound پنل کلاینت دارد. outboundها همچنان می‌توانند از آن استفاده کنند.
|
||
|
||
<Callout type="info">
|
||
انتقال‌ها و امنیت باید در هر دو سر یکسان باشند. لینک اشتراک کلاینت آن‌ها را
|
||
کدگذاری می‌کند (`type=ws`، `security=reality`، `flow=xtls-rprx-vision`، …) —
|
||
هر لینکی را با [بازرس لینک اشتراک](/docs/config/share-links) رمزگشایی کنید.
|
||
</Callout>
|