Como executar um relay Tor numa VPS Linux

O que um relay Tor faz numa VPS

Um relay Tor é um daemon Tor executado numa máquina com um endereço IP público que encaminha tráfego cifrado de 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. Nunca abre uma ligação a um site em nome de um desconhecido. Esse facto explica por que não recebe mensagens de abuso e por que esta é a contribuição adequada para uma VPS comum. Um relay transporta o tráfego de outras pessoas e não publica conteúdo próprio. Se pretende colocar o seu próprio site na rede, em vez de encaminhar pacotes para ele, executar um serviço onion v3 atrás do nginx é uma tarefa diferente para o mesmo daemon tor. Executar um relay também não melhora a privacidade da sua própria navegação. Esse é um problema separado, com um limite inferior ao que a maioria das pessoas espera: o que o alojamento próprio do SearXNG realmente oculta é uma medida razoável do que consegue obter ao mover um serviço para a sua própria VPS.

O trabalho é pequeno: um pacote, quinze linhas de configuração, uma regra de firewall e um reinício. O restante deste guia aborda a parte que costuma falhar. Inclui os cálculos de largura de banda num plano 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 daemon executa as quatro funções. A sua configuração, juntamente com as autoridades de diretório, determina qual delas irá assumir.

• 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 nesta função.
• Relay guard. Usa a mesma configuração, com uma flag adicional. As autoridades de diretório atribuem a flag Guard aos relays que permanecem rápidos e estáveis durante tempo suficiente. Não é você que a escolhe. Você conquista-a, 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: pouca largura de banda, sem listagem pública e o primeiro passo adequado se o seu plano for pequeno. Também precisa de um proxy obfs4 a executar juntamente com o daemon e de um conjunto diferente de linhas no torrc. O guia configurar um bridge obfs4 num VPS barato explica o processo, incluindo como entregar a bridge line aos utilizadores no final.
• Relay exit. É o último salto e abre a ligação ao site de destino. Cada pedido feito por um utilizador sai do seu endereço IP. Por isso, as denúncias de abuso e os contactos das autoridades chegam ao titular desse endereço.

A função exit é a única que não deve ser executada num VPS de uso geral. Execute um exit apenas num fornecedor que tenha concordado previamente em receber esse correio, com um endereço IP próprio e um contacto de abuso publicado. A maioria das condições normais de alojamento proíbe essa função. O resultado habitual de ignorar essa proibição é a suspensão do servidor e a perda do endereço IP. Se essa for mesmo a função que pretende executar, o que envolve realmente executar um relay exit explica como encontrar um host compatível com exits, definir a exit policy e o reverse DNS e responder ao correio quando ele chegar. 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 middle.

O que o VPS precisa antes de começar

O Tor Project publica requisitos mínimos para relays. Em agosto de 2026, são os seguintes: um endereço IPv4 público para o relay, pelo menos 10 Mbit/s de largura de banda em cada direção, 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 ligação, não a configuração. É necessária uma porta que suporte essa velocidade. A quantidade dessa largura de banda que permitirá ao relay utilizar é uma decisão separada, baseada no limite mensal de transferência. Consulte o seu plano antes de alterar a configuração. Se ainda está a escolher um servidor, quanto custa realmente um VPS por mês explica como são vendidos os limites de transferência, e medir o débito de rede real de um VPS mostra como descobrir o desempenho da ligação 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 reforçar a configuração do sshd demora dez minutos e deve ser feito antes de o relay entrar em funcionamento, não depois.

Instale o Tor a partir do repositório do Tor Project

Use o repositório apt próprio 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 wget

Adicione 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 --version

tor --version mostra a versão que acabou de instalar. Se apt update tiver mostrado um erro NO_PUBKEY, a chave convertida para o formato dearmored não está no caminho indicado na linha Signed-By:, por isso o apt não tem uma 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, informe-as sobre a nova origem.

sudo apt install -y unattended-upgrades apt-listchanges

No 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. A linha a adicionar é "origin=TorProject";. Verifique o resultado com sudo unattended-upgrade --debug --dry-run, que mostra as origens sobre as quais atuará e não escreve nada.

O torrc que importa

O pacote instala um /etc/tor/torrc longo e com muitos comentários. Para um relay, apenas algumas linhas importam. Adicione-as no fim do ficheiro.

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

Nickname tem entre 1 e 19 caracteres e aceita apenas letras e dígitos. Não é exclusivo na rede; a identidade é o fingerprint. É assim que encontrará o seu próprio relay numa caixa de pesquisa, por isso escolha um nome que consiga soletrar ao telefone.

