2026 সালের আধুনিক VLESS স্ট্যাক
Contents
2026 সাল পর্যন্ত VLESS একটি হালকা, স্টেটলেস প্রক্সি প্রোটোকল হিসেবেই আছে, তবে “VLESS-এ এনক্রিপশন নেই”—এই কথা এখন আর পূর্ণ বর্ণনা নয়। Xray-core এখন ঐচ্ছিক VLESS Encryption দেয়। ডিপ্লয়মেন্টে নিজেদের হুমকি-মডেল অনুযায়ী VLESS-এর সঙ্গে TLS, REALITY, XTLS Vision, XHTTP ও XUDP মেলানো যায়। এই স্তরগুলো ভিন্ন ভিন্ন সমস্যার সমাধান করে, তাই এগুলোকে একটি প্রোটোকল হিসেবে গুলিয়ে ফেলা ঠিক নয়।
প্রমাণ-নীতি: এই গাইডে Project X, Xray-core, sing-box ও AnyTLS-এর প্রাথমিক উৎস ব্যবহার করা হয়েছে। GitHub-এর পুল রিকোয়েস্ট ও আলোচনায় রক্ষণাবেক্ষণকারীদের নকশা ও বাস্তবায়নের বিবরণ থাকে; সেগুলো স্বাধীন নিরাপত্তা অডিট নয়। SingLink-এর উল্লেখ কেবল আর্কিটেকচারের তুলনা; SingLinkVPN এই প্রকল্পগুলো বাস্তবায়ন করে—এমন দাবি নয়।
1. এক নজরে আধুনিক VLESS স্ট্যাক
- VLESS: পরিচয়, কমান্ড ও গন্তব্য বহনকারী একটি হালকা স্তর।
- VLESS Encryption: বর্তমান Xray-core-এ একটি ঐচ্ছিক নিজস্ব পেলোড-সুরক্ষা স্তর।
- TLS 1.3 / REALITY: বাইরের ট্রান্সপোর্ট নিরাপত্তা, প্রমাণীকরণ ও নেটওয়ার্কে বাহ্যিক চেহারা।
- XTLS Vision: ফ্লো কন্ট্রোল ও ডেটা-পথের অপ্টিমাইজেশন, আলাদা কোনো সাইফার নয়।
- RAW / XHTTP / gRPC / WebSocket: প্রক্সি ডেটা বহন করার ট্রান্সপোর্ট।
- XUDP: Xray ইকোসিস্টেমে UDP প্যাকেট এনকোড করার একটি বিকল্প।
- XMUX ও অন্যান্য MUX ব্যবস্থা: নিচের সংযোগ ভাগাভাগি করে ব্যবহারের উপায়।
- Padding / FinalMask / Browser Dialer: দৈর্ঘ্য, সময়, বাইরের ট্রান্সপোর্টের আচরণ বা ব্রাউজার-নেটওয়ার্কিং নিয়ন্ত্রণের টুল।
তাই একটি সংযোগকে এভাবে ভাবা যায়: অ্যাপ্লিকেশনের ট্রাফিক → VLESS পরিচয় ও গন্তব্য → প্রোটোকল বা বাইরের নিরাপত্তা → Vision ফ্লো কন্ট্রোল → RAW বা XHTTP-এর মতো ট্রান্সপোর্ট → TCP বা UDP। প্রতিটি নকশায় প্রতিটি মডিউল দরকারি বা পরস্পর-সামঞ্জস্যপূর্ণ নয়।
2. মূল VLESS প্রোটোকল কী করে
Project X-এর ডকুমেন্টেশন VLESS-কে একটি হালকা, স্টেটলেস ট্রান্সপোর্ট প্রোটোকল হিসেবে সংজ্ঞায়িত করে, যা সিস্টেমের সময়ের ওপর নির্ভর করে না এবং প্রমাণীকরণের জন্য UUID বা ম্যাপ করা ID ব্যবহার করে। সর্বজনীন Xray-core এনকোডিং বাস্তবায়নে দেখা যায় সংস্করণ, ব্যবহারকারী ID, অ্যাডঅন, কমান্ড, গন্তব্য পোর্ট, ঠিকানা এবং এরপরের ডেটা।
ব্যবহারিক অর্থে মূল স্তরটি উত্তর দেয়: ক্লায়েন্ট কে, কোন সংযোগ চাওয়া হচ্ছে, আর তা কোথায় যাবে? স্মার্ট রাউটিং, নোডের লোড, প্ল্যানের অধিকার ও স্বয়ংক্রিয় পুনঃসংযোগ সাধারণত পণ্য ও নিয়ন্ত্রণের ওপরের স্তরের কাজ।
প্রচলিত কনফিগারেশনে সাধারণত `encryption: "none"` ব্যবহার হয়। Project X-এর বর্তমান নির্দেশনা অনুযায়ী, পিয়ার ও লিংক বিশ্বস্ত প্রাইভেট অবকাঠামো না হলে, কিংবা VLESS Encryption চালু না থাকলে, বাইরের ট্রান্সপোর্ট নিরাপত্তা আবশ্যক।
3. VLESS Encryption কী বদলায়
VLESS Encryption হলো 2025 সালে Xray-core-এ যুক্ত হওয়া একটি ঐচ্ছিক নিজস্ব সুরক্ষা স্তর। মার্জ হওয়া PR #5067 ও বর্তমান কনফিগারেশন ডকুমেন্টেশনে বর্ণনা আছে `mlkem768x25519plus` হ্যান্ডশেক, `native`, `xorpub` ও `random` চেহারা, `1rtt` ও `0rtt` সেশন আচরণ এবং পরিবর্তনশীল প্যাডিংয়ের।
প্রকাশিত নকশার লক্ষ্য
- ML-KEM-768 ও X25519-এর সমন্বয়ে সেশন কী তৈরি করা;
- বাইরের TLS ছাড়াই VLESS পেলোড সুরক্ষিত রাখা;
- পরবর্তী 0-RTT পুনরারম্ভের জন্য টিকিট এবং রিপ্লে-ঝুঁকি কমাতে স্বল্পমেয়াদি স্টেট ব্যবহার করা;
- নির্দিষ্ট দৈর্ঘ্য বা পাবলিক কী-এর চেহারা বদলাতে পরিবর্তনশীল প্যাডিং ও ঐচ্ছিক XOR মোড ব্যবহার করা।
এগুলো রক্ষণাবেক্ষণকারীদের নকশা ও বাস্তবায়ন-সংক্রান্ত দাবি। প্রতিটি বৈশিষ্ট্য যাচাই করেছে এমন কোনো স্বাধীন ক্রিপ্টোগ্রাফিক অডিট আমরা পাইনি, তাই এই গাইড নকশাটিকে “রিপ্লে-প্রতিরোধী” বা “সম্পূর্ণ কোয়ান্টাম-নিরাপদ” বলে না।
যা এটি নিজে থেকে প্রতিস্থাপন করে না
VLESS Encryption প্রোটোকলের পেলোড সুরক্ষিত করে। এটি নিজে থেকে সাধারণ HTTPS সার্টিফিকেট চেইন, ওয়েবসাইটের হ্যান্ডশেক, HTTP/2 বা HTTP/3 আচরণ, কিংবা CDN-এর সঙ্গে সামঞ্জস্য তৈরি করে না। তাই এটি TLS বা REALITY-র সমতুল্য নয়।
4. TLS 1.3 ও REALITY
TLS দেয় মানসম্মত সার্টিফিকেট যাচাই, কী বিনিময়, অখণ্ডতা ও ট্রান্সপোর্ট এনক্রিপশন। এটি RAW, XHTTP, gRPC বা WebSocket-এর সঙ্গে চলতে পারে; তবে কোন সংস্করণ নির্ধারিত হবে, ALPN ও সার্টিফিকেট যাচাই—সবই কনফিগারেশন ও পিয়ারের সমর্থনের ওপর নির্ভর করে।
Project X-এর REALITY ডকুমেন্টেশন একটি পরিবর্তিত 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 হেডার প্যাডিং, আপলোড/ডাউনলোডের আলাদা পথ এবং XMUX-ও ব্যবহার করতে পারে। কোনো নির্দিষ্ট CDN-এর মধ্য দিয়ে এটি কাজ করবে কি না, তা নির্ভর করে মোড, HTTP সংস্করণ, রিভার্স-প্রক্সির আচরণ ও প্রোভাইডারের কনফিগারেশনের ওপর।
7. XMUX, সাধারণ মাল্টিপ্লেক্সিং ও হেড-অফ-লাইন ব্লকিং
XMUX পরিচালনা করে XHTTP-এর সমান্তরালতা, নিচের সংযোগের সংখ্যা, পুনর্ব্যবহার, আয়ুষ্কাল ও keepalive। এর লক্ষ্য চিরকাল ঠিক একটি সংযোগ ধরে রাখা নয়; এটি হ্যান্ডশেকের খরচ, সমান্তরালতা ও দীর্ঘস্থায়ী সংযোগের ধরনের মধ্যে ভারসাম্য রাখে।
sing-box মাল্টিপ্লেক্স ডকুমেন্টেশনে smux, yamux ও h2mux-এর কথাও আছে। মাল্টিপ্লেক্সিং হ্যান্ডশেক কমাতে পারে, তবে নিচের একটি TCP সংযোগে প্যাকেট হারানো বা আটকে যাওয়া একাধিক স্ট্রিমকে প্রভাবিত করতে পারে। HTTP/3 TCP পর্যায়ের আন্তঃস্ট্রিম হেড-অফ-লাইন ব্লকিং এড়ায়, তবে একটি নির্দিষ্ট QUIC স্ট্রিমকে তবুও হারানো প্যাকেট পুনরুদ্ধারের জন্য অপেক্ষা করতে হতে পারে।
8. XUDP হলো UDP এনকোডিংয়ের একটি বিকল্প
sing-box-এর VLESS ডকুমেন্টেশনে `xudp`-কে প্যাকেট-এনকোডিংয়ের একটি বিকল্প হিসেবে তালিকাভুক্ত করা হয়েছে, `packetaddr` ও বাড়তি এনকোডিং বন্ধ রাখার বিকল্পের পাশাপাশি। এ থেকে সীমিত এই সিদ্ধান্তে আসা যায় যে এই ইকোসিস্টেমে XUDP UDP বহন করে; এটি কোনো পূর্ণাঙ্গ, সংস্করণভিত্তিক প্যাকেট স্পেসিফিকেশন নয়।
সেশন, ঠিকানা, সীমানা ও মাইগ্রেশনের বিস্তারিত আচরণ নির্দিষ্ট কোর সংস্করণ ও কোডের সঙ্গে মিলিয়ে যাচাই করা উচিত। অনুমাননির্ভর ফ্রেমিংয়ের খুঁটিনাটিকে সর্বজনীন মানদণ্ড হিসেবে উপস্থাপন করা থেকে এই গাইড ইচ্ছাকৃতভাবে বিরত থেকেছে।
9. Padding, FinalMask, ECH ও Browser Dialer
- Padding: দৈর্ঘ্য বা সময়ের বৈশিষ্ট্য বদলায়; এটি এনক্রিপশন নয়।
- FinalMask: এর কনফিগারেশন ডকুমেন্টেশন একে বাইরের ট্রান্সপোর্ট-প্রক্রিয়াকরণের ধাপে রাখে, TCP, UDP ও QUIC-সম্পর্কিত সেটিংসহ।
- ECH: sing-box-এর TLS ডকুমেন্টেশনে ClientHello-র একাংশ সুরক্ষিত রাখতে Encrypted ClientHello কনফিগারেশন আছে; ECH টানেল এনক্রিপশনের বিকল্প নয়।
- Browser Dialer: Project X-এর ডকুমেন্টেশন অনুযায়ী এটি একটি আসল ব্রাউজারকে দিয়ে TLS ও HTTP সংযোগ তৈরি করায়, ফলে ব্রাউজারের আচরণ বেশি খাঁটি হয়, তবে ডিপ্লয়মেন্ট ও পারফরম্যান্সে সীমাবদ্ধতা আসে।
10. Fallback কী পারে আর কী পারে না
Project X-এর Fallback ডকুমেন্টেশন দেখায়, কীভাবে মেলে না এমন SNI, পাথ বা প্রোটোকল ট্রাফিককে Nginx, Caddy বা সাধারণ ওয়েবসাইটে পাঠানো যায়, যাতে একটি প্রবেশপথেই প্রক্সি ও সাধারণ সেবা দুটোই চালানো যায়।
Fallback প্রতিটি ব্যর্থ প্রমাণীকরণের জবাবে একই স্পষ্ট ত্রুটি দেখানো এড়াতে পারে। তবে এটি সক্রিয় প্রোবিং থেকে সুরক্ষার নিশ্চয়তা নয়; চেনা যাবে কি না, তা তবুও TLS, ট্রান্সপোর্ট, রেসপন্স, সময় ও সার্ভারের কনফিগারেশনের ওপর নির্ভর করে।
11. AnyTLS একটি তুলনা, VLESS-এর অংশ নয়
AnyTLS প্রোটোকল ডকুমেন্ট এই ক্রম বর্ণনা করে: TCP → TLS → `SHA-256(password)` প্রমাণীকরণ → একটি সেশন → একাধিক স্ট্রিম। ফ্রেমে থাকে Command, Stream ID, Data Length ও Data, আর কমান্ডগুলো হলো SYN, PSH, FIN, settings, padding, heartbeat এবং সংস্করণ 2-এর SYNACK।
এর সেশন মডেল, একাধিক স্ট্রিম, ডায়নামিক প্যাডিং ও হেলথ চেক তুলনার জন্য কাজে লাগে। তবে AnyTLS একটি আলাদা প্রোটোকলই থাকে; VLESS এই বৈশিষ্ট্যগুলো নিজে থেকে পায় না।
12. প্রচলিত সমন্বয় ও তাদের সীমাবদ্ধতা
- VLESS + REALITY + Vision + RAW: সরাসরি পারফরম্যান্স ও TLS-ধাঁচের বাইরের চেহারার দিকে মনোযোগ; CDN-এর ওপর নির্ভরতা নেই।
- VLESS + TLS/REALITY + XHTTP: HTTP-র মাধ্যমে বহন, রিভার্স প্রক্সি এবং শর্তসাপেক্ষ CDN সামঞ্জস্যের দিকে মনোযোগ।
- VLESS Encryption + Vision: রিলে বা অপ্রচলিত বাইরের নিরাপত্তার পরিস্থিতিতে প্রোটোকলের পেলোড সুরক্ষিত রাখে, সাধারণ HTTPS চেহারা ছাড়াই।
- VLESS + TLS + XHTTP + Browser Dialer: আসল ব্রাউজারের নেটওয়ার্ক স্ট্যাক ব্যবহার করে, তবে পরিচালনার খরচ বেশি।
- AnyTLS + TLS: আলাদা সেশন/স্ট্রিম ও প্যাডিং নকশা, কোনো VLESS স্ট্যাক নয়।
পারফরম্যান্স, সামঞ্জস্য, রক্ষণাবেক্ষণযোগ্যতা, চেহারা ও নিরাপত্তা—সব দিক থেকে একসঙ্গে সবসময় সেরা, এমন কোনো কনফিগারেশন নেই। বাছাই শুরু করা উচিত হুমকি-মডেল, নেটওয়ার্ক পথ, CDN বা প্রক্সির সীমাবদ্ধতা, ক্লায়েন্ট প্ল্যাটফর্ম এবং পর্যবেক্ষণের প্রয়োজন দিয়ে।
13. SingLink-এর গবেষণার জন্য এর অর্থ
VLESS ও AnyTLS-এর সর্বজনীন উপকরণ পরিচয়, কী বিনিময়, সেশন, স্ট্রিম, UDP, প্যাডিং, মাল্টিপ্লেক্সিং, পুনরুদ্ধার ও সংস্করণ-আলোচনা নিয়ে গবেষণায় সহায়ক হতে পারে। তবে এই লেখা প্রমাণ করে না যে SingLink 2.0 VLESS, REALITY, XHTTP বা AnyTLS-এর ওপর ভিত্তি করে তৈরি।
SingLinkVPN-এর উচিত প্রকাশিত আচরণ, গবেষণার দিক ও অপ্রকাশিত বাস্তবায়নকে আলাদা রাখা অব্যাহত রাখা। বর্তমানে প্রকাশিত পরিসর জানতে দেখুন SingLinkVPN ওপেন-সোর্স পরিকল্পনা।
14. সচরাচর জিজ্ঞাসিত প্রশ্ন (FAQ)
VLESS কি নিজে থেকে ট্রাফিক এনক্রিপ্ট করে?
VLESS নিজে থেকে এনক্রিপ্ট করবে কি না, তা বাস্তবায়ন ও কনফিগারেশনের ওপর নির্ভর করে। প্রচলিত `encryption: "none"` প্রোটোকলের পেলোড সুরক্ষিত করে না, তাই এর জন্য বিশ্বস্ত প্রাইভেট অবকাঠামো বা বাইরের নিরাপত্তা দরকার। বর্তমান Xray-core-এ VLESS Encryption চালু করা যায়।
VLESS Encryption কি TLS বা REALITY-র জায়গা নিতে পারে?
না, VLESS Encryption TLS বা REALITY-র সমতুল্য বিকল্প নয়। এটি VLESS পেলোড সুরক্ষিত রাখে, কিন্তু নিজে থেকে মানসম্মত HTTPS সার্টিফিকেট, হ্যান্ডশেক বা ওয়েবসাইটের মতো চেহারা দেয় না।
XTLS Vision কি এনক্রিপশন করে?
না, XTLS Vision এনক্রিপশন করে না। Vision মূলত ফ্লো কন্ট্রোল ও ডেটা-পথের অপ্টিমাইজেশন দেয়।
XHTTP-এর তিনটি মোডের মধ্যে কীভাবে বাছাই করবেন?
XHTTP মোড বাছাই নির্ভর করে আপনার মধ্যবর্তী পথের ওপর: packet-up সামঞ্জস্যে জোর দেয়, stream-up দুই দিকের স্ট্রিমিং আলাদা রাখে, আর stream-one একটিমাত্র দ্বিমুখী স্ট্রিম ব্যবহার করে। প্রতিটিকে আসল মধ্যবর্তী পথে পরীক্ষা করে দেখতে হবে।
XUDP সাধারণ UDP প্রক্সি থেকে কীভাবে আলাদা?
XUDP হলো Xray ইকোসিস্টেমে UDP এনকোডিংয়ের একটি বিকল্প। এর সঠিক আচরণ কোর ও সংস্করণের ওপর নির্ভর করে; শুধু নাম দেখে তা অনুমান করা উচিত নয়।
SingLink 2.0 কি VLESS বা AnyTLS-এর ওপর ভিত্তি করে তৈরি?
SingLink-এর এই দ্বিতীয় প্রজন্মের প্রোটোকল আর VLESS বা AnyTLS-এর মধ্যে এমন সম্পর্ক প্রতিষ্ঠার মতো যথেষ্ট সর্বজনীন প্রমাণ নেই। এই লেখা একটি প্রযুক্তিগত তুলনা, বাস্তবায়নের প্রকাশ নয়।
15. উপসংহার ও উৎসের তারিখ
আধুনিক VLESS একটি জোড়া লাগানো যায় এমন স্ট্যাক: VLESS বহন করে পরিচয় ও গন্তব্য, VLESS Encryption যোগ করে ঐচ্ছিক প্রোটোকল-স্তরের সুরক্ষা, TLS বা REALITY দেয় বাইরের নিরাপত্তা, Vision ফ্লো অপ্টিমাইজ করে, XHTTP ও XUDP ট্রাফিক বহন করে, আর মাল্টিপ্লেক্সিং বা প্যাডিং সংযোগের আচরণ আরও বদলে দেয়।
মূল প্রকাশের তারিখ: 20 মে 2026। প্রযুক্তিগত উৎস পর্যালোচনা: 28 জুলাই 2026। এই প্রকল্পগুলো বদলাতে থাকে; ডিপ্লয় করার আগে নির্দিষ্ট সংস্করণের ডকুমেন্টেশন, পরিবর্তন লগ ও সামঞ্জস্য যাচাই করে নিন।
