Configurazione sing-box VLESS Reality 2026: i campi che quasi tutte le guide sbagliano

Cerca una guida a sing-box Reality e troverai parecchi file di configurazione che erano corretti nel 2024. Vengono ancora interpretati senza errori, ed è proprio questo il problema: niente ti avverte che hai appena costruito su campi che il progetto ha deprecato. Qui percorriamo una configurazione VLESS Reality verificata campo per campo sulla documentazione attuale, segnalando le parti che si sono spostate in silenzio.

Per riferimento, la versione su cui è stata fatta la verifica è sing-box 1.13.15, rilasciata il 29 luglio 2026.

Che cosa cambia davvero Reality

I proxy convenzionali basati su TLS hanno una debolezza strutturale: il certificato appartiene a te. Un censore che ispeziona l'handshake vede un dominio e un certificato che non corrispondono a un sito web reale e popolare, e quella discrepanza è essa stessa il segnale.

L'approccio di Reality consiste nel prendere in prestito l'handshake di un sito terzo autentico. Il tuo server è configurato per puntare a un host esterno reale, e il traffico che non supera l'autenticazione viene inoltrato lì. Per un osservatore, la connessione somiglia a una connessione verso quel sito, perché in parte lo è.

Ecco perché la configurazione ha un blocco handshake. Non è un ornamento e la sua scelta conta più di qualsiasi altro valore che imposterai.

I tre campi Reality obbligatori sul server

Dentro l'oggetto tls, il blocco reality richiede esattamente tre cose secondo la documentazione:

• handshake (oggetto), contenente server e server_port, il sito esterno da cui il tuo server prende in prestito
• private_key (stringa), che secondo la documentazione viene generata da sing-box generate reality-keypair
• short_id (stringa), descritta come una stringa esadecimale da zero a otto cifre

C'è anche un booleano enabled, e un campo facoltativo max_time_difference, che imposta la differenza di orologio tollerata tra le due estremità. La documentazione nota che il controllo è disabilitato quando questo campo è lasciato vuoto. Se lo imposti, tieni presente che ora dipendi dal fatto che entrambe le macchine mantengano l'ora esatta.

Generare le chiavi

Due valori vanno generati prima di scrivere qualsiasi cosa:

sing-box generate reality-keypair
sing-box generate uuid

La coppia di chiavi stampa una chiave privata e una chiave pubblica. La chiave privata resta sul server. La chiave pubblica va a ogni client. L'UUID è l'identità dell'utente VLESS.

Conserva la coppia insieme in un posto sicuro quando la generi. La chiave pubblica non è recuperabile da un file di configurazione che memorizza solo quella privata, e rigenerare la coppia invalida ogni client che hai già distribuito.

L'inbound del server

Un inbound VLESS richiede type, tag, i campi di ascolto e un array users. Ogni voce utente prende un uuid, facoltativamente un name, e facoltativamente un flow. La documentazione elenca esattamente un valore di flow disponibile: xtls-rprx-vision.

{
  "type": "vless",
  "tag": "vless-in",
  "listen": "::",
  "listen_port": 443,
  "users": [
    {
      "name": "me",
      "uuid": "PASTE-YOUR-GENERATED-UUID",
      "flow": "xtls-rprx-vision"
    }
  ],
  "tls": {
    "enabled": true,
    "server_name": "your-handshake-host.example",
    "reality": {
      "enabled": true,
      "handshake": {
        "server": "your-handshake-host.example",
        "server_port": 443
      },
      "private_key": "PASTE-YOUR-PRIVATE-KEY",
      "short_id": "0123abcd"
    }
  }
}

Nota server_name e il server dell'handshake. Sono campi distinti che normalmente conterranno lo stesso host, e una discrepanza tra i due è una causa frequente di configurazioni che si avviano senza problemi e poi falliscono al momento della connessione.

La parte che quasi tutte le guide sbagliano

Ecco la differenza tra una configurazione del 2024 e una attuale. Questi tre campi dell'inbound sono stati deprecati nella versione 1.11.0:

• sniff
• sniff_timeout
• domain_strategy

Sono usciti dall'inbound e sono diventati azioni delle regole di route. La guida alla migrazione fornisce gli equivalenti diretti:

