Protokół VLESS: V2Ray VPN, serwer Xray i przewodnik po omijaniu cenzury
Około pół dekady po pojawieniu się w mało znanym repozytorium inkubacyjnym GitHub, VLESS po cichu stał się domyślnym protokołem proxy, z których korzystają mieszkańcy Rosji, Iranu i Chin. Powody są mało romantyczne. Jest niewielki. Sam niczego nie szyfruje. Jest to również jedyny powszechnie wdrożony protokół, którego największe państwowe systemy głębokiej inspekcji pakietów (DPI) nie zdołały jeszcze ostatecznie pokonać (stan na połowę 2026 roku).
Ten przewodnik wyjaśnia, czym jest VLESS jako lekki protokół, jak działa wewnętrznie, co na nim działa (Xray, XTLS, REALITY), jak wypada w porównaniu z VMess, Trojan, Shadowsocks, WireGuard i tradycyjnymi protokołami VPN, takimi jak OpenVPN, oraz jak wygląda w praktyce konfiguracja VLESS VPN. Jest to techniczne wyjaśnienie, a nie przewodnik po konfiguracji. Jeśli po jego ukończeniu nadal chcesz kopiować i wklejać polecenia serwera, dokumentacja projektu na stronie xtls.github.io będzie właściwym kolejnym krokiem.
Czym jest VLESS i dlaczego społeczność V2Ray go stworzyła
VLESS, skrót od „VMess Less”, to bezstanowy, lekki protokół proxy wprowadzony w 2020 roku przez dewelopera znanego jako RPRX, który od 2019 roku utrzymywał repozytorium inkubacyjne w RPRX/v2ray-vless. Został on zaprojektowany jako celowa redukcja VMess, pierwotnego protokołu V2Ray, który pod koniec lat 2010. stał się nieporęczny ze względu na własne mechanizmy szyfrowania, ochrony przed powtórzeniami i synchronizacji zegara.
Obecnie VLESS funkcjonuje głównie w dwóch bazach kodu. Oryginalne repozytorium v2fly/v2ray-core utrzymuje go ze względu na kompatybilność. Fork XTLS/Xray-core, również utrzymywany przez RPRX, jest aktywniej rozwijaną implementacją: 38 600 gwiazdek w serwisie GitHub i około 5400 forków w maju 2026 roku, w porównaniu z 33 900 gwiazdkami w v2fly/v2ray-core. Xray dostarcza istotne funkcje, a mianowicie kontrolę przepływu XTLS Vision i transport REALITY, których nie oferuje upstream v2fly.
Jak działa protokół VLESS: UUID, brak szyfrowania, TLS zewnętrzny
Protokół przewodowy VLESS jest na tyle krótki, że można go opisać w jednym akapicie. Klient nawiązuje połączenie. Wysyła nagłówek. Nagłówek zawiera bajt wersji, 16-bajtowy identyfikator UUID użytkownika, wskaźnik długości pola opcjonalnych dodatków, same dodatki, jednobajtowe polecenie (TCP lub UDP), port docelowy, bajt typu adresu oraz adres. To daje od 25 do 50 bajtów na połączenie. OpenVPN obsługuje ponad 100 bajtów na pakiet.
Nagłówek nie jest w żaden sposób szyfrowany przez sam protokół VLESS. Protokół wyraźnie wymaga `encryption: "none"` w konfiguracji JSON, a dokumentacja v2fly stwierdza, że to pole nie może być puste — należy powiedzieć `none'' na głos, aby operatorzy pamiętali, że protokół deleguje całą poufność do transportu znajdującego się pod spodem. W praktyce transport ten to prawie zawsze TLS 1.3.
Ten wybór konstrukcyjny jest źródłem wszystkich interesujących właściwości VLESS. Nie uruchamiając własnej warstwy szyfrowania, VLESS unika trybu awarii, który skazał VMess na porażkę w sieciach z cenzurą. Druga warstwa szyfrowania wewnątrz zewnętrznego tunelu TLS generuje to, co badacze analizy ruchu nazywają wzorcami „TLS-in-TLS”. Systemy DPI stanu, wytrenowane w wykrywaniu dokładnie takiego podwójnego zawinięcia, były głównym powodem, dla którego wskaźniki wykrywania VMess przekroczyły 80% na chińskiej zaporze sieciowej do września 2025 roku. VLESS, przenosząc jedynie blob uwierzytelniania i metadane routingu, jest znacznie bardziej zbliżony do pojedynczej, zwykłej konwersacji TLS, co uniemożliwia odcisk palca protokołu, na którym opierają się systemy głębokiej inspekcji pakietów.
Drugim celowym pominięciem jest stanowość. VMess opiera się na zsynchronizowanych zegarach między klientem a serwerem, a znaczniki czasu pakietów służą do zapobiegania atakom typu replay. Rezultatem były lata mylących awarii połączeń, gdy zegar telefonu się przesunął, laptop się uruchomił na dwóch komputerach lub serwer znajdował się w niewłaściwej strefie czasowej. VLESS jest bezstanowy. Identyfikator UUID stanowi całą historię uwierzytelniania. Jeśli UUID jest zgodny, połączenie jest autoryzowane; jeśli nie, jest odrzucane na pierwszym bajcie. Nic nie zależy od czasu.
Identyfikatory UUID w VLESS to standardowe identyfikatory RFC-4122. Generuje je polecenie `xray uuid`; działa również dowolny standardowy generator UUID. Akceptowane są niestandardowe ciągi znaków o długości do 30 bajtów, które są mapowane na identyfikatory UUID zgodnie z tym, co w dokumentacji nazywa się „Standardem mapowania UUID VLESS”. Większość konfiguracji korzysta z kanonicznych identyfikatorów UUID, ponieważ mapowanie niczego nie zmienia w praktyce.
Opcje transportu leżą u podstaw protokołu: obsługiwane są TCP (z TLS lub bez), mKCP, WebSocket, gRPC i QUIC. Każda z nich kształtuje ruch w inny sposób. WebSocket pozwala VLESS ukryć się za standardowym uzgadnianiem aktualizacji HTTP/1.1 i kierować ruch przez sieci CDN, takie jak Cloudflare. gRPC korzysta z multipleksowania HTTP/2. QUIC przenosi wszystko w zewnętrznej sesji TLS 1.3 opartej na UDP. Protokół nie ma znaczenia, na jakim transporcie działa. To właśnie ta separacja sprawia, że jest przenośny.
Xray, REALITY i XTLS: stos, na którym faktycznie działa VLESS
W praktyce nikt nie korzysta z VLESS bez nadzoru. Interesujące są elementy, które działają dookoła.
Xray-core to dominujące środowisko uruchomieniowe. Jest to rozwidlenie V2Ray-core, zapoczątkowane przez RPRX i współtwórców XTLS po rozłamie w społeczności. Zawiera dwie technologie, od których VLESS zależy w przypadku poważnych działań związanych z omijaniem cenzury: XTLS Vision i REALITY.
XTLS Vision (określony jako `flow: "xtls-rprx-vision" w konfiguracji) to schemat uzupełniania stosowany do ruchu TLS 1.3. Problem, który rozwiązuje, jest subtelny. Rekordy TLS 1.3 mają przewidywalne sygnatury długości, gdy zawierają wewnętrzne dane aplikacji o ustalonym kształcie — długości te ujawniają informacje o tym, co jest tunelowane. Vision dodaje bajty uzupełniania na wczesnym etapie uzgadniania. Po nawiązaniu połączenia przełącza się na kopiowanie surowych gniazd. W systemie Linux używa wywołania systemowego `splice()` do przekazywania pakietów TCP w jądrze bez kopiowania przez przestrzeń użytkownika. Rezultatem jest przepustowość zbliżona do tej, jaką zapewniłoby połączenie TCP bez proxy, z wyrównanym wyciekiem sygnatury długości.
REALITY, wydany w 2023 roku i utrzymywany na github.com/XTLS/REALITY, jest bardziej radykalny. Standardowy serwer VLESS+TLS prezentuje własny certyfikat TLS, co oznacza, że posiada domenę, uruchamia gdzieś Certbota i ujawnia odcisk palca certyfikatu, który system DPI może powiązać z użyciem serwera proxy. REALITY odrzuca cały ten pomysł. Zamiast uruchamiać własny TLS, serwer podszywa się pod prawdziwą witrynę internetową innej firmy. Operator wybiera cel: `microsoft.com`, `apple.com`, dowolną domenę. Serwer wykorzystuje podrabianie SNI i wymianę kluczy X25519. Klienci znający poprawny klucz publiczny REALITY przeprowadzają prawdziwą uzgadnianie TLS 1.3 z podrobionym łańcuchem certyfikatów, dokładnie tak, jak przeglądarka nawiązałaby uzgadnianie z prawdziwym serwerem WWW, a następnie są kierowani do tunelu VLESS. Klienci, którzy tego nie robią, w tym badający systemy DPI, widzą coś, co wygląda na normalne połączenie z podszywającą się witryną, łącznie z prawdziwym certyfikatem.
Połączenie protokołu wewnętrznego VLESS, XTLS Vision do spłaszczania podpisów długości i REALITY do maskowania uścisku dłoni to właśnie to, co ludzie mają na myśli, mówiąc „VLESS+REALITY” lub „VLESS+Vision+REALITY”. Jest to konfiguracja, która w połowie 2026 roku nadal działała w środowiskach, w których prawie nic innego nie działało.
VLESS kontra VMess kontra Trojan kontra Shadowsocks kontra WireGuard
Przestrzeń protokołu wokół VLESS jest niewielka, a różnice mają znaczenie. Krótsza wersja znajduje się poniżej; dłuższa wersja to tabela.
VMess to poprzednik VLESS. Oferuje własne szyfrowanie AEAD, ochronę przed powtórzeniami i warianty oparte na alterId. W sieciach bez cenzury te funkcje kosztują kilka procent przepustowości i nie przynoszą żadnych korzyści. W sieciach z cenzurą wzorzec szyfrowania wewnątrz TLS jest wykrywalny, a telemetria GFW wskazuje na jego wykrywalność na poziomie ~80% od września 2025 roku.
Trojan to siostrzany projekt innego zespołu. Jest jeszcze prostszy niż VLESS: hasło zamiast UUID, brak pola dodatków, TLS na zewnątrz. Przez lata ten minimalizm zapewniał mu siłę; aktualizacja GFW w sierpniu 2025 roku to zmieniła, a trojan osiąga teraz około 90% wykrywalności.
Shadowsocks wywodzi się z zupełnie innej rodziny. Jest to symetryczny szyfr AEAD bez fasady TLS, zaprojektowany tak, aby wyglądał jak losowe bajty, a nie jak HTTPS. To podejście działało, dopóki GFW nie zaczął domyślnie oznaczać w pełni zaszyfrowanego ruchu jako podejrzanego; współczesne wdrożenia Shadowsocks opierają się na wtyczkach transportowych (v2ray-plugin, cloak), które opakowują szyfr w TLS lub HTTP, skutecznie odbudowując architekturę VLESS z drugiej strony.
WireGuard należy do zupełnie innej dyskusji. To protokół VPN na poziomie jądra, a nie protokół proxy. W czystej sieci jest o ~2–3 procent szybszy niż VLESS+XTLS przy surowej przepustowości, przy znacznie mniejszym obciążeniu procesora i pozostaje właściwym rozwiązaniem w typowych przypadkach użycia prywatności od dostawcy usług internetowych. W sieciach cenzurowanych jego stały bajt uzgadniania 0x01 jest trywialnie odciskany, a efektywna przepustowość spada niemal do zera.
| Protokół | Rodzina | Warstwa zewnętrzna | Odporność na DPI | Najlepszy dla |
|---|---|---|---|---|
| MNIEJ+RZECZYWISTOŚCI | Serwer proxy V2Ray/Xray | Podszywający się pod TLS 1.3 | Wysoki (≤5% wykrycia w raportach terenowych) | Wrogie sieci |
| VMess | Serwer proxy V2Ray | Samoszyfrowanie w protokole TLS | Niski (~80% GFW) | Tylko zgodność ze starszymi wersjami |
| trojański | Serwer proxy obsługujący TLS | TLS będące własnością własną | Niski (~90% GFW po sierpniu 2025 r.) | Prostsze samodzielne hostowanie |
| Skarpety Cienia (AEAD) | Symetryczne zaciemnianie | Losowe bajty / wtyczka TLS | Mieszane (zależy od wtyczki) | Użytkownicy urządzeń mobilnych korzystający z niestabilnych łączy |
| WireGuard | Kernel VPN | Uzgadnianie UDP + Noise | Bardzo niski (wykrywalny przez DPI) | Czysta prywatność i szybkość sieci |
VLESS, cenzura i blokada rosyjskiego DPI
VLESS byłby jedynie przypisem w historii oprogramowania proxy, gdyby nie fakt, że omija cenzurę w Rosji i podobnych systemach skuteczniej niż jakikolwiek inny powszechnie stosowany protokół. Od 2024 roku największe państwowe systemy DPI na świecie aktywnie próbują go unicestwić. Od tego czasu historia ta to powolna, publiczna gra eskalacji.
W Rosji, Roskomnadzor zgłosił zablokowanie 439 usług VPN do stycznia 2026 roku. Federalny budżet na blokowanie VPN wynosi około 60 miliardów rubli (około 780 milionów dolarów) na lata 2025–2027, a kolejne 2,27 miliarda rubli (około 29 milionów dolarów) przeznaczono specjalnie na filtrowanie ruchu oparte na sztucznej inteligencji, zgodnie z raportem zona.media z kwietnia 2026 roku. 17 lutego 2026 roku Roskomnadzor ponownie zaostrzył swoją działalność, gwałtownie zwiększając liczbę blokad skierowanych konkretnie na VLESS-over-TCP-with-TLS, co udokumentowali Mezha i digirpt. Użytkownicy przeszli na transporty REALITY, gRPC i CDN w ciągu kilku godzin. Zgłoszony wskaźnik obejścia sieci przez VLESS+REALITY w porównaniu z rosyjskim DPI wyniósł blisko 99,5% w trakcie tej fali, co należy traktować jako wartość kierunkową, a nie mierzalną.
W Chinach, w 2025 roku, Wielka Zapora Sieciowa przeszła przez podobną sekwencję zdarzeń. W sierpniu liczba wykrytych trojanów spadła do około 90%, a w przypadku VMess do około 80% we wrześniu. Odrębne zdarzenie związane z cyberbezpieczeństwem we wrześniu 2025 roku, wyciek 600 GB danych od chińskiego dostawcy GFW, o którym donosi Cybernews, ujawnił części wewnętrznej infrastruktury klasyfikacji, ale samo w sobie nie wpłynęło na ekonomikę wdrożenia. Testy społecznościowe na greatfirewallguide.com wykazały 98-procentowy wskaźnik obejścia dla VLESS+REALITY+Vision na początku 2026 roku.
W Iranie IRGFW MCI umieszcza adresy IP REALITY na szarej liście co najmniej od kwietnia 2024 r., co zostało udokumentowane w dyskusji XTLS/Xray-core nr 3269. Operatorzy zgłaszają, że adres IP przenoszący około 100 GB ruchu REALITY jest zazwyczaj blokowany przez Irancell w ciągu 48 godzin, dlatego rotacja serwerów i frontowanie CDN stały się tam standardową praktyką.
Jak wygląda konfiguracja sieci VPN VLESS: serwer, klienci, konfiguracje
Działające wdrożenie VLESS składa się z trzech części: serwera w jakimś miejscu, klienta na każdym urządzeniu oraz ciągu połączenia, który je łączy.
Strona serwerowa jest mało wymagająca. Wystarczy dowolny tani VPS: Hetzner, Vultr, OVH, dowolny z publicznym IPv4. Zainstaluj Xray-core z plików binarnych wydania projektu lub menedżera pakietów, wygeneruj UUID (`xray uuid`), wygeneruj parę kluczy X25519 dla REALITY (`xray x25519`), wybierz cel personifikacji (prawdziwą witrynę HTTPS obsługującą TLS 1.3 i HTTP/2) i napisz konfigurację serwera JSON, która wiąże się z portem 443. Całkowity czas konfiguracji, po jej jednorazowym wykonaniu: około dziesięciu minut. Panele internetowe, takie jak 3X-UI i Hiddify-Manager, zawierają tę samą konfigurację w interfejsie przeglądarki dla operatorów, którzy nie chcą edytować pliku JSON. Istnieją również zarządzane urządzenia. W AWS Marketplace dostępny jest obraz serwera VPN Xray VLESS w cenie 0,063 USD za godzinę na platformie t3.micro, z 5-dniowym bezpłatnym okresem próbnym.
Po stronie klienta ekosystem jest rozdrobniony, ale niezawodny. v2rayN i Nekoray to dominujące klienty dla systemu Windows. v2rayNG, NekoBox i Hiddify działają na Androidzie. Hiddify działa również wieloplatformowo na macOS i Linuksie. Na iOS, gdzie polityka App Store firmy Apple utrudnia życie, Streisand jest opcją darmową, a Shadowrocket lub V2Box płatnymi. Wszystkie obsługują VLESS; większość obsługuje REALITY. Konfiguracja jest zazwyczaj importowana za pomocą schematu URI `vless://`, pojedynczego adresu URL zawierającego UUID, adres, port, transport i parametry REALITY, lub skanowana jako kod QR z panelu po stronie serwera.
Wydajność, ryzyko i kiedy VLESS nie jest właściwym narzędziem
Wydajność przede wszystkim. Testy porównawcze społeczności wskazują, że VLESS oferuje o około 15–25% lepszą przepustowość niż VMess na tym samym transporcie, głównie dzięki znacznie krótszemu nagłówkowi VLESS i brakowi wewnętrznego szyfrowania. Dzięki XTLS Vision i optymalizacji połączeń linuksowych, dobrze dostrojone wdrożenie VLESS zbliża się do natywnej przepustowości TCP, ograniczonej jedynie przepustowością VPS i czasem transmisji danych do serwera. WireGuard pozostaje o 2–3% szybszy w sieciach bez cenzury, gdzie jego uzgadnianie nie stanowi problemu.
Ryzyko jest realne. Protokół VLESS jest neutralny i udostępniany jako oprogramowanie open source, ale status prawny jego wykorzystania do omijania cenzury państwowej różni się znacznie w zależności od jurysdykcji. Rosyjska ustawa federalna o narzędziach do obchodzenia zabezpieczeń kryminalizuje promowanie działających konfiguracji zamiast użytku osobistego; chińskie przepisy są bardziej surowe i arbitralne; Iran ściga operatorów dużych pul serwerów proxy. Sieci korporacyjne często całkowicie blokują wszelki ruch proxy i VPN. Użytkownicy w takich środowiskach powinni znać przepisy, na których działają, zanim cokolwiek skonfigurują. Darmowe aplikacje VPN z preinstalowanymi subskrypcjami VLESS należą do odrębnej kategorii regulacyjnej w niektórych jurysdykcjach i mogą podlegać innej kontroli.
Ostatnia, mniej dramatyczna uwaga. Jeśli nie korzystasz z cenzurowanej sieci, VLESS to przesada. Aby zapewnić zwykłą prywatność od dostawcy usług internetowych na czystym łączu, WireGuard lub nowoczesna konfiguracja OpenVPN są szybsze, prostsze i obsługiwane przez każdego komercyjnego dostawcę VPN. VLESS+REALITY to narzędzie do rozwiązania konkretnego problemu, a sięganie po nie, gdy problem dotyczy czegoś innego, zazwyczaj wiąże się z większymi komplikacjami.
