Proxy inverso FiveM: para qué sirve realmente y cómo montarlo en un VPS

«Pon un proxy delante de tu servidor» es el consejo más repetido en los Discord de FiveM tras un ataque. A veces es correcto y a menudo incompleto. Un proxy inverso cambia lo que ven los atacantes, no la cantidad de tráfico que pueden enviar. Esta guía explica qué protege, cuándo es mejor prescindir de él y cómo montarlo bien en un VPS.

1. Qué hace un proxy inverso

Es una máquina intermedia entre los jugadores y tu servidor. Los jugadores se conectan a la dirección del proxy, y este reenvía el tráfico al servidor real, llamado servidor de origen, por un canal privado. Para los jugadores y la lista pública, solo existe la dirección del proxy.

2. Qué protege realmente

• La dirección de tu servidor de origen, mientras nunca se haya publicado. Nadie puede atacar directamente una máquina cuya dirección desconoce.
• Un servidor alojado sin protección: en casa o con un proveedor sin filtrado. El proxy, en un proveedor protegido, recibe el golpe en su lugar.
• Varios servidores tras una sola entrada, que puedes mover sin cambiar la dirección que dan los jugadores.

3. Sus límites, de los que se habla menos

• Un proxy no filtra nada por sí mismo. Sin protección de red, un ataque volumétrico lo satura y tu servidor queda inaccesible como antes. El proxy debe estar detrás de un Anti-DDoS de red.
• Añade latencia: un rodeo por otra máquina. En el mismo país que el origen, son unos milisegundos. Mal situado, los jugadores lo notarán.
• Añade un punto de fallo. Si el proxy cae, el servidor queda inaccesible aunque funcione perfectamente.
• La dirección de origen se filtra con facilidad: un registro DNS antiguo, un script que llama a una API externa, una captura de la consola. Una sola filtración y el proxy deja de servir.
• Complica la administración: según el método, el servidor puede dejar de ver las direcciones reales de los jugadores, lo que afecta a los baneos por IP y a algunos anti-cheats.

4. ¿Proxy o servidor protegido directamente?

Un proxy tiene sentido si tu servidor está en casa o en un proveedor sin Anti-DDoS y no puedes moverlo, si quieres varios servidores tras una sola dirección y si estás dispuesto a mantener una máquina y un túnel más.

Un servidor protegido basta si puedes alojar el servidor de juego en una máquina filtrada en origen, si quieres la latencia más baja posible y si prefieres una arquitectura simple.

Es lo que hemos elegido para nuestros servidores de juego: el Anti-DDoS filtra el tráfico en la red antes de que llegue a la máquina. Consulta nuestra página de protección FiveM. Si estás en el primer caso, sigue leyendo.

5. La arquitectura

• Un VPS proxy en un proveedor con Anti-DDoS de red, idealmente en el mismo país que el origen. Consume poca CPU, así que un VPS NVMe de entrada es suficiente.
• Un túnel WireGuard entre el proxy y el origen: el tráfico va cifrado y el origen no necesita puertos abiertos a Internet.
• Nginx en el proxy, con su módulo stream, que reenvía el puerto 30120 en TCP y UDP hacia el origen por el túnel.

En los ejemplos, el proxy tiene la dirección 10.8.0.1 en el túnel y el servidor de origen 10.8.0.2.

6. El túnel WireGuard

Instala WireGuard en las dos máquinas y genera un par de claves en cada una:

apt update && apt install -y wireguard
cd /etc/wireguard && umask 077
wg genkey | tee private.key | wg pubkey > public.key

En el proxy, /etc/wireguard/wg0.conf:

[Interface]
Address = 10.8.0.1/24
ListenPort = 51820
PrivateKey = <clave privada del proxy>
[Peer]
PublicKey = <clave pública del origen>
AllowedIPs = 10.8.0.2/32

En el servidor de origen:

[Interface]
Address = 10.8.0.2/24
PrivateKey = <clave privada del origen>
[Peer]
PublicKey = <clave pública del proxy>
Endpoint = IP_PUBLICA_DEL_PROXY:51820
AllowedIPs = 10.8.0.1/32
PersistentKeepalive = 25

El origen inicia la conexión gracias a PersistentKeepalive, así que no necesita ningún puerto de entrada, incluso detrás de un router doméstico. Arranca el túnel en ambos lados con systemctl enable --now wg-quick@wg0 y comprueba con ping 10.8.0.2 desde el proxy.

7. El reenvío Nginx en el proxy

apt install -y nginx libnginx-mod-stream

Añade esto al final de /etc/nginx/nginx.conf, fuera del bloque http:

stream {
    upstream fivem_tcp { server 10.8.0.2:30120; }
    upstream fivem_udp { server 10.8.0.2:30120; }
    server {
        listen 30120;
        proxy_pass fivem_tcp;
    }
    server {
        listen 30120 udp reuseport;
        proxy_pass fivem_udp;
        proxy_timeout 60s;
    }
}

nginx -t && systemctl reload nginx
ufw allow 30120 comment 'FiveM via proxy'
ufw allow 51820/udp comment 'WireGuard'

En el servidor de origen, cierra el puerto 30120 a Internet y permite solo el túnel con ufw allow in on wg0 to any port 30120. Así nadie puede saltarse el proxy.

8. El server.cfg del servidor de origen

FiveM debe saber que está detrás de un proxy, para anunciar su dirección en la lista pública y confiar en el reenvío. Las directivas principales son:

set sv_forceIndirectListing true
set sv_listingHostOverride "play.tuservidor.com"
set sv_proxyIPRanges "10.8.0.0/24"
set sv_endpoints "IP_PUBLICA_DEL_PROXY:30120"

Apunta tu dominio, play.tuservidor.com en este ejemplo, a la dirección del proxy, nunca a la del origen.

9. Comprobar que no hay fugas

1. Entra en el juego con connect play.tuservidor.com:30120: el servidor debe responder con normalidad.
2. Desde otra conexión, intenta llegar directamente a la dirección de origen en el puerto 30120: debe fallar.
3. Busca tu dirección de origen en el historial DNS público de tu dominio. Si aparece, cámbiala, porque ya se conoce.
4. Vigila la latencia de los jugadores los primeros días. Si ha aumentado claramente, acerca el proxy al origen.

¿Problemas al arrancar? Consulta los errores de arranque más frecuentes.

Preguntas frecuentes