Sing-Box vs Xray-Core nel 2026: benchmark, DPI, protocolli e scelta per VPS

Introduzione: perché è un tema attuale e cosa scoprirai

Nel 2026 l’accesso a Internet non dipende solo dalla velocità e dal costo, ma anche dalla resistenza alla filtrazione del traffico. Il DPI (Deep Packet Inspection) è diventato più intelligente: analizza non solo IP e porte, ma anche il comportamento dei protocolli, le impronte TLS, i pattern del traffico. In questo scenario, la scelta tra due standard de facto per VPN e proxy fai-da-te — Sing-Box e Xray-Core — non è più questione di gusti. Conta performance, affidabilità, compatibilità e strategie pratiche contro i blocchi. Vedremo basi e argomenti avanzati, illustreremo metodologie e risultati dei benchmark 2026, forniremo istruzioni per VPS, checklist di tuning e casi d’uso. Alla fine avrai un quadro chiaro per scegliere in base alle tue esigenze, oltre a configurazioni e step pronti da applicare subito.

Basi: concetti fondamentali e terminologia

Cosa sono Sing-Box e Xray-Core

Sing-Box è un server/client modulare, focalizzato sui protocolli moderni (VLESS/Reality, Hysteria2, TUIC, Shadowsocks, Trojan), con attenzione alla resistenza al DPI, routing flessibile e supporto anticipato per nuovi trasporti. Scritto in Go, offre un ricco set di offuscamenti, uTLS, padding e catene di routing mature. Xray-Core deriva da V2Ray, è un server/client specializzato in VLESS, VMess, Trojan, Shadowsocks e trasporti avanzati (XTLS, Vision, HTTP/2, gRPC). I suoi punti di forza sono stabilità, compatibilità, ecosistema maturo e routing flessibile.

Perché tutto questo: DPI, protocolli e trasporti

DPI è una tecnologia di analisi del traffico a livello di pacchetto/sessione. Rileva firme QUIC/TLS, comportamenti TCP, header HTTP/2/3. Per bypassare si usano: mascheramento delle impronte TLS (uTLS), offuscamento dinamico e trasporti che si comportano come servizi legittimi. Nel 2026 il trend è chiaro: i protocolli basati su QUIC (Hysteria2, TUIC) assicurano miglior resistenza alle perdite e alta velocità su linee mobili e intercontinentali. VLESS/Reality e XTLS Vision rimangono lo standard d’oro per mimetizzarsi sotto TLS 1.3 verso siti reali.

Termini chiave

• VLESS/Reality — protocollo di autenticazione leggero VLESS con spoofing SNI lato server e handshake su dominio bait reale (senza MITM). Resistente a firme semplici.
• XTLS Vision — miglioramento della gestione TLS per minimizzare l’overhead, spesso usato con VLESS in Xray-Core.
• Hysteria2 — protocollo simile a QUIC con strategie aggressive di controllo di flusso e perdita. Ottimo su canali scadenti.
• TUIC — trasporto affidabile e veloce basato su QUIC, bilanciamento tra velocità e prevedibilità.
• uTLS — libreria che emula le impronte TLS di client noti (Chrome, iOS, Firefox).
• BBR — algoritmo di controllo congestionamento TCP che riduce il bufferbloat e aumenta la larghezza di banda.

Approfondimento: architettura, differenze e trend 2026

Differenze architetturali

Entrambi i progetti sono scritti in Go e utilizzano pipeline modulari: inbound (input), outbound (output), routing (regole). Sing-Box spesso implementa prima funzionalità resistenti al DPI, con focus su completo supporto Hysteria2/TUIC e uTLS flessibile su vari livelli di trasporto. Xray-Core primeggia nella maturità di VLESS/XTLS Vision e configurazioni stabili per HTTP/2 e trasporti gRPC. La differenza è importante: se cerchi massima performance su QUIC e tecniche nuove di evasione, Sing-Box è avanti. Se preferisci scenari consolidati con VLESS/VMess/Trojan e pipe mature per HTTP/2 e gRPC, Xray-Core è più comodo.

DPI nel 2026: cosa si cerca di rilevare

• Impronte TLS ClientHello/ServerHello e discrepanze tra SNI/ALPN.
• Pattern QUIC: RTT/pacchetti fissi, assenza di estensioni tipiche browser, timer idle non standard.
• Comportamento HTTP/2/3: header atipici, dimensioni frame, frequenza keep-alive.
• Segnali stocastici: distribuzione degli intervalli, entropia del payload, correlazioni di porte e reputazione IP.

