Servidor FiveM propio : ventajas frente a unirte a otro

Par Benjamin D. · PDG

7 de septiembre de 2026 · Mis à jour le 7 de septiembre de 2026 · Lecture 9 min

Índice

Administrar tu propio servidor FiveM cambia por completo la relación con el juego: dejas de ser un pasajero que acepta reglas ajenas y pasas a controlar el server.cfg, los recursos que se cargan, el modo OneSync, las ACE permissions y hasta el ritmo de los reinicios. Este artículo explica, desde el punto de vista técnico, qué ganas realmente al ponerte al mando.

Qué controlas tú y qué controla el administrador cuando juegas en un servidor FiveM ajeno

Cuando te conectas a una comunidad de terceros, tu experiencia depende de decisiones que no puedes tocar. La lista de recursos, el número de slots, la versión de los artifacts, el estado de OneSync, la frecuencia de reinicio y los límites de streaming ya están fijados. Si el resmon del servidor está saturado por un script mal escrito, tú solo notas el resultado: rubber banding, entidades que aparecen tarde, coches que se desincronizan.

La diferencia práctica en cinco puntos

Elemento técnico	Jugando en una comunidad ajena	Administrando tu propia instancia
`server.cfg`	Inaccesible	Editable línea por línea desde el panel
Recursos y scripts	Fijos, decididos por el staff	Tú eliges qué se hace `ensure` y en qué orden
OneSync	Configuración impuesta	`infinity`, `on` o desactivado según tu proyecto
Permisos	Dependes de la jerarquía existente	Defines principals y ACEs desde cero
Diagnóstico	Solo ves síntomas	Consola en vivo, logs, `resmon`, txAdmin

Ese salto de control es el que separa "jugar rol" de "construir una comunidad". Si tu proyecto ya tiene forma y necesitas una máquina con CPU Ryzen de alta frecuencia, NVMe y anti-DDoS incluido para soportarlo, la referencia técnica está en la página de alojamiento servidor FiveM de Fly-Serv.

server.cfg: el archivo que define tu servidor FiveM

Todo empieza y termina aquí. El server.cfg es el punto de entrada del framework: define identidad, red, seguridad y qué código se ejecuta. Un ejemplo mínimo pero realista:

# --- Red ---
endpoint_add_tcp "0.0.0.0:30120"
endpoint_add_udp "0.0.0.0:30120"

# --- Identidad ---
sv_hostname "Mi comunidad RP | ESX | Whitelist"
sv_projectName "MiProyecto"
sv_projectDesc "Rol serio, economia cerrada"
sets tags "roleplay, esx, es"
load_server_icon icon.png

# --- Capacidad y sincronizacion ---
sv_maxclients 48
set onesync infinity
set onesync_population true

# --- Seguridad ---
sv_scriptHookAllowed 0
sv_endpointPrivacy true
rcon_password "cadena-larga-y-aleatoria"
sv_licenseKey "TU_CLAVE_KEYMASTER"

# --- Recursos base ---
ensure mapmanager
ensure chat
ensure spawnmanager
ensure sessionmanager
ensure hardcap

# --- Permisos ---
add_ace group.admin command allow
add_principal identifier.fivem:1234567 group.admin
exec permissions.cfg

Las líneas que más impacto tienen

sv_maxclients: no lo pongas al máximo "porque suena bien". Cada slot activo consume CPU en el hilo principal. Es más sensato empezar en 32 o 48 y subir cuando los tiempos de tick estén estables.
rcon_password: si no vas a usar RCON, déjalo vacío. Si lo usas, una cadena de 24 caracteres aleatorios como mínimo.
sv_scriptHookAllowed 0: bloquea la inyección de scripthook del lado cliente. En rol es prácticamente obligatorio.
sv_endpointPrivacy true: evita exponer las IP de tus jugadores en la lista de conectados.
ensure vs start: ensure reinicia el recurso si ya estaba corriendo. Es la forma correcta de declararlos.

Orden de carga: el error que rompe frameworks

ESX y QBCore dependen de un orden estricto. El core debe cargarse antes que sus dependencias, y estas antes que los scripts de terceros. Una estructura sana en el server.cfg:

# 1. Base
ensure oxmysql
ensure es_extended        # o qb-core

