A opção prevent-proxy-connections em server.properties verifica se o ISP ou ASN observado pelo servidor difere do enviado pelo serviço de autenticação do Minecraft; quando difere, o jogador não pode entrar, conforme a descrição da propriedade. Apesar do nome, isso não configura um proxy reverso, não restringe acesso ao backend e não substitui proteção de rede.

Essa distinção importa em uma rede com Velocity. Um jogador se conecta ao proxy, que autentica e encaminha as informações. O endereço e o caminho vistos pelo backend podem não corresponder ao cenário em que essa verificação espera operar. Antes de ativá-la, teste o fluxo de login e leia as instruções de forwarding da versão instalada.

Entenda o campo e seus limites

A propriedade é voltada a uma comparação feita durante conexão/autenticação, não à identificação de um serviço de proxy pelo nome. O resultado depende de metadados de rede e autenticação, que podem variar entre provedores, operadoras móveis, VPNs legítimas, NAT, redes corporativas e roteamento internacional.

Ela não esconde o servidor, não bloqueia ataques, não garante que conexões só chegam por Velocity e não autentica o backend. O nome leva a uma suposição comum, mas a segurança de uma rede proxy depende de firewall, binding, forwarding seguro e configuração do backend.

Uma regra baseada em diferença de ISP/ASN pode rejeitar conexões legítimas de jogadores que usam VPN por privacidade ou conectam de redes com roteamento incomum. Se isso ocorrer, o suporte deve conseguir explicar como pedir diagnóstico e qual informação mínima fornecer.

Verifique a arquitetura antes de aplicar

Desenhe o fluxo: cliente para endereço público do Velocity, autenticação no proxy, encaminhamento ao Paper backend e conexão de retorno. Anote onde termina cada conexão, modo de autenticação, versão do proxy e opções do servidor. Em rede com vários proxies, documente cada rota possível.

Para modern forwarding, Velocity e Paper precisam concordar no modo, o segredo deve corresponder e permanecer privado, e a configuração de online-mode é diferente entre proxy e backend. Siga a documentação oficial de forwarding. Não misture modern, legacy e BungeeGuard; Velocity documenta que somente um formato deve estar ativo por vez.

Proteja os backends para que somente o proxy possa conectar. A documentação recomenda firewall; quando proxy e backend compartilham máquina dedicada, binding em localhost pode ser opção. Modern forwarding não substitui firewall. Em hospedagem compartilhada, coordene regras com o provedor e não bloqueie endereços compartilhados sem confirmação.

Teste compatibilidade sem excluir jogadores

Use staging com a mesma topologia e autenticação. Teste conexão direta bloqueada, conexão via proxy autorizada, conta legítima, VPN de teste autorizada e jogador de rede móvel, sempre sem expor o backend à internet pública. Registre mensagem exata e logs do proxy e do Paper.

Não ative em produção durante um evento para descobrir a compatibilidade. Se a configuração já estiver ativa e alguém legítimo for rejeitado, valide qual processo autenticou o jogador, qual ASN foi informado e se o login passou pelo proxy esperado. Evite pedir que o usuário envie dados sensíveis em canais públicos.

Também teste fallback, reconexões, troca de backend e manutenção. Um jogador que entra no lobby mas não no survival pode indicar configuração desigual entre servidores. Se apenas algumas regiões são afetadas, compare operadoras e rotas antes de atribuir o problema à conta.

Escolha controles adequados para o objetivo

Se o objetivo é impedir acesso direto ao backend, aplique firewall ou bind adequado. Se é impedir falsificação de identidade, use forwarding moderno compatível e segredo forte. Se é mitigar flood, use proteção de rede, limites de conexão, proxy e serviço anti-DDoS do provedor. São ameaças diferentes e requerem controles diferentes.

O endereço do jogador também é dado pessoal ou sensível em muitos contextos operacionais. Limite quem acessa logs, estabeleça retenção e remova detalhes ao abrir tickets. Não use configuração de proxy como justificativa para registrar ou compartilhar mais informação do que o necessário.

Em servidores independentes sem proxy, avalie o campo conforme a documentação e sua população. Se a maioria acessa por redes móveis, VPNs ou provedores que fazem roteamento particular, o custo de falsos positivos pode superar eventual benefício. Faça decisão informada e mantenha canal de exceção.

Valide login e observabilidade

Durante o teste, confirme UUID e perfil corretos, skins, endereço, permissões e troca de servidores. Se o login falha, identifique em que etapa: autenticação, handshake, forwarding, firewall, backend ou plugin de login. Uma mensagem genérica de desconexão não localiza a causa sozinha.

Monitore taxa de login, rejeições por horário, país ou provedor de rede se isso for necessário e apropriado. Não transforme monitoramento numa coleta indiscriminada; agregue dados quando possível e informe a equipe sobre acesso e retenção.

Após mudança, tenha rollback e compare com o estado anterior. Se uma comunidade relata bloqueio, desative temporariamente o controle em staging ou reverta a opção enquanto investiga arquitetura e evidência. Não enfraqueça outras camadas que já protegem a rede.

Mantenha documentação e plano de suporte

Registre valor, motivo, topologia, modo de forwarding, compatibilidade de clientes e resultados. Guarde a configuração sem segredos e uma versão confidencial separada. Rotacione o segredo se ele for exposto, atualize todos os lados de forma coordenada e valide em janela de manutenção.

Treine a equipe para distinguir “proxy não aceito” de “backend exposto” e “falsificação de identidade”. A clareza evita correções arriscadas no meio de uma indisponibilidade. Mantenha os guias oficiais atuais junto ao runbook, pois caminhos e nomes de configuração variam conforme versão.

Uma opção chamada prevent-proxy-connections não deve ser confundida com a arquitetura de proxy do servidor. A proteção real depende de um fluxo coerente, backends privados e forwarding autenticado que funcione para os jogadores legítimos que você atende.

Documente exceções sem criar uma brecha

Se um jogador legítimo não consegue conectar por causa de uma rota ou VPN, não divulgue um método de contorno permanente sem entender o risco. Colete apenas a mensagem e os horários necessários, confirme o caminho usado e verifique os registros do proxy. Se uma exceção temporária for inevitável, restrinja escopo e prazo, aprove internamente e remova após o teste.

Não resolva falso positivo abrindo o backend à internet, desativando autenticação ou compartilhando segredo de forwarding. Procure o fornecedor de hospedagem e pergunte como a verificação de ISP/ASN interage com a topologia. Uma mudança de rede pode impactar todos os jogadores no mesmo provedor e precisa ser testada antes de anúncio.

Registre a decisão com data de revisão, versão, casos de teste e impacto observado. Segurança operacional exige saber não apenas qual controle está ativo, mas também quem pode alterá-lo e como detectar se deixou de funcionar.

Checklist antes de ativar

  • Identifique versão do Paper, modo de autenticação e ponto em que o jogador é autenticado.
  • Confirme forwarding e segredo apenas em canais protegidos; não os inclua em logs de suporte.
  • Restrinja portas de backend ao proxy por firewall ou rede privada.
  • Teste contas de provedores distintos, conexões móveis e VPNs legítimas em staging.
  • Garanta canal de suporte e rollback para reduzir falsos positivos rapidamente.

Se não consegue responder a esses itens, primeiro documente e valide a arquitetura. Ativar uma opção pouco compreendida pode prejudicar jogadores sem resolver a ameaça que motivou a mudança.

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.