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 consenso, é um documento assinado que qualquer pessoa pode descarregar, e um censor também pode descarregá-lo. Bloquear o Tor a partir dessa lista demora uma tarde: descarregue o consenso e bloqueie 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 em pequenas quantidades, para que nenhuma solicitação individual revele todo o conjunto.

Um endereço não listado é apenas metade da solução. A inspeção profunda de pacotes (DPI), que classifica o tráfego pelo seu conteúdo em vez do endereço, reconhece uma ligação Tor pelo formato do seu handshake TLS (transport layer security). Um censor sem a lista ainda pode ver que "isto parece Tor" e bloquear a ligação. Um transporte plugável remove esse sinal. Ele encapsula o fluxo Tor em outra coisa no lado do cliente, e a sua bridge o desencapsula.

obfs4 é o transporte executado pela maioria das bridges. Ele transforma o fluxo em bytes sem cabeçalho e sem handshake fixo, para que a DPI não tenha nenhum 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 a sondagem ativa: um censor que se liga ao seu endereço para testar se ele fala Tor não recebe resposta e não aprende nada.

Que transporte plugável deve executar?

• obfs4 precisa de um VPS, duas portas TCP e nenhum 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 lista como requisitos um endereço IPv4 estático, um domínio sob seu controlo, um servidor web funcional como NGINX ou Apache, um certificado TLS válido e pelo menos 1 GB de RAM, com 4 GB recomendados. É adequado para redes onde o tráfego com padrões aleatórios é suspeito por si só, porque um país que permite pouco além de navegação web continua a permitir HTTPS.
• Snowflake é uma contribuição diferente. 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 uma bridge WebTunnel mais tarde, num segundo endereço: executar ambos no mesmo IP significa que um único endereço bloqueado deixa os dois indisponíveis.

Qual é o custo de operar 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, o requisito é de 10 Mbit/s, com 16 Mbit/s recomendado. 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 transfira pelo menos 100 GByte de tráfego de saída por mês, um volume que os planos mais pequenos já suportam. Por isso, consulte o custo mensal real de uma VPS pequena antes de escolher uma configuração 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 pelo utilizador. O seu endereço IP nunca aparece no log web de um desconhecido como origem de um pedido. Por isso, as mensagens de abuso que os operadores de relays de saída tratam não chegam aqui. Consulte ainda a política de utilização aceitável do seu provedor, porque alguns hosts tratam qualquer serviço Tor como um caso especial. Uma bridge e um serviço onion são imagens espelhadas neste aspeto: uma bridge só é útil porque o seu endereço pode ser alcançado e acaba por ser distribuído, enquanto um serviço onion v3 na mesma categoria de VPS só é útil enquanto o seu IP público permanecer oculto.

Não faça o seguinte: converta um relay público existente numa bridge no mesmo endereço. Para esse caso, o Tor Project recomenda alterar o "endereço IP, nome e fingerprint", porque o endereço antigo já está no consenso que os censores descarregam. Uma bridge que era um relay público na semana passada já está numa lista de bloqueio.

A disponibilidade é mais importante do que a velocidade. Os requisitos dos relays dizem que "se o seu relay não estiver em execução durante mais de 2 horas por dia, a sua utilidade será limitada". 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 reinício desliga todos os utilizadores ligados a ela. Configure uma verificação da porta TCP no Uptime Kuma para a porta obfs4, para saber no próprio dia em que ela deixa 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 atualizado. Adicione primeiro o repositório próprio do 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. Elimine /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 diretamente do Debian e do Ubuntu (versão 0.0.14 no Debian 13, em agosto de 2026). Confirme onde o binário foi instalado, porque esse caminho será usado na configuração:

command -v obfs4proxy || command -v lyrebird

O projeto upstream 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 específica, por isso analise-as uma de cada vez.

BridgeRelay 1 indica ao tor que envie 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-se a publicar um descritor enquanto esse teste não passar.

ServerTransportPlugin fornece 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 em que o obfs4proxy escuta. Se omitir esta linha, o obfs4proxy escolhe uma porta livre durante o arranque e, depois da maioria dos reinícios, escolhe outra porta. Assim, cada linha de bridge que já distribuiu aponta para uma porta onde nenhum processo está a escutar. Esses clientes recebem uma ligação recusada e deixam de tentar.

ExtORPort auto abre a ORPort estendida, um canal de loopback que o obfs4proxy utiliza 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 esta opção 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. Utilize um endereço que consulte, pois é através dele que o Tor Project contacta consigo sobre uma bridge com problemas. Escolha um nickname que não o identifique, se preferir manter o anonimato.

BridgeDistribution escolhe o distribuidor que fornece o seu endereço aos utilizadores. Os valores aceites são https, email, telegram, settings, none e any. Utilize any para uma primeira bridge e deixe o sistema decidir. Utilize none para uma bridge privada que distribua 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 devem ser diferentes, porque tor e obfs4proxy fazem cada um o bind do seu próprio listener.

