Hysteria 2: guida completa al protocollo, differenze rispetto a Hysteria 1, configurazione di server e client

Introduzione

Negli ultimi anni i sistemi di blocco e l'ispezione approfondita dei pacchetti sono diventati più precisi, aggressivi e subdoli. I tradizionali VPN su TCP perdono sempre più spesso velocità e prevedibilità, soprattutto nelle reti mobili e congestionate. In questo contesto, Hysteria 2 si è affermato come uno dei trasporti più pratici per un tunneling robusto su QUIC/UDP: avvio rapido, alta tolleranza alle perdite, mascheramento efficace e amministrazione semplice e ben studiata. In questo articolo esploreremo l'architettura del protocollo, le differenze chiave rispetto a Hysteria 1, le migliori pratiche per configurare server e client, oltre a fornire checklist, ottimizzazioni e casi reali.

Cosa otterrai: un modello mentale chiaro di Hysteria 2, una serie di configurazioni e passaggi collaudati, strumenti diagnostici, strategie di mascheramento e risposte ai quesiti più complessi. Il nostro obiettivo è che questo articolo diventi il tuo manuale pratico di riferimento per Hysteria 2 “da chi lavora per chi lavora”.

Basi

Che cos'è Hysteria 2 e perché QUIC/UDP

Hysteria 2 è un tunnel ad alte prestazioni su QUIC/UDP con autenticazione, crittografia TLS 1.3 e offuscamento opzionale. A differenza dei VPN basati su TCP, QUIC funziona sopra UDP, implementando il controllo di congestione e la consegna affidabile a livello di spazio utente. Questo significa praticamente: avvio più veloce, meno blocchi per perdita di pacchetti, comportamento migliore in reti instabili e nessun problema con il lento recupero delle sessioni TCP lunghe.

Dove Hysteria 2 dà il meglio

• Reti con alta latenza e perdite (reti mobili, Wi-Fi in ambienti congestionati).
• Funzionamento su reti dove il DPI si concentra su firme TCP, impronte TLS e pattern comportamentali insoliti.
• Carichi con molte richieste brevi: riscaldamento rapido della pipeline e minori overhead.

Differenze tra Hysteria 2 e Hysteria 1

• Modello di trasporto: Hysteria 1 supportava modalità di mascheramento aggiuntive (es. faketcp), mentre Hysteria 2 si concentra su QUIC/UDP puro e pulito, minimizzando artefatti riconoscibili.
• Pulizia del protocollo: migliorata compatibilità con i comportamenti tipici di QUIC e TLS 1.3, riducendo la possibilità di rilevamento di pattern specifici del trasporto.
• Offuscamento: in Hysteria 2 si usa un offuscamento leggero prima della stretta di mano TLS (es. modalità 'salamander') per nascondere i segnali DPI prima che venga stabilita la cifratura.
• Modello di autenticazione: semplificato, basato su password/token, con migliore ergonomia per scenari multi-client.
• Prestazioni: parametri di congestion control e buffering aggiornati alle best practice; affinati gli algoritmi per la valutazione iniziale della banda.
• Mascheramento/masquerade: più semplice configurare risposte “credibili” per scanner casuali e probe, riducendo il rischio di blocchi selettivi delle porte.

Approfondimenti

Stack di protocollo di Hysteria 2

• UDP come trasporto di base: minima complicazione legata al blocco Head-of-Line, indipendenza dalla macchina di stato TCP dei dispositivi di rete.
• QUIC: assicura crittografia a livello trasporto, controllo di congestione indipendente, multiplexing di flussi senza blocco globale.
• TLS 1.3 sopra QUIC: handshake veloci, ripresa delle sessioni, suite di cifratura compatte, limitata dispersione di metadata. Visibile di norma solo il SNI, se non si usa ECH (ancora poco diffuso in pratica).
• Offuscamento prima di TLS: leggero layer che rende il traffico iniziale meno prevedibile ai DPI, riducendo le probabilità di rilevamento tramite firma prima dell'instaurazione del canale protetto.

