Nós e infraestrutura

Como resolver problemas de conexão em um nó de Bitcoin

10 de dezembro de 2024 · 19 min de leitura · Atualizado em
Uma mão alinha um conector Ethernet à porta de rede de um nó doméstico durante uma verificação cuidadosa da conexão.

Este guia é uma tradução do original em inglês, que é o texto de referência. Ler em inglês

Conexões estáveis e confiáveis entre nós são um dos pilares da arquitetura do Bitcoin. Elas são essenciais para manter a rede descentralizada e garantir a validade das transações. Aqui, examinamos as implicações técnicas da conectividade dos nós, a importância dela para quem participa da rede e o avanço rumo à operação de nós próprios (em inglês) no ecossistema do Bitcoin.

A arquitetura ponto a ponto do Bitcoin se apoia em um sistema robusto de nós interligados que mantêm e verificam a blockchain em conjunto. Quando você usa uma carteira para interagir com a rede, essas conexões são a ponte para o restante do ecossistema do Bitcoin. A estabilidade pode variar bastante conforme fatores como a localização, a qualidade do serviço de internet e os nós específicos aos quais você se conecta.

Os nós públicos prestam um serviço valioso à comunidade do Bitcoin, embora tenham limitações e possíveis desvantagens. Podem sofrer interrupções periódicas, ter largura de banda limitada ou apresentar conexões instáveis quando a demanda for alta. Se você depender da infraestrutura pública para operar com Bitcoin, é importante entender essas limitações, porque desconexões intermitentes podem afetar a transmissão e a verificação de transações.

A dificuldade de manter conexões estáveis entre nós levou a várias soluções no ecossistema do Bitcoin. Quem desenvolve carteiras implementou funções como a reconexão automática e a possibilidade de se conectar a vários nós ao mesmo tempo. Essa redundância aumenta a confiabilidade. Essas adaptações reduzem o impacto das desconexões temporárias para quem usa a carteira e mantêm os padrões de segurança.

Operar seu próprio nó de Bitcoin é um passo importante para ganhar soberania e participar da rede. Entre as vantagens estão mais privacidade (em inglês), uma verificação de transações mais confiável e uma contribuição direta para a descentralização. Os requisitos técnicos para operar um nó estão cada vez mais acessíveis. Surgiram várias soluções prontas para uso que simplificam o processo para quem não tem conhecimentos técnicos.

As conexões de um nó servem para mais do que transmitir transações. Os nós fazem cumprir as regras de consenso da rede, validam transações e propagam blocos. Conexões estáveis permitem que cumpram essas funções e contribuem para o bom funcionamento e a segurança da rede Bitcoin. Se as conexões ficarem instáveis, o nó pode ter dificuldade para continuar sincronizado com o estado atual da blockchain.

A infraestrutura de nós avançou bastante nos últimos anos. As melhorias se concentraram em tornar as conexões mais confiáveis, reduzir os requisitos de hardware e simplificar a operação de um nó (em inglês) para usuários comuns. Agora ficou mais prático participar diretamente da validação e da verificação da rede.

As carteiras de Bitcoin atuais têm funções avançadas para gerenciar as conexões. Podem selecionar servidores automaticamente, monitorar a qualidade da conexão e recorrer a alternativas quando as conexões principais falham. Essas funções ajudam a manter a experiência fluida e preservam os benefícios de segurança e privacidade de uma boa conexão com um nó.

À medida que o Bitcoin ampliar sua capacidade, desenvolver a infraestrutura de nós e os sistemas que gerenciam suas conexões terá um papel fundamental. Conforme a rede crescer e a adoção aumentar, manter conexões confiáveis entre nós ficará cada vez mais importante. É provável que as melhorias se concentrem em aumentar a estabilidade, reduzir os recursos necessários e melhorar a experiência tanto de quem usa nós públicos quanto de quem opera um nó próprio.

A relação entre as carteiras e as conexões dos nós é um ponto de encontro importante entre facilidade de uso e segurança. À medida que a tecnologia amadurecer, podemos esperar novos avanços no gerenciamento de conexões, na operação de nós e na confiabilidade da rede. Isso contribui para que o Bitcoin se torne mais robusto e acessível e mantenha os princípios de descentralização e soberania dos usuários que definem o sistema.

Guia passo a passo

Diagnosticar e resolver problemas de conexão em um nó de Bitcoin exige um método. Estes passos ajudam a isolar e corrigir os problemas mais comuns, seja para operar um nó completo próprio, conectar uma carteira a um servidor Electrum público ou investigar falhas nas conexões de um nó da Lightning com outros nós.

