Como operar um nó de saída Tor com segurança

O que um nó de saída Tor faz e quem ele o identifica

Um nó de saída Tor é o último relay de um circuito: a máquina que abre a ligação para o destino. Por isso, o destino regista o endereço do seu servidor e nunca o do utilizador. Todas as outras decisões deste guia resultam desse facto. O endereço é tratado como a origem de tudo o que passa por ele. Portanto, tem de ser um endereço dedicado, num provider que tenha concordado em transportar este tráfego.

Executar um nó de saída é o oposto de se esconder. O relay aparece num diretório público que qualquer pessoa pode descarregar. O seu endereço de contacto fica nesse diretório em ContactInfo. O seu nome de reverse DNS (domain name system) indica o que é a máquina. A porta 80 apresenta uma página que diz o mesmo. E é você que responde às mensagens de abuso, em seu próprio nome. Ninguém neste sistema é mais identificável do que um operador de nó de saída. Essa é a função. É por isso que ela funciona.

Nós executamos estes nós. A SSD Nodes opera relays de saída em vários países como contribuição para a liberdade de expressão. Alugamos essas máquinas a providers que aderiram deliberadamente ao tráfego de saída. Não somos o provider dessas máquinas. Isso é intencional. A próxima secção explica porquê.

Onde um exit é adequado e onde não é

Um exit não é adequado num VPS (servidor privado virtual) de uso geral, e isso inclui o nosso. Uma rede de uso geral transporta websites, correio, backups e painéis de controlo de milhares de clientes sem relação entre si, em endereços vizinhos. O tráfego de exit faz com que um desses endereços apareça em relatórios de varredura e listas de bloqueio de spam, e os efeitos recaem sobre os vizinhos. Os fornecedores que alojam exits de forma adequada prepararam a infraestrutura para isso: espaço de endereçamento reservado para essa finalidade e uma equipa de abuso que já conhece o Tor.

Por isso, quando um anfitrião deste guia lhe diz para comprar a máquina noutro lugar, essa é a parte útil. Sabemos o que o tráfego de exit faz a um endereço porque pagamos a outras pessoas para transportarem o nosso, e pagamos porque transportá-lo corretamente é uma atividade diferente da venda de servidores de uso geral.

O Tor Project afirma o mesmo de forma mais direta. A página tipos de relays indica que os relays de exit "têm a maior exposição e responsabilidade jurídicas entre todos os relays" e que "não deve executar um relay de exit a partir de casa". Um VPS de uso geral que aloja os seus próprios projetos está mais próximo de casa do que parece. É uma máquina com a qual se preocupa, num endereço que quer manter limpo.

Se tem um VPS comum e quer ajudar a rede esta semana, execute nele um relay que não seja exit ou uma bridge. Isso não é um prémio de consolação. É uma função diferente, com um perfil de risco diferente, e a rede precisa de ambos. Um relay que não seja exit nunca abre uma ligação para um destino, por isso gera quase nenhuma reclamação, e as orientações do Tor recomendam pelo menos 2 MByte/s (megabytes por segundo) em cada direção antes de valer a pena listá-lo. Uma bridge é um ponto de entrada não listado para utilizadores em redes censuradas. Precisa de conectividade 24/7 e de uma porta TCP (protocolo de controlo de transmissão) aberta, o que faz dela a contribuição de maior valor que uma máquina pequena pode oferecer. Ambos são adequados para hardware que já possui. Um exit não é.

Como encontrar um provedor favorável a exits?

Pergunte antes de contratar, por escrito, e guarde a resposta. As diretrizes para exits do Tor sugerem fazer a pergunta em duas etapas: primeiro, se o provedor aceita um exit do Tor; depois, se atribui um endereço ou intervalo dedicado para esse fim. Perguntar as duas coisas ao mesmo tempo tende a provocar uma recusa automática.

Quatro perguntas mostram se um provedor está realmente preparado para isso.

• Vai atribuir um endereço IP dedicado, que não aloje mais nada, e definir o registo DNS inverso que eu solicitar?
• Quem recebe as mensagens de abuso e vai encaminhá-las para mim sem alterações, mantendo intacto o endereço do remetente para que eu possa responder diretamente?
• O que acontece na primeira reclamação: encaminham-na para mim ou fazem primeiro um null-route do endereço e só depois perguntam?
• Quantos exits já estão nesta rede? As diretrizes do Tor são claras sobre este ponto: "não ajuda concentrar demasiados exits num ISP que já é favorável".

