A propriedade log-ips em server.properties controla se o próprio servidor registra endereços IP de jogadores nos logs. Paper esclarece que desativá-la não impede plugins de registrar esses endereços. Por isso, privacidade não se resolve alterando uma linha: é preciso saber quais componentes coletam dados, quem pode ler os arquivos e por quanto tempo eles ficam armazenados.

Endereços IP podem auxiliar suporte em caso de abuso, bloqueios e investigação de conexão, mas também são dados que merecem proteção. Defina finalidade, acesso e retenção antes de coletar. A equipe deve conseguir diagnosticar incidentes sem manter logs pessoais para sempre.

Entenda exatamente o escopo de log-ips

A opção afeta os logs gerados pelo servidor Paper para informações de conexão. Ela não garante anonimato nem desativa captura em plugins, proxy, firewall, painel, provedor ou monitoramento. Se um proxy fica na frente, Paper pode registrar o endereço que recebe conforme forwarding e integração; o comportamento precisa ser testado na topologia real.

Faça inventário de Velocity, plugins de login, anticheat, banimento, analytics, Discord e sistemas externos que recebem eventos. Leia a documentação de cada um. Alguns têm configuração própria de log, banco e retenção. Desativar registro no Paper enquanto plugin mantém IP em banco não cumpre a intenção.

Também revise backups: arquivos de log antigos podem ser incluídos em cópias e sobreviver muito além do diretório ativo. Retenção precisa abranger snapshots, exports e cópias baixadas por operadores, não só limpeza automática de logs/.

Escolha uma finalidade legítima e mínima

Para controle de abuso, determine quais incidentes exigem endereços, quem pode investigar e como será feito o descarte. Para suporte de conexão, talvez um registro temporário com rotação seja suficiente. Para estatísticas de comunidade, dados agregados podem responder à pergunta sem guardar IP bruto.

Não colete por precaução sem um processo de uso. Se uma equipe não sabe como buscar, restringir ou apagar dados, a coleta aumenta risco e raramente melhora operação. Escreva uma política curta que explique finalidade, acesso, prazo, exceções de incidente e responsável.

O público deve saber como reportar problema sem postar IP, UUID ou captura de painel em canal aberto. Disponibilize canal privado para denúncia e instrua moderadores a não pedir dados completos publicamente.

Revise plugins e serviços externos

Pesquise configurações de privacidade de cada plugin e serviço. Alguns plugins podem armazenar IP para banimento ou anticheat; outros enviam métricas a um serviço remoto. Verifique termos, localização, retenção e controles de exclusão. Instale apenas extensões confiáveis, pois elas têm amplo acesso ao servidor e aos dados locais.

Em Velocity, identifique se o proxy registra IP e se o backend recebe dados encaminhados. Não assuma que o campo log-ips mascara o conteúdo para o proxy. A configuração de forwarding deve ser segura, e segredos não podem aparecer em logs compartilhados.

Confira dashboards, tickets e alertas. Um moderador pode copiar logs para Discord ou armazenamento pessoal. Limite permissões, use contas individuais e evite acesso amplo a arquivos de conexão. Treine a equipe para ocultar dados antes de pedir ajuda externa.

Configure acesso e retenção de logs

Os logs atuais e compactados ficam no diretório documentado pelo Paper, como logs/latest.log e arquivos rotacionados. Defina retenção por período necessário e automatize a remoção segura das cópias vencidas. Verifique espaço em disco e que limpeza não apaga evidência de incidente ativo antes da preservação autorizada.

Guarde logs de suporte em armazenamento restrito, criptografado quando viável, com controle de acesso. Não use link público de nuvem para compartilhar arquivos. Se um fornecedor precisa receber log, remova IPs, nomes e tokens que não sejam necessários à análise.

Implemente rotação e retenção nas camadas do servidor, proxy, hospedagem, backups e plugins. Um plano de exclusão deve apontar cada cópia. Se houve incidente, preserve apenas o conjunto relevante pelo período necessário à investigação e registre a exceção.

