Saltar al contenido principal

Autoalojar el paquete de recursos

ResourcePackManager incluye su propio pequeño servidor HTTP. Cuando autoHost: true (el valor por defecto) y preferSelfHost: true (el valor por defecto), el plugin intenta alojar el paquete fusionado desde la misma JVM que el propio servidor de Minecraft — sin host de archivos externo, sin servidor web separado, sin pegar URLs manualmente.

Esta página cubre cómo funciona esa ruta de autoalojamiento, qué hacen las comprobaciones de cordura, cómo se eligen el puerto y el hostname, y qué configurar cuando los valores por defecto no encajan con tu configuración.

Para colocar un proxy inverso HTTPS delante de RSPM y conservar la entrega automática, utiliza selfHostExternalUrl como se describe a continuación. Utiliza autoHost: false solo cuando otro sistema se encargue tanto del alojamiento como de la entrega a jugadores.

Árbol de decisión de entrega​

Cuando un jugador se conecta, RSPM elige una URL de entrega usando esta precedencia:

La entrega automática normal requiere autoHost: true. Con autoHost: false, solo la anulación explícita selfHostForce: true envía una URL.

  1. selfHostForce: true — directo al autoalojamiento, sin sondeos ni subida remota. Principalmente para probar esta ruta. Anula autoHost y selfHostEnabled; la validación de la URL y el inicio del servidor HTTP deben seguir completándose correctamente.
  2. preferSelfHost: true Y selfHostEnabled: true: intentar autoalojamiento con las comprobaciones siguientes, también en backends de proxy. Si alguna falla, usar alojamiento remoto.
  3. En caso contrario — reutiliza o sube el paquete a https://magmaguy.com/rsp/ y anuncia esa URL. Si falla la inicialización, la comprobación SHA1 o la subida, intenta el autoalojamiento verificado (con selfHostEnabled: true). SESSION_NOT_FOUND también borra la sesión remota para que un intento posterior pueda inicializarla de nuevo. Este respaldo automático ejecuta las mismas comprobaciones que el autoalojamiento preferente; si ambas rutas fallan, no se anuncia ninguna URL de entrega nueva.

El host remoto acepta paquetes Java de hasta 50.000 KiB (51.200.000 bytes). RSPM comprueba el tamaño antes de subirlo. Un paquete más grande nunca se sube: la consola muestra Automatic hosting skipped: resource pack is <size> bytes; the limit is 51200000 bytes. Después, RSPM deja de usar el alojamiento remoto para ese paquete y sigue reintentando el autoalojamiento verificado (con selfHostEnabled: true) hasta que el alojamiento se reinicie por un paquete nuevo o una recarga. Reduce el tamaño del paquete o haz accesible el autoalojamiento y después ejecuta /rspm reload.

Una vez que tiene una URL, RSPM usa la API de varios paquetes de Minecraft, de modo que su paquete Java puede coexistir con otros paquetes enviados por el servidor. El descriptor actual del plugin de Bukkit requiere Minecraft 1.21.4 o posterior.

Las tres comprobaciones de validez​

RSPM ejecuta estas comprobaciones en orden antes de elegir el autoalojamiento automático, incluido el respaldo tras un fallo del alojamiento remoto. Solo selfHostForce: true las omite:

Capa 1: comprobación heurística del host externo resuelto​

Si el host resuelto (consulta «Detección del host externo») es RFC1918 (10.*, 172.16-31.*, 192.168.*), loopback (127.* o localhost), link-local (169.254.*) o no especificado (0.0.0.0), se descarta el autoalojamiento. También se rechazan las direcciones IPv6 no especificadas, loopback, link-local, site-local y unique-local. Es una comprobación heurística del texto del host; los nombres de host aún deben superar las comprobaciones de descarga siguientes.

Esto detecta el modo de fallo muy común de "la búsqueda en ipify falló, recurrió a la IP de LAN".

Capa 2: descargas locales y de la URL anunciada​

RSPM envía una solicitud GET con un rango de bytes primero a http://127.0.0.1:<port>/rspm.zip y después a la URL exacta que recibirían los jugadores. Compara hasta el primer KiB con el paquete local. Acepta HTTP 200 o 206; las longitudes indicadas deben coincidir y una respuesta 206 debe incluir el Content-Range esperado. Rechaza las redirecciones. Esto detecta:

  • colisiones de enlace de puerto (otra cosa ocupa el puerto elegido)
  • archivo de paquete faltante (la ruta está registrada pero el zip aún no está en disco)
  • rutas incorrectas, páginas de error HTML o bytes de otro paquete
  • una URL anunciada que el propio servidor no puede descargar, incluidos fallos de NAT loopback

Cada conexión y lectura tiene un tiempo límite de 3 s, con un plazo independiente de 3 s para leer la muestra. Son comprobaciones de muestras acotadas, no descargas completas del cliente.