A última pergunta é mais importante do que parece. Parte do valor de um exit depende da sua localização na rede. Outro exit numa rede que já aloja cinquenta acrescenta menos valor do que a mesma máquina num local novo. O Relay Search mostra que redes já transportam exits, para que possa verificar isso antes de se comprometer.

Obtenha as respostas antes de pagar e contrate a máquina numa conta própria, em vez de a adicionar à conta onde estão os outros servidores. A segurança do alojamento VPS depende sobretudo do que coloca junto de quê, e este é o exemplo mais claro dessa regra.

Um endereço, uma função

O endereço de saída não pode alojar mais nada. Nenhum site, serviço de correio, VPN, dashboard de monitorização ou jump host SSH (secure shell) pessoal. O endereço acabará em blocklists, e qualquer outro serviço alojado nele começará a falhar de formas difíceis de diagnosticar. Um endereço dedicado a uma única função também torna curta a resposta a reclamações: este endereço é um relay de saída e não faz mais nada.

Antes de iniciar o tor, faça o trabalho habitual. Use SSH apenas com chaves, desative o login por palavra-passe e configure uma firewall que permita apenas as portas publicadas. Reforçar a segurança do SSH numa VPS cobre a primeira parte e Noções básicas da firewall ufw cobre a segunda. Um relay de saída publica exatamente duas portas para a Internet: a ORPort, que transporta o tráfego do Tor, e a porta 80, para a página de aviso do relay. Todas as outras portas permanecem fechadas.

Ative as atualizações automáticas, porque um relay de saída que continue a executar uma versão antiga do tor é um problema para todos os utilizadores encaminhados através dele.

sudo apt update && sudo apt install -y unattended-upgrades
sudo dpkg-reconfigure -plow unattended-upgrades

Não adicione logging. Capturar o texto simples que sai de um relay de saída é tecnicamente fácil, mas é algo que um operador nunca deve fazer. A FAQ jurídica do Tor da EFF recomenda que os operadores não o façam, porque a legislação norte-americana sobre interceção de comunicações e legislação comparável noutros países pode criar responsabilidade legal por examinar esse tráfego. Mantenha o logging no nível de notice predefinido do tor e nada mais.

Instalar o tor a partir do repositório do Tor Project

Os pacotes da distribuição ficam desatualizados. Use o repositório do próprio Tor Project para receber as correções de segurança no dia em que forem lançadas. Em agosto de 2026, a série estável atual é a 0.4.9.

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

Escreva /etc/apt/sources.list.d/tor.sources, substituindo noble pelo codinome que lsb_release -cs apresentou:

Types: deb deb-src
URIs: https://deb.torproject.org/torproject.org/
Suites: noble
Components: main
Signed-By: /usr/share/keyrings/deb.torproject.org-keyring.gpg

Adicione a chave de assinatura e instale:

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

O pacote deb.torproject.org-keyring mantém essa chave atualizada automaticamente, para que o repositório não deixe de funcionar no dia em que a chave for substituída. Se apt update informar que o mesmo repositório está configurado duas vezes, você tem um ficheiro .list e um ficheiro .sources que o referenciam, e o erro de fonte duplicada do deb822 explica como remover essa duplicação.

DNS: o seu exit resolve nomes para todos os utilizadores que o utilizam

Um exit faz as consultas de nomes para cada circuito que sai através dele, por isso o seu resolver vê um fluxo de nomes pertencentes a outras pessoas. Se apontar esse fluxo para um resolver público de grande dimensão, entrega-o na totalidade a uma empresa. Essa é precisamente a centralização que Tor pede aos operadores de exits para evitarem. Em vez disso, execute um resolver com validação e cache no próprio servidor.

sudo apt install -y unbound bind9-dnsutils
sudo cp /etc/resolv.conf /etc/resolv.conf.backup
echo "nameserver 127.0.0.1" | sudo tee /etc/resolv.conf
sudo chattr +i /etc/resolv.conf
sudo systemctl enable --now unbound