Um roteiro de diagnóstico com três verificações. 1. Conexões de saída, no campo connections_out de getnetworkinfo. Se mostrar 0, nenhuma conexão sai. Confira primeiro a conexão com a internet, depois o Tor se o bitcoin.conf tiver uma linha proxy=, em seguida os ajustes do bitcoin.conf no passo 5 e, por último, o provedor de internet, testando o modo só Tor. Cerca de 10 conexões indicam que tudo vai bem. 2. Conexões de entrada, connections_in. Um 0 costuma ser normal. Um nó em sincronização só anuncia o endereço depois que terminar. Se a porta 8333 estiver fechada, outros nós não conseguem entrar. Para aceitá-los, abra a porta no roteador e no firewall. Em qualquer caso, siga em frente. 3. Se a carteira ainda mostrar “not connected” (sem conexão), a falha está entre a carteira e o nó. Confira o servidor Electrum e os ajustes de servidor e do Tor na carteira. Se a mensagem não aparecer, está tudo conectado.
Dois números e uma pergunta indicam onde está a falha. Zero conexões de saída indica uma falha. Zero conexões de entrada costuma ser normal. Se a carteira não se conectar e o nó tiver pares, o problema está do lado da carteira.

Passo 1: verifique a sincronização do nó. Antes de procurar uma falha de conexão, confira se o nó está totalmente sincronizado com a blockchain. Execute bitcoin-cli getblockchaininfo e compare o número em “blocks” com a altura atual em um explorador de blocos. Se o nó ainda estiver sincronizando (o campo initialblockdownload mostra true), espere poucas conexões de entrada ou nenhuma. O Bitcoin Core só anuncia o próprio endereço a outros nós quando a sincronização termina. As conexões de saída devem funcionar durante o processo, por isso um nó sem nenhum par ainda tem um problema a resolver.

Passo 2: confira as conexões com outros nós. Execute bitcoin-cli getpeerinfo para listar todos os nós conectados. Um nó que funciona bem mantém 10 conexões de saída por padrão: 8 retransmitem transações e blocos, e 2 só retransmitem blocos (o campo connection_type distingue as duas). Se a lista estiver vazia ou mostrar apenas 1 ou 2 nós, é provável que o seu esteja com dificuldade para alcançar a rede. Veja no campo “addr” se os endereços dos nós são IPv4, IPv6 ou Tor (.onion). Assim, você pode identificar se o problema é de um protocolo específico.

Passo 3: teste a conexão básica com a rede. Confira se o dispositivo tem acesso à internet. Envie um ping para um servidor conhecido ou carregue uma página da web. Se você usar o Tor, verifique se o serviço está ativo e se a configuração no arquivo torrc aponta para a porta correta do proxy SOCKS (9050 por padrão). Teste a conexão pelo Tor com curl --socks5-hostname 127.0.0.1:9050 https://check.torproject.org/api/ip. O resultado deve incluir "IsTor":true.

Passo 4: confira o firewall e o redirecionamento de portas. O Bitcoin Core usa a porta 8333 para conexões P2P da rede principal. Se você quiser aceitar conexões de entrada, que melhoram a saúde da rede e aumentam sua contagem de conexões, o roteador precisa redirecionar a porta 8333 e o firewall local precisa permitir o tráfego nela. Desde a versão 30.0, o Bitcoin Core também pede ao roteador para abrir a porta usando PCP ou NAT-PMP. Isso só funciona se o roteador oferecer suporte a um desses protocolos. Se a configuração usar só conexões de saída, o redirecionamento é dispensável, mas o firewall precisa permitir conexões TCP de saída. Confira com sudo ufw status ou sudo iptables -L.

Seu nó à esquerda, depois duas barreiras, o firewall do nó e o roteador, e outros nós à direita. Conexões de saída. Seu nó se conecta a cerca de 10 nós passando pelas duas barreiras sem precisar abrir nada. Conexões de entrada, três casos. Se o roteador não redirecionar a porta 8333, os outros nós param no roteador. Se o roteador redirecionar a porta, mas o firewall a bloquear, os outros nós param no firewall. Se as duas barreiras estiverem abertas, os outros nós se conectam ao seu, até 189 ao mesmo tempo no Bitcoin Core 32.1. Para aceitar conexões de entrada, redirecione a porta TCP 8333 para o nó no roteador. O Bitcoin Core também pede ao roteador para fazer isso via PCP ou NAT-PMP, o que só funciona se o roteador oferecer suporte. Permita também as conexões TCP de entrada na porta 8333 do firewall.
As conexões de saída dispensam abrir as barreiras. As de entrada precisam que as duas estejam abertas. Por isso um nó atrás de um roteador fechado fica com cerca de 10 conexões. Ele continua sendo um nó completo, plenamente capaz de verificar cada bloco.

