Come creare 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 consensus, è un documento firmato che chiunque può scaricare, compreso un censore. Bloccare Tor usando questo elenco richiede un pomeriggio: è sufficiente scaricare il consensus e bloccare al confine ogni indirizzo che contiene. I bridge esistono perché l’elenco pubblicato è il punto debole. Gli indirizzi dei bridge vengono distribuiti pochi alla volta, quindi nessuna singola richiesta restituisce l’intero insieme.

Un indirizzo non pubblicato risolve solo metà del problema. La deep packet inspection (DPI), che classifica il traffico in base al contenuto invece che all’indirizzo, riconosce una connessione Tor dalla struttura del suo handshake TLS (transport layer security). Un censore che non dispone dell’elenco può comunque rilevare che «sembra traffico Tor» e bloccare la connessione. Un pluggable transport elimina questo segnale. Sul client incapsula il flusso Tor in un altro tipo di traffico, che il bridge poi decapsula.

obfs4 è il transport più usato dai bridge. Trasforma il flusso in byte privi di header e di handshake fisso, quindi la DPI non trova alcun pattern 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. In questo modo si contrastano le active probing: un censore che si connette al tuo indirizzo per verificare se parla Tor non riceve alcuna risposta e non apprende nulla.

Quale trasporto collegabile dovresti usare?

• obfs4 richiede 1 VPS, 2 porte TCP e nessun nome di dominio. È la soluzione utile più semplice da eseguire e l'argomento di questa guida.
• WebTunnel nasconde la connessione all'interno del normale traffico HTTPS diretto a un sito web reale. Tor Project indica come requisiti 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 dall'aspetto casuale è di per sé sospetto, perché un Paese che consente poco oltre la navigazione web consente comunque HTTPS.
• Snowflake è un tipo di contributo diverso. I volontari eseguono proxy WebRTC di breve durata, quindi i punti di ingresso cambiano continuamente e non esiste un indirizzo stabile che un censore possa bloccare. Non devi gestire un bridge per questo trasporto. Devi eseguire 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 inutilizzabili 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
  }
]

Ad agosto 2026 il Tor Project richiede a un bridge almeno 1 Mbit/s di banda in upstream e downstream. Per un relay guard o middle richiede 10 Mbit/s, con 16 Mbit/s consigliati. Si tratta di requisiti pubblicati, non di misurazioni. Un bridge nuovo rimane solitamente 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ù piccoli coprono già questo requisito. Prima di dimensionare una soluzione più grande, leggi quanto costa davvero al mese un piccolo VPS.

La superficie di abuso è ridotta. È questo il punto che viene spesso frainteso. Un bridge è il primo hop. Il traffico che lascia il tuo server raggiunge un altro relay Tor, non il sito web scelto dall'utente. Il tuo indirizzo IP non compare mai nei log web di terzi come origine di una richiesta. Le segnalazioni che gestiscono gli operatori degli exit relay, quindi, non arrivano al tuo server. Controlla comunque la policy di utilizzo accettabile del provider, perché alcuni host considerano qualsiasi servizio Tor un caso speciale.

Non convertire un relay pubblico esistente in un bridge mantenendo lo stesso indirizzo. Per questo caso il Tor Project consiglia di cambiare "IP address, name and fingerprint", perché il vecchio indirizzo è già incluso nel consensus scaricato dai sistemi di censura. Un bridge che la settimana scorsa era un relay pubblico è già presente in una blocklist.

L'uptime conta più della velocità. I requisiti per i relay indicano che "if your relay is not running for more than 2 hours a day its usefulness is limited". In questo aspetto un bridge è svantaggiato rispetto a un relay, perché ogni client dispone di un solo indirizzo e non ha un fallback. Un riavvio disconnette tutti gli utenti che lo utilizzano. Configura un controllo della porta TCP in Uptime Kuma sulla porta obfs4, così saprai il giorno in cui smette di rispondere.

Installa Tor dal repository del progetto Tor

