BungeeCord: Could not connect to a default or fallback server

Could not connect to a default or fallback server significa: o BungeeCord está a funcionar, mas não conseguiu encaminhar o jogador para nenhum destino inicial permitido. A causa normalmente está em priorities, no estado do backend, no endereço/porta, na firewall, no forwarding ou na compatibilidade de protocolo.

Não abras o porto do backend para a Internet de forma genérica só para diagnosticar. Testa do ponto de vista do proxy e continua a permitir apenas o caminho verificado dele. A imagem-alvo segura está no pilar de configuração do BungeeCord.

Árvore de diagnóstico

Cada nome em priorities existe em servers?
├─ não -> corrigir nomes e maiúsculas/minúsculas
└─ sim
   Há pelo menos um destino totalmente iniciado?
   ├─ não -> resolver erro de arranque do backend
   └─ sim
      O proxy alcança exatamente este endereço e este porto?
      ├─ não -> verificar endereço, alocação, rota e firewall
      └─ sim
         Forwarding e versões estão corretos?
         ├─ não -> corrigir a configuração de forma consistente
         └─ sim -> verificar o primeiro stacktrace concreto do proxy/backend

1. Comparar priorities com servers

servers:
  lobby:
    address: <LOBBY-ADRESSE>:<PORT>
    restricted: false

listeners:
  - priorities:
      - lobby

lobby, Lobby e lobby não são a mesma chave. Cada entrada em priorities tem de existir em servers. Com vários destinos, o BungeeCord tenta-os por ordem; um primeiro destino avariado não deve também esconder o segundo fallback.

2. Iniciar realmente o backend

Um estado de contentor “running” não chega. Lê o log do backend até à mensagem de conclusão do arranque. Bloqueios típicos no arranque são:

• EULA não aceite;
• imagem Java errada;
• JAR de plugin danificado ou incompatível;
• erro de mundo/mod;
• porto já ocupado;
• servidor a escutar noutra alocação.

Depois testa o servers.<name>.address concreto. Um ping ao IP do host não prova que o porto TCP do Minecraft esteja acessível.

3. Verificar o endereço do ponto de vista do proxy

127.0.0.1 aponta, no contentor do proxy, para o próprio contentor do proxy. Usa-o apenas se o backend e o proxy comprovadamente partilharem o mesmo namespace de rede. Em instâncias separadas, precisas do endereço do backend que seja alcançável pelo proxy.

Padrões de erro:

Na game-serverhosting, o Backend Guard ativo protege os caminhos BungeeCord comprovados. Se o proxy estiver parado ou a sua origem concreta estiver em falta, o caminho para o backend fica intencionalmente apenas em drop. Inicia o proxy correto e espera pela reavaliação, em vez de remover a regra de proteção.

4. Verificar a firewall com precisão

A firewall tem de cumprir duas condições ao mesmo tempo:

1. o proxy associado alcança o porto TCP do backend;
2. uma origem independente não o alcança.

Se ambas falharem, verifica primeiro a associação concreta do proxy e a resolução da origem. Se ambas funcionarem, o backend está desprotegido. Uma autorização para uma sub-rede inteira de shared hosting ou Docker não é uma reparação limpa.

5. Comparar os valores de forwarding

Para BungeeCord clássico com Paper/Spigot:

• Proxy online_mode: true;
• Proxy ip_forward: true;
• Backend server.properties com online-mode=false;
• Backend spigot.yml com settings.bungeecord: true;
• Paper proxies.bungee-cord.online-mode: true, se o proxy autenticar online.

Uma mensagem como If you wish to use IP forwarding... mostra frequentemente uma configuração inconsistente entre proxy e backend. Por causa de possíveis alterações de UUID, altera estes valores apenas depois de um backup e com o guia de segurança de forwarding.

6. Isolar versão e plugins

Compara o protocolo do cliente, do proxy e do backend. Um porto TCP aberto ainda pode rejeitar um join. Se possível, inicia com uma lobby sem plugins de proxy adicionados recentemente. Instala plugins do BungeeCord apenas no proxy e plugins Bukkit/Paper apenas nos backends; o guia de plugins explica as camadas.

Não removas plugins às cegas de uma produção. Faz backup de plugins/ e da configuração, altera uma variável numa cópia e, se falhar, reverte.

7. Verificar o domínio só depois do caminho direto

Testa primeiro o IP público do proxy mais o porto. Se funcionar, mas o domínio não, investiga A/AAAA e SRV separadamente. O nome de destino SRV tem de apontar para o proxy. Usa o guia de domínio/SRV.

Verificação final

O erro só está resolvido quando TCP, ping do Minecraft e join real na lobby através do proxy estiverem verdes. Depois repete o teste negativo independente para o backend. Para uma migração ou troca de versão, usa antes o caminho de backup e rollback. O crossplay vem só depois; TCP e Geyser-UDP são verificados separadamente.

FAQ

O que significa exatamente esta mensagem?

Que o próprio BungeeCord está a funcionar e aceitou o jogador, mas não conseguiu encaminhá-lo para nenhum destino inicial permitido. Assim, o proxy não é a fonte do erro — a causa está em priorities, no estado do backend, no endereço e porto, na firewall, no forwarding ou na versão do protocolo.

Posso introduzir 127.0.0.1 como endereço do backend?

Só se o proxy e o backend comprovadamente partilharem o mesmo namespace de rede. No contentor do proxy, 127.0.0.1 aponta para o próprio contentor do proxy, não para o backend. Em instâncias separadas, precisas do endereço pelo qual o proxy realmente alcança o backend.

Connection refused ou Timeout — qual é a diferença?

Connection refused significa que nada está a escutar no porto de destino ou que uma regra rejeita ativamente: normalmente um backend não iniciado ou um porto errado. Um timeout indica uma rota ou firewall que descarta pacotes, um destino bloqueado ou um endereço errado.

Devo abrir brevemente o porto do backend para diagnosticar?

Não. Um porto de backend em Offline Mode aberto permite que terceiros se façam passar por qualquer jogador. Em vez disso, testa do ponto de vista do proxy. Se o caminho para o backend continuar bloqueado apesar de o proxy estar a correr, verifica a associação concreta do proxy — e não removas a regra de proteção.

O porto TCP está acessível, mas o join continua a falhar — qual é a causa?

Um porto aberto só prova que algo está a escutar. Se o join falhar depois disso, compara as versões de protocolo do cliente, proxy e backend e inicia, como teste, uma lobby sem plugins de proxy adicionados recentemente. Verifica também se plugins do BungeeCord foram colocados por engano num backend.

Fontes primárias

• Instalação do BungeeCord
• Guia de configuração do BungeeCord
• Repositório do BungeeCord e aviso de segurança