3x-ui testانتقالها و امنیت
هر انتقالی که 3x-ui ارائه میدهد — TCP، mKCP، WebSocket، gRPC، HTTPUpgrade، XHTTP، Hysteria — بههمراه تنظیماتشان، و نیز مبهمسازی FinalMask، sockopt، TLS/REALITY، XTLS-Vision و رمزنگاری VLESS.
یک انتقال تعیین میکند که بستهها چگونه میان کلاینت و سرور حمل شوند، یک لایه امنیتی تعیین میکند که چگونه رمزنگاری و استتار شوند، و 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. |
inboundهای WireGuard و Tunnel (dokodemo-door) هیچ انتخابگر انتقالی
نمایش نمیدهند — جریان آنها تنها security/sockopt را حمل میکند. پنلهای قدیمیتر
یک انتقال خام HTTP/2 (http) نیز نمایش میدادند؛ این انتقال جای خود را به
XHTTP داده و دیگر قابل انتخاب نیست.
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 | کران بالای بستههای در حال پرواز. |
mKCP نمیتواند TLS یا REALITY حمل کند. برای استتار آن، یک ماسک UDP از نوع
FinalMask اضافه کنید — ماسک mkcp-legacy همان مبهمسازی کلاسیک هدر را
بازتولید میکند که Xray قدیمیتر در kcpSettings.header/seed ذخیره میکرد
(آن فیلدها دیگر اینجا وجود ندارند).
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 مراجعه کنید.
جریان 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 تککاربره است.
انتقالها و امنیت باید در هر دو سر یکسان باشند. لینک اشتراک کلاینت آنها را
کدگذاری میکند (type=ws، security=reality، flow=xtls-rprx-vision، …) —
هر لینکی را با بازرس لینک اشتراک رمزگشایی کنید.