A propriedade spawn-protection em server.properties controla a área inicial protegida para jogadores sem permissão de operador, conforme as regras do servidor Vanilla/Paper. Paper documenta que o valor define o lado da região pela fórmula 2x + 1; por exemplo, valor 16 corresponde a lado 33. Definir 0 desativa essa proteção. A configuração também depende de existir pelo menos um operador.

Essa proteção simples ajuda a evitar que jogadores comuns alterem o centro do spawn, mas não substitui sistema de regiões, claims ou regras do mundo. Para proteger lobby, terrenos e arenas, use um plugin adequado com limites e permissões testados.

Identifique o spawn que o servidor usa

O ponto de spawn do mundo e o nome configurado em level-name influenciam a área observada. Em redes com Multiverse ou vários mundos, a proteção Vanilla pode não representar todos os pontos de entrada. Teste no mundo correto e confirme onde o jogador aparece depois de conectar.

O campo costuma ser medido em torno do centro do spawn com tamanho derivado, não como um raio simples de distância. Verifique a fórmula na documentação da versão e marque os cantos num mundo de teste para entender a dimensão. A proteção não é um quadrado configurável por jogador ou por claim.

Se o ponto de spawn mudou recentemente, reveja a área protegida. Uma configuração que antes cobria praça central pode agora proteger terreno vazio e deixar construções novas expostas. Registre coordenadas e mudanças para a equipe.

Confira o efeito de operadores

Paper observa que precisa haver pelo menos um operador para a proteção entrar em funcionamento. Operadores e outros comandos administrativos podem contornar proteções. Não conceda OP amplo a equipe temporária só para resolver acesso; use permissões específicas em plugins quando apropriado.

Teste com uma conta normal sem OP, uma conta de operador e permissões de plugin. Confirme colocação, quebra, interação com baús, botões, alavancas, placas, entidades e acesso a comandos. A proteção vanilla pode ter escopo diferente do plugin de região ou do sistema de spawn.

Se um plugin de lobby declara proteção independente, descubra qual camada está bloqueando. Dois sistemas sobrepostos podem permitir ação em um mundo e negar em outro. Mantenha documentação da regra final que o jogador encontra.

Escolha tamanho conforme o uso

Uma praça pequena pode exigir proteção curta e uma região de boas-vindas maior pode precisar de plugin dedicado. Defina fronteiras com base em construções, rotas de jogadores, decoração e portais. Não escolha apenas um número grande “por segurança”, porque isso pode bloquear equipe, eventos e construção legítima em área excessiva.

Se quer proteger uma região irregular, casas de staff ou vários pontos, a proteção quadrada em torno do spawn é limitada. Use WorldGuard ou sistema adequado, com prioridade, flags e permissões. Teste sobreposição e bypass para evitar que um cargo de jogador ganhe mais acesso do que deveria.

Em minigames, reinício de mapas ou mundos temporários, coordene proteção com o ciclo do mapa. Configuração global pode sobreviver ao evento e afetar outro mundo. Faça perfil por mundo quando Paper e plugins permitirem.

Ative com teste de permissão

Antes de mudar, faça backup de server.properties e registre o valor atual. Edite no servidor correto, reinicie se necessário e confirme o campo depois. Entre com conta de teste sem OP a partir de outro jogador ou modo de jogo e tente ações dentro e fora da área.

Confira se a equipe pode executar suas tarefas por permissões deliberadas, sem distribuir OP como workaround. Se proteção falhar, verifique ponto de spawn, operador, plugin de permissões e sobreposição de regiões. Não conclua que a configuração está ativa só porque o valor está escrito no arquivo.

Observe console e logs por erros de configuração, e faça teste depois de reiniciar. Algumas proteções dependem de plugin carregado ou regra de mundo e podem perder estado se a instância iniciou em outro diretório.

Combine proteção com experiência acolhedora

O spawn é muitas vezes a primeira experiência da pessoa no servidor. Proteja builds e NPCs, mas forneça placas, tutoriais, acesso a portais e comandos de ajuda. Uma proteção invisível que impede interação necessária pode parecer bug ou ser usada para prender jogadores.

Forneça mensagem clara de bloqueio quando plugin permitir. Teste sinais, baús informativos, NPCs e comandos de tutorial com conta comum. Reveja contraste e acessibilidade das placas e menus, além de traduções usadas pela comunidade.

Planeje exceções para eventos sem abrir uma brecha permanente. Use permissões temporárias ou alterações registradas, com data e responsável. Depois do evento, remova exceção e teste o comportamento normal.

Audite equipe e recuperação

Revise operadores e grupos periodicamente. Um atacante com OP pode contornar a proteção; logo, a área protegida não compensa credenciais fracas. Proteja conta de painel, configure autenticação forte e guarde backups antes de mudanças de spawn.

Use backups e CoreProtect ou ferramenta adequada para recuperação de alterações, reconhecendo que logs de bloco não substituem cópia completa. Teste restauração em staging e valide mundo e plugins. Se uma alteração indevida ocorrer, limite acesso, preserve logs e investigue como a conta obteve permissão.

Registre fronteira pretendida, valor, mundo, plugins de proteção e resultado do teste. Quando mover o spawn ou atualizar Paper, repita o teste de permissões; mudanças pequenas podem deslocar toda a área protegida.

Resolva conflitos entre proteção nativa e plugins

Se jogador consegue quebrar um bloco protegido, faça uma reprodução em coordenada conhecida com conta comum. Verifique primeiro se o bloqueio é spawn-protection, WorldGuard, claim, modo de jogo ou permissão. Teste temporariamente em mundo isolado sem plugins e compare com produção; remover extensões em produção pode causar perda de dados ou permitir acesso indevido.

Proteção nativa é vinculada ao spawn e tem escopo limitado. WorldGuard usa regiões e prioridades, e claims de jogadores têm regras próprias. Sobreposição pode fazer uma flag permitir algo em uma região interna mesmo que a região externa bloqueie. Confira a configuração exata e documentação antes de mudar prioridades.

Mantenha uma tabela simples com mundo, região, regra, cargo que tem bypass e pessoa responsável. Em redes maiores, isso ajuda a explicar qual controle prevalece e impede que equipe conceda OP global para contornar um problema localizado.

Use permissões de equipe com menor privilégio

Separar construção, moderação e administração reduz erros. Um construtor pode precisar editar spawn durante evento, mas não precisa reiniciar servidor nem alterar whitelist. Use grupos e permissões específicas do plugin quando a plataforma oferece esses controles.

Audite quem tem OP e bypass de região. Remova acessos temporários depois de concluir o projeto. Revise logs e backups se uma construção protegida foi alterada sem autorização, e recupere apenas o trecho necessário quando a ferramenta permitir.

Instrua a equipe sobre como solicitar acesso e como registrar exceções. Mudança emergencial deve ter motivo, escopo e horário de expiração para não enfraquecer a proteção permanentemente.

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.