Passo 5: procure problemas de configuração no bitcoin.conf. Entre as causas comuns estão maxconnections=0, que desativa todas as conexões automáticas de entrada e saída (só os nós adicionados com addnode ainda conseguem se conectar), uma configuração incorreta de proxy= que aponta para uma instância do Tor que não está rodando, linhas connect= que restringem seu nó a nós específicos que podem estar offline, e listen=0, que impede conexões de entrada. Confira o arquivo linha por linha e comente qualquer configuração de que você não precise explicitamente.

Quatro linhas do bitcoin.conf e seus efeitos. maxconnections=0: sem conexões de saída, exceto para nós adicionados com addnode, e sem conexões de entrada. proxy=127.0.0.1:9050 com o Tor parado: todas as conexões de saída falham porque passam pelo Tor, e as de entrada ficam desativadas, a menos que você adicione listen=1. connect=203.0.113.5 com esse nó offline: não há conexões de saída porque seu nó só tenta se conectar àquele par, e as de entrada ficam desativadas, a menos que você adicione listen=1. listen=0: as conexões de saída funcionam normalmente, cerca de 10, e não há conexões de entrada. Para resolver, comente as linhas desnecessárias, reinicie e consulte getnetworkinfo outra vez.
Uma única linha do bitcoin.conf pode cortar todas as conexões. proxy= e connect= também desativam as conexões de entrada por padrão, mesmo sem listen=0.

Passo 6: adicione manualmente nós confiáveis que você conhece. Se o nó não encontrar outros nós pelas sementes DNS ou pelo protocolo de descoberta de pares, adicione manualmente nós de confiança com bitcoin-cli addnode "ip:port" add. Você pode encontrar endereços de nós confiáveis em listas mantidas pela comunidade ou em um nó secundário que você opere. Isso contorna bloqueios no DNS e ajuda a estabelecer as primeiras conexões em redes restritivas.

Onde o Bitcoin Core encontra outros nós, em ordem. 1. Endereços que já conhece, no peers.dat. Outros nós compartilham os endereços que conhecem. Seu nó grava os endereços no disco e tenta usá-los primeiro. Se o peers.dat estiver vazio ou o nó continuar quase sem pares após uma breve espera, ele passa para a próxima opção. 2. Sementes DNS. São servidores operados por voluntários e listados no Bitcoin Core. Cada servidor responde com os nós que viu online. Se o nó continuar sem conhecer nenhum endereço após 1 minuto, ele passa para a próxima opção. 3. Sementes fixas. São endereços de nós embutidos no Bitcoin Core que funcionam mesmo quando o DNS está bloqueado. Separadamente, o nó sempre tenta se conectar aos nós que você adicionar com addnode, a qualquer momento e além das conexões automáticas (até 8 nós adicionados). Se você apagar o peers.dat, o nó consulta as sementes DNS em questão de segundos quando a busca por DNS está ativada, como ocorre por padrão. Um nó no modo só Tor (onlynet=onion) pula essa consulta e recorre às sementes fixas. Se o DNS estiver bloqueado, as sementes fixas e addnode continuam funcionando.
Um nó tenta primeiro os endereços que tem salvos. As sementes DNS e as fixas são alternativas. Por isso, quando você apaga o peers.dat, um nó com as configurações padrão consulta diretamente as sementes DNS (um nó no modo só Tor recorre às sementes fixas). É também por isso que addnode ajuda quando o nó não consegue acessar as sementes.

Passo 7: verifique se há interferência do provedor de internet ou da rede. Alguns provedores limitam ou bloqueiam o tráfego P2P do Bitcoin na porta 8333. Para testar, mude para o modo só Tor. Esse modo encapsula todo o tráfego em circuitos do Tor e contorna a filtragem de portas específicas. Mudar a porta do nó com port= só altera o ponto por onde outros nós acessam o seu. Isso pode ajudar nas conexões de entrada, mas as de saída continuam indo para a porta de cada nó de destino. Se a conectividade melhorar de imediato no Tor, é provável que seu provedor esteja interferindo no tráfego do Bitcoin na rede pública (clearnet).