chattr +i marca o ficheiro como imutável, porque os clientes DHCP (protocolo de configuração dinâmica de anfitriões) e o resolvconf reescrevem /etc/resolv.conf segundo o seu próprio calendário. Sem essa proteção, um reboot pode voltar a direcionar as suas consultas para o resolver do fornecedor, sem qualquer aviso de que isso aconteceu. As instruções de Tor para Debian e Ubuntu também ativam a minimização dos nomes consultados, que envia para cada servidor de nomes apenas a parte do nome de que este realmente precisa:

server:
    qname-minimisation: yes

Coloque isso num ficheiro dentro de /etc/unbound/unbound.conf.d/ e confirme que o resolver responde:

sudo systemctl restart unbound
dig +short example.com @127.0.0.1

Um endereço na resposta significa que unbound está a funcionar. Se unbound falhar ao iniciar com address already in use, outro processo está a utilizar a porta 53: execute sudo ss -lntup | grep :53 e verifique qual é o processo que a detém. No Ubuntu, systemd-resolved escuta em 127.0.0.53, por isso não entra em conflito com unbound em 127.0.0.1.

A configuração torrc de um relay de saída

O pacote Debian lê /etc/tor/torrc. Esta é toda a configuração relevante para a saída.

Nickname     exampleExit01
ORPort       443
ExitRelay    1
SocksPort    0
ContactInfo  email:tor[]example.org abuse:abuse[]example.org url:https://example.org ciissversion:3
ReducedExitPolicy 1
Log          notice syslog

Cada linha é essencial, por isso analise-as uma de cada vez.

ORPort 443 é onde os outros relays se ligam a si. A porta 443 atravessa redes restritivas que bloqueiam portas invulgares, por isso o seu relay fica acessível a mais pessoas do que ficaria na porta tradicional 9001. Só pode usar a 443 porque nenhum outro serviço neste servidor precisa dela, o que constitui mais um argumento a favor do endereço dedicado.

SocksPort 0 desativa o proxy SOCKS local. Um relay nunca precisa dele, e uma porta SOCKS à escuta num endereço público é um proxy aberto que será encontrado e abusado em poucas horas.

ExitRelay 1 é a opção que transforma este servidor num relay de saída. Defina-a explicitamente em vez de depender de um valor predefinido, para que o ficheiro de configuração indique claramente a função da máquina.

ContactInfo é publicado no diretório público para leitura por qualquer pessoa. Escreva-o no formato ContactInfo Information Sharing Specification, que é o formato analisado pelas ferramentas da rede, e mantenha ciissversion:3 nele. O [] em vez de @ é a convenção usada pela especificação para dificultar a recolha automática de endereços. Use uma caixa de correio que consulte todos os dias, porque é para este endereço que chegam as mensagens de abuso.

Se o servidor tiver IPv6 funcional, adicione uma ORPort IPv6 e ative a saída por IPv6. Omita ambas se não tiver, porque um relay que anuncia um endereço que não consegue realmente usar falha o próprio teste de acessibilidade.

ORPort   [2001:db8::1]:443
IPv6Exit 1

Política de saída: o que cada porta permite

A política de saída é a lista de destinos aos quais o seu relay aceita ligar-se. O Tor lê essa lista de cima para baixo, e a primeira regra correspondente prevalece. ReducedExitPolicy 1 seleciona uma lista definida de cerca de 70 portas, que abrange a Web, o envio de correio, o chat e o Git, e exclui as portas que geram mais reclamações. É o ponto de partida adequado para um primeiro relay de saída.

Há duas regras que deve conhecer pelo nome. ExitPolicyRejectPrivate está ativa por predefinição. Impede o relay de ligar-se a intervalos de endereços privados e aos próprios endereços do relay. Isto impede que o relay de saída seja direcionado para a rede interna do seu fornecedor. A porta 25 (SMTP, simple mail transfer protocol) é rejeitada e deve continuar rejeitada. Permiti-la transforma o relay numa fonte de spam, e o endereço entra numa blocklist em poucos dias.

Um relay de saída tem de permitir as portas 80 e 443 para ser útil. A documentação do relay de saída do Tor afirma esse requisito mínimo diretamente. Se o seu fornecedor exigir uma política mais restritiva do que a política reduzida, um relay de saída apenas para a Web continua a ser uma contribuição válida:

ExitPolicy accept *:80
ExitPolicy accept *:443
ExitPolicy reject *:*

