Guías / Servidores y rendimiento
Whitelist, ban y op: los comandos de servidor que se comportan distinto de lo que esperas
La whitelist no expulsa a los jugadores ya conectados, /ban necesita un motivo para ser útil, y el nivel de op importa más que la lista de ops. Los detalles que muerden a los dueños de servidores.
Los comandos de administración parecen simples y en su mayoría lo son. Los fallos vienen de tres comportamientos que no son obvios a partir de la sintaxis.
La whitelist no elimina a quien ya está dentro — a menos que se lo indiques
/whitelist on empieza a aplicar la lista para los nuevos inicios de sesión. Si los jugadores ya conectados son expulsados o no lo decide una sola línea en server.properties:
enforce-whitelist=trueEstá en false por defecto, y mientras lo esté, los jugadores que no figuran en la lista permanecen conectados tanto por /whitelist on como por /whitelist reload. Ponlo en true y on, reload y remove expulsarán a todos los jugadores conectados que no estén en la lista. Activar la whitelist con la aplicación desactivada e irse es el error clásico.
Dos detalles más:
/whitelist add <name>resuelve el nombre contra la API de Mojang en un servidor en modo online. En un servidor en modo offline, en su lugar añade a la whitelist el UUID offline del nombre, así que no hace falta editarwhitelist.jsona mano.- Los operadores omiten la whitelist por defecto, y por eso tu propia cuenta nunca demuestra que la whitelist funcione. Prueba con una segunda cuenta.
/ban quiere un motivo, y /ban-ip es una lista distinta
/ban <player> [reason]
/ban-ip <address|player> [reason]El motivo es opcional, y omitirlo es un error: es lo que ve el jugador baneado, y es lo que tu yo del futuro leerá en /banlist intentando recordar por qué. Sin uno, la entrada solo dice "Banned by an operator".
/ban y /ban-ip escriben en archivos separados (banned-players.json, banned-ips.json). Indultar uno no limpia el otro, que es la razón habitual por la que un jugador "indultado" sigue sin poder conectarse. Usa /pardon y /pardon-ip ambos.
Niveles de op, no solo la lista de ops
/op otorga nivel 4 por defecto, que es acceso total incluyendo /stop. Los cuatro niveles son reales y configurables en server.properties mediante op-permission-level:
| Nivel | Otorga |
|---|---|
| 1 | Omitir la protección del punto de aparición |
| 2 | La mayoría de comandos de trucos, bloques de comandos |
| 3 | Gestión de jugadores — kick, ban, op |
| 4 | Todo, incluyendo /stop |
Los moderadores que necesitan /kick y /ban quieren el nivel 3, no el 4. Repartir el nivel 4 a todos los que ayudan a moderar es como los servidores acaban borrados por una cuenta comprometida.
function-permission-level es aparte y controla qué funciones de datapack pueden ejecutarse — dejarlo en 2 mientras el nivel de op es 4 es una fuente común de "mi función no hace nada".
Los comandos de lista
/banlist players, /banlist ips y /banlist a secas existen todos e imprimen en la consola en lugar del chat si se ejecutan desde la terminal del servidor. /whitelist list muestra solo nombres, no UUIDs — lee whitelist.json cuando necesites comprobar la identidad.
Construye cualquiera de estos con los argumentos en el orden correcto en el Server Admin Command Builder, que cubre ban, ban-ip, pardon, kick, op, deop y whitelist desde un solo formulario.