ContactInfo é publicado no descriptor do relay, que é um documento público que qualquer pessoa pode descarregar. Por isso, o endereço será recolhido. Use um endereço que ainda leia 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 outros relays e clientes se ligam. 9001 é a escolha convencional. A porta 443 é outra opção comum, porque algumas redes restritivas permitem apenas ligações de saída na porta 443. Assim, um relay que escute nessa porta fica acessível a mais clientes. Escolha 443 apenas se nenhum outro serviço no servidor 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]:9001

Num VPS com 1 GB, adicione MaxMemInQueues 512 MB. O Tor calcula o limite da fila com base na memória que deteta no sistema. Num servidor partilhado pequeno, esse valor é superior ao que pretende que o processo utilize. Definir o limite manualmente faz com que o tor descarte células em fila quando há pressão de memória. O relay mantém-se em execução, em vez de a fila crescer até o kernel terminar o processo.

Abrir a ORPort na firewall

A ORPort tem de estar acessível a partir de qualquer ponto da Internet para ligações de entrada. Para ligações de saída, deixe o relay sem restrições: este abre ligações para milhares de outros relays em muitas portas diferentes, e uma allowlist de saída irá limitá-lo gravemente sem gerar erros visíveis.

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

Em seguida, verifique a firewall de rede do próprio fornecedor. Muitos painéis de controlo executam um filtro de pacotes à frente da máquina virtual. Nesse caso, uma regra adicionada com ufw não tem efeito nesse filtro. A porta aparece aberta na máquina, mas fechada a partir do exterior. Se o ufw for novidade para si, as regras 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 bucket de tokens 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.

