A opção enable-query em server.properties habilita o listener do protocolo GameSpy4 Query, usado por algumas ferramentas para obter informações do servidor. A consulta usa a porta definida por query.port. Ela é diferente do status básico que o cliente consulta para exibir um servidor na lista; não ative Query supondo que ela seja obrigatória para qualquer lista ou painel.

Como todo serviço de rede adicional, Query aumenta a superfície exposta e pode divulgar informações dependendo da implementação e ferramenta. Ative somente quando uma integração identificada precisa do protocolo, limite a porta à origem necessária e teste quais dados ficam acessíveis.

Diferencie Query do status Minecraft

enable-status controla status/list ping e também se o servidor aparece como online na lista. Paper diz que, se desativado, jogadores ainda podem conectar embora o servidor pareça offline. enable-query ativa um listener separado baseado no protocolo GameSpy4. Ferramentas diferentes podem usar um ou outro caminho.

Antes de abrir Query, leia a documentação do monitor, diretório ou painel. Pergunte qual host e porta ele consulta e se existe alternativa por API autenticada. Não exponha Query “para garantir compatibilidade” se nenhum componente depende dela.

Em uma rede com proxy, verifique onde o status público é servido: backend Paper ou proxy Velocity. A ativação no backend não implica que o proxy publicará os mesmos dados. Teste do ponto de vista externo e consulte as configurações de status do proxy.

Avalie dados e exposição

Descubra que informações a implementação do servidor e a ferramenta retornam. Não suponha que uma consulta exponha apenas número de jogadores; confira descrição, versão e campos disponíveis na versão atual. Diretórios de servidores podem armazenar respostas e publicá-las para terceiros.

Se a população ou nomes devem ser privados, confirme que o protocolo e a integração respeitam a intenção. hide-online-players trata a lista enviada no status, mas não necessariamente altera Query. Teste as interfaces separadamente e não prometa privacidade com base em uma única propriedade.

Respeite regras de privacidade e retenção de cada serviço. Se uma ferramenta registra consultas ou nomes, limite o acesso ao painel e informe a equipe. Dados de conexão podem se tornar identificáveis quando correlacionados com outros registros.

Habilite com porta e firewall controlados

Faça backup de server.properties, habilite Query somente na instância necessária e defina query.port compatível com regra de rede. Confirme que a porta está disponível. Não abra todas as portas do host; permita somente origem e protocolo exigidos quando a infraestrutura suportar ACL restritiva.

Em hospedagem compartilhada, pergunte ao provedor como reservar a porta e isolar clientes. Uma porta liberada para um servidor pode pertencer a outro serviço. Não altere firewall global sem entender os demais aplicativos na máquina.

Em proxy, mantenha backends privados. Uma Query pública ao backend pode expor a existência de instâncias internas e ignorar a camada de apresentação do proxy. Avalie se o monitor deve consultar o proxy ou uma rede privada de gerenciamento.

Teste a integração antes de produção

Use staging com dados de teste, habilite a opção e consulte da origem exata que a ferramenta usará. Confirme resposta, campos, timeout, firewall e comportamento quando o serviço está offline. Não use endpoint de produção para teste externo em massa.

Verifique também o que acontece com clientes: status normal, MOTD, contagem, lista, ping e login. Query deve coexistir com as conexões do jogo sem atrapalhar. Teste restart e mudança de porta, e confirme que monitoramento não gera alerta falso ao falhar em um único ciclo.

Se uma integração não funciona, valide host, porta UDP/TCP segundo a documentação da ferramenta, firewall e versão antes de abrir acesso amplo. Erros de Query podem vir de NAT ou porta incorreta e não de servidor indisponível.

Mantenha os privilégios mínimos

Query não é console nem RCON, mas acesso de rede ainda deve ser limitado. Não configure uma porta de administração na mesma ACL aberta a todos. Separe monitoramento público de administração e proteja credenciais de painéis. Monitores devem usar contas próprias e somente leitura sempre que possível.

Se não consegue limitar origem em hospedagem compartilhada, avalie se a ferramenta realmente é essencial. Pergunte ao provedor por endpoint monitorável interno, firewall de aplicação ou proxy de métricas. Mantenha software atualizado e consulte recomendações oficiais.

Não use varredura de portas de terceiros ou diretórios como teste. Faça verificações no seu próprio domínio e instância, respeitando limites. Monitore logs e banda quando habilitar qualquer listener adicional.

Desative e revise quando não houver uso

Se nenhum componente depende de Query, deixe-a desativada. Remova regra de firewall que ficou órfã e atualize inventário de portas. Revisões periódicas detectam serviços auxiliares expostos por engano após migrações.

Se ferramenta deixa de funcionar, verifique mudança de versão, protocolo ou porta antes de reativar globalmente. Atualize a integração, limite seu acesso e registre o motivo, responsável e data para revisão.

O critério é simples: saiba qual sistema precisa consultar, quais dados ele recebe e por que deve alcançar aquela porta. Com isso documentado e validado, Query pode servir ao monitoramento sem virar um listener público esquecido.

Planeje descoberta e proteção juntas

Se Query alimenta uma página de status pública, verifique se ela precisa listar nomes, contagem ou apenas disponibilidade. Configure a ferramenta para mostrar informação mínima e evite duplicar os dados num serviço sem necessidade. Se o objetivo é monitorar uptime, um health check privado pode ser suficiente.

Confirme se o serviço responde na interface correta e se a porta está exposta somente ao consumidor esperado. Faça uma checagem externa controlada, registre o resultado e remova temporariamente a regra para confirmar que o firewall bloqueia tráfego não autorizado. Não dependa do fato de a porta ser pouco conhecida.

Se hospeda em painel compartilhado, solicite confirmação de que Query não permite consultar outros containers e que regras de firewall são aplicadas no escopo certo. A responsabilidade pode estar dividida entre operador do servidor e provedor.

Inclua Query no inventário de superfície

Registre porta, protocolo, endereço de bind, finalidade, integração consumidora e pessoa responsável. Indique se a consulta é pública ou restrita e qual dado pode aparecer. Esse mapa ajuda a detectar listener esquecido quando a ferramenta é substituída ou o servidor migra de host.

Ao trocar a porta do jogo, não presuma que a porta Query mudou também. Revise query.port, firewall, NAT, monitor e documentação. Faça a mudança em janela de manutenção e confirme os dois caminhos separadamente.

Se uma auditoria de segurança encontra Query inesperado, desligue o listener quando possível, preserve logs e descubra qual processo ou painel ativou a opção. Atualize inventário e remova regra de rede depois de testar que nenhum serviço legítimo depende dela.

Melhore alertas sem expor mais dados

Um monitor pode verificar que a porta responde e ainda evitar guardar a lista de jogadores. Configure retenção mínima e proteja credenciais de API. Se uma plataforma só funciona armazenando lista de nomes, avalie se isso é necessário para o objetivo e informe a comunidade.

Estabeleça alertas com tolerância para uma falha isolada, mas sem ocultar queda real. Compare status do jogo, proxy e Query para distinguir backend fora do ar de integração indisponível. Uma dependência crítica deve ter responsável e canal de manutenção.

Revise os alertas após troca de proxy, host ou monitor. O serviço que consulta pode mudar IP de origem e uma regra antiga pode ficar ampla ou bloquear silenciosamente a conexão legítima.

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.