Passo 8: monitore e mantenha a conexão estável. Quando resolver a falha, configure o monitoramento contínuo. Use bitcoin-cli getnetworkinfo para verificar a contagem de conexões periodicamente ou instale uma ferramenta de monitoramento que avise se o número de nós ficar abaixo de um limite. Para infraestrutura crítica, como nós que atendem canais da Lightning, considere uma tarefa no cron que reinicie o Bitcoin Core automaticamente caso ele pare de responder.

Erros comuns a evitar

1. Reiniciar o nó várias vezes em vez de diagnosticar o problema. Reiniciar o Bitcoin Core corta todas as conexões e faz o nó se conectar outra vez a partir dos endereços salvos no peers.dat. Isso pode esconder temporariamente um problema persistente. Se o nó se desconectar repetidamente, procure mensagens de erro específicas em debug.log antes de reiniciar às cegas. O log costuma mostrar se as conexões são recusadas, se atingem o limite de espera ou se o outro lado as encerra.

2. Rodar o Bitcoin Core com um banco de dados de pares desatualizado. O arquivo peers.dat guarda endereços conhecidos da rede. Se você migrou o diretório de dados de outro ambiente de rede ou de um backup antigo, os endereços salvos podem estar desatualizados ou inacessíveis. Apagar o peers.dat faz o nó voltar a buscar as sementes. Com as configurações padrão, o nó consulta as sementes DNS em questão de segundos, o que costuma resolver problemas de conexão inicial. Com dnsseed=0 ou no modo só Tor (onlynet=onion), a busca por DNS fica desativada e o nó recorre às sementes fixas integradas. Com connect=, o nó só tenta se conectar aos pares que você indicou, por isso o arquivo peers.dat não interfere nesse caso.

3. Confundir a conexão da carteira com a do nó. Se a carteira mostrar “not connected”, mas o nó Bitcoin Core estiver totalmente sincronizado e tiver pares, a falha está na conexão entre a carteira e o nó, não entre o nó e a rede Bitcoin. Confira o processo do servidor Electrum. Depois que o Bitcoin Core terminar a sincronização, o servidor pode levar horas para montar o próprio índice. O Fulcrum, por exemplo, recusa conexões de carteiras até terminar. Confira separadamente a configuração do servidor na carteira e os ajustes de proxy do Tor no aplicativo. Esses ajustes são independentes da camada P2P do nó.

Uma cadeia da esquerda para a direita. O aplicativo da carteira, um servidor Electrum se você usar um, o Bitcoin Core (seu nó) e outros nós da rede. Os dois primeiros elos são a conexão da carteira, de onde vem a mensagem “not connected”. Confira se o servidor Electrum está rodando, se terminou de montar o próprio índice, se a carteira tem o endereço e a porta do servidor e se os ajustes do Tor na carteira estão corretos. O último elo é a conexão do nó com a rede, verificada com o getnetworkinfo. Se o nó tiver pares e a carteira mostrar “not connected”, confira o lado da carteira.
“Not connected” na carteira e um nó sem pares são dois problemas diferentes. São conexões diferentes, com verificações próprias. Um servidor Electrum novo pode recusar conexões de carteiras por horas enquanto monta o próprio índice.

4. Abrir a porta 8333 no roteador sem ajustar o firewall. Só o redirecionamento não basta se o firewall local do servidor bloquear o tráfego de entrada nessa porta. Da mesma forma, abrir a porta no firewall sem redirecioná-la no roteador também não permite conexões de entrada pela internet. As duas camadas precisam estar configuradas de forma coerente para as conexões de entrada funcionarem.

5. Culpar banimentos automáticos pela falta de pares. Desde a versão 0.20.1 (2020), se outro nó enviar dados inválidos, o Bitcoin Core desconecta esse nó e o evita por um tempo em vez de bani-lo. O Bitcoin Core chama isso de desencorajar o par. A lista fica apenas na memória, por isso uma reinicialização a limpa, e o bitcoin-cli listbanned não a mostra. Os banimentos em listbanned foram adicionados com setban por você ou por uma ferramenta que você usa. Se as entradas parecerem incorretas ou excessivas, limpe-as com bitcoin-cli clearbanned.

Perguntas frequentes

Por que meu nó mostra 10 conexões e nunca mais do que isso?