In sintesi: vince lo stack che imita meglio traffico reale (uTLS, padding, ALPN corretti), randomizza comportamenti e si adatta ai segnali di rete (perdite, jitter, restart handshake, porte alternative).

Trend 2026

• Estensione UDP GSO/GRO nei kernel 5.x/6.x ha aumentato la performance del traffico QUIC. Vantaggio per Hysteria2/TUIC.
• Maggiore supporto a TLS 1.3 e ALPN h2/h3 su siti reali, facilitando la mimica Reality/XTLS Vision.
• Uso esteso di BBR2/BBRv3 nel cloud, che mitiga il bufferbloat sotto carichi elevati.
• Aumento delle euristiche DPI degli operatori: conta uno stack protocollo flessibile e percorsi di riserva.

Pratica 1: metodologia di benchmarking Sing-Box e Xray-Core nel 2026

Perché una metodologia separata

Misurare solo la «velocità di download» è un errore. Serve valutare: banda disponibile con diverse perdite, latenza, entropia del carico, effetto di core/tuning e resilienza al DPI (tempo prima del blocco, frequenza di restart handshake).

Test environment

• Classi VPS: 1 vCPU e 2 vCPU, 1–4 GB RAM; CPU AMD EPYC o Intel Xeon; reti 1–5 Gbps.
• Geografia: coppie intra-regionali (es. Francoforte-Amsterdam) e intercontinentali (Francoforte-Singapore, Londra-San Jose).
• OS: Ubuntu 22.04/24.04 o Debian 12, kernel 5.15+ o 6.x.
• Rete: BBR abilitato, fq qdisc; buffer UDP aumentati via sysctl.

Carichi

• Bulk: stream lungo 2–5 minuti, 1 e 8 connessioni parallele.
• Web mix: oggetti brevi da 64–512 KB, 50–200 RPS, simulazione pattern web.
• Loss/Latency: tc netem con delay 50–200 ms, perdite 0.5–2%, reorder 0.2%.
• Simulazione DPI: cambio porte, validazione SNI, controllo stabilità handshake.

Metriche

• Throughput (Mbps) su bulk e web mix.
• Latenti P95/P99 su transazioni brevi.
• CPU% server e client, RSS memoria.
• Time-to-first-byte su setup sessione.
• Failover time su cambio porta/SNI/availability upstream.

Strumenti

• iperf3 per bulk TCP/UDP (via tunnel proxy).
• wget/curl per TTFB e oggetti brevi.
• wrk2/vegeta per RPS stabile.
• tc per netem, pidstat per CPU, ss/nstat per socket/statistiche.

Risultati 2026 (pattern)

• Hysteria2/TUIC in Sing-Box: vantaggio con loss≥1% e RTT≥100 ms, +10–30% throughput e fino a 20–40% riduzione P95 latency vs stack equivalente HTTP/2/gRPC.
• VLESS/Reality in entrambi: TTFB minimi, handshake stabili con uTLS corretto e dominio bait valido.
• Xray-Core con XTLS Vision: comportamento prevedibile, basso overhead CPU su TCP pulito e setup curato.
• Focus sul core: passare da CUBIC a BBR2 aggiunge +5–15% banda nella maggior parte degli scenari, buffer UDP adeguati aggiungono ulteriori +5–10% su QUIC.

Nota: i numeri specifici dipendono da hardware e rete. La metodologia sopra ti permette di replicare i test e ottenere metriche personali.

Pratica 2: avvio rapido e corretta architettura di deployment

Scenari di deployment

• Single-host: Sing-Box o Xray-Core ascoltano su 1–2 porte, client si connettono direttamente. Pro: latenza minima. Contro: flessibilità ridotta.
• Reverse-proxy front: Nginx/HAProxy/Caddy su 443, terminazione TLS su dominio reale, forwarding al backend. Pro: mimetizzazione come sito, ALPN=«h2,h3». Contro: configurazione più complessa.
• Split-tunnel: solo subnet necessarie passano nel tunnel, resto su Internet locale. Pro: risparmio banda e minor fingerprint. Contro: bisogna gestire liste.

Passi base per il deployment