# 2. Dependencias compartidas
ensure ox_lib
ensure ox_inventory
ensure menuv

# 3. Scripts de comunidad
ensure mi_trabajo_taxi
ensure mi_sistema_bandas

# 4. Mapas y streaming al final
ensure mi_mapa_comisaria

Si un recurso lanza Failed to load resource, casi siempre es un problema de orden o de dependencia declarada en el fxmanifest.lua. Desde la consola del panel puedes probar en caliente sin reiniciar todo:

refresh
ensure mi_sistema_bandas
stop mi_mapa_comisaria
restart es_extended

OneSync, streaming y rendimiento: donde se gana o se pierde la partida

OneSync es la capa de sincronización que permite superar los 32 jugadores del netcode clásico de GTA Online y mover la lógica de entidades al lado del servidor. Es el parámetro con más consecuencias de toda tu configuración.

Qué modo elegir

set onesync legacy: hasta 64 slots. Compatible con casi todo, pero limitado.
set onesync on (infinity): hasta 2048 slots teóricos, culling de entidades por distancia y control server-side real. Es el estándar actual para rol.
set onesync_population true/false: activa o desactiva el tráfico y peatones gestionados por el servidor. Desactivarlo baja notablemente la carga en mundos densos.

Con OneSync Infinity aparecen dos ajustes muy útiles cuando tu instancia empieza a llenarse:

set onesync_distanceCullVehicles true
set onesync_forceMigration true
set sv_enforceGameBuild 3095
set sv_enableNetworkedSounds false

sv_enforceGameBuild merece atención especial: fija el build de GTA V que tu instancia exige. Cambiarlo habilita DLC recientes (vehículos, ropa, interiores) pero puede romper recursos antiguos que dependen de índices de modelos anteriores. Cámbialo siempre con un respaldo hecho y en horario de baja actividad.

Medir antes de tocar

La herramienta clave es el monitor de recursos del cliente. Con el juego abierto y conectado:

/resmon 1     # muestra el consumo de cada recurso cliente
/netgraph     # latencia, packet loss y tiempos de red

La regla de campo: cualquier recurso que pase de 0,5 ms en estado de reposo es candidato a revisión. Suele tratarse de un bucle Citizen.CreateThread con Wait(0) donde bastaría un Wait(500). En el lado servidor, txAdmin te muestra el tiempo de tick: si sube de forma sostenida, el cuello de botella está en un script server-side o en consultas SQL sin índices.

Hardware y latencia

FiveM depende sobre todo de la frecuencia por núcleo, no del número de hilos: el bucle principal del servidor es esencialmente monohilo. Por eso una CPU Ryzen de alta frecuencia rinde mejor que un procesador con muchos núcleos lentos. El almacenamiento NVMe importa en la carga de assets streameados y en las consultas a MySQL. Y el anti-DDoS de la infraestructura te ahorra el escenario clásico de una comunidad rival tumbando tu instancia en pleno evento. Puedes ver la variedad de juegos disponibles en Todos nuestros servidores de juegos, incluido Servidor RedM si tu comunidad quiere una segunda ambientación.

Administración diaria: consola, permisos, respaldos y seguridad

Aquí es donde administrar tu propia instancia deja de ser un lujo y se convierte en trabajo real. Bien organizado, son 20 minutos al día.

Permisos con ACEs, no con listas improvisadas

El sistema de principals y ACEs de FiveM permite una jerarquía limpia. Un permissions.cfg tipo:

add_ace group.moderador command.kick allow
add_ace group.moderador command.clear allow
add_ace group.admin command allow
add_ace group.admin command.quit deny

add_principal identifier.license:abc123... group.admin
add_principal identifier.discord:987654321 group.moderador
add_principal group.admin group.moderador

Fíjate en command.quit deny: evita que un administrador apague la instancia por error desde el chat. Y prefiere el identificador license: frente a steam: o ip:, porque es estable y no depende de la plataforma.

Whitelist y control de acceso

Una whitelist bien montada elimina el 90 % del trabajo de moderación. Tres capas habituales:

