O campo server-ip em server.properties escolhe o endereço local de rede ao qual o processo Minecraft tenta se vincular. Ele não é um campo para digitar o IP público do servidor. Paper informa que, na maioria dos casos, o valor deve ficar vazio para escutar em todas as interfaces disponíveis. Uma configuração incorreta pode causar Failed to bind to port ou tornar a instância inalcançável.

Interfaces são pontos locais do sistema operacional: por exemplo, loopback, endereço privado da placa de rede ou IP atribuído a um container. O endereço público pode existir num roteador ou NAT e nem estar configurado diretamente na máquina. O cliente conecta ao destino público; redirecionamento de porta e firewall determinam se os pacotes chegam ao processo.

O que significa bind na prática

Quando o servidor abre uma porta, ele associa o listener a um IP local e a uma porta. Se server-ip contém um endereço que não existe na máquina, o sistema pode recusar o bind. Se fica vazio, o processo normalmente escuta em todas as interfaces, sujeito a firewall e publicação de porta.

Em container, o processo pode ver apenas um endereço interno. Um painel publica a porta e faz NAT para o container; colocar o IP público do host dentro do container costuma falhar porque aquele endereço não pertence à interface do ambiente. Pergunte ao provedor qual endereço local deve ser usado antes de personalizar o valor.

Em máquina com proxy local, pode-se considerar 127.0.0.1 para backend quando proxy e Paper estão no mesmo host e ninguém não confiável hospeda serviços nele. Essa decisão precisa combinar com o endereço configurado no Velocity e com o ambiente de rede. Em hospedagem compartilhada, localhost pode representar a máquina inteira e não oferecer isolamento entre clientes.

Diagnostique Failed to bind to port

A documentação do Paper lista duas causas comuns: outro servidor já ocupa a porta ou o server-ip está incorreto. Verifique a lista de processos Java e o painel para ver se a instância anterior ainda está ativa. Confirme também se duas instâncias usam a mesma porta e endereço local.

Leia a mensagem completa. “Address already in use” aponta para conflito de porta; erro de endereço indisponível sugere IP que não existe localmente ou interface ainda não configurada. Em Windows e Linux, ferramentas do sistema podem revelar qual processo escuta na porta, mas siga o método suportado pelo host e não encerre processos alheios sem identificá-los.

Confira o estado do painel e aguarde o processo realmente terminar antes de reiniciar. Uma tarefa de reinício automático pode deixar instância antiga ativa, e um deploy pode iniciar uma cópia duplicada. Correlacione horário e PID com logs para não confundir duas pastas de servidor.

Separar bind, porta e firewall

server-port é a porta local usada pelo servidor; server-ip é o endereço de bind. Uma regra NAT ou firewall pode publicar outra porta externa e encaminhar para a interna. Se a conexão funciona dentro do host mas não da internet, investigue firewall, NAT, DNS e provedor antes de trocar o bind.

Em proxy Velocity, clientes entram na porta do proxy e os backends podem usar portas privadas. A topologia precisa garantir que o backend só aceite o proxy e que o proxy encaminhe ao IP local correto. Modern forwarding autentica informações de jogador, mas não substitui firewall ou controle de acesso do backend.

DNS aponta o cliente para um endereço, mas não cria listener nem abre porta. Um registro SRV pode apontar para porta diferente; verifique alvo e porta separadamente. Ao testar, compare conexão local, na mesma rede e de uma rede externa para isolar a camada com problema.

Escolha uma configuração segura

Se não há requisito claro para um bind específico, deixe server-ip vazio, como recomenda o diagnóstico do Paper para a maioria dos casos. Se houver motivo para restringir a uma interface, use endereço realmente atribuído à instância e valide após reiniciar. Documente porque a escolha foi feita e qual listener deveria aparecer.

Para rede com proxy no mesmo servidor dedicado, loopback pode reduzir exposição. Configure o backend para o mesmo endereço local e feche a porta pública de backend no firewall. Teste que proxy conecta e acesso externo direto falha. Em vários hosts, use endereços privados de rede e ACLs entre máquinas, conforme suporte do provedor.

Não copie um IP de painel que se refere ao serviço público, nem use endereço de outro nó. Em containers e hospedagem compartilhada, descubra o modelo de rede do provedor. Um IP privado compartilhado pode ser válido para bind, mas não representa isolamento de cliente.

Valide o serviço depois da mudança

Faça backup de server.properties, pare corretamente e altere somente a propriedade necessária. Reinicie e confirme no log que o servidor abriu o endereço e a porta esperados. Não publique o backend até firewall, modo de autenticação e forwarding estarem configurados.

Teste uma conexão pelo caminho público, pelo proxy e, quando aplicável, diretamente do host. Confira status, entrada de jogadores, UUID, permissões e troca de backend. Para testar bloqueio direto, faça a tentativa a partir de rede autorizada e confirme firewall em vez de depender só de mensagens de cliente.

Se falhar, restaure o valor anterior e preserve a mensagem. Não altere simultaneamente DNS, porta, firewall e bind; faça uma mudança de cada vez. Essa sequência torna o diagnóstico mais rápido e evita deixar o serviço exposto durante tentativa-e-erro.

Cuidados em instalações com vários servidores

Mantenha inventário de IPs, portas e nomes por instância: lobby, survival, minigames e proxy. Cada configuração deve indicar se o serviço é público ou backend. Evite reutilizar portas sem necessidade e use firewall para permitir somente fluxos previstos.

Quando migrar para outro host, a interface e os IPs locais podem mudar. Atualize os binds, endereços do Velocity, regras de firewall, DNS e documentação numa janela coordenada. Guarde backups de configurações e teste a rota antes de abrir acesso da comunidade.

Entender bind separadamente de IP público e redirecionamento de porta evita muitos falsos diagnósticos. Comece pelo log de startup, confirme a interface local e depois siga o tráfego até a máquina. O valor correto é o que atende ao desenho de rede real da instância.

Fontes e referências

Documentação consultada em 2026-10-08. Os exemplos precisam ser conferidos na versão instalada; este guia não afirma que a configuração foi testada no seu ambiente.