Termine a lista com reject *:* para que a sua política seja autónoma e nada mais seja herdado. A política reduzida permite a porta 22 (SSH), que é a origem habitual de relatórios de tentativas de força bruta. Por isso, adicione ExitPolicy reject *:22 antes das restantes regras se preferir não receber mensagens desse tipo. As portas de partilha de ficheiros no intervalo 6881-6999 são a origem habitual de notificações de direitos de autor, e a política reduzida já as exclui.

Uma alteração da política só chega aos clientes depois de o relay publicar um novo descritor e de o diretório o propagar. Por isso, aguarde algumas horas antes de avaliar o efeito.

Informações de contacto, chaves da família e registo do relay

Registar um exit significa associá-lo a um nome que qualquer pessoa possa verificar. Existem dois mecanismos para isso, e funcionam em conjunto.

O primeiro é um ficheiro conhecido. Publique a identidade da sua família num domínio que controla e indique essa prova em ContactInfo:

ContactInfo email:tor[]example.org url:https://example.org proof:uri-familyid-ed25519 ciissversion:3

O ficheiro fica em https://example.org/.well-known/tor-relay/ed25519-family-id.txt e contém o ID da sua família. Qualquer pessoa pode confirmar que quem reivindica estes relays também controla esse domínio. Essa é a diferença entre um endereço de contacto e um endereço verificado.

O segundo mecanismo é a própria família. Se executar mais de um relay, a rede precisa de saber que partilham o mesmo operador, para que um cliente nunca crie um circuito através de duas das suas máquinas. O tor atual faz isso com uma chave de família, denominada Happy Families, em relays que executam a versão 0.4.9.2-alpha ou posterior:

tor --keygen-family exampleFamily

Esse comando cria exampleFamily.secret_family_key e apresenta uma linha FamilyId. Copie o ficheiro da chave secreta para o diretório de chaves de cada relay (/var/lib/tor/keys no Debian e Ubuntu), mantenha o sufixo .secret_family_key no nome do ficheiro, adicione a linha FamilyId apresentada a cada torrc e recarregue o tor. A documentação do Tor é explícita: ainda tem de definir a opção MyFamily legada, que lista a impressão digital de cada relay, até o projeto anunciar que ela deixou de ser necessária. Por isso, configure ambas. A impressão digital de cada relay está em /var/lib/tor/fingerprint.

É no segundo e no terceiro servidor que as operações começam a ser importantes, e gerir vários servidores Linux em simultâneo envolve aqui o mesmo problema que em qualquer outro contexto. Faça uma cópia de segurança de /var/lib/tor/keys fora do servidor. Se o perder, o relay regressa como um desconhecido e terá de obter novamente todas as flags e toda a reputação desde zero.

Subscreva também a lista de correio tor-relays. As alterações que afetam os operadores são anunciadas primeiro nessa lista.

DNS reverso e aviso de saída na porta 80

Configure o registo DNS reverso antes de o relay transportar tráfego. As orientações de saída do Tor recomendam que o nome indique a função do servidor, seguindo o formato de tor-exit-01.example.org. O motivo é prático. Quando um endereço desconhecido aparece nos logs de alguém, a primeira ação do administrador é fazer uma consulta reversa. Um nome que contenha "tor-exit" responde à pergunta antes de alguém lhe escrever. Assim, parte das reclamações que poderiam surgir deixa de ser feita. Peça ao fornecedor para configurar o registo PTR (pointer) e adicione um registo direto correspondente do seu lado.

Depois, disponibilize na porta 80 uma página de aviso que transmita a mesma informação por extenso. Guias antigos fazem isso com a configuração DirPortFrontPage do tor, que depende de um DirPort. O DirPort foi descontinuado para relays desde o tor 0.4.6.5. Por isso, use um servidor web pequeno.

sudo apt install -y nginx
sudo install -d -m 755 /srv/tor-exit-notice

Escreva /srv/tor-exit-notice/index.html:

<!DOCTYPE html>
<html>
<head><title>This is a Tor exit relay</title></head>
<body>
<h1>This is a Tor exit relay</h1>
<p>Traffic from this address was sent by a user of the Tor network. It did not
come from the operator of this machine, and this machine keeps no record of
who sent it.</p>
<p>Operator: Example Org. Abuse reports: abuse@example.org. Every report gets a
reply from a person.</p>
<p>To check whether this address was a Tor exit at a given date and time:
https://metrics.torproject.org/exonerator.html</p>
</body>
</html>

