پروتکل VLESS: راهنمای V2Ray VPN، سرور Xray و دور زدن سانسور
تقریباً نیم دهه پس از آنکه VLESS در یک مخزن گمنام GitHub incubation ظاهر شد، بیسروصدا به پروتکل پیشفرض پشت پروکسیهایی که مردم روسیه، ایران و چین واقعاً از آنها استفاده میکنند تبدیل شده است. دلایل آن غیر رمانتیک است. کوچک است. خودش چیزی را رمزگذاری نمیکند. همچنین تنها پروتکل پرکاربردی است که بزرگترین سیستمهای بازرسی عمیق بسته (DPI) دولتی تا اواسط سال 2026 هنوز نتوانستهاند آن را به طور قطعی شکست دهند.
این راهنما توضیح میدهد که VLESS به عنوان یک پروتکل سبک وزن چیست، چگونه از نظر داخلی کار میکند، چه چیزی روی آن اجرا میشود (Xray، XTLS، REALITY)، چگونه با VMess، Trojan، Shadowsocks، WireGuard و پروتکلهای VPN سنتی مانند OpenVPN مقایسه میشود و یک راهاندازی واقعی VLESS VPN در عمل چگونه است. این یک توضیح فنی است، نه یک راهنمای پیکربندی. اگر آن را تمام کردید و هنوز میخواهید دستورات سرور را کپی-پیست کنید، اسناد پروژه در xtls.github.io گام بعدی مناسب هستند.
VLESS چیست و چرا انجمن V2Ray آن را ساخته است؟
VLESS، مخفف "VMess Less"، یک پروتکل پروکسی سبک وزن بدون تابعیت است که در سال ۲۰۲۰ توسط توسعهدهندهای به نام RPRX معرفی شد، که از سال ۲۰۱۹ یک مخزن انکوباسیون در RPRX/v2ray-vless را نگهداری میکرد. این پروتکل به عنوان یک نسخه اصلاحشده عمدی از VMess، پروتکل اصلی V2Ray، طراحی شده است که تا اواخر دهه ۲۰۱۰ تحت سیستم رمزگذاری، محافظت در برابر بازپخش و همگامسازی ساعت خود، به طور فزایندهای ناکارآمد شده بود.
امروزه VLESS عمدتاً در دو پایگاه کد وجود دارد. مخزن اصلی v2fly/v2ray-core آن را برای سازگاری در خود جای داده است. انشعاب XTLS/Xray-core که توسط RPRX نیز نگهداری میشود، پیادهسازی فعالتری است که توسعه داده شده است: 38600 ستاره گیتهاب و تقریباً 5400 انشعاب تا ماه مه 2026، در مقایسه با 33900 ستاره در v2fly/v2ray-core. Xray ویژگیهای مهم، یعنی کنترل جریان XTLS Vision و انتقال REALITY را ارائه میدهد، که v2fly upstream فاقد آن است.
نحوه عملکرد پروتکل VLESS: UUID، بدون رمزگذاری، TLS در خارج
پروتکل سیم VLESS به اندازه کافی کوتاه است که بتوان آن را در یک پاراگراف توضیح داد. یک کلاینت یک اتصال را باز میکند. یک هدر ارسال میکند. هدر دارای یک بایت نسخه، یک UUID شانزده بایتی برای کاربر، یک نشانگر طول برای فیلد افزونههای اختیاری، خود افزونهها، یک دستور یک بایتی (TCP یا UDP)، پورت مقصد، یک بایت نوع آدرس و آدرس است. این مقدار به ۲۵ تا ۵۰ بایت در هر اتصال میرسد. OpenVPN بیش از ۱۰۰ بایت در هر بسته اجرا میکند.
هدر به هیچ وجه توسط خود VLESS رمزگذاری نشده است. پروتکل به صراحت در پیکربندی JSON خود به `encryption: "none"` نیاز دارد و مستندات v2fly بیان میکند که این فیلد نمیتواند خالی بماند - باید با صدای بلند "none" نوشته شود، به طوری که به اپراتورها یادآوری شود که پروتکل تمام محرمانگی را به هر انتقالی که در زیر آن قرار دارد، واگذار میکند. در عمل، آن انتقال تقریباً همیشه TLS 1.3 است.
این انتخاب طراحی، منبع تمام ویژگیهای جالب VLESS است. VLESS با عدم اجرای لایه رمزگذاری خود، از حالت خرابی که VMess را در شبکههای سانسور شده محکوم به فنا میکرد، جلوگیری میکند. لایه دوم رمزگذاری درون یک تونل TLS بیرونی، چیزی را تولید میکند که محققان تحلیل ترافیک آن را الگوهای "TLS-in-TLS" مینامند. سیستمهای DPI ایالتی که برای تشخیص دقیق آن شکل دولایه آموزش دیدهاند، دلیل اصلی افزایش نرخ تشخیص VMess از 80 درصد در فایروال بزرگ چین تا سپتامبر 2025 بودند. VLESS که تنها یک حباب احراز هویت و ابرداده مسیریابی را حمل میکند، بسیار نزدیکتر به یک مکالمه TLS معمولی به نظر میرسد، که نوع انگشتنگاری پروتکلی را که سیستمهای بازرسی عمیق بسته به آن متکی هستند، شکست میدهد.
یکی دیگر از موارد عمدی که نادیده گرفته شده، وضعیت (stateness) است. VMess به ساعتهای هماهنگ بین کلاینت و سرور متکی است و از مهرهای زمانی بسته برای جلوگیری از حملات بازپخش استفاده میکند. نتیجه، سالها خرابی اتصال گیجکننده بود، هر زمان که ساعت تلفن تغییر میکرد، لپتاپ بوت دوگانه داشت یا سرور در منطقه زمانی اشتباه قرار داشت. VLESS بدون وضعیت است. UUID کل داستان احراز هویت است. اگر UUID مطابقت داشته باشد، اتصال مجاز است. در غیر این صورت، در اولین بایت رد میشود. هیچ چیز به زمان بستگی ندارد.
UUIDها در VLESS شناسههای استاندارد RFC-4122 هستند. دستور `xray uuid` آنها را تولید میکند؛ هر مولد UUID استانداردی نیز کار میکند. رشتههای سفارشی تا 30 بایت پذیرفته میشوند و از طریق آنچه اسناد "استاندارد نگاشت UUID VLESS" مینامند، به UUIDها نگاشت میشوند. اکثر تنظیمات به UUIDهای متعارف پایبند هستند زیرا نگاشت در عمل هیچ چیزی را تغییر نمیدهد.
گزینههای انتقال در زیر پروتکل قرار دارند: TCP (با یا بدون TLS)، mKCP، WebSocket، gRPC و QUIC همگی پشتیبانی میشوند. هر کدام ترافیک را به طور متفاوتی شکل میدهند. WebSocket به VLESS اجازه میدهد پشت یک handshake معمولی برای ارتقاء HTTP/1.1 پنهان شود و از طریق CDNهایی مانند Cloudflare مسیریابی کند. gRPC از مالتیپلکسینگ HTTP/2 پشتیبانی میکند. QUIC همه چیز را درون یک نشست TLS 1.3 مبتنی بر UDP خارجی حمل میکند. این پروتکل اهمیتی نمیدهد که روی کدام انتقال اجرا شود. این جداسازی همان چیزی است که آن را قابل حمل میکند.

