Administrar un servidor de Arma Reforger en Pterodactyl

Actualizado 2026-10-02 · 5 min de lectura

Pterodactyl es el panel de hosting más usado para servidores dedicados de Arma Reforger, propios o alquilados. Esta guía cubre lo que un admin necesita saber para operar el servidor desde ahí y, si quiere, conectarlo a un panel de administración externo.

Puertos: tres allocations

Un servidor de Reforger usa tres puertos UDP, y en Pterodactyl cada uno tiene que ser una allocation asignada al servidor:

Si el egg solo trae la allocation del juego, las otras dos las agrega el administrador del nodo (Admin → Servers → Build → Allocations) y después tú las pones en config.json. El clásico "RCON no responde" en Pterodactyl es un puerto en el JSON que no está asignado al servidor.

Dónde está config.json

Depende del egg. Lo habitual es que el archivo esté en la raíz del contenedor (/home/container/config.json) o en la carpeta del perfil (/home/container/profile/). Para saberlo con certeza, mira la variable de arranque del egg: el comando de inicio lleva -config <ruta>. Editalo desde la pestaña Files; los cambios se leen al reiniciar.

Los secretos importantes viven ahí: game.passwordAdmin (el #login del juego) y rcon.password. Quien tenga acceso a Files los ve; limita los subusuarios de Pterodactyl a lo que de verdad necesitan.

Reiniciar y apagar

Los botones Start / Restart / Stop / Kill de Pterodactyl actúan sobre el proceso. Diferencias que importan:

• Restart de Pterodactyl mata el proceso y lo arranca de nuevo: recarga config.json y los mods. Tarda lo que tarde el servidor en levantar (uno o dos minutos con mods).
• #restart por RCON reinicia la partida sin bajar el proceso: no recarga config.json. Es más rápido y sirve para "limpiar" el escenario.
• #shutdown por RCON cierra el proceso; si el servidor está en Pterodactyl con reinicio automático (crash detection), vuelve solo.

La API de cliente

Pterodactyl tiene una API por usuario con la que se puede hacer todo lo que hace la interfaz: ver el estado, enviar señales de energía, leer y escribir archivos. Se genera en Account → API Credentials. La clave es de tu cuenta, hereda tus permisos, y se puede revocar en cualquier momento. El identificador del servidor es el código corto de 8 caracteres que aparece en la URL (/server/a1b2c3d4).

Con esos dos datos y la URL del panel, una herramienta externa puede reiniciar el servidor, leer config.json y aplicar cambios sin que entres a Pterodactyl. Reforger Ops usa exactamente eso: reinicio y apagado desde el panel, edición validada de config.json con copia de seguridad del archivo anterior (un JSON roto deja el servidor sin arrancar), lista de mods con nombre y tamaño desde el Workshop, e instalación del mod compañero en el perfil con un clic. La clave se guarda cifrada y nunca se muestra de vuelta.

Errores típicos

• El servidor no aparece en el navegador de servidores: puerto A2S sin allocation, o publicAddress/publicPort apuntando a otro lado.
• Loop de reinicios tras editar config.json: JSON inválido (una coma de más). Vuelve a la copia anterior.
• Mods que no cargan: el ID está mal copiado o el mod fue bloqueado/retirado del Workshop. Las dependencias no son el problema: el servidor las resuelve y las descarga solo, no hace falta listarlas en game.mods.

Dónde están los logs de verdad

Cuando un servidor se cae solo, la respuesta está en los logs, y encontrarlos en Pterodactyl tiene truco. El servidor crea una carpeta nueva por cada arranque, con nombre logs_<fecha>. La más reciente es la del proceso que está corriendo ahora: si el servidor se reinició, lo que explica la caída está en la anterior, no en la última.

Dentro de cada carpeta hay tres archivos que importan: console.log (todo lo que pasó), error.log (solo los errores) y crash.log si el proceso se murió de verdad. Y ojo con la ruta: los logs cuelgan de la carpeta que le pasas con -profile. El prefijo $profile: que aparece en la configuración apunta a una subcarpeta de esa, así que no es raro mirar en el sitio equivocado y concluir que no hay logs.

El console.log crece más rápido de lo que parece

En un servidor con gente y mods, el console.log llega a varios megas en un par de horas. El visor de archivos de Pterodactyl se niega a abrir archivos pasado cierto tamaño, así que justo los días en que hay algo que investigar es cuando no se puede abrir. La salida es bajarlo con el enlace de descarga en vez de abrirlo en el navegador, y mirar el final del archivo, que es donde está lo que pasó antes de caerse.

Un patrón que vale oro: si un mod está roto, el console.log se llena de líneas repetidas del tipo Failed to open o Wrong GUID con la ruta del mod dentro. No es una línea perdida: son cientos o miles, y eso es lo que lo separa del ruido normal de un servidor modeado.

Las dependencias de los mods se descargan solas

No hace falta listar en game.mods las dependencias de los mods que pones. El servidor las resuelve y las descarga al arrancar. Se ve en el propio log del servidor: aparecen descargas de mods que no están en la configuración, porque son dependencias de los que sí están.

Esto ahorra mucho trabajo con listas largas, y evita el error de quitar un mod y dejar sus dependencias sueltas en la configuración. Lo que sí hay que tener en cuenta: la versión nueva de un mod se baja al arrancar. Hasta el siguiente reinicio, el servidor sigue corriendo la versión vieja, aunque el Workshop ya muestre otra.