Escreva este bloco de servidor em /etc/nginx/sites-available/tor-exit-notice:

server {
    listen 80 default_server;
    listen [::]:80 default_server;
    server_name _;
    root /srv/tor-exit-notice;
    index index.html;
    access_log off;
}

Ative-o, remova o site predefinido do nginx e verifique o resultado:

sudo ln -sf /etc/nginx/sites-available/tor-exit-notice /etc/nginx/sites-enabled/tor-exit-notice
sudo rm -f /etc/nginx/sites-enabled/default
sudo nginx -t && sudo systemctl reload nginx
curl -s http://127.0.0.1/ | head -n 5

nginx -t reporting syntax is ok and test is successful significa que o ficheiro é válido. O curl deve mostrar as primeiras linhas do seu aviso. Se mostrar a página de boas-vindas do nginx, o site predefinido continua ativo e o seu bloco não está a ser utilizado.

Inicie-o e leia o que aparece no log

sudo systemctl restart tor@default
sudo journalctl -u tor@default -n 50 --no-pager

Dentro de alguns minutos, o log deverá conter a linha que indica que outros relays conseguem aceder ao seu:

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

Se essa linha nunca aparecer, a ORPort não está acessível. Confirme se o tor está a escutar com sudo ss -lntp | grep 443 e teste a porta a partir de outra máquina com nc -vz your.address.here 443. Uma firewall à frente do VPS, sua ou do painel de controlo do fornecedor, é a causa habitual.

Confirme que o serviço regressa após um reboot com systemctl is-enabled tor, que deverá apresentar enabled.

O relay aparece no Relay Search cerca de três horas depois de arrancar, com o nickname que escolheu. O tráfego aumenta ao longo de vários dias, porque a medição de largura de banda da rede tem de observar o seu relay antes de os clientes lhe atribuírem um peso significativo. É normal que um novo exit transporte quase nada no primeiro dia.

O manual de resposta a abusos e o conteúdo das mensagens

Escreva o manual antes da primeira reclamação, porque a primeira normalmente chega na primeira semana. A maior parte dessas mensagens é gerada automaticamente. As diretrizes de saída do Tor indicam que os relatórios automatizados representam cerca de 80% do total, e uma resposta padrão resolve a maioria dos restantes.

Veja o que realmente chega. Um relatório de varredura ou de tentativa de força bruta produzido pelo sistema de deteção de intrusões de alguém, com o seu endereço e um timestamp. Uma notificação de direitos de autor, se a sua política permitir portas de partilha de ficheiros. Uma reclamação de spam num fórum ou em comentários, enviada pelo responsável de um site. Ocasionalmente, um pedido de preservação de dados ou uma intimação de uma autoridade policial. Esta é uma categoria diferente e é o momento de falar com um advogado, em vez de usar um modelo de resposta.

A resposta é curta e é praticamente sempre igual:

Hello,

Thank you for the report. The address 203.0.113.10 is a Tor exit relay,
operated by <your name> at <your organisation>. The connection you saw was
made by a user of the Tor network. It did not originate on this machine.

This relay keeps no record of which user made which connection, so I cannot
identify the sender and there are no logs for me to hand over.

You can confirm that this address was a Tor exit at the date and time in
question here: https://metrics.torproject.org/exonerator.html

If you would prefer to stop Tor traffic reaching your service, the current
list of exit addresses is published here:
https://check.torproject.org/torbulkexitlist

I read this mailbox personally and will answer any follow-up.

<your name>

Quatro hábitos tornam este processo eficaz. Responda no prazo de um dia útil, a partir do endereço em ContactInfo, e assine com o seu próprio nome. Nunca se ofereça para identificar um utilizador, porque não pode fazê-lo. Um operador que dê a entender o contrário terá de quebrar essa promessa mais tarde. Guarde todas as respostas numa pasta, para que uma segunda mensagem sobre o mesmo incidente receba a mesma resposta. Se o fornecedor reencaminhar uma reclamação acompanhada de um aviso de suspensão, responda primeiro ao fornecedor e depois ao denunciante.

Duas ligações são especialmente importantes nessas respostas. O ExoneraTor responde à pergunta que um investigador realmente tem: este endereço era uma saída do Tor naquele momento? A lista completa de saídas é uma lista simples dos endereços de saída atuais, um por linha, para quem decidiu bloquear o Tor e prefere fazê-lo com precisão em vez de adivinhar.