Autenticazione e modello di accesso

La pratica standard prevede password/token simmetrici, uno unico o un set per diversi utenti. Questo semplifica il deployment e l'integrazione di client multipiattaforma (desktop e mobile). Cambiare la password è un’operazione semplice e poco dispendiosa, ideale per rotazioni regolari.

Algoritmi e parametri di performance

• Stima iniziale banda (up/down): fornisci la banda in uscita/entrata prevista del client; il trasporto la utilizza come suggerimento per finestra e ritmo, riducendo lo “scalettamento” della pipeline.
• MTU e frammentazione: QUIC prevede un MTU minimo di 1200 byte. Su percorsi problematici è utile abilitare la frammentazione/limitare la dimensione dei datagrammi lato client (es. 1200 byte) per evitare PMTU blackhole.
• Keepalive: invii periodici minimi mantengono vivo lo stato NAT, evitando reset inattesi di sessioni lunghe e inattive.
• Multiplexing dei flussi: decine di stream bidirezionali simultanei senza blocchi reciproci velocizzano carichi web e scenari API.

Mascheramento da traffico comune

Gli elementi chiave per la plausibilità: porta 443/UDP, ALPN 'h3' (dove supportato dal client), certificato corretto e valido, SNI adeguato. In caso di accessi casuali esterni (scanner o client curiosi), il server può rispondere con contenuti statici o fare da proxy per un sito legittimo (masquerade), senza rivelarsi un servizio tunnel.

DPI e blocchi: tendenze 2026

• DPI ibrido: combinazione di criteri basati su firme e comportamenti: dimensione, frequenza, temporizzazione dei pacchetti e impronte TLS/QUIC persistenti.
• Limiti di velocità su UDP: alcuni provider limitano UDP, soprattutto su porte popolari. È cruciale testare porte alternative e configurare frammentazione controllata.
• Reputazione IP individuale: indirizzi VPN condivisi finiscono più facilmente in blacklist. Un IP dedicato riduce correlazioni massive e “rumori” di vicini.

Pratica 1: progettazione dell’architettura e profiling dei rischi

Step 1. Definisci gli obiettivi

• Connessione stabile per navigazione web e chiamate API.
• Resistenza a perdite e alta latenza (rete mobile o percorso “lungo”).
• Profilo basso di rilevamento: porta credibile, TLS valido, comportamento con minime “anomalie”.

Step 2. Scelta di piattaforma e collocazione

• Server: VPS leggero con supporto garantito UDP, 1–2 vCPU, 1–2 GB RAM sono sufficienti per iniziare. Storage 10–20 GB.
• OS: Linux LTS moderno, kernel aggiornato (per stack di rete e timer migliorati).
• Stack di rete: preferisci nftables, systemd-networkd o NetworkManager, chrony/ntpd per tempo preciso.

Step 3. Dominio, certificato, porta

• Dominio: nome neutro senza riferimenti a “vpn”. Idealmente un dominio a cui appoggiare un sito legittimo per masquerade.
• Certificato: certificato pubblico valido per il dominio, RSA o ECDSA. Auto-aggiornamento critico.
• Porta: 443/UDP di default per plausibilità; porta secondaria 8443/UDP o altra porta meno ovvia.

Step 4. Modello di segreti e rotazione

• Password/token nel file di configurazione server e client — unici, complessi, diversi da altri servizi.
• Rotazione regolare: ogni 1–3 mesi o in caso di leak.
• Segreti separati per gruppi di utenti — facilita il revoca degli accessi.

Checklist di progettazione

• UDP aperto su firewall e dalla console del provider.
• Tempo del server sincronizzato (senza grossi scostamenti).
• Certificato valido e auto-rinnovabile.
• Porta 443/UDP selezionata e porta di riserva impostata.
• Password e regole di rotazione definite.
• Contenuti masquerade pronti (pagina statica o proxy inverso).

