Come eseguire un relay Tor su un VPS Linux

Cosa fa un relay Tor su un VPS

Un relay Tor è un demone Tor eseguito su una macchina con un indirizzo IP pubblico, che inoltra traffico crittografato per conto di altri utenti. Le directory authority lo pubblicano e i client Tor costruiscono circuiti attraverso di esso. Un relay guard o middle inoltra il traffico esclusivamente a un altro relay. Non apre quindi connessioni a siti web per conto di estranei. Questo spiega perché non riceve messaggi di abuso e perché rappresenta il contributo più adatto a un VPS ordinario. Un relay trasporta il traffico di altre persone e non pubblica contenuti propri. Se vuoi pubblicare il tuo sito sulla rete invece di inoltrarne i pacchetti, eseguire un servizio onion v3 dietro nginx è un'attività diversa che usa lo stesso demone tor. Eseguire un relay non migliora la privacy della tua navigazione. Questo è un problema separato e offre meno vantaggi di quanto molti si aspettino: cosa nasconde realmente il self-hosting di SearXNG mostra in modo realistico quanto si ottiene spostando un servizio sul proprio VPS.

Il lavoro richiesto è limitato: un pacchetto, quindici righe di configurazione, una regola del firewall e un riavvio. Il resto di questa guida riguarda gli aspetti che causano più problemi: il calcolo della larghezza di banda su un piano a consumo e il motivo per cui un relay nuovo, perfettamente funzionante, sembra inattivo per una settimana.

Guard, middle, bridge o exit: scegli prima di installare

Un solo demone svolge tutti e quattro i ruoli. Sono la configurazione e le directory authority a determinare quale ruolo assumi.

• Middle relay. Riceve il traffico da un guard e lo inoltra a un altro relay. Non contatta mai il sito di destinazione. Ogni nuovo relay inizia da qui.
• Guard relay. Usa la stessa configurazione, con un flag aggiuntivo. Le directory authority assegnano il flag Guard ai relay che sono stati veloci e stabili per un periodo sufficiente. Non puoi sceglierlo. Devi ottenerlo, e la configurazione riportata di seguito serve proprio a questo.
• Bridge. È un relay mantenuto intenzionalmente fuori dalla directory pubblica e distribuito privatamente agli utenti che si trovano in luoghi dove Tor è bloccato. È il ruolo che richiede l'impegno minore: poca larghezza di banda, nessuna pubblicazione nella directory e un primo passo adatto se il tuo progetto è di piccole dimensioni. Richiede inoltre un proxy obfs4 eseguito insieme al demone e un insieme diverso di righe in torrc. La guida configurare un bridge obfs4 su un VPS economico illustra la procedura, compreso il modo in cui distribuire agli utenti la bridge line al termine.
• Exit relay. È l'ultimo hop e apre la connessione al sito di destinazione. Ogni richiesta inviata da un utente esce dal tuo indirizzo IP, quindi le segnalazioni di abuso e le richieste delle forze dell'ordine arrivano al titolare di quell'indirizzo.

L'exit è l'unico ruolo che non dovrebbe essere eseguito su un VPS generico. Esegui un exit solo presso un provider che abbia accettato in anticipo di ricevere quella corrispondenza, con un indirizzo IP dedicato e un contatto abuse pubblicato. La maggior parte delle condizioni standard dei provider vieta questo utilizzo. Ignorarle porta normalmente alla sospensione del server e alla perdita dell'indirizzo IP. Se vuoi comunque svolgere questo ruolo, cosa comporta realmente eseguire un exit relay spiega come trovare un host che accetti gli exit, definire l'exit policy e il reverse DNS e gestire la corrispondenza quando arriva. Un guard o un middle relay trasporta lo stesso traffico degli utenti senza questa esposizione.

Tutto ciò che segue configura un guard/middle relay. ExitRelay 0 è la riga che lo mantiene in questo ruolo.

Cosa serve al VPS prima di iniziare

Il Tor Project pubblica requisiti minimi specifici per i relay. Ad agosto 2026 sono i seguenti: un indirizzo IPv4 pubblico per il relay, almeno 10 Mbit/s di banda in entrambe le direzioni, con 16 Mbit/s consigliati, almeno 100 GB di traffico in uscita al mese e 512 MB di RAM sotto i 40 Mbit/s oppure 1 GB oltre questa velocità. Non esiste una regola fissa sull'uptime, ma un relay attivo meno di due ore al giorno è di scarsa utilità per la rete.

