Um proxy Velocity fornece o endereço de entrada e encaminha jogadores para um ou mais servidores de jogo. Em uma rede Paper, esse desenho precisa preservar a identidade dos jogadores e controlar quem pode alcançar cada servidor de destino. Apenas apontar o domínio para o proxy não protege uma porta de Paper que continua acessível diretamente.

Este guia descreve o encaminhamento moderno do Velocity com Paper. Os arquivos e nomes de opções mudam entre versões. Antes de aplicar qualquer configuração, confira os manuais das versões efetivamente instaladas e faça a mudança primeiro em uma cópia restrita. O segredo de encaminhamento é uma credencial e deve ser tratado como tal.

Planeje o caminho da conexão

Desenhe o trajeto que o jogador deve percorrer: cliente, endereço público, proxy e servidor Paper de destino. Liste endereços e portas de cada etapa, identificando quais precisam aceitar conexões externas. Em uma instalação na mesma máquina, os servidores de destino podem escutar em loopback. Em hosts separados, restrinja a origem por regras de rede quando o provedor permitir.

Confirme quem autentica o jogador. No modo com proxy, o Velocity autentica a conexão pública e encaminha os dados para Paper. Isso altera o comportamento esperado de online-mode no backend. Nunca copie a configuração de autenticação isolada de Paper para uma rede com proxy sem ler as instruções completas de encaminhamento.

Escolha um formato de encaminhamento suportado pelo cliente e pelos componentes instalados. Para clientes modernos suportados, a documentação indica o modo moderno. Compatibilidade com versões antigas pode exigir outro protocolo, com requisitos de proteção adicionais. Não tente combinar os modos como se fossem camadas independentes.

Crie e proteja o segredo no Velocity

Na primeira inicialização, Velocity prepara seus arquivos, incluindo a configuração e o arquivo de segredo de encaminhamento. Restringa o acesso a esses arquivos no painel. Gere ou use o segredo segundo a instalação atual e forneça o mesmo valor ao backend através da configuração segura, sem incluí-lo em uma página pública ou repositório.

O segredo não é o endereço do servidor, uma senha dos jogadores ou uma opção visual. Quem obtiver o valor e tiver acesso de rede suficiente pode tentar falsificar o tráfego de proxy. Use um segredo diferente de qualquer senha já usada em painéis, bancos ou contas pessoais.

Se for necessário trocar o segredo, agende a mudança em conjunto no Velocity e nos servidores Paper. Um valor diferente em cada lado causa falha de conexão. Atualize todos os backends ligados ao mesmo proxy e remova cópias antigas dos locais de acesso que já não deveriam mantê-las.

Configure Paper para aceitar Velocity

Pare cada servidor de destino antes de editar as configurações. Nas versões atuais do Paper, siga o caminho para suporte nativo em config/paper-global.yml. Ative o encaminhamento Velocity, informe o segredo correspondente e alinhe a opção de autenticação do proxy ao valor esperado pelo Paper. Desative o encaminhamento BungeeCord legado caso tenha sido ativado anteriormente.

O nome e a localização das opções podem variar nas versões anteriores. Uma instalação antiga pode manter opções de suporte ao Velocity em outro arquivo. Consulte o guia oficial de encaminhamento para a versão do Paper que você usa em vez de criar chaves novas em YAML e presumir que o processo as leu.

Confira também server.properties, spigot.yml e o endereço e porta internos registrados no velocity.toml. Não deixe uma configuração Bungee ativa junto com a moderna. Faça uma lista com o valor esperado de cada opção por servidor para evitar que o lobby e o survival terminem com comportamentos diferentes.

Reforce a rede entre o proxy e os backends

O encaminhamento moderno protege dados de identidade, mas não substitui regras de firewall. A documentação do Velocity recomenda proteger também o acesso de rede aos servidores. Se proxy e Paper estiverem no mesmo host exclusivo, configurar o endereço de escuta interno para loopback pode impedir conexões de outras máquinas.

Para servidores em máquinas separadas, permita a porta interna somente a partir do IP do proxy, quando a infraestrutura possibilitar isso. Hospedagens compartilhadas podem exigir auxílio do provedor para restringir acesso. Confirme a topologia e a forma como o tráfego passa entre as máquinas, em vez de assumir que dois servidores no mesmo painel compartilham rede privada.

Verifique o endereço público e as portas expostas. O cliente deve alcançar a entrada pública planejada; portas administrativas, RCON e endpoints internos não devem ficar acessíveis sem necessidade. Para uma análise mais ampla, consulte o guia de portas do servidor.

Aplique em uma cópia e teste cada destino

  1. Faça uma cópia das configurações atuais e anote a topologia e os endereços.
  2. Crie uma instância de teste do proxy e um backend Paper separado, sem banco de produção.
  3. Configure a mesma forma de encaminhamento e o mesmo segredo nas duas extremidades.
  4. Inicie o backend e depois o proxy; leia ambos os consoles do início ao fim.
  5. Conecte pela entrada pública de teste e confirme nome, UUID e skin esperados.
  6. Se houver vários backends, repita a entrada e a troca de servidor em cada um.
  7. Tente acessar diretamente o backend dentro do teste e confirme que a rede recusa o caminho indevido.

Faça os testes com uma conta de jogador sem OP e confirme os recursos que dependem de identidade, como whitelist e permissões. O fato de uma conta administrativa entrar não comprova que o encaminhamento de usuários comuns está correto.

Investigue os sintomas por camada

Se o Velocity não alcançar o Paper, confirme o endereço, a porta e a regra de firewall entre eles. Uma rejeição por segredo costuma apontar para valores diferentes ou modo de encaminhamento incompatível. Não troque para o modo legado como atalho sem entender sua exposição.

Se os jogadores entram com UUID ou skin inesperados, confira quem autentica, os modos configurados e se outro proxy está modificando a rota. Revise os arquivos completos e o console. A informação encaminhada precisa fazer sentido em todos os saltos; ajustar só um dos servidores não conclui a investigação.

Se o acesso direto ao backend continua possível, reveja o bind, as portas públicas e as regras na rede do provedor. Encaminhamento moderno dificulta falsificação de identidade, mas uma origem pública ainda pode ser submetida a conexão, ruído ou ataques que a política de rede deveria filtrar.

Planeje a migração de encaminhamento

Mudar de protocolo afeta todas as instâncias conectadas ao proxy. Registre versões suportadas e as exceções dos clientes antigos antes da alteração. Se uma plataforma de mod não suportar o formato escolhido, identifique um componente compatível segundo a documentação. Se não houver caminho seguro e suportado, registre a limitação antes de agendar a mudança.

Não misture uma mudança de forwarding com uma atualização grande do mundo. Teste o fluxo separado; isso torna mais fácil decidir se o problema veio da rede ou do software de jogo. Mantenha configuração anterior e cópia de segurança até que o fluxo normal tenha sido verificado em produção.

Libere o proxy com um registro de configuração

Antes de abrir a rede, confira que apenas o proxy é publicado, todos os backends usam a configuração pretendida e o segredo não aparece em logs compartilhados. Mantenha acesso individual ao painel e anote quem pode alterar o segredo ou as regras de firewall.

Depois de atualizar qualquer componente, repita um teste de entrada e de troca de backend. A introdução a proxies explica a arquitetura; este procedimento trata da proteção da conexão real. Armazene um diagrama simples junto da documentação operacional para a próxima pessoa que precisar investigar uma falha.

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.