1. Scegli la location VPS vicina al tuo pubblico target (+/- 20–40 ms RTT risparmiati).
2. Installa kernel 5.15+ o 6.x, abilita BBR e fq (sysctl sotto).
3. Apri le porte necessarie in ufw/nftables (es. 443/tcp, 443/udp, 8443/udp per QUIC).
4. Genera la config per il protocollo scelto (VLESS/Reality o Hysteria2/TUIC).
5. Verifica il profilo uTLS (Chrome/Firefox/iOS) e un SNI valido.
6. Esegui test semplici con curl/wget, poi stress test con wrk2/iperf3.

Mini checklist sicurezza

• Disabilita login root con password, usa chiavi SSH.
• Applica aggiornamenti di sicurezza, riavvio automatico servizio in caso di crash (systemd Restart=always).
• Log: limita rotazione, monitora spazio disco.

Pratica 3: tuning del kernel e rete per TCP/QUIC

Impostazioni sysctl comuni

• Congestion control: net.ipv4.tcp_congestion_control=bbr, net.core.default_qdisc=fq.
• TFO: net.ipv4.tcp_fastopen=3 (client+server), se usi trasporti TCP.
• Buffer UDP: net.core.rmem_max=2500000, net.core.wmem_max=2500000 e aumentati rmem_default/wmem_default.
• Code: net.core.netdev_max_backlog=4096, net.core.somaxconn=4096.

Offload e timing

• Controlla GRO/GSO per UDP; se noti latenza anomala, prova a disabilitarli sull’interfaccia (ethtool -K).
• Configura intervalli keepalive per rapido rilevamento disconnessioni (soprattutto reti mobili).

Fine tuning BBR

BBR2/BBRv3 nei kernel recenti gestisce meglio l’accumulo in coda; verifica sysctl net.ipv4.tcp_ecn=0/1 per la tua rete (talvolta ECN riduce jitter, a volte no). Testa sul tuo percorso.

Pratica 4: scelta di protocollo e trasporto rispetto a DPI e rete

Matrice di scelta (semplificata)

• Mobili/alto RTT/perdite: Hysteria2 o TUIC (Sing-Box spesso offre +performance). Alternativa: VLESS/Reality con HTTP/3.
• Reti aziendali con ispezione HTTPS: VLESS/Reality oppure VLESS+XTLS Vision (Xray-Core), con uTLS corretto e SNI su CDN/sito reale.
• Canali stabili con ottimizzazione TCP: VLESS/Trojan via gRPC o HTTP/2 (entrambi i motori). Plus: latenze prevedibili.
• Impronta minima, semplicità client: Shadowsocks con cifrature 2022; ma contro DPI moderno serve offuscamento o migrazione a QUIC.

uTLS e mimetizzazione

• Scegli impronte Chrome/iOS adatte al traffico della tua regione. Impronte errate sono causa frequente di trigger DPI.
• ALPN deve corrispondere al comportamento applicativo: h2 per HTTP/2, h3 per QUIC; evita di lasciarlo vuoto.
• Padding e simulazione dei timing delle richieste brevi riducono l’entropia del flusso.

Reality/XTLS vs protocolli QUIC

VLESS/Reality e XTLS Vision sono ottimi quando serve mimetizzazione sotto sito reale e puoi mantenere domini bait. Hysteria2/TUIC sono ideali quando la resistenza e velocità su reti instabili sono critiche. Spesso vince un’architettura combinata: trasporto principale QUIC (Hysteria2/TUIC), riserva VLESS/Reality su 443 con SNI adeguato.

Pratica 5: config di riferimento e verifiche (breve)

VLESS/Reality

• Porta: 443/tcp (possibilmente anche 443/udp).
• SNI: dominio reale con A/AAAA corretti e comportamento TLS valido.
• uTLS: profilo Chrome 120+ (approssimativo) o mobile iOS per il pubblico target.
• Controlli: curl -vk --http2 https://sni.example.com deve comportarsi come un server normale, handshake senza allarmi.

Hysteria2

• Porta: udp non standard, es. 8443/udp; in caso di blocchi, rotazione.
• Parametri QUIC: modalità default per perdite ok, ma testa mimetizzazione keepalive e timer idle.
• Controlli: iperf3 -u -b 0 -t 30 tramite tunnel per stimare il plafond di banda.

TUIC

• Scelta bilanciata per carichi misti; testa ping sotto carico e download brevi 64–256 KB.
• Profilazione CPU con 8 flussi paralleli — TUIC a volte vince per prevedibilità P95.