A porta obfs4 mais eficaz é 443. As ligações de saída para 443 estão abertas em quase todas as redes restritas, e uma ligação mantida durante muito tempo parece uma sessão web normal. Fazer o bind numa porta inferior a 1024 exige um passo 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 abrir:

[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 de 443 enquanto essa definição estiver ativa.

Se preferir ignorar esse passo, escolha uma porta alta pouco chamativa e registe-a. Seja qual for a sua escolha, não altere a porta obfs4 posteriormente. Uma linha de bridge associa o endereço, a porta, a impressão digital 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 em ambas as firewalls

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

Ambas as portas precisam de estar abertas, e a maioria dos fornecedores executa uma segunda firewall no painel de controlo, que o ufw desconhece. Uma regra existente 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 é realmente uma porta em escuta no Linux explicam o assunto. Enquanto estiver nessa tarefa, 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 e consulte o log

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

Debian e Ubuntu fornecem duas unidades. tor.service é um pequeno wrapper e tor@default.service é o processo que executa o trabalho. Por isso, journalctl -u tor parece quase vazio, enquanto o log que procura 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 aprovado 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 o tráfego para a ORPort. A segunda linha tem de mostrar a porta configurada. Uma porta diferente indica que o tor nunca aplicou ServerTransportListenAddr. A causa habitual é um nome de transporte incompatível: tem de ser obfs4 em ambas as diretivas.

Confirme que os dois listeners existem:

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

Onde está a minha linha de bridge?

O obfs4proxy grava 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 seu servidor, <PORT> pela porta do obfs4, e não pela ORPort, e <FINGERPRINT> pela impressão digital de 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 seu nickname e a impressão digital de identidade que devem aparecer numa linha de bridge. O segundo contém a impressão digital com hash. É esse valor que deve colar no Relay Search para verificar se a sua bridge está em execução e ter uma estimativa de quantos clientes chegam até ela. Os dois valores não são intercambiáveis. Uma linha de bridge que contenha o valor com hash não corresponde à chave de identidade apresentada pela sua bridge. Por isso, o cliente rejeita a ligação que acabou de abrir.

Como um bridge chega efetivamente aos utilizadores?

Não entregue a linha do seu bridge a qualquer pessoa. Quando o descritor chega à autoridade de bridges, o sistema de distribuição (rdsys, sucessor do BridgeDB) atribui o seu 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 bridges depois de um captcha.
• O envio de uma mensagem para bridges@torproject.org a partir de um endereço Gmail ou Riseup, que responde com linhas de bridges. A restrição do fornecedor existe porque contas gratuitas ilimitadas permitiriam que um censor enumerasse todos os bridges.
• O bot do Telegram @GetBridgesBot. Envie /start e, em seguida, /obfs4 ou /webtunnel.
• O próprio Tor Browser, em Settings e depois Connection, onde "Request bridges" os obtém através do canal moat.

Um bridge novo 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 "It can take several days or weeks until you see a consistent set of users." É normal não haver atividade significativa nas primeiras duas semanas. Isso não indica uma falha.

Definir BridgeDistribution none desativa todas estas opções. Nesse caso, a linha do bridge fica disponível para ser enviada às pessoas que precisam dela, através de um canal que o censor não está a monitorizar.

Quando algo não funciona

Nenhuma 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 bloqueada, os pacotes estão a ser descartados; verifique o ufw e o painel do fornecedor. Se houver recusa, 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 nome em ServerTransportPlugin, e ambos têm de estar definidos como obfs4.

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

Nada dentro de /var/lib/tor/pt_state/. O tor nunca iniciou o transporte, o que significa que o caminho em ServerTransportPlugin está errado. Compare-o com a saída de command -v obfs4proxy.

Os clientes deixaram de se ligar 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 endereço IP público do servidor mudou, algo que pode acontecer durante uma recriação com alguns fornecedores.

O tor não inicia 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, que é o que gera as reclamações recebidas pelos operadores de relays de saída. As regras de alojamento continuam a variar e 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 introduza um endereço que tenha lido em ContactInfo.

Quanta largura de banda usa uma bridge Tor?

O mínimo publicado é de 1 Mbit/s de entrada e saída, contra 10 Mbit/s para um relay guard ou middle. O consumo 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 no torrc.

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

Uma bridge demora cerca de três horas a aparecer no Relay Search, e as orientações do Tor Project indicam que um conjunto consistente de utilizadores demora vários dias ou semanas a formar-se. Confirme que o descritor foi publicado, o que corresponde à linha de autoteste em journalctl -u tor@default, procure o 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. Execute WebTunnel quando o tráfego com aspeto aleatório também estiver bloqueado, pois precisa de um domínio sob o seu controlo, de um servidor web real, de um certificado TLS válido e de pelo menos 1 GB de RAM. Coloque-os em endereços separados se executar ambos, porque um único IP bloqueado removeria duas bridges de uma só vez.

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

Todas as linhas de bridge já distribuídas deixam de funcionar. Uma linha de bridge associa o endereço, a porta, o 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 se aplica quando o IP público do servidor muda. Escolha a porta durante a configuração e não a altere.