Pratica 2: Configurazione del server Hysteria 2 su Linux

Prerequisiti

• Binario 'hysteria' compilato o installato con supporto Hysteria 2.
• Certificato valido e chiave privata in formato PEM.
• Permessi per l’esecuzione da utente dedicato senza accesso shell.

Configurazione server base (esempio)

Di seguito un esempio illustrativo YAML. I nomi dei campi possono differire in base alla versione: verifica con la tua build. Valori tra virgolette sono d’esempio; usa i tuoi segreti e percorsi.

• listen: ':443'
• tls:
•   cert: '/etc/hysteria/cert.pem'
•   key: '/etc/hysteria/key.pem'
• auth:
•   type: 'password'
•   password: 'S3cure-Long-Secret-Token'
• obfs:
•   type: 'salamander'
•   password: 'Another-Obfs-Secret'
• masquerade:
•   type: 'file'
•   dir: '/var/www/masq'
• quic:
•   alpn: ['h3']
•   max_idle_timeout: '30s'
•   disable_path_mtu_discovery: false
• bandwidth:
•   up: '50 Mbps'
•   down: '200 Mbps'

Sistema e sicurezza

• Crea utente: `useradd --system --no-create-home --shell /usr/sbin/nologin hysteria`.
• Permessi chiavi: `chown -R root:hysteria /etc/hysteria` e `chmod 640` sulla chiave.
• Apri porta: nftables o iptables per UDP 443 (e porta di riserva).
• SELinux/AppArmor: concedi i permessi necessari a binario e cartella di configurazione.

Servizio systemd (minimale)

• [Unit] Description='Hysteria 2 Server' After=network.target
• [Service] User=hysteria Group=hysteria AmbientCapabilities=CAP_NET_BIND_SERVICE CapabilityBoundingSet=CAP_NET_BIND_SERVICE ExecStart='/usr/local/bin/hysteria' 'server' '-c' '/etc/hysteria/config.yaml' Restart=on-failure
• [Install] WantedBy=multi-user.target

Abilita l’avvio automatico: `systemctl enable --now hysteria.service`. Controlla i log: `journalctl -u hysteria -f`.

Ottimizzazione di rete (kernel)

• net.core.rmem_max=67108864; net.core.wmem_max=67108864
• net.ipv4.udp_mem='262144 524288 1048576'
• net.ipv4.udp_rmem_min=4096; net.ipv4.udp_wmem_min=4096
• net.ipv4.ip_local_port_range='10000 65000'
• net.core.default_qdisc=fq (kernel moderni)

Applica tramite sysctl.d e ricarica parametri. Monitora limiti con `ss -u -a`, `ethtool -S`, `nstat`.

Masquerade: risposta credibile

• Tipo 'file': file statici in '/var/www/masq' (semplice sito placeholder).
• Tipo 'proxy': proxy inverso verso sito esterno (non sovraccaricare: l’obiettivo è realismo, non traffico elevato).

Verifica

• Porta UDP: `nmap -sU -p 443 tuo_IP` deve risultare aperta.
• Pacchetti QUIC: `tcpdump -ni any udp port 443` - verifica scambio Initial, Handshake.
• Certificato: verifica TLS 1.3 sulla porta QUIC (o browser con supporto HTTP/3 in modalità masquerade).

Pratica 3: Configurazione client (Desktop)

Opzione A: client nativo 'hysteria'

Esempio base di YAML client:

• server: 'tuo_dominio:443'
• auth:
•   type: 'password'
•   password: 'S3cure-Long-Secret-Token'
• obfs:
•   type: 'salamander'
•   password: 'Another-Obfs-Secret'
• tls:
•   sni: 'tuo_dominio'
•   insecure: false
• quic:
•   alpn: ['h3']
• bandwidth:
•   up: '20 Mbps'
•   down: '150 Mbps'
• socks5:
•   listen: '127.0.0.1:1080'
• http:
•   listen: '127.0.0.1:8080'

