Antes de empezar
Ten a mano la dirección y el puerto de juego asignados, la hora del fallo, el estado del panel y los mensajes relevantes de consola. Anota los últimos cambios de recursos. Retira claves y credenciales de cualquier registro que compartas con soporte.
Confirmar que el juego terminó de arrancar
Un proceso iniciado no siempre significa que el servicio esté listo. Revisa la consola y busca errores de configuración, recursos o preparación de txAdmin. Usa el puerto de juego mostrado en el panel: el puerto administrativo de txAdmin no lo sustituye. En un nodo compartido no des por hecho que la instancia utiliza el puerto estándar.
Registra la etapa mostrada y los errores en la consola F8. La falla al conectarse, una descarga detenida y una pantalla de carga después de las descargas apuntan a componentes diferentes. Cambie una cosa a la vez y registre lo que muestra cada prueba.
Comparar conexión directa y listado
Prueba desde F8 una conexión directa a la dirección de juego asignada y compara el resultado con la entrada de la lista. Si solo funciona una vía, anota esa diferencia. No cambies anuncios, IP o puertos al azar: revisa primero los endpoints documentados y evita utilizar la dirección de otra instancia que esté en la misma máquina.
Verifique que FXServer se haya iniciado, que sus puntos finales coincidan con la asignación y que las reglas de red cubran los protocolos requeridos. Una prueba exitosa de TCP no establece que UDP funcione. Para hosting administrado, use la configuración del panel y solicite una verificación de asignación antes de cambiar las reglas del firewall del host.
Separar HTTP de la conexión de juego
Las descargas y endpoints HTTP pueden responder mientras la conexión UDP falla. Comprueba por separado los archivos, la conexión y el acceso administrativo. Un resultado correcto en info.json no demuestra que el camino UDP funcione. Tampoco una comprobación TCP permite validar todo el tráfico del juego detrás de un proxy.
Reproduzca el problema en una copia de prueba con un conjunto de recursos mínimo y luego agregue extensiones gradualmente. No desactive aleatoriamente los scripts en un servidor comunitario en vivo. Verifique el tamaño de los archivos y el espacio libre: mover un recurso grande a un caché no repara sus errores de script o de dependencia.
Revisar los cambios de recursos
Si el problema apareció tras una actualización, conserva el estado actual y analiza la última modificación con sus dependencias y orden de arranque. Usa mensajes concretos de consola. Cambia una cosa cada vez y prueba en una ventana de mantenimiento. Vaciar todos los recursos o el caché del cliente no arregla una dirección o un reenvío incorrectos.
Compare direcciones anunciadas, puntos finales de conexión y destinos de archivos con la documentación de su versión. Una dirección de origen expuesta puede eludir la protección remota. Confirme el enrutamiento y el tráfico cubierto antes de restringir el origen: bloquear un servicio legítimo, el tráfico de voz o un puerto requerido puede empeorar la interrupción.
Comprobar el proxy y el origen
Los endpoints publicados, los orígenes autorizados y las reglas de reenvío deben coincidir con la topología real. La documentación de Cfx.re diferencia estas funciones y sus requisitos. No declares todo Internet como proxy de confianza ni desactives la protección para hacer una prueba más cómoda. Cualquier comparación directa debe ser controlada y acordada con el operador.
Antes de cambiar los artefactos, verifique los requisitos previos del marco y los recursos, haga una copia de seguridad y pruebe la versión elegida. FiveM para GTA V Enhanced introduce cambios que pueden entrar en conflicto con las configuraciones de Legacy. La disponibilidad de un artefacto más nuevo no certifica automáticamente que su instalación, scripts o plantilla de alojamiento sean compatibles.
Entregar un caso reproducible
Compara, cuando sea posible, dos conexiones de Internet independientes y averigua qué jugadores están afectados. Guarda la hora, la dirección y las líneas relevantes de consola. Un timeout no demuestra un ataque DDoS: contrasta tráfico, filtros y carga del servidor. Con un procedimiento reproducible, soporte podrá distinguir un fallo local, de aplicación o del camino de red.
Si sospecha de un ataque, solicite correlación con eventos de mitigación o mediciones de red. Un tiempo de espera por sí solo no demuestra un ataque DDoS. Evite reinicios repetidos, pruebas de carga improvisadas y desactivación global de la seguridad: estos pueden ocultar la causa o crear otra interrupción.
Qué hacer en tu caso
| Situación | Próximo paso |
|---|---|
| El proceso aún no está listo | Revisa el arranque y la configuración; espera a que el juego esté disponible antes de evaluar el acceso público. |
| Descargas correctas, conexión fallida | Comprueba la dirección asignada y el reenvío UDP. La respuesta HTTP no valida todo el recorrido. |
| Fallo tras cambiar un recurso | Guarda una copia y prueba esa modificación con sus dependencias en un mantenimiento anunciado. |
Fuentes oficiales
Estas fuentes explican los protocolos y ajustes mencionados. Comprueba siempre la documentación de tu versión.