Como rodar um relay Tor em uma VPS Linux
Configure um relay guard ou middle do Tor com torrc, limite de banda para planos medidos, monitoramento no nyx e entenda a lenta entrada no consenso.
O que um relay Tor faz numa VPS
Um relay Tor é um daemon Tor numa máquina com um endereço IP público que encaminha tráfego encriptado para outras pessoas. As autoridades de diretório publicam-no, e os clientes Tor constroem circuitos através dele. Um relay guard ou middle apenas encaminha o tráfego para outro relay. Por isso, nunca abre uma ligação a um site em nome de um desconhecido. Esse facto explica por que razão não recebe mensagens de abuso e por que razão esta é a contribuição adequada para uma VPS comum.
O trabalho é pequeno: um pacote, quinze linhas de configuração, uma regra de firewall e um reinício. O restante deste guia aborda o que costuma correr mal. Isto inclui os cálculos de largura de banda num plano com tráfego medido e a razão por que um relay novo e perfeitamente saudável parece estar inativo durante uma semana.
Guard, middle, bridge ou exit: escolha antes de instalar
Um único daemon executa os quatro papéis. A sua configuração, juntamente com as autoridades de diretório, determina qual deles será.
- Relay middle. Recebe tráfego de um guard e encaminha-o para outro relay. Nunca contacta um site de destino. Todo relay novo começa aqui.
- Relay guard. Usa a mesma configuração, com uma flag adicional. As autoridades de diretório atribuem a flag Guard aos relays que se mantêm rápidos e estáveis durante tempo suficiente. Não é você que a escolhe. Você a conquista, e é a configuração abaixo que permite conquistá-la.
- Bridge. É um relay mantido deliberadamente fora do diretório público e distribuído de forma privada a utilizadores em locais onde o Tor está bloqueado. É o menor compromisso dos quatro: baixa largura de banda, sem listagem pública e o passo inicial adequado se o seu plano for pequeno.
- Relay exit. É o último salto e abre a ligação para o site de destino. Cada pedido feito por um utilizador sai do seu endereço IP, portanto as denúncias de abuso e os pedidos das autoridades policiais chegam ao responsável por esse endereço.
O exit é o único papel que não deve ser executado num VPS de uso geral. Execute um exit apenas num provedor que tenha concordado previamente em receber esse tipo de mensagem, com um endereço IP próprio e um contacto de abuso publicado. A maioria dos termos de serviço de hospedagem comuns proíbe essa função. O resultado habitual de ignorar essa regra é um servidor suspenso e a perda do endereço IP. Um relay guard ou middle transporta o mesmo tráfego de utilizadores sem essa exposição.
Tudo o que se segue configura um relay guard/middle. ExitRelay 0 é a linha que o mantém como um deles.
O que a VPS precisa antes de começar
O Tor Project publica requisitos mínimos para relays. Em agosto de 2026, são estes: um endereço IPv4 público para o relay, pelo menos 10 Mbit/s de largura de banda em cada sentido, com 16 Mbit/s recomendados, pelo menos 100 GB de tráfego de saída por mês e 512 MB de RAM abaixo de 40 Mbit/s ou 1 GB acima desse valor. Não existe uma regra fixa de disponibilidade, mas um relay que funciona menos de duas horas por dia tem pouca utilidade para a rede.
O valor de 10 Mbit/s descreve a linha, não a configuração. É necessária uma porta que suporte essa velocidade. A quantidade dessa largura de banda que será permitida ao relay é uma decisão separada, baseada no limite mensal de transferência. Leia o seu plano antes de alterar a configuração. Se ainda estiver a escolher um servidor, quanto custa realmente uma VPS por mês explica como são vendidos os limites de transferência, e medir a velocidade real da rede de uma VPS mostra como descobrir o desempenho da linha com iperf3, em vez de confiar na página comercial.
Reforce a segurança da máquina primeiro. Um relay é um serviço público num endereço público, e o endereço começa a ser analisado poucos minutos depois de ser publicado. Restringir o SSH a chaves e configurar um sshd reforçado demora dez minutos e deve ser feito antes de o relay entrar em funcionamento, não depois.
Instalar o tor a partir do repositório do Tor Project
Use o repositório apt do Tor Project em vez do pacote da distribuição. O código do relay evolui mais rapidamente do que uma versão estável, por isso as correções chegam primeiro a este repositório e o pacote da distribuição fica desatualizado entre versões.
sudo apt update
sudo apt install -y apt-transport-https gnupg wgetAdicione a chave de assinatura e, em seguida, o repositório. O codename é obtido da máquina, por isso o mesmo bloco funciona no Ubuntu 24.04 (noble) e no 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 --versiontor --version mostra a versão que acabou de instalar. Se apt update mostrar um erro NO_PUBKEY, a chave convertida não está no caminho indicado na linha Signed-By:, pelo que o apt não tem nenhuma chave para verificar o ficheiro de versão. O pacote deb.torproject.org-keyring será importante mais tarde: fornece a chave de assinatura como um pacote normal, para que o apt continue a funcionar quando essa chave for substituída.
Ative as atualizações automáticas e, em seguida, indique-lhes a nova origem.
sudo apt install -y unattended-upgrades apt-listchangesNo Ubuntu, adicione a origem do Tor ao bloco Allowed-Origins em /etc/apt/apt.conf.d/50unattended-upgrades:
Unattended-Upgrade::Allowed-Origins {
"${distro_id}:${distro_codename}-security";
"TorProject:${distro_codename}";
};No Debian, o mesmo ficheiro usa Origins-Pattern, onde a linha a adicionar é "origin=TorProject";. Verifique o resultado com sudo unattended-upgrade --debug --dry-run, que mostra as origens sobre as quais vai atuar e não escreve nada.
O torrc que importa
O pacote instala um /etc/tor/torrc extenso e com muitos comentários. Para um relay, apenas algumas linhas são relevantes. Adicione-as ao fim do ficheiro.
Nickname mynicerelay
ContactInfo relay-ops[at]example.com
ORPort 9001
ExitRelay 0
SocksPort 0Nickname tem entre 1 e 19 caracteres e aceita apenas letras e dígitos. Não é único na rede; a impressão digital é que identifica o relay. É o nome que utilizará para encontrar o seu próprio relay numa caixa de pesquisa, por isso escolha algo que consiga soletrar ao telefone.
ContactInfo é publicado dentro do descritor do relay. Esse descritor é um documento público que qualquer pessoa pode transferir, por isso o endereço será recolhido. Use um endereço que continuará a ler daqui a dois anos e, se quiser, ofusque-o. Este é o único canal que o Tor Project tem para o avisar sobre um problema no seu relay.
ORPort 9001 é a porta à qual os outros relays e clientes se ligam. 9001 é a escolha convencional. A porta 443 é outra escolha comum, porque algumas redes restritivas permitem apenas ligações de saída para 443. Assim, um relay que escute nessa porta fica acessível a mais clientes. Escolha 443 apenas se nenhum outro serviço no sistema precisar dela.
SocksPort 0 desativa o proxy SOCKS local, que um relay não utiliza, e remove um socket de escuta do sistema. ExitRelay 0 regista essa intenção no ficheiro: este relay nunca se ligará a um destino em nome de um utilizador, e quem consultar a configuração mais tarde não terá de deduzir isso a partir do valor predefinido.
Se o VPS tiver um endereço IPv6, adicione uma segunda linha ORPort. O Tor não consegue associar-se a qualquer endereço IPv6 da mesma forma que faz com IPv4, por isso escreva o endereço entre parênteses retos.
ORPort 9001
ORPort [2001:db8::1]:9001Num VPS com 1 GB, adicione MaxMemInQueues 512 MB. O Tor determina o limite da fila com base na memória que deteta no sistema. Num servidor partilhado pequeno, esse limite é superior ao que pretende que o processo utilize. Definir o limite manualmente faz com que o tor descarte células em fila sob pressão, permitindo que o relay continue a funcionar, em vez de a fila crescer até o kernel terminar o processo.
Abrir a ORPort no firewall
Nas ligações de entrada, a ORPort tem de ser acessível a partir de qualquer ponto da Internet. Nas ligações de saída, deixe o relay sem restrições: ele abre ligações para milhares de outros relays em muitas portas diferentes, e uma allowlist de saída vai limitá-lo gravemente sem gerar erros claros.
sudo ufw allow 9001/tcp comment 'tor ORPort'
sudo ufw status verboseEm seguida, verifique o firewall de rede do próprio fornecedor. Muitos painéis de controlo executam um filtro de pacotes à frente da máquina virtual. Uma regra adicionada com ufw não tem efeito nesse filtro. Por isso, a porta pode aparecer aberta na máquina e fechada a partir do exterior. Se o ufw for novo para si, as regras do ufw que devem existir em todos os VPS explicam a política predefinida e a ordem pela qual as regras são avaliadas.
Dimensione a largura de banda de acordo com o seu plano
O manual descreve RelayBandwidthRate como um token bucket separado que limita "a utilização média da largura de banda de entrada para o tráfego retransmitido neste nó ao número especificado de bytes por segundo, e a utilização média da largura de banda de saída ao mesmo valor". Leia isto duas vezes. O limite aplica-se separadamente a cada direção. Um relay configurado para 1 Mbit/s pode transferir 1 Mbit/s de entrada e 1 Mbit/s de saída ao mesmo tempo, e um fornecedor que contabilize ambas as direções cobra a soma.
The data behind this chart
[
{
"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"
}
]Essas 5 linhas são cálculos aritméticos, não medições: mostram o custo de uma taxa se o relay a mantiver durante 30 dias completos em ambas as direções. Um relay fica abaixo do limite durante grande parte do tempo, sobretudo nas primeiras semanas. Use a tabela para excluir configurações que não cabem no orçamento, não para prever uma fatura ao gigabyte.
A 1 Mbit/s em cada direção, um relay transfere cerca de 21.6 GB por dia, pelo que um mês de 30 dias custa aproximadamente 648 GB de tráfego contabilizado. Isso cabe numa franquia de 1 TB, deixando margem para atualizações e backups. Se subir para 2 Mbit/s, o mês custa 1,296 GB, o que já ultrapassa um plano de 1 TB. A última linha, 20 Mbit/s, precisa de 12,960 GB por mês e deve usar uma porta sem limite de tráfego. Se o seu fornecedor contabilizar apenas o tráfego de saída, divida todos os valores por dois. Confirme qual dos casos se aplica antes de definir a taxa, porque as duas respostas diferem por um fator de dois.
Agora, a configuração. Limite primeiro a taxa e depois a quota.
RelayBandwidthRate 125 KBytes
RelayBandwidthBurst 250 KBytes
AccountingMax 400 GBytes
AccountingRule sum
AccountingStart month 1 00:00RelayBandwidthBurst é o tamanho do token bucket. Permite picos curtos acima da taxa enquanto a média se mantém dentro do limite. Um valor aproximadamente igual ao dobro da taxa é adequado.
AccountingRule é a linha que muitos operadores não alteram. O valor predefinido é max, que compara a maior das duas direções com a quota. Com o valor predefinido, AccountingMax 400 GBytes permite 400 GB de entrada e 400 GB de saída, o que corresponde a 800 GB num contador que contabilize ambas as direções. AccountingRule sum contabiliza a leitura e a escrita contra uma única quota, que é o que uma franquia de transferência mede efetivamente.
Escreva também AccountingStart, nunca apenas AccountingMax. A quota é o valor, e a linha de início define o período em que ela é reposta. Uma quota sem período deixa o relay em hibernação, sem nada que o possa reativar.
A hibernação é um mecanismo brusco. Quando a quota se esgota, tor regista o evento e deixa de aceitar trabalho:
Bandwidth soft limit reached; commencing hibernation. No new connections will be acceptedO relay também não é reativado exatamente no início do período seguinte. Tor regista a velocidade a que a quota anterior foi consumida e escolhe um momento aleatório dentro do novo intervalo, para que milhares de relays não regressem à rede no mesmo segundo. Um relay que desaparece durante a última semana de cada mês perde continuamente a estabilidade que as autoridades de diretório usam para o avaliar. Dimensione RelayBandwidthRate para que o limite nunca seja atingido e mantenha AccountingMax como salvaguarda que protege a fatura.
Inicie o relay e confirme que está acessível
sudo systemctl restart tor@default
sudo systemctl status tor@default
sudo journalctl -u tor@default -n 50Dentro de alguns minutos, o log deverá conter esta linha:
Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor.Essa mensagem significa que outros relays estabeleceram ligação com a sua ORPort e criaram um circuito através dela. Até essa mensagem aparecer, o seu relay não está no diretório e não transporta tráfego. O erro aparece assim:
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.Verifique os pontos pela ordem indicada. A ORPort está aberta no ufw? Também está aberta na firewall de rede separada do provedor? O endereço apresentado nessa mensagem é o endereço para o qual a Internet encaminha efetivamente o tráfego, e não um endereço privado de uma configuração NAT? Teste a porta a partir de outra máquina com nc -vz 203.0.113.10 9001. O Tor repete o teste de conectividade automaticamente, por isso deteta uma firewall corrigida sem intervenção adicional. Um reinício torna o teste imediato.
A identidade permanente do seu relay é a respetiva impressão digital:
sudo cat /var/lib/tor/fingerprintCerca de três horas depois de o descritor ser publicado, o relay aparece no Relay Search. Pesquise pelo nickname ou cole a impressão digital. Essa página mostra o que a rede considera sobre o seu relay: os flags que ele possui, o peso que as autoridades lhe atribuem e a versão que está a publicar.
Por que um novo relay Tor transporta quase nenhum tráfego?
Porque a rede ainda não o mediu, e essa medição demora semanas. O Tor Project descreve a progressão em quatro fases, mas um operador que não a conhece conclui que o relay está avariado e começa a alterar configurações.
Durante os primeiros três dias, o relay não é medido. Ele comunica o resultado do próprio autoteste, mas as autoridades de diretório limitam o peso publicado a 20 KB, por isso os clientes quase nunca o selecionam. Aproximadamente do terceiro ao oitavo dia, as autoridades de largura de banda medem-no efetivamente e o peso aumenta. No entanto, ele é usado apenas como salto intermédio, porque nenhum cliente está disposto a tornar um relay totalmente novo no seu primeiro salto.
Por volta do oitavo dia, o relay torna-se elegível para o sinalizador Guard. Obter esse sinalizador faz o tráfego diminuir, o que surpreende toda a gente: os clientes ignoram os guards ao escolher saltos intermédios, partindo do princípio de que um guard já está ocupado. Assim, o relay perde tráfego intermédio antes de ganhar tráfego de guard. O tráfego só volta a aumentar à medida que os clientes rodam os seus conjuntos de guards, o que demora semanas. Por volta do dia 68, atinge um estado estável, no qual os clientes que o removem equilibram os clientes que o adicionam.
Por isso, a expectativa realista é não haver nada durante três dias, haver algum tráfego depois de uma semana e haver carga significativa depois de dois meses. Altere uma configuração e aguarde uma semana para verificar o efeito. Uma página de estado Uptime Kuma autoalojada com uma verificação TCP na porta 9001 é uma utilização melhor dessa preocupação: responde à pergunta que pode realmente controlar, ou seja, se a porta continua a responder.
Monitorizar o relay com nyx
nyx é o monitor de terminal de um relay em execução. Comunica com a porta de controlo do tor, por isso ative-a primeiro em torrc:
ControlPort 9051
CookieAuthentication 1
CookieAuthFileGroupReadable 1ControlPort escuta apenas em 127.0.0.1, e a autenticação por cookie exige que um programa leia um ficheiro secreto antes de poder emitir comandos. O Tor escreve esse cookie em /run/tor/control.authcookie como o utilizador debian-tor, com o modo 600, para que mais nada o possa ler. CookieAuthFileGroupReadable 1 abre o acesso ao grupo, permitindo que a sua própria conta execute o nyx sem sudo.
sudo apt install -y nyx
sudo adduser "$USER" debian-tor
sudo systemctl restart tor@defaultTermine a sessão e inicie-a novamente; depois execute nyx. O novo grupo tem de ser aplicado no início da sessão, por isso executar o nyx na mesma sessão da shell produz um erro de permissão no ficheiro de cookie, mesmo que a configuração esteja correta. O nyx mostra a largura de banda em tempo real, o tempo de atividade, o fluxo de logs e a lista de ligações. Nas primeiras semanas, o valor a monitorizar é o gráfico de largura de banda permanecer abaixo do seu RelayBandwidthRate.
Executar mais de um relay: MyFamily e chaves de família
Se tiver apenas um relay, ignore esta seção. Dois ou mais relays operados pelo mesmo administrador devem declarar uns aos outros. Assim, os clientes nunca criam um circuito que entre e saia pelas suas máquinas. Caso contrário, um único administrador poderia ver as duas extremidades do circuito.
O método usado há mais tempo é MyFamily no torrc de cada relay, listando as fingerprints de todos os outros:
MyFamily AAAAAAAAAA,BBBBBBBBCada relay lista todos os outros. Portanto, adicionar um quarto relay exige editar quatro arquivos. O Tor 0.4.9 substituiu esse método por uma chave de família. Gere uma chave e compartilhe-a:
tor --keygen-family myfamilyEsse comando grava myfamily.secret_family_key e exibe uma linha FamilyId. Copie o arquivo de chave para cada relay, no subdiretório keys do DataDirectory (/var/lib/tor/keys no Debian e no Ubuntu), mantendo o sufixo .secret_family_key. Adicione a linha FamilyId exibida a cada torrc e recarregue com sudo systemctl reload tor@default. Por enquanto, mantenha também a lista MyFamily. Os clientes que ainda não entendem certificados de família continuam lendo a lista legada. O Tor Project informará quando ela puder ser removida.
O que avaria depois de estar em execução
A versão fica desatualizada. As atualizações automáticas substituem o pacote, mas o processo em execução continua a usar o binário com que foi iniciado até ser reiniciado. Compare tor --version no servidor com a versão apresentada na página Relay Search do relay. Se forem diferentes, a rede continua a ver a versão antiga, por isso reinicie o serviço.
O relógio fica dessincronizado. Os documentos de consenso e os certificados têm todos limites temporais, por isso uma máquina cujo relógio esteja muito adiantado ou atrasado rejeita o consenso e deixa de publicar. timedatectl deve indicar que o relógio do sistema está sincronizado. Se não estiver, ative systemd-timesyncd ou instale chrony.
O endereço IP muda. O descriptor contém o endereço, e os clientes não conseguem aceder a um endereço que mudou. Depois de qualquer migração de fornecedor ou alteração de endereço, reinicie tor e monitorize novamente a linha do autoteste.
O relay é mais lento do que o plano permite. A criptografia de relay do Tor é eficiente nos processadores modernos, e o Tor Project estima cerca de 400 a 450 Mbit/s em cada direção para uma CPU com suporte para AES-NI. Muito antes desse limite, ficará condicionado pela velocidade da porta e pelo limite de transferência. É por isso que a secção sobre contabilização acima é mais importante do que o hardware.
FAQ
Quanto de largura de banda um relay Tor utiliza?
Utiliza o máximo que você permitir, e não mais do que isso. RelayBandwidthRate limita o tráfego retransmitido separadamente em cada direção, portanto um relay configurado para 1 Mbit/s pode transportar simultaneamente 1 Mbit/s de entrada e 1 Mbit/s de saída. Isso corresponde a cerca de 21.6 GB por dia, ou 648 GB num mês de 30 dias, contando as duas direções. Adicione AccountingMax com AccountingRule sum como quota mensal rígida abaixo desse limite.
Executar um relay Tor fará com que eu receba reclamações de abuso?
Um relay guard ou middle encaminha o tráfego apenas para outros relays Tor e nunca se liga a um site em nome de um utilizador. Por isso, as reclamações sobre algo que alguém fez através do Tor são enviadas ao operador do relay de saída, não a você. O que você poderá observar são varreduras e, ocasionalmente, listagens em bases de reputação de IP, porque o endereço está publicamente listado como relay. Os relays de saída são os que recebem mensagens de abuso e notificações legais. Eles precisam de um fornecedor que tenha concordado antecipadamente em tratar desses casos. Leia os termos do seu fornecedor antes de iniciar qualquer um dos dois tipos.
Por que o meu novo relay Tor não está a receber tráfego?
Porque os relays novos são limitados por conceção até serem medidos. Durante os primeiros três dias, as autoridades de diretório limitam o peso publicado a 20 KB, portanto os clientes quase nunca escolhem o relay. As autoridades de largura de banda fazem a medição a partir de aproximadamente o terceiro dia. O relay torna-se elegível para a flag Guard por volta do oitavo dia, e o tráfego diminui novamente nesse momento porque os clientes evitam guards ao escolher saltos intermédios. A carga completa chega por volta do dia 68. Confirme que o log mostra "Self-testing indicates your ORPort is reachable from the outside" e, depois, não altere nada.
Posso executar um relay Tor numa VPS com uma franquia de transferência de 1 TB?
Sim, a cerca de 1 Mbit/s em cada direção, o que corresponde a RelayBandwidthRate 125 KBytes. Isso equivale a aproximadamente 648 GB por mês se o seu fornecedor contabilizar as duas direções, deixando margem para atualizações e backups. Adicione AccountingMax 400 GBytes com AccountingRule sum e AccountingStart month 1 00:00 para que o relay entre em hibernação em vez de exceder o plano. Se o fornecedor cobrar apenas o tráfego de saída, você pode duplicar a taxa.
Preciso definir MyFamily se executar apenas um relay?
Não. As declarações de família existem para que os clientes evitem criar um circuito através de dois relays pertencentes ao mesmo operador. Isso não tem efeito quando existe apenas um relay. Defina-a assim que adicionar um segundo relay: liste a fingerprint de cada relay na linha MyFamily de todos os relays ou use a chave de família introduzida pelo Tor 0.4.9, que distribui um FamilyId em vez de uma lista cada vez maior.