Shadowsocks e Xray: quando la VPN viene bloccata

Lavoro spesso con le VPN. Non come tema teorico, ma nella pratica: collegare sedi, dare accesso ai clienti alla rete aziendale, mantenere raggiungibili i server, configurare firewall, rinnovare certificati, stabilizzare tunnel IPsec, fare debug di client SSL VPN e capire perché una sede all’improvviso non passa più.

Di solito è normale lavoro di rete, solido e noioso. Ed è giusto che sia così.

Ci sono però casi in cui una VPN tecnicamente corretta non basta più. Con clienti provenienti da paesi con Internet fortemente regolato, per esempio Cina o Russia, capita di vedere protocolli VPN classici bloccati, disturbati o riconosciuti in modo mirato. Lavorando a Dubai con una clientela molto internazionale, non è un tema astratto. La domanda operativa non è quale contesto politico ci sia dietro, ma come mantenere un accesso legittimo alla propria infrastruttura quando la connessione viene filtrata lungo il percorso.

In questo contesto compaiono nomi come Shadowsocks, ShadowsocksR, V2Ray, Xray-core, VLESS, Trojan, REALITY o XHTTP. All’inizio sembrano un miscuglio confuso di progetti, fork e abbreviazioni. E in parte lo sono davvero.

Perché è nato Shadowsocks

Shadowsocks non nasce dal classico mondo delle VPN enterprise. Non è stato creato per costruire una soluzione site-to-site più elegante o perché IPsec fosse troppo complesso. L’origine era più diretta: nel 2012 uno sviluppatore con lo pseudonimo clowwindy voleva un modo leggero per uscire da una rete fortemente filtrata e raggiungere Internet aperto.

Questo spiega molto del design. Shadowsocks doveva essere leggero, veloce e pratico: non un pesante client VPN, non un grande gateway, non una suite di accesso remoto con identity management e compliance. Piuttosto, un proxy SOCKS5 locale che cifra il traffico e lo invia a un server fuori dal blocco.

Il bisogno non era “più funzioni security per aziende”, ma “mi serve una via d’uscita funzionante da una rete che filtra certi protocolli e destinazioni”. Per questo Shadowsocks è ancora interessante e allo stesso tempo facile da fraintendere. È un ottimo componente di trasporto snello, ma non è automaticamente una VPN aziendale completa.

Nel 2015 la storia è diventata politica: clowwindy scrisse su GitHub che la polizia era stata da lui e che doveva smettere di lavorarci. Lo sviluppo continuò poi tramite fork e altre implementazioni. Strumenti del genere nascono spesso da un dolore tecnico concreto e diventano parte di una corsa più ampia fra utenti, sviluppatori e infrastrutture di filtraggio.

Perché una VPN si nota

Quando si parla di VPN, molti pensano prima alla cifratura. È corretto, ma è solo una parte.

Un censore, un provider o un grande firewall nazionale non deve necessariamente leggere il contenuto cifrato per disturbarlo. Spesso basta riconoscere l’involucro. IPsec, SSL VPN, WireGuard e OpenVPN hanno caratteristiche tipiche: porte, dimensioni dei pacchetti, pattern di handshake, comportamento dei certificati, timing, uso di UDP, ritrasmissioni, errori o IP di server già noti.

La metafora utile è la busta, non la lettera. Il testo è cifrato, ma la busta ha dimensione, colore, timbro e mittente ricorrenti. Chi smista solo buste non deve leggere il contenuto per dire: questo tipo lo conosco, va controllato.

Il traffico di rete è simile. Deep Packet Inspection e Traffic Classification non guardano solo le porte; analizzano pattern. In TLS possono risaltare fingerprint del Client Hello, SNI, catene di certificati o ALPN. Nei protocolli completamente cifrati, perfino l’apparenza casuale dei primi pacchetti può diventare un segnale. Ricerche sulla Great Firewall hanno mostrato che contano anche lunghezze dei pacchetti, entropia e caratteri ASCII stampabili nei pacchetti iniziali.

Il punto scomodo è questo: “tutto sembra casuale” non significa automaticamente “tutto è discreto”. A volte è proprio quello a sembrare sospetto.

Cosa mostra la ricerca

Per me il punto decisivo non è che i sistemi di censura “riconoscano le VPN”. Questo si sapeva già a grandi linee. È interessante quanto possano essere tecnicamente poco spettacolari molti inizi di rilevamento.

