Un servidor dedicado de Minecraft sin whitelist ni protección anti-grief es una invitación abierta a trolls, griefers y bots. La whitelist controla quién entra; el anti-grief controla lo que puede hacer quien ya pasó esa puerta. Ambas capas son obligatorias en 2026: por separado se complementan, juntas convierten un servidor público vulnerable en una comunidad cerrada que solo ven tus jugadores.
Lo esencial antes de empezar:
- Whitelist: filtra quién puede unirse al servidor (solo jugadores aprobados)
- Anti-grief: limita lo que cualquier jugador aprobado puede romper, colocar o saquear
- Stack mínimo 2026: LuckPerms + WorldGuard + CoreProtect + EssentialsX + anti-cheat actualizado
- Backup obligatorio antes de tocar server.properties o permissions.yml
- Hosting recomendado: panel intuitivo y soporte 24/7 para aplicar cambios sin tirar el server, como RDSNode Minecraft Hosting
Servidor Minecraft con whitelist y anti-grief 2026: guía paso a paso
Si alguna vez entraste a tu servidor y encontraste tu base con crateres, cofres vacíos y bloques de obsidiana por todas partes, sabes exactamente por qué importa este artículo. La mayoría de las guías online se quedan en “actíva la whitelist en server.properties y listo”, pero eso es solo la mitad del trabajo. Una whitelist sin anti-grief sigue dejando a tus propios jugadores autorizados destruir builds con TNT, saquear cofres y gripar el server con exploits.
Esta guía cubre el flujo completo para 2026: whitelist en Java 1.21.x (con mención a Bedrock y crossplay), capas de anti-grief con plugins profesionales, permisos granulares con LuckPerms, configuración de WorldGuard, y el orden exacto para hacerlo sin romper tu mundo en el proceso.
Qué cubren realmente la whitelist y el anti-grief
Antes de entrar en comandos, conviene separar bien qué resuelve cada capa. Son cosas distintas y se complementan:
| Capa | Qué previene | Limitaciones |
|---|---|---|
| Whitelist | Acceso de jugadores no autorizados, bots, trolls aleatorios | No controla qué hacen los jugadores autorizados |
| Anti-grief (WorldGuard/CoreProtect) | Destrucción de builds, robos en cofres, explosiones masivas, spam de redstone | Requiere configuración fina y mantenimiento |
| Permisos (LuckPerms) | Escalación de privilegios, ops accidentales, abuso de comandos | No evita grief por sí sola, solo organiza quién puede aplicar cambios |
| Anti-cheat | Movimientos imposibles, kill-aura, fly hacks, exploits del Mace/Breeze | Tasa de falsos positivos si está mal calibrado |
| Backups automáticos | Pérdida total del mundo por crash o raid | No previene el incidente, solo te ayuda a recuperarte |
La suma de todas estas capas es lo que hace un servidor “a prueba de griefers” de verdad. Quitar una sola capa (sobre todo backups) es comprometer el resultado.
Requisitos antes de tocar nada
Antes de empezar, asegúrate de tener lo siguiente resuelto:
- Acceso al panel o a la consola del servidor: necesitas poder editar server.properties, recargar plugins y reiniciar el server.
- Permisos de operador (OP) en Minecraft Java: solo OPs pueden usar /whitelist. Si no tienes OP, no puedes activar la whitelist de forma efectiva.
- Backup completo del mundo: Worlds/world, plugins, configs. Si rompes algo, vuelves en segundos.
- Stack de plugins descargados: LuckPerms, WorldGuard, WorldEdit, EssentialsX, CoreProtect, Vault. Todos en versión compatible con tu versión del server (1.21.x).
- Hosting con panel intuitivo y consola en tiempo real: para iterar configuraciones sin perder el server. RDSNode ofrece panel propio pensado para esto: instalar plugins, editar configs, ver logs y reiniciar sin tocar SSH.
Parte 1: Configurar la whitelist en Java 1.21.x
La whitelist es una feature nativa de Minecraft, no un plugin. Funciona en vanilla, Spigot, Paper, Forge, Fabric, Purpur: cualquier servidor Java la soporta. Aquí los pasos exactos.
Paso 1: Activar la whitelist
Tienes tres formas de hacerlo, todas equivalentes:
Desde la consola del server o panel de control:
whitelist on
Editando server.properties directamente:
white-list=true
Desde el chat si eres operador:
/whitelist on
El archivo whitelist.json se crea automáticamente al activar la whitelist.
Paso 2: Añadir jugadores
Por cada jugador que quieras autorizar:
/whitelist add NombreJugador
El sistema almacena el UUID del jugador además del nombre, así que un cambio de nombre en Mojang no rompe la whitelist. Para ver la lista actual:
/whitelist list
Paso 3: Recargar si editaste manualmente
Si modificas whitelist.json directamente desde el panel de archivos, recarga con:
/whitelist reload
Paso 4: Mensaje para jugadores no autorizados
Edita server.properties:
white-list=true motd=Servidor privado. Solicita acceso en discord.ejemplo.com
Cuando un jugador sin whitelist intente entrar, verá ese mensaje en la pantalla de conexión. Úsalo como CTA hacia tu canal de aprobación.
Comandos útiles de whitelist (cheat-sheet)
| Comando | Función |
|---|---|
whitelist on |
Activa la whitelist |
whitelist off |
Desactiva la whitelist |
whitelist add <jugador> |
Añade un jugador |
whitelist remove <jugador> |
Quita un jugador |
whitelist list |
Lista todos los autorizados |
whitelist reload |
Recarga la lista desde el archivo |
Parte 2: Whitelist para Bedrock y crossplay
Si tu servidor también acepta jugadores Bedrock (consolas, mobile, Windows 10/11), el flujo es ligeramente distinto. Para crossplay con Geyser o Floodgate, los jugadores Bedrock deben entrar al server una vez antes de ser añadidos.
Bedrock (sin crossplay)
- En server.properties:
allow-list=true - Desde consola:
allowlist add NombreJugador - El archivo generado se llama
allowlist.jsonen lugar de whitelist.json
Crossplay (Geyser/Floodgate)
- El jugador Bedrock entra una vez para registrar su nombre (prefijo automático con punto:
.NombreJugador) - Desde consola:
whitelist add .NombreJugador(nótese el punto inicial) - Geyser y Floodgate se encargan de mapear los UUIDs cross-platform
Parte 3: Capas anti-grief para servidores Java 1.21.x
Whitelist activada no significa que tu server esté seguro. Cualquier jugador autorizado puede romper, construir o saquear lo que quiera. Aquí es donde entran los plugins.
Capas recomendadas para una protección sólida
Capa 1: LuckPerms (permisos)
LuckPerms es el gestor de permisos estándar del ecosistema Bukkit/Paper. Te permite crear grupos (admin, mod, vip, default), asignar permisos granulares y propagar cambios sin reiniciar.
Instalación:
- Descarga LuckPerms desde luckperms.net (versión Bukkit/Paper).
- Copia el
.jara la carpetaplugins/. - Reinicia el server.
- Define grupos:
/lp creategroup admin,/lp creategroup default - Asigna permisos por grupo, no por jugador.
Convención de grupos recomendada para un servidor de comunidad:
| Grupo | Color en chat | Permisos clave |
|---|---|---|
| owner | Rojo | Todos los permisos, OP completo |
| admin | Dorado | Wildcard con scope limitado (sin permisos de LuckPerms admin) |
| mod | Verde | Ban, kick, mute, tp, heal, tpa, inspeccionar cofres |
| vip | Amarillo | Comandos cosméticos, homes adicionales, fly en zona propia |
| default | Blanco | Sin permisos especiales, solo essentials básico |
Capa 2: WorldGuard (protección de regiones)
WorldGuard protege zonas (regiones) contra interacciones no autorizadas: romper bloques, colocar bloques, abrir cofres, usar items específicos. Es la pieza central del anti-grief.
Configuración mínima recomendada en plugins/WorldGuard/worldguard/config.yml:
regions:
max-region-count-per-player: 5
wand: 334 # Default wand is a stick; oak slab item ID
default-region-name: __global__
global:
region:
build-permission:
default: ALLOW
interaction-protection:
default: ALLOW
protection:
chest-protection:
enable: true
block-break: true
block-place: true
fire:
disable-fire-spread: false
disable-lava-fire-spread: false
lava-spread: false
Para crear una zona protegida alrededor del spawn:
- Darte la WorldEdit wand con
//wand(te entrega un hacha de madera por defecto) - Marcar dos esquinas opuestas con clic izquierdo y clic derecho en bloques
- Definir la región:
/rg define spawn "Spawn principal" - Añadir flags:
/rg flag spawn pvp deny,/rg flag spawn tnt deny
El sistema de flags es muy potente. Algunas flags clave para anti-grief:
pvp: permite/prohíbe combate entre jugadorestnt: permite/prohíbe explosiones de TNTcreeper-explosion: explota o no los creepersfire-spread: propagación de fuegochest-access: abrir cofres ajenossleep: dormir en la regiónbuild: romper/construir bloques
Capa 3: CoreProtect (rollback y logs)
CoreProtect es el mejor plugin de inspección y rollback. Guarda en una base de datos interna quién colocó, rompió, abrió cofre o mató mob en cada coordenada. Si alguien griefea, puedes revertir exactamente a un estado anterior.
Comandos clave para mods:
/co lookup u:<jugador> t:1h a:block: ver todos los bloques que colocó ese jugador en la última hora/co lookup u:<jugador> t:30m a:container: ver todos los cofres que abrió/co rollback u:<jugador> t:1h r:50: revertir todo lo que hizo ese jugador en la última hora, en un radio de 50 bloques/co restore t:4h: restaurar el mundo a cómo estaba hace 4 horas
Configuración recomendada en plugins/CoreProtect/config.yml:
- Activa el check-update automático para mantener el plugin al día
- Ajusta default-radius para rollbacks a 50 bloques
- Limita el historial según tu espacio en disco: 30 días suele ser suficiente para la mayoría de comunidades
Capa 4: EssentialsX (comandos y antiflood)
EssentialsX añade comandos de calidad de vida (/home, /tpa, /spawn, /msg), pero también incluye protección anti-grief por defecto:
- /tp cooldown: previene teleports abusivos
- /heal cooldown: previene curación infinita en PvP
- Anti-build: configurable para impedir construir en zonas específicas
- Anti-flood: limita mensajes repetidos en chat
Parte 4: Proteger contra griefs específicos
Más allá de los plugins generales, hay tipos de grief que requieren configuración especial.
Proteger contra explosiones
El grief clásico: TNT, creepers, end crystal. WorldGuard lo maneja, pero conviene reforzar.
/rg flag global tnt deny(globalmente)/rg flag global creeper-explosion deny(explosiones de creeper)/rg flag global other-explosion deny(end crystal, bed en Nether)- Para servidores con quests, deja una zona “wilderness” donde sí se permiten
Proteger cofres
- WorldGuard con
chest-access: denyen regiones públicas - LWC plugin como capa adicional si quieres cofres privados lockeables
- Forja reglas:
default-protectionenconfig.ymlde WorldGuard
Proteger contra raids y Ominous Events
Desde 1.21.x, los jugadores pueden lanzar raids en aldeas consumiendo Ominous Bottles. Si no quieres raids aleatorios por todo el mundo:
- Restringe el permiso
minecraft:bad_omencon LuckPerms - Permite el efecto solo a vip/mod/admin si quieres controlados
- Añade una flag
bad-omenen las regiones sensibles
Proteger contra spam de redstone y lag machines
El grief técnico más dañino. Jugadores maliciosos crean máquinas de redstone que saturan el server.
- Paper/Spigot ya mitigan bastante con límites nativos (redstone, hopper, mob-spawn-range)
- Configura
paper-world-defaults.ymlcon maxEntityCramming reducido - Plugin adicional: ClearLag o FarmLimiter para limpiar entities acumuladas
- Bloquea farms específicos con WorldGuard flags
Parte 5: Checklist de configuración paso a paso
- Backup completo del mundo y carpeta plugins antes de empezar.
- Whitelist activada y jugadores de confianza añadidos.
- LuckPerms instalado, grupos creados y permisos asignados.
- Vault instalado para que LuckPerms y EssentialsX se conecten.
- EssentialsX instalado con config básica (homes, teleports, antiflood activo).
- WorldEdit + WorldGuard instalados. Proteger spawn con región y flags.
- CoreProtect instalado con radio de rollback razonable.
- Región global definida con flags anti-explosión, anti-grief.
- Probar con dos cuentas: una como jugador default y otra como admin.
- Configurar backups automáticos cada 3-6 horas en el hosting.
- Documentar las reglas y publicarlas en Discord/MOTD.
Errores comunes que rompen la protección
- Activar whitelist sin dar OP primero: si no tienes /op, no puedes añadir jugadores.
- Confiar solo en op-permission: los OPs pueden deshabilitar WorldGuard. Usa LuckPerms para admins no-OP.
- Sin backups: si un rollback sale mal, solo el backup te salva.
- WorldGuard sin WorldEdit: definir regiones sin wand es dolor puro.
- Plugins desactualizados: las flags, items y mobs de 1.21.x pueden no ser reconocidos por plugins viejos.
- Permisos copiados de tutoriales viejos: revisa qué perm node existe realmente. Muchos dejaron de existir.
Cómo elegir hosting para un servidor con whitelist y anti-grief
La calidad del hosting importa más de lo que parece. Estas capas requieren I/O constante (logs de CoreProtect, consultas LuckPerms, ticks de WorldGuard). Un hosting mediocre te da lag en cuanto aplican las primeras flags regionales.
Lo que debe ofrecer:
- Hardware moderno: NVMe y CPUs de última generación, porque los plugins de protección comen CPU en cada tick.
- Backups automáticos incluidos en el plan, con retención mínima de 7 días.
- Panel intuitivo: instalar plugins editando config desde GUI, sin SSH.
- Consola en tiempo real: ver logs, errores y aplicar comandos al vuelo.
- Soporte 24/7: cuando un plugin de permisos rompe el server a las 3 AM, necesitas respuesta.
- Activación inmediata: pagas y minutos después estás protegiendo tu server.
Para servidores en Chile, Perú, Argentina y resto de LATAM, RDSNode Minecraft Hosting cumple todos los puntos anteriores: panel propio, hardware moderno, soporte eficiente y activación inmediata. La baja latencia desde Santiago de Chile hace que el TPS sea más estable que en hostings genéricos de Europa o Estados Unidos, lo que se nota especialmente con WorldGuard y CoreProtect corriendo.
Si prefieres comparar opciones, revisa también la página principal de RDSNode con el catálogo completo de planes y juegos soportados. Para tu primer server protegido o una migración desde otro proveedor, ten a mano el 15% de descuento con el código RDSNODE15.
Preguntas frecuentes sobre whitelist y anti-grief
¿La whitelist nativa es suficiente o necesito un plugin?
Para whitelist pura (controlar quién entra), la feature nativa basta y es la opción más limpia. Para anti-grief necesitas plugins sí o sí: WorldGuard para zonas, CoreProtect para rollback, LuckPerms para permisos.
¿Cómo recupero un mundo después de un grief?
Si tienes CoreProtect activo, usa /co rollback u:<jugador> t:1h r:50 ajustando tiempo y radio al incidente. Si no tenías CoreProtect, toca restaurar desde un backup automático previo al evento.
¿Qué pasa si alguien entra con una cuenta de un amigo ya whitelisted?
No puede. La whitelist valida por UUID de Mojang, no por nombre. Aun si dos jugadores usan el mismo nick, el sistema los trata como cuentas distintas.
¿Cómo permito que un admin investigue cofres sin ser sospechoso?
Usa el modo /co inspect con CoreProtect. Permite ver interacciones con cofres, bloques y mobs sin que el dueño note que alguien tocó sus cosas. Es la herramienta estándar de los mods.
¿WorldGuard protege contra hacks de cliente?
No directamente. WorldGuard valida acciones en el server; si el cliente hace algo que el server no entiende, simplemente se rechaza. Para movimientos imposibles o kill-aura necesitas un anti-cheat como Vulcan, Grim o NoCheatPlus.
¿Cuál es el límite de jugadores en whitelist?
No hay límite técnico. La whitelist es un archivo JSON que escala sin problemas hasta cientos de miles de entries. Lo que sí limita es la RAM del server y los TPS cuando hay 100+ jugadores concurrentes.
¿Qué hago si un moderador abusa de sus permisos?
Aplica el principio de menor privilegio: cada mod solo tiene los permisos específicos que necesita, no un wildcard. Registra toda acción sensible con CoreProtect y haz auditorías periódicas. Si el abuso es grave, revoca permisos desde LuckPerms con /lp user <mod> permission unset *.
Tu turno
¿Ya configuraste whitelist y anti-grief en tu servidor o todavía corres con la puerta abierta? Cuéntame en los comentarios:
- ¿Qué tipo de grief te ha costado más trabajo revertir?
- ¿Usas CoreProtect desde el día uno o lo añadiste después del primer incidente?
- ¿Tienes algún truco de configuración de WorldGuard que te haya salvado la vida?