Velocity é o ponto de entrada de uma rede de Minecraft. Jogadores conectam ao proxy, que os encaminha a lobbies ou modos Paper. Essa arquitetura só é segura quando o proxy encaminha identidade corretamente e os servidores backend não podem ser acessados de maneira que contorne o proxy. A configuração básica da conexão, sozinha, não completa essa proteção.

Este checklist aborda a revisão de uma rede controlada por você. Faça mudanças em janela e teste de fora e de dentro da rede. Forwarding, autenticação e firewall formam uma configuração combinada; seguir metade do procedimento pode criar identidades falsas ou indisponibilidade.

Desenhe os caminhos de conexão

Liste endereço público, listener do Velocity, backends Paper, portas, endereços privados, provedores e regras de firewall. Marque quais interfaces aceitam conexão externa. Se backends estão em hospedagens separadas, identifique controles de rede disponíveis em ambas, e o que o provedor expõe por padrão.

Desenho simples evita proteger somente um servidor enquanto outro mundo fica diretamente acessível. Inclua proxies redundantes, lobby de manutenção e serviços de consulta se existirem. Para cada backend, escreva o caminho esperado: jogador para proxy, proxy para Paper. Qualquer caminho externo direto à porta do Paper merece análise.

Escolha um modo único de encaminhamento

Velocity oferece forwarding moderno, legado compatível com BungeeCord e opção BungeeGuard para cenários que precisam da compatibilidade antiga. Não combine formatos no mesmo servidor. A documentação geralmente recomenda modern para redes que suportam clientes atuais, enquanto legado é menos seguro e deve ser acompanhado por medidas adicionais.

Confira a versão suportada e limitações de plugins ou clientes antes de selecionar. Em velocity.toml, a opção de modo precisa corresponder ao backend. No Paper, habilite suporte ao Velocity na configuração apropriada e use os mesmos parâmetros de autenticação indicados pela documentação. Reinicie de forma coordenada após editar.

Proteja o segredo de forwarding moderno

O segredo compartilhado precisa ser igual no proxy e no Paper que confia nele. Trate o arquivo como credencial: restrinja acesso no painel, não o inclua em screenshots públicos nem em repositórios. Não reutilize a chave para um propósito que amplie o impacto de vazamento.

Se a chave foi exposta, planeje rotação dos dois lados no mesmo período. Um valor diferente entre proxy e backend pode impedir conexão legítima. Prepare acesso de console e janela para fazer a troca, reinicie os serviços e valide uma conta de teste. Nunca cole o valor secreto em um ticket público de suporte.

Reforce a autenticação onde a rede termina

Num desenho com proxy, o backend deixa de autenticar a conta diretamente quando a documentação requer que o proxy faça isso. Isso não significa aceitar conexões irrestritas ao backend. O modo offline do Paper precisa ser combinado com o encaminhamento seguro e proteção de rede descritos oficialmente; sozinho ele permite identidade não autenticada a quem consegue alcançá-lo.

Verifique o valor online-mode do proxy e o ajuste correspondente no Paper. As opções devem concordar. Não altere autenticação em um backend exposto antes que regras de firewall e forwarding estejam configuradas; caso contrário, uma pessoa externa pode tentar conectar diretamente e personificar outra conta.

Feche o acesso direto aos backends

Sempre que a infraestrutura permitir, use firewall para aceitar a porta do Paper somente do endereço do proxy. Em hosting compartilhado, confira controles de ACL, allowlist ou rede privada disponibilizados pelo provedor. Uma porta diferente ou nome de host obscuro não substitui controle de origem.

Revise todos os endereços públicos do provedor e eventuais portas secundárias. Teste do lado de fora que backend não aceita conexão direta, e por dentro que Velocity consegue conectar. Não abra a instância aos jogadores durante um intervalo entre desligar autenticação e aplicar a regra de acesso. Se os recursos do hosting não permitirem isolamento, a arquitetura tem um risco que precisa de mitigação oferecida pelo próprio fornecedor.

Audite arquivos e modos antigos

Procure configuração legada remanescente como encaminhamento BungeeCord habilitado ao mesmo tempo que Velocity moderno. Verifique plugins de autenticação, proxy ou protocolo que mudam UUID, endereço e skins. Desligue opções antigas conforme o fluxo oficial e confirme após a reinicialização que foram lidas pelo backend.

Tenha uma lista de cada Paper: flags do proxy, segredo correspondente, modo online e regra de firewall. Uma rede pode incluir dezenas de backends, e consistência manual fica sujeita a erro. O registro deve armazenar a localização da credencial, não o conteúdo da credencial.

Teste identidade e disponibilidade

Faça primeiro uma conexão válida passando pelo proxy. Confirme UUID, skin, permissões, banimentos e endereço conforme o comportamento esperado. Depois tente alcançar a porta do backend a partir de uma origem externa controlada: a conexão deve ser rejeitada pela camada de rede. Execute esse teste somente em servidores que você administra.

Simule falha de segredo numa cópia para entender a mensagem e a recuperação. Uma chave incorreta deve levar a conexão a falhar, não a aceitar identidade desprotegida. Observe console e firewall para confirmar qual camada bloqueou. Teste cada backend e rota alternativa, não apenas o lobby principal.

Prepare recuperação e monitoração

Faça backup dos arquivos e registre o estado atual antes de mudanças. Tenha console acessível mesmo quando jogadores não conseguem entrar. Anote ordem e responsabilidade de reinício; uma configuração parcialmente aplicada pode deixar um modo acessível e outro fora do ar.

Monitore falhas de conexão, mudanças no endereço encaminhado e tentativas de acessar diretamente backends. Configure alertas com parcimônia e proteja logs, porque eles podem revelar endereços e padrões de acesso. Após atualização de Paper ou Velocity, confira novamente nomes de opções, modos aceitos e documentação da versão.

Documente as limitações da hospedagem

Se não é possível restringir origem pelo firewall, peça ao provedor uma configuração de rede privada ou regra de acesso ao backend. Uma chave de forwarding protege dados e identidade entre componentes, mas a disponibilidade de uma porta pública ainda permite conexão direta na camada de transporte; as defesas são complementares.

Não publique detalhes de endereço, portas internas ou credenciais em canais abertos. Ao pedir suporte, remova o segredo dos trechos de configuração e descreva o modo selecionado e o sintoma. Compartilhe apenas o mínimo necessário com a equipe autorizada.

Siga a documentação de Velocity para proteger servidores, configurar forwarding de jogadores e revisar o arquivo de início. As instruções mostram quais opções pertencem ao proxy e quais pertencem ao Paper; confirme os valores compatíveis com suas versões.

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.