Como configurar uma bridge Tor com obfs4 em um VPS

O que é uma bridge Tor e por que ela existe

Uma bridge Tor é um ponto de entrada na rede Tor cujo endereço não é publicado na lista pública de relays. Essa lista, chamada de consensus, é um documento assinado que qualquer pessoa pode baixar, e um censor também pode baixá-lo. Bloquear o Tor a partir dela leva uma tarde: basta obter o consensus e bloquear todos os endereços nele contidos na fronteira da rede. As bridges existem porque a lista publicada é o ponto fraco. Os endereços das bridges são distribuídos aos poucos, para que nenhuma solicitação individual receba o conjunto completo.

Um endereço não listado é apenas metade da solução. A inspeção profunda de pacotes (DPI), que classifica o tráfego pelo conteúdo em vez do endereço, reconhece uma conexão Tor pelo formato do handshake TLS (transport layer security). Um censor sem a lista ainda pode identificar que "isto parece Tor" e bloquear a conexão. Um transporte plugável remove esse sinal. No lado do cliente, ele envolve o fluxo Tor em outro protocolo, e a sua bridge remove esse encapsulamento.

obfs4 é o transporte usado pela maioria das bridges. Ele transforma o fluxo em bytes sem cabeçalho e sem handshake fixo, portanto a DPI não encontra um padrão para identificar. Ele também autentica o cliente. O valor cert= dentro de uma linha de bridge é uma chave que o cliente precisa provar que possui antes que a bridge responda, o que impede sondagens ativas: um censor que se conecta ao seu endereço para verificar se ele fala Tor não recebe resposta e não descobre nada.

Que transporte conectável deve executar?

• obfs4 precisa de 1 VPS, 2 portas TCP e não precisa de um nome de domínio. É a opção útil mais simples que pode executar e é o tema deste guia.
• WebTunnel oculta a ligação dentro de tráfego HTTPS normal dirigido a um site real. O Tor Project indica como requisitos um endereço IPv4 estático, um domínio sob o seu controlo, um servidor web funcional, como NGINX ou Apache, um certificado TLS válido e pelo menos 1 GB de RAM, sendo recomendados 4 GB. É adequado para redes onde o tráfego com aspeto aleatório é suspeito por si só, porque um país que permite pouco além da navegação web continua a permitir HTTPS.
• Snowflake é um tipo diferente de contribuição. Os voluntários executam proxies WebRTC de curta duração, por isso os pontos de entrada mudam constantemente e não existe um endereço estável que um censor possa bloquear. Não opera uma bridge para este transporte. Executa um proxy, que não precisa de um endereço fixo.

Comece com obfs4. Pode adicionar mais tarde uma bridge WebTunnel num segundo endereço: executar ambos no mesmo IP significa que o bloqueio de um único endereço interrompe os dois.

Qual é o custo de executar uma bridge?

[
  {
    "label": "Bridge, minimum",
    "min_upstream_mbit": 1
  },
  {
    "label": "Guard or middle relay, minimum",
    "min_upstream_mbit": 10
  },
  {
    "label": "Guard or middle relay, recommended",
    "min_upstream_mbit": 16
  }
]

Em agosto de 2026, o Tor Project exige que uma bridge tenha pelo menos 1 Mbit/s de largura de banda de upstream e downstream. Para um relay guard ou middle, são exigidos 10 Mbit/s, com 16 Mbit/s recomendados. Estes são requisitos publicados, não medições. Uma bridge nova normalmente fica muito abaixo do seu próprio mínimo durante semanas. A mesma página de requisitos pede que um relay tenha pelo menos 100 GByte de tráfego de saída por mês, valor que os planos mais pequenos já cobrem. Por isso, leia quanto custa realmente uma VPS pequena por mês antes de escolher um plano maior.

A superfície de abuso é pequena, e é aqui que muitas pessoas se enganam. Uma bridge é o primeiro salto. O tráfego que sai do seu servidor vai para outro relay Tor, nunca para um site escolhido por um utilizador. O seu endereço IP nunca aparece no log web de outra pessoa como origem de um pedido. Por isso, os emails de reclamação tratados pelos operadores de exit relay não chegam aqui. Consulte ainda a política de utilização aceitável do seu fornecedor, porque alguns hosts tratam qualquer serviço Tor como um caso especial.

Há uma coisa que não deve fazer: converter um relay público existente numa bridge no mesmo endereço. O Tor Project recomenda, nesse caso, alterar o "IP address, name and fingerprint", porque o endereço antigo já está no consensus que os censores descarregam. Uma bridge que era um relay público na semana passada já está numa blocklist.