Teste o efeito com tráfego próprio

Altere log-ips em staging, reinicie e faça login com contas de teste. Inspecione logs do Paper e de plugins para descobrir o que continua sendo registrado. Teste do proxy e diretamente numa rede isolada se ambos fazem parte do desenho, sem abrir backend ao público.

Verifique que o diagnóstico operacional continua possível. Um bloqueio ou banimento ainda precisa produzir contexto suficiente para investigar sem necessariamente expor o endereço completo em cada linha. Avalie formas de pseudonimização ou acesso sob demanda se os sistemas permitirem.

Depois, teste a política de retenção: confirme compressão, exclusão, backup e acesso do time. Um trabalho de limpeza que só apaga o arquivo ativo mas deixa cópia no snapshot não conclui a tarefa.

Defina procedimento para incidentes

Quando surge abuso, preserve o trecho necessário em repositório restrito, limite acesso e anote responsável e prazo de revisão. Correlacione somente as fontes necessárias, evitando exportar histórico completo de todos os jogadores. Após resolver, elimine cópias de trabalho e respeite a retenção definida.

Se um dado foi exposto, remova acesso público, revise permissões e informe responsável pelo tratamento conforme políticas da organização. Não publique endereços para “provar” um banimento. Use identificadores internos e evidência sanitizada.

Tenha cuidado com bloqueio por IP compartilhado, VPN e rede móvel. Um IP não identifica uma única pessoa e pode mudar. Combine evidências, como comportamento e registro de sessão, evitando punir grupos inteiros por um endereço sem contexto.

Revise a política periodicamente

Após trocar proxy ou plugin, teste de novo quem registra endereços. Atualizações podem alterar formatos, integração e localização de logs. Mantenha um inventário com nome do sistema, tipo de dado, finalidade, retenção e responsável.

Se o objetivo é reduzir exposição, desligue coleta desnecessária em todas as camadas e reduza quem pode acessar dados remanescentes. Se precisa manter logs para segurança, use prazo claro e monitore acesso. Privacidade e diagnóstico podem coexistir quando a coleta é intencional e restrita.

Consulte as normas aplicáveis e obtenha orientação profissional quando a operação envolver obrigações legais específicas. Este guia trata da configuração técnica do Paper e não substitui avaliação jurídica do tratamento de dados de jogadores.

Crie uma política de acesso por função

Separe quem precisa ver métricas agregadas de quem precisa investigar um incidente individual. Moderadores podem precisar de histórico de chat e punição sem acesso a endereços de rede; administradores de infraestrutura podem precisar de conexão e firewall sem ler conversas. Revise permissões de pastas, painéis, bots e armazenamento de backups.

Use contas nominativas e autenticação forte nos sistemas que guardam logs. Evite conta compartilhada “staff” que impede saber quem consultou ou exportou dados. Revogue acesso quando alguém sai da equipe e mantenha registro mínimo de operações sensíveis.

Ao enviar material a fornecedores, remova campos não necessários. Mantenha original apenas no repositório restrito e registre qual cópia foi compartilhada, com quem e para qual suporte. Isso facilita excluir cópias depois que o ticket termina.

Considere a operação de banimentos

Banimentos por endereço podem atingir várias pessoas que compartilham NAT, rede escolar, operadora móvel ou VPN. Um IP pode mudar e não deve ser tratado como prova única de identidade. Combine comportamento observado, contexto de conta, horário e regras de moderação antes de aplicar punição ampla.

Quando possível, prefira ferramentas de punição que mantenham motivo e expiração sem espalhar endereço em mensagens públicas. A equipe precisa compreender se o banimento está no proxy, Paper, firewall ou plugin, pois cada camada requer método e critério de remoção diferentes.

Tenha procedimento para contestação e falso positivo, especialmente após mudança de provedor, rede ou política de IP. O administrador pode verificar logs sem compartilhar o dado bruto com toda a equipe.

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.