Come configurare un bridge Tor obfs4 su un VPS

Che cos’è un bridge Tor e perché esiste

Un bridge Tor è un punto di ingresso nella rete Tor il cui indirizzo non viene pubblicato nell’elenco pubblico dei relay. Questo elenco, chiamato consenso, è un documento firmato che chiunque può scaricare, compreso un soggetto che applica la censura. Bloccare Tor partendo da quell’elenco richiede poco tempo: si scarica il consenso e si bloccano tutti gli indirizzi che contiene sul perimetro della rete. I bridge esistono perché l’elenco pubblicato è il punto debole. Gli indirizzi dei bridge vengono distribuiti pochi alla volta, quindi una singola richiesta non restituisce l’intero insieme.

Un indirizzo non elencato risolve solo metà del problema. La deep packet inspection (DPI), che classifica il traffico in base al contenuto anziché all’indirizzo, riconosce una connessione Tor dalla struttura dell’handshake TLS (transport layer security). Un soggetto che applica la censura può quindi riconoscere che «sembra Tor» e bloccare la connessione anche senza disporre di un elenco. Un transport pluggable elimina questo segnale. Sul lato client incapsula il flusso Tor in un altro tipo di traffico; il bridge lo decapsula.

obfs4 è il transport usato dalla maggior parte dei bridge. Converte il flusso in byte privi di header e di un handshake fisso, quindi la DPI non trova alcun modello da riconoscere. Inoltre autentica il client. Il valore cert= contenuto in una bridge line è una chiave che il client deve dimostrare di possedere prima che il bridge risponda. Questo impedisce l’attive probing: un soggetto che applica la censura e si connette al tuo indirizzo per verificare se parla Tor non riceve alcuna risposta e non acquisisce informazioni.

Quale transport pluggable utilizzare?

• obfs4 richiede un solo VPS, due porte TCP e nessun nome di dominio. È la soluzione utile più semplice da configurare ed è l'argomento di questa guida.
• WebTunnel nasconde la connessione all'interno del normale traffico HTTPS diretto a un sito web reale. Tor Project indica questi requisiti: ove possibile, un indirizzo IPv4 statico, un dominio sotto il tuo controllo, un web server funzionante come NGINX o Apache, un certificato TLS valido e almeno 1 GB di RAM; sono consigliati 4 GB. È adatto alle reti in cui il traffico con caratteristiche casuali è di per sé sospetto, perché un Paese che consente poco oltre alla navigazione web consente comunque il traffico HTTPS.
• Snowflake è un tipo diverso di contributo. I volontari eseguono proxy WebRTC di breve durata, quindi i punti di ingresso cambiano continuamente e non esiste un indirizzo stabile che un sistema di censura possa bloccare. Non devi gestire un bridge per questo trasporto. Esegui un proxy, che non richiede un indirizzo fisso.

Inizia con obfs4. In seguito puoi aggiungere un bridge WebTunnel su un secondo indirizzo: eseguire entrambi sullo stesso IP significa che il blocco di un singolo indirizzo rende indisponibili entrambi.

Quanto costa gestire un bridge?

[
  {
    "label": "Bridge, minimum",
    "min_upstream_mbit": 1
  },
  {
    "label": "Guard or middle relay, minimum",
    "min_upstream_mbit": 10
  },
  {
    "label": "Guard or middle relay, recommended",
    "min_upstream_mbit": 16
  }
]

A ottobre 2026 il Tor Project richiede a un bridge almeno 1 Mbit/s di banda in ingresso e in uscita. Per un relay guard o middle sono richiesti 10 Mbit/s, con 16 Mbit/s consigliati. Si tratta di requisiti pubblicati, non di misurazioni. Un bridge nuovo rimane generalmente molto al di sotto del proprio minimo per settimane. La stessa pagina dei requisiti richiede a un relay almeno 100 GByte di traffico in uscita al mese. I piani più economici coprono già questo valore, quindi consulta quanto costa davvero un piccolo VPS al mese prima di dimensionare qualcosa di più grande.

