mirror of
https://github.com/MHSanaei/3x-ui.git
synced 2026-08-28 05:57:19 +00:00
MHSanaei
814cda3fb4
Bump xtls/xray-core to 50231eaf (v26.7.11) and the three binary pins (DockerInit.sh, release.yml x2) in lockstep. Adapt the panel to the upstream changes: - Shadowsocks "none"/"plain" and VMess "none"/"zero" were removed from the core. A migration rewrites stored none/plain SS methods to a supported cipher and none/zero VMess security to "auto" (on both the clients column and inbound settings JSON); the SS build-time heal does the same so a row injected after boot cannot brick startup. The removed values are dropped from every frontend option list, schema and adapter, and coerced to "auto" at the Go link/sub/Clash emit sites and both link importers. Fix the CipherType_NONE sentinel that no longer compiles. - Unencrypted vless/trojan outbounds to a public address are now refused by the core. Validate outbounds through the vendored config loader when saving the xray template and when storing/merging outbound subscriptions, so one such outbound cannot keep the core from starting. - New TCP finalmask type "xmc" (Minecraft mimicry): add it to the sub link allowlist, the frontend enum and the FinalMask form (hostname, usernames, required password), and document it. - streamSettings gained a "method" alias for "network"; canonicalize it to "network" at inbound save time and in the form adapters/schema so a method-keyed config keeps its transport. - New root "env" config key is passed through xray.Config, compared in Equals, and forces a restart in the hot diff. - REALITY now defaults minClientVer to 26.3.27; update the form placeholder.
204 lines
16 KiB
Plaintext
204 lines
16 KiB
Plaintext
---
|
||
title: انتقالها و امنیت
|
||
description: هر انتقالی که 3x-ui ارائه میدهد — TCP، mKCP، WebSocket، gRPC، HTTPUpgrade، XHTTP، Hysteria — بههمراه تنظیماتشان، و نیز مبهمسازی 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**. |
|
||
|
||
<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`. |
|
||
|
||
## FinalMask — مبهمسازی لایه پایانی
|
||
|
||
**FinalMask** ترافیک را **پس از** لایههای انتقال و امنیت میپیچد، بنابراین میتواند
|
||
انتقالهایی را که TLS حمل نمیکنند (مانند mKCP) استتار کند یا پوستهای دوم روی TLS
|
||
بیفزاید. ماسکها برای هر جهت پیکربندی میشوند:
|
||
|
||
- **ماسکهای TCP** — `fragment`، `sudoku`، `header-custom`، `xmc` (ترافیک را به شکل
|
||
پروتکل Minecraft استتار میکند؛ گذرواژه الزامی است و نام میزبان و نامهای بازیکن
|
||
اختیاریاند).
|
||
- **ماسکهای UDP** — `salamander`، `mkcp-legacy`، `header-custom`، `xdns`، `xicmp`،
|
||
`noise`، `sudoku`، `realm`. (`mkcp-legacy` همان مبهمسازی قدیمی هدر mKCP را
|
||
بازتولید میکند.)
|
||
- **پارامترهای QUIC** — کنترل ازدحام (`reno`، `bbr`، `brutal`، `force-brutal`)،
|
||
نرخهای آپلود/دانلود Brutal، `udpHop` (چرخاندن پورت QUIC در یک بازه برای دور زدن
|
||
مسدودسازی پورت)، و تنظیم پنجره دریافت.
|
||
|
||
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
|
||
کلاسیک)، یا
|
||
- انتقال، **XHTTP** با رمزنگاری VLESS فعال باشد (به ادامه مراجعه کنید).
|
||
|
||
جریان را روی **کلاینت** VLESS تنظیم کنید، نه روی inbound. با Vision کلاسیک روی
|
||
TCP، پنل میتواند پس از آنکه یک کلاینت از جریان استفاده کرد، یک **Vision seed** نیز
|
||
ارائه دهد.
|
||
|
||
## رمزنگاری VLESS (ML-KEM)
|
||
|
||
VLESS از **رمزنگاری** پساکوانتومی (ML-KEM / `mlkem768x25519`) پشتیبانی میکند که در
|
||
`decryption` مربوط به inbound (سمت سرور) و `encryption` کلاینتها (برای تولید
|
||
لینک) ذخیره میشود. وقتی فعال باشد، جریان Vision را روی XHTTP باز میکند. کلیدها
|
||
را از تنظیمات VLESS در پنل تولید کنید.
|
||
|
||
## رمزهای Shadowsocks
|
||
|
||
inboundهای Shadowsocks هم از رمزهای کلاسیک و هم از **Shadowsocks-2022**
|
||
پشتیبانی میکنند (نام روشهایی که با `2022-blake3-` آغاز میشوند). بیشتر رمزها چندکاربره هستند؛
|
||
`2022-blake3-chacha20-poly1305` تککاربره است.
|
||
|
||
<Callout type="info">
|
||
انتقالها و امنیت باید در هر دو سر یکسان باشند. لینک اشتراک کلاینت آنها را
|
||
کدگذاری میکند (`type=ws`، `security=reality`، `flow=xtls-rprx-vision`، …) —
|
||
هر لینکی را با [بازرس لینک اشتراک](/docs/config/share-links) رمزگشایی کنید.
|
||
</Callout>
|