A disponibilidade é mais importante do que a velocidade. Os requisitos dos relays dizem que "if your relay is not running for more than 2 hours a day its usefulness is limited". Neste aspeto, uma bridge fica em pior situação do que um relay, porque cada cliente tem um único endereço e não dispõe de fallback. Um restart desliga todos os utilizadores ligados a ela. Configure uma verificação de porta TCP no Uptime Kuma para a porta obfs4, para saber no próprio dia quando ela deixar de responder.

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

Os pacotes da distribuição ficam desatualizados, e uma bridge é software de segurança que deve estar atual. Adicione primeiro o repositório do próprio projeto.

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

Agora crie o ficheiro de origem. A linha Suites: deve conter o codename da sua release, por isso leia-o do sistema em vez de o escrever de memória.

sudo tee /etc/apt/sources.list.d/tor.sources >/dev/null <<EOF
Types: deb deb-src
URIs: https://deb.torproject.org/torproject.org/
Suites: $(lsb_release -cs)
Components: main
Signed-By: /usr/share/keyrings/deb.torproject.org-keyring.gpg
EOF
sudo apt update
sudo apt install -y tor deb.torproject.org-keyring obfs4proxy

Se apt update indicar que o repositório não tem um ficheiro Release para o seu codename, o Tor Project não disponibiliza essa release. Remova /etc/apt/sources.list.d/tor.sources, execute sudo apt update novamente e instale o pacote tor fornecido pela sua distribuição. Tudo o que vem abaixo permanece igual.

O pacote obfs4proxy vem do próprio Debian e Ubuntu (versão 0.0.14 no Debian 13, em agosto de 2026). Confirme onde o binário foi instalado, porque o respetivo caminho será usado na configuração:

command -v obfs4proxy || command -v lyrebird

A montante, o projeto mudou o nome para lyrebird, por isso um pacote mais recente pode instalar /usr/bin/lyrebird. Use o caminho apresentado por esse comando.

Configurar a bridge em /etc/tor/torrc

BridgeRelay 1
ORPort 8443
ServerTransportPlugin obfs4 exec /usr/bin/obfs4proxy
ServerTransportListenAddr obfs4 0.0.0.0:9443
ExtORPort auto
ContactInfo you@example.com
Nickname PickANickname
BridgeDistribution any

Cada uma destas linhas está associada a uma falha possível, por isso analise-as uma de cada vez.

BridgeRelay 1 faz o tor enviar o seu descritor para a autoridade de bridges, em vez de o enviar para o consenso público. Esta única linha faz com que o relay não seja listado.

ORPort é a porta real do Tor. Tem de estar acessível a partir da Internet, porque o tor testa-a e recusa publicar um descritor enquanto esse teste não passar.

ServerTransportPlugin indica ao tor o comando a executar. O tor inicia o obfs4proxy como processo filho e comunica com ele através de um pipe. Por isso, o obfs4proxy não tem uma unidade de serviço própria e nunca aparece em systemctl status.

ServerTransportListenAddr fixa a porta onde o obfs4proxy fica à escuta. Se omitir esta linha, o obfs4proxy escolhe uma porta livre no arranque e uma porta diferente depois da maioria dos reinícios. Assim, cada linha da bridge que já distribuiu aponta para uma porta onde não está nada à escuta. Esses clientes recebem uma ligação recusada e deixam de tentar.

ExtORPort auto abre a ORPort estendida, um canal de loopback que o obfs4proxy usa para devolver ao tor as ligações concluídas juntamente com o endereço do cliente. O guia de configuração do Tor Project inclui-a em todas as bridges, porque, sem ela, o transporte não consegue comunicar esse endereço ao tor.

ContactInfo e Nickname são ambos públicos. Use um endereço que consulte, porque é através dele que o Tor Project o contacta sobre uma bridge avariada. Escolha um nickname que não o identifique se preferir não chamar a atenção.

BridgeDistribution escolhe qual distribuidor fornece o seu endereço aos utilizadores. Os valores aceites são https, email, telegram, settings, none e any. Use any para uma primeira bridge e deixe o sistema decidir. Use none para uma bridge privada que distribui diretamente, mantendo o endereço totalmente fora da distribuição pública.

Por que a escolha da porta é importante

Evite usar 9001 para ambas as portas. O Tor Project afirma isso diretamente, porque 9001 é a ORPort tradicional e os censores fazem varreduras à sua procura na Internet. As duas portas também têm de ser diferentes, porque tor e obfs4proxy fazem o bind dos seus próprios listeners.

A porta obfs4 mais forte é 443. As ligações de saída para 443 estão abertas em quase todas as redes restritas, e uma ligação de longa duração para essa porta parece uma sessão Web normal. Fazer o bind numa porta inferior a 1024 requer uma etapa adicional, porque obfs4proxy não é executado como root:

sudo setcap cap_net_bind_service=+ep /usr/bin/obfs4proxy
sudo systemctl edit tor@.service tor@default.service