Dez é o número de conexões de saída que o Bitcoin Core estabelece por conta própria: 8 retransmitem transações e blocos e 2 só retransmitem blocos. Antes da versão 0.19, de novembro de 2019, estabelecia 8. Você pode ver uma ou duas a mais por um momento enquanto ele testa outros nós. As conexões de entrada, de outros nós para o seu, exigem que a porta 8333 esteja acessível pela internet. Isso implica redirecionar a porta no roteador e ter uma regra de firewall que permita tráfego de entrada. Sem isso, o nó continua ouvindo conexões, mas ninguém de fora consegue alcançá-lo, por isso fica com 10 conexões de saída. Quando está acessível, o Bitcoin Core 32.1 aceita até 189 conexões de entrada. No máximo metade delas pode ser de nós que retransmitem transações. Os demais só retransmitem blocos. Assim, o nó funciona com segurança. Aceitar conexões de entrada melhora a descentralização, mas é dispensável para uso pessoal.

Meu nó funcionava bem e de repente perdeu todos os pares. O que aconteceu?

Perder os pares de repente costuma indicar uma mudança na rede. O roteador pode ter reiniciado ou o endereço IP público pode ter mudado. Qualquer um dos dois eventos derruba todas as conexões abertas, e o nó deve voltar a se conectar sozinho em poucos minutos. Também pode ter havido uma interrupção no provedor de internet ou, no modo só Tor, uma falha no serviço do Tor. Um roteador que perdeu as regras de redirecionamento de portas tem um efeito diferente. Só as conexões de entrada caem, e seu nó mantém cerca de 10 conexões de saída. Confira primeiro a configuração da rede. Depois, procure mensagens de tempo de espera esgotado ou erros de socket no debug.log do Bitcoin Core perto do momento em que as quedas começaram. Um peers.dat corrompido (o arquivo com os endereços salvos dos pares) aparece de outra forma. O Bitcoin Core para na inicialização com o erro “Invalid or corrupt peers.dat”. Se você mover esse arquivo para outro lugar, o Bitcoin Core consegue iniciar com uma lista nova.

É normal o nó levar dias para sincronizar depois de um tempo offline?

Depende do tempo que o nó ficou offline e das especificações do hardware. Por dia offline, ele precisa baixar e validar cerca de 144 blocos. Em novembro de 2026, isso dá cerca de 230 MB de dados, com blocos de aproximadamente 1,6 MB em média. Depois de uma semana offline, um nó precisa processar cerca de 1.000 blocos (cerca de 1,6 GB). Isso pode levar de minutos em um equipamento rápido a horas em um Raspberry Pi com pouca RAM. Se a sincronização levar muito mais tempo do que o esperado, monitore a saída de debug.log para conferir se o nó está conectado a outros nós e baixando blocos.

Barras em escala dos dados de blocos que um nó baixa para se atualizar. Um dia offline: cerca de 144 blocos e cerca de 230 MB. Uma semana: cerca de 1.000 blocos e cerca de 1,6 GB. Um mês: cerca de 4.300 blocos e cerca de 7 GB. A primeira sincronização do zero, de cerca de 800 GB, aparece encurtada porque, na mesma escala, a barra seria mais de 100 vezes maior que a de um mês. Em novembro de 2026, os blocos têm em média cerca de 1,6 MB. Sai um bloco a cada 10 minutos, em média. Se o nó levar dias para se atualizar, confira se tem pares e está baixando blocos.
Uma semana offline dá cerca de 1,6 GB de blocos. Sincronizar do zero exige muito mais. Se a atualização levar dias, é provável que o nó não esteja baixando os blocos. Confira as conexões com outros nós.

Devo usar uma VPN em vez do Tor para proteger a privacidade do nó?

As VPNs e o Tor atendem a objetivos de privacidade diferentes. Uma VPN oculta o tráfego do Bitcoin do provedor de internet, mas transfere a confiança para o provedor da VPN, que pode registrar seu IP e os padrões de tráfego. O Tor distribui a confiança entre vários operadores de retransmissores e oferece mais anonimato, mas com latência maior. Para um nó de Bitcoin, em geral prefere-se o Tor porque você não precisa confiar em um único provedor. Além disso, quando todas as conexões do nó passam pelo Tor, o IP da sua casa fica fora das listas de pares de outros nós. Ainda assim, o Tor pode introduzir latência e afetar o desempenho do roteamento na Lightning. Como solução intermediária, alguns operadores usam uma VPN para o nó da Lightning e o Tor para o nó da camada base do Bitcoin.

Recursos relacionados

Faz parte do nosso curso de Bitcoin:Este tema é explicado em Como configurar seu nó de Bitcoin passo a passo, do curso Rede Lightning e nós de Bitcoin.
Categoria: Nós e infraestrutura

Continue lendo

← Voltar aos cursos