I pacchetti della distribuzione possono essere obsoleti. Un bridge è un componente di sicurezza e deve essere aggiornato. Aggiungi prima il repository 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 crea il file di configurazione del repository. La riga Suites: deve contenere il codename della tua release. Leggilo 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 alcun file Release per il tuo codename, il progetto Tor non supporta quella release. Elimina /etc/apt/sources.list.d/tor.sources, esegui di nuovo sudo apt update e installa il pacchetto tor fornito dalla tua distribuzione. Tutto ciò che segue resta invariato.

Il pacchetto obfs4proxy proviene direttamente da Debian e Ubuntu (versione 0.0.14 in Debian 13, ad agosto 2026). Verifica dove è stato installato il file binario, perché il relativo percorso verrà inserito nella configurazione:

command -v obfs4proxy || command -v lyrebird

Il progetto upstream è stato rinominato lyrebird. Un pacchetto più recente potrebbe quindi installare invece /usr/bin/lyrebird. Usa 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 conseguenza specifica in caso di errore, quindi analizzale una alla volta.

BridgeRelay 1 indica a tor di inviare il proprio descrittore all'autorità dei bridge invece che al consenso pubblico. Questa riga è ciò che rende il relay non elencato.

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

ServerTransportPlugin specifica il comando da eseguire. tor avvia obfs4proxy come processo figlio e comunica con esso tramite una pipe. Per questo obfs4proxy non ha una propria unità di servizio e non compare mai in systemctl status.

ServerTransportListenAddr imposta la porta sulla quale 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. Ogni riga del bridge già distribuita rimane quindi associata a una porta sulla quale non è in ascolto alcun processo. I client ricevono un rifiuto della connessione e smettono di tentare.

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 questa porta il transport non può comunicare quell'indirizzo a tor.

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

BridgeDistribution seleziona quale distributor comunica il tuo indirizzo agli utenti. I valori accettati sono https, email, telegram, settings, none e any. Usa any per un primo bridge e lascia che sia il sistema a decidere. Usa none per un bridge privato che distribuisci personalmente; in questo modo l'indirizzo resta completamente escluso dalla distribuzione pubblica.

Perché la scelta delle porte è importante

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

La porta obfs4 più efficace è 443. Il traffico in uscita sulla porta 443 è consentito su quasi tutte le reti soggette a restrizioni e una connessione persistente verso questa porta appare come una normale sessione web. Il binding 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 si apre:

[Service]
NoNewPrivileges=no

La capability, da sola, non è sufficiente. Il NoNewPrivileges di systemd impedisce a un processo di acquisire privilegi che il processo padre non aveva e una capability di file rientra esattamente in questo caso. Di conseguenza, obfs4proxy non riesce ad aprire il binding sulla porta 443 finché l'impostazione resta attiva.

Se preferisci evitare questo passaggio, scegli una porta alta poco significativa e annotala. Qualunque porta tu scelga, non modificarla in seguito. Una riga del bridge associa indirizzo, porta, fingerprint e certificato. Pertanto, ogni copia già presente nel browser di un utente smette di funzionare non appena 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 inoltre un secondo firewall nel pannello di controllo, che ufw non può gestire. 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 è nuovo per te, consulta le regole ufw necessarie su un VPS appena creato e che cosa sia effettivamente una porta in ascolto su Linux. Mentre esegui queste verifiche, limita l’accesso SSH usando 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 forniscono due unità. tor.service è un semplice wrapper, mentre tor@default.service è il processo che esegue il lavoro. Per questo journalctl -u tor sembra 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 descriptor è stato inviato all'autorità del bridge. Se non compare mai, qualcosa tra Internet e il server sta scartando il traffico diretto alla 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: deve essere obfs4 in entrambe le direttive.

Conferma che i due listener esistano:

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

Dov'è la mia riga bridge?