Un buon punto di partenza è un lavoro di misurazione di GFW Report presentato nel 2020 alla ACM Internet Measurement Conference. GFW Report non è un prodotto o un vendor, ma un progetto di ricerca e misurazione sulla Great Firewall.

Il punto importante: non si trattava di un attacco magico alla cifratura. La Great Firewall combinava osservazione passiva e probing attivo. Prima una connessione diventava sospetta per lunghezza ed entropia del primo pacchetto dati. Poi arrivavano probe attivi: il censore si collega al server sospetto, riproduce pacchetti vecchi o modificati e osserva se l’altro lato reagisce come un server Shadowsocks.

Per gli amministratori questo separa due livelli di difesa:

• Il traffico non deve apparire troppo evidente passivamente.
• Il server non deve rispondere come un proxy ai test attivi.

Nel 2023 un altro studio GFW ha mostrato che traffico completamente cifrato può essere bloccato con euristiche semplici. Se il primo payload TCP non sembra TLS, HTTP o testo stampabile, ma un blocco casuale, questo può già essere un segnale. “Massimamente casuale” non è quindi sempre il miglior obiettivo di mimetizzazione.

Nel 2024 la ricerca sugli handshake TLS incapsulati ha aggiunto un altro livello: anche se il tunnel esterno è cifrato e ben mascherato, un handshake TLS interno può emergere come pattern dentro uno stack di protocolli annidato. Il padding casuale aiuta solo in parte; lo stream multiplexing sembra più promettente, ma non risolve automaticamente tutto se alla fine resta visibile un solo flusso applicativo.

Anche timing e cross-layer RTT sono importanti. Un proxy sposta fra loro sessioni di trasporto e applicazione. Queste differenze temporali possono essere misurabili, indipendentemente dalla distanza fra client e proxy. Non si risolvono con un header diverso.

La conseguenza è sobria: non decide l’etichetta del protocollo, ma il comportamento complessivo del setup.

Shadowsocks non è una VPN classica

Shadowsocks viene spesso messo nello stesso contenitore delle VPN. Nel linguaggio quotidiano si capisce, ma tecnicamente è impreciso.

Shadowsocks è un proxy cifrato, vagamente basato su SOCKS5. Un client locale offre un proxy alle applicazioni, cifra il traffico e lo manda a un server Shadowsocks remoto. Il server decifra la richiesta, si collega alla destinazione vera e rimanda la risposta nel canale cifrato.

È più snello di una VPN completa. Shadowsocks non porta automaticamente tutto il sistema operativo dentro un tunnel. Serve a mandare traffico selezionato su un percorso diverso. Con client e componenti aggiuntivi si può costruire un comportamento quasi da VPN, ma l’idea resta proxy, non site-to-site VPN.

Per gli amministratori questo corregge le aspettative:

• Shadowsocks non sostituisce un IPsec site-to-site fatto bene.
• Shadowsocks non protegge magicamente da ogni rilevamento.
• Shadowsocks è utile quando serve un proxy cifrato semplice e veloce da una rete restrittiva.

Tecnicamente Shadowsocks si è evoluto. Le vecchie configurazioni con stream cipher non sono più il riferimento. I deployment moderni appartengono al mondo AEAD, e Shadowsocks 2022 aggiunge chiavi simmetriche precondivise, derivazione basata su BLAKE3, protezione replay e altre correzioni. Limite importante: secondo la specifica non offre Forward Secrecy. Se una chiave viene compromessa, la rotazione pulita è obbligatoria.

shadowsocks-rust è oggi un’implementazione moderna, anche utilizzabile con Docker. Sul server può girare ssserver, sul client sslocal. Servono segreti generati correttamente, una porta raggiungibile, cipher attuali e una decisione chiara su TCP, UDP o entrambi.

Perché Xray-core è un’altra categoria

Xray-core non è semplicemente “Shadowsocks, ma nuovo”. È più un framework per scenari proxy e tunnel.

Xray può combinare protocolli inbound e outbound come VLESS, VMess, Trojan, Shadowsocks, WireGuard, Hysteria, SOCKS e HTTP. Sopra si usano transport come RAW, WebSocket, gRPC, XHTTP o Hysteria, combinati con TLS, REALITY o XTLS Vision. VMess appare ancora in molti vecchi setup, ma per nuovi deployment è più legacy; oggi in Xray il centro è spesso VLESS.