Pratica 6: osservabilità e profilazione

Cosa monitorare

• CPU e RSS dei processi server e reverse-proxy.
• nstat per retransmits, inCsumErrors, UdpInErrors.
• ss -s riepilogo socket; conntrack per NAT.

Allarmi

• Calo throughput superiore al 30% in 5 minuti — attiva diagnostica rete/DPI.
• Aumento RTT > 2x a RPS costante — verifica sovraccarico canale/core (somaxconn, backlog).

Tracing

tcpdump/pcap su sessioni brevi per controllo TLS/ALPN e handshake. Per QUIC usa qlog (se disponibile nel client), verifica handshake flight e perdite.

Pratica 7: resilienza e tattiche anti-DPI

Rotazione e riserva

• Due trasporti su porte e stack diversi: principale QUIC (Hysteria2/TUIC), riserva VLESS/Reality su 443.
• Rotazione automatica di SNI/dominio bait via scheduler se frequenti interruzioni handshake.
• Usa SNI su CDN popolare con comportamento h2/h3 valido; evita domini sospetti o rari.

Trucchi comportamentali

• Intervalli keepalive casuali, padding fino a MTU reale.
• Limitazione dei picchi RPS se DPI reagisce a burst improvvisi.

Test linea

• tc netem localmente per simulare 1–2% perdite, verifica stabilità e riavvio flussi.

Errori tipici: cosa evitare

• Ignorare uTLS: impronta di default facilmente individuata dal DPI.
• Unica porta per tutto il traffico: mancanza di riserva aumenta downtime in caso di blocchi.
• Stack non ottimizzato: CUBIC + buffer UDP piccoli = perdita prestazioni 10–30%.
• SNI falso su dominio inesistente: subito un red flag.
• Mancanza di monitoraggio: latenza aumenta per settimane, utenti silenziosi, business in perdita.

Strumenti e risorse: cosa usare in pratica

Motori server

• Sing-Box: aggiornamenti rapidi, forti protocolli QUIC (Hysteria2/TUIC), ricco di uTLS e regole di routing. Ideale per sperimentatori e chi vuole il massimo da reti instabili.
• Xray-Core: stack maturo VLESS/XTLS Vision, stabilità, documentazione e comunità ampie. Perfetto per «setup e dimentica» su HTTP/2/gRPC e Reality.

Complementari

• Caddy/Nginx per fronting 443 con ALPN e HTTPS corretti.
• wrk2/vegeta, iperf3, tc, pidstat per misurazioni.

Alternativa: VPN personale come servizio

Se l’obiettivo non è costruire e mantenere lo stack, ma avere rapidamente un canale stabile con tracce minime nelle blacklist, una soluzione pratica è il servizio vpn.how. Perché funziona bene contro il DPI: ottieni un server VPN personale con IP dedicato (non condiviso), riducendo molto il rischio di blacklist esistenti. Sono supportati protocolli resistenti al DPI a seconda dei casi: WireGuard su porte non standard, IKEv2 su 4500/UDP, oltre a OpenVPN, L2TP, SSTP — scegli quello più adatto alla tua rete. La rete server copre nodi chiave: Mosca, San Pietroburgo, Amsterdam, Francoforte, Londra, New York, San Jose, Chicago, Singapore, Sydney, Madrid, Helsinki, Stoccolma, Varsavia, Copenaghen, Stavanger. Pagamenti flessibili: carte russe (inclusi Tinkoff, Ozon), SBP e USDT/BTC; setup server automatico in 5 minuti senza logging. Prezzi a partire da 490 ₽ al giorno e 2490 ₽ al mese con sconti sui periodi lunghi. È un compromesso tra autonomia totale (Sing-Box/Xray-Core sul tuo VPS) e pronta difesa contro DPI «out of the box».

Casi e risultati: riferimenti e pattern di soluzioni

Caso 1: rete mobile con perdite 1–2% e RTT 120–180 ms

• Obiettivo: minimizzare latenza P95 sulle richieste brevi mantenendo bulk accettabile.
• Stack: Sing-Box con Hysteria2 principale, VLESS/Reality riserva su 443.
• Tuning: BBR, buffer UDP aumentati, keepalive casuali.
• Risultato-pattern: riduzione P95 del 20–35% vs HTTP/2 puro, throughput più stabile con perdita 1%.

Caso 2: rete aziendale con DPI severo e ispezione header TLS

