Cómo hacer que tu dominio aparezca en el navegador de servidores de FiveM¶

Esta guía explica, de cabo a rabo, cómo hacer que tu dominio propio (por ejemplo play.example.com) aparezca en el navegador de servidores de FiveM cuando los jugadores buscan tu servidor, y también cómo conseguir que connect play.example.com funcione desde la consola F8.

Vamos a cubrir:

Lo que Zaroz Cloud configura solo cuando enlazas un dominio a tu pedido.
Las líneas que tienes que añadir en server.cfg para que el dominio aparezca realmente en la lista (y no la IP cruda).
Cómo funciona por dentro el backend de listado de cfx.re, para que puedas depurarlo cuando algo no va.
La configuración avanzada (con tu propio proxy inverso) si quieres ocultar del todo la IP por protección DDoS.

Cómo llega un dominio a la lista de servidores en realidad¶

Antes de tocar nada, necesitas tener clara una idea: FiveM hace dos cosas totalmente distintas por dos caminos distintos.

Entrar al servidor escribiendo connect <nombre> en la consola F8. Esta vía usa DNS. El cliente busca primero un registro SRV (_cfx._udp.<tu-dominio>) para sacar el puerto, después un registro A para sacar la IP, y se conecta. En ningún momento le pregunta nada al backend de listado de cfx.re.
Encontrar (o entrar al) servidor por el navegador interno del juego. Esta vía usa el backend de listado de cfx.re. El backend cada cierto tiempo pinguea a tu servidor en una URL tipo https://<host>/dynamic.json para refrescar los datos de la lista. Cuando un jugador pulsa "Conectar" en el navegador, el backend le pasa al cliente un valor connectEndPoints que le dice a dónde tiene que conectarse. Ese connectEndPoints es justo lo que decide si el jugador ve tu IP o tu dominio.

Las dos vías son independientes: los registros SRV hacen que funcione el comando connect, pero no afectan en absoluto a lo que muestra el navegador de servidores. Para controlar el navegador tienes que decirle a tu propio servidor qué dominio anunciar al backend de listado.

Las reglas oficiales de cómo el cliente resuelve un destino de conexión están resumidas en la documentación de Cfx.re sobre proxy:

Los hosts a pelo (p. ej. play.example.com) se resuelven a http://play.example.com:30120/.
Los hosts con puerto (p. ej. play.example.com:30121) se resuelven a http://play.example.com:30121/.
Las URLs con esquema (p. ej. https://play.example.com/) se usan tal cual, con los puertos por defecto del esquema (80/443).

Esta última regla es la más importante para la lista: si quieres que la lista le entregue a los jugadores una URL limpia tipo https://play.example.com/ (sin puerto y sin tener que escribir el esquema), el backend de listado tiene que poder llegar a tu servidor justo por esa URL.

Qué hace Zaroz Cloud por ti¶

Cuando enlazas un dominio a tu pedido desde el panel (Página del pedido → pestaña External Access → Dominio personalizado):

Cogemos el parent domain que has elegido (p. ej. play.zaroz.cloud) y el subdominio que escribes (p. ej. myserver), formando un host completo tipo myserver.play.zaroz.cloud.
Por la API de Cloudflare, creamos un registro A para ese host apuntando a la IP pública que tenemos reservada para tu pedido.
Si tu pedido es de FiveM, también creamos un registro SRV en _cfx._udp.<tu-host> apuntando de nuevo al host con el puerto UDP de juego de tu pedido. (En Minecraft es _minecraft._tcp.<host>, en Factorio _factorio._udp.<host>.)
Un job de reconciliación en segundo plano mantiene los dos registros sincronizados si tu pedido se mueve a otro nodo o cambia de puerto.

El efecto neto de todo esto es que en cuanto el dominio queda enlazado, los jugadores ya pueden entrar con connect myserver.play.zaroz.cloud desde la consola F8, aunque no escriban puerto. El SRV le dice al cliente de FiveM por qué puerto UDP entrar, y el A le da la IP.

Lo que esto no hace por sí solo: no cambia lo que muestra el navegador de servidores. Eso sigue requiriendo cambios en tu server.cfg.

Configuración mínima en `server.cfg` para el navegador de servidores¶

Si solo quieres que funcione el connect por SRV (escribir la dirección en la consola F8), no tienes que tocar server.cfg para nada. Con los registros que creamos basta.

Si quieres que el navegador de servidores muestre tu dominio cuando los jugadores busquen tu servidor, mete estas líneas en server.cfg, hacia el principio:

# Hace como si no tuvieras IP estática. Fuerza al backend a usar
# connectEndPoints/sv_listingHostOverride en vez de filtrar la IP.
sv_forceIndirectListing true

# Le dice al backend de listado a qué host pegar y qué host pasarle
# al jugador cuando pulsa "Conectar".
sv_listingHostOverride "http://myserver.play.zaroz.cloud:30120/"

Usa la forma URL completa, no solo el host:

El esquema (http://) le dice al backend que tu servidor habla HTTP plano, no HTTPS. El endpoint por defecto de FXServer es HTTP, no HTTPS.
El puerto (:30120) es el puerto real de juego/HTTP de tu contenedor. Si lo omites, el backend asume el 80, que no es el puerto donde FXServer escucha, y el heartbeat falla.

En Zaroz Cloud, ese <puerto> es el valor que aparece arriba del todo de tu server.cfg, en la línea endpoint_add_tcp "0.0.0.0:<puerto>" que nuestro entrypoint reescribe en cada arranque del contenedor. También lo tienes a mano en el panel, en Página del pedido → External Access → Conexión de jugadores:

Panel de conexión de jugadores con la dirección y el puerto del servidor

La parte después de los dos puntos en Dirección del servidor es el puerto que tienes que meter en sv_listingHostOverride.

Tras reiniciar, el master tarda unos minutos en recoger el override y empezar a anunciar tu host en la lista. En la sección "Cómo comprobar que ha funcionado" más abajo lo verificamos.

Por qué hace falta cada línea¶

`sv_forceIndirectListing true`¶

De la documentación oficial: "prevents the server list from advertising your server using its actual IP" (impide que la lista anuncie tu servidor usando su IP real).

Si está apagado, la lista sigue publicando la IP cruda diga lo que diga sv_listingHostOverride, porque el backend asume que cualquier cliente puede conectarse directamente a la IP de origen y que el override solo es para el heartbeat suyo. Con esto activado se suprime la IP, y el campo connectEndPoints lleva el host en su lugar.

`sv_listingHostOverride`¶

De la documentación oficial: "makes the server list backend request https://server1.example.com/ instead of the default" (hace que el backend pida https://server1.example.com/ en lugar de la dirección por defecto).

Cumple dos papeles a la vez:

A dónde te pinguea el backend. El heartbeat de cfx.re pega a <host>/dynamic.json, <host>/info.json y <host>/players.json en esta URL.
Qué ven y a qué se conectan los jugadores. Cuando el listado indirecto está activado, este mismo valor se devuelve a los clientes como connectEndPoints, que es lo que usa el botón "Conectar" del navegador.

Por ese doble papel, el valor tiene que ser alcanzable desde internet. En Zaroz, el endpoint HTTP de tu contenedor está atado a 0.0.0.0:<tu-puerto> y tu registro A ya apunta el host a la IP correcta, así que http://<host>:<puerto>/ funciona sin infraestructura adicional.

¿Y `sv_listingIpOverride`?¶

Normalmente no hace falta tocarlo en Zaroz Cloud. De la documentación oficial: "this value is only needed if the server list backend can't guess the IP to query itself, and is not provided to any front-end connection" (solo hace falta si el backend de la lista no puede deducir solo qué IP consultar, y no se le pasa a ninguna conexión de cliente).

Nuestro entrypoint ya escribe el sv_listingIpOverride correcto para la IP pública que te tenemos reservada, en cada arranque del contenedor. Es lo que usa el master para encontrar tu dynamic.json cuando no hay host override. Con sv_listingHostOverride puesto, el override de IP queda en redundante pero inofensivo.

¿Y `sv_endpoints`?¶

sv_endpoints es "the actual endpoint your server is hosted on, or one or multiple server endpoint proxies" (el endpoint real donde está tu servidor, o uno o varios proxies de endpoint).

En un montaje a pelo sin proxy no hace falta: el backend de listado va a usar la IP a la que te pinguea y el puerto que descubre. Solo lo pones cuando metes tu propio proxy inverso o túnel anti-DDoS entre los jugadores y FXServer, y hay que decirle a los jugadores que se conecten a la IP y puerto del proxy, no a los de FXServer.

Registros DNS completos¶

Por si quieres comprobar lo que hemos puesto del lado de Cloudflare, esto es exactamente lo que tienes con un dominio personalizado bien montado en Zaroz:

;; Registro A
myserver.play.zaroz.cloud.   60   IN   A   188.213.7.49

;; Registro SRV (FiveM)
_cfx._udp.myserver.play.zaroz.cloud.  60  IN  SRV  0 0 32541 myserver.play.zaroz.cloud.

Campos, por orden: prioridad (0), peso (0), puerto (el puerto UDP de juego de tu pedido, p. ej. 32541) y target (tu host, terminando en punto).

La IP y el puerto son ejemplo: van a reflejar lo que el kernel tenga asignado a tu pedido en el momento de crear el registro. Si tu pedido se mueve a otro nodo o le reasignamos el puerto, el job de reconciliación reescribe los dos registros.

Cómo comprobar que ha funcionado¶

Tras reiniciar tu servidor con el server.cfg nuevo, tienes tres formas de ver que todo está bien.

1. Tirar de los endpoints en el navegador¶

Estos deberían devolverte JSON (o como mínimo HTTP 200):

http://<tu-dominio>:<tu-puerto>/info.json
http://<tu-dominio>:<tu-puerto>/players.json
http://<tu-dominio>:<tu-puerto>/dynamic.json

Si alguno se queda colgado o da error de conexión, el master tampoco va a poder llegar. Revisa el firewall y comprueba que la URL de sv_listingHostOverride cuadra con lo que tu contenedor escucha de verdad.

2. Mirar la consola del servidor¶

Después del arranque, busca líneas de log de [citizen-server-impl]. Un servidor sano acaba logueando heartbeats correctos. Si te aparece Server list query returned an error: server request failed for endpoint http://<host>:<puerto>/dynamic.json, es que el master ha intentado llegar al override y ha fallado. La causa más típica está cubierta en la guía del error de Server list query (caché de license key con retraso).

3. Tirar de la API pública de servidores¶

Vete a https://servers.fivem.net/api/servers/single/<tu-cfx-id> (el cfx ID es la cadena corta alfanumérica que sale en la URL del listado in-game) y busca el campo connectEndPoints en el JSON. Una vez se propague el override, ahí tiene que aparecer tu dominio, no la IP cruda.

Avanzado: con tu propio proxy inverso¶

La configuración básica de arriba oculta tu IP en la lista de servidores, pero un atacante decidido todavía puede sacarla pegando paquetes al puerto de juego directamente. Si quieres ocultar la IP del todo (por ejemplo, detrás de un túnel de Cloudflare Spectrum o un nginx propio en otra IP distinta), necesitas un proxy inverso de verdad.

Layout de referencia, adaptado de la documentación oficial de proxy y del gist de la comunidad con nginx:

# Proxy a nivel HTTP: 443 → HTTP del puerto de juego de FXServer
upstream fivem_http {
    server <tu-ip-de-zaroz>:<tu-puerto>;
}

server {
    listen 443 ssl http2;
    server_name myserver.example.com;

    ssl_certificate     /etc/letsencrypt/live/myserver.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/myserver.example.com/privkey.pem;

    location / {
        proxy_pass http://fivem_http;
        proxy_set_header Host             $host;
        proxy_set_header X-Real-IP        $remote_addr;
        proxy_set_header X-Forwarded-For  $remote_addr;
        proxy_http_version 1.1;
    }

    location /files/ {
        proxy_pass        http://fivem_http$request_uri;
        proxy_cache       assets;
        proxy_cache_valid 1y;
    }
}

# Proxy a nivel stream: TCP + UDP 30120 → puerto de juego de FXServer
stream {
    upstream fivem_game {
        server <tu-ip-de-zaroz>:<tu-puerto>;
    }
    server {
        listen 30120;
        proxy_pass fivem_game;
    }
    server {
        listen 30120 udp reuseport;
        proxy_pass fivem_game;
    }
}

Con este proxy delante, el server.cfg queda así:

sv_forceIndirectListing true
sv_listingHostOverride  "https://myserver.example.com/"
sv_endpoints            "<tu-ip-de-proxy>:30120"
sv_proxyIPRanges        "<tu-ip-de-proxy>/32"

Dos cosas a tener en cuenta de este montaje avanzado:

No puedes reutilizar el subdominio que te da Zaroz (p. ej. myserver.play.zaroz.cloud) para esto, porque ese registro A ya está apuntando a la IP de tu contenedor y lo manejamos nosotros automáticamente. Usa un dominio tuyo (uno que controles tú, con el DNS alojado en Cloudflare o en donde sea).
sv_proxyIPRanges es obligatorio, si no FXServer rechaza la cabecera X-Real-IP que mete el proxy, y además mantiene el rate limiter por IP pegando contra la única IP de tu proxy, que satura enseguida.

Errores típicos¶

Olvidar el esquema o el puerto en sv_listingHostOverride. Poner sv_listingHostOverride "myserver.play.zaroz.cloud" (solo el host) hace que el backend intente http://myserver.play.zaroz.cloud:30120/ aunque tu pedido use otro puerto, y eso falla. Usa siempre la forma URL completa, con esquema y puerto correctos.
No poner sv_forceIndirectListing true. Sin esto, tu IP sigue filtrándose en la lista aunque tengas puesto el override, porque el backend trata sv_listingHostOverride como cosa interna suya y para los clientes sigue anunciando la IP cruda.
Esperar que los registros SRV arreglen el navegador. Los SRV solo afectan al connect por F8. El navegador de servidores usa el backend de listado, que solo respeta sv_listingHostOverride y sv_forceIndirectListing.
Propagación de DNS. Cloudflare propaga rápido (normalmente en menos de un minuto), pero el backend de listado de cfx.re tiene su propia caché. Cuenta con unos minutos tras cualquier cambio de configuración antes de que el nuevo connectEndPoints salga en la API pública.

Cuándo escribirnos¶

Si has seguido la guía y:

Los endpoints (/info.json, /dynamic.json, /players.json) responden bien en el navegador, y
En el navegador de servidores tu servidor sigue saliendo con la IP cruda, o
El connectEndPoints de https://servers.fivem.net/api/servers/single/<cfx-id> vuelve a la IP tras reiniciar,

mándanos tu server.cfg (con el rcon_password y el sv_licenseKey tachados), el ID de cfx.re de tu servidor y el ID de tu pedido. Comprobamos si el backend de listado nos está llegando bien y confirmamos que por nuestro lado no hay nada que pise tu override.