“Servidor offline” no navegador de lista e “não consigo conectar” não são o mesmo sintoma. Teste cada camada da rota e registre a mensagem exata. Para evitar uma correção baseada em suposição, identifique primeiro a versão, a instância e o sintoma observável. Faça alterações em cópia sempre que houver risco para mundo, dados ou acesso dos jogadores.
Este guia explica como validar a hipótese com evidências. Os nomes, padrões e efeitos podem variar entre versões e integrações; consulte a documentação oficial listada no final para o seu release e registre o estado anterior antes de editar.
O que a configuração controla
Comece pela definição oficial e registre o padrão documentado para a versão instalada. Evite inferir comportamento apenas pelo nome do parâmetro: opções semelhantes podem atuar em estágios diferentes. Confira o arquivo e a build exatos antes de comparar resultados.
Registre o que mudou, execute o fluxo em pelo menos duas condições relevantes e confira os logs desde a inicialização. Se o resultado esperado não ocorrer, volte ao valor original e investigue a camada responsável antes de ampliar a mudança.
Identifique arquivo e processo ativos
Confirme o diretório de trabalho, o JAR executado e o processo que atende o endereço público. Painéis podem iniciar mais de uma instância e gerar arquivos no diretório configurado pelo comando. Compare timestamps, console e caminho informado pelo painel.
Registre o que mudou, execute o fluxo em pelo menos duas condições relevantes e confira os logs desde a inicialização. Se o resultado esperado não ocorrer, volte ao valor original e investigue a camada responsável antes de ampliar a mudança.
Entenda precedência e integrações
Procure argumentos CLI, configurações do proxy e plugins que possam substituir ou apresentar o valor. A referência de CLI do Paper descreve opções que sobrepõem propriedades equivalentes; gateways e painéis também mantêm dados próprios. Anote cada fonte antes de editar.
Registre o que mudou, execute o fluxo em pelo menos duas condições relevantes e confira os logs desde a inicialização. Se o resultado esperado não ocorrer, volte ao valor original e investigue a camada responsável antes de ampliar a mudança.
Reproduza em ambiente controlado
Faça backup e copie a situação para homologação. Mude uma variável por vez, reinicie pelo procedimento normal e repita uma ação concreta. Registre resultado esperado, resultado observado, mensagem e linhas de log. Isso reduz tentativa e erro e facilita voltar ao estado conhecido.
Registre o que mudou, execute o fluxo em pelo menos duas condições relevantes e confira os logs desde a inicialização. Se o resultado esperado não ocorrer, volte ao valor original e investigue a camada responsável antes de ampliar a mudança.
Faça a alteração mínima e segura
Com o processo parado quando a mudança exige reinício, salve a configuração original e edite somente a instância confirmada. Respeite formato, tipos e versão. Não substitua arquivo inteiro por um exemplo de outro release nem copie uma linha de fórum sem conferir sua documentação.
Registre o que mudou, execute o fluxo em pelo menos duas condições relevantes e confira os logs desde a inicialização. Se o resultado esperado não ocorrer, volte ao valor original e investigue a camada responsável antes de ampliar a mudança.
Valide no cliente e no servidor
Teste caminho completo: console, backend, proxy e cliente real quando aplicável. Confirme status, login, reconexão e persistência depois do reinício. Uma mensagem visual antiga pode vir de cache, mas um erro no log do backend aponta para outro ponto do diagnóstico.
Registre o que mudou, execute o fluxo em pelo menos duas condições relevantes e confira os logs desde a inicialização. Se o resultado esperado não ocorrer, volte ao valor original e investigue a camada responsável antes de ampliar a mudança.
Se o comportamento continuar incorreto
Reverta apenas a última alteração e confira se o problema desaparece. Analise o primeiro erro, identifique plugin citado e compare com uma cópia sem o componente quando seguro. Mantenha bibliotecas exigidas por outros plugins e use busca binária para isolar conflitos.
Registre o que mudou, execute o fluxo em pelo menos duas condições relevantes e confira os logs desde a inicialização. Se o resultado esperado não ocorrer, volte ao valor original e investigue a camada responsável antes de ampliar a mudança.
Documente e monitore
Anote valor anterior e novo, origem do parâmetro, versão, horário e plano de retorno. Acompanhe métricas e chamados após a mudança. Se a mesma divergência voltar após atualização ou restauração de painel, revise templates e automações que escrevem o arquivo.
Registre o que mudou, execute o fluxo em pelo menos duas condições relevantes e confira os logs desde a inicialização. Se o resultado esperado não ocorrer, volte ao valor original e investigue a camada responsável antes de ampliar a mudança.
Plano de validação em produção
Aprove a mudança em uma cópia representativa, prepare uma janela de manutenção e defina sinais de sucesso e reversão. Avise a equipe sobre o que observar, mantenha backup recente e não combine ajustes não relacionados durante a mesma janela.
- Confirme versão, instância e fonte efetiva do valor.
- Preserve configuração e dados antes da alteração.
- Reproduza o caso e anote logs e resultado.
- Altere um item por vez e reinicie quando necessário.
- Repita o teste com conta e cenário representativos.
- Documente conclusão e condição de rollback.
Esse processo não substitui testes específicos do seu plugin, proxy ou provedor. Quando um sintoma apontar para uma integração, use a documentação dessa integração e forneça aos mantenedores logs sanitizados e passos mínimos para reproduzir o problema.
Capture a mensagem exata do cliente
Peça a uma pessoa de teste a hora, versão do cliente, endereço usado e texto integral do erro. “Timed out”, “connection refused”, incompatibilidade de protocolo e whitelist indicam camadas diferentes. Compare o horário com logs do Paper e do proxy. Redija credenciais ou endereços privados antes de compartilhar registros em público.
Ao concluir, compare o resultado com a linha de base, registre versão e horário e mantenha o procedimento de retorno documentado. Um teste reproduzível evita reaplicar a mesma hipótese em produção sem saber se resolveu a causa.
Teste rota direta e rota pública com segurança
Primeiro verifique se o processo backend está online no console; depois confira porta e proxy internamente. A propriedade server-ip é endereço de bind, não substituto do IP externo anunciado. Em rede proxyada, preserve firewall do backend e teste a rota autorizada; não abra a porta pública como atalho de diagnóstico.
Ao concluir, compare o resultado com a linha de base, registre versão e horário e mantenha o procedimento de retorno documentado. Um teste reproduzível evita reaplicar a mesma hipótese em produção sem saber se resolveu a causa.
Diferencie status de disponibilidade
enable-status afeta apresentação e consultas de status, mas a documentação indica que desligar status não impede por si só conexões. Um cliente pode ver offline enquanto a rota ainda aceita login. Verifique login real e logs antes de mexer em firewall. Se a conexão entra e logo cai, investigue autenticação, forwarding, versão e plugins de entrada.
Ao concluir, compare o resultado com a linha de base, registre versão e horário e mantenha o procedimento de retorno documentado. Um teste reproduzível evita reaplicar a mesma hipótese em produção sem saber se resolveu a causa.
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.