La superficie di abuso è ridotta, ed è questo il punto che spesso viene frainteso. Un bridge è il primo hop. Il traffico che lascia il server raggiunge un altro relay Tor, mai il sito web scelto dall'utente. Il tuo indirizzo IP non compare mai nei log web di estranei come origine di una richiesta, quindi qui non arrivano le segnalazioni che devono gestire gli operatori dei relay exit. Controlla comunque la policy di utilizzo accettabile del provider, perché alcuni host trattano qualsiasi servizio Tor come un caso speciale. Un bridge e un onion service sono immagini speculari sotto questo aspetto: un bridge è utile solo perché il suo indirizzo è raggiungibile e viene infine distribuito, mentre un onion service v3 sullo stesso tipo di VPS può tenere completamente nascosto il tuo IP pubblico.

Non fare una cosa: convertire un relay pubblico esistente in un bridge mantenendo lo stesso indirizzo. In questo caso il Tor Project consiglia di cambiare «indirizzo IP, nome e fingerprint», perché il vecchio indirizzo è già incluso nel consensus che i censori scaricano. Un bridge che la settimana scorsa era un relay pubblico è già presente in una blocklist.

L'uptime è più importante della velocità. I requisiti per i relay affermano che «se il relay non è in esecuzione per più di 2 ore al giorno, la sua utilità è limitata». In questo ambito un bridge è in una posizione peggiore rispetto a un relay, perché il client conosce solo le bridge line che gli sono state fornite. Tor Browser ne accetta diverse, una per riga, ma quando smettono tutte di rispondere l'utente deve richiederne di nuove. Un riavvio disconnette tutti gli utenti del tuo bridge. Configura un controllo della porta TCP in Uptime Kuma sulla porta obfs4, così saprai il giorno in cui smette di rispondere.

Installare Tor dal repository del progetto Tor

I pacchetti della distribuzione possono essere obsoleti. Un bridge è un componente software di sicurezza e deve essere aggiornato. Aggiungere prima il repository ufficiale del progetto.

sudo apt update
sudo apt install -y apt-transport-https gnupg wget lsb-release
wget -qO- https://deb.torproject.org/torproject.org/A3C4F0F979CAA22CDBA8F512EE8CBC9E886DDD89.asc | gpg --dearmor | sudo tee /usr/share/keyrings/deb.torproject.org-keyring.gpg >/dev/null

Ora creare il file sorgente. La riga Suites: deve contenere il codename della release. Leggerlo dal sistema invece di inserirlo a memoria.

sudo tee /etc/apt/sources.list.d/tor.sources >/dev/null <<EOF
Types: deb deb-src
URIs: https://deb.torproject.org/torproject.org/
Suites: $(lsb_release -cs)
Components: main
Signed-By: /usr/share/keyrings/deb.torproject.org-keyring.gpg
EOF
sudo apt update
sudo apt install -y tor deb.torproject.org-keyring obfs4proxy

Se apt update segnala che il repository non contiene un file Release per il proprio codename, il progetto Tor non supporta quella release. Eliminare /etc/apt/sources.list.d/tor.sources, eseguire di nuovo sudo apt update e installare il pacchetto tor fornito dalla distribuzione. Tutto ciò che segue resta invariato.

Il pacchetto obfs4proxy proviene direttamente da Debian e Ubuntu (versione 0.0.14 in Debian 13, a ottobre 2026). Verificare dove è stato installato il file binario, perché il relativo percorso deve essere inserito nella configurazione:

command -v obfs4proxy || command -v lyrebird

Il progetto upstream ha cambiato nome in lyrebird. Una versione più recente del pacchetto potrebbe quindi installare invece /usr/bin/lyrebird. Usare il percorso stampato da quel comando.

Configura il bridge in /etc/tor/torrc

BridgeRelay 1
ORPort 8443
ServerTransportPlugin obfs4 exec /usr/bin/obfs4proxy
ServerTransportListenAddr obfs4 0.0.0.0:9443
ExtORPort auto
ContactInfo you@example.com
Nickname PickANickname
BridgeDistribution any

Ogni riga ha una possibile causa di errore associata, quindi analizzale una alla volta.

BridgeRelay 1 indica a tor di inviare il proprio descriptor all'autorità dei bridge invece che al consensus pubblico. Questa singola riga rende il relay non elencato.

