Propiedades del servidor en la instantánea 26.4 de Minecraft: allowed-connection-ids, status-contact-details y enable-legacy-status explicadas

Dos instantáneas de septiembre añadieron silenciosamente tres claves server.properties que serán importantes para los administradores de servidores. Aquí te explicamos qué hace cada una, las advertencias de Mojang y si deberías probar las instantáneas 26.4 ya.

Ilustración estilizada de un rack de servidores naranja brillante situado en una cueva de hielo nevada al atardecer, con la silueta de un lobo tallada en la pared rocosa helada.

Los snapshots 26.4 ya están aquí: el Snapshot 1 llegó el 22 de septiembre de 2026 y el Snapshot 2 siguió el 29 de septiembre. Entre ambos, los snapshots de Minecraft 26.4 añadieron tres nuevas claves server.properties que importarán a los administradores de servidores dedicados: allowed-connection-ids, status-contact-details y enable-legacy-status. Ninguna está aún en una versión estable, y el propio 26.4 solo está planeado para el cuarto trimestre de 2026 sin fecha oficial.

TL;DR: estas claves merece la pena aprenderlas ahora, pero no las uses en producción hasta que 26.4 se lance oficialmente. Los servidores de instantáneas implican no Paper, sin plugins y con actualizaciones de mundo unidireccionales.

La Instantánea 1 es la interesante. Añadió las tres claves, además de un cambio de protocolo relacionado en cómo el cliente envía la dirección del servidor. La Instantánea 2 trajo correcciones de errores, cambios en la niebla de distancia de renderizado y un rediseño de la pantalla de depuración, sin nuevas propiedades (versiones de desarrollo de 26.4, minecraft.wiki). La fuente principal de todo lo siguiente es el registro de cambios de la Instantánea 1 de Mojang.

Una nota sobre la nomenclatura: desde el cambio de numeración de diciembre de 2025, las instantáneas se nombran al estilo 26.4-snapshot-1 en lugar del antiguo formato de número de semana 25w44a. La secuencia de Mojang es instantáneas → -pre-N → -rc-N → lanzamiento.

Antes de ir clave por clave, necesitas entender por qué existen estas claves. La nueva interpretación del campo host es la base de todo lo siguiente.

El contexto primero: cómo funcionan las propiedades en la dirección del servidor

El campo host en el paquete serverbound minecraft:intention ahora lleva parámetros al estilo de consulta URI. (Mojang escribe inconsistentemente minecraft:intent y minecraft:intention en el mismo registro de cambios. Es el mismo paquete, un error tipográfico, no dejes que te confunda.) Eso significa que una dirección de servidor puede verse como example.com?key1=value1&key2, con claves y valores con codificación porcentual según las reglas URI, y se permiten valores vacíos para omitir el =. El campo también se amplió a 1024 caracteres, y los jugadores pueden escribir estas propiedades en cualquier campo "Dirección del Servidor".

También hay una forma corta: una dirección como [email protected] se interpreta como play.example.com?_id=myid. La wiki SAS Gaming añade que el id es "cualquier carácter antes del primer @" en la dirección. Ese es un detalle de la wiki comunitaria, de segunda mano, pero coincide con el ejemplo de Mojang.

Las claves que comienzan con _ están reservadas para la versión vanilla. _id es la clave con la que se compara allowed-connection-ids. También hay una interacción SRV que vale la pena conocer: si un registro SRV resuelve la dirección a un dominio diferente, el resuelto se convierte en el primario y el original se pasa como la propiedad _o (origen). Según el registro de cambios, esto aborda el comportamiento inconsistente de SRV que Mojang rastrea bajo el ID de error MC-278651.

La propia advertencia de Mojang, citada exactamente: "Nota: dado que el paquete minecraft:intent no está cifrado, las propiedades no deben usarse para ningún propósito sensible a la seguridad." Tenlo presente para todo lo que sigue.

Un elemento más del registro de cambios para completar: el paquete minecraft:transfer ganó un campo properties, un mapa de cadena a cadena añadido al campo host enviado al servidor de destino. Importa para configuraciones de transferencia y proxy una vez que 26.4 sea estable.

status-contact-details: la clave que realmente usarán la mayoría de los administradores

En nuestra opinión, esta es la más útil de las tres para servidores comunitarios. Si status-contact-details no está vacío, su valor se envía en el JSON del paquete minecraft:status_response bajo la propiedad contact, lo que significa que aparecerá en la entrada de tu servidor en la lista.

La intención declarada de Mojang: una forma legible por humanos para que los jugadores contacten a los propietarios del servidor cuando no haya sitio web ni otra información. No hay restricciones de formato. Nuestra sugerencia editorial: una invitación a Discord o una dirección de correo electrónico funcionan bien. Ambas son cortas y fáciles de copiar y pegar, y resuelven exactamente el problema que describe Mojang: jugadores que encuentran tu servidor y no tienen idea de cómo contactarte.