Il valore di 10 Mbit/s descrive la linea, non l'impostazione. Serve una porta in grado di raggiungerlo. La quantità di banda che si consente al relay di utilizzare è una decisione separata, da prendere in base al limite mensile di trasferimento. Leggere il piano prima di modificare la configurazione. Se si sta ancora scegliendo il server, quanto costa realmente un VPS al mese spiega come vengono venduti i limiti di trasferimento, mentre misurare il throughput di rete effettivo di un VPS mostra come verificare le prestazioni della linea con iperf3 invece di affidarsi alla pagina commerciale.

Mettere in sicurezza la macchina prima di tutto. Un relay è un servizio pubblico su un indirizzo pubblico e l'indirizzo viene sottoposto a scansioni entro pochi minuti dalla pubblicazione. Limitare SSH alle chiavi e usare una configurazione sshd più sicura richiede dieci minuti e deve essere completato prima di rendere operativo il relay, non dopo.

Installare Tor dal repository del Tor Project

Usare il repository apt del Tor Project invece del pacchetto della distribuzione. Il codice del relay viene aggiornato più rapidamente rispetto a una release stabile, quindi le correzioni arrivano prima in questo repository, mentre il pacchetto della distribuzione rimane indietro tra una release e l’altra.

sudo apt update
sudo apt install -y apt-transport-https gnupg wget

Aggiungere la chiave di firma, quindi il repository. Il codename viene letto dalla macchina, quindi lo stesso blocco funziona su Ubuntu 24.04 (noble) e Debian 13 (trixie).

wget -qO- https://deb.torproject.org/torproject.org/A3C4F0F979CAA22CDBA8F512EE8CBC9E886DDD89.asc \
  | gpg --dearmor \
  | sudo tee /usr/share/keyrings/deb.torproject.org-keyring.gpg >/dev/null

CODENAME=$(. /etc/os-release && echo "$VERSION_CODENAME")
echo "$CODENAME"

sudo tee /etc/apt/sources.list.d/tor.sources >/dev/null <<EOF
Types: deb deb-src
URIs: https://deb.torproject.org/torproject.org/
Suites: $CODENAME
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
tor --version

tor --version stampa la versione appena installata. Se apt update ha invece stampato un errore NO_PUBKEY, la chiave dearmored non si trova nel percorso indicato nella riga Signed-By:, quindi apt non dispone di una chiave con cui verificare il file di release. Il pacchetto deb.torproject.org-keyring sarà importante in seguito: distribuisce la chiave di firma come pacchetto ordinario, quindi apt continua a funzionare quando la chiave viene ruotata.

Attivare gli aggiornamenti automatici, quindi configurare la nuova origine.

sudo apt install -y unattended-upgrades apt-listchanges

Su Ubuntu, aggiungere l’origine Tor al blocco Allowed-Origins in /etc/apt/apt.conf.d/50unattended-upgrades:

Unattended-Upgrade::Allowed-Origins {
        "${distro_id}:${distro_codename}-security";
        "TorProject:${distro_codename}";
};

Su Debian lo stesso file usa Origins-Pattern; la riga da aggiungere è "origin=TorProject";. Verificare il risultato con sudo unattended-upgrade --debug --dry-run, che stampa le origini su cui interverrà senza scrivere nulla.

Il file torrc che conta

Il pacchetto installa un lungo file /etc/tor/torrc con numerosi commenti. Per un relay contano solo poche righe. Aggiungile alla fine del file.

Nickname mynicerelay
ContactInfo relay-ops[at]example.com
ORPort 9001
ExitRelay 0
SocksPort 0

Nickname contiene da 1 a 19 caratteri, solo lettere e cifre. Non è univoco nella rete e non identifica il relay: a identificarlo è il fingerprint. Serve per trovare il proprio relay in una casella di ricerca, quindi scegli un nome che sia facile da pronunciare al telefono.

ContactInfo viene pubblicato nel descriptor del relay, un documento pubblico che chiunque può scaricare, quindi l'indirizzo verrà raccolto. Usa un indirizzo che continuerai a leggere tra due anni e, se vuoi, offuscalo. Questo è l'unico canale che il Tor Project ha per avvisarti di un problema del relay.