Avvia: `hysteria client -c client.yaml`. Nel browser configura proxy locale SOCKS5 127.0.0.1:1080 o HTTP 127.0.0.1:8080.

Opzione B: sing-box (client universale)

Esempio illustrativo JSON con outbound 'hysteria2' e inbound SOCKS locale. Usa virgolette singole per comodità (sostituisci con doppie in JSON reale):

• {
•  'inbounds': [ {'type':'socks','listen':'127.0.0.1','listen_port':1080} ],
•  'outbounds': [
•   { 'type':'hysteria2', 'server':'tuo_dominio', 'server_port':443, 'password':'S3cure-Long-Secret-Token', 'obfs':'salamander', 'obfs-password':'Another-Obfs-Secret', 'tls':{'enabled':true,'server_name':'tuo_dominio','alpn':['h3']}, 'udp_fragment':{'enabled':true,'length':1200,'interval':0}, 'multiplex':{'enabled':true,'max_streams':32} }
•  ]
• }

Avvia sing-box con questa configurazione e imposta nei programmi il proxy SOCKS locale. In caso di problemi MTU, riduci 'udp_fragment.length' a 1200 o anche 1180.

Opzione C: v2rayN / Clash Meta / Nekoray

• Importa profilo Hysteria 2 manualmente: inserisci server, porta, password, obfs 'salamander' e relativo password, SNI, abilita ALPN 'h3' (se supportato dal client).
• Configura proxy locale SOCKS/HTTP oppure attiva modalità TUN per intercettare tutto il traffico.

Test di velocità e stabilità

• Latency: `ping` verso server (per stima), quindi latenza reale delle app.
• Perdite: `mtr` verso server senza proxy e attraverso tunnel (indiretto).
• Banda: scarica file grandi, streaming video 1080p/4K, download paralleli; valuta stabilità oltre al picco velocità.

Pratica 4: Client mobili e router

Android: v2rayNG e simili

• Crea profilo Hysteria 2: indirizzo server, porta 443, password, obfs 'salamander' con la sua password, SNI = tuo dominio, abilita opzioni QUIC/HTTP3 se disponibili.
• Modalità: preferisci TUN/VPN per intercettazione sistema o proxy manuale per singole app.
• MTU: se si bloccano pagine, attiva frammentazione/riduci dimensione datagram a 1200.

iOS: Shadowrocket, FoXray e altri

• Importa configurazione Hysteria 2 o compila manualmente i campi. Verifica validità certificato server; evita insecure=true se non strettamente necessario.
• Profili bypass: aggiungi regole per escludere domini interni e reti locali.

OpenWrt/router: proxy trasparente

• Installa sing-box su router, crea outbound hysteria2 e inbound TUN.
• Instrada tutto il traffico via TUN, con eccezioni per subnet locali, NTP, aggiornamenti firmware.
• Testa dai client: stabilità video YouTube 4K, download in messenger, giochi online (verifica modalità UDP).

Pratica 5: strategie di mascheramento

Strategia base

• Porta 443/UDP, certificato pubblico valido, SNI corretto.
• ALPN 'h3' se supportato, masquerade 'file' o 'proxy'.
• Offuscamento 'salamander' con password diversa da quella principale.

Rafforzamenti

• Rotazione di porta e password ogni 1–3 mesi.
• Duplicazione punto d'ingresso: porta primaria 443 e secondaria (es. 8443/UDP) nelle configurazioni client.
• IPv6+IPv4: vettori aggiuntivi contro blocchi selettivi.
• Limitazione dimensione datagrammi (1200) per ridurre pattern di frammentazione.

Framework di risposta ai blocchi

1. Evento: degrado o blocco solo UDP 443.
2. Diagnosi: test UDP su porta di riserva; verifica log server; pcap in ingresso.
3. Risposta: switch client su porta di riserva; cambio password; se serve cambio SNI e dominio.
4. Consolidamento: aggiornamento masquerade, ottimizzazione MTU, riallocazione traffico tra IPv4/IPv6.