• Obiettivo: massima mimetizzazione sotto HTTPS legittimo.
• Stack: Xray-Core VLESS + XTLS Vision o VLESS/Reality; SNI su CDN popolare.
• uTLS: profilo Chrome/iOS, ALPN h2/h3 accurato.
• Risultato-pattern: handshake stabili, nessun blocco falso a RPS moderato, TTFB vicino a HTTPS «pulito».

Caso 3: traffico intercontinentale con picchi elevati

• Obiettivo: mantenere throughput alta su RTT elevato senza cali bruschi.
• Stack: Sing-Box TUIC, riserva VLESS/gRPC; BBR2 e offload ben calibrato.
• Risultato-pattern: P95 prevedibile, stabile a 8 streams paralleli, rari ritrasmissioni.

In tutti i casi è fondamentale: testare personalmente sulle tue rotte. Usa la nostra metodologia per ottenere dati tuoi e calibrare le config.

FAQ: domande approfondite

1. Cosa scegliere nel 2026 per iniziare — Sing-Box o Xray-Core?

Se prioritizza QUIC (Hysteria2/TUIC) e DPI-funk «early market», parti da Sing-Box. Se preferisci maturità VLESS/XTLS e comportamento prevedibile in reti aziendali, Xray-Core. Poi combina.

2. Reality e XTLS Vision sono concorrenti?

Più complementari. Entrambi puntano a mimetizzarsi come TLS legittimo. La scelta dipende dallo stack che preferisci gestire e dal DPI specifico.

3. Quanto è importante BBR?

Critico per transatlantici e canaline instabili. Spesso dà 5–15% in più e migliora latenza. Testa BBR2/BBRv3 e monitora la coda.

4. QUIC è sempre meglio di TCP?

No. QUIC vince con perdite, jitter e mobilità. Su canali puliti e basso RTT TCP con gRPC/HTTP/2 può essere altrettanto o più prevedibile.

5. Shadowsocks è sufficiente nel 2026?

Per scenari semplici sì, specialmente con cifrature nuove. Per DPI severo spesso serve spostarsi su Reality/XTLS o QUIC.

6. Come scegliere il profilo uTLS?

Guarda i client dominanti nel tuo pubblico: iOS/Android mobile o Chrome desktop. Mixalo e verifica ALPN e estensioni TLS.

7. Quanto spesso cambiare porte/SNI?

Non esagerare. Trigger è aumento interruzioni/errori handshake. Meglio avere profilo di riserva piuttosto che cambiare porte ogni giorno.

8. Docker o systemd?

Docker comodo per migrazioni e versioning, systemd per minima latenza e semplicità. A velocità alte la differenza è quasi nulla con rete ben configurata.

9. Come verificare se TLS è «scoperto»?

Confronta ClientHello con browser di riferimento (pcap), controlla SNI/ALPN e assenza di estensioni rare o ordine errato campi.

10. Posso combinare Sing-Box e Xray-Core?

Sì. Per esempio, frontend su 443 proxy verso Xray-Core (VLESS/XTLS) e contemporaneamente Sing-Box su porta UDP per Hysteria2/TUIC. Il client decide quale usare.

Conclusione: riassunto e prossimi passi

Nel 2026 la resilienza al DPI e la performance non dipendono dal brand del motore, ma da come combini protocolli, ottimizzi rete e misuri risultati. Sing-Box è scelta top per puntare su protocolli QUIC (Hysteria2/TUIC), mimica DPI avanzata e rapida evoluzione. Xray-Core è base solida per VLESS/XTLS Vision, HTTP/2/gRPC e ambienti aziendali rigorosi. Il miglior approccio pratico è mantenere un’architettura dual stack: canale principale ad alta velocità su QUIC e riserva su Reality/XTLS via 443 con SNI valido e uTLS. Attiva BBR, aumenta buffer UDP, verifica ALPN e impronte TLS, automatizza monitoraggi e test. Poi segui la checklist: 1) scegli geografia VPS e stack (Sing-Box o Xray-Core) adatti alla tua rete, 2) deploya configurazione base VLESS/Reality o Hysteria2/TUIC, 3) applica tuning sysctl, 4) esegui benchmark (bulk + web mix, con perdita), 5) imposta trasporto di riserva e alert, 6) ottimizza in base alle tue metriche. È semplice: misura, migliora, documenta. Così il tuo stack VPN durerà di più e supererà ondate DPI senza drammi.