transports.mdx 16 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203
  1. ---
  2. title: انتقال‌ها و امنیت
  3. description: هر انتقالی که 3x-ui ارائه می‌دهد — TCP، mKCP، WebSocket، gRPC، HTTPUpgrade، XHTTP، Hysteria — به‌همراه تنظیماتشان، و نیز مبهم‌سازی FinalMask، sockopt، TLS/REALITY، XTLS-Vision و رمزنگاری VLESS.
  4. icon: Network
  5. ---
  6. یک **انتقال** تعیین می‌کند که بسته‌ها چگونه میان کلاینت و سرور حمل شوند، یک
  7. لایه **امنیتی** تعیین می‌کند که چگونه رمزنگاری و استتار شوند، و **FinalMask**
  8. می‌تواند آنچه باقی مانده را مبهم کند. پنل تنها ترکیب‌های معتبر را ارائه می‌دهد؛ این
  9. صفحه تنظیمات هر انتقال و قواعدی را که پنل اعمال می‌کند فهرست می‌کند.
  10. ## انتقال‌ها
  11. انتقال (مقدار `network` مربوط به inbound) را در فرم inbound/outbound انتخاب کنید. هر
  12. شبکه کلید تنظیمات خود را روی سیم می‌نویسد (`tcpSettings`، `kcpSettings`، …).
  13. | انتقال | کلید تنظیمات | چه زمانی از آن استفاده کنید |
  14. | --------------- | --------------------- | ---------------------------------------------------------------------- |
  15. | **TCP (Raw)** | `tcpSettings` | کمترین سربار. پایه‌ای برای REALITY + XTLS-Vision و fallback‌ها؛ استتار اختیاری هدر HTTP/1.1. |
  16. | **mKCP** | `kcpSettings` | پروتکل قابل‌اعتماد روی **UDP** — پهنای باند را با تأخیر کمتر روی لینک‌های پُرافت معاوضه می‌کند. هیچ TLS/REALITY حمل نمی‌کند. |
  17. | **WebSocket** | `wsSettings` | از طریق CDN‌ها و پراکسی‌های معکوس HTTP کار می‌کند؛ بسیار سازگار است. |
  18. | **gRPC** | `grpcSettings` | مبتنی بر HTTP/2؛ مالتی‌پلکس خوبی دارد و به‌خوبی از طریق Nginx پراکسی می‌شود. |
  19. | **HTTPUpgrade** | `httpupgradeSettings` | `Upgrade` مربوط به HTTP/1.1 و سازگار با CDN؛ سبک‌تر از WebSocket کامل. |
  20. | **XHTTP** | `xhttpSettings` | انتقال HTTP مدرن با مالتی‌پلکس جریانی؛ سازگار با CDN و توانمند برای REALITY. |
  21. | **Hysteria** | `hysteriaSettings` | انتقال مبتنی بر QUIC — تنها برای پروتکل **Hysteria2**. |
  22. <Callout type="info">
  23. inbound‌های **WireGuard** و **Tunnel** (dokodemo-door) هیچ انتخابگر انتقالی
  24. نمایش نمی‌دهند — جریان آن‌ها تنها security/sockopt را حمل می‌کند. پنل‌های قدیمی‌تر
  25. یک انتقال خام **HTTP/2 (`http`)** نیز نمایش می‌دادند؛ این انتقال جای خود را به
  26. **XHTTP** داده و دیگر قابل انتخاب نیست.
  27. </Callout>
  28. ### TCP (Raw) — `tcpSettings`
  29. | فیلد | پیش‌فرض | معنی |
  30. | ------------------------------ | ------- | ----------------------------------------------------------------------- |
  31. | `acceptProxyProtocol` | `false` | پذیرش پروتکل PROXY از یک پراکسی بالادست تا IP واقعی کلاینت حفظ شود. |
  32. | `header.type` | `none` | `none`، یا `http` برای استتار HTTP/1.1. |
  33. | `header.request` / `response` | — | هنگام `type: http`: متد، مسیر، نسخه و یک نگاشت هدر که یک تبادل HTTP معمولی را تقلید می‌کنند. |
  34. ### mKCP — `kcpSettings`
  35. | فیلد | پیش‌فرض | معنی |
  36. | ------------------ | ----------- | ---------------------------------------------------------------- |
  37. | `mtu` | `1350` | بیشینه واحد انتقال، بر حسب بایت (576–1460). |
  38. | `tti` | `20` | بازه زمانی انتقال، بر حسب میلی‌ثانیه (10–100). کمتر = پاسخگوتر، سربار بیشتر. |
  39. | `uplinkCapacity` | `5` | بودجه پهنای باند آپلود، بر حسب **MB/s**. |
  40. | `downlinkCapacity` | `20` | بودجه پهنای باند دانلود، بر حسب **MB/s**. |
  41. | `cwndMultiplier` | `1` | ضریب پنجره ازدحام؛ برای فشار بیشتر روی لینک‌های خوب آن را بالا ببرید. |
  42. | `maxSendingWindow` | `2097152` | کران بالای بسته‌های در حال پرواز. |
  43. <Callout type="info">
  44. mKCP نمی‌تواند TLS یا REALITY حمل کند. برای استتار آن، یک ماسک UDP از نوع
  45. **FinalMask** اضافه کنید — ماسک `mkcp-legacy` همان مبهم‌سازی کلاسیک هدر را
  46. بازتولید می‌کند که Xray قدیمی‌تر در `kcpSettings.header`/`seed` ذخیره می‌کرد
  47. (آن فیلدها دیگر اینجا وجود ندارند).
  48. </Callout>
  49. ### WebSocket — `wsSettings`
  50. | فیلد | پیش‌فرض | معنی |
  51. | --------------------- | ------- | ---------------------------------------------------------------- |
  52. | `path` | `/` | مسیر درخواست — وقتی چند سرویس یک میزبان را به اشتراک می‌گذارند، بر اساس آن مسیریابی کنید. |
  53. | `host` | _(none)_| بازنویسی هدر `Host` (پشت یک CDN مفید است). |
  54. | `headers` | `{}` | هدرهای درخواست اضافی. |
  55. | `heartbeatPeriod` | `0` | ثانیه‌های بین پینگ‌های keepalive؛ `0` آن‌ها را غیرفعال می‌کند. |
  56. | `acceptProxyProtocol` | `false` | پذیرش پروتکل PROXY از یک بالادست. |
  57. ### gRPC — `grpcSettings`
  58. | فیلد | پیش‌فرض | معنی |
  59. | ------------- | ------- | --------------------------------------------------------- |
  60. | `serviceName` | _(none)_| مسیر سرویس gRPC؛ مانند یک مسیر مخفی عمل می‌کند. |
  61. | `authority` | _(none)_| بازنویسی شبه‌هدر `:authority`. |
  62. | `multiMode` | `false` | مالتی‌پلکس چند جریان روی یک اتصال. |
  63. ### HTTPUpgrade — `httpupgradeSettings`
  64. | فیلد | پیش‌فرض | معنی |
  65. | --------------------- | ------- | --------------------------------------------- |
  66. | `path` | `/` | مسیر درخواست. |
  67. | `host` | _(none)_| بازنویسی هدر `Host`. |
  68. | `headers` | `{}` | هدرهای درخواست اضافی. |
  69. | `acceptProxyProtocol` | `false` | پذیرش پروتکل PROXY از یک بالادست. |
  70. ‏HTTPUpgrade یک `Upgrade` تک‌مرحله‌ای HTTP/1.1 بدون قاب‌بندی WebSocket است — هیچ
  71. فیلد heartbeat ندارد.
  72. ### XHTTP — `xhttpSettings`
  73. ‏XHTTP (SplitHTTP) مجموعه فیلد بزرگی دارد؛ پنل پیش‌فرض‌های معقولی را پر می‌کند.
  74. آن‌هایی که معمولاً سراغشان می‌روید:
  75. | فیلد | پیش‌فرض | معنی |
  76. | ---------------------- | ----------- | ---------------------------------------------------------------------- |
  77. | `path` | `/` | مسیر درخواست. |
  78. | `host` | _(none)_ | بازنویسی هدر `Host`. |
  79. | `mode` | `auto` | `auto`، `packet-up`، `stream-up` یا `stream-one`. `packet-up` بیشترین سازگاری با CDN را دارد؛ `stream-*` تأخیر کمتری دارند. |
  80. | `xPaddingBytes` | `100-1000` | بازه padding تصادفی که اندازه بسته‌ها را محو می‌کند. |
  81. | `scMaxBufferedPosts` | `30` | بافر سمت سرور برای POST‌های آپلودشده. |
  82. | `scStreamUpServerSecs` | `20-80` | پنجره stream-up سمت سرور (بازه با خط تیره). |
  83. | `xmux` (`enableXmux`) | _(off)_ | مالتی‌پلکس اتصال — `maxConcurrency` `16-32`، `maxConnections` `6`، … برای همزمانی بالا روشن کنید. |
  84. فیلدهای Session-ID (`sessionIDPlacement`، `sessionIDKey`، `sessionIDTable`،
  85. `sessionIDLength`) و کلیدهای `scMin/MaxEachPostBytes` پیشرفته‌اند؛ آن‌ها را خالی
  86. بگذارید مگر آنکه با یک بالادست مشخص هماهنگ می‌شوید.
  87. ### Hysteria — `hysteriaSettings`
  88. تنها زمانی معتبر است که پروتکل **Hysteria2** باشد.
  89. | فیلد | پیش‌فرض | معنی |
  90. | ---------------- | ------- | ----------------------------------------------------------------------- |
  91. | `version` | `2` | نسخه پروتکل Hysteria. |
  92. | `auth` | _(none)_| رشته احراز هویت مشترک. |
  93. | `udpIdleTimeout` | `60` | ثانیه (2–600) پیش از حذف نشست‌های بی‌کار UDP. |
  94. | `masquerade` | — | استتار به‌عنوان یک سرور HTTP/3: `type` با مقدار `proxy`/`file`/`string` و `url`/`dir`/`content`، به‌علاوه `headers` و `statusCode`. |
  95. ## FinalMask — مبهم‌سازی لایه پایانی
  96. **FinalMask** ترافیک را **پس از** لایه‌های انتقال و امنیت می‌پیچد، بنابراین می‌تواند
  97. انتقال‌هایی را که TLS حمل نمی‌کنند (مانند mKCP) استتار کند یا پوسته‌ای دوم روی TLS
  98. بیفزاید. ماسک‌ها برای هر جهت پیکربندی می‌شوند:
  99. - **ماسک‌های TCP** — `fragment`، `sudoku`، `header-custom`، `xmc` (ترافیک را به شکل
  100. پروتکل Minecraft استتار می‌کند؛ گذرواژه الزامی است و نام میزبان و نام‌های بازیکن
  101. اختیاری‌اند).
  102. - **ماسک‌های UDP** — `salamander`، `mkcp-legacy`، `header-custom`، `xdns`، `xicmp`،
  103. `noise`، `sudoku`، `realm`. (`mkcp-legacy` همان مبهم‌سازی قدیمی هدر mKCP را
  104. بازتولید می‌کند.)
  105. - **پارامترهای QUIC** — کنترل ازدحام (`reno`، `bbr`، `brutal`، `force-brutal`)،
  106. نرخ‌های آپلود/دانلود Brutal، `udpHop` (چرخاندن پورت QUIC در یک بازه برای دور زدن
  107. مسدودسازی پورت)، و تنظیم پنجره دریافت.
  108. ‏FinalMask جایگزین مبهم‌سازی `header`/`seed` به‌ازای هر انتقال می‌شود که بیلدهای
  109. قدیمی‌تر Xray نمایش می‌دادند.
  110. ## sockopt — گزینه‌های سطح پایین سوکت
  111. ‏`sockopt` در کنار هر انتقالی سوار می‌شود و سوکت زیرین را تنظیم می‌کند. مفیدترین
  112. فیلدها:
  113. | فیلد | پیش‌فرض | معنی |
  114. | --------------------- | ------- | ---------------------------------------------------------------- |
  115. | `tcpFastOpen` | `false` | فعال‌سازی TCP Fast Open. |
  116. | `tcpcongestion` | `bbr` | کنترل ازدحام: `bbr`، `cubic` یا `reno`. |
  117. | `tproxy` | `off` | حالت پراکسی شفاف: `off`، `redirect` یا `tproxy`. |
  118. | `domainStrategy` | `AsIs` | نحوه تفکیک نشانی‌ها (`UseIP`، `ForceIPv4`، …). |
  119. | `dialerProxy` | _(none)_| زنجیر کردن شماره‌گیری این outbound از طریق یک تگ outbound دیگر. |
  120. | `interface` | _(none)_| اتصال به یک رابط شبکه مشخص. |
  121. | `mark` | `0` | SO_MARK برای مسیریابی سیاستی (`0` = تنظیم‌نشده). |
  122. فیلدهای عددی که روی `0` رها شوند روی سیم حذف می‌شوند تا Xray پیش‌فرض‌های سیستم‌عامل
  123. را حفظ کند. ورودی‌های پیشرفته (`happyEyeballs`، `customSockopt[]`، تایمرهای
  124. keepalive) برای موارد خاص در دسترس‌اند.
  125. ## امنیت
  126. لایه امنیتی یکی از **`none`**، **`tls`** یا **`reality`** است، با این
  127. قواعد واجد شرایط بودن:
  128. | امنیت | انتقال‌های واجد شرایط | پروتکل‌های واجد شرایط |
  129. | ----------- | -------------------------------------------- | --------------------------------------------------- |
  130. | **TLS** | `tcp`، `ws`، `grpc`، `httpupgrade`، `xhttp` | VLESS، VMess، Trojan، Shadowsocks (Hysteria2 همیشه TLS است) |
  131. | **REALITY** | `tcp`، `grpc`، `xhttp` | VLESS، Trojan |
  132. mKCP و Hysteria لایه TLS/REALITY جداگانه‌ای نمی‌گیرند — mKCP به‌صورت متن ساده اجرا
  133. می‌شود (با FinalMask استتارش کنید)، و Hysteria به‌طور ذاتی QUIC/TLS است. REALITY
  134. سرور شما را به‌عنوان یک سایت واقعی TLS استتار می‌کند و به هیچ گواهی نیازی ندارد — به
  135. [REALITY](/docs/config/reality) مراجعه کنید.
  136. ## جریان XTLS-Vision
  137. جریان `xtls-rprx-vision` سریع و مقاوم در برابر DPI است. این جریان برای
  138. **VLESS** در یکی از این دو حالت در دسترس است:
  139. - انتقال، **TCP** خام با امنیت **TLS** یا **REALITY** باشد (XTLS-Vision
  140. کلاسیک)، یا
  141. - انتقال، **XHTTP** با رمزنگاری VLESS فعال باشد (به ادامه مراجعه کنید).
  142. جریان را روی **کلاینت** VLESS تنظیم کنید، نه روی inbound. با Vision کلاسیک روی
  143. TCP، پنل می‌تواند پس از آنکه یک کلاینت از جریان استفاده کرد، یک **Vision seed** نیز
  144. ارائه دهد.
  145. ## رمزنگاری VLESS (ML-KEM)
  146. ‏VLESS از **رمزنگاری** پساکوانتومی (ML-KEM / `mlkem768x25519`) پشتیبانی می‌کند که در
  147. ‏`decryption` مربوط به inbound (سمت سرور) و `encryption` کلاینت‌ها (برای تولید
  148. لینک) ذخیره می‌شود. وقتی فعال باشد، جریان Vision را روی XHTTP باز می‌کند. کلیدها
  149. را از تنظیمات VLESS در پنل تولید کنید.
  150. ## رمزهای Shadowsocks
  151. ‏inbound‌های Shadowsocks هم از رمزهای کلاسیک و هم از **Shadowsocks-2022**
  152. پشتیبانی می‌کنند (نام روش‌هایی که با `2022-blake3-` آغاز می‌شوند). بیشتر رمزها چندکاربره هستند؛
  153. ‏`2022-blake3-chacha20-poly1305` تک‌کاربره است.
  154. <Callout type="info">
  155. انتقال‌ها و امنیت باید در هر دو سر یکسان باشند. لینک اشتراک کلاینت آن‌ها را
  156. کدگذاری می‌کند (`type=ws`، `security=reality`، `flow=xtls-rprx-vision`، …) —
  157. هر لینکی را با [بازرس لینک اشتراک](/docs/config/share-links) رمزگشایی کنید.
  158. </Callout>