Largura de banda, custo e o segundo relay

Os exits transportam tráfego real. Defina o limite mensal antes de contratar e confirme como o fornecedor cobra depois de esgotar a franquia, porque o custo real de uma VPS depende sobretudo da franquia de transferência, e não do preço anunciado. O Tor pode impor esse limite do seu lado:

AccountingMax 4 TBytes
AccountingStart month 1 00:00
RelayBandwidthRate 20 MBytes
RelayBandwidthBurst 25 MBytes

AccountingMax faz o Tor hibernar depois de transferir esse volume no período de contabilização e voltar a funcionar no início do período seguinte. Compare o primeiro mês com o contador do próprio fornecedor antes de confiar no valor, porque os dois nem sempre contabilizam os mesmos bytes. RelayBandwidthRate limita a velocidade sustentada, o que mantém o uplink utilizável e evita problemas com o fornecedor.

Quando adicionar um segundo exit, coloque-o numa rede diferente, e não no mesmo rack do primeiro. A diversidade é uma parte importante do contributo de um exit, e duas máquinas no mesmo local podem falhar em conjunto. Associe-os à mesma família, publique o mesmo contacto verificado para ambos e responda ao correio recebido pelos dois. Um exit que ninguém consegue contactar é tratado como um problema anónimo. Um exit cujo operador responde no mesmo dia é tratado como um servidor com uma pessoa responsável por trás, que é exatamente o que ele é.

FAQ

Posso executar um nó de saída Tor numa VPS que já tenho?

Não. Este é o único ponto em que deve ser rigoroso. Um nó de saída precisa de um endereço dedicado que não aloje mais nada, num fornecedor que tenha concordado previamente em transportar tráfego de saída e encaminhar-lhe as mensagens de abuso sem as alterar. Numa VPS de uso geral, incluindo a nossa, esse endereço já desempenha outra função e partilha a mesma rede com clientes que executam serviços comuns. Execute na máquina que já tem um relay que não seja de saída ou uma bridge obfs4. São realmente úteis, geram quase nenhuma reclamação e não precisam de mais nada além do servidor que já paga.

Quantas mensagens de abuso recebe um relay de saída Tor e quem as recebe?

Depende da sua política de saída. Com ReducedExitPolicy 1, a porta 25 rejeitada e as portas de partilha de ficheiros excluídas, a maior parte do que chega são relatórios de varreduras automatizadas e de tentativas de força bruta. As orientações para nós de saída do Tor indicam que os relatórios automatizados representam aproximadamente 80% do total. As mensagens são enviadas para quem o departamento de abuso do fornecedor as encaminhar. Por isso, antes de encomendar, pergunte se as encaminham para si com o endereço do autor do relatório intacto. Publique o mesmo endereço em ContactInfo e na página informativa da porta 80, e responda no prazo de um dia útil.

Tenho de publicar o meu nome verdadeiro e o endereço de email?

Sim. ContactInfo é publicado no diretório público de relays e qualquer pessoa o pode descarregar, o nome DNS inverso anuncia a função da máquina e a página informativa na porta 80 repete-o. Essa transparência faz parte do desenho do sistema, não é um efeito secundário. Um nó de saída sem um contacto funcional é tratado como uma fonte anónima de problemas, e alguns clientes excluem nós de saída que não publiquem qualquer contacto. Adicione proof:uri-familyid-ed25519 e o ficheiro /.well-known/tor-relay/ed25519-family-id.txt num domínio que controla, para que o contacto possa ser verificado e não seja apenas declarado.

Por que razão o meu novo relay de saída transporta quase nenhum tráfego?

Primeiro, confirme que journalctl -u tor@default contém Self-testing indicates your ORPort is reachable from the outside. Excellent., porque um relay que falha o teste de acessibilidade nunca é publicado e não transportará tráfego algum. Se essa linha estiver presente, a explicação normalmente é o tempo. Um relay aparece no Relay Search cerca de três horas depois do arranque, e os clientes só lhe enviam tráfego significativo depois de a medição de largura de banda da rede o observar, o que demora dias. Também é necessária uma política que permita as portas 80 e 443 antes de o relay ser tratado como nó de saída.