Italiano
Guida VLESS + Reality: Configurazione Proxy Sicura
Parole chiave
Prima di iniziare la configurazione, ecco i termini principali che probabilmente avranno bisogno 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 a HTTPS normale utilizzando impronte TLS simili a quelle del browser e una convalida speciale basata su chiavi. |
| 🔍 DPI (Deep Packet Inspection) | Una tecnica di filtraggio di rete che analizza i modelli di pacchetti, gli handshake e le impronte dei protocolli per identificare e bloccare il traffico come VPN e proxy. |
| 🖥️ VPS | Un Virtual Private Server che affitti e controlli da remoto, che funge da macchina host per la tua configurazione VLESS + Reality. |
| ⚙️ 3x-ui | Un pannello di gestione basato su web per Xray che ti consente di creare inbound, utenti e impostazioni Reality senza modificare manualmente JSON. |
| 🚀 Xray | Il motore proxy principale in esecuzione sotto 3x-ui che gestisce effettivamente VLESS, Reality, routing e connessioni client. |
| 🆔 UUID | Un identificatore univoco assegnato a ogni client e utilizzato da VLESS come valore di autenticazione principale. |
| 🌐 SNI | Server Name Indication, un campo TLS che comunica al server quale hostname è richiesto e deve corrispondere correttamente alla configurazione target di Reality. |
| 🧬 Coppia di chiavi x25519 | La coppia di chiavi pubblica/privata utilizzata da Reality in modo che i client approvati possano completare la connessione mentre i probe indesiderati vengono trattati diversamente. |
| 🔑 Chiave pubblica vs chiave privata | La chiave pubblica è condivisa con il client in modo che possa connettersi, mentre la chiave privata rimane solo sul server e non deve mai essere esposta. |
| 🧭 Impronta uTLS | Un’impronta TLS client che imita il browser, come chrome, utilizzata per far sembrare la connessione come traffico ordinario del browser. |
| 📡 Inbound | La configurazione del listener 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. |
| ✅ Convalida ACME | Il passaggio di verifica pubblica utilizzato da servizi di certificati come Let’s Encrypt per confermare che il tuo server o dominio è raggiungibile e autorizzato a richiedere il certificato. |
Configurazione di VLESS VPN con Reality Stealth nel 2026
La frustrazione è familiare: configuri un server VPN, tutto funziona perfettamente, e poi una mattina ti svegli per scoprire che è stato bloccato. La connessione che funzionava ieri oggi non funziona più. Nessun cambiamento da parte tua, eppure improvvisamente non funziona nulla. Non è uno scenario ipotetico—è la realtà dell’utilizzo di protocolli VPN tradizionali nel 2026, dove la tecnologia di deep packet inspection si è evoluta per identificare e bloccare anche il traffico correttamente crittografato.
La soluzione non è un algoritmo di crittografia diverso o un protocollo più veloce—è un approccio fondamentalmente diverso a come il tuo traffico appare sulla rete. VLESS combinato con il protocollo stealth Reality è uno degli approcci self-hosted più efficaci disponibili nel 2026 per rendere il traffico proxy molto più simile al traffico HTTPS ordinario. Questa guida ti guida attraverso la distribuzione del tuo server VLESS + Reality utilizzando il pannello di controllo 3x-ui, dalla comprensione del perché questo approccio funziona fino ad avere una connessione funzionante sul tuo dispositivo.
Il Problema: Perché le VPN Standard Vengono Bloccate
I tempi in cui un semplice server OpenVPN o WireGuard funzionava in modo affidabile per mesi—o addirittura anni—sono finiti. La tecnologia Deep Packet Inspection (DPI) ha fatto progressi drammatici, 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 straordinaria precisione.
Considera cosa accade quando ti connetti utilizzando OpenVPN o WireGuard standard. Il traffico è crittografato, ma ha comunque una forma riconoscibile. OpenVPN spesso espone un handshake TLS e un modello di traffico che non assomiglia a una sessione browser ordinaria. WireGuard non utilizza TLS affatto, ma il suo handshake basato su UDP e il comportamento dei pacchetti sono comunque abbastanza distintivi da risaltare sulle 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 server VPN appena distribuito poteva funzionare per mesi prima di essere rilevato, ora i nuovi server possono essere identificati entro giorni o addirittura ore dalla messa in servizio. 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—che faccia sembrare il tuo traffico come qualcos’altro completamente diverso.
Cos’è VLESS? Il Protocollo Spiegato
VLESS sta per “VMess Less”—un nome che riflette direttamente la sua filosofia di progettazione. È stato creato come successore più leggero e semplice del protocollo VMess, che era il protocollo di trasporto predefinito originale nel progetto V2Ray. Mentre 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 proxy, non come 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 quello che ti aspetti da una VPN: il tuo traffico sembra provenire dall’indirizzo IP del server. Ma questa architettura proxy è precisamente il motivo per cui VLESS funziona così bene con Reality, poiché il sovraccarico del protocollo più leggero consente al meccanismo di stealth di operare senza interferenze.
Il design proxy significa anche meno sovraccarico rispetto ai protocolli VPN tradizionali. Non c’è un’interfaccia tunnel a livello kernel da gestire, nessun livello di crittografia aggiuntivo oltre a quello necessario, e il protocollo è stato progettato da zero per funzionare con i moderni meccanismi di stealth 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 la Realtà: La Tecnologia Invisibile
Reality è ciò che trasforma VLESS da un semplice 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 quello che stai facendo, Reality fa sembrare il tuo traffico come qualcos’altro completamente diverso.
Reality realizza questo attraverso una tecnica che opera a livello di TLS handshake. Quando un client si connette al tuo server, invia un TLS ClientHello che imita un browser reale—utilizzando la libreria uTLS per replicare l’impronta digitale di Chrome, Firefox o un altro browser popolare. Il server quindi valida la connessione utilizzando il materiale chiave di Reality e i parametri client costruiti attorno a una coppia di chiavi x25519. Se il client presenta i valori 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 legittimo come www.microsoft.com o www.apple.com. Per il sistema di sondaggio, il tuo server sembra un sito web normale piuttosto che un endpoint proxy ovvio.
Pensa a indossare un’uniforme. Una 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 l’uniforme 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 digitale 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 perché questo funzioni. I metodi di invisibilità precedenti richiedevano di possedere un dominio e ottenere certificati Let’s Encrypt, il che creava una traccia cartacea e complessità aggiuntiva. Reality non richiede nulla se non un indirizzo IP VPS. I siti web target (Microsoft, Apple, Google) hanno un uptime quasi del 100% e supportano il protocollo TLS 1.3 più recente, rendendoli ancore perfette per questa tecnica.
La porta 443 dà a questo travestimento la migliore possibilità di mimetizzarsi. Il traffico HTTPS standard normalmente utilizza la porta 443, quindi mantenere Reality su quella porta rende la connessione molto più simile alla normale navigazione web. Altre porte potrebbero funzionare tecnicamente, ma indeboliscono il camuffamento perché non corrispondono più alla forma predefinita del traffico HTTPS quotidiano.
Malintesi Comuni
Prima di procedere, affrontiamo tre malintesi che confondono chi esplora 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, da una prospettiva funzionale per l’utente, fornisce esattamente quello che ti aspetteresti da una VPN: il tuo traffico internet sembra provenire dall’indirizzo IP del server. La distinzione è importante per gli ingegneri di rete ma raramente importa per gli utenti finali.
“Reality ha bisogno di un dominio.” Questo era vero per le tecniche di stealth precedenti che utilizzavano domini di proprietà e certificati Let’s Encrypt. Reality è stato specificamente progettato per funzionare senza alcun dominio che controlli. Utilizza la mimesi dell’impronta digitale del browser e l’autenticazione della chiave x25519, il che significa che non hai bisogno di registrare, gestire o rinnovare nulla. Configuralo una volta e continuerà a funzionare.
“Questo è inattaccabile.” Niente è inattaccabile. Reality è altamente resistente al rilevamento e al blocco perché assomiglia genuinamente al normale traffico HTTPS. Ma non è immune ai futuri miglioramenti della tecnologia DPI, al potenziale fingerprinting del protocollo o agli attacchi mirati. Quello che fornisce è la migliore protezione disponibile nel 2026 contro le forme più comuni di filtraggio di rete. Trattalo come una soluzione robusta, non come uno scudo magico.
Cosa Ti Serve Prima di Iniziare
Ti servirà un VPS da qualsiasi provider (ad esempio AvaHost), e servizi simili funzionano altrettanto bene. Per prestazioni tipiche single-user, un piano base con 1 core CPU e 1GB di RAM è sufficiente. Il server deve eseguire Ubuntu 22.04 LTS o 24.04 LTS; queste versioni hanno il supporto del kernel per le funzionalità di rete richieste già incluso.
L’accesso root SSH è essenziale. Hai bisogno della capacità di connetterti al tuo server tramite la riga di comando ed eseguire comandi privilegiati. La maggior parte dei provider VPS lo offre per impostazione predefinita—riceverai un indirizzo IP, un nome utente (solitamente 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 in dettaglio nella sezione delle applicazioni client più avanti in questa guida.
Un vantaggio significativo del metodo Reality: non hai bisogno di un dominio che controlli. Molte configurazioni stealth richiedono di registrarne e gestirne uno, ma Reality può funzionare direttamente dall’IP del VPS mentre prende in prestito l’aspetto di una destinazione TLS legittima.
Una breve nota su considerazioni legali: Le tecniche descritte in questa guida sono intese per esigenze legittime di privacy e accesso. Le leggi di filtraggio di Internet variano significativamente per 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
Con i prerequisiti verificati, prepariamo il server. Questa fase ottimizza il tuo VPS prima di installare qualsiasi software, garantendo le massime prestazioni fin dall’inizio.
💡 CONSIGLIO: Utilizza BBR prima di distribuire — spesso migliora il throughput e la latenza su link con vincoli o latenza più elevata.
Per prima cosa, aggiorna i pacchetti di sistema. Questo assicura che tu abbia gli ultimi aggiornamenti di sicurezza e le dipendenze richieste:
apt update && apt upgrade -y
Questo passaggio potrebbe richiedere 1-5 minuti a seconda del tuo provider VPS e della velocità della rete. Alcuni provider pre-aggiornano le loro immagini durante la distribuzione, 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 affidarsi principalmente alla perdita di pacchetti come segnale, tenta di modellare la larghezza di banda disponibile e il tempo di round-trip più direttamente, il che può migliorare il throughput e la reattività su alcuni link VPS.
# Verify BBR module is available
lsmod | grep tcp_bbr
Se non appare nulla, 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.conf
Verifica che BBR sia attivo:
sysctl net.ipv4.tcp_congestion_control
sysctl net.ipv4.tcp_available_congestion_control
Dovresti vedere bbr come algoritmo attivo.
Alcuni sistemi traggono vantaggio da un riavvio dopo l’abilitazione di BBR — assicura che il modulo si carichi correttamente e che tutte le ottimizzazioni di rete abbiano effetto:
reboot
Ora assicurati che la porta 443 sia raggiungibile. Se prevedi di utilizzare il flusso Let’s Encrypt integrato dell’installer 3x-ui per il pannello, consenti anche 80/tcp — quella porta viene utilizzata per la convalida del certificato ACME, non per il pannello stesso. Se il tuo provider 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 è solitamente 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
⚠️ AVVERTENZA: La porta 443 è fortemente consigliata perché corrisponde al traffico HTTPS normale. Altre porte potrebbero funzionare tecnicamente, ma si mimetizzano meno naturalmente e rendono la configurazione più facile da rilevare.
Il tuo server è ora ottimizzato e pronto per l’installazione di 3x-ui.
Installazione del Pannello 3x-ui
Prima di eseguire l’installer, nota un requisito facile da trascurare: se desideri che la configurazione Let’s Encrypt integrata dell’installer emetta un certificato SSL per il pannello, 80/tcp deve essere aperto e raggiungibile da internet pubblico. Questa porta di validazione 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’installer non iniziano con il menu numerato più vecchio Install / Update / Uninstall che molti tutorial mostrano ancora. Invece, lo script avvia 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 assomiglia a questo:
- Scegli se impostare una porta del pannello personalizzata o lasciare che l’installer ne generi una casuale.
- Lascia che l’installer generi un nome utente, una password e un webBasePath casuali.
- Scegli come configurare l’SSL del 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 validazione ACME. Potresti eseguire il pannello su una porta casuale come 13525 e avere comunque bisogno che 80/tcp pubblico sia aperto affinché Let’s Encrypt possa validare il certificato.
La regola importante è semplice: utilizza le credenziali esatte, il percorso e l’URL stampati dal tuo installer, non supposizioni copiate da tutorial più vecchi.
Il tuo output finale avrà un aspetto 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 dello stato:
- Se vedi Web server running HTTPS …, l’SSL del pannello 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’URL esatto, il nome utente e la password generati dal tuo installer. Non supporre che il percorso sia /panel e non supporre che le credenziali siano admin/admin a meno che il tuo installer non lo dica esplicitamente.
💡 SUGGERIMENTO 1: Per visualizzare di nuovo le impostazioni attuali del pannello e stampare l’URL di accesso, nella CLI esegui il comando “x-ui” e scegli il numero 10 “View Current Settings” dall’output del menu.
💡 SUGGERIMENTO 2: Se l’URL di accesso non si carica, assicurati che la porta del pannello 3x-ui sia aperta nel 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’installer 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 validazione di Let’s Encrypt. In quel caso, il pannello potrebbe comunque installarsi e avviarsi, ma l’emissione del certificato fallisce.
Correggi prima il firewall:
ufw allow 80/tcp
ufw status
Se il tuo provider VPS ha un firewall cloud o un livello di gruppo di sicurezza, consenti 80/tcp anche lì. Quindi riesegui la configurazione del certificato del pannello dallo script di gestione 3x-ui:
x-ui
Per un certificato del pannello basato su IP, scegli:
- 19 → 6 (Get SSL for IP Address)
Per un certificato del pannello basato su dominio, scegli:
- 19 → 1 (Get SSL (Domain))
Dopo l’emissione del certificato, verifica di nuovo:
systemctl status x-ui
Vuoi che l’output dello stato mostri Web server running HTTPS … prima di continuare.
💡 SUGGERIMENTO: Salva immediatamente le credenziali generate e l’URL del pannello. Nota inoltre che il riepilogo dell’installer può essere fuorviante se l’emissione del certificato fallisce — se il blocco finale stampa un URL HTTPS ma systemctl status x-ui mostra ancora HTTP, affidati all’output dello stato del servizio e correggi SSL prima di procedere.
Configurazione VLESS + Reality Inbound
Questo è il passaggio di configurazione critico in cui il tuo sistema simile a una VPN viene effettivamente creato. All’interno del pannello 3x-ui, accedi a Inbounds → Add Inbound.
Configura i campi come segue:
| Campo | Valore | Note |
|---|---|---|
| Protocol | VLESS | Seleziona dal menu a discesa |
| Listen IP | 0.0.0.0 | Default / tutte le interfacce |
| Port | 443 | Consigliato per il mascheramento HTTPS più naturale |
| Client → Authentication | Lascia vuoto / default | Non utilizzare Get New keys per questa configurazione di base |
| Client → decryption | none | Obbligatorio per VLESS |
| Client → encryption | none | Lascia al default |
| Client → Flow | xtls-rprx-vision | Imposta questo nella sottosezione Client. Se non vedi ancora questo campo, imposta prima Transmission su TCP (RAW) e Security su reality. |
| Transmission | TCP (RAW) | Utilizza il trasporto TCP diretto |
| Security | reality | Seleziona dalle opzioni di sicurezza |
| uTLS | chrome | Utilizza un fingerprint browser comune |
| Target | www.microsoft.com:443 | Target TLS 1.3 stabile per fallback/probing |
| SNI | www.microsoft.com | Mantienilo allineato con Target |
| Short IDs | Genera o utilizza il default del pannello | Copia un valore generato al client |
| SpiderX | / | Default semplice |
| Public Key | Genera con Get New Cert | Copia questo al client |
| Private Key | Genera con Get New Cert | Mantieni questo solo sul server |
📋 NOTA: Lascia gli altri campi visibili — come Total Flow, Traffic Reset, Duration, Fallbacks, Proxy Protocol, HTTP Obfuscation, Sockopt, External Proxy, Show, Xver, Max Time Diff, Min Client Ver, Max Client Ver, Sniffing e i campi ML-DSA — ai loro default per questa configurazione di base.
Infine, fai clic su Save per creare l’inbound.
⚠️ AVVERTENZA: La porta 443 è il default migliore perché corrisponde al traffico HTTPS ordinario. Se la modifichi, l’inbound potrebbe comunque funzionare, ma non si mimetizza più così bene.
⚠️ AVVERTENZA: Il target Reality deve supportare TLS 1.3 — Microsoft, Apple e Google sono scelte sicure. Utilizzare un target che non supporta TLS 1.3 causerà il fallimento di Reality, poiché il protocollo è progettato specificamente per gli handshake TLS 1.3.
Il motivo per cui questi valori sono importanti: la porta 443 ti dà il profilo HTTPS più credibile, un target TLS 1.3 stabile fornisce ai probe un posto legittimo dove atterrare, e il fingerprint chrome mantiene il lato client allineato con uno dei fingerprint browser più comuni su internet. Inizia in modo semplice, ottieni un percorso funzionante, quindi espandi in seguito se hai bisogno di più target.
Gestione degli utenti in 3x-ui
Con l’inbound configurato, è necessario creare connessioni utente che i tuoi dispositivi utilizzeranno per l’autenticazione. In 3x-ui, accedi a Inbounds → [Fai clic sul menu del tuo inbound VLESS] → Add Client.
Ogni utente riceve un UUID univoco (generato automaticamente), insieme a un’email per l’identificazione e limiti facoltativi di traffico/scadenza. Quando crei un client, il pannello genera i valori necessari per la connessione: indirizzo del server, UUID, flow, chiave pubblica, short ID e impostazioni correlate a SNI.
Premendo il segno più (“+”) dell’inbound selezionato, apparirà l’elenco degli utenti.
Esportazione di 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 modale QR
- Icona Info → apre il modale dei dettagli
Questi corrispondono ai primi due metodi di condivisione.
Codice QR: Fai clic sull’icona QR del client. Se gli abbonamenti sono abilitati, il modale QR potrebbe mostrare due codici QR:
- Abbonamento → un QR per l’URL di abbonamento del client
- Client QR (etichettato con l’email o l’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 gli aggiornamenti automatici. Il QR del client è l’importazione diretta una tantum per quel client specifico.
Link di condivisione / URL: Fai clic sull’icona Info del client. Nel modale dei dettagli, potresti visualizzare due tipi di esportazione di testo:
- URL di abbonamento → un endpoint di abbonamento aggiornabile
- URL → l’URI VLESS Reality diretto per quel client
Utilizza il pulsante di copia accanto alla sezione URL per l’importazione da desktop.
Come minimo, un URI Reality diretto utilizzabile dovrebbe includere valori popolati come:
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 recupero; la configurazione restituita contiene i parametri Reality effettivi.
Alcune versioni di 3x-ui hanno avuto bug nei link di condivisione Reality in cui pbk= è vuoto. Se l’URI diretto non contiene pbk= o sid=, non fidarti ciecamente. In tal caso, utilizza invece la configurazione manuale.
Configurazione manuale: Non esiste un pulsante di esportazione “configurazione manuale” separato. In pratica, la configurazione manuale significa inserire i valori direttamente nell’app client o comporre e verificare tu stesso l’URI VLESS Reality finale dai valori grezzi. Raccogli i valori richiesti da:
- il modale Infoindirizzo del server, porta, UUID, flow e l’URI diretto
- le impostazioni Reality dell’inbound: SNI, chiave pubblica, short ID, fingerprint (chrome) e SpiderX (/) se necessario
Puoi creare più utenti per dispositivi diversi o persone diverse. Ogni UUID è indipendente, quindi la revoca dell’accesso per un utente non influisce su altri.
Configurazione Manuale di Xray (Breve)
Alcuni utenti preferiscono non utilizzare un’interfaccia grafica e desiderano modificare direttamente la configurazione di Xray. Su un’installazione standard di 3x-ui su Linux, la configurazione runtime attiva viene 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 dal database, quindi le modifiche manuali possono essere sovrascritte quando Xray si riavvia o quando salvi le modifiche nel pannello.
Prima di modificarlo, crea un backup:
cp /usr/local/x-ui/bin/config.json /usr/local/x-ui/bin/config.json.bak
La modifica manuale può essere utile per test rapidi o debug, ma un JSON non corretto può impedire l’avvio di Xray. Se 3x-ui soddisfa le tue esigenze, utilizza il pannello per le modifiche permanenti e usa le modifiche dirette di config.json solo per i 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 system tray |
| macOS | V2Box, Streisand | V2Box è gratuito; Streisand è disponibile 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 Reality. Per i dispositivi mobili, sia v2rayNG che V2Box supportano 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 presumere che il problema sia il protocollo stesso.
Connessione del Primo Client
Procediamo con la connessione di un client Windows utilizzando v2rayN—il processo è simile su altre piattaforme, ma questo ti fornisce un esempio completo.
Passaggio 1: Scarica v2rayN
Visita https://github.com/2dust/v2rayN/releases e scarica la build desktop Windows attuale. A partire dal 2026, l’opzione più semplice è solitamente v2rayN-windows-64-desktop.zip (o il pacchetto desktop equivalente attuale mostrato nella pagina delle release).
Passaggio 2: Estrai ed Esegui
Estrai il file ZIP in una cartella (ad es. C:v2rayN). Esegui v2rayN.exe. Le build desktop recenti sono generalmente autonome, quindi di solito non è necessario installare un runtime .NET desktop separato. L’applicazione appare nel vassoio di sistema.
Passaggio 3: Importa Configurazione
Per questa connessione, utilizza l’URL VLESS diretto da 3x-ui — quello che inizia con vless:// — non l’URL di sottoscrizione. Se il tuo link Reality esportato non contiene valori richiesti come pbk= o sid=, torna alla sezione 3x-ui precedente e utilizza i valori manuali dalle impostazioni inbound.
In v2rayN, apri il menu Configuration nell’area in alto a sinistra della finestra. Il metodo più semplice è copiare l’URL VLESS diretto da 3x-ui e quindi selezionare Configuration → Import Share Links from clipboard. Sulla 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 da clipboard non è l’opzione desiderata, è possibile utilizzare anche il codice QR o l’importazione manuale.
Passaggio 4: Connetti
Dopo che il client è stato importato, per attivare il tunnel tra il client Windows e il server, premi “Enable tunnel” nella parte inferiore dell’interfaccia v2rayN.
Passaggio 5: Verifica
Apri il tuo browser e visita https://whatismyipaddress.com/ o https://ip.sb. L’indirizzo IP visualizzato dovrebbe essere l’IP del tuo server, non il tuo IP locale. Questo conferma che il tuo traffico viene instradato attraverso la VPN.
Verifica della Configurazione
La verifica della connessione conferma che tutto funziona come previsto. Oltre a controllare l’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’indirizzo IP visualizzato deve corrispondere all’IP del tuo server VPS, non all’IP della tua rete domestica o locale.
Test di DNS Leak: Visita https://dnsleak.com o https://browserleaks.com/dns ed esegui il test. Un client configurato correttamente non dovrebbe esporre i tuoi normali resolver 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 la console del provider cloud |
| Il pannello non si apre | URL errato o vecchio presupposto /panel | Usa l’URL HTTPS esatto stampato dal programma di installazione |
| Il link importato non si connette | Link Reality mancante di pbk o sid | Ispeziona il link o passa alla configurazione manuale del client |
| Timeout della connessione | SNI errato | Verifica che SNI corrisponda (www.microsoft.com) nelle impostazioni del client |
| Errore TLS | Fingerprint errato o valori Reality non corrispondenti | Imposta il fingerprint su chrome e ricontrolla SNI, chiave pubblica e short ID |
| Velocità lenta | BBR non abilitato | Riabilita BBR secondo la sezione di preparazione del server |
| “Nessuna risposta dal server” | Firewall bloccante | Controlla sia il firewall del server che i gruppi di sicurezza del provider cloud |
Se riscontri problemi, verifica che la configurazione del client corrisponda esattamente a quella generata in 3x-ui—l’UUID, SNI, chiave pubblica, short ID e flow devono tutti corrispondere tra server e client.
Passaggi Successivi e Opzioni Avanzate
Ora hai una VPN VLESS + Reality funzionante. Da qui, sono disponibili diversi miglioramenti:
Aggiungi un inbound di backup con cautela: Se hai genuinamente bisogno di un fallback, puoi aggiungere qualcosa come VMess + WebSocket come inbound secondario. Ricorda solo che ogni inbound aggiuntivo aumenta la complessità e ti dà una superficie in più da proteggere e risolvere i problemi.
Scalabilità per più utenti: Crea client aggiuntivi in 3x-ui per familiari o dispositivi. Ognuno ottiene un UUID univoco e puoi tracciare l’utilizzo separatamente.
Ottimizzazione delle prestazioni: BBR è già abilitato, ma puoi esplorare l’ottimizzazione TCP/UDP, il tuning dei buffer di rete e il tuning TCP lato server per miglioramenti marginali.
Target SNI alternativi: Mentre 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 panel: Limita la porta del panel al tuo IP admin personale se possibile, ruota le credenziali se le hai scelte manualmente, e considera l’installazione di Fail2Ban per proteggere il panel dai tentativi di brute-force.
Conclusione
VLESS + Reality è un’opzione self-hosted robusta per il 2026 se hai bisogno di una configurazione che si integri meglio rispetto ai protocolli VPN tradizionali. Il suo vantaggio non è l’invisibilità magica; è che il traffico assomiglia molto più al traffico web crittografato ordinario rispetto alle connessioni in stile OpenVPN o WireGuard su reti pesantemente filtrate.
Se comprendi il modello concettuale—fingerprinting TLS simile a un browser, materiale chiave Reality, un target credibile e una porta HTTPS standard—avrai un’esperienza molto più facile nel distribuire, eseguire il debug e mantenere la configurazione. Da qui, i passaggi naturali successivi sono il rafforzamento della sicurezza del pannello, l’aggiunta di più dispositivi client e la convalida di quali target e app client funzionano meglio per il tuo ambiente specifico. Per l’hosting, provider come AvaHost possono fornire una base stabile per eseguire la tua configurazione VLESS + Reality, garantendo un uptime affidabile e una gestione semplice.
Post Correlati