Shadowsocks è il cacciavite rapido. Xray è la cassetta degli attrezzi. Si possono costruire setup semplici, ma anche catene in cui un client locale SOCKS o TUN riceve traffico, lo invia con VLESS e REALITY a un server e da lì esce verso Internet tramite un outbound freedom.

VLESS non è la mimetizzazione stessa. È un protocollo proxy leggero con autenticazione UUID. Riservatezza e mimetizzazione arrivano dallo strato di trasporto e sicurezza sottostante, per esempio TLS, REALITY o XTLS Vision.

REALITY è particolarmente interessante perché non fa semplicemente “un altro TLS”. Verso l’esterno il server prende in prestito l’handshake TLS di un vero sito HTTPS terzo. Per un osservatore non sembra un certificato proxy improvvisato, ma un certificato reale di un sito reale. Solo un client autorizzato, grazie al materiale di chiave configurato, riconosce il proprio server Xray.

Questo affronta soprattutto fingerprint TLS lato server e active probing. uTLS aiuta lato client imitando Client Hello di browser. Xray però non è invisibile: timing, dimensioni dei pacchetti, ALPN, comportamento del server e pattern TLS annidati possono ancora produrre segnali. XTLS Vision e XHTTP sono blocchi interessanti, non garanzie. Un po’ di padding aiuta poco se il pattern di base resta visibile.

Approcci UDP come Hysteria o QUIC possono essere performanti, ma in reti restrittive vengono spesso limitati o bloccati più facilmente di TCP/443 in uscita. Xray richiede quindi disciplina: versioni fissate, test, release notes e niente copia-incolla cieco dai forum.

La confusione tra fork e nomi

Chi inizia a cercare trova presto vecchi post, fork GitHub e client mantenuti a metà. Dipende dalla storia di questi strumenti.

Shadowsocks è protocollo ed ecosistema con varie implementazioni. shadowsocks-rust è oggi una scelta naturale per un server moderno. Implementazioni come shadowsocks-libev sono note, ma a seconda dello stato del progetto vanno considerate più legacy o orientate ai bugfix.

ShadowsocksR era un fork con idee aggiuntive di obfuscation. SSR compare in molte guide vecchie. Oggi sarei prudente: non perché ogni vecchia installazione sia cattiva, ma perché bisogna verificare client, server, crittografia, aggiornamenti e comunità.

Xray-core viene dall’ambiente V2Ray, ma si è evoluto autonomamente. Copiare vecchi tutorial V2Ray su Xray è rischioso: alcuni concetti sono simili, ma configurazioni, funzioni e raccomandazioni sono cambiate.

V2Fly resta rilevante come progetto community più conservativo. Xray-core spinge più rapidamente funzioni come REALITY, XTLS Vision o XHTTP. C’è anche sing-box come piattaforma universale moderna. In questo articolo resto su Xray, ma in laboratorio guarderei anche sing-box.

Consiglio pratico:

• Per nuovi setup semplici: Shadowsocks con implementazione attuale.
• Per reti difficili: Xray-core con design pulito e aggiornato.
• Per vecchie guide SSR o V2Ray: verificare prima stato e sicurezza.
• Per clienti in produzione: non copiare setup senza capirli.

Cosa serve su entrambi i lati

Un setup minimo ha sempre due lati.

Sul lato remoto serve un server fuori dalla rete restrittiva: VPS, server proprio o infrastruttura controllata in una regione raggiungibile dal cliente. Deve essere hardened, patchato, monitorato e documentato. Un’istanza economica dimenticata diventa un rischio.

Sul lato client serve il programma giusto: per Shadowsocks spesso un client SOCKS locale o un’app che imposta il proxy di sistema; per Xray un client Xray, modalità TUN, router o app con import di profili.

Servono inoltre:

• scopo chiaro
• autenticazione pulita
• software aggiornato
• DNS controllato
• logging senza dati cliente inutili
• monitoraggio della raggiungibilità
• piano di rotazione per server, porte e segreti
• verifica legale e contrattuale

L’ultimo punto conta. In alcuni paesi l’uso di questi strumenti può essere legalmente problematico. In azienda bisogna distinguere accesso ai propri sistemi, reti cliente e accesso generale a Internet.