Pratica 6: Prestazioni e stabilità

Ottimizzazione kernel e rete

• Aumenta buffer rmem/wmem e UDP in base al carico.
• Imposta fq come qdisc di default per shaping più fluido delle code.
• Verifica CPU governor — modalità performance su istanze cariche riduce jitter timer.
• IRQ affinity e NUMA: assegna IRQ di rete a core dedicati sotto carico elevato.

Parametri client

• bandwidth up/down — indica valori realistici, non esagerare.
• udp_fragment length — 1200 su percorsi complessi, 1250–1350 dove sicuro (testa).
• multiplex max_streams — 16–64 per carico web, meno per giochi/realtà aumentata.

Monitoraggio

• Log server: livello warning/info in produzione, debug temporaneo per indagini.
• pcap selettivo: filtro udp e porta; osserva dimensioni e intervalli.
• Metriche sistema: latenza, perdite, CPU, softirq, drops driver NIC.

Pratica 7: gestione, aggiornamenti e sicurezza

Checklist operativa

• Auto-rinnovo certificati funzionante; notifiche di fallimento attivate.
• Rotazione password e revoca accessi in caso di compromissione client.
• Porta secondaria e profilo client pronti e testati.
• Log privi di eccessivi dettagli di segreti; rotazione log attiva.

Aggiornamenti

• Pianifica rolling restart in orari di basso carico.
• Tieni backup binario precedente.
• Controlla differenze formato config con esempio in ambiente di test.

Sicurezza

• Minimi permessi per processo, utente e gruppo dedicati.
• Firewall default deny, whitelist solo porte necessarie.
• Monitoraggio di picchi UDP anomali o scansioni.

Errori comuni e anti-pattern

• Certificato o SNI errati: causano fallimenti handshake e ritentativi sospetti.
• Solo TCP 443 aperta: dimenticata UDP, client non si connette.
• Bandwidth troppo alto: velocità irregolare, cadute sotto carico.
• Assenza di masquerade: porta con risposta “vuota” attira scanner.
• Stessa password per molti client: complicazioni per revoca e indagini incidenti.
• MTU troppo grande: blocchi dovuti a PMTU blackhole, soprattutto su reti mobili.
• Tempo server non valido: errori TLS e fallimenti inspiegabili.

Strumenti e risorse

Amministrazione e diagnostica

• tcpdump, Wireshark: acquisizione mirata per verificare pacchetti QUIC Initial/Handshake e dimensione datagrammi.
• nftables, iptables: regole per porte UDP e limiti base velocità.
• journalctl, systemd: gestione e consultazione log del servizio.
• iperf3 (UDP): valutazione grezza di banda e perdite.
• mtr: traceroute combinato con analisi perdita fino al server.

Applicazioni client

• hysteria (client e server), sing-box (client universale con TUN), v2rayN, Nekoray, Clash Meta, client mobili Android e iOS.
• OpenWrt: sing-box come servizio di sistema con TUN per tutta la rete.

Alternativa pratica all’installazione autonoma

vpn.how offre server VPN personali con IP dedicato. Le località, i protocolli e i prezzi disponibili sono indicati sul sito e nel tuo account. I metodi di pagamento e il totale vengono mostrati al pagamento. Scegli un server

Casi pratici e risultati

Caso 1: rete mobile con perdite 2–5%

• Condizioni: RTT 120–180 ms, perdite 2–5%, VPN TCP base offre velocità variabile 2–6 Mbps.
• Hysteria 2: alpn 'h3', udp_fragment 1200, bandwidth up/down 10/80 Mbps.
• Risultato: 12–18 Mbps stabili su tre download paralleli, video 1080p senza buffering e micro-lag quasi scomparsi.

Caso 2: Wi-Fi aziendale con DPI aggressivo