El valor por defecto está vacío (inferido del registro de cambios, no documentado explícitamente). Una advertencia: la información de contacto solo aparece cuando enable-status=true.

Si ejecutas un servidor para amigos y comunidad sin sitio web, esta es la clave que merece la pena configurar pronto en la versión estable.

allowed-connection-ids: un filtro de conexión ligero con un gran riesgo oculto

Citando el registro de cambios: "Una lista de ids separados por comas. Si no está vacío, el servidor comparará los valores contra la propiedad _id en el paquete minecraft:intention. Si no hay coincidencia, el servidor rechazará la conexión. Esto funciona tanto para conexiones de estado como de login, por lo que cualquier usuario que se conecte sin el _id correcto en la dirección del servidor no verá el estado y no podrá unirse al servidor."

Un ejemplo práctico (nuestra deducción, no de ninguna fuente): digamos que configuras

allowed-connection-ids=friends,alt-night

Los jugadores luego se unen mediante [email protected] en el campo de dirección del servidor, o la forma completa your.server.ip?_id=friends. Ambos se interpretan como _id=friends, lo cual coincide, y entran.

El riesgo oculto: porque el filtro también controla los pings de estado, un id incorrecto o ausente significa que el servidor no responde al estado en absoluto. Tu servidor aparece como desconectado en la lista de servidores. Esta es la configuración errónea más probable. Alguien configura la clave, olvida decirles a sus jugadores el id y pasa una tarde convencido de que el servidor se ha caído. Los clientes rechazados ven el mensaje "Conexión rechazada por el servidor" (según MC Toolkit).

Vamos a ser claros: esto es oscuridad, no autenticación. El identificador viaja sin cifrar durante el handshake, tal como advirtió Mojang. Cualquiera que sniffée la conexión o lea el formato del paquete puede leerlo, y cualquiera puede escribirlo. No lo trates como un reemplazo de tu allowlist. Mantén la allowlist real activa.

Piensa en allowed-connection-ids como un filtro de conveniencia para un servidor semi-privado donde prefieres que los desconocidos sean rechazados en lugar de pasar por un flujo de ban.

Dos incógnitas que no vamos a suponer: el valor por defecto no está documentado (se infiere vacío), ni tampoco los caracteres permitidos ni los límites de longitud para los ids. Tampoco está verificado el comportamiento detrás de Velocity o BungeeCord. Los administradores de redes deben esperar y probar en la etapa RC, ya que los proxies analizan el formato del handshake ellos mismos.

enable-legacy-status: mantenimiento para herramientas de ping antiguas

Esta es la única de las tres con un valor por defecto documentado: true, preservando el comportamiento existente. Establecerlo en false deshabilita el manejo del protocolo de estado/ping legacy pre-1.7. También requiere enable-status=true para que se envíe cualquier información de estado, moderna o legacy, en absoluto.

¿Cuándo cambiarías esta configuración? Nuestra recomendación: solo si estás seguro de que nada en tu cadena de herramientas sigue haciendo ping con el protocolo legacy. Algunos bots antiguos de listas de servidores, paneles de control y escáneres aún lo hacen. Si una herramienta de monitoreo deja de detectar tu servidor después de configurar esto, esta clave es el primer sospechoso. Revierte el cambio y actualiza la herramienta.

Nada aquí bloquea jugadores; solo afecta cómo se responden las solicitudes de ping muy antiguas.

Referencia rápida: las tres claves de un vistazo

Clave Por defecto Qué hace ¿Bloquea el estado? Cuándo usarla
status-contact-details vacío (inferido) Publica la información de contacto en la respuesta de estado (propiedad contact) No Servidores comunitarios sin sitio web
allowed-connection-ids vacío (inferido) Rechaza inicios de sesión y pings de estado sin un _id coincidente Sí, id incorrecto = el servidor parece muerto Servidores semi-privados para amigos, como conveniencia, no como seguridad
enable-legacy-status true (documentada) Deshabilita el manejo de ping pre-1.7 cuando false Solo clientes legacy Administradores retirando herramientas de ping antiguas

Recordatorio al editar server.properties: es UTF-8, líneas key=value con comentarios #, y el servidor reescribe el archivo al inicio, copiando los valores existentes y restableciendo las claves faltantes o inválidas a los valores por defecto. Se requiere un reinicio tras las ediciones, y haz una copia de seguridad del archivo antes de experimentar.

Las tres son solo de snapshot ahora mismo y podrían cambiar antes de que se lance 26.4.

Probar en un servidor de snapshot: el procedimiento sensato

La propia advertencia de Mojang aplica: las versiones de prueba pueden corromper tu mundo, así que haz una copia de seguridad y ejecuta los snapshots en una carpeta separada de tus mundos principales. Los mundos de snapshot se actualizan de forma unidireccional a la versión de datos del snapshot. Sin aviso, sin deshacer, y la única ruta de regreso es una copia de seguridad previa al snapshot. Los mundos incluso pueden romperse entre snapshots consecutivos.