Adicione estas duas linhas em cada editor que for aberto:

[Service]
NoNewPrivileges=no

A capability, por si só, não é suficiente. O NoNewPrivileges do systemd impede que um processo obtenha privilégios que o processo pai não tinha, e uma capability de ficheiro é exatamente isso. Por esse motivo, obfs4proxy não consegue fazer o bind da porta 443 enquanto essa definição estiver ativa.

Se preferir ignorar essa etapa, escolha uma porta alta pouco evidente e anote-a. Independentemente da escolha, não altere a porta obfs4 mais tarde. Uma linha de bridge associa o endereço, a porta, a fingerprint e o certificado. Por isso, todas as cópias que já estejam no browser de um utilizador deixam de funcionar assim que a porta muda.

Abra as portas nas duas firewalls

sudo ufw allow 8443/tcp
sudo ufw allow 9443/tcp
sudo ufw status

As duas portas precisam de estar abertas, e a maioria dos fornecedores mantém uma segunda firewall no painel de controlo, que o ufw desconhece. Uma regra que existe no servidor, mas não no painel, cria uma bridge que nunca fica acessível e nunca publica um descritor. Se alguma destas partes for nova para si, as regras do ufw necessárias num VPS novo e o que significa efetivamente uma porta em escuta no Linux explicam o assunto. Enquanto estiver a configurar isso, proteja o SSH com chaves e uma configuração reforçada do sshd. Uma bridge não listada num servidor com SSH por palavra-passe continua a ser um servidor com SSH por palavra-passe.

Inicie o serviço e leia o log

sudo systemctl enable --now tor.service
sudo systemctl restart tor.service
sudo journalctl -e -u tor@default

Debian e Ubuntu disponibilizam duas unidades. tor.service é um wrapper pequeno e tor@default.service é o processo que executa o trabalho. Por isso, journalctl -u tor parece quase vazio, enquanto o log pretendido está em tor@default.

Duas linhas indicam que funcionou:

Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor.
Registered server transport 'obfs4' at '0.0.0.0:9443'

A primeira significa que o teste de acessibilidade foi concluído com sucesso e que o descritor foi enviado para a autoridade da bridge. Se nunca aparecer, algo entre a Internet e o seu servidor está a descartar tráfego destinado à ORPort. A segunda linha tem de mostrar a porta que configurou. Uma porta diferente nessa linha significa que o tor não aplicou ServerTransportListenAddr. A causa habitual é um nome de transporte inconsistente: tem de apresentar obfs4 em ambas as diretivas.

Confirme que os dois listeners existem:

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

Onde está a minha bridge line?

obfs4proxy escreve um modelo no diretório de dados do tor:

sudo cat /var/lib/tor/pt_state/obfs4_bridgeline.txt

Esse diretório pertence ao utilizador tor e tem o modo 700. Sem sudo, obtém Permission denied. O ficheiro contém uma linha neste formato:

Bridge obfs4 <IP ADDRESS>:<PORT> <FINGERPRINT> cert=<CERTIFICATE> iat-mode=0

Substitua <IP ADDRESS> pelo endereço público do servidor, <PORT> pela porta do obfs4, e não pela ORPort, e <FINGERPRINT> pelo fingerprint da identidade que o tor gravou no diretório de dados:

sudo cat /var/lib/tor/fingerprint
sudo cat /var/lib/tor/hashed-fingerprint

O primeiro ficheiro contém o nickname e o fingerprint da identidade que devem constar numa bridge line. O segundo contém o fingerprint com hash. É esse valor que deve colar no Relay Search para verificar se a bridge está em execução e obter uma estimativa do número de clientes que a alcançam. Os dois valores não são intercambiáveis. Uma bridge line que contenha o valor com hash não corresponde à chave de identidade apresentada pela bridge, por isso o cliente rejeita a ligação que acabou de abrir.

Como uma bridge chega efetivamente aos utilizadores?

Não deve enviar a linha da bridge a ninguém. Depois de o descritor chegar à autoridade de bridges, o sistema de distribuição (rdsys, o sucessor do BridgeDB) atribui a sua bridge a um distribuidor, e os utilizadores pedem bridges a esse distribuidor. Em agosto de 2026, existem estas opções:

• O formulário Web em bridges.torproject.org/options, que fornece linhas de bridge depois de um captcha.
• Enviar um email para bridges@torproject.org a partir de um endereço Gmail ou Riseup. O serviço responde com linhas de bridge. A restrição de fornecedores existe porque contas gratuitas ilimitadas permitiriam que um censor enumerasse todas as bridges.
• O bot do Telegram @GetBridgesBot. Envie /start e, depois, /obfs4 ou /webtunnel.
• O próprio Tor Browser, em Settings e depois Connection, onde "Request bridges" as obtém através do canal moat.

