Italiano
Guida VLESS + Reality: Configurazione Proxy Sicura
Parole Chiave
Prima di immergersi nella configurazione, ecco i termini chiave che potrebbero necessitare di chiarimenti in questa guida.
| Parola Chiave | Definizione |
|---|---|
| 🔐 VLESS | Un protocollo proxy leggero dell’ecosistema V2Ray/Xray che autentica gli utenti con un UUID ed è comunemente abbinato a trasporti stealth moderni come Reality. |
| 🔀 Proxy vs VPN | Un proxy di solito inoltra il traffico dell’applicazione attraverso un server, mentre una VPN tradizionale crea tipicamente un tunnel di rete virtuale completo per il dispositivo o il sistema. |
| 🎭 Reality | Un meccanismo di trasporto stealth per Xray che fa sembrare il traffico molto più simile al normale HTTPS utilizzando impronte TLS simili a quelle dei browser e una validazione speciale basata su chiave. |
| 🔍 DPI (Deep Packet Inspection) | Una tecnica di filtraggio della rete che analizza i modelli dei pacchetti, le handshake e le impronte dei protocolli per identificare e bloccare il traffico come VPN e proxy. |
| 🖥️ VPS | Un server virtuale privato che affitti e controlli da remoto, che funge da macchina host per la tua configurazione VLESS + Reality. |
| ⚙️ 3x-ui | Un pannello di gestione basato sul web per Xray che ti consente di creare inbound, utenti e impostazioni di Reality senza modificare manualmente il JSON. |
| 🚀 Xray | Il motore proxy principale che funziona sotto 3x-ui e che gestisce effettivamente VLESS, Reality, instradamento e connessioni client. |
| 🆔 UUID | Un identificatore unico assegnato a ciascun client e utilizzato da VLESS come valore principale di autenticazione. |
| 🌐 SNI | Server Name Indication, un campo TLS che informa il server quale hostname viene richiesto e deve corrispondere correttamente alla configurazione del target di Reality. |
| 🧬 x25519 Key Pair | La coppia di chiavi pubblica/privata utilizzata da Reality affinché i client approvati possano completare la connessione mentre le sonde indesiderate vengono trattate diversamente. |
| 🔑 Chiave pubblica vs chiave privata | La chiave pubblica è condivisa con il client affinché possa connettersi, mentre la chiave privata rimane solo sul server e non deve mai essere esposta. |
| 🧭 uTLS Fingerprint | Un’impronta client TLS che imita un browser, come chrome, utilizzata per far sembrare la connessione simile al traffico normale del browser. |
| 📡 Inbound | La configurazione dell’ascoltatore lato server in Xray/3x-ui che definisce come i client si connettono, inclusi protocollo, porta, trasporto e impostazioni di sicurezza. |
| ⚡ BBR | Un algoritmo di controllo della congestione TCP di Google che può migliorare il throughput e la reattività su alcuni percorsi di rete VPS. |
| ✅ ACME validation | Il passaggio di verifica pubblica utilizzato dai servizi di certificazione come Let’s Encrypt per confermare che il tuo server o dominio sia raggiungibile e autorizzato a richiedere il certificato. |
Impostare VLESS VPN con Reality Stealth nel 2026
La frustrazione è familiare: hai impostato un server VPN, tutto funziona perfettamente, e poi una mattina ti svegli e scopri che è bloccato. La connessione che funzionava ieri oggi fallisce. Nessuna modifica da parte tua, eppure all’improvviso nulla funziona. Questo non è uno scenario ipotetico: è la realtà dell’uso dei protocolli VPN tradizionali nel 2026, dove la tecnologia di ispezione profonda dei pacchetti si è evoluta per identificare e bloccare anche il traffico correttamente crittografato.
Il Problema: Perché le VPN Standard Vengono Bloccate
I giorni in cui un semplice server OpenVPN o WireGuard funzionava in modo affidabile per mesi—o addirittura anni—sono finiti. La tecnologia di ispezione profonda dei pacchetti (DPI) è avanzata notevolmente, e non si tratta più solo di rilevare il traffico non crittografato. I moderni sistemi DPI esaminano molteplici caratteristiche del tuo traffico di rete per identificare le connessioni VPN con una precisione straordinaria.
Considera cosa succede quando ti connetti utilizzando OpenVPN o WireGuard standard. Il traffico è crittografato, ma ha comunque una forma riconoscibile. OpenVPN espone spesso una handshake TLS e un modello di traffico che non assomiglia a una normale sessione del browser. WireGuard non utilizza affatto TLS, ma la sua handshake e il comportamento dei pacchetti basati su UDP sono comunque distintivi abbastanza da spiccare su reti filtrate. È come avere un passaporto con il codice paese sbagliato: il documento è valido, ma i dettagli non corrispondono a nessun viaggiatore legittimo.
Nel 2026, questo blocco avviene più velocemente che mai. Dove una volta un VPN appena distribuito poteva funzionare per mesi prima di essere rilevato, ora i nuovi server possono essere identificati entro giorni o addirittura ore dalla loro attivazione. Il blocco è anche più pervasivo, avvenendo a livello ISP, a livello di rete aziendale e, in alcune giurisdizioni, a livello di firewall nazionale. Hai bisogno di una soluzione che non solo crittografi il tuo traffico: lo faccia sembrare qualcos’altro del tutto.
Cos’è VLESS? Il Protocollo Spiegato
VLESS sta per “VMess Less”—un nome che riflette direttamente la sua filosofia di design. È stato creato come un successore più leggero e semplice del protocollo VMess, che era il protocollo di trasporto predefinito originale nel progetto V2Ray. Dove VMess raggruppava crittografia, autenticazione e trasporto in un unico sistema strettamente accoppiato, VLESS elimina i livelli non necessari e lascia un protocollo di trasporto pulito e senza stato.
Ecco la distinzione critica: VLESS funziona come un proxy, non come un tunnel VPN completo. Il protocollo reindirizza il tuo traffico attraverso il server piuttosto che creare un’interfaccia di rete virtuale completa. Per la maggior parte degli utenti, questa distinzione è accademica: il risultato funzionale è esattamente ciò che ti aspetti da una VPN: il tuo traffico appare provenire dall’indirizzo IP del server. Ma questa architettura proxy è esattamente il motivo per cui VLESS funziona così bene con Reality, poiché il carico di protocollo più leggero consente al meccanismo stealth di operare senza interferenze.
Il design del proxy significa anche meno overhead rispetto ai protocolli VPN tradizionali. Non c’è interfaccia di tunnel a livello di kernel da gestire, nessun ulteriore livello di crittografia oltre a ciò che è necessario, e il protocollo è stato progettato fin dall’inizio per funzionare con meccanismi stealth moderni basati su TLS. Questa semplicità è una caratteristica, non una limitazione: significa meno cose che possono andare male e meno impronte che possono essere rilevate.
Comprendere Reality: La Tecnologia Stealth
Reality è ciò che trasforma VLESS da un altro protocollo proxy in qualcosa di molto più difficile da distinguere dal normale traffico web crittografato. Il meccanismo è elegante nella sua semplicità: invece di cercare di nascondere ciò che stai facendo, Reality fa sembrare il tuo traffico qualcos’altro del tutto.
Reality raggiunge questo attraverso una tecnica che opera a livello di handshake TLS. Quando un client si connette al tuo server, invia un TLS ClientHello che imita un vero browser—utilizzando la libreria uTLS per replicare l’impronta di Chrome, Firefox o un altro browser popolare. Il server quindi convalida la connessione utilizzando il materiale chiave di Reality e i parametri del client costruiti attorno a una coppia di chiavi x25519. Se il client presenta i valori di Reality attesi, la connessione procede come un proxy VLESS. Se non lo fa—cosa che accade quando un sistema DPI o una sonda attiva colpisce il tuo server—il traffico viene inoltrato a un sito web target legittimo come www.microsoft.com o www.apple.com. Per il sistema di sondaggio, il tuo server appare come un normale sito web piuttosto che un evidente endpoint proxy.
Pensalo come indossare una divisa. Un guardia di frontiera che ispeziona i veicoli non controlla ogni auto a fondo: fa passare quelle che sembrano legittime in base alla loro registrazione, targhe e aspetto del conducente. Il tuo traffico indossa la divisa di una grande azienda, quindi l’ispettore di rete lo fa passare senza l’ispezione dettagliata che rivelerebbe che in realtà è qualcos’altro. L’impronta uTLS è il travestimento, e lo scambio di chiavi x25519 è la stretta di mano segreta che solo il tuo client conosce.
Un punto critico: non hai bisogno del tuo dominio affinché questo funzioni. I metodi stealth precedenti richiedevano di possedere un dominio e ottenere certificati Let’s Encrypt, il che creava una traccia cartacea e una complessità aggiuntiva. Reality non richiede altro che un indirizzo IP VPS. I siti web target (Microsoft, Apple, Google) hanno un uptime vicino al 100% e supportano l’ultimo protocollo TLS 1.3, rendendoli ancore perfette per questa tecnica.
La porta 443 dà a questo travestimento la migliore possibilità di mimetizzarsi. Il traffico HTTPS standard utilizza normalmente la porta 443, quindi mantenere Reality su quella porta fa sembrare la connessione molto più simile alla normale navigazione web. Altre porte possono funzionare tecnicamente, ma indeboliscono il camuffamento perché non corrispondono più alla forma predefinita del traffico HTTPS quotidiano.
Comuni Malintesi
Prima di procedere, affrontiamo tre malintesi che intralciano le persone che esplorano VLESS + Reality per la prima volta.
“VLESS è una VPN.” In termini tecnici, VLESS è un protocollo proxy, non una VPN nel senso tradizionale. Non c’è interfaccia TUN/TAP, nessun adattatore di rete virtuale e nessuna manipolazione della tabella di routing. Tuttavia, dalla prospettiva funzionale dell’utente, fornisce esattamente ciò che ti aspetteresti da una VPN: il tuo traffico internet appare provenire dall’indirizzo IP del server. La distinzione è importante per gli ingegneri di rete, ma raramente conta per gli utenti finali.
“Reality ha bisogno di un dominio.” Questo era vero per le tecniche stealth precedenti che utilizzavano domini di proprietà e certificati Let’s Encrypt. Reality è stato specificamente progettato per funzionare senza alcun dominio che controlli. Utilizza l’imitazione dell’impronta del browser e l’autenticazione con chiave x25519, il che significa che non è necessario registrare, gestire o rinnovare nulla. Configuralo una volta e continua a funzionare.
“Questo è inespugnabile.” Nulla è inespugnabile. Reality è altamente resistente alla rilevazione e al blocco perché sembra genuinamente traffico HTTPS normale. Ma non è immune ai futuri miglioramenti nella tecnologia DPI, alla potenziale identificazione del protocollo o agli attacchi mirati. Ciò che fornisce è la migliore protezione disponibile nel 2026 contro le forme più comuni di filtraggio della rete. Consideralo come una soluzione robusta, non come uno scudo magico.
Cosa Ti Serve Prima di Iniziare
Avrai bisogno di un VPS da qualsiasi fornitore (cioè AvaHost), e servizi simili funzionano bene. Per prestazioni tipiche per un singolo utente, un piano base con 1 core CPU e 1GB RAM è sufficiente. Il server dovrebbe eseguire Ubuntu 22.04 LTS o 24.04 LTS; queste versioni hanno supporto del kernel per le funzionalità di rete richieste out of the box.
L’accesso SSH come root è essenziale. Hai bisogno della possibilità di connetterti al tuo server tramite la riga di comando ed eseguire comandi privilegiati. La maggior parte dei fornitori di VPS offre questo per impostazione predefinita: riceverai un indirizzo IP, un nome utente (di solito root) e una password o una chiave SSH dopo il deployment.
Per le applicazioni client, a seconda dei tuoi dispositivi avrai bisogno di: v2rayNG per Android, v2rayN per Windows, V2Box o Streisand per macOS, e Shadowrocket o FoXray per iOS. Tratteremo questi dettagliatamente nella sezione delle applicazioni client più avanti in questa guida.
Un vantaggio significativo del metodo Reality: non hai bisogno di un dominio che controlli. Molti setup stealth richiedono di registrare e gestirne uno, ma Reality può funzionare direttamente dall’IP VPS mentre prende in prestito l’aspetto di una destinazione TLS legittima.
Una breve nota sulle considerazioni legali: Le tecniche descritte in questa guida sono destinate a esigenze legittime di privacy e accesso. Le leggi sul filtraggio di Internet variano significativamente in base alla giurisdizione. Assicurati che il tuo utilizzo di questi strumenti sia conforme alle leggi applicabili nella tua regione.
Preparazione del Server: BBR e Nozioni di Base
Verificate le condizioni preliminari, prepariamo il server. Questa fase ottimizza il tuo VPS prima di installare qualsiasi software, garantendo le massime prestazioni fin dall’inizio.
💡 TIP: Usa BBR prima di distribuire — spesso migliora il throughput e la latenza su collegamenti limitati o con alta latenza.
Prima di tutto, aggiorna i pacchetti di sistema. Questo garantisce di avere gli ultimi aggiornamenti di sicurezza e le dipendenze richieste:
apt update && apt upgrade -yQuesto passaggio può richiedere 1-5 minuti a seconda del tuo fornitore di VPS e della velocità di rete. Alcuni fornitori pre-aggiornano le loro immagini durante il deployment, quindi questo potrebbe completarsi rapidamente su alcuni sistemi.
Successivamente, abilita il controllo della congestione Google BBR. BBR (Bottleneck Bandwidth and Round-trip propagation time) è l’algoritmo di controllo della congestione di Google. Invece di fare affidamento principalmente sulla perdita di pacchetti come segnale, cerca di modellare più direttamente la larghezza di banda disponibile e il tempo di andata e ritorno, il che può migliorare il throughput e la reattività su alcuni collegamenti VPS.
# Verify BBR module is available
lsmod | grep tcp_bbrSe nulla appare, carica il modulo manualmente:
modprobe tcp_bbr
Ora crea la configurazione sysctl per abilitare BBR in modo persistente:
cat >> /etc/sysctl.d/99-bbr.conf << 'EOF'
net.core.default_qdisc=fq
net.ipv4.tcp_congestion_control=bbr
EOF
Applica la configurazione:
sysctl -p /etc/sysctl.d/99-bbr.confVerifica che BBR sia attivo:
sysctl net.ipv4.tcp_congestion_control
sysctl net.ipv4.tcp_available_congestion_controlDovresti vedere bbr come algoritmo attivo.
Alcuni sistemi beneficiano di un riavvio dopo aver abilitato BBR: garantisce che il modulo venga caricato correttamente e che tutte le ottimizzazioni di rete abbiano effetto:
rebootOra assicurati che la porta 443 sia raggiungibile. Se prevedi di utilizzare il flusso Let’s Encrypt integrato dell’installatore 3x-ui per il pannello, consenti anche 80/tcp — quella porta è utilizzata per la convalida del certificato ACME, non per il pannello stesso. Se il tuo fornitore di VPS ha anche un firewall cloud o un livello di gruppo di sicurezza, consenti le stesse porte anche lì. Su Ubuntu, il percorso più sicuro è di solito UFW.
# If this is a remote VPS and you're enabling UFW for the first time, allow SSH before enabling the firewall
ufw allow OpenSSH
# Allow HTTPS-style Reality traffic
ufw allow 443/tcp
# Allow ACME validation for the 3x-ui panel's built-in Let's Encrypt setup
ufw allow 80/tcp
# Review rules, then enable only if UFW is not already active
ufw status
ufw enable⚠️ ATTENZIONE: La porta 443 è fortemente raccomandata perché corrisponde al traffico HTTPS normale. Altre porte possono funzionare tecnicamente, ma si mimetizzano meno naturalmente e rendono l’installazione più facile da segnalare.
Il tuo server è ora ottimizzato e pronto per l’installazione di 3x-ui.
Installazione del Pannello 3x-ui
Prima di eseguire l’installatore, nota un requisito facile da perdere: se vuoi che il flusso Let’s Encrypt integrato dell’installatore emetta un certificato SSL per il pannello, 80/tcp deve essere aperto e raggiungibile da Internet pubblico. Questa porta di convalida ACME è separata dalla porta del pannello che scegli durante la configurazione.
Esegui il comando di installazione:
bash <(curl -Ls https://raw.githubusercontent.com/mhsanaei/3x-ui/master/install.sh)Le versioni attuali dell’installatore non iniziano non con il menu numerato più vecchio Install / Update / Uninstall che molti tutorial mostrano ancora. Invece, lo script inizia immediatamente l’installazione, installa eventuali dipendenze mancanti, scarica l’ultima versione e poi ti guida attraverso i prompt di configurazione del pannello.
Un flusso di installazione tipico ora appare così:
- Scegli se impostare una porta personalizzata per il pannello o lasciare che l’installatore ne generi una casuale.
- Lascia che l’installatore generi un nome utente, una password e un webBasePath casuali.
- Scegli come configurare SSL per il pannello:
- 1 = Let’s Encrypt per un dominio
- 2 = Let’s Encrypt per l’IP del server
- 3 = utilizza un certificato esistente
- Completa i prompt del certificato se utilizzi il flusso Let’s Encrypt integrato.
⚠️ IMPORTANTE: La porta del pannello non è la stessa cosa della porta di convalida ACME. Potresti eseguire il pannello su una porta casuale come 13525 e dover comunque avere aperto il pubblico 80/tcp affinché Let’s Encrypt possa convalidare il certificato.
La regola importante è semplice: usa le esatte credenziali, il percorso e l’URL stampati dal tuo stesso installatore, non assunzioni copiate da tutorial più vecchi.
Il tuo output finale apparirà più simile a questo:
Username: GENERATED_USERNAME Password: GENERATED_PASSWORD Port: 13525 WebBasePath: RANDOM_PATH Access URL: https://YOUR_SERVER_IP:13525/RANDOM_PATH
Verifica che il servizio sia in esecuzione:
systemctl status x-ui
Questo controllo è importante. Guarda specificamente la riga del server web nell’output di stato:
- Se vedi Web server running HTTPS …, il pannello SSL funziona correttamente.
- Se vedi Web server running HTTP …, il pannello è stato installato con successo ma la configurazione SSL non è stata completata.
Accedi al pannello utilizzando l’esatto URL, nome utente e password generati dal tuo stesso install. Non assumere che il percorso sia /panel, e non assumere che le credenziali siano admin/admin a meno che il tuo install non lo dica esplicitamente.
💡 TIP 1: Per visualizzare nuovamente le impostazioni correnti del pannello e stampare l’URL di accesso, nella CLI esegui il comando “x-ui” e scegli il numero 10 “Visualizza Impostazioni Correnti” dall’output del menu.
💡 TIP 2: Se l’URL di accesso non si carica, assicurati che la porta del pannello 3x-ui sia aperta sul firewall del tuo VPS. Ad esempio, se il tuo pannello è in esecuzione sulla porta “13525”, consentila con: ” ufw allow 13525/tcp “. Sostituisci 13525 con la porta effettiva che hai configurato per il pannello 3x-ui.
Se l’installatore termina ma systemctl status x-ui mostra HTTP invece di HTTPS
La causa più comune è che 80/tcp non era raggiungibile da Internet pubblico durante la convalida di Let’s Encrypt. In tal caso, il pannello potrebbe comunque installarsi e avviarsi, ma il rilascio del certificato fallisce.
Correggi prima il firewall:
ufw allow 80/tcp
ufw statusSe il tuo fornitore di VPS ha un firewall cloud o un livello di gruppo di sicurezza, consenti anche 80/tcp lì. Quindi riesegui la configurazione del certificato del pannello dallo script di gestione 3x-ui:
x-uiPer un certificato del pannello basato su IP, scegli:
- 19 → 6 (Ottieni SSL per Indirizzo IP)
Per un certificato del pannello basato su dominio, scegli:
- 19 → 1 (Ottieni SSL (Dominio))
Dopo che il certificato è stato emesso, verifica di nuovo:
systemctl status x-uiVuoi che l’output di stato mostri Web server running HTTPS … prima di continuare.
💡 TIP: Salva immediatamente le credenziali generate e l’URL del pannello. Nota anche che il riepilogo dell’installatore può essere fuorviante se il rilascio del certificato fallisce — se l’ultimo blocco stampa un URL HTTPS ma systemctl status x-ui mostra ancora HTTP, fidati dell’output dello stato del servizio e correggi SSL prima di procedere.
Configurazione di VLESS + Reality Inbound
Questo è il passaggio di configurazione critico in cui il tuo sistema simile a VPN viene effettivamente creato. All’interno del pannello 3x-ui, naviga su Inbounds → Aggiungi Inbound.
Configura i campi come segue:
| Campo | Valore | Note |
|---|---|---|
| Protocollo | VLESS | Seleziona dal menu a discesa |
| IP di Ascolto | 0.0.0.0 | Predefinito / tutte le interfacce |
| Porta | 443 | Consigliata per il camuffamento HTTPS più naturale |
| Client → Autenticazione | Lascia vuoto / predefinito | Non utilizzare Ottieni Nuove chiavi per questa configurazione di base |
| Client → decrittazione | none | Richiesta per VLESS |
| Client → crittografia | none | Lascia al predefinito |
| Client → Flusso | xtls-rprx-vision | Imposta questo nella sottosezione Client. Se non vedi ancora questo campo, imposta prima Trasmissione su TCP (RAW) e Sicurezza su reality. |
| Trasmissione | TCP (RAW) | Usa trasporto TCP diretto |
| Sicurezza | reality | Seleziona dalle opzioni di sicurezza |
| uTLS | chrome | Usa un’impronta del browser comune |
| Target | www.microsoft.com:443 | Target TLS 1.3 stabile per fallback/sondaggio |
| SNI | www.microsoft.com | Mantienilo allineato con il Target |
| ID Brevi | Genera o usa il predefinito del pannello | Copia un valore generato nel client |
| SpiderX | / | Predefinito semplice |
| Chiave Pubblica | Genera con Ottieni Nuovo Cert | Copia questo nel client |
| Chiave Privata | Genera con Ottieni Nuovo Cert | Conserva solo sul server |
📋 NOTA: Lascia gli altri campi visibili — come Flusso Totale, Ripristino Traffico, Durata, Fallbacks, Protocollo Proxy, Offuscamento HTTP, Sockopt, Proxy Esterno, Mostra, Xver, Max Time Diff, Min Client Ver, Max Client Ver, Sniffing e i campi ML-DSA — ai loro valori predefiniti per questa configurazione di base.
Infine, fai clic su Salva per creare l’inbound.
⚠️ ATTENZIONE: La porta 443 è la migliore predefinita perché corrisponde al traffico HTTPS ordinario. Se la cambi, l’inbound potrebbe comunque funzionare, ma non si mimetizza più in modo pulito.
⚠️ ATTENZIONE: Il target Reality deve supportare TLS 1.3 — Microsoft, Apple e Google sono scommesse sicure. Utilizzare un target che non supporta TLS 1.3 causerà il fallimento di Reality, poiché il protocollo è progettato specificamente per le handshake TLS 1.3.
Il motivo per cui questi valori sono importanti: la porta 443 ti offre il profilo HTTPS più credibile, un target TLS 1.3 stabile dà alle sonde un posto legittimo dove atterrare, e l’impronta chrome mantiene il lato client allineato con una delle impronte del browser più comuni su Internet. Inizia semplice, ottieni un percorso funzionante, poi espandi in seguito se hai bisogno di più target.
Gestione Utenti in 3x-ui
Con l’inbound configurato, devi creare connessioni utente che i tuoi dispositivi utilizzeranno per autenticarsi. In 3x-ui, naviga su Inbounds → [Fai clic sul tuo Menu VLESS inbound] → Aggiungi Client.
Ogni utente ottiene un UUID unico (generato automaticamente), insieme a un’email per identificazione e limiti opzionali di traffico/scadenza. Quando crei un client, il pannello genera i valori necessari per la connessione: indirizzo del server, UUID, flusso, chiave pubblica, ID breve e impostazioni relative a SNI.
Premendo il segno più (“+”) dell’inbound selezionato, apparirà l’elenco degli utenti.
Esportare un client
Per esportare i dettagli di connessione di un singolo client, espandi prima la riga dell’inbound in modo che la tabella dei client sia visibile. Nella riga del client, utilizza le due azioni di esportazione per client:
- Icona QR → apre il modulo QR
- Icona Info → apre il modulo dettagli
Questi corrispondono ai primi due metodi di condivisione.
Codice QR: Fai clic sull’icona QR del client. Se gli abbonamenti sono abilitati, il modulo QR potrebbe mostrare due codici QR:
- Abbonamento → un QR per l’URL di abbonamento del client
- Client QR (etichettato con l’email o identificatore del client, come example@mail.com) → un QR per l’URI VLESS Reality diretto
Il QR di abbonamento è utile per i client che supportano aggiornamenti automatici. Il QR del client è l’importazione diretta una tantum per quel specifico client.
Link / URL di Condivisione: Fai clic sull’icona Info del client. Nel modulo dettagli, potresti vedere due tipi di esportazione testuale:
- URL di Abbonamento → un endpoint di abbonamento rinfrescabile
- URL → l’URI VLESS Reality diretto per quel client
Utilizza il pulsante di copia accanto alla sezione URL per l’importazione desktop.
Al minimo, un URI Reality diretto utilizzabile dovrebbe includere valori popolati come:
type=tcp encryption=none security=reality sni=www.microsoft.com fp=chrome pbk=YOUR_PUBLIC_KEY sid=YOUR_SHORT_ID spx=/ flow=xtls-rprx-vision
pbk= è la chiave pubblica Reality e appartiene all’URI VLESS diretto. L’URL di abbonamento stesso di solito non conterrà pbk= perché è solo l’endpoint di fetch; la configurazione restituita contiene i reali parametri di Reality.
Alcune versioni di 3x-ui hanno avuto bug nei link di condivisione Reality dove pbk= è vuoto. Se l’URI diretto manca di pbk= o sid=, non fidarti ciecamente. In tal caso, utilizza invece la configurazione manuale.
Configurazione Manuale: Non esiste un pulsante di esportazione separato per la “configurazione manuale”. In pratica, la configurazione manuale significa inserire direttamente i valori nell’app client o comporre e verificare tu stesso il finale URI VLESS Reality dai valori grezzi. Raccogli i valori richiesti da:
- il modulo Info: indirizzo del server, porta, UUID, flusso e l’URI diretto
- le impostazioni Reality dell’inbound: SNI, chiave pubblica, ID breve, impronta (chrome) e SpiderX (/) se necessario
Puoi creare più utenti per dispositivi diversi o persone diverse. Ogni UUID è indipendente, quindi revocare l’accesso per un utente non influisce sugli altri.
Configurazione Manuale di Xray (Breve)
Al alcuni utenti preferiscono non utilizzare un’interfaccia grafica e vogliono modificare direttamente la configurazione di Xray. Su un’installazione standard di Linux 3x-ui, la configurazione runtime attiva è scritta in /usr/local/x-ui/bin/config.json, quindi puoi ispezionarla o apportare modifiche manuali temporanee lì.
Tratta quel file come un artefatto runtime generato, non come la fonte di verità del pannello. 3x-ui ricostruisce config.json dalle sue impostazioni supportate da database, quindi le modifiche manuali possono essere sovrascritte quando Xray si riavvia o quando salvi modifiche nel pannello.
Prima di modificarlo, crea un backup:
cp /usr/local/x-ui/bin/config.json /usr/local/x-ui/bin/config.json.bakLa modifica manuale può essere utile per test rapidi o debug, ma un JSON errato può impedire a Xray di avviarsi. Se 3x-ui soddisfa le tue esigenze, attieniti al pannello per modifiche persistenti e utilizza le modifiche dirette a config.json solo per casi avanzati.
Applicazioni Client per Piattaforma
Per connetterti al tuo server, avrai bisogno di software client sui tuoi dispositivi. Ecco cosa è disponibile:
| Piattaforma | App Consigliate | Note |
|---|---|---|
| Windows | v2rayN | Client GUI con integrazione nella barra di sistema |
| macOS | V2Box, Streisand | V2Box è gratuito; Streisand è su App Store |
| Android | v2rayNG, NekoBox | Entrambi disponibili su GitHub e F-Droid |
| iOS | Shadowrocket, FoXray, V2Box | Shadowrocket è a pagamento; la disponibilità di FoXray può variare |
Per Windows, v2rayN è la scelta consigliata: è attivamente mantenuto, ha un’interfaccia pulita e gestisce nativamente la configurazione di Reality. Per mobile, v2rayNG e V2Box supportano entrambi l’importazione tramite codice QR, rendendo la configurazione rapida.
📋 NOTA: La disponibilità delle applicazioni client per piattaforme Apple cambia frequentemente. Se un’app elencata non è disponibile nella tua regione, controlla il sito ufficiale del progetto, l’elenco dell’App Store o il percorso TestFlight prima di assumere che sia il protocollo stesso a essere il problema.
Collegare il Tuo Primo Client
Procediamo con la connessione di un client Windows utilizzando v2rayN: il processo è simile su altre piattaforme, ma questo ti offre un esempio completo.
Passo 1: Scarica v2rayN
Visita https://github.com/2dust/v2rayN/releases e scarica l’attuale build desktop per Windows. A partire dal 2026, l’opzione più semplice è di solito v2rayN-windows-64-desktop.zip (o il pacchetto desktop equivalente attuale mostrato nella pagina di rilascio).
Passo 2: Estrai e Esegui
Estrai il ZIP in una cartella (ad esempio, C:v2rayN). Esegui v2rayN.exe. Le recenti build desktop sono tipicamente autonome, quindi di solito non è necessario installare un runtime desktop .NET separato. L’applicazione appare nella barra di sistema.
Passo 3: Importa la Configurazione
Per questa connessione, utilizza l’URL VLESS diretto da 3x-ui — quello che inizia con vless:// — non l’URL di abbonamento. Se il tuo link Reality esportato manca di valori richiesti come pbk= o sid=, torna alla sezione precedente di 3x-ui e utilizza invece i valori manuali dalle impostazioni inbound.
In v2rayN, apri il menu Configurazione nell’area in alto a sinistra della finestra. Il metodo più semplice è copiare l’URL VLESS diretto da 3x-ui e poi selezionare Configurazione → Importa Link di Condivisione dagli appunti. Nella maggior parte delle build, puoi anche semplicemente premere Ctrl+V. Assicurati di aver copiato prima l’URL VLESS diretto, in modo che l’app possa incollare il valore.
Se l’importazione tramite appunti non è l’opzione desiderata, puoi utilizzare anche il codice QR o l’importazione manuale.
Passo 4: Connetti
Dopo che il client è stato importato, per rendere attivo il tunnel tra il client Windows e il server, premi “Abilita tunnel” in fondo all’interfaccia di v2rayN.
Passo 5: Verifica
Apri il tuo browser e visita https://whatismyipaddress.com/ o https://ip.sb. L’indirizzo IP visualizzato dovrebbe essere l’indirizzo IP del tuo server, non il tuo IP locale. Questo conferma che il tuo traffico sta passando attraverso la VPN.
Verifica della Tua Configurazione
La verifica della connessione conferma che tutto funziona come previsto. Oltre a controllare il tuo indirizzo IP nel browser, ci sono alcuni test aggiuntivi che vale la pena eseguire.
Controllo Indirizzo IP: Visita https://whatismyipaddress.com/ o https://ip.sb mentre sei connesso. L’IP visualizzato dovrebbe corrispondere all’IP del tuo server VPS, non al tuo IP domestico o di rete locale.
Test di Perdita DNS: Visita https://dnsleak.com o https://browserleaks.com/dns e esegui il test. Un client configurato correttamente non dovrebbe esporre i tuoi normali risolutori DNS locali mentre il proxy è attivo.
Problemi Comuni e Soluzioni
| Problema | Causa | Soluzione |
|---|---|---|
| Nessuna connessione | Porta 443 bloccata | Controlla il firewall: ufw allow 443/tcp e console del fornitore cloud |
| Il pannello non si apre | URL errato o vecchia /panel assunzione | Utilizza l’esatto URL HTTPS stampato dall’installatore |
| Il link importato non si connette | Link Reality mancante pbk o sid | Ispeziona il link o passa alla configurazione manuale del client |
| Timeout di connessione | SNI errato | Verifica che il SNI corrisponda (www.microsoft.com) nelle impostazioni del client |
| Errore TLS | Impronta errata o valori Reality non corrispondenti | Imposta l’impronta su chrome e ricontrolla SNI, chiave pubblica e ID breve |
| Velocità lenta | BBR non abilitato | Riabilita BBR secondo la sezione di preparazione del server |
| “Nessuna risposta dal server” | Blocco del firewall | Controlla sia il firewall del server che i gruppi di sicurezza del fornitore cloud |
Se incontri problemi, verifica che la configurazione del tuo client corrisponda esattamente a ciò che è stato generato in 3x-ui: l’UUID, il SNI, la chiave pubblica, l’ID breve e il flusso devono corrispondere tra server e client.
Prossimi Passi & Opzioni Avanzate
Ora hai una VPN VLESS + Reality funzionante. Da qui, sono disponibili diversi miglioramenti:
Aggiungi un inbound di backup con attenzione: Se hai davvero bisogno di un fallback, puoi aggiungere qualcosa come VMess + WebSocket come inbound secondario. Ricorda solo che ogni inbound extra aumenta la complessità e ti dà un’altra superficie da proteggere e risolvere.
Scala per più utenti: Crea client aggiuntivi in 3x-ui per membri della famiglia o dispositivi. Ognuno ottiene un UUID unico e puoi monitorare l’uso separatamente.
Ottimizzazione delle prestazioni: BBR è già abilitato, ma puoi esplorare l’ottimizzazione TCP/UDP, la regolazione del buffer di rete e la regolazione TCP lato server per miglioramenti marginali.
Target SNI alternativi: Anche se Microsoft/Apple/Google sono affidabili, alcuni utenti preferiscono www.oracle.com o altri target. Il principio rimane lo stesso: qualsiasi sito con certificati TLS 1.3 validi funziona.
Sicurezza del pannello: Limita la porta del pannello al tuo IP amministrativo se possibile, ruota le credenziali se le hai scelte manualmente e considera di installare Fail2Ban per proteggere il pannello da tentativi di brute-force.
Conclusione
VLESS + Reality è una forte opzione auto-ospitata per il 2026 se hai bisogno di una configurazione che si mimetizzi meglio rispetto ai protocolli VPN tradizionali. Il suo vantaggio non è l’invisibilità magica; è che il traffico appare molto più simile al normale traffico web crittografato rispetto alle connessioni in stile OpenVPN o WireGuard su reti fortemente filtrate.
Se comprendi il modello mentale—l’impronta TLS simile a quella di un browser, il materiale chiave di Reality, un target credibile e una porta HTTPS standard—avrai un’esperienza molto più semplice nel distribuire, debug e mantenere la configurazione. Da qui, i prossimi passi naturali sono stringere la sicurezza del pannello, aggiungere più dispositivi client e convalidare quali target e app client funzionano meglio per il tuo ambiente. Per l’hosting, fornitori come AvaHost possono offrirti una base stabile per eseguire la tua configurazione VLESS + Reality, garantendo un uptime affidabile e una gestione semplice.
Messaggi correlati