{
  "route": {
    "rules": [
      { "inbound": "vless-in", "action": "sniff", "timeout": "1s" },
      { "inbound": "vless-in", "action": "resolve", "strategy": "prefer_ipv4" }
    ]
  }
}

Quindi "sniff": true diventa un action di tipo sniff, sniff_timeout diventa il timeout di quell'azione, e domain_strategy diventa un action di tipo resolve con una strategy.

Per essere precisi sulla posta in gioco: la documentazione li segnala come deprecati e non annuncia una data di rimozione. Oggi non si rompe nulla. Ma una configurazione che li porta ancora è scritta su un'interfaccia da cui il progetto si è allontanato, e vale la pena saperlo quando scegli quale tutorial seguire.

Due campi correlati, sniff_override_destination e udp_disable_domain_unmapping, sono anch'essi segnati come deprecati nella documentazione attuale dei campi di ascolto.

Il lato client

Al client serve meno che al server. Reality sul client richiede:

• public_key, la controparte della chiave privata del server
• short_id, che deve corrispondere a un valore accettato dal server

L'oggetto utls si affianca a questi, con enabled e fingerprint. I valori di fingerprint documentati come accettati sono chrome, firefox, edge, safari, 360, qq, ios, android, random e randomized. La documentazione afferma che viene usato il fingerprint di Chrome quando il campo è vuoto.

Un punto di onestà qui, perché le guide tendono ad affermare il contrario: la documentazione di sing-box presenta utls come un'opzione TLS indipendente e non afferma che Reality lo richieda. La maggior parte delle configurazioni client lo attiva comunque.

Scegliere l'host di handshake

Nessun valore di configurazione incide di più sul risultato, e nessuna guida può sceglierlo al posto tuo, perché la risposta giusta dipende da dove si trova il tuo server e da dove si trovano i tuoi client.

Le proprietà che contano:

• Dovrebbe essere un host che supporta davvero TLS 1.3 sulla porta a cui punti
• Dovrebbe essere traffico plausibile dalla posizione di rete del tuo server
• Non dovrebbe essere un sito a sua volta bloccato nel paese da cui ti connetti, il che vanificherebbe completamente lo scopo
• Non dovrebbe essere un sito che controlli tu, dato che il punto è che sia traffico reale di qualcun altro

Un consiglio ripetuto di frequente è di scegliere qualcosa di grande e generico. Attenzione a questo ragionamento: un host che ogni tutorial raccomanda è, per definizione, un host che compare in ogni configurazione, e la popolarità all'interno della comunità dei proxy non è la stessa cosa che passare inosservati.

Prima di concludere che funziona

Due verifiche che vale la pena fare e che vanno oltre il "il client si è connesso".

Conferma che il fallback si comporti correttamente. Punta un normale browser all'indirizzo e alla porta del tuo server. Quello che dovresti vedere è il sito di handshake, non un errore e non un timeout. Se ottieni qualcos'altro, il passthrough non sta facendo il suo lavoro e la configurazione è più vistosa di un proxy ordinario.

Controlla entrambi gli orologi. Se imposti max_time_difference, uno scarto su una delle due macchine produrrà errori che sembrano problemi di autenticazione e ti manderà a modificare chiavi che non erano mai sbagliate.

Se stai ancora decidendo tra i motori invece di configurarne uno, i compromessi sono esposti nel nostro confronto tra sing-box e Xray.

La versione breve

Tre campi Reality obbligatori sul server: handshake, private_key, short_id. Due sul client: public_key, short_id. Le chiavi arrivano da sing-box generate reality-keypair. E se la guida che stai leggendo mette sniff o domain_strategy dentro l'inbound, è precedente alla versione 1.11 e l'equivalente attuale è un'azione di una regola di route.

I nomi dei campi, i requisiti e le deprecazioni citati in questo articolo provengono dalla documentazione ufficiale di sing-box e dalla guida alla migrazione, verificati sulla release 1.13.15 il 30 luglio 2026. Le interfacce di configurazione cambiano tra le versioni, quindi verifica sulla documentazione della release che stai usando. Aggirare la censura è limitato o illecito in alcune giurisdizioni: controlla che cosa si applica dove ti trovi.