obfs4proxy scrive un modello nella directory dei 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 propria directory dei 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 ad hashing, che puoi incollare in Ricerca relay per verificare se il bridge è in esecuzione e avere una stima del numero di client che lo raggiungono. I due valori non sono intercambiabili. Una riga bridge che contiene il valore sottoposto ad 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 consegnare 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. Ad agosto 2026 i canali sono questi:

• Il modulo web all'indirizzo bridges.torproject.org/options, che restituisce le righe dei bridge dopo un captcha.
• Un'email a bridges@torproject.org inviata da un indirizzo Gmail o Riseup, a cui il sistema risponde con le righe dei bridge. La limitazione sui provider esiste perché gli account gratuiti illimitati consentirebbero a un singolo censore di enumerare tutti i bridge.
• Il bot Telegram @GetBridgesBot. Invia /start, quindi /obfs4 o /webtunnel.
• Tor Browser, nella sezione Impostazioni, quindi Connessione, dove l'opzione "Richiedi bridge" li recupera tramite il canale moat.

Un nuovo bridge compare in Relay Search circa tre ore dopo la configurazione. Gli utenti richiedono molto più tempo: la formulazione usata dal Tor Project è: "Possono essere necessari diversi giorni o settimane prima di vedere un insieme stabile di utenti." È normale che nelle prime due settimane l'attività sia ridotta; non si tratta di un guasto.

Impostando BridgeDistribution none rinunci a tutti questi canali. In questo caso la riga del bridge resta a tua disposizione per inviarla alle persone che ne hanno bisogno, tramite un canale che il censore non sta monitorando.

Quando qualcosa non funziona

Nessuna riga di autodiagnosi nel log. ORPort non è raggiungibile. Esegui il test da un'altra macchina con nc -vz your.ip 8443. Se la connessione resta in attesa, i pacchetti vengono scartati: controlla ufw e il pannello del provider. Se la connessione viene rifiutata, tor non è in ascolto: controlla ss -lntp e cerca 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 e in entrambi i casi deve essere obfs4.

obfs4proxy non riesce a mettersi in ascolto sulla porta 443. Verifica la capability con getcap /usr/bin/obfs4proxy, quindi verifica 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 mai avviato il transport, quindi il percorso indicato in ServerTransportPlugin è errato. Confrontalo con l'output di command -v obfs4proxy.

I client hanno smesso di connettersi dopo una modifica. Qualsiasi modifica all'indirizzo o alla porta obfs4 invalida tutte le bridge line già distribuite. Verifica anche se è cambiato l'indirizzo IP pubblico del server. Con alcuni provider questo può accadere dopo una ricostruzione.

tor non si avvia in alcun modo. Esegui 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 e alcuni provider trattano qualsiasi servizio Tor come un caso particolare. Leggi quindi la policy sull'uso accettabile prima di iniziare e inserisci un indirizzo che hai letto 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 parte vicino a zero, perché il tuo bridge trasporta soltanto il traffico degli utenti che un distributore gli assegna. Se vuoi un limite massimo rigido, imposta 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, servono diversi giorni o settimane prima di raggiungere un insieme stabile di utenti. 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 eseguire obfs4 o WebTunnel?

Esegui obfs4 se questo è il tuo primo bridge: un VPS, due porte, nessun dominio e nessun certificato. Usa WebTunnel quando il traffico dall'aspetto casuale è bloccato, perché richiede un dominio sotto il tuo controllo, un web server reale, un certificato TLS valido e almeno 1 GB di RAM. Se esegui entrambi, assegnali a indirizzi distinti. In caso contrario, il blocco di un solo IP renderebbe inutilizzabili due bridge contemporaneamente.

Cosa succede se modifico in seguito la porta obfs4?

Ogni bridge line già distribuita smette di funzionare. Una bridge line associa l'indirizzo, la porta, l'impronta e il certificato. Un client che conserva la vecchia riga tenta quindi di connettersi a una porta su cui non è in ascolto alcun servizio e interrompe il tentativo. Lo stesso vale se cambia l'IP pubblico del server. Scegli la porta durante la configurazione e non modificarla in seguito.