پشتهٔ مدرن VLESS در 2026
Contents
تا سال 2026، VLESS همچنان یک پروتکل پراکسی سبک و بدون حالت (stateless) است، اما جملهٔ «VLESS رمزگذاری ندارد» دیگر توصیف کاملی نیست. Xray-core اکنون VLESS Encryption را به‌صورت اختیاری ارائه میدهد. استقرارها همچنین می‌توانند بسته به مدل تهدید، VLESS را با TLS، REALITY، XTLS Vision، XHTTP و XUDP ترکیب کنند. این لایه‌ها مسائل متفاوتی را حل می‌کنند و نباید همه را در قالب یک پروتکل یکی دانست.
سیاست استناد: این راهنما از منابع اصلی Project X، Xray-core، sing-box و AnyTLS استفاده میکند. Pull requestها و بحث‌های GitHub طراحی و پیادهسازی نگه‌دارندگان پروژه را مستند می‌کنند؛ آن‌ها ممیزی امنیتی مستقل نیستند. اشاره‌ها به SingLink مقایسه‌های معماری‌اند، نه ادعای اینکه SingLinkVPN این پروژه‌ها را پیادهسازی کرده است.
1. پشتهٔ مدرن VLESS در یک نگاه
- VLESS: لایه‌ای سبک برای هویت، فرمان و مقصد.
- VLESS Encryption: لایهٔ اختیاری و بومی محافظت از payload در نسخهٔ فعلی Xray-core.
- TLS 1.3 / REALITY: امنیت انتقال بیرونی، احراز هویت و ظاهر شبکه‌ای.
- XTLS Vision: کنترل جریان و بهینهسازی مسیر داده، نه یک رمز جداگانه.
- RAW / XHTTP / gRPC / WebSocket: روش‌های انتقالی که دادهٔ پراکسی را حمل می‌کنند.
- XUDP: گزینه‌ای برای کدگذاری بسته‌های UDP در اکوسیستم Xray.
- XMUX و دیگر سیستم‌های MUX: روش‌هایی برای اشتراک‌گذاری اتصال‌های زیرین.
- Padding / FinalMask / Browser Dialer: ابزارهایی برای طول، زمان‌بندی، رفتار انتقال بیرونی یا شبکه‌سازی مرورگر.
بنابراین یک اتصال را می‌توان این‌طور مدل کرد: ترافیک برنامه ← هویت و مقصد VLESS ← امنیت پروتکلی یا بیرونی ← کنترل جریان Vision ← یک روش انتقال مانند RAW یا XHTTP ← TCP یا UDP. هر ماژول در هر طراحی لازم یا سازگار نیست.
2. پروتکل پایهٔ VLESS چه کاری انجام میدهد
مستندات Project X VLESS را یک پروتکل انتقال سبک و بدون حالت تعریف میکند که به زمان سیستم وابسته نیست و برای احراز هویت از UUID یا شناسهٔ نگاشت‌شده استفاده میکند. پیادهسازی عمومی کدگذاری در Xray-core نسخه، شناسهٔ کاربر، افزونه‌ها (addons)، فرمان، پورت مقصد، آدرس و داده‌های پس از آن را نشان میدهد.
به زبان عملی، لایهٔ پایه به این پرسش‌ها پاسخ میدهد: کلاینت کیست، چه اتصالی درخواست شده و به کجا باید برود؟ مسیریابی هوشمند، بار نودها، حقوق پلن و اتصال مجدد خودکار معمولاً به لایه‌های بالاتر محصول و کنترل تعلق دارند.
پیکربندی‌های سنتی معمولاً از `encryption: "none"` استفاده می‌کنند. راهنمای فعلی Project X امنیت انتقال بیرونی را الزامی می‌داند، مگر اینکه طرف مقابل و پیوند، زیرساخت خصوصی مورد اعتماد باشند یا VLESS Encryption فعال باشد.
3. VLESS Encryption چه چیزی را تغییر میدهد
VLESS Encryption یک لایهٔ محافظتی بومی و اختیاری است که در 2025 به Xray-core ادغام شد. PR ادغام‌شدهٔ #5067 و مستندات فعلی پیکربندی، دست‌دهی `mlkem768x25519plus`، ظاهرهای `native`، `xorpub` و `random`، رفتار نشست `1rtt` و `0rtt` و padding متغیر را توصیف می‌کنند.
اهداف طراحی منتشرشده
- استخراج کلیدهای نشست از ترکیب ML-KEM-768 و X25519؛
- محافظت از payloadهای VLESS بدون نیاز به TLS بیرونی؛
- استفاده از tickets برای ازسرگیری 0-RTT در اتصال‌های بعدی و حالت کوتاه‌عمر برای کاهش خطر بازپخش (replay)؛
- استفاده از padding متغیر و حالت‌های اختیاری XOR برای تغییر ظاهر طول ثابت یا کلید عمومی.
این‌ها ادعاهای طراحی و پیادهسازی نگه‌دارندگان پروژه‌اند. ما ممیزی رمزنگاری مستقلی که همهٔ این ویژگی‌ها را پوشش دهد پیدا نکردیم؛ به همین دلیل این راهنما طراحی را «مقاوم کامل در برابر بازپخش» یا «کاملاً امن در برابر کوانتوم» نمی‌نامد.
آنچه به‌طور خودکار جایگزین نمیکند
VLESS Encryption از payload پروتکل محافظت میکند. این لایه به‌طور خودکار زنجیرهٔ گواهی HTTPS معمولی، دست‌دهی وب‌سایت، رفتار HTTP/2 یا HTTP/3 یا سازگاری با CDN ایجاد نمیکند. بنابراین معادل TLS یا REALITY نیست.
4. TLS 1.3 و REALITY
TLS اعتبارسنجی استاندارد گواهی، تبادل کلید، یکپارچگی و رمزگذاری انتقال را فراهم میکند. میتواند همراه RAW، XHTTP، gRPC یا WebSocket به کار رود؛ نسخهٔ مذاکره‌شده، ALPN و بررسی گواهی همچنان به پیکربندی و پشتیبانی طرف مقابل بستگی دارد.
مستندات REALITY در Project X یک لایهٔ امنیتی اصلاح‌شده به سبک TLS را توصیف میکند که تنظیمات target، serverNames، کلیدهای X25519 و shortId و همچنین دادهٔ اختیاری تأیید ML-DSA-65 دارد. REALITY میتواند همراه RAW، XHTTP و gRPC به کار رود.
REALITY را نباید به «TLS بدون گواهی» تقلیل داد. رفتار آن مجوزدهی کلاینت را با ظاهر یک دست‌دهی بیرونی ترکیب میکند. نتیجه همچنان به target، اثر انگشت کلاینت، روش انتقال و کیفیت استقرار بستگی دارد و نمی‌تواند نامرئی بودن در برابر همهٔ طبقه‌بندها را تضمین کند.
5. XTLS Vision پروتکل رمزگذاری نیست
مستندات VLESS/Vision Vision را در دستهٔ کنترل جریان قرار میدهد. در شرایط پشتیبانی‌شده میتواند ترافیک TLS درونی را تشخیص دهد و رمزگذاری یا کپی اضافی را کاهش دهد. در مسیرهای سازگار Linux و TCP، هسته ممکن است از `splice` استفاده کند تا کرنل داده را مستقیماً منتقل کند.
تقسیم‌بندی دقیق این است: TLS، REALITY یا VLESS Encryption امنیت را تأمین می‌کنند؛ Vision نحوهٔ عبور دادهٔ محافظت‌شده از لایهٔ پراکسی را بهینه میکند. هر پلتفرم، روش انتقال یا نوع ترافیکی نمی‌تواند از splice استفاده کند.
6. سه حالت XHTTP
بحث طراحی XHTTP از سوی نگه‌دارندگان یک سیستم انتقال HTTP را توصیف میکند که میتواند در محیط‌های HTTP/1.1، HTTP/2 و HTTP/3 کار کند:
- packet-up: چند درخواست POST بالادستی همراه با یک پاسخ پایین‌دستی پیوسته؛ برای سازگاری گسترده با واسطه‌ها طراحی شده است.
- stream-up: یک POST بالادستی جریانی و یک GET پایین‌دستی جریانی جداگانه.
- stream-one: یک درخواست جریانی دوطرفه؛ عملکرد و سازگاری آن به واسطه‌ها بستگی دارد.
XHTTP همچنین میتواند از padding سرآیند، مسیرهای جداگانهٔ آپلود و دانلود و XMUX استفاده کند. اینکه از طریق یک CDN مشخص کار کند یا نه، به حالت، نسخهٔ HTTP، رفتار reverse proxy و پیکربندی ارائه‌دهنده بستگی دارد.
7. XMUX، مالتی‌پلکسینگ عمومی و انسداد سر صف
XMUX هم‌زمانی XHTTP، تعداد اتصال‌های زیرین، استفادهٔ مجدد، طول عمر و keepalive را مدیریت میکند. هدفش نگه داشتن دقیقاً یک اتصال برای همیشه نیست؛ بلکه میان هزینهٔ دست‌دهی، هم‌زمانی و الگوهای اتصال طولانی‌مدت توازن برقرار میکند.
مستندات multiplex در sing-box نیز smux، yamux و h2mux را فهرست میکند. مالتی‌پلکسینگ میتواند دست‌دهی‌ها را کاهش دهد، اما اتلاف بسته یا انسداد در یک اتصال TCP زیرین ممکن است روی چند جریان اثر بگذارد. HTTP/3 از انسداد سر صف میان جریان‌ها در سطح TCP جلوگیری میکند، هرچند یک جریان QUIC بهتنهایی همچنان ممکن است منتظر بازیابی بسته‌های ازدست‌رفته بماند.
8. XUDP یک گزینهٔ کدگذاری UDP است
مستندات VLESS در sing-box `xudp` را در کنار `packetaddr` و غیرفعال کردن کدگذاری اضافی، به‌عنوان یک گزینهٔ کدگذاری بسته فهرست میکند. این فقط از این نتیجهٔ محدود پشتیبانی میکند که XUDP در این اکوسیستم UDP را حمل میکند؛ XUDP یک مشخصهٔ کامل و نسخه‌دار بسته نیست.
رفتار دقیق نشست، آدرس، مرزبندی و مهاجرت باید با نسخه و کد دقیق هسته بررسی شود. این راهنما عمداً از ارائهٔ جزئیات استنباطی قاب‌بندی (framing) به‌عنوان یک استاندارد همگانی پرهیز میکند.
9. Padding، FinalMask، ECH و Browser Dialer
- Padding: ویژگی‌های طول یا زمان‌بندی را تغییر میدهد؛ رمزگذاری نیست.
- FinalMask: مستندات پیکربندی آن FinalMask را در مرحلهٔ پردازش انتقال بیرونی، با تنظیمات مرتبط با TCP، UDP و QUIC قرار میدهد.
- ECH: مستندات TLS در sing-box پیکربندی Encrypted ClientHello را برای محافظت از بخشی از ClientHello شامل می‌شود؛ ECH جایگزین رمزگذاری تونل نیست.
- Browser Dialer: مستندات Project X این امکان را میدهد که یک مرورگر واقعی اتصال‌های TLS و HTTP را برقرار کند؛ با این کار رفتار مرورگر واقعی‌تر می‌شود، اما به بهای محدودیت‌های استقرار و عملکرد.
10. Fallback چه کاری میتواند و نمی‌تواند بکند
مستندات Fallback در Project X نشان میدهد چگونه SNI، مسیرها یا ترافیک پروتکلی ناهمخوان می‌توانند به Nginx، Caddy یا یک وب‌سایت معمولی هدایت شوند تا یک نقطهٔ ورود هم سرویس پراکسی و هم سرویس‌های معمولی را میزبانی کند.
Fallback میتواند از پاسخ دادن به هر تلاش ناموفق احراز هویت با یک خطای آشکار یکسان جلوگیری کند. اما مصونیت در برابر کاوش فعال (active probing) نیست؛ قابلیت شناسایی همچنان به TLS، روش انتقال، پاسخ‌ها، زمان‌بندی و پیکربندی سرور بستگی دارد.
11. AnyTLS یک مقایسه است، نه جزئی از VLESS
سند پروتکل AnyTLS این مسیر را توصیف میکند: TCP ← TLS ← احراز هویت با `SHA-256(password)` ← یک نشست ← چند جریان. قاب‌ها شامل Command، Stream ID، Data Length و Data هستند و فرمان‌های SYN، PSH، FIN، settings، padding، heartbeat و SYNACK نسخهٔ 2 را دارند.
مدل نشست، جریان‌های متعدد، padding پویا و بررسی سلامت آن، مقایسهٔ مفیدی فراهم میکند. AnyTLS همچنان پروتکلی جداگانه است؛ VLESS این ویژگی‌ها را به‌طور خودکار به ارث نمی‌برد.
12. ترکیب‌های رایج و محدودیت‌هایشان
- VLESS + REALITY + Vision + RAW: با تمرکز بر عملکرد مستقیم و ظاهر بیرونی به سبک TLS؛ بدون وابستگی به CDN.
- VLESS + TLS/REALITY + XHTTP: با تمرکز بر حمل از طریق HTTP، reverse proxyها و سازگاری مشروط با CDN.
- VLESS Encryption + Vision: از payload پروتکل در سناریوهای رله یا امنیت بیرونی غیراستاندارد محافظت میکند، بدون ظاهر HTTPS معمولی.
- VLESS + TLS + XHTTP + Browser Dialer: از پشتهٔ شبکهٔ یک مرورگر واقعی استفاده میکند، با هزینهٔ عملیاتی بالاتر.
- AnyTLS + TLS: طراحی جداگانه‌ای از نشست، جریان و padding؛ یک پشتهٔ VLESS نیست.
هیچ پیکربندی‌ای همیشه و هم‌زمان از نظر عملکرد، سازگاری، قابلیت نگهداری، ظاهر و امنیت بهترین نیست. انتخاب باید از مدل تهدید، مسیر شبکه، محدودیت‌های CDN یا پراکسی، پلتفرم‌های کلاینت و نیازهای مشاهده‌پذیری آغاز شود.
13. معنای این موضوع برای پژوهش‌های SingLink
مستندات عمومی VLESS و AnyTLS می‌توانند به پژوهش دربارهٔ هویت، تبادل کلید، نشست‌ها، جریان‌ها، UDP، padding، مالتی‌پلکسینگ، بازیابی و مذاکرهٔ نسخه کمک کنند. این مقاله ثابت نمیکند که SingLink 2.0 بر پایهٔ VLESS، REALITY، XHTTP یا AnyTLS ساخته شده است.
SingLinkVPN باید همچنان رفتار منتشرشده، جهت‌های پژوهشی و پیادهسازی افشانشده را از هم جدا نگه دارد. برای دامنهٔ منتشرشدهٔ فعلی، برنامهٔ متن‌باز SingLinkVPN را ببینید.
14. سوالات متداول (FAQ)
آیا VLESS بهتنهایی ترافیک را رمزگذاری میکند?
VLESS در پیکربندی سنتی `encryption: "none"` از payload پروتکل محافظت نمیکند و به زیرساخت خصوصی مورد اعتماد یا امنیت بیرونی نیاز دارد. نسخهٔ فعلی Xray-core میتواند VLESS Encryption را فعال کند، بنابراین پاسخ به پیادهسازی و پیکربندی بستگی دارد.
آیا VLESS Encryption میتواند جایگزین TLS یا REALITY شود?
VLESS Encryption معادل TLS یا REALITY نیست. از payloadهای VLESS محافظت میکند، اما به‌طور خودکار گواهی HTTPS استاندارد، دست‌دهی یا ظاهر یک وب‌سایت را فراهم نمیکند.
آیا XTLS Vision رمزگذاری انجام میدهد?
خیر، XTLS Vision رمزگذاری انجام نمیدهد. Vision در درجهٔ اول کنترل جریان و بهینهسازی مسیر داده را فراهم میکند.
سه حالت XHTTP را چگونه باید انتخاب کرد?
در XHTTP، حالت packet-up بر سازگاری تأکید دارد، stream-up جهت‌های جریانی را از هم جدا میکند و stream-one از یک جریان دوطرفه استفاده میکند. هر کدام باید روی مسیر واقعی واسطه‌ها آزموده شود.
تفاوت XUDP با یک پراکسی UDP عمومی چیست?
XUDP یک گزینهٔ کدگذاری UDP در اکوسیستم Xray است. رفتار دقیق آن به هسته و نسخه بستگی دارد و نباید آن را فقط از روی نامش استنباط کرد.
آیا SingLink 2.0 بر پایهٔ VLESS یا AnyTLS ساخته شده است?
شواهد عمومی کافی برای اثبات چنین رابطهای میان پروتکل SingLink و VLESS یا AnyTLS وجود ندارد. این مقاله یک مقایسهٔ فنی است، نه افشای پیادهسازی.
15. جمع‌بندی و تاریخ منابع
VLESS مدرن یک پشتهٔ ترکیب‌پذیر است: VLESS هویت و مقصد را حمل میکند، VLESS Encryption محافظت اختیاری در لایهٔ پروتکل را اضافه میکند، TLS یا REALITY امنیت بیرونی را تأمین میکند، Vision جریان را بهینه میکند، XHTTP و XUDP ترافیک را حمل می‌کنند و مالتی‌پلکسینگ یا padding رفتار اتصال را بیشتر تغییر می‌دهند.
تاریخ انتشار اصلی: 20 مه 2026. تاریخ بازبینی منابع فنی: 28 ژوئیهٔ 2026. این پروژه‌ها همچنان در حال تغییرند؛ پیش از استقرار، مستندات، تاریخچهٔ تغییرات و سازگاری نسخهٔ دقیق را بررسی کنید.