Uma bridge nova aparece no Relay Search cerca de três horas depois da configuração. Os utilizadores demoram muito mais tempo: a formulação do próprio Tor Project é que "Pode demorar vários dias ou semanas até ver um conjunto consistente de utilizadores." É normal não haver atividade durante as primeiras duas semanas. Isso não indica uma falha.

Definir BridgeDistribution none exclui a bridge de todos estes mecanismos. Nesse caso, a linha da bridge fica sob o seu controlo para ser enviada às pessoas que precisam dela, através de um canal que o censor não esteja a monitorizar.

Quando algo não funciona

Não existe uma linha de autoteste no log. A ORPort não está acessível. Teste-a a partir de outra máquina com nc -vz your.ip 8443. Se a ligação ficar pendurada, os pacotes estão a ser descartados. Verifique o ufw e o painel do fornecedor. Uma recusa significa que o tor não está a escutar. Verifique ss -lntp e procure um erro de configuração no log.

O transporte registado mostra uma porta que não escolheu. O tor ignorou ServerTransportListenAddr. O nome do transporte tem de corresponder exatamente ao definido em ServerTransportPlugin, e ambos têm de estar em obfs4.

O obfs4proxy não consegue associar-se à porta 443. Confirme a capacidade com getcap /usr/bin/obfs4proxy. Depois confirme que a substituição chegou à unidade com systemctl show tor@default -p NoNewPrivileges. Se esse comando mostrar NoNewPrivileges=yes, o drop-in foi aplicado a uma unidade que não está em execução.

Não há nada dentro de /var/lib/tor/pt_state/. O tor nunca iniciou o transporte, o que significa que o caminho em ServerTransportPlugin está incorreto. Compare-o com o resultado de command -v obfs4proxy.

Os clientes deixaram de estabelecer ligação depois de uma alteração. Qualquer alteração ao endereço ou à porta obfs4 invalida todas as linhas de bridge já distribuídas. Verifique também se o IP público do servidor mudou. Isto acontece durante uma reconstrução com alguns fornecedores.

O tor não arranca de todo. Execute sudo -u debian-tor tor --verify-config -f /etc/tor/torrc. O comando analisa o ficheiro, mostra a linha que causou o erro e deixa o serviço em execução inalterado.

FAQ

O meu fornecedor de VPS vai reclamar de uma bridge Tor?

Uma bridge é um ponto de entrada. Por isso, o tráfego que sai do seu servidor segue para outros relays Tor e nunca para um site escolhido por um utilizador. O seu endereço IP não aparece nos logs web de ninguém como origem de um pedido. É isso que gera as reclamações recebidas pelos operadores de relays de saída. As regras de alojamento continuam a variar. Alguns fornecedores tratam qualquer serviço Tor como um caso especial. Leia a política de utilização aceitável antes de começar e coloque um endereço que tenha consultado em ContactInfo.

Quanta largura de banda uma bridge Tor utiliza?

O mínimo publicado é de 1 Mbit/s de entrada e de saída. Para um relay guard ou middle, o valor é de 10 Mbit/s. O uso real começa perto de zero, porque a sua bridge só transporta tráfego dos utilizadores que um distribuidor lhe encaminha. Se quiser definir um limite máximo rígido, configure RelayBandwidthRate e RelayBandwidthBurst em torrc.

Por que ninguém se ligou à minha bridge nova?

Uma bridge demora cerca de três horas a aparecer no Relay Search. As orientações do Tor Project indicam que um conjunto consistente de utilizadores demora vários dias ou semanas a formar-se. Verifique se o descritor foi publicado. Essa é a linha de autoteste em journalctl -u tor@default. Procure a sua fingerprint com hash no Relay Search e confirme que BridgeDistribution não está definido como none.

Devo executar obfs4 ou WebTunnel?

Execute obfs4 se esta for a sua primeira bridge: uma VPS, duas portas, sem domínio e sem certificado. Use WebTunnel quando o tráfego com aparência aleatória também estiver bloqueado. Nesse caso, precisa de um domínio sob o seu controlo, um servidor web real, um certificado TLS válido e pelo menos 1 GB de RAM. Coloque-os em endereços separados se executar ambos. Caso contrário, um único endereço IP bloqueado removeria duas bridges de uma vez.

O que acontece se eu alterar a porta obfs4 mais tarde?

Todas as bridge lines já distribuídas deixam de funcionar. Uma bridge line associa o endereço, a porta, a fingerprint e o certificado. Por isso, um cliente que tenha a linha antiga tenta ligar-se a uma porta onde nada está a escutar e desiste. O mesmo acontece quando o IP público do servidor muda. Escolha a porta durante a configuração e não a altere.