ORPort è la porta Tor effettiva. Deve essere raggiungibile da Internet, perché tor la verifica e rifiuta di pubblicare un descriptor finché il test non ha esito positivo.

ServerTransportPlugin indica a tor il comando da eseguire. tor avvia obfs4proxy come processo figlio e comunica con esso tramite una pipe, quindi obfs4proxy non dispone di una propria unità di servizio. Compare comunque in systemctl status tor@default, elencato nel CGroup di quella unità insieme a tor.

ServerTransportListenAddr fissa la porta su cui obfs4proxy resta in ascolto. Se ometti questa riga, obfs4proxy sceglie una porta libera all'avvio e, dopo la maggior parte dei riavvii, ne sceglie una diversa. Di conseguenza ogni bridge line già distribuita punta a una porta su cui non è in ascolto alcun processo. I client ricevono una connessione rifiutata e smettono di riprovare.

ExtORPort auto apre la ORPort estesa, un canale di loopback che obfs4proxy usa per restituire a tor le connessioni completate insieme all'indirizzo del client. La guida alla configurazione del Tor Project la include in ogni bridge, perché senza di essa il transport non può comunicare quell'indirizzo a tor.

ContactInfo e Nickname sono entrambi pubblici. Usa un indirizzo che controllerai, perché il Tor Project lo utilizza per contattarti in caso di problemi con il bridge. Scegli un nickname che non permetta di identificarti, se preferisci non attirare attenzione.

BridgeDistribution sceglie quale distributor fornisce il tuo indirizzo agli utenti. I valori accettati sono https, email, telegram, settings, none e any. Per il primo bridge usa any e lascia che sia il sistema a decidere. Usa none per un bridge privato che distribuisci personalmente, mantenendo così l'indirizzo completamente fuori dalla distribuzione pubblica.

Perché la scelta della porta è importante

Evita di usare 9001 per entrambe le porte. Il Tor Project lo indica esplicitamente, perché 9001 è la ORPort tradizionale e i censori eseguono scansioni su Internet per individuarla. Le due porte devono inoltre essere diverse, perché tor e obfs4proxy effettuano ciascuno il bind del proprio listener.

La porta obfs4 più efficace è 443. La porta 443 in uscita è aperta su quasi tutte le reti soggette a restrizioni, quindi anche un filtro che lascia passare quasi esclusivamente le porte web consente questo traffico. La porta non nasconde il protocollo: il traffico obfs4 continua ad apparire come dati casuali, non come HTTPS. Rendere una connessione simile all'accesso a un sito web è invece il compito di WebTunnel. Il bind su una porta inferiore a 1024 richiede un passaggio aggiuntivo, perché obfs4proxy non viene eseguito come root:

sudo setcap cap_net_bind_service=+ep /usr/bin/obfs4proxy
sudo systemctl edit tor@.service tor@default.service

Aggiungi queste due righe in ogni editor che viene aperto:

[Service]
NoNewPrivileges=no

La capability da sola non è sufficiente. NoNewPrivileges di systemd impedisce a un processo di acquisire privilegi che il processo padre non possedeva, e una file capability è esattamente questo. Di conseguenza obfs4proxy non riesce a effettuare il bind sulla porta 443 mentre l'impostazione resta attiva.

Se preferisci evitare questo passaggio, scegli una porta alta poco appariscente e annotala. Qualunque porta tu scelga, non modificare in seguito la porta obfs4. Una bridge line associa indirizzo, porta, fingerprint e certificato. Ogni copia già presente nel browser di un utente smette quindi di funzionare nel momento in cui la porta cambia.

Aprire le porte su entrambi i firewall

sudo ufw allow 8443/tcp
sudo ufw allow 9443/tcp
sudo ufw status

Entrambe le porte devono essere aperte. La maggior parte dei provider gestisce un secondo firewall dal pannello di controllo, che ufw non conosce. Una regola presente sul server ma assente nel pannello crea un bridge che non è mai raggiungibile e non pubblica mai un descriptor. Se uno dei due aspetti non è ancora chiaro, consultare le regole ufw necessarie su un VPS appena installato e che cosa significa realmente una porta in ascolto su Linux. Già che ci si trova, proteggere SSH con chiavi e una configurazione sshd più sicura. Un bridge non elencato su un server con accesso SSH tramite password resta comunque un server con accesso SSH tramite password.