Una torre de servidor con componentes internos brillando tenuemente sobre una meseta nevada junto a una hoguera naranja cálida, con luz azul-violeta fría en los acantilados helados de fondo
Un servidor de snapshot desechable: créalo, prueba las nuevas propiedades y luego elimínalo.

Soporte de frameworks primero. A finales de septiembre, Vanilla y Fabric pueden ejecutar snapshots, mientras que Paper, Purpur, Spigot, Forge y NeoForge no han publicado builds de snapshot 26.4; solo construyen releases y release candidates. Esto proviene de una sola fuente (GameServerKings, verificado el 28 sep 2026) y vale la pena volver a verificarlo contra la API de builds de Paper antes de confiar en ello. Por ahora, eso significa que no hay plugins en un servidor de snapshot.

Para probar específicamente las nuevas claves: añádelas a server.properties, reinicia el servidor, conéctate usando la abreviatura friends@ip y verifica que la entrada de tu lista de servidores muestre tus detalles de contacto. Luego realiza las comprobaciones de integridad más amplias:

  1. Haz una copia de seguridad de tu mundo y configuraciones de producción.
  2. Crea un servidor separado y desechable. No toques la producción.
  3. Copia tus configuraciones allí.
  4. En el primer arranque, lee el registro buscando claves rechazadas o desconocidas.
  5. Recorre tus granjas y construcciones de redstone para comprobar que nada se haya roto.
  6. Desecha el servidor cuando termines.

Si quieres una instancia lateral para pruebas de snapshot junto a tu servidor de producción, alojamiento de servidores Minecraft con copias de seguridad diarias y configuración en un clic te ofrece tu propia máquina con restauración en un clic, que es exactamente lo que necesitas antes de tocar cualquier cosa.

¿Deberías ejecutar snapshots 26.4 en producción todavía? (Veredicto: no)

No. Espera al lanzamiento, o al menos a los release candidates si eres administrador de Paper, ya que Paper publica builds de los RC. Tres razones: sin soporte de frameworks de plugins o mods en las snapshots, actualizaciones de mundo unidireccionales, y las tres claves son lo suficientemente nuevas como para cambiar antes del lanzamiento de 26.4.

En cuanto al cronograma, sé honesto contigo mismo: el 26.4 está planeado para el Q4 de 2026 según la wiki, sin fecha oficial de Mojang. Hay una estimación de diciembre de 2026 circulando basada en el ciclo aproximado de 10 a 14 semanas entre snapshot y lanzamiento de las versiones 26.1 a 26.3. Esta es una proyección del calendario, no una declaración de Mojang.

Qué hacer ahora: nada en producción. Opcionalmente, crea un servidor vanilla o Fabric de snapshot desechable para probar status-contact-details y ver cómo se ve la cadena de contacto en la lista de servidores.

Qué vigilar: si usas Velocity o BungeeCord, eres el grupo que debe vigilar 26.4, porque los proxies analizan el formato del handshake por sí mismos y el campo host extendido cambia lo que ven. SyntaxMine identifica precisamente a los administradores de redes como este grupo. Revisitaremos este artículo cuando 26.4 llegue a release candidates o a la versión estable, y actualizaremos los detalles clave si algo cambia.

Preguntas frecuentes

¿Qué hacen realmente allowed-connection-ids, status-contact-details y enable-legacy-status?

allowed-connection-ids rechaza las conexiones (estado y login) que no lleven un _id coincidente en la dirección del servidor. status-contact-details publica una cadena de contacto en la respuesta de estado de tu servidor. enable-legacy-status=false desactiva el manejo legacy de ping anterior a la 1.7. Solo enable-legacy-status tiene un valor por defecto documentado (true); los otros dos están vacíos a menos que los configures.

¿Cómo introduce un jugador el id de conexión en la dirección de su servidor?

Ya sea la forma corta [email protected] (interpretada como your.server.ip?_id=friends) o la forma completa de consulta your.server.ip?_id=friends. Todo lo anterior al primer @ se trata como el id.

¿Por qué mi servidor aparece como desconectado en la lista después de configurar allowed-connection-ids?

El filtro se aplica tanto a los pings de estado como a los logins. Si el cliente que se conecta no envía un _id coincidente, el servidor no responderá al estado, por lo que la lista de servidores lo mostrará como fuera de línea. Corrige el id en la dirección del servidor o borra la clave.

¿Puedo usar allowed-connection-ids como lista blanca?

No. Mojang indica explícitamente que el paquete minecraft:intent no está cifrado, por lo que el id puede leerse o suplantarse. Trátalo como un filtro de conveniencia para un servidor semiprivado y mantén tu allowlist real activa.

¿Funcionan estas nuevas claves con Velocity o BungeeCord?

Sin verificar. Los proxies analizan ellos mismos el campo host del handshake, por lo que el comportamiento detrás de un proxy no está confirmado para las instantáneas 26.4. Los administradores de red deben esperar a las versiones candidatas de lanzamiento y probar antes de confiar en nada de esto.