Capa 3: sondeo de accesibilidad externa​

Hace POST de la URL anunciada a POST /rsp/probe en el hoster de magmaguy.com. El hoster obtiene la URL desde un punto de observación público (con protecciones SSRF y un timeout ajustado) e informa de vuelta si es accesible.

Detecta el modo de fallo de producción más común: el servidor tiene una IP pública pero el puerto HTTP no está reenviado en el router o el firewall. La Capa 2 pasa (el servidor responde en 127.0.0.1), pero ningún cliente real podría descargar nunca el paquete.

Política de decisión sobre los resultados del sondeo:

  • reachable=true con HTTP 200 o 206 → el sondeo pudo acceder a la URL desde su ubicación pública. Se elige el autoalojamiento.
  • reachable=false u otro estado HTTP → la verificación falla. Se retira la URL Java candidata y se intenta el alojamiento remoto mediante magmaguy.com. En modo de red se mantiene el servidor HTTP del backend para que el proxy consulte los artefactos.
  • falla la comunicación del sondeo (IOException), o su cliente no está disponible → no se ha verificado la accesibilidad. Se intenta el alojamiento remoto; no poder contactar con el sondeo no demuestra que la subida vaya a fallar. El respaldo automático no puede omitir esta comprobación.

Lo que las comprobaciones aún no detectan​

La descarga de la URL anunciada ahora detecta fallos de NAT loopback desde la red del propio servidor. No demuestra la accesibilidad desde la red de cada jugador ni que una descarga completa del cliente de Minecraft vaya a funcionar. Comprueba la descarga completa y la aceptación del paquete con un cliente real; utiliza otra red externa al comprobar el acceso público.

Para una prueba rápida desde la máquina host, establece preferSelfHost: false y usa el respaldo remoto, o prueba la URL pública desde una red móvil/externa. Para una configuración autoalojada permanente, usa DNS de horizonte dividido (el mismo hostname público resuelve a la dirección LAN del servidor dentro de tu red). No establezcas selfHostExternalHost a 127.0.0.1: los hosts de loopback y privados los rechaza la comprobación de cordura del host público y no pueden servir a clientes externos.

Resolución de puertos​

Interactúan dos opciones:

  • selfHostPort — puerto explícito entre 1 y 65535, o -1 (por defecto) para autoderivación. El puerto derivado también debe estar dentro de ese rango; otros valores impiden iniciar el servidor HTTP.
  • networkHttpOffset-v2 — solo se consulta cuando selfHostPort = -1. Se añade al puerto del servidor de Minecraft para derivar el puerto HTTP. Por defecto 1. (En redes proxy este mismo valor es también la conjetura de respaldo del proxy para el puerto HTTP de un backend — ver abajo.)

El valor por defecto es selfHostPort: -1 + networkHttpOffset-v2: 1, por lo que:

  • puerto MC 25565 → puerto HTTP 25566
  • puerto MC 25584 → puerto HTTP 25585

Los puertos de Minecraft únicos producen puertos HTTP derivados únicos, pero un puerto derivado puede coincidir con el puerto de Minecraft de otro backend o con otro servicio. Comprueba todos los puertos de escucha y los que te haya asignado el proveedor.

¿Por qué un desplazamiento de 1?​

El alojamiento compartido y gestionado puede asignar solo unos pocos puertos a cada contenedor. Un desplazamiento de 1 mantiene el puerto derivado cerca del puerto del juego, pero no lo reserva ni garantiza que el proveedor lo haya asignado o abierto. Confirma el puerto HTTP exacto en tu panel.

Los administradores autoalojados con control total de puertos pueden subirlo a cualquier valor. En una red proxy, el backend anuncia automáticamente al proxy el puerto HTTP exacto al que se enlazó, por lo que el proxy lo sigue incluso si cambias el desplazamiento o estableces un selfHostPort explícito. Subir el network-http-offset-v2 del proxy para que coincida solo importa como respaldo durante la breve ventana antes de que un backend haya anunciado (o si el anuncio no puede alcanzar el proxy).

Cuidado: colisión con RCON​

Si tu host activa RCON por defecto en MC port + 1, elige el desplazamiento 2 o 3 para evitar una colisión de puertos. Comprueba server.properties en busca de rcon.port=.

Clave de configuración versionada​

La opción en config.yml se llama literalmente networkHttpOffset-v2. La clave de v1 era networkHttpOffset, con un valor por defecto de 100 que podía situar el puerto de escucha fuera de los puertos asignados por el proveedor. El valor por defecto de v2 es 1; ese puerto aún debe estar disponible y ser accesible.

Si actualizas desde la v1, la clave v1 muerta queda en tu config como un artefacto inofensivo hasta que la limpies — RSPM intencionadamente no la lee.

Detección del host externo​

