config.yml do BungeeCord explicado: definições seguras

O config.yml define onde o BungeeCord escuta, quais backends conhece e para onde novos jogadores são encaminhados. Gera sempre o ficheiro com a tua versão instalada. Exemplos antigos de blog podem conter campos ou defaults que já não combinam com a build atual.

Uma configuração sintaticamente válida ainda não é uma rede segura. Assim que os backends usam online-mode=false, a sua porta TCP tem de estar protegida contra ligações diretas. O processo completo está no pilar de configuração do BungeeCord.

Estrutura base segura

online_mode: true
ip_forward: true
player_limit: -1
server_connect_timeout: 5000
remote_ping_timeout: 5000

servers:
  lobby:
    address: <LOBBY-ADRESSE>:<PORT>
    motd: '&aLobby'
    restricted: false
  survival:
    address: <SURVIVAL-ADRESSE>:<PORT>
    motd: '&aSurvival'
    restricted: false

listeners:
  - host: 0.0.0.0:<PROXY-PORT>
    motd: '&aA Minha Rede'
    priorities:
      - lobby
      - survival
    force_default_server: true
    forced_hosts:
      survival.example.net: survival
    max_players: 100
    tab_list: GLOBAL_PING
    query_enabled: false
    proxy_protocol: false

Os placeholders têm de ser substituídos pelos endereços do painel. Um endereço de backend público no exemplo não é uma autorização para deixar a porta aberta publicamente.

Campos globais

servers: nomear backends

Cada chave em servers é um nome interno. address tem de estar acessível do ponto de vista do processo do proxy. restricted: true exige a permissão bungeecord.server.<name>, mas não impede acesso direto pela rede à porta do backend.

Evita usar o mesmo domínio público do proxy como endereço de backend: isso pode criar um loop. Usa um endereço concreto interno, privado ou autorizado de outra forma para o proxy.

listeners: entradas públicas

host tem de corresponder à alocação atribuída ao proxy. priorities é a lista ordenada para arranque e fallback. Um erro de digitação como Lobby em vez de lobby basta para que nenhum destino padrão seja encontrado.

force_default_server: true inicia novas ligações através da lógica de prioridades/Forced Host. Com false, o BungeeCord pode tentar restaurar um destino usado anteriormente.

max_players não é player_limit

listeners.*.max_players controla o número de jogadores mostrado na lista de servidores. player_limit é o limite global rígido. Define ambos de forma consciente; uma apresentação bonita não substitui medição de capacidade.

forced_hosts e DNS

forced_hosts associa um hostname a um nome interno de servidor. O DNS continua a apontar para o BungeeCord. Para domínio e porta diferente, usa o guia de domínio/SRV.

Não confundas os campos

• proxy_protocol é para um remetente HAProxy/PROXY Protocol colocado à frente, não para o forwarding normal do BungeeCord.
• query_enabled abre, se necessário, um serviço UDP separado; não o atives por precaução.
• ping_passthrough assume o MOTD e o estado de um destino, mas torna uma falha do backend mais visível.
• restricted é uma permissão do BungeeCord, não uma firewall.
• /greload não recarrega de forma fiável todas as alterações de plugins e permissões; planeia um reinício.

Configurar corretamente o lado do backend

Define server.properties como online-mode=false e settings.bungeecord: true em spigot.yml. No Paper, proxies.bungee-cord.online-mode tem de combinar com o online_mode do proxy. Antes de mudares algo, lê o guia de forwarding seguro e cria um backup testado através do caminho de cópia/rollback descrito no guia de mudança de versão.

Validação

1. Usa apenas espaços, sem tabs.
2. Verifica a indentação e strings com caracteres especiais.
3. Compara todos os nomes em priorities e forced_hosts com servers.
4. Reinicia completamente o backend e o proxy.
5. Testa TCP, ping do Minecraft e entrada real no lobby separadamente.
6. Testa a partir de uma fonte independente se a porta do backend está bloqueada.

Se o BungeeCord não chegar a nenhum lobby, o guia de erros de fallback ajuda. Só depois deste teste base instala plugins de proxy e backend no nível correto.

FAQ

Porque não devo copiar o config.yml de um tutorial?

Porque campos e valores padrão mudam entre builds. Deixa o BungeeCord gerar o ficheiro com a tua versão instalada e transfere daí apenas os valores que realmente queres ajustar. Um campo de um exemplo antigo pode faltar na tua build ou ter outro significado.

Qual é a diferença entre max_players e player_limit?

listeners.*.max_players é apenas apresentação: o número que os clientes veem na lista de servidores. player_limit é o limite global rígido a partir do qual o proxy recusa ligações (0 ou menor significa ilimitado). Define ambos de forma consciente: uma indicação alta não substitui medição de capacidade.

restricted: true basta para proteger um backend?

Não. restricted é uma permissão do BungeeCord e exige bungeecord.server.<name> para a troca através do proxy. Não impede ninguém de contactar diretamente a porta do backend. A proteção aí é firewall ou rede privada, não a configuração do proxy.

Tenho de reiniciar depois de uma alteração, ou /greload chega?

Planeia um reinício. /greload relê a configuração, mas não transfere de forma fiável todas as alterações de plugins e permissões para o estado em execução. Em alterações a listeners, servidores ou forwarding, o reinício completo é o único caminho fiável.

Porque é que o domínio do proxy não pode estar como endereço de backend?

Porque o proxy passaria a contactar-se a si próprio como destino e criaria um loop. Em servers.<name>.address deve estar o endereço pelo qual o processo do proxy alcança o backend: um endereço interno ou privado, não o nome público para o qual o DNS da tua rede aponta.

Fontes primárias

• Referência oficial de configuração do BungeeCord
• Defaults atuais do BungeeCord no source
• Configuração global do Paper