Protocollo VLESS: Guida a V2Ray VPN, server Xray e aggiramento della censura
A circa cinque anni dalla sua comparsa in un oscuro repository di incubazione su GitHub, VLESS è diventato silenziosamente il protocollo predefinito alla base dei proxy effettivamente utilizzati in Russia, Iran e Cina. I motivi sono tutt'altro che romantici. È piccolo. Non crittografa nulla direttamente. Ed è anche l'unico protocollo ampiamente diffuso che i più grandi sistemi di ispezione approfondita dei pacchetti (DPI) gestiti dallo Stato non sono ancora riusciti a superare in modo decisivo a metà del 2026.
Questa guida spiega cos'è VLESS come protocollo leggero, come funziona internamente, cosa gira sopra di esso (Xray, XTLS, REALITY), come si confronta con VMess, Trojan, Shadowsocks, WireGuard e i protocolli VPN tradizionali come OpenVPN, e come si presenta una vera configurazione VPN VLESS nella pratica. Si tratta di una spiegazione tecnica, non di una guida alla configurazione. Se dopo averla letta desiderate comunque copiare e incollare i comandi del server, la documentazione del progetto su xtls.github.io è il passo successivo giusto.
Cos'è VLESS e perché la community di V2Ray lo ha creato
VLESS, abbreviazione di "VMess Less", è un protocollo proxy leggero e senza stato introdotto nel 2020 dallo sviluppatore noto come RPRX, che dal 2019 gestiva un repository di incubazione all'indirizzo RPRX/v2ray-vless. È stato progettato come una semplificazione deliberata di VMess, il protocollo V2Ray originale, che alla fine degli anni 2010 era diventato ingestibile a causa dei suoi meccanismi di crittografia, protezione dalla riproduzione e sincronizzazione dell'orologio.
Oggi VLESS è presente principalmente in due codebase. Il repository originale v2fly/v2ray-core lo ospita per motivi di compatibilità. Il fork XTLS/Xray-core, anch'esso gestito da RPRX, è l'implementazione più attivamente sviluppata: 38.600 stelle su GitHub e circa 5.400 fork a maggio 2026, contro le 33.900 stelle di v2fly/v2ray-core. Xray include le funzionalità più importanti, ovvero il controllo del flusso XTLS Vision e il trasporto REALITY, che v2fly upstream non offre.
Come funziona il protocollo VLESS: UUID, nessuna crittografia, TLS esterno
Il protocollo di rete VLESS è abbastanza breve da poter essere descritto in un paragrafo. Un client apre una connessione e invia un'intestazione. L'intestazione contiene un byte che indica la versione, un UUID di 16 byte per l'utente, un indicatore di lunghezza per il campo opzionale dei componenti aggiuntivi, i componenti aggiuntivi stessi, un comando di un byte (TCP o UDP), la porta di destinazione, un byte che indica il tipo di indirizzo e l'indirizzo. Questo si traduce in 25-50 byte per connessione. OpenVPN, invece, utilizza oltre 100 byte per pacchetto.
L'intestazione non viene crittografata in alcun modo da VLESS stesso. Il protocollo richiede esplicitamente `encryption: "none"` nella sua configurazione JSON e la documentazione di v2fly afferma che questo campo non può essere lasciato vuoto: deve contenere "none" per esteso, in modo che gli operatori vengano informati che il protocollo delega tutta la riservatezza al mezzo di trasporto sottostante. In pratica, tale mezzo di trasporto è quasi sempre TLS 1.3.
Questa scelta progettuale è all'origine di tutte le interessanti caratteristiche di VLESS. Non eseguendo un proprio livello di crittografia, VLESS evita la modalità di errore che ha condannato VMess nelle reti censurate. Un secondo livello di crittografia all'interno di un tunnel TLS esterno produce ciò che i ricercatori di analisi del traffico chiamano pattern "TLS-in-TLS". I sistemi DPI statali addestrati a individuare esattamente questa struttura a doppio avvolgimento sono stati il motivo principale per cui i tassi di rilevamento di VMess hanno superato l'80% sul Great Firewall cinese entro settembre 2025. VLESS, trasportando solo un blob di autenticazione e metadati di routing, appare molto più simile a una singola, normale conversazione TLS, il che vanifica il tipo di fingerprinting del protocollo su cui si basano i sistemi di ispezione approfondita dei pacchetti.
L'altra omissione intenzionale è la gestione dello stato. VLESS si basa su orologi sincronizzati tra client e server, con timestamp dei pacchetti utilizzati per prevenire attacchi di replay. Il risultato sono stati anni di errori di connessione confusi ogni volta che l'orologio di un telefono si spostava, un laptop aveva un sistema dual-boot o un server si trovava in un fuso orario errato. VLESS è senza stato. L'UUID è l'unica informazione di autenticazione. Se l'UUID corrisponde, la connessione è autorizzata; in caso contrario, viene rifiutata al primo byte. Nulla dipende dal tempo.
Gli UUID in VLESS sono identificatori standard RFC-4122. Il comando `xray uuid` li genera; qualsiasi generatore di UUID standard funziona altrettanto bene. Sono accettate stringhe personalizzate fino a 30 byte, che vengono mappate agli UUID tramite quello che la documentazione definisce "Standard di mappatura UUID VLESS". Nella maggior parte dei casi, le configurazioni utilizzano gli UUID canonici perché la mappatura non cambia nulla nella pratica.
Le opzioni di trasporto sono alla base del protocollo: TCP (con o senza TLS), mKCP, WebSocket, gRPC e QUIC sono tutti supportati. Ognuno di essi modella il traffico in modo diverso. WebSocket consente a VLESS di nascondersi dietro un normale handshake di aggiornamento HTTP/1.1 e di instradare il traffico attraverso CDN come Cloudflare. gRPC si basa sul multiplexing HTTP/2. QUIC trasporta tutto all'interno di una sessione TLS 1.3 esterna basata su UDP. Il protocollo non fa distinzione tra i diversi protocolli di trasporto utilizzati. Questa separazione è ciò che lo rende portatile.
Xray, REALITY e XTLS: lo stack su cui VLESS gira realmente
In pratica, nessuno utilizza VLESS senza protezione. Le parti interessanti sono quelle che lo circondano.
Xray-core è il runtime dominante. Si tratta di un fork di V2Ray-core, avviato da RPRX e dai collaboratori di XTLS dopo una scissione della comunità, e include due tecnologie su cui VLESS fa affidamento per un serio lavoro di elusione della censura: XTLS Vision e REALITY.
XTLS Vision (specificato come `flow: "xtls-rprx-vision"` nella configurazione) è uno schema di padding applicato al traffico TLS 1.3. Il problema che risolve è sottile. I record TLS 1.3 hanno firme di lunghezza prevedibili quando trasportano dati applicativi interni di dimensioni fisse: le lunghezze rivelano informazioni su ciò che viene incapsulato. Vision aggiunge byte di padding durante la fase iniziale di handshake. Una volta stabilita la connessione, passa alla copia raw del socket. Su Linux utilizza la chiamata di sistema `splice()` per inoltrare i pacchetti TCP nel kernel senza copiarli attraverso lo spazio utente. Il risultato è una velocità di trasmissione simile a quella che si otterrebbe con una connessione TCP non proxy, con la perdita di informazioni sulla firma di lunghezza appiattita.
REALITY, rilasciato nel 2023 e gestito su github.com/XTLS/REALITY, è più radicale. Un server VLESS+TLS standard presenta il proprio certificato TLS, il che significa che possiede un dominio, esegue un Certbot da qualche parte ed espone un'impronta digitale del certificato che un sistema DPI può correlare all'utilizzo di un proxy. REALITY abbandona completamente questo concetto. Invece di eseguire il proprio TLS, il server simula l'handshake di un sito web reale di terze parti. L'operatore sceglie il target: `microsoft.com`, `apple.com`, qualsiasi dominio. Il server utilizza la falsificazione SNI e uno scambio di chiavi X25519. I client che conoscono la chiave pubblica REALITY corretta completano un vero handshake TLS 1.3 con la catena di certificati simulata, esattamente come farebbe un browser con un server web reale, e vengono quindi instradati nel tunnel VLESS. I client che non la conoscono, inclusi i sistemi DPI di scansione, vedono quella che sembra una normale connessione al sito simulato, incluso il certificato reale.
La combinazione di VLESS come protocollo interno, XTLS Vision per l'appiattimento della firma di lunghezza e REALITY per il camuffamento dell'handshake è ciò che si intende quando si parla di "VLESS+REALITY" o "VLESS+Vision+REALITY". È la configurazione che, a metà del 2026, funziona ancora in ambienti in cui quasi nessun'altra soluzione è efficace.
VLESS contro VMess contro Trojan contro Shadowsocks contro WireGuard
Lo spazio dei protocolli attorno a VLESS è ristretto e le differenze sono importanti. La versione breve è riportata di seguito; la versione estesa è nella tabella.
VMess è il predecessore di VLESS. Integra la crittografia AEAD, la protezione contro gli attacchi di replay e varianti basate su alterId. In una rete non censurata, queste funzionalità comportano una perdita di throughput di qualche punto percentuale e non apportano alcun vantaggio. In una rete censurata, il pattern di crittografia all'interno di TLS è rilevabile e, secondo i dati di telemetria del Great Firewall, la sua rilevazione si aggira intorno all'80% da settembre 2025.
Trojan è un progetto simile, sviluppato da un team diverso. È persino più semplice di VLESS: una password al posto di un UUID, nessun campo per i componenti aggiuntivi, TLS in uscita. Per anni questo minimalismo lo ha reso efficace; l'aggiornamento del Great Firewall nell'agosto 2025 ha cambiato le cose e ora Trojan ha un tasso di rilevamento di circa il 90%.
Shadowsocks appartiene a una famiglia completamente diversa. Si tratta di un cifrario simmetrico AEAD senza facciata TLS, progettato per apparire come byte casuali anziché come HTTPS. Questo approccio ha funzionato fino a quando il Great Firewall non ha iniziato a segnalare il traffico completamente crittografato come sospetto per impostazione predefinita; le moderne implementazioni di Shadowsocks si basano su plugin di trasporto (v2ray-plugin, cloak) che incapsulano il cifrario in TLS o HTTP, ricostruendo di fatto l'architettura VLESS dalla direzione opposta.
WireGuard merita una discussione completamente diversa. Si tratta di una VPN a livello kernel, non di un protocollo proxy. Su una rete pulita è circa il 2-3% più veloce di VLESS+XTLS in termini di throughput grezzo, con un overhead della CPU molto inferiore, e rimane la soluzione ideale per i casi d'uso comuni di protezione della privacy dagli ISP. Nelle reti censurate, il suo byte di handshake fisso 0x01 è facilmente identificabile e il throughput effettivo crolla quasi a zero.
| Protocollo | Famiglia | Strato esterno | Resistenza DPI | Ideale per |
|---|---|---|---|---|
| VLESS+REALITY | Proxy V2Ray/Xray | Impersonamento di TLS 1.3 | Elevata (rilevamento ≤5% nei rapporti sul campo) | Reti ostili |
| VMess | Proxy V2Ray | Crittografia automatica all'interno di TLS | Basso (~80% GFW) | Solo compatibilità con versioni precedenti |
| Troiano | Proxy di front-end TLS | TLS di proprietà | Basso (~90% GFW dopo agosto 2025) | Un hosting più semplice |
| Shadowsocks (AEAD) | Offuscamento simmetrico | Byte casuali / plugin TLS | Misto (dipende dal plugin) | Utenti di dispositivi mobili con collegamenti instabili |
| WireGuard | VPN del kernel | Handshake UDP + rumore | Molto basso (rilevabile tramite DPI) | Privacy e velocità di rete pulite |
VLESS, censura e blocco DPI russo
VLESS sarebbe una nota a piè di pagina nella storia dei software proxy se non fosse per il fatto che aggira la censura in Russia e in regimi simili con maggiore affidabilità rispetto a qualsiasi altro protocollo ampiamente diffuso. Dal 2024, i più grandi sistemi DPI statali del mondo stanno attivamente cercando di eliminarlo. Da allora, la vicenda si è trasformata in una lenta e pubblica escalation.
In Russia, Roskomnadzor ha segnalato il blocco di 439 servizi VPN entro gennaio 2026. Il budget federale per il blocco delle VPN ammonta a circa 60 miliardi di rubli (circa 780 milioni di dollari) per il periodo 2025-2027, con altri 2,27 miliardi di rubli (circa 29 milioni di dollari) specificamente destinati al filtraggio del traffico basato sull'intelligenza artificiale, secondo quanto riportato da zona.media nell'aprile 2026. Il 17 febbraio 2026, Roskomnadzor ha intensificato nuovamente le misure, con una forte ondata di blocchi mirati specificamente a VLESS-over-TCP-with-TLS, come documentato da Mezha e digirpt. Gli utenti sono passati a REALITY, gRPC e ai trasporti con CDN nel giro di poche ore. Il tasso di aggiramento della comunità per VLESS+REALITY rispetto al DPI russo si è attestato intorno al 99,5% durante quell'ondata, un dato che dovrebbe essere considerato indicativo piuttosto che misurato con precisione.
In Cina, il Great Firewall ha attraversato una sequenza simile nel 2025. Il tasso di rilevamento dei Trojan è sceso a circa il 90% ad agosto, mentre quello di VMess a circa l'80% a settembre. Un altro evento di sicurezza informatica, avvenuto a settembre 2025 e riportato da Cybernews, ha causato una fuga di dati di 600 GB da un fornitore cinese del GFW, esponendo parte dell'infrastruttura di classificazione interna, ma senza modificare di per sé i costi di implementazione. I test della community su greatfirewallguide.com hanno riportato tassi di elusione del 98% per VLESS+REALITY+Vision all'inizio del 2026.
In Iran, l'IRGFW di MCI ha inserito nella greylist gli indirizzi IP di REALITY almeno dall'aprile 2024, come documentato nella discussione XTLS/Xray-core n. 3269. Gli operatori segnalano che un IP che trasporta circa 100 GB di traffico REALITY tende a essere bloccato da Irancell entro 48 ore, motivo per cui la rotazione dei server e l'utilizzo di CDN front-end sono diventati prassi standard in Iran.
Come si presenta una configurazione VPN VLESS: server, client, configurazioni
Un'implementazione VLESS funzionante si compone di tre parti: un server da qualche parte, un client su ciascun dispositivo e una stringa di connessione che li collega.
La parte server è semplice. Qualsiasi VPS economico andrà bene: Hetzner, Vultr, OVH, qualsiasi con IPv4 pubblico. Installa Xray-core dai binari di rilascio del progetto o da un gestore di pacchetti, genera un UUID (`xray uuid`), genera una coppia di chiavi X25519 per REALITY (`xray x25519`), scegli un target di impersonificazione (un sito HTTPS reale che supporti TLS 1.3 e HTTP/2) e scrivi una configurazione server JSON che si colleghi alla porta 443. Il tempo totale di configurazione, una volta eseguita la prima volta, è di circa dieci minuti. Pannelli web come 3X-UI e Hiddify-Manager offrono la stessa configurazione tramite un'interfaccia browser per gli operatori che preferiscono non modificare il JSON. Esistono anche appliance gestite. AWS Marketplace elenca un'immagine Xray VLESS VPN Server a $ 0,063 all'ora su un t3.micro, con una prova gratuita di 5 giorni.
Lato client, l'ecosistema è frammentato ma affidabile. v2rayN e Nekoray sono i client Windows più diffusi. v2rayNG, NekoBox e Hiddify supportano Android. Hiddify è compatibile anche con macOS e Linux. Su iOS, dove le politiche dell'App Store di Apple complicano le cose, Streisand è l'opzione gratuita, mentre Shadowrocket e V2Box sono a pagamento. Tutti questi client utilizzano il protocollo VLESS; la maggior parte supporta anche REALITY. La configurazione viene solitamente importata tramite un URI `vless://`, un singolo URL contenente UUID, indirizzo, porta, trasporto e parametri REALITY, oppure scansionata come codice QR dal pannello lato server.
Prestazioni, rischi e quando VLESS non è lo strumento giusto
Le prestazioni prima di tutto. I benchmark della community indicano che VLESS offre un throughput superiore di circa il 15-25% rispetto a VMess sullo stesso trasporto, principalmente perché l'intestazione VLESS è molto più corta e non prevede un passaggio di crittografia interno. Con XTLS Vision e l'ottimizzazione dello splice di Linux, un'implementazione VLESS ben configurata si avvicina al throughput nativo di TCP, limitato solo dalla larghezza di banda del VPS e dal tempo di andata e ritorno al server. WireGuard rimane comunque più veloce del 2-3% sulle reti non censurate, dove il suo handshake non rappresenta un problema.
I rischi sono reali. Il protocollo VLESS è neutrale e open-source, ma lo status legale del suo utilizzo per aggirare la censura statale varia notevolmente a seconda della giurisdizione. La legge federale russa sugli strumenti di elusione criminalizza la promozione di configurazioni funzionanti piuttosto che l'uso personale; la posizione normativa cinese è più rigida e arbitraria; l'Iran persegue i gestori di grandi pool di proxy. Le reti aziendali spesso vietano completamente il traffico proxy e VPN. Gli utenti che operano in tali contesti dovrebbero conoscere le normative vigenti prima di configurare qualsiasi sistema. Le app VPN gratuite che includono abbonamenti VLESS preinstallati rientrano in una categoria normativa diversa in alcune giurisdizioni e potrebbero essere soggette a un controllo differente.
Un ultimo punto, meno drammatico. Se non vi trovate in una rete censurata, VLESS è eccessivo. Per una normale protezione della privacy dal vostro ISP su una connessione pulita, WireGuard o una moderna configurazione OpenVPN sono più veloci, più semplici e già supportati da tutti i provider VPN commerciali. VLESS+REALITY è uno strumento per un problema specifico, e ricorrervi quando il problema è diverso significa perlopiù complicarsi la vita.