selfHostExternalHost controla qué hostname ven los clientes en la URL. Déjalo vacío (por defecto) para autodetectar en este orden de prioridad:

  1. api.ipify.org / checkip.amazonaws.com — devuelve la IPv4 pública de este host. Se almacena en caché una vez por /rspm reload para no martillear los servicios de IP.
  2. Bukkit.getIp() — la dirección de enlace del servidor, cuando no está vacía y no es 0.0.0.0. Normalmente una dirección de LAN.
  3. InetAddress.getLocalHost() — el mejor esfuerzo posible.
  4. localhost — respaldo de último recurso. Los clientes fuera de la máquina no alcanzarán esto.

Si la autodetección aterriza en una dirección no enrutable y preferSelfHost: true, la comprobación heurística de la Capa 1 falla y el plugin cambia al alojamiento remoto.

Para la configuración de autoalojamiento más fiable, establece selfHostExternalHost explícitamente a tu hostname público (p. ej. play.example.com). Esto omite por completo la detección de ipify/AWS y el sondeo se ejecuta contra el valor explícito.

Referencia de configuración​

HTTPS y proxies inversos​

Establece selfHostExternalUrl con la URL pública completa de descarga:

autoHost: true
selfHostEnabled: true
preferSelfHost: true
selfHostPort: 25566
selfHostExternalUrl: "https://packs.example.com/rspm.zip"

Configura tu proxy inverso para reenviar esa ruta pública a la ruta interna http://<server>:25566/rspm.zip de RSPM y encargarse de TLS. RSPM sigue ejecutando un servidor de escucha HTTP; esta opción no instala un certificado ni configura tu servidor web.

La URL exacta se envía a los jugadores de Java y se usa en el sondeo de accesibilidad externa. No se añade el sufijo /rspm.zip. Sustituye a selfHostExternalHost y a la detección de IP pública para la entrega Java; selfHostPort sigue controlando el puerto de escucha interno. El sondeo de artefactos Bedrock del proxy sigue usando el punto de acceso HTTP del backend.

Solo se aceptan URLs HTTP o HTTPS completas, con host y sin credenciales incrustadas ni fragmentos. Un puerto explícito en la URL debe estar entre 1 y 65535. Una URL inválida impide el autoalojamiento. El alojamiento automático normal puede recurrir al host remoto; el autoalojamiento forzado no. Deja la opción vacía para usar la detección de host y puerto.

Opciones​

# Whether the built-in HTTP server may be used as a delivery path at all.
# When false, ordinary self-host attempts are disabled. selfHostForce still overrides it.
selfHostEnabled: true

# Port for the self-host HTTP server.
# -1 (default) = auto-derive: HTTP port = Minecraft server port + networkHttpOffset-v2.
# Set to a value from 1 to 65535 to force an explicit port.
selfHostPort: -1

# Added to the Minecraft server port when selfHostPort = -1.
# Default 1 (MC 25565 -> HTTP 25566). On a proxy network this is only a FALLBACK:
# the backend announces the exact HTTP port it actually bound to the proxy, so
# you no longer have to match this against the proxy's network-http-offset-v2.
networkHttpOffset-v2: 1

# Public hostname or IP clients use to reach the self-host server.
# Leave empty for auto-detect (api.ipify.org / checkip.amazonaws.com).
selfHostExternalHost: ""

# Optional complete public Java-pack URL, including the path.
# Your reverse proxy supplies HTTPS and forwards to the internal /rspm.zip route.
selfHostExternalUrl: ""

# Try self-host FIRST with three sanity checks, fall back to remote if any fail.
# When false, use the legacy order: remote upload first, self-host only on upload failure.
preferSelfHost: true

# Skip ALL other delivery paths and force self-hosting.
# Bypasses sanity checks AND remote upload. Mainly for testing.
selfHostForce: false

# Print every step of pack preparation and the hosting handshake.
# Default false — see "What the console actually prints" below.
# `/rspm verbose on|off` flips this same key at runtime and saves it here.
verboseLogging: false

Qué imprime realmente la consola​

Los fallos del alojamiento remoto Java y del relevo Bedrock usan esperas exponenciales con variación aleatoria. Cada flujo permite un intento activo y hasta cinco reintentos; después espera entre 15 y 30 minutos antes de iniciar otra serie. Un éxito reinicia el contador y el cliente HTTP no añade reintentos automáticos. El alojamiento Java consulta el SHA-1 remoto antes de subir el archivo. Los reintentos Bedrock reutilizan durante un máximo de 20 minutos los archivos sin cambios que ya se hayan subido correctamente. La renovación habitual del relevo cada 25 minutos sigue subiendo los archivos para renovar su vigencia en el servidor.

RSPM imprime deliberadamente una línea sobre el alojamiento en un arranque normal — el resultado, no el trayecto:

[ResourcePackManager] Resource pack is live via self-hosting — http://play.example.com:25566/rspm.zip

o, cuando gana la ruta remota:

[ResourcePackManager] Resource pack is live via automatic hosting — https://magmaguy.com/rsp/<uuid>

Esa línea se imprime una vez cada vez que se inicializa de cero una ruta de entrega, no en los reintentos de los jugadores ni en los ticks de keep-alive. Una recarga cuyo paquete no ha cambiado puede reutilizar el registro de alojamiento existente en lugar de imprimir un nuevo resultado.

Los fallos de accesibilidad se registran a nivel de detalle. Por ejemplo: Self-host check: local pack link is not public. This is OK. Las comprobaciones del host y de localhost terminan con This is OK.; la descarga de la URL anunciada y la verificación externa informan de su fallo sin ese sufijo. Una URL inválida, un fallo al iniciar el servidor HTTP o un fallo de comunicación remota sí pueden generar advertencias. Una comprobación fallida no demuestra por sí sola que el respaldo remoto haya funcionado; consulta el estado final de entrega.

Para ver toda la cadena de decisión — qué comprobación falló, la URL del sondeo, el código de motivo, cada paquete preparado y cada clúster fusionado — ejecuta:

/rspm verbose on

Y luego /rspm reload. Este es el interruptor que hay que accionar antes de abrir un informe de error sobre el alojamiento. El comando escribe verboseLogging: true en config.yml y la opción persiste entre reinicios, así que ejecuta /rspm verbose off cuando termines; editar la clave de configuración a mano tiene exactamente el mismo efecto.

Ten en cuenta que verboseLogging cubre la preparación de paquetes y el alojamiento. El convertidor de Bedrock tiene su propio interruptor independiente, bedrockConverterDebug — consulta Conversión a Bedrock.

Rutas del servidor HTTP del backend​

El servidor HTTP integrado siempre sirve el zip del paquete en:

http://<host>:<port>/rspm.zip

En modo de red (RSPM está detrás de un proxy de Velocity / BungeeCord) se registran rutas adicionales para que el plugin del proxy las obtenga:

http://<host>:<port>/bedrock.zip   # the Bedrock-converted pack
http://<host>:<port>/mappings.json # the Geyser custom-mappings JSON
http://<host>:<port>/rspm-update.jar # the universal RSPM update jar (authenticated)

Las rutas del paquete y de los artefactos de Bedrock usan archivos y resuelven el artefacto publicado actual en cada solicitud. Una nueva mezcla publicada correctamente queda disponible sin reiniciar el servidor HTTP; sustituir un archivo en disco no lo autoriza por sí solo. Las rutas devuelven 404 si no hay un artefacto actual autorizado, falta el archivo o sus bytes ya no coinciden con el resumen de publicación. Las rutas de Bedrock también requieren que la conversión siga activada. Los ETags fuertes admiten If-None-Match, que tiene prioridad sobre la comprobación de compatibilidad If-Modified-Since; las consultas sin cambios pueden recibir un 304 sin cuerpo. La ruta de actualización está protegida aparte por un token bearer derivado de la clave de red compartida y solo está disponible cuando se puede ofrecer un jar de actualización válido.

Verificar que el autoalojamiento está activo​

/rspm status muestra:

  • Active delivery: SELF-HOSTED — el autoalojamiento está en uso
  • Active delivery: REMOTE (magmaguy.com) — el auto-host remoto está en uso
  • URL: ... — la URL real que verán los clientes
  • Resolved external host — a qué se resolvió selfHostExternalHost
  • Public IP (auto-detected) — lo que informó ipify/AWS, si es que algo
  • selfHostPort — auto vs explícito, y el valor resuelto

Si esperabas autoalojamiento pero ves remoto, /rspm status es el sitio donde mirar — el log de arranque permanece callado sobre los fallos de sondeo autorresueltos por diseño. Ejecuta /rspm verbose on y /rspm reload para ver qué comprobación de cordura falló y por qué.

Errores comunes​

  • Tratar un sondeo correcto como una prueba completa del cliente — la muestra local y el sondeo público cubren rutas de red concretas. Comprueba una descarga completa y la aceptación del paquete con un jugador real; el autoalojamiento forzado omite por completo estas comprobaciones.
  • Subir networkHttpOffset-v2 más allá del rango de puertos de tu proveedor de alojamiento — el síntoma es un CONNECT_FAILED silencioso para siempre del lado del proxy. Los backends anuncian su puerto enlazado real al proxy, pero el servidor HTTP aún tiene que enlazarse a un puerto accesible y el proxy aún tiene que poder alcanzarlo; si mcPort + offset aterriza fuera de la banda de puertos asignada de tu contenedor, el enlace/firewall falla independientemente del anuncio. Comprueba que el puerto esté en la banda asignada de tu contenedor antes de subir el desplazamiento.