Antes de empezar
Anota direcciones, puertos, versión de artifacts y servicios públicos. Guarda configuración y lista de fuentes autorizadas del proxy o filtro. Prepara una ventana de mantenimiento y una reversión verificable antes de modificar cómo llegan los jugadores al origen.
Inventariar lo que se publica
Distingue dirección de juego, listado, descargas y administración. Si solo proteges un acceso, el resto sigue necesitando evaluación. Usa los puertos que asigna el panel: txAdmin no reemplaza el puerto del juego. En un nodo compartido no se pueden escoger puertos de otras instancias ni añadir servicios sin ajustarlos al esquema del operador.
Verifique también las direcciones de dominio, direcciones públicas antiguas y puntos finales anunciados por FXServer. Un servicio secundario puede exponer el origen incluso cuando el enlace principal utiliza un proxy. Utilice este inventario para establecer el alcance con el proveedor.
Validar TCP y UDP
Comprueba por separado entrada al juego, archivos y gestión. Una respuesta HTTP o un puerto TCP abierto no validan por completo el camino UDP. Un proxy HTTP cubre la parte configurada para HTTP; el juego requiere su tratamiento de red y transporte. Pide una descripción de la topología antes de interpretar L7 como protección total de FiveM.
Si utiliza un caché de archivos, verifique los destinos y las condiciones de acceso. La configuración del proxy y del archivo depende de la versión de FXServer. Es posible que falte una configuración en la documentación más reciente en un artefacto más antiguo: confirme la disponibilidad antes de cambiar la configuración.
Aplicar ajustes oficiales de proxy
Cfx.re documenta proxy y distribución de archivos. Los ajustes deben corresponder a la versión de artifacts y a los endpoints reales. No copies sin revisar una guía de otra versión. Limita los proxies de confianza a fuentes autorizadas: confiar en todo Internet elimina esa separación. Define qué conexiones deben funcionar después y compruébalas de forma controlada.
Mantenga listas de fuentes confiables documentadas y precisas. Una asignación global o una dirección de proxy incorrecta pueden socavar la protección; un bloque mal colocado puede impedir que los jugadores se unan. La rotación de un IP o un puerto no reemplaza la protección de origen y no debe describirse como automático sin un mecanismo entregado.
Revisar el acceso directo al origen
Un atacante puede evitar el intermediario si conoce un origen desprotegido accesible. Revisa DNS, URLs de recursos y puertos adicionales. Cambiar la IP pública no borra automáticamente los caminos conocidos. Restringe el origen solo después de confirmar fuentes y retorno. La rotación automática de IP solo existe como función cuando está documentada y configurada en el servicio concreto.
No exponga públicamente una base de datos o una herramienta de administración sin una necesidad identificada y controles adecuados. El panel de alojamiento y txAdmin son entornos separados; proteger a uno no garantiza la seguridad del otro. Mantener el software y revisar el acceso después de cambios de equipo.
Asegurar recursos y eventos
La protección de red no sustituye validaciones de servidor. Comprueba permisos, límites y eventos que generan trabajo; los valores enviados por un cliente no deben aceptarse sin verificar. Relaciona los errores con carga de scripts y base de datos. Un recurso costoso puede parecer un problema de conexión; más RAM o un filtro diferente no corrigen automáticamente ese código.
Monitoree errores repetidos y operaciones que se vuelven costosas bajo carga. Pruebe los cambios en una copia, conserve versiones anteriores y administre dependencias. Los marcos y recursos requieren mantenimiento; Agregar protección no hace que los scripts sean seguros automáticamente.
Comprobar el recorrido del jugador
Tras un cambio relevante, prueba listado, conexión, archivos y juego con accesos independientes. Registra hora y carga para comparar. Un test de la web no demuestra latencia UDP. Los 15 Tbps son capacidad agregada aguas arriba, no el puerto de tu servidor. Confirma alcance y límites concretos; no hagas pruebas intensivas que afecten a otras instancias sin coordinación.
Durante un incidente, retenga la hora, las redes afectadas, los mensajes y los eventos de mitigación disponibles. Distinguir saturación, falsos positivos, fallas de recursos y errores de administración. Coordine pruebas activas con el proveedor en lugar de enviar tráfico de carga improvisado a producción.
Qué hacer en tu caso
| Situación | Próximo paso |
|---|---|
| Solo HTTP está protegido | Revisa también TCP/UDP y accesos directos al origen. Una web accesible no cubre todo el juego. |
| Falla tras cambiar una regla | Contrasta fuentes y retorno con el diseño y utiliza la reversión preparada. |
| Red normal, juego bloqueado | Perfila recursos, eventos y base de datos junto con las medidas de red. |
Fuentes oficiales
Estas fuentes explican los protocolos y ajustes mencionados. Comprueba siempre la documentación de tu versión.