ORPort 9001 è la porta a cui si connettono gli altri relay e i client. 9001 è la scelta convenzionale. L'altra scelta comune è la porta 443, perché alcune reti restrittive consentono solo connessioni in uscita sulla porta 443; un relay in ascolto su questa porta è quindi raggiungibile da più client. Scegli 443 solo se nessun altro servizio sul server ne ha bisogno.

SocksPort 0 disattiva il proxy SOCKS locale, che un relay non utilizza, e rimuove un socket in ascolto dal sistema. ExitRelay 0 rende esplicita questa scelta nel file: il relay non si connetterà mai a una destinazione per conto di un utente e chi leggerà la configurazione in seguito non dovrà dedurlo dal comportamento predefinito.

Se il VPS ha un indirizzo IPv6, aggiungi una seconda riga ORPort. Tor non può associarsi a un indirizzo IPv6 "qualsiasi" come fa con IPv4, quindi scrivi l'indirizzo tra parentesi quadre.

ORPort 9001
ORPort [2001:db8::1]:9001

Su un VPS con 1 GB, aggiungi MaxMemInQueues 512 MB. Tor determina il limite della coda in base alla memoria rilevata sul sistema; su un server condiviso di piccole dimensioni, questo valore è superiore a quello che vuoi consentirgli di utilizzare. Impostando direttamente il limite, fai in modo che tor scarti le celle accodate sotto carico, consentendo al relay di continuare a funzionare, invece di far crescere la coda fino a quando il kernel termina il processo.

Aprire la ORPort nel firewall

In ingresso, la ORPort deve essere raggiungibile da qualsiasi punto di Internet. In uscita, lascia il relay senza restrizioni: apre connessioni verso migliaia di altri relay su molte porte diverse e una allowlist per il traffico in uscita lo renderebbe inutilizzabile senza segnalarlo chiaramente.

sudo ufw allow 9001/tcp comment 'tor ORPort'
sudo ufw status verbose

Controlla quindi anche il firewall di rete del provider. Molti pannelli di controllo eseguono un filtro dei pacchetti davanti alla macchina virtuale. In questo caso, una regola aggiunta con ufw non ha effetto e la porta risulta aperta sulla macchina, ma chiusa dall'esterno. Se ufw è una novità, le regole ufw da configurare su ogni VPS spiega la policy predefinita e l'ordine di valutazione delle regole.

Dimensionare la larghezza di banda in base al piano

Il manuale descrive RelayBandwidthRate come un token bucket separato che limita «l'utilizzo medio della larghezza di banda in ingresso per il traffico inoltrato su questo nodo al numero specificato di byte al secondo e l'utilizzo medio della larghezza di banda in uscita allo stesso valore». Rileggi il passaggio. Il limite si applica separatamente a ciascuna direzione. Un relay impostato a 1 Mbit/s può trasferire contemporaneamente 1 Mbit/s in ingresso e 1 Mbit/s in uscita; un provider che contabilizza entrambe le direzioni addebita la somma.

[
  {
    "label": "1 Mbit/s",
    "torrc_rate": "125 KBytes",
    "gb_per_day": 21.6,
    "gb_per_month": "648"
  },
  {
    "label": "2 Mbit/s",
    "torrc_rate": "250 KBytes",
    "gb_per_day": 43.2,
    "gb_per_month": "1,296"
  },
  {
    "label": "5 Mbit/s",
    "torrc_rate": "625 KBytes",
    "gb_per_day": 108,
    "gb_per_month": "3,240"
  },
  {
    "label": "10 Mbit/s",
    "torrc_rate": "1250 KBytes",
    "gb_per_day": 216,
    "gb_per_month": "6,480"
  },
  {
    "label": "20 Mbit/s",
    "torrc_rate": "2500 KBytes",
    "gb_per_day": 432,
    "gb_per_month": "12,960"
  }
]

Le 5 righe sono calcoli aritmetici, non misurazioni: mostrano il consumo di una determinata velocità se il relay la mantiene per 30 giorni interi in entrambe le direzioni. Un relay resta al di sotto del limite per gran parte del tempo, soprattutto nelle prime settimane. Usa la tabella per escludere impostazioni incompatibili con il piano, non per prevedere una fattura al gigabyte.

