EasyXrayانتقال‌ها و امنیت
هر انتقالی که EasyXray ارائه می‌دهد — TCP، mKCP، WebSocket، gRPC، HTTPUpgrade، XHTTP، Hysteria، XDRIVE، MASQUE — به‌همراه تنظیماتشان، و نیز مبهم‌سازی 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. |
| XDRIVE | xdriveSettings | جریان را از طریق فایل‌ها در یک فضای ذخیره‌سازی ابری مشترک (Google Drive، یک پوشهٔ محلی یا هر API ذخیره‌سازی HTTP) تونل می‌کند. |
| MASQUE | masqueSettings | CONNECT-IP روی HTTP/3 یا HTTP/2 — تنها برای پروتکل MASQUE. مشاهده MASQUE. |
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. |
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 مراجعه کنید.
جریان 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ها همچنان می‌توانند از آن استفاده کنند.
انتقال‌ها و امنیت باید در هر دو سر یکسان باشند. لینک اشتراک کلاینت آن‌ها را
کدگذاری می‌کند (type=ws، security=reality، flow=xtls-rprx-vision، …) —
هر لینکی را با بازرس لینک اشتراک رمزگشایی کنید.