• Condizioni: filtro impronte TLS non standard, UDP bloccato su quasi tutte le porte, 443/UDP aperto.
• Hysteria 2: certificato valido, masquerade 'file' con sito semplice, obfs 'salamander'.
• Risultato: tunnel stabile, scanner vede un normale 443 con sito placeholder; banda media 30–40 Mbps in orario di lavoro.

Caso 3: router domestico con OpenWrt

• Condizioni: provider limita UDP in modo intermittente, IPv6 disponibile.
• Soluzione: sing-box su router, outbound hysteria2, TUN inbound per tutta la rete, porta di riserva 8443.
• Risultato: video 4K stabile, giochi UDP più prevedibili, minore latenza e jitter rispetto a VPN TCP.

FAQ

1) Hysteria 2 è HTTP/3 o un QUIC “proprio”?

Hysteria 2 usa QUIC e TLS 1.3; alcuni client permettono impostare ALPN 'h3' per sembrare HTTP/3. La logica tunnel è propria, non una completa implementazione proxy HTTP/3.

2) La porta 443/UDP è obbligatoria?

No, ma 443/UDP aumenta il realismo. Tieni sempre una porta di riserva in caso di blocchi selettivi su 443/UDP. Testa nella tua rete.

3) Posso usare un certificato self-signed?

Tecnicamente sì, attivando insecure sui client. In pratica peggiora il mascheramento e aumenta il rischio di rilevamento. Si raccomanda un certificato pubblico valido.

4) E l’ECH e la protezione del SNI?

ECH è ancora poco diffuso e complesso da integrare in tunnel generici. Considera sempre il SNI visibile, scegli un dominio neutro e un masquerade corretto.

5) Hysteria 2 va bene per i giochi?

Dipende dal gioco. Se il traffico è su TCP, Hysteria 2 aiuta contro perdite e jitter. Se usa UDP peer-to-peer “raw”, può essere utile la modalità UDP-proxy su client/app, ma non tutti i client la supportano direttamente.

6) Ha fallback su TCP?

Hysteria 2 non ha nativamente modalità TCP. Fallback va gestito a livello client: profili alternativi (WireGuard/IKEv2/OpenVPN) o trasporti separati. Prepara un “piano B” in anticipo.

7) Posso piazzare il server dietro un proxy inverso?

Proxy UDP è più complesso di TCP. Esistono alcune soluzioni per QUIC proxy, ma è più semplice e affidabile ascoltare direttamente la porta UDP server. Per il masquerade usa i meccanismi integrati.

8) Perché la velocità è inferiore alle aspettative?

Cause comuni: bandwidth hint troppo alto, buffer di sistema piccoli, problemi PMTU, limitazioni del provider su UDP. Riduci MTU a 1200, aumenta rmem/wmem, verifica porta secondaria.

9) Supporta accesso multiutente?

Sì, con password condivisa o segreti diversi. Per gestibilità è meglio fornire password separate a gruppi o utenti e tenere un registro.

10) Serve IPv6?

Preferibile. Lo stack duale aumenta la resilienza: se uno degrada o è filtrato, l’altro può restare operativo.

Conclusione

Hysteria 2 è un trasporto QUIC maturo e pratico per l’era dei blocchi aggressivi e delle reti instabili. Si avvia rapidamente, resiste bene alle perdite, si maschera naturalmente come traffico comune con configurazione TLS e ALPN adeguata e offre controllo all’amministratore: offuscamento pre-handshake, masquerade, consigli banda, controllo MTU e multiplexing. Abbiamo esaminato architettura, differenze con Hysteria 1, configurazioni server e client, ottimizzazioni, strategie di mascheramento, errori tipici e dati reali. Ora è tempo di pratica: monta un setup minimo, segui le checklist di progettazione e gestione, cattura qualche pcap in differenti scenari, apri la porta di riserva, imposta rotazione segreti e testa alcuni giorni in condizioni reali. La connettività stabile non è un punto fermo, ma un processo, e con Hysteria 2 diventa più trasparente e gestibile.