DNS è spesso sottovalutato. Se browser o sistema risolvono ancora i domini tramite il provider locale, il tunnel aiuta solo a metà. Il contenuto passa forse dal proxy, ma la query DNS rivela la destinazione. Bisogna controllare percorso DNS, IPv6 e comportamento in caso di caduta del tunnel.

Anche il logging è delicato. Per troubleshooting serve sapere se il tunnel vive; per privacy bisogna conservare poco. Meglio stati tecnici, latenza, errori e volumi che liste complete di connessioni. Debug log, TLS keylog e access log non mascherati non devono restare in produzione.

Il monitoring deve verificare un vero percorso di test, DNS corretto, eventuali blocchi per regione e differenze fra la vista dal paese interessato e quella dall’ufficio.

Come lo inquadrerei operativamente

Per me Shadowsocks o Xray non sostituiscono architettura firewall, Zero Trust, MFA o segmentazione. Sono strumenti di trasporto per casi speciali.

Un approccio aziendale sensato:

1. Verificare prima SSL VPN, IPsec o WireGuard.
2. Se sono bloccati, misurare DNS, porta, protocollo, IP server, fingerprint TLS e limitazioni UDP.
3. Testare poi Shadowsocks o Xray-core.
4. Usare il tunnel solo per le destinazioni necessarie.
5. Filtrare lato server i servizi interni raggiungibili.
6. Monitorare, così non si scopre il blocco dal cliente.
7. Avere fallback: secondo exit, altro provider, regione o protocollo.
8. Separare segreti e profili per sede o utente.
9. Costruire log e metriche senza raccolte inutili.

Quando una sede non accede più ai sistemi, “basta che funzioni” è comprensibile. Ma dopo bisogna ripulire e documentare. Altrimenti un workaround temporaneo diventa un percorso produttivo invisibile.

Perché i blocchi recuperano

La controparte adatta continuamente il rilevamento.

Se molti usano lo stesso Docker Compose, porta, fingerprint TLS, strategia di dominio e provider VPS, il pattern diventa visibile. Non viene bloccato “Xray” o “Shadowsocks” in astratto, ma un pattern concreto: handshake, dimensioni pacchetti, range IP, client tipici, fallback sbagliati o errori sospetti.

La mimetizzazione non è solo una funzione del tool. È operatività: stessi strumenti, domini diversi, provider diversi, profili diversi e pattern di traffico diversi possono apparire molto diversi.

Per questo sono prudente con le promesse di progetto. Se uno strumento dice di non essere rilevabile, è un’affermazione del progetto. Se un paper mostra un rilevamento in una rete reale, ha un peso diverso. Servono entrambe le cose: innovazione dei progetti e sobrietà della ricerca.

La mia valutazione

Shadowsocks ha senso quando serve un proxy cifrato snello, veloce e relativamente semplice: primi test, accessi temporanei e ambienti senza rilevamento molto aggressivo.

Xray-core ha senso quando la rete è più difficile, servono più transport o si vuole lavorare con VLESS, REALITY, WebSocket, gRPC o XHTTP. Richiede però più comprensione e perdona meno errori.

Per clienti non lo venderei come “sostituto della VPN”. Lo descriverei come percorso di trasporto alternativo per accessi legittimi. È meno spettacolare, ma più onesto.

La differenza più importante non è Shadowsocks contro Xray, ma se capisco il problema che sto risolvendo. Per accesso remoto normale uso VPN normale. Per rilevamento statale o del provider devo parlare di riconoscibilità, fingerprint e strategia operativa. Se non so spiegarlo, non dovrei gestirlo in produzione per clienti.

Conclusione

Shadowsocks e Xray-core sono strumenti di un mondo in cui le connessioni di rete non semplicemente “funzionano” o “non funzionano”. A volte vengono classificate, rallentate, testate attivamente o bloccate. Chi segue clienti internazionali prima o poi incontra questa realtà.

Il tema mi interessa perché rende concreta la rete: cifratura, pattern, fingerprint, routing, DNS, operation, diritto, responsabilità e il fatto che un tunnel funzionante non sia automaticamente un buon design.

Il prossimo passo per me è chiaro: voglio provare Shadowsocks e Xray-core in un piccolo lab. Non per aggirare censura alla cieca, ma per capire meglio perché le VPN classiche a volte si notano e quali alternative possono essere gestite seriamente.

Alla prossima,
Joe

FAQ