Avvialo, quindi leggi il log

sudo systemctl enable --now tor.service
sudo systemctl restart tor.service
sudo journalctl -e -u tor@default

Debian e Ubuntu installano due unità. tor.service è un wrapper minimale e tor@default.service è il processo che esegue il lavoro. Per questo journalctl -u tor risulta quasi vuoto, mentre il log che ti interessa si trova in tor@default.

Due righe confermano che il servizio ha funzionato:

Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor.
Registered server transport 'obfs4' at '0.0.0.0:9443'

La prima indica che il test di raggiungibilità è riuscito e che il descrittore è stato inviato all'autorità bridge. Se non compare mai, qualcosa tra Internet e il server sta bloccando il traffico verso l'ORPort. La seconda riga deve mostrare la porta configurata. Se indica una porta diversa, tor non ha applicato ServerTransportListenAddr. La causa più comune è un nome di trasporto non corrispondente: in entrambe le direttive deve essere presente obfs4.

Verifica che esistano entrambi i listener:

sudo ss -lntp | grep -E 'tor|obfs4|lyrebird'

Dov’è la mia riga bridge?

obfs4proxy scrive un modello nella directory dati di tor:

sudo cat /var/lib/tor/pt_state/obfs4_bridgeline.txt

Questa directory appartiene all’utente tor e ha modalità 700, quindi senza sudo si ottiene Permission denied. Il file contiene una riga in questo formato:

Bridge obfs4 <IP ADDRESS>:<PORT> <FINGERPRINT> cert=<CERTIFICATE> iat-mode=0

Sostituisci <IP ADDRESS> con l’indirizzo pubblico del server, <PORT> con la porta obfs4 e non con la ORPort, quindi <FINGERPRINT> con l’impronta dell’identità che tor ha scritto nella directory dati:

sudo cat /var/lib/tor/fingerprint
sudo cat /var/lib/tor/hashed-fingerprint

Il primo file contiene il nickname e l’impronta dell’identità da inserire in una riga bridge. Il secondo contiene l’impronta sottoposta a hashing. È questo il valore da incollare in Ricerca relay per verificare se il bridge è in esecuzione e quanti client lo raggiungono approssimativamente. I due valori non sono intercambiabili. Una riga bridge con il valore sottoposto a hashing non corrisponde alla chiave dell’identità presentata dal bridge, quindi il client rifiuta la connessione appena aperta.

Come raggiunge effettivamente gli utenti un bridge?

Non devi distribuire a nessuno la riga del bridge. Quando il descriptor raggiunge l'autorità dei bridge, il sistema di distribuzione (rdsys, il successore di BridgeDB) assegna il bridge a un distributore e gli utenti chiedono i bridge a quel distributore. A ottobre 2026 i canali sono questi:

• Il sito web dei bridge all'indirizzo bridges.torproject.org/options, dove "Dammi semplicemente i bridge." restituisce subito le righe obfs4. Non è presente alcun captcha: Tor Project lo ha rimosso quando rdsys ha sostituito BridgeDB, modifica annunciata a dicembre 2024.
• Un messaggio email inviato a bridges@torproject.org da un indirizzo Gmail o Riseup, al quale segue una risposta con le righe dei bridge. La limitazione ai provider esiste perché gli account gratuiti illimitati consentirebbero a un censore di enumerare tutti i bridge.
• Il bot Telegram @GetBridgesBot. Invia /start, quindi /obfs4 o /webtunnel.
• Tor Browser, in Settings e poi Connection, dove "Request bridges" li recupera tramite il canale moat.

Un nuovo bridge compare in Relay Search circa tre ore dopo la configurazione. Per gli utenti occorre molto più tempo: la formulazione usata da Tor Project è: "Possono essere necessari diversi giorni o settimane prima di vedere un insieme stabile di utenti." Un primo periodo di due settimane con poca attività è normale e non indica un problema.

Impostare BridgeDistribution none disattiva tutti questi canali. In questo caso spetta a te inviare la riga del bridge alle persone che ne hanno bisogno, tramite un canale che il censore non sta monitorando.

