Configuración del servidor dedicado Crossplay de Valheim 1.0: flags de inicio e ID de administrador

Si tu grupo de Valheim está dividido entre Steam, Xbox o Microsoft Store, y las plataformas anunciadas para la 1.0, la decisión importante no es simplemente quién pulsa Host. Una sesión alojada por un jugador es una sesión de juego entre pares, mientras que un servidor dedicado es un proceso separado que mantiene disponible el mundo compartido sin atarlo a la sesión de un jugador. Esa diferencia convierte al alojamiento dedicado en la base sensata para un mundo persistente de grupo, pero el servidor todavía debe ejecutarse en el entorno documentado para PC, Linux u otro entorno de servidor compatible.

Esta guía usa el manual actual de servidores dedicados de Iron Gate para los pasos operativos y trata el anuncio de la 1.0 del 9 de septiembre de 2026 como una capa de confirmación separada. La 1.0 confirma el juego cruzado en todas las plataformas y un alcance de 1–10 jugadores, pero todavía no sustituye el manual del servidor por una sintaxis nueva ni publica una matriz completa de seguridad para los logros. Elegirás el backend, iniciarás el servidor, aplicarás flags de modificadores acotados, localizarás los archivos de control y construirás la lista de administradores a partir de los ID exactos que informe el servidor; después dejarás una lista clara de comprobaciones para hacer tras el inicio.

Un servidor dedicado separa el mundo del host del jugador

La decisión trata de dónde vive la sesión multijugador. Al iniciar el multijugador desde Valheim se crea una sesión pública o privada entre pares mediante el juego, vinculada al jugador que la inicia. La aplicación Valheim Dedicated Server, en cambio, inicia un proceso separado para un mundo persistente. Ese proceso puede mantener el mundo disponible mientras el host habitual no está dentro del juego, siempre que la máquina que lo ejecuta esté conectada y el proceso del servidor siga activo; es acceso independiente del host, no una garantía de disponibilidad continua.

Para un grupo de diez jugadores dividido entre Steam, Microsoft/Xbox y las plataformas anunciadas para la 1.0, la diferencia es práctica. Si el host habitual solo juega por las tardes, una sesión alojada por un jugador hace que el horario del grupo dependa de esa persona. Un servidor dedicado que funcione en un PC compatible, una máquina Linux u otro entorno de servidor permite mantener disponible un único proceso del mundo. Planifica según el alcance de 1–10 jugadores de los servidores de Valheim; el alojamiento dedicado no amplía esa capacidad.

El límite de las consolas importa antes de elegir la máquina. Xbox no puede alojar el proceso dedicado desde la consola, aunque los jugadores de Xbox sí pueden unirse a un servidor dedicado cuando la ruta Crossplay está activada. Mantén la aplicación del servidor en el entorno compatible de PC/Linux/servidor y deja la elección del backend para una decisión posterior de la configuración. Una vez elegido ese modelo operativo, instala la aplicación oficial del servidor y comprueba que su proceso haya iniciado antes de configurar cómo se conectarán los jugadores.

Instala e inicia la aplicación de servidor actual

Coloca el proceso del servidor en el PC, la máquina Linux u otro entorno de servidor compatible que hayas elegido para el mundo. En Steam, instala o localiza Valheim Dedicated Server, abre sus archivos locales y usa el archivo de inicio correspondiente a ese sistema operativo. Este es el punto en que la decisión de alojamiento se convierte en un proceso de servidor real; deja la elección del backend y el resto de la configuración de inicio para cuando el proceso pueda iniciarse limpiamente.

En Windows, abre la carpeta del Dedicated Server y ejecuta start_headless_server.bat. En Linux, ejecuta ./start_server.sh desde el directorio del servidor. El manual actual enumera libatomic1, libpulse-dev y libpulse0 como dependencias de Linux, así que instálalas antes de ejecutar el script en una instalación de Steam para Linux. En ambos casos, observa la ventana de comandos en lugar de tomar la apertura del archivo como prueba de que el servidor está listo: espera a que el registro indique Game server connected.

Para una instalación de Windows desde Microsoft Store, usa su carpeta Server independiente en C:\XboxGames\Valheim\Content\Server y ejecuta allí StartHeadlessServer.bat. Esa es una ruta de instalación distinta para PC de la aplicación del servidor, no una prueba de que una consola Xbox pueda alojar el proceso dedicado.

Cuando termines, detén el proceso con Ctrl+C en la ventana de comandos. No cierres la ventana con su X, porque eso no sigue la ruta de apagado documentada. El paquete del servidor dedicado también incluye un script de Docker, pero Docker y el despliegue específico de proveedores quedan fuera de esta configuración básica: primero consigue que la aplicación documentada funcione y después elige el backend que determinará cómo se conectarán los jugadores.

Elige el backend que coincide con la ruta de acceso del grupo

Cuando el proceso del servidor ya está en ejecución, su backend determina quién puede verlo y qué ruta de conexión debe usar el grupo. La elección es directa:

Ejemplo histórico de selección de servidor y unión por IP; comprueba los códigos de unión y el navegador de servidores de Crossplay en la versión activa.

Si omites -crossplay, Valheim usa el backend de Steam. La visibilidad y el acceso quedan limitados a usuarios de Steam, y el intervalo de puertos predeterminado del servidor es 2456–2457; esos puertos deben ser accesibles desde Internet. Es la ruta sensata para un grupo solo de Steam y mantiene al grupo en la ruta de identidad de Steam cuando después configures la administración.

Para un grupo dividido entre Steam, Microsoft/Xbox y las plataformas anunciadas para la 1.0, añade -crossplay. Esto selecciona el backend PlayFab Crossplay y envía el tráfico externo mediante su relé, así que no necesitas configurar el reenvío de puertos del router para esa ruta. Los jugadores pueden usar la IP pública y el puerto del servidor, pegar un código de unión mediante Join Game o seleccionar el servidor desde el navegador. El puerto sigue siendo útil cuando varios servidores comparten una IP pública, porque distingue cada servidor aunque el relé gestione la conexión externa.

Haz la prueba según la ruta que hayas elegido. Un servidor Crossplay que funciona mediante un código de unión o el navegador de servidores, pero falla cuando intentas usar la dirección LAN de la máquina del servidor o 127.0.0.1, se está comportando como está documentado: las conexiones Crossplay no aceptan una IP local ni una dirección de loopback. Da a los jugadores de plataformas mixtas el código de unión o la ruta del navegador en lugar de investigar un fallo esperado como si fuera un problema de reenvío de puertos.

Añade -instanceid solo cuando varios servidores usen el mismo puerto en la misma máquina o dirección MAC. En ese caso, da a cada servidor un valor único; -instanceid "1" es un ejemplo, para que el servicio Crossplay les asigne ID de PlayFab distintos. Con un solo servidor en la máquina, deja fuera esta excepción. Con la decisión del backend completa, el siguiente paso es componer el comando de inicio y aplicar la precedencia documentada entre preajustes y modificadores.

Compón los flags de inicio en el orden en que los lee el servidor

Con el backend elegido, añade los flags principales de identidad y mundo y usa la configuración de modificadores documentada a continuación. Los flags principales dan al proceso un nombre, puerto, mundo, contraseña y visibilidad:

Para el grupo de plataformas mixtas de esta guía, conserva el flag -crossplay elegido antes en el comando. Un ejemplo completo centrado en los modificadores podría verse así:

-name "Valheim 1.0 group" -port 2456 -world "Dedicated" -password "Secret" -public 1 -crossplay -preset hard -modifier resources more -setkey nomap

Precedencia del preajuste. -preset establece una base y sobrescribe los modificadores de mundo anteriores. Si también necesitas un cambio independiente, coloca -modifier después del preajuste para que el par explícito de grupo/valor se aplique después. En el ejemplo, el servidor parte del preajuste Hard y después cambia Resources a more; el preajuste no sobrescribe esa elección posterior.

Los nombres de preajuste documentados son:

Normal, Casual, Easy, Hard, Hardcore, Immersive y Hammer.

Los modificadores independientes son más acotados que un espacio de nombres general de claves de mundo. Usa solo estas combinaciones de grupo/valor:

Valores de modificador aceptados. La sintaxis es el grupo seguido de su valor, como en -modifier resources more. No sustituyas un valor que solo parezca plausible, como normal para un grupo cuya lista documentada no lo incluye. Si el grupo necesita más de un ajuste explícito, mantén cada -modifier dentro de su conjunto de grupo/valor publicado y haz que el comando resultante sea lo bastante legible como para auditarlo antes de usar el mundo.

Límite de inicio de -setkey. -setkey es una opción de inicio independiente y restringida. La documentación oficial del servidor enumera solo cuatro claves de inicio: nobuildcost, playerevents, passivemobs y nomap. El ejemplo compacto -setkey nomap es válido; los nombres arbitrarios del espacio de nombres más amplio de Claves Globales no quedan documentados por ello como argumentos de inicio válidos. El comando de desarrollador setkey dentro del juego es un mecanismo distinto, y activar devcommands no amplía esta lista permitida para el inicio.

Flags de mantenimiento. Puedes añadir los flags operativos documentados alrededor de esta configuración cuando los necesites: -logFile, -saveinterval (el valor predeterminado es de 1,800 segundos), -backups (cuatro copias de seguridad automáticas por defecto), -backupshort (dos horas por defecto) y -backuplong (12 horas por defecto). Mantén esas decisiones de mantenimiento separadas de la decisión sobre modificadores para que la configuración del mundo siga siendo evidente en el archivo por lotes o el script de inicio de Linux.

Antes de usar el mundo. Copia la estructura en el archivo de inicio, elige una sola vez el nombre del mundo, la contraseña y la visibilidad, y fija el estado de los modificadores antes de que los jugadores construyan en el mundo. Trata la lista de -setkey de inicio como un límite documentado de cuatro claves y no describas una combinación arbitraria de -preset, -modifier o -setkey como universalmente segura para los logros mientras la matriz completa de elegibilidad siga sin publicarse.

Localiza el directorio de guardado y separa el control de acceso de los datos del mundo

El comando de inicio ya define qué mundo carga el servidor y qué modificadores aplica. Mantén ese estado del mundo separado de los archivos que deciden quién puede administrar o entrar al servidor. Antes de editar permisos, identifica el directorio de guardado que está usando ese proceso concreto del servidor.

Si la configuración de inicio incluye -savedir, usa esa ubicación en lugar de buscar la ruta predeterminada del sistema operativo. Aplica la misma elección de -savedir cada vez que inicies o mantengas el servidor; de lo contrario, es fácil inspeccionar un directorio mientras el proceso en ejecución lee otro. Confirma primero la ubicación activa y después haz una copia de seguridad del mundo y de sus archivos de control antes de cambiar la política de acceso.

Los archivos de control de acceso están en esa ruta de guardado o en la ruta seleccionada con -savedir:

Cada archivo acepta un Platform User ID por línea. Ese formato compartido no hace que los archivos sean intercambiables: adminlist.txt controla el acceso de gestión del servidor, bannedlist.txt controla las exclusiones y un permittedlist.txt con contenido convierte deliberadamente el servidor en una lista exclusiva. Deja permittedlist.txt vacío salvo que pretendas usar una lista blanca; de lo contrario, un jugador que no esté incluido será rechazado aunque el servidor sea accesible mediante la ruta correcta de conexión.

Estos archivos gobiernan el acceso alrededor del mundo; no son ajustes de modificadores del mundo ni sustituyen los datos del mundo. Cambiar la lista de administradores no aplica un preajuste, no modifica un -setkey de inicio ni migra el guardado. Trata el contenido del mundo y la política de acceso como dos tareas de mantenimiento que casualmente viven bajo el mismo directorio de guardado activo.

Encontrar adminlist.txt es solo la mitad de la administración. El siguiente paso es determinar qué cadena de identidad exacta debe aportar cada jugador y distinguir el acceso de gestión del servidor que concede esa lista del límite separado de los trucos nativos.

Crea adminlist.txt con los ID que informa el servidor

El archivo solo sirve si cada línea contiene la identidad que reconoce realmente el backend elegido. Para un servidor solo de Steam, usa el SteamID64 de 17 dígitos del jugador. Para un servidor Crossplay, usa el ID de plataforma completo que muestre el juego o el servidor, no un Steam ID convertido ni un número que hayas adivinado.

El valor de Crossplay sigue el patrón [Platform]_[User ID], que distingue mayúsculas y minúsculas. Conserva exactamente el prefijo, el guion bajo, los dígitos y las mayúsculas tal como se emitan. En particular, no reduzcas Xbox_2433224801742044 a 2433224801742044 ni des por hecho que Xbox es el único prefijo de plataforma que puede aparecer cuando se incorporen más plataformas a la ruta Crossplay.

Usa este flujo de captura para el grupo:

1. Deja que cada jugador se conecte al servidor una vez. En Crossplay, asegúrate de que el jugador se una mediante la ruta Crossplay elegida antes.
2. Lee el ID completo de ese jugador en el panel F2 del juego o en el registro del servidor.
3. Pega un ID sin cambios en cada línea de adminlist.txt.
4. Guarda el archivo y después reinicia o recarga el servidor según lo requiera el entorno antes de probar el nuevo acceso.

Esto hace que la lista sea auditable: una entrada de solo Steam se ve claramente como un SteamID64 de 17 dígitos, mientras que una entrada Crossplay conserva la información de plataforma que informó el servidor. Si una entrada falla, vuelve a capturarla desde F2 o el registro en lugar de normalizar su escritura o probar otro formato de ID. Cuando el archivo esté activo, los comandos documentados de gestión del servidor incluyen Kick PLAYERNAME, Ban PLAYERNAME, Unban PLAYERNAME y Banned; las referencias actuales de la comunidad también enumeran comandos como save, setworldmodifier, setworldpreset y resetworldkeys, pero esa lista ampliada no debe tratarse como un catálogo oficial completo de comandos.

Estar incluido como administrador no concede acceso a los trucos nativos. En un servidor dedicado vanilla, añadir un ID a adminlist.txt no activa devcommands ni hace que estén disponibles spawn, god, fly o el comando de setkey dentro del juego. Esos trucos pertenecen a la ruta de comandos separada del modo de un jugador o de un mundo alojado manualmente; la administración gestiona el servidor y, cuando corresponde, sus ajustes del mundo. Verifica la lista con una acción de gestión no destructiva que admita tu entorno y conserva esta distinción al evaluar las implicaciones del servidor para los logros.

Trata el mundo 1.0 como una decisión de migración, no como una continuación garantizada

Esta distinción importa cuando el servidor que acabas de administrar llegue a la 1.0. Iron Gate ha anunciado la 1.0 para el 9 de septiembre de 2026, con compatibilidad para Windows, Linux, Mac, Microsoft Store, Xbox One, Xbox Series X|S, PlayStation 5 y Nintendo Switch 2, además de juego cruzado entre todas las plataformas. El anuncio mantiene el juego en 1–10 jugadores, pero no sustituye el proceso del servidor que configuraste por un nuevo contrato de alojamiento: el manual actual del servidor dedicado sigue siendo la fuente operativa de esta guía.

Ilustración genérica de Valheim de la FAQ de 1.0; no muestra alojamiento de servidor ni migración de guardados.

Tu primera decisión es si vale la pena conservar el mundo existente. Iron Gate dice que los mundos existentes seguirán disponibles después de la actualización, pero la generación de biomas nuevos solo funciona correctamente en las zonas que ningún jugador haya explorado antes de la 1.0. Su definición de no explorado es estricta: ningún jugador ha puesto un pie en un radio aproximado de 500 metros. Las mismas preguntas frecuentes recomiendan empezar de nuevo, así que un mundo nuevo es la opción más segura si el grupo quiere la generación prevista del contenido del Norte Profundo. Reutilizar el mundo actual conserva las construcciones, rutas y trabajo acumulado del grupo, pero puede dejar con el límite de generación antiguo las zonas a las que ya se hubiera llegado antes del lanzamiento.

Estas son las dos estrategias legítimas para el servidor:

No confundas esa decisión sobre el mundo con la portabilidad de los guardados entre plataformas. Los jugadores pueden unirse al mismo servidor Crossplay y compartir su mundo sin que sus archivos de guardado individuales se sincronicen entre plataformas. Las preguntas frecuentes de la 1.0 dicen que la sincronización de archivos de guardado entre plataformas no está disponible en general; el acceso a guardados de Xbox desde PC está limitado a iniciar el juego mediante Microsoft Store. En otras palabras, -crossplay responde a «¿pueden estos jugadores entrar en este servidor?». No responde a «¿puede cada plataforma abrir y transferir libremente este mundo o el guardado de este personaje?». Mantén el mundo autoritativo en el proceso del servidor y no prometas una copia portátil como parte de la configuración.

La suposición de alojamiento también sigue siendo más limitada que el anuncio de plataformas. Xbox no puede alojar el proceso dedicado desde la consola, y el material de la 1.0 comprobado no establece que PlayStation 5 o Nintendo Switch 2 puedan alojarlo. Mantén el servidor en el entorno documentado de PC, Linux u otro servidor compatible hasta que Iron Gate publique una ruta explícita de alojamiento desde consola. Las nuevas plataformas pueden unirse al mundo compartido mediante Crossplay; ese hecho por sí solo no demuestra que puedan ejecutar la aplicación de servidor dedicado.

Trata los logros como otro límite de lanzamiento. El seguimiento de logros comienza cuando se descarga la versión 1.0. Iron Gate dice que la mayoría de los trucos y algunos modificadores del mundo, incluido el modo Hammer, pueden bloquear la elegibilidad, pero no ha publicado la matriz completa de modificadores. Evita el modo Hammer y no etiquetes una combinación arbitraria de -preset, -modifier o -setkey como segura para los logros solo porque el servidor la acepte. Un servidor dedicado vanilla elimina la ruta normal de trucos del lado del cliente, pero eso no es una garantía oficial de que toda configuración del mundo siga siendo elegible. Tampoco hay una Public Test Branch para la 1.0, y los mods no tienen soporte oficial, así que ni una rama de pruebas escalonada ni una promesa de compatibilidad con mods pueden sustituir la comprobación del lanzamiento real.

La referencia operativa actual es, por tanto, un límite previo a la 1.0, no un contrato permanente. El marcador estable proporcionado es la versión 0.221.12, publicada el 19 de febrero de 2026, mientras que las preguntas frecuentes de la 1.0 no vuelven a publicar la sintaxis del servidor dedicado para un binario nuevo, el comportamiento de los puertos, ejemplos de ID de administrador ni una lista completa de elegibilidad de modificadores.

Antes de iniciar, registra esta lista de comprobación:

• Decide si reutilizarás la construcción compartida o crearás un mundo 1.0 nuevo.
• Mantén el servidor en el proceso documentado de PC/Linux/servidor.
• Programa una verificación posterior al lanzamiento. Después del 9 de septiembre de 2026, vuelve a comprobar las suposiciones del manual actual que conserva esta guía: -crossplay; los puertos predeterminados del backend de Steam, 2456–2457; el comportamiento del relé PlayFab; las rutas de unión aceptadas, incluidas las de IP pública/puerto, código de unión y navegador de servidores; los nombres y el orden de los modificadores; los valores de inicio de -setkey; los formatos de ID de plataforma; las rutas de guardado; los comandos de administración; la compatibilidad de alojamiento desde consola; y la elegibilidad para logros.
• No presentes la configuración como definitiva para la 1.0 hasta completar esas comprobaciones.