Antes de começar
Regista Java ou Bedrock, versões de cliente e servidor, endereço com porta e hora exata. Conserva mensagens da consola e alterações recentes. Antes de mudar mundos, mods ou ficheiros, prepara uma cópia que possas restaurar.
Confirmar edição e endereço
Java e Bedrock não são intercambiáveis: Java utiliza normalmente TCP e Bedrock UDP. Mudar a porta não torna as duas edições compatíveis. Usa o endereço atribuído no painel e verifica o destino de DNS ou de um registo SRV Java. Um acesso administrativo disponível não confirma que estejas a testar a porta de jogo correta.
A jogabilidade Java geralmente usa um endpoint TCP, enquanto a jogabilidade do servidor Bedrock usa UDP. Os padrões comuns nunca substituem a alocação do painel. Em um nó compartilhado, copiar uma porta padrão de um tutorial pode entrar em conflito com outra instância. Um teste TCP não pode validar a conectividade Bedrock UDP.
Testar apenas o percurso TCP Java a partir do Windows
Test-NetConnection -ComputerName 192.0.2.10 -Port 25565Substitua o endereço e a porta pela atribuição real. TcpTestSucceeded=True confirma apenas a ligação TCP; não verifica UDP Bedrock, autenticação Minecraft ou desempenho. Se aparecer False, compare a escuta, o arranque e as regras dessa porta específica.
Verificar o arranque completo
O processo pode estar ativo enquanto o mundo carrega. Procura a conclusão do arranque e erros de Java, configuração, plugins ou mods. Se o serviço reinicia continuamente, analisa primeiro esse ciclo. Reinícios repetidos podem acrescentar carga e esconder pistas; guarda os registos e não alteres mundo, versão e extensões ao mesmo tempo.
Após adicionar um plugin ou mod, verifique suas dependências e compatibilidade do motor. Paper, Fabric, Forge e NeoForge não carregam automaticamente as mesmas extensões. Utilize uma cópia de teste e remova apenas o acréscimo identificado; excluir um mundo não é uma forma de diagnosticar um erro de software.
Testar o protocolo necessário
Confirma a associação autorizada entre IP pública e porta. Um teste TCP não valida uma porta Bedrock UDP. Com visibilidade LAN ativada, Bedrock pode abrir portas padrão adicionais mesmo com outra porta configurada; num nó partilhado isso tem de respeitar o esquema do operador. Não abras portas extra ou de outras instâncias para tentar resolver a falha.
Em seguida, compare com outra conexão autorizada. Quando apenas uma rede falhar, registre seu provedor e os horários, em vez de alterar imediatamente a configuração global. O ping ICMP bloqueado não estabelece que o jogo está inacessível; uma resposta de ping também não prova que a porta do jogo está aberta.
Verificar o DNS Java sem alterar a zona
dig +short A play.example.com
dig +short SRV _minecraft._tcp.play.example.comUm registo SRV Java pode anunciar outro destino e outra porta. Resolva também o nome devolvido e compare-o com a atribuição. Não é necessário SRV se o cliente já utiliza o endereço e a porta corretos. Este não é um teste UDP Bedrock.
Comparar versões e dependências
Verifica versão do jogo, software do servidor e loader. Um modpack pode exigir a mesma combinação no cliente e no servidor. Se a falha segue uma mudança, investiga essa dependência com uma cópia preservada. Regressar a uma versão antiga ou mudar de mundo pode tornar dados incompatíveis. Não apagues o original nem todas as extensões para experimentar.
A descoberta de LAN Bedrock também pode abrir suas portas usuais, além de uma porta personalizada. Em um nó compartilhado, use a configuração adaptada do painel e solicite uma verificação de conflito de alocação. Para um proxy Java ou gateway de jogo cruzado, inspecione cada estágio do caminho em vez de apenas o endereço público.
Medir a carga no momento do problema
Observa processador, memória e consola no mesmo intervalo. Uma tarefa principal saturada pode bloquear Minecraft apesar de uma utilização média baixa. Em Paper, spark permite analisar a situação enquanto ocorre. Confirma distâncias de visão e simulação e eventuais substituições noutras configurações: mais RAM não corrige necessariamente esse trabalho nem uma configuração demasiado exigente.
Onde houver suporte, crie o perfil do servidor durante o problema com uma ferramenta compatível. Versões recentes do Paper incluem spark. Um relatório de um servidor vazio é menos útil do que um relatório capturado durante a desaceleração. Limite a gravação e proteja links de diagnóstico que possam conter informações confidenciais.
Preparar um diagnóstico reproduzível
Compara um segundo acesso à Internet e identifica os jogadores afetados. Guarda hora, endpoint e mensagens úteis, retirando credenciais e dados privados. Um timeout pode resultar de encaminhamento, filtragem, protocolo errado ou servidor ainda indisponível. Atribui-o a um ataque ou falta de recursos apenas quando os dados de rede e aplicação sustentam essa conclusão.
A atividade suspeita de DDoS precisa de correlação com medições de tráfego ou eventos de mitigação. Um tempo limite por si só não é evidência suficiente. Evite reinicializações repetidas e verificações agressivas: elas aumentam a carga e dificultam o diagnóstico. Teste a correção usando uma conexão normal e verifique se os jogadores normais podem retornar.
O que fazer no teu caso
| Situação | Próximo passo |
|---|---|
| Edição errada | Escolhe Java ou Bedrock e o endpoint real. Outra porta não converte a edição. |
| Falha após mods ou mudança de mundo | Confirma versões e dependências, conservando uma cópia separada do estado anterior. |
| Só falha sob carga | Analisa a tarefa principal e os chunks durante o problema antes de aumentar o plano. |
Fontes oficiais
Estas fontes explicam os protocolos e configurações referidos. Confirma sempre a documentação da tua versão.