Quando qualcosa non funziona

Nel log non compare la riga di self-test. La ORPort non è raggiungibile. Eseguire il test da un altro computer con nc -vz your.ip 8443. Se il comando resta in attesa, i pacchetti vengono filtrati: controllare ufw e il pannello del provider. Se la connessione viene rifiutata, tor non è in ascolto: controllare ss -lntp e cercare nel log eventuali errori di configurazione.

Il transport registrato mostra una porta diversa da quella scelta. tor ha ignorato ServerTransportListenAddr. Il nome del transport deve corrispondere esattamente a quello indicato in ServerTransportPlugin, ed entrambi devono essere obfs4.

obfs4proxy non riesce ad associare la porta 443. Verificare la capability con getcap /usr/bin/obfs4proxy, quindi verificare che l'override sia stato applicato all'unità con systemctl show tor@default -p NoNewPrivileges. Se il comando restituisce NoNewPrivileges=yes, il drop-in è stato applicato a un'unità che non è in esecuzione.

/var/lib/tor/pt_state/ è vuota. tor non ha avviato il transport, quindi il percorso indicato in ServerTransportPlugin è errato. Confrontarlo con l'output di command -v obfs4proxy.

I client hanno smesso di connettersi dopo una modifica. Qualsiasi modifica all'indirizzo o alla porta obfs4 rende non validhe tutte le bridge line già distribuite. Verificare anche se è cambiato l'IP pubblico del server. Questo può accadere durante una ricostruzione con alcuni provider.

tor non si avvia affatto. Eseguire sudo -u debian-tor tor --verify-config -f /etc/tor/torrc. Il comando analizza il file, indica la riga che causa il problema e lascia invariato il servizio in esecuzione.

FAQ

Il mio provider VPS si lamenterà per un bridge Tor?

Un bridge è un punto di ingresso, quindi il traffico in uscita dal server raggiunge altri relay Tor e non il sito scelto dall'utente. Il tuo indirizzo IP non compare nei log web di nessuno come origine di una richiesta. È questo che genera le segnalazioni gestite dagli operatori dei relay di uscita. Le regole di hosting variano comunque. Alcuni provider considerano qualsiasi servizio Tor un caso particolare. Leggi quindi la policy sull'uso accettabile prima di iniziare e inserisci un indirizzo che controlli in ContactInfo.

Quanta larghezza di banda usa un bridge Tor?

Il minimo pubblicato è 1 Mbit/s in upload e download, rispetto a 10 Mbit/s per un relay guard o middle. L'utilizzo effettivo inizialmente è quasi nullo. Il bridge trasporta infatti solo il traffico degli utenti che un distributore gli assegna. Se vuoi impostare un limite massimo preciso, configura RelayBandwidthRate e RelayBandwidthBurst in torrc.

Perché nessuno si è connesso al mio nuovo bridge?

Un bridge impiega circa tre ore per comparire in Relay Search. Secondo le indicazioni del Tor Project, per raggiungere un insieme costante di utenti servono diversi giorni o settimane. Verifica che il descriptor sia stato pubblicato. È la riga di autotest in journalctl -u tor@default. Cerca l'impronta hashata in Relay Search e conferma che BridgeDistribution non sia impostato su none.

Devo usare obfs4 o WebTunnel?

Usa obfs4 se questo è il tuo primo bridge: un VPS, due porte, nessun dominio e nessun certificato. Usa WebTunnel quando il traffico non riconoscibile è a sua volta bloccato. Richiede un dominio sotto il tuo controllo, un web server reale, un certificato TLS valido e almeno 1 GB di RAM. Se usi entrambi, assegnali a indirizzi distinti. In caso contrario, il blocco di un solo IP rimuoverebbe contemporaneamente due bridge.

Cosa succede se in seguito cambio la porta obfs4?

Ogni bridge line già distribuita smette di funzionare. Una bridge line associa tra loro indirizzo, porta, impronta e certificato. Un client che conserva la vecchia riga apre quindi una connessione verso una porta sulla quale non è in ascolto alcun servizio e interrompe il tentativo. Lo stesso vale quando cambia l'IP pubblico del server. Scegli la porta durante la configurazione e non modificarla.