A 1 Mbit/s per direzione, un relay trasferisce circa 21.6 GB al giorno; in un mese di 30 giorni questo corrisponde a circa 648 GB di traffico contabilizzato. Il consumo rientra in un piano da 1 TB, lasciando margine per aggiornamenti e backup. Passando a 2 Mbit/s, il consumo mensile raggiunge 1,296 GB, superando già un piano da 1 TB. L'ultima riga, 20 Mbit/s, richiede 12,960 GB al mese e dovrebbe essere usata su una porta non soggetta a limiti di traffico. Se il provider addebita soltanto il traffico in uscita, dimezza ogni valore. Verifica quale metodo applica prima di impostare la velocità, perché i due risultati differiscono di un fattore due.

Ora la configurazione. Prima limita la velocità, poi imposta la quota.

RelayBandwidthRate 125 KBytes
RelayBandwidthBurst 250 KBytes
AccountingMax 400 GBytes
AccountingRule sum
AccountingStart month 1 00:00

RelayBandwidthBurst è la dimensione del token bucket, quindi consente picchi brevi superiori alla velocità configurata mentre mantiene invariata la media. Un valore pari a circa il doppio della velocità è ragionevole.

AccountingRule è la riga che molti operatori trascurano. Il valore predefinito è max e confronta con la quota la direzione che presenta il consumo maggiore. Con il valore predefinito, AccountingMax 400 GBytes consente 400 GB in ingresso e 400 GB in uscita, per un totale di 800 GB su un contatore che considera entrambe le direzioni. AccountingRule sum somma letture e scritture ai fini dell'unica quota, che è il comportamento corrispondente a una disponibilità di trasferimento.

Scrivi anche AccountingStart, mai AccountingMax da solo. La quota indica il valore numerico; la riga di avvio stabilisce il momento in cui la quota viene azzerata. Una quota senza periodo lascia il relay in ibernazione, senza alcun evento che possa riattivarlo.

L'ibernazione è un meccanismo drastico. Quando la quota si esaurisce, tor lo registra nei log e smette di accettare lavoro:

Bandwidth soft limit reached; commencing hibernation. No new connections will be accepted

Il relay non si riattiva esattamente all'inizio del periodo successivo. Tor calcola la velocità con cui è stata consumata l'ultima quota e sceglie un momento casuale all'interno del nuovo intervallo, così migliaia di relay non tornano nella rete nello stesso secondo. Un relay che scompare durante l'ultima settimana di ogni mese perde continuamente la stabilità sulla quale le directory authorities valutano la sua affidabilità. Dimensiona RelayBandwidthRate in modo che il limite non venga mai raggiunto e mantieni AccountingMax come protezione finale per evitare costi imprevisti.

Avviare il relay e verificare che sia raggiungibile

sudo systemctl restart tor@default
sudo systemctl status tor@default
sudo journalctl -u tor@default -n 50

Nel giro di pochi minuti, il log dovrebbe contenere questa riga:

Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor.

Questa frase indica che altri relay si sono collegati all'ORPort e hanno creato un circuito attraverso il tuo relay. Finché non compare, il relay non è presente nella directory e non trasporta alcun traffico. L'errore è simile al seguente:

Your server has not managed to confirm reachability for its ORPort(s) at 203.0.113.10:9001. Relays do not publish descriptors until their ORPort and DirPort are reachable. Please check your firewalls, ports, address, /etc/hosts file, etc.

Verifica i punti nell'ordine indicato. L'ORPort è aperta in ufw? È aperta anche nel firewall di rete separato del provider? L'indirizzo riportato nel messaggio è quello a cui Internet instrada effettivamente il traffico, invece di essere un indirizzo privato di una configurazione NAT? Verifica la porta da un'altra macchina con nc -vz 203.0.113.10 9001. Tor ripete automaticamente il test di raggiungibilità, quindi rileva una correzione del firewall senza altri interventi; un riavvio rende il controllo immediato.

L'identità permanente del relay è la relativa fingerprint:

sudo cat /var/lib/tor/fingerprint

Circa tre ore dopo la pubblicazione del descriptor, il relay compare in Relay Search. Cerca il nickname oppure incolla la fingerprint. Questa pagina mostra come la rete considera il relay: quali flag possiede, quale peso gli assegnano le autorità e quale versione pubblica.

Perché un nuovo relay Tor gestisce quasi tutto il traffico?

Perché la rete non lo ha ancora misurato e la misurazione richiede settimane. Il Tor Project descrive la fase di crescita in quattro fasi, ma un operatore che non le conosce conclude che il relay non funziona e inizia a modificare la configurazione.

Nei primi tre giorni il relay non viene misurato. Pubblica il risultato del proprio self-test, ma le directory authority limitano comunque il peso pubblicato a 20 KB, quindi i client lo selezionano quasi mai. Dal terzo all'ottavo giorno circa, le bandwidth authority lo misurano realmente e il peso aumenta, ma il relay viene usato solo come hop intermedio, perché nessun client è disposto a usare un relay completamente nuovo come primo hop.

Intorno all'ottavo giorno il relay può ottenere il flag Guard. L'assegnazione del flag fa diminuire il traffico, con un risultato che sorprende molti operatori: i client ignorano i guard quando scelgono gli hop intermedi, presumendo che un guard sia già occupato. Di conseguenza il relay perde traffico intermedio prima di acquisire traffico come guard. Recupera traffico solo quando i client ruotano i propri set di guard, un processo che richiede settimane. Intorno al giorno 68 raggiunge uno stato stabile, in cui il numero di client che lo rimuovono bilancia quello dei client che lo aggiungono.

L'aspettativa realistica è quindi: nulla per tre giorni, qualcosa dopo una settimana e un carico significativo dopo due mesi. Modifica una sola impostazione, poi attendi una settimana per valutarne l'effetto. Una pagina di stato Uptime Kuma self-hosted con un controllo TCP sulla porta 9001 è un uso migliore dell'ansia dell'operatore: risponde alla domanda che puoi realmente controllare, cioè se la porta continua a rispondere.

Monitorare il relay con nyx

nyx è il monitor del terminale per un relay in esecuzione. Comunica con la porta di controllo di tor, quindi è necessario abilitarla prima in torrc:

ControlPort 9051
CookieAuthentication 1
CookieAuthFileGroupReadable 1

ControlPort resta in ascolto solo su 127.0.0.1 e l'autenticazione tramite cookie richiede che un programma legga un file segreto prima di poter inviare comandi. Tor scrive questo cookie in /run/tor/control.authcookie come utente debian-tor, con modalità 600, in modo che nessun altro possa leggerlo. CookieAuthFileGroupReadable 1 concede l'accesso al gruppo, permettendo al proprio account di eseguire nyx senza sudo.

sudo apt install -y nyx
sudo adduser "$USER" debian-tor
sudo systemctl restart tor@default

Disconnettiti e accedi di nuovo, quindi esegui nyx. Il nuovo gruppo deve essere acquisito al momento dell'accesso; per questo, eseguire nyx nella stessa sessione della shell genera un errore di autorizzazione sul file cookie anche se la configurazione è corretta. nyx mostra la larghezza di banda in tempo reale, il tempo di attività, il flusso dei log e l'elenco delle connessioni. Nelle prime settimane, il valore da controllare è il grafico della larghezza di banda, che deve restare al di sotto di RelayBandwidthRate.

Eseguire più relay: MyFamily e chiavi di famiglia

Con un solo relay, saltare questa sezione. Due o più relay gestiti dallo stesso operatore devono dichiararsi reciprocamente, in modo che i client non costruiscano mai un circuito che entra ed esce dalle macchine dell'operatore. In caso contrario, un singolo operatore potrebbe vedere entrambe le estremità del circuito.

Il metodo storico consiste nell'impostare MyFamily nel torrc di ogni relay, elencando le fingerprint di tutti gli altri:

MyFamily AAAAAAAAAA,BBBBBBBB

Ogni relay elenca tutti gli altri. Di conseguenza, per aggiungere un quarto relay è necessario modificare quattro file. Tor 0.4.9 ha sostituito questo metodo con una chiave di famiglia. Generare una chiave e quindi distribuirla:

tor --keygen-family myfamily

Il comando scrive myfamily.secret_family_key e stampa una riga FamilyId. Copiare il file della chiave su ogni relay, nella sottodirectory keys di DataDirectory (/var/lib/tor/keys su Debian e Ubuntu), mantenendo il suffisso .secret_family_key. Aggiungere la riga FamilyId stampata al torrc di ogni relay e ricaricare la configurazione con sudo systemctl reload tor@default. Per il momento, mantenere anche l'elenco MyFamily. I client che non supportano ancora i certificati di famiglia continuano a leggere l'elenco precedente. Il Tor Project comunicherà quando sarà possibile rimuoverlo.

Cosa può rompersi dopo l'avvio

La versione diventa obsoleta. Gli aggiornamenti automatici sostituiscono il pacchetto, ma il processo in esecuzione continua a usare il binario con cui è stato avviato finché non viene riavviato. Confrontare tor --version sul server con la versione mostrata nella pagina Relay Search del relay. Se differiscono, la rete sta ancora utilizzando la versione precedente: riavviare il servizio.

L'orologio non è sincronizzato. I documenti di consenso e i certificati sono tutti vincolati al tempo. Una macchina il cui orologio è molto indietro o avanti rifiuta il consenso e interrompe la pubblicazione. timedatectl dovrebbe indicare che l'orologio di sistema è sincronizzato. In caso contrario, abilitare systemd-timesyncd oppure installare chrony.

L'indirizzo IP cambia. Il descriptor contiene l'indirizzo e i client non possono raggiungere un indirizzo che è cambiato. Dopo una migrazione del provider o una modifica dell'indirizzo, riavviare tor e attendere nuovamente la riga del self-test.

Il relay è più lento di quanto consentito dal piano. La crittografia del relay Tor è efficiente sui processori moderni e il Tor Project indica circa 400 to 450 Mbit/s per direzione per una CPU con supporto AES-NI. Molto prima di raggiungere questo limite, le prestazioni sono vincolate dalla velocità della porta e dal traffico incluso nel piano. Per questo la sezione sull'accounting sopra è più importante dell'hardware.

FAQ

Quanta larghezza di banda utilizza un relay Tor?

Utilizza la quantità consentita dalla configurazione, senza superarla. RelayBandwidthRate limita separatamente il traffico inoltrato in ciascuna direzione, quindi un relay configurato a 1 Mbit/s può gestire contemporaneamente 1 Mbit/s in ingresso e 1 Mbit/s in uscita. In totale sono circa 21.6 GB al giorno, oppure 648 GB in un mese di 30 giorni, considerando entrambe le direzioni. Aggiungete AccountingMax con AccountingRule sum come quota mensile rigida al di sotto di tale velocità.

L'esecuzione di un relay Tor genera segnalazioni di abuso?

Un relay guard o middle inoltra il traffico soltanto ad altri relay Tor e non si connette mai a un sito web per conto di un utente. Le segnalazioni relative alle attività svolte tramite Tor arrivano quindi al gestore del relay exit, non a voi. Potreste invece rilevare scansioni e occasionali inserimenti in liste di reputazione IP, perché l'indirizzo è pubblicato come relay. Sono i relay exit a ricevere messaggi di abuso e comunicazioni legali; per questo devono utilizzare un provider che abbia accettato in anticipo di gestirli. Leggete i termini del provider prima di avviare uno dei due tipi di relay.

Perché il mio nuovo relay Tor non riceve traffico?

Perché i nuovi relay vengono limitati intenzionalmente finché non sono stati misurati. Nei primi tre giorni le directory authority limitano il peso pubblicato a 20 KB, quindi i client scelgono quasi mai il relay. Le bandwidth authority lo misurano a partire circa dal terzo giorno; il relay può ottenere il flag Guard intorno all'ottavo giorno. A quel punto il traffico diminuisce nuovamente, perché i client evitano i guard quando selezionano gli hop middle. Il carico completo arriva intorno al giorno 68. Verificate che il log mostri "Self-testing indicates your ORPort is reachable from the outside", quindi non intervenite.

Posso eseguire un relay Tor su un VPS con una quota di trasferimento di 1 TB?

Sì, a circa 1 Mbit/s in ciascuna direzione, cioè RelayBandwidthRate 125 KBytes. Sono all'incirca 648 GB al mese se il provider conteggia entrambe le direzioni, lasciando margine per aggiornamenti e backup. Aggiungete AccountingMax 400 GBytes con AccountingRule sum e AccountingStart month 1 00:00, in modo che il relay entri in ibernazione invece di superare la quota prevista. Se il provider fattura soltanto il traffico in uscita, potete raddoppiare la velocità.

Devo impostare MyFamily se eseguo un solo relay?

No. Le dichiarazioni di famiglia servono a impedire ai client di costruire un circuito attraverso due relay gestiti dallo stesso operatore. Con un solo relay non hanno alcuna utilità. Impostatele non appena aggiungete un secondo relay: elencate il fingerprint di ogni relay nella riga MyFamily di ciascun relay, oppure utilizzate la family key introdotta da Tor 0.4.9, che distribuisce un unico FamilyId invece di un elenco sempre più lungo.