[
  {
    "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, 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 plano, 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. Assim, um mês de 30 dias corresponde aproximadamente a 648 GB de tráfego contabilizado. Isto cabe num plano com 1 TB, deixando margem para atualizações e cópias de segurança. Se aumentar para 2 Mbit/s, o mês corresponde a 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 ser usada numa porta sem tráfego contabilizado. Se o fornecedor contabilizar apenas o tráfego de saída, divida todos os valores por dois. Confirme qual é o seu caso antes de definir a taxa, porque as duas respostas diferem por um fator de dois.

Agora, a configuração. Primeiro limite a taxa. Depois defina a quota.

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

RelayBandwidthBurst é o tamanho do bucket de tokens. Por isso, permite picos curtos acima da taxa enquanto a média se mantém dentro do limite. Cerca de duas vezes a taxa é um valor adequado.

AccountingRule é a linha que muitos operadores ignoram. O valor predefinido é max, que compara a maior das duas direções com a quota. Com esse 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 soma as leituras e as escritas na mesma quota. É isso que uma franquia de transferência mede na prática.

Escreva também AccountingStart. Nunca use AccountingMax sozinho. 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 suspenso, sem uma condição que o reative.

A hibernação é um mecanismo pouco preciso. Quando a quota se esgota, o tor regista o evento e deixa de aceitar trabalho:

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

O relay também não é reativado exatamente no início do período seguinte. O Tor acompanha a velocidade a que a quota anterior foi consumida e escolhe um momento aleatório dentro do novo intervalo. Assim, milhares de relays não regressam à rede no mesmo segundo. Um relay que desaparece durante a última semana de cada mês perde continuamente a estabilidade pela qual as autoridades de diretório o avaliam. Dimensione RelayBandwidthRate para que o limite nunca seja atingido e mantenha AccountingMax como proteção final contra uma fatura inesperada.

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 50

Dentro de alguns minutos, o log deverá conter esta linha:

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

Esta frase significa que outros relays estabeleceram ligações de volta à sua ORPort e criaram um circuito através dela. Até esta linha aparecer, o seu relay não está no diretório e não transporta tráfego. A falha 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 fornecedor? 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 automaticamente o autoteste, por isso deteta uma firewall corrigida sem intervenção adicional. Um restart torna o teste imediato.

A identidade permanente do seu relay é o fingerprint:

sudo cat /var/lib/tor/fingerprint

Cerca de três horas depois de o descriptor ser publicado, o relay aparece no Relay Search. Pesquise pelo nickname ou cole o fingerprint. Essa página mostra o que a rede sabe sobre o seu relay: que flags possui, que weight as authorities lhe atribuem e que versão está a publicar.

Por que um novo relay Tor transporta quase nenhum tráfego?

Porque a rede ainda não o mediu, e a medição demora semanas. O Tor Project descreve o processo em quatro fases, mas um operador que não o leu 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 seu próprio autoteste, mas as autoridades de diretório limitam o peso publicado a 20 KB, por isso os clientes quase nunca o selecionam. Entre aproximadamente o terceiro e o oitavo dia, as autoridades de largura de banda medem-no efetivamente e o peso aumenta, mas ele é usado apenas como salto intermédio, porque nenhum cliente aceita fazer de um relay completamente novo o seu primeiro salto.

Por volta do oitavo dia, o relay torna-se elegível para a flag Guard. Obter essa flag faz o tráfego diminuir, o que surpreende toda a gente: ao escolher saltos intermédios, os clientes ignoram os guards, 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. Só recupera tráfego à medida que os clientes renovam os seus conjuntos de guards, o que demora semanas. Por volta do dia 68, atinge um estado estável, em que 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 existir uma carga significativa após dois meses. Altere uma definição e espere uma semana para observar o efeito. Uma página de estado Uptime Kuma alojada localmente com uma verificação TCP à 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 1

ControlPort 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 grava esse cookie em /run/tor/control.authcookie como o utilizador debian-tor, com o modo 600, para que mais ninguém 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@default

Termine a sessão e volte a iniciar sessão; depois execute nyx. O novo grupo só é aplicado no início da sessão, por isso executar o nyx na mesma sessão de shell gera um erro de permissões 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 de RelayBandwidthRate.

Executar mais de um relay: MyFamily e chaves de família

Com um único 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 operador poderia ver as duas extremidades do circuito.

O método tradicional consiste em usar MyFamily no torrc de cada relay, listando as impressões digitais de todos os outros relays:

MyFamily AAAAAAAAAA,BBBBBBBB

Cada relay lista todos os outros. Por isso, 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 depois compartilhe-a:

tor --keygen-family myfamily

Esse comando grava myfamily.secret_family_key e exibe uma linha FamilyId. Copie o arquivo da 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 o serviço 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 anunciará quando ela puder ser removida.

O que falha depois de estar a funcionar

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é algo o reiniciar. 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, pelo que deve reiniciar o serviço.

O relógio deriva. Os documentos de consenso e os certificados têm todos uma validade temporal, 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 alcançar um endereço que mudou. Depois de qualquer migração de fornecedor ou alteração de endereço, reinicie o tor e monitorize novamente a linha do autoteste.

O relay é mais lento do que o plano permite. A criptografia de relay do Tor é eficiente em 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á limitado pela velocidade da porta e pelo limite de transferência. Por isso, a secção sobre contabilização acima é mais importante do que o hardware.

FAQ

Quanto tráfego de rede utiliza um relay Tor?

Utiliza o volume que definir, sem ultrapassá-lo. RelayBandwidthRate limita separadamente o tráfego retransmitido em cada direção. Assim, um relay configurado para 1 Mbit/s pode transportar 1 Mbit/s de entrada e 1 Mbit/s de saída em simultâneo. Isto 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 receba reclamações de abuso?

Um relay guard ou middle encaminha 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 o que alguém fez através do Tor são enviadas ao operador do relay exit, não a si. Poderá receber varrimentos e, ocasionalmente, ver o endereço IP incluído em listas de reputação, porque está publicado como relay. Os relays exit são os que recebem mensagens de abuso e notificações legais. Precisam de um fornecedor que tenha aceitado previamente tratar desses casos. Leia os termos do fornecedor antes de iniciar qualquer um dos dois tipos.

Por que motivo o meu novo relay Tor não está a receber tráfego?

Porque os novos relays são limitados intencionalmente até serem medidos. Durante os primeiros três dias, as autoridades de diretório limitam o peso publicado a 20 KB. Por isso, os clientes quase nunca escolhem o relay. As autoridades de largura de banda começam a medi-lo por volta do terceiro dia. O relay torna-se elegível para a flag Guard por volta do oitavo dia. Nessa altura, o tráfego volta a diminuir porque os clientes evitam guards ao escolher os hops intermédios. A carga total 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 a configuração.

Posso executar um relay Tor numa VPS com um limite 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 aproximadamente a 648 GB por mês se o 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 ultrapassar o plano. Se o fornecedor cobrar apenas o tráfego de saída, pode duplicar o limite.

Preciso de 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 se aplica quando existe apenas um relay. Defina-a assim que adicionar um segundo relay: liste o fingerprint de cada relay na linha MyFamily de todos os relays ou utilize a chave de família introduzida pelo Tor 0.4.9, que distribui um FamilyId em vez de uma lista que cresce continuamente.