Xray، REALITY و XTLS: Stack VLESS واقعاً اجرا میشود
در عمل، هیچکس VLESS را بدون اجازه اجرا نمیکند. بخشهای جالب آن، چیزهایی هستند که در اطراف آن اجرا میشوند.
Xray-core سیستم عامل غالب است. این سیستم عامل، انشعابی از V2Ray-core است که توسط RPRX و مشارکتکنندگان XTLS پس از جدایی از جامعه آغاز شد و دو فناوری را ارائه میدهد که VLESS برای کارهای جدی دور زدن سانسور به آنها وابسته است: XTLS Vision و REALITY.
XTLS Vision (که در پیکربندی به صورت `flow: "xtls-rprx-vision"` مشخص شده است) یک طرح لایهگذاری است که بر روی ترافیک TLS 1.3 اعمال میشود. مشکلی که این طرح حل میکند، ظریف است. رکوردهای TLS 1.3 وقتی دادههای داخلی برنامه با اشکال ثابت را حمل میکنند، امضاهای طولی قابل پیشبینی دارند - این طولها اطلاعات مربوط به آنچه که تونل میشود را فاش میکنند. Vision در مرحله اولیه handshake، بایتهای لایهگذاری را اضافه میکند. پس از برقراری اتصال، به کپی کردن سوکت خام تغییر میکند. در لینوکس، از فراخوانی سیستمی `splice()` برای ارسال بستههای TCP در هسته بدون کپی کردن از طریق فضای کاربر استفاده میکند. نتیجه، توان عملیاتی نزدیک به آنچه یک اتصال TCP بدون پروکسی ارائه میدهد، است، با این تفاوت که نشت امضای طولی مسطح میشود.
REALITY که در سال ۲۰۲۳ منتشر شد و در github.com/XTLS/REALITY نگهداری میشود، رادیکالتر است. یک سرور استاندارد VLESS+TLS گواهی TLS خود را ارائه میدهد، به این معنی که مالک یک دامنه است، یک Certbot را در جایی اجرا میکند و یک اثر انگشت گواهی را افشا میکند که یک سیستم DPI میتواند با استفاده از پروکسی مرتبط کند. REALITY کل این ایده را کنار میگذارد. سرور به جای اجرای TLS خود، handshake یک وبسایت شخص ثالث واقعی را جعل میکند. اپراتور هدف را انتخاب میکند: `microsoft.com`، `apple.com`، هر دامنهای. سرور از جعل SNI و تبادل کلید X25519 استفاده میکند. کلاینتهایی که کلید عمومی صحیح REALITY را میدانند، یک handshake واقعی TLS 1.3 را در برابر زنجیره گواهی جعل شده تکمیل میکنند، دقیقاً همانطور که یک مرورگر با یک وب سرور واقعی handshake میکند و سپس به تونل VLESS هدایت میشوند. کلاینتهایی که این کار را نمیکنند، از جمله سیستمهای DPI کاوشگر، چیزی شبیه به یک اتصال عادی به سایت جعلی، از جمله گواهی واقعی، را میبینند.
منظور مردم از ترکیب VLESS به عنوان پروتکل داخلی، XTLS Vision برای مسطحسازی طولی و REALITY برای استتار دست دادن، ترکیبی است که از عبارت «VLESS+REALITY» یا «VLESS+Vision+REALITY» استفاده میکند. این پیکربندی است که تا اواسط سال ۲۰۲۶، هنوز در محیطهایی که تقریباً هیچ چیز دیگری کار نمیکند، کار میکند.
VLESS در مقابل VMess در مقابل Trojan در مقابل Shadowsocks در مقابل WireGuard
فضای پروتکل اطراف VLESS کوچک است و تفاوتها مهم هستند. نسخه کوتاه در زیر آمده است؛ نسخه طولانیتر جدول است.
VMess نسل قبلی VLESS است. این نرمافزار رمزگذاری AEAD، محافظت در برابر بازپخش و انواع مبتنی بر alterId مخصوص به خود را دارد. در یک شبکه بدون سانسور، این ویژگیها چند درصد از توان عملیاتی را کاهش میدهند و هیچ مزیتی ندارند. در یک شبکه سانسور شده، الگوی رمزگذاری درون TLS قابل تشخیص است و تلهمتری GFW از سپتامبر 2025، حدود 80 درصد تشخیص آن را نشان میدهد.
تروجان یک طرح مشابه از یک تیم متفاوت است. حتی از VLESS سادهتر است: یک رمز عبور به جای UUID، بدون فیلد افزونه، TLS در بیرون. سالها این مینیمالیسم باعث قدرت آن میشد؛ ارتقاء GFW در آگوست 2025 این وضعیت را تغییر داد و تروجان اکنون حدود 90 درصد تشخیص را دارد.
Shadowsocks از خانوادهی کاملاً متفاوتی میآید. این یک رمزنگاری AEAD متقارن بدون نمای TLS است که طوری طراحی شده که شبیه بایتهای تصادفی به جای HTTPS به نظر برسد. این رویکرد تا زمانی که GFW شروع به علامتگذاری ترافیک کاملاً رمزگذاری شده به عنوان مشکوک به طور پیشفرض کرد، کار میکرد. پیادهسازیهای مدرن Shadowsocks به افزونههای انتقال (v2ray-plugin، cloak) متکی هستند که رمزنگاری را در TLS یا HTTP میپیچند و به طور مؤثر معماری VLESS را از جهت دیگر بازسازی میکنند.
وایرگارد کاملاً به بحث دیگری تعلق دارد. این یک VPN در سطح هسته است، نه یک پروتکل پروکسی. در یک شبکه پاک، در توان عملیاتی خام حدود ۲ تا ۳ درصد سریعتر از VLESS+XTLS است، با سربار CPU بسیار کمتر، و همچنان پاسخ مناسبی برای موارد استفاده معمولی از حریم خصوصی از ISP است. در شبکههای سانسور شده، بایت ثابت 0x01 handshake آن به طور جزئی انگشتنگاری میشود و توان عملیاتی مؤثر به نزدیک صفر میرسد.
| پروتکل | خانواده | لایه بیرونی | مقاومت در برابر DPI | بهترین برای |
|---|---|---|---|---|
| واقعیت مجازی | پروکسی V2Ray/Xray | TLS جعل هویتشده ۱.۳ | بالا (تشخیص کمتر یا مساوی ۵٪ در گزارشهای میدانی) | شبکههای متخاصم |
| ویمِس | پروکسی V2Ray | خود رمزگذاری درون TLS | کم (~۸۰٪ وزن خالص) | فقط سازگاری قدیمی |
| تروجان | پروکسیِ TLS-fronting | TLS متعلق به خود | پایین (حدود ۹۰٪ GFW پس از آگوست ۲۰۲۵) | میزبانی سادهتر |
| شدوساکس (AEAD) | مبهمسازی متقارن | بایتهای تصادفی / افزونه TLS | مختلط (بستگی به افزونه دارد) | کاربران موبایل در لینکهای بیکیفیت |
| وایرگارد | هسته VPN | UDP + نویز هندشینگ | بسیار پایین (قابل تشخیص DPI) | حریم خصوصی و سرعت شبکه پاک |
VLESS، سانسور و محاصره DPI روسیه
اگر VLESS به خاطر این واقعیت نبود که سانسور در روسیه و رژیمهای مشابه را با اطمینان بیشتری نسبت به هر پروتکل گسترده دیگری دور میزند، در تاریخ نرمافزارهای پروکسی به حاشیه میرفت. از سال ۲۰۲۴، بزرگترین سیستمهای DPI دولتی در جهان به طور فعال در تلاش برای از بین بردن آن بودهاند. از آن زمان، داستان به یک بازی عمومی و آهسته تبدیل شده است.
در روسیه، Roskomnadzor گزارش داد که تا ژانویه ۲۰۲۶، ۴۳۹ سرویس VPN مسدود شده است. طبق گزارش zona.media در آوریل ۲۰۲۶، بودجه فدرال برای مسدود کردن VPN تقریباً ۶۰ میلیارد روبل (حدود ۷۸۰ میلیون دلار) برای سالهای ۲۰۲۵-۲۰۲۷ است و ۲.۲۷ میلیارد روبل دیگر (حدود ۲۹ میلیون دلار) به طور خاص برای فیلتر کردن ترافیک مبتنی بر هوش مصنوعی اختصاص داده شده است. در ۱۷ فوریه ۲۰۲۶، Roskomnadzor دوباره تشدید شد و موج شدیدی از مسدود کردن را با هدف قرار دادن VLESS-over-TCP-with-TLS، به طور خاص، همانطور که توسط Mezha و digirpt مستند شده است، آغاز کرد. کاربران ظرف چند ساعت به REALITY، gRPC و انتقالهای مبتنی بر CDN روی آوردند. نرخ دور زدن گزارش شده جامعه برای VLESS+REALITY در برابر DPI روسیه در طول آن موج نزدیک به ۹۹.۵ درصد بود، عددی که باید به عنوان یک جهت در نظر گرفته شود تا اندازهگیری.
در چین، دیوار بزرگ آتش (Great Firewall) در سال ۲۰۲۵ روند مشابهی را طی کرد. میزان شناسایی تروجانها در ماه اوت به حدود ۹۰ درصد و میزان شناسایی VMess در ماه سپتامبر به حدود ۸۰ درصد کاهش یافت. یک رویداد امنیت سایبری جداگانه در سپتامبر ۲۰۲۵، نشت ۶۰۰ گیگابایتی از یک پیمانکار GFW چینی که توسط Cybernews گزارش شد، بخشهایی از زیرساخت طبقهبندی داخلی را در معرض خطر قرار داد، اما به خودی خود تغییری در اقتصاد استقرار ایجاد نکرد. آزمایش جامعه در greatfirewallguide.com نرخ دور زدن ۹۸ درصدی را برای VLESS+REALITY+Vision در اوایل سال ۲۰۲۶ گزارش کرد.
در ایران، IRGFW شرکت MCI حداقل از آوریل ۲۰۲۴ آدرسهای IP مربوط به REALITY را در لیست خاکستری قرار داده است، که در بحث XTLS/Xray-core شماره ۳۲۶۹ مستند شده است. اپراتورها گزارش میدهند که یک IP که حدود ۱۰۰ گیگابایت ترافیک REALITY را حمل میکند، معمولاً ظرف ۴۸ ساعت توسط ایرانسل مسدود میشود، به همین دلیل است که چرخش سرور و پوشش CDN در آنجا به یک رویه استاندارد تبدیل شده است.
ظاهر راهاندازی VLESS VPN: سرور، کلاینتها، پیکربندیها
یک پیادهسازی VLESS کارآمد سه بخش دارد: یک سرور در جایی دیگر، یک کلاینت روی هر دستگاه و یک رشته اتصال که آنها را به هم متصل میکند.
سمت سرور ساده است. هر VPS ارزان قیمتی جواب میدهد: Hetzner، Vultr، OVH، یا هر چیزی با IPv4 عمومی. Xray-core را از فایلهای باینری انتشار پروژه یا یک مدیر بسته نصب کنید، یک UUID (`xray uuid`) ایجاد کنید، یک جفت کلید X25519 برای REALITY (`xray x25519`) ایجاد کنید، یک هدف جعل هویت (یک سایت HTTPS واقعی که از TLS 1.3 و HTTP/2 پشتیبانی میکند) انتخاب کنید، و یک پیکربندی سرور JSON بنویسید که به پورت ۴۴۳ متصل شود. کل زمان راهاندازی، پس از انجام یک بار: شاید ده دقیقه. پنلهای وب مانند 3X-UI و Hiddify-Manager همان پیکربندی را در یک رابط مرورگر برای اپراتورهایی که ترجیح میدهند JSON را ویرایش نکنند، قرار میدهند. دستگاههای مدیریتشده نیز وجود دارند. AWS Marketplace یک تصویر سرور VPN Xray VLESS را با قیمت ۰.۰۶۳ دلار در ساعت در t3.micro فهرست میکند، با یک دوره آزمایشی رایگان ۵ روزه.
در سمت کلاینت، اکوسیستم چندپاره اما قابل اعتماد است. v2rayN و Nekoray کلاینتهای غالب ویندوز هستند. v2rayNG، NekoBox و Hiddify اندروید را پوشش میدهند. Hiddify به صورت کراس پلتفرم روی macOS و لینوکس نیز اجرا میشود. در iOS، جایی که سیاست اپ استور اپل کار را سختتر میکند، Streisand گزینه رایگان و Shadowrocket یا V2Box گزینههای پولی هستند. همه آنها با VLESS صحبت میکنند؛ اکثر آنها از REALITY پشتیبانی میکنند. پیکربندی معمولاً از طریق یک طرح URI `vless://`، یک URL واحد حاوی پارامترهای UUID، آدرس، پورت، انتقال و REALITY، یا به صورت کد QR از پنل سمت سرور اسکن میشود.

عملکرد، خطرات و اینکه چه زمانی VLESS ابزار مناسبی نیست
اولویت با عملکرد. معیارهای جامعه، VLESS را تقریباً ۱۵ تا ۲۵ درصد توان عملیاتی بهتر از VMess در انتقال یکسان نشان میدهند، عمدتاً به این دلیل که هدر VLESS بسیار کوتاهتر است و هیچ گذرگاه رمزگذاری داخلی وجود ندارد. با XTLS Vision و بهینهسازی اتصال لینوکس، یک استقرار VLESS که به خوبی تنظیم شده باشد، به توان عملیاتی TCP بومی نزدیک میشود و تنها با پهنای باند VPS و زمان رفت و برگشت به سرور محدود میشود. WireGuard در شبکههای بدون سانسور، جایی که handshake آن مشکلی ایجاد نمیکند، ۲ تا ۳ درصد سریعتر باقی میماند.
خطرات واقعی هستند. پروتکل VLESS خنثی و متنباز است، اما وضعیت قانونی استفاده از آن برای دور زدن سانسور دولتی به شدت بسته به حوزه قضایی متفاوت است. قانون فدرال روسیه در مورد ابزارهای دور زدن سانسور، تبلیغ پیکربندیهای کاری را به جای استفاده شخصی جرم میداند؛ وضعیت نظارتی چین سختگیرانهتر و خودسرانهتر است؛ ایران اپراتورهای مجموعههای بزرگ پروکسی را تحت پیگرد قانونی قرار میدهد. شبکههای شرکتی اغلب تمام ترافیک پروکسی و VPN را به طور کامل ممنوع میکنند. خوانندگان در این محیطها باید قبل از تنظیم هر چیزی، قوانینی را که تحت آن فعالیت میکنند، بدانند. برنامههای VPN رایگان که اشتراکهای VLESS از پیش بارگذاری شده را ارائه میدهند، در برخی حوزههای قضایی متعلق به یک دسته نظارتی جداگانه هستند و ممکن است بررسیهای متفاوتی را به خود جلب کنند.
نکته آخر و کمتر دراماتیک. اگر در یک شبکه سانسور شده نیستید، VLESS بیش از حد نیاز است. برای حفظ حریم خصوصی معمولی از ISP خود در یک لینک پاک، WireGuard یا پیکربندی مدرن OpenVPN سریعتر، سادهتر و توسط هر ارائه دهنده VPN تجاری پشتیبانی میشود. VLESS+REALITY ابزاری برای یک مشکل خاص است و استفاده از آن وقتی مشکل چیز دیگری است، بیشتر پیچیدگی به همراه دارد.