Filtro por Discord: un recurso que consulta roles vía bot antes de permitir el deferrals.done().
Verificación de identificadores: rechazar conexiones sin license o con múltiples cuentas asociadas al mismo hardware.
Anticheat server-side: validar en el servidor cualquier acción con impacto económico. Nunca confíes en un evento enviado por el cliente.

-- Mal: el cliente decide cuanto dinero recibe
RegisterNetEvent('banco:ingresar', function(cantidad)
    Player(source).state.money = cantidad
end)

-- Bien: el servidor valida contra su propia fuente
RegisterNetEvent('banco:ingresar', function()
    local src = source
    local pago = CalcularPagoServidor(src)  -- logica server-side
    if pago > 0 then AnadirDinero(src, pago) end
end)

Respaldos: la base de datos es tu comunidad

Los assets se vuelven a descargar; los personajes de 300 horas, no. Las copias automáticas del panel cubren el sistema de archivos, pero conviene añadir un volcado de MySQL antes de cada actualización importante:

mysqldump -u fivem -p --single-transaction --routines \
  esx_db > /home/container/backups/esx_$(date +%F_%H%M).sql

Y antes de tocar el server.cfg en producción, guarda la versión que funciona:

cp server.cfg server.cfg.ok_$(date +%F)

Actualizaciones de artifacts

Los artifacts (el binario FXServer) se actualizan con frecuencia. La rutina segura es: respaldo completo, cambiar a la versión recomendada desde el panel, arrancar y revisar la consola en busca de warnings de recursos obsoletos. Si algo se rompe, vuelves al build anterior en un minuto. Los detalles de cada comando y variable están en la documentación oficial de FiveM.

Checklist semanal

Revisar tiempos de tick en txAdmin y picos en el gráfico de rendimiento.
Vaciar logs antiguos para no llenar el disco.
Verificar que la última copia automática se completó y es restaurable.
Comprobar recursos por encima de 0,5 ms en /resmon.
Rotar la contraseña RCON si varias personas tienen acceso al panel.
Auditar los add_principal: quitar a quien ya no esté en el staff.

Errores frecuentes y su causa real

Síntoma	Causa habitual	Acción
Conexión rechazada al entrar	`sv_licenseKey` caducada o IP no coincidente	Regenerar la clave en Keymaster
Pantalla infinita en "Loading screen"	Recurso con `deferrals` sin cerrar	Revisar el script de whitelist
Vehículos que desaparecen	Culling de OneSync demasiado agresivo	Ajustar `onesync_distanceCullVehicles`
Lag general con pocos jugadores	Bucle sin `Wait` en un recurso	Localizar con `/resmon 1`
Objetos custom invisibles	`fxmanifest.lua` sin `data_file` declarado	Revisar el manifest del mapa

Si quieres profundizar en optimización, moderación o configuración de otros títulos, hay más guías técnicas en el Blog de Fly-Serv.

Conclusión

Administrar tu propio servidor FiveM te da acceso a las tres palancas que de verdad definen la experiencia: el server.cfg, la selección de recursos y la configuración de OneSync. Con un panel Pterodactyl, copias automáticas y consola en vivo, cada problema deja de ser una queja en Discord y pasa a ser algo que puedes medir, entender y corregir en minutos.

FAQ

¿OneSync Infinity consume más recursos que el modo legacy?

Sí, porque traslada la gestión de entidades al lado del servidor, pero a cambio te da culling por distancia y control real sobre población y vehículos. Con una CPU de alta frecuencia, activar onesync infinity y desactivar onesync_population suele dar un resultado más estable que legacy con 60 jugadores.

¿Cómo sé qué recurso está causando lag en mi instancia?

Conéctate y ejecuta /resmon 1 para ver el consumo del lado cliente; ordena por milisegundos y marca todo lo que supere 0,5 ms en reposo. Para el lado servidor, revisa el gráfico de tiempos de tick de txAdmin y usa stop sobre recursos sospechosos uno a uno hasta que el tick se normalice.

¿Puedo cambiar el sv_enforceGameBuild sin romper mis scripts?

No siempre. Subir el build habilita DLC recientes, pero los recursos que dependen de índices de modelos antiguos pueden fallar. Haz una copia completa y un volcado de MySQL, cambia el valor, arranca y revisa la consola: los warnings te dirán qué recurso necesita actualización antes de volver a abrir al público.