Redes proxy (BungeeCord / Velocity)

ResourcePackManager funciona en redes proxy. Instala el mismo ResourcePackManager.jar en el proxy y en cada backend que suministre paquetes de recursos. Los demás servidores registrados pueden permanecer sin RSPM. En un backend fusiona, aloja, entrega y convierte paquetes. En Velocity o BungeeCord, el jar detecta la plataforma del proxy y gestiona la entrega de Bedrock de la red. El proxy posee la clave de red y la envía a cada backend la primera vez que un jugador se conecta allí.

A lo largo de esta página, "el plugin del proxy" es la forma abreviada de referirse a ese mismo ResourcePackManager.jar ejecutándose en rol de proxy.

Qué hace el plugin del proxy

El trabajo del plugin del proxy es la fusión y entrega del paquete de Bedrock. En una red con varios backends, cada backend produce su propio paquete de Bedrock (la versión convertida de su paquete Java fusionado). El plugin del proxy:

1. Descubre qué backends registrados ejecutan RSPM y después sondea a esos participantes cada 5 segundos para obtener /bedrock.zip y /mappings.json. Prefiere ETags fuertes con If-None-Match y conserva la compatibilidad con If-Modified-Since para backends antiguos. Los archivos sin cambios devuelven 304. Cada backend anuncia el puerto HTTP exacto en el que escucha, por lo que el proxy normalmente lo usa de forma automática. Consulta la resolución del puerto HTTP del backend.
2. Espera a que el estado de la bandeja de entrada se estabilice — fusiona en cuanto dos sondeos adyacentes observan el mismo conjunto de hashes de archivos.
3. Fusiona el paquete de Bedrock de cada backend en un único paquete a nivel de red.
4. Cuando existen mappings de ítems, copia el archivo fusionado de mappings personalizados de Geyser en plugins/Geyser-*/custom_mappings/ del proxy.
5. Sirve el paquete fusionado a los clientes de Bedrock al conectarse mediante el SessionLoadResourcePacksEvent de Geyser.

La entrega del paquete Java en redes se realiza por backend mediante la API habitual setResourcePack / addResourcePack. Además de fusionar paquetes Bedrock, la función de proxy añade el aprovisionamiento de claves de red y la propagación autenticada de actualizaciones de RSPM. Una red exclusivamente Java no la necesita para entregar paquetes Java.

Configuración

Floodgate

Floodgate permite que los jugadores de Bedrock se autentiquen sin una cuenta de pago de Java Edition. Geyser también puede usar autenticación en línea con una cuenta Java; sigue la guía de configuración de Geyser correspondiente a tu modo de autenticación. RSPM puede enlazar su proxy y sus backends sin Floodgate.

Si Floodgate está instalado cuando RSPM arranca por primera vez en el proxy, RSPM deriva su clave de red de plugins/floodgate/key.pem, conservando la identidad de una red existente. Los arranques posteriores usan el archivo network-key de RSPM mientras contenga una clave válida. Si falta o no es válida, RSPM vuelve a probar la semilla de Floodgate antes de generar una clave aleatoria.

Copia ResourcePackManager.jar al proxy

Solo hay un jar. El mismo ResourcePackManager.jar que instalas en los backends de Bukkit/Paper es también el plugin del proxy — incluye las implementaciones de Velocity y BungeeCord juntas en un único jar sombreado y autodetecta en qué plataforma se está ejecutando. No hay un jar de proxy específico por plataforma que extraer.

Si ya arrancaste los backends sin poner RSPM en el proxy, no tienes que buscar la descarga: cada backend detrás de un proxy y sin clave prepara una copia idéntica byte a byte de su propio jar en plugins/ResourcePackManager/proxy-extension/ResourcePackManager.jar e imprime esa ruta exacta en la consola. Copiar ese archivo instala la versión que se ejecuta actualmente en ese backend; actualiza también los demás backends para mantener toda la red en la misma versión.

Copia el mismo ResourcePackManager.jar en la carpeta plugins/ de tu proxy:

Software de proxy	Usa este jar
Velocity	ResourcePackManager.jar
BungeeCord	ResourcePackManager.jar

Puedes confirmarlo desde un backend en cualquier momento ejecutando /rspm status; la sección Proxy deployment imprime Network proxy jar: ResourcePackManager.jar y Use the same jar on Bukkit/Paper, Velocity, and BungeeCord.

Reinicia el proxy. Eso es todo.

No hay ninguna configuración obligatoria que editar ni clave que pegar. El proxy establece la clave de red por sí mismo al arrancar y aprovisiona automáticamente a cada backend con ella — consulta Cómo se enlazan el proxy y los backends más abajo. El config.yml generado del proxy contiene solo dos opciones, ambas opcionales y descritas más adelante.

El primer sondeo del proxy se dispara ~2 segundos después del arranque, y luego cada 5 segundos. Combinado con la verja de estabilidad de un solo ciclo, la primera fusión se publica aproximadamente 7 segundos después de que el proxy pueda ver al menos un backend que ya esté produciendo contenido.

Descubrimiento de backends

El proxy comprueba qué servidores registrados ejecutan RSPM sin hacer que la sincronización de paquetes espere a los que no lo usan. Los anuncios de endpoints y el contenido en caché validado previamente pueden identificar participantes de inmediato. En otros casos, el descubrimiento comprueba el endpoint HTTP resuelto en segundo plano, con un máximo de dos comprobaciones simultáneas y un tiempo de espera de cinco segundos. Los servidores sin confirmar se vuelven a comprobar aproximadamente un minuto después.

/rspm status muestra el número de participantes confirmados y el estado de descubrimiento de cada servidor restante. RSPM not confirmed significa que el descubrimiento no ha establecido la presencia de RSPM; no demuestra que el plugin esté ausente. Comprueba la dirección, el puerto HTTP y la accesibilidad del backend si debería participar. La instalación de RSPM en otro backend se detecta automáticamente.

Una vez confirmado un backend, los fallos de conexión se muestran como fallos de actualización de ese participante. El contenido disponible de operaciones completadas se conserva, y los resultados directos y por retransmisión siguen visibles en /rspm status. Un contador de sondeos vacíos a cero significa que hay contenido disponible, no que todas las conexiones estén sanas.

El descubrimiento no concede acceso a las actualizaciones. La autenticación mediante clave de red y la validación del jar siguen aplicándose a las actualizaciones automáticas del plugin.

Cómo se enlazan el proxy y los backends

Todo lo que sigue ocurre sin configuración. Está documentado aquí porque, cuando una red no se enlaza, conocer la secuencia es todo el diagnóstico.

1. El proxy establece la clave. Al arrancar resuelve exactamente un valor, en este orden:

1. su archivo network-key guardado, en la propia carpeta de datos del plugin del proxy — el estado estable en cada arranque después del primero;
2. una siembra única derivada de plugins/floodgate/key.pem en el proxy, si ese archivo existe;
3. una clave aleatoria recién generada.

La clave resuelta se guarda en network-key y se reutiliza mientras sea válida. La consola indica su origen (Network key loaded ✓, adopted from Floodgate key.pem o New network key generated). Un archivo network-key mal formado se sustituye. Si RSPM no puede guardar una clave nueva, o no puede leer un archivo network-key existente, el rol de proxy deja de arrancar con Could not establish persistent RSPM network identity o Cannot read established RSPM network identity, en lugar de funcionar con una clave que podría cambiar en el siguiente reinicio. Corrige los permisos de la carpeta y reinicia el proxy.

2. El proxy envía la clave a cada backend. En cuanto un jugador se conecta a un backend, el proxy le manda la clave por el canal de plugin rspm:network. La dirección es deliberada: un backend físicamente no puede pedirla, porque un proxy no reenvía un mensaje de plugin por un canal que el propio cliente del jugador nunca registró.

3. El backend la adopta y la persiste. Guarda la clave en su data.yml e informa Network key received from the proxy; this backend is now linked. Las concesiones solo se honran mientras el backend no tenga ninguna clave — un backend ya establecido registra una advertencia y conserva la que tiene en lugar de dejar que un mensaje lo reapunte a otra red.

En Velocity con reenvío moderno, las concesiones se firman con un HMAC sobre el forwarding.secret del proxy, y un backend configurado para reenvío moderno exige esa firma. En BungeeCord y el reenvío heredado no hay ningún secreto compartido con el que firmar, así que las concesiones van sin firmar y se aceptan como tales.

Un backend que llega al paso 2 pero nunca al paso 3 mantiene su origen de clave en not set. Ese es exactamente el estado que dispara la preparación de proxy-extension/ y el banner de advertencia específico de Bedrock.

Verificar que funciona

Consola del proxy

En ~10 segundos tras el reinicio (suponiendo que los backends están en marcha) deberías ver:

[ResourcePackManager] Network key loaded ✓
[ResourcePackManager] Network key provisioning ready on rspm:network; backends are keyed as players connect.
[ResourcePackManager] NetworkSync starting (poll interval 5000 ms, network-http-offset 1 - endpoint announcements preferred, fallback HTTP port = mcPort + offset)
[ResourcePackManager] NetworkSync: inbox stabilized — merging 2 Bedrock zip(s) and 2 mappings file(s) across 2 backend(s).
[ResourcePackManager] Merged Bedrock pack published at .../merged/Bedrock.zip (sha1=...).
[ResourcePackManager] ✔ Network resource pack is now ready (... KB, sha1 ABCD1234)

/rspm status en el proxy

Imprime una instantánea: huella de la clave de red, lista de backends, resultados de obtención por backend y por ruta (200 / 304 / 404 / CONNECT_FAILED) para /bedrock.zip, /mappings.json y /rspm-update.jar, los anuncios de endpoints que ha recibido, las entradas de relevo que puede ver, el contador de sondeos vacíos consecutivos, si el paquete de Bedrock fusionado y los mappings fusionados están en disco (con sus tamaños) más el prefijo SHA-1 del paquete fusionado actual, el respaldo network-http-offset, la carpeta del plugin Geyser detectada y el archivo de mappings desplegado, y la presencia de Floodgate / Geyser en el proxy. Velocity acepta resourcepackmanager.command.status o resourcepackmanager.*; BungeeCord registra el nodo exacto resourcepackmanager.command.status, que los plugins de permisos pueden satisfacer mediante expansión de comodines. La consola puede ejecutarlo. La salida no revela secretos (la clave de red aparece solo como una huella hash corta de un solo sentido, y no se imprime ningún token de autenticación), por lo que conceder estos permisos de forma amplia es seguro.

/rspm status en un backend

La línea Deploy mode debería indicar network-backend. Network key fingerprint debería mostrar un hash corto — debe coincidir con la huella que imprime el proxy. Network key source te dice cómo obtuvo la clave este backend:

Línea de origen	Significado
provided by the proxy	El estado enlazado normal. El proxy concedió la clave al conectarse un jugador.
saved on this server	Ya tenía clave de un arranque anterior (o es un servidor independiente que generó la suya).
adopted from Floodgate's key	Sembrada una única vez desde el plugins/floodgate/key.pem local de este backend.
not set — the proxy sends one when a player next connects here	No enlazado. O bien ningún jugador se ha conectado desde que el proxy arrancó, o al proxy le falta RSPM / es un proxy no compatible.

Cliente de Bedrock

Conéctate vía Bedrock. Deberías ver el aviso de descarga del paquete de recursos antes de llegar al mundo. Los ítems personalizados se renderizan con sus modelos previstos en lugar de simples soportes de armaduras (armor stands).

Referencia de configuración

Backend plugins/ResourcePackManager/config.yml

El modo de red se autodetecta — no hay un flag networkMode: true que establecer. Señales de detección (cualquiera es suficiente):

1. Floodgate presente, Geyser-Spigot ausente — la señal más fuerte para el caso de Bedrock-vía-proxy.
2. spigot.yml: settings.bungeecord: true — interruptor heredado de reenvío de IP de BungeeCord.
3. paper-global.yml: proxies.velocity.enabled: true — reenvío moderno de Velocity.

La opción de puerto alternativo para el modo de red es networkHttpOffset-v2, que controla el puerto HTTP de respaldo que el proxy sondeará en cada backend (el puerto que calcula antes de que el backend anuncie su puerto real de escucha). El valor por defecto es 1; el puerto correspondiente debe ser accesible entre el proxy y el backend, o debe estar disponible la ruta de retransmisión. Consulta Autoalojamiento para conocer todos los detalles de la resolución de puertos.

En operación normal, cada backend anuncia su puerto HTTP real al proxy automáticamente (a través del registro de endpoints de magmaguy.com), por lo que el desplazamiento solo se consulta como respaldo de arranque/fallo. Consulta Resolución del puerto HTTP del backend más abajo.

Proxy config.yml

El plugin del proxy escribe una configuración mínima por defecto en el primer arranque. La carpeta varía según la plataforma, porque cada proxy la deriva de su propio identificador de plugin:

Software de proxy	Ruta de configuración
Velocity	plugins/resourcepackmanager/config.yml
BungeeCord	plugins/ResourcePackManager/config.yml

Contiene exactamente dos opciones, ambas opcionales:

# FALLBACK offset added to each backend's Minecraft port to derive the HTTP
# port this proxy will hit for /bedrock.zip and /mappings.json BEFORE that
# backend has announced its real ResourcePackManager HTTP port. Default 1.
# In normal operation the backend announces the exact port it bound, so this
# value is only used at startup or if announcement fails — but if it IS used,
# it should match each backend's networkHttpOffset-v2.
network-http-offset-v2: 1

# Installs and updates this universal ResourcePackManager.jar in the proxy's
# Geyser extensions folder, which is what makes custom Bedrock ENTITIES render.
# Default true. Setting it to false stops future installation and update
# staging; it does not delete an extension jar that is already installed —
# remove that by hand while Geyser is stopped.
geyser-extension-auto-install: true

Los equivalentes del lado del backend son networkHttpOffset-v2 y geyserExtensionAutoInstall en el config.yml del backend. Los dos lados son opciones independientes — desactivar la instalación de la extensión en el proxy no la desactiva en los backends, ni al revés.

Junto a config.yml, el proxy escribe network-key. Conserva este estado generado y no lo copies entre redes distintas. Borrarlo repite la resolución de la clave en el siguiente arranque; una semilla de Floodgate disponible puede producir la misma clave. Si cambia, los backends ya aprovisionados conservan la anterior y rechazan la nueva. Dos proxies que sirvan a los mismos backends deben compartir una clave: copia el archivo entre esos proxies.

No existe ninguna opción force-resource-pack del lado del proxy. Forzar la aceptación del paquete es una decisión del lado del backend (forceResourcePack en el config.yml del backend) porque el plugin del proxy solo gestiona la entrega del paquete de Bedrock — nunca envía paquetes de Java. Si un config.yml de proxy antiguo todavía lleva una línea force-resource-pack, simplemente se ignora y se puede borrar.

Intencionadamente no hay ninguna entrada de configuración network-key — una clave pegable se retiró antes del lanzamiento porque las erratas rompían silenciosamente el enlace proxy↔backend sin ningún error en ninguna parte. La clave la establece el proxy y se aprovisiona a los backends automáticamente, tal y como se describe en Cómo se enlazan el proxy y los backends.

Resolución del puerto HTTP del backend

El proxy necesita saber qué puerto HTTP sondear en cada backend para /bedrock.zip y /mappings.json. Resuelve ese puerto en este orden:

1. Endpoint anunciado por el backend (preferido). Cada backend sube el puerto HTTP exacto al que se enlazó al registro de endpoints de magmaguy.com, indexado por la clave de red. En cada sondeo, el proxy refresca esta lista y empareja el puerto anunciado de un backend con la entrada de la lista de servidores por el puerto de Minecraft (y por el host cuando está disponible). Esto significa que un administrador que establezca un selfHostPort explícito en un backend, o cuyo backend aterrice automáticamente en mcPort + 1, se gestiona de forma idéntica — el proxy usa lo que el backend realmente haya enlazado.
2. mcPort + network-http-offset-v2 (respaldo). Se usa solo cuando no hay un anuncio coincidente disponible (p. ej. el primer sondeo antes de que ningún backend haya anunciado, o el registro de endpoints está brevemente inaccesible). Por eso los dos desplazamientos deberían seguir coincidiendo si dependes del respaldo.

El proxy deliberadamente no hace escaneo de puertos en un backend como respaldo — eso parece comportamiento abusivo para el host. Cuando la obtención directa no puede funcionar en absoluto, la ruta de relevo (más abajo) es la respuesta categórica.

/rspm status en el proxy muestra, por backend, qué puerto se eligió y si provino de un anuncio o del respaldo del desplazamiento.

Estabilidad y cadencia de fusión

Las preferencias de alojamiento Java también se aplican a los backends detrás de un proxy. Si falla un sondeo de autoalojamiento Java, RSPM puede cambiar la entrega Java al alojamiento remoto mientras mantiene activo el servidor HTTP del backend para /bedrock.zip y /mappings.json.

El proxy espera a que el estado de la bandeja de entrada se estabilice antes de fusionar: el primer sondeo establece el conjunto base de hashes de archivos, y el siguiente sondeo que observa el mismo conjunto dispara la fusión (una verja de estabilidad de un ciclo). Con el retardo inicial de ~2 s y el intervalo de sondeo de 5 s, eso sitúa la primera fusión ~7 s después de que el proxy pueda ver al menos un backend produciendo contenido. Las fusiones posteriores solo vuelven a comprimir cuando cambia el conjunto SHA-1 de los archivos de la bandeja de entrada, por lo que un periodo largo de inactividad cuesta aproximadamente nada.

Los backends escriben su bedrock.zip en un archivo temporal y lo renombran de forma atómica, de modo que la ruta /bedrock.zip siempre sirve un zip completo — el proxy nunca tiene que defenderse de lecturas a medio escribir, razón por la cual la verja es de un solo ciclo en lugar de dos.

Descarga directa y retransmisión alternativa

La ruta por defecto es la obtención directa: el proxy hace un HTTP GET a http://<backend-host>:<mcPort + offset><path> para cada backend.

Si el proxy no puede alcanzar directamente el puerto HTTP de un backend (típico de los alojamientos de Minecraft compartidos / gestionados donde los puertos MC están expuestos pero los puertos adyacentes están bloqueados por el firewall), el backend envía su bedrock.zip y mappings.json a un endpoint de relevo en magmaguy.com bajo el namespace de la red (derivado de la clave de red). El proxy lista y descarga desde el relevo cuando la obtención directa falla por completo.

Ambas rutas alimentan el mismo paso de fusión, por lo que el operador nunca tiene que elegir — la obtención directa es la preferida (coste de ancho de banda cero para magmaguy.com), el relevo entra de forma transparente cuando es necesario.

El relevo tiene un TTL de 30 minutos del lado del servidor. Los backends hacen push cada 25 minutos para mantener viva la entrada; un apagado limpio elimina la entrada de inmediato en lugar de esperar al TTL.

Solución de problemas comunes

Un backend nunca recibe una clave de red

Síntoma: /rspm status en el backend muestra Network key source: not set — the proxy sends one when a player next connects here, y la consola del backend repite:

[ResourcePackManager] This backend is behind a proxy but has no network key yet, so it is not linked to the proxy.
[ResourcePackManager] The proxy sends one automatically the first time a player connects to this server.

Repasa esto en orden:

1. ¿De verdad se ha conectado alguien a ese backend desde que arrancó el proxy? La concesión viaja con una conexión de jugador. Un lobby que nadie ha visitado todavía está legítimamente sin clave.
2. ¿Está RSPM en el proxy siquiera? El backend prepara una copia de su propio jar en plugins/ResourcePackManager/proxy-extension/ResourcePackManager.jar exactamente para este caso. Cópialo en la carpeta plugins/ del proxy y reinicia el proxy.
3. Reenvío moderno de Velocity: ¿coincide el secreto de reenvío del backend con el del proxy? Un backend configurado para reenvío moderno rechaza a propósito una concesión sin firmar o mal firmada — esa comprobación es lo único que impide que un proxy no autorizado dé claves a tus backends. El log del backend indica cuál de los dos casos se dio. Corrige el secreto en ambos lados y la siguiente conexión de un jugador lo reintenta automáticamente; no hace falta reiniciar ninguno de los dos lados para rearmarlo.
4. ¿Es un proxy no compatible? Solo Velocity y BungeeCord ejecutan el rol de proxy. Waterfall no es compatible.

El key.pem de Floodgate ya no forma parte de este proceso. Que falte plugins/floodgate/key.pem en el proxy es un estado totalmente compatible: el proxy genera su propia clave. La autenticación de Floodgate es independiente del enlace de red de RSPM.

Dos proxies delante de los mismos backends

Ambos proxies deben presentar la misma clave de red, o cada backend se enlaza con el que llegue primero y rechaza al otro (registrando A proxy offered a network key that differs from the one this backend already uses). Copia el archivo network-key de la carpeta de datos de RSPM del proxy principal a la del otro proxy y reinícialo.

Advertencia "No merged pack content" tras ~20 segundos

Tras cuatro ciclos de sondeo vacíos consecutivos con participantes RSPM confirmados, el proxy registra una advertencia con esos participantes, las URL intentadas y sus resultados. Un proxy nuevo que aún busca su primer participante no cuenta los servidores registrados ajenos a RSPM como backends de paquetes fallidos. La advertencia explica las soluciones más comunes:

• CONNECT_FAILED en cada backend — el proxy no puede alcanzar el puerto HTTP del backend en absoluto. Comprueba que la dirección en velocity.toml / config.yml sea una que el proxy pueda alcanzar realmente (no un nombre interno de Docker que no se resuelve desde la red del proxy) y que el puerto HTTP del backend esté abierto entre el proxy y el backend. La advertencia imprime el host:puerto HTTP exacto que intentó para cada backend y si ese puerto provino del anuncio del backend o del respaldo mcPort + networkHttpOffset-v2. Si no tienes forma de abrir ese puerto (alojamiento gestionado), consulta la sección de respaldo por relevo más arriba — el backend debería estar subiendo al relevo automáticamente.
• NOT_FOUND_404 en cada backend — los backends están en marcha pero no producen un paquete de Bedrock. Ejecuta /rspm status en cada backend; el bloque de diagnóstico del paquete Bedrock te dirá por qué (lo más frecuente: no hay mappings de ítems convertibles ni paquetes de entidades en el paquete fusionado, o el primer ciclo de mezcla aún no se ha completado).

La advertencia se dispara una vez por periodo de atasco. Se registra una línea NetworkSync: recovered cuando al menos un backend vuelve a devolver contenido.

Los jugadores de Bedrock no ven modelos personalizados en el primer arranque del proxy

Geyser registra su tabla de ítems personalizados solo al arrancar el proxy. Si el proxy arrancó antes de que ningún backend produjera un paquete de Bedrock, Geyser se ejecuta con una tabla de mappings vacía y permanece así durante el resto de la sesión.

Solución: reinicia el proxy una vez después de que el propio proxy registre su primera línea Merged Bedrock pack published. RSPM prepara las asignaciones de la ejecución anterior en cada arranque del proxy, de modo que los arranques posteriores puedan cargarlas antes de que Geyser las examine. Añadir o eliminar objetos personalizados más adelante también cambia el conjunto de asignaciones del arranque y requiere reiniciar; los nuevos identificadores de entidades personalizadas o tipos de propiedades requieren el mismo tratamiento.

Advertencias "Duplicate bedrock_identifier" al arrancar el proxy

Distintos identificadores Bedrock pueden compartir el mismo selector Java de objeto/modelo/predicados. Cambiar solo el nombre del modelo de origen resuelto no distingue esos objetos. Asigna selectores distintos, por ejemplo valores de custom-model-data diferentes. El mezclador actual prefiere una definición moderna a una entrada legacy del mismo selector; entre tipos iguales, gana la última. La deduplicación conserva un objeto, no ambos.

El jugador de Bedrock se conectó pero no ve el paquete

El proxy envía un aviso de chat al personal conectado que tenga resourcepackmanager.* cuando una sesión de Bedrock se carga sin un paquete de RSPM utilizable:

⚠ [RSPM] La jugadora de Bedrock Alice se conectó antes de que el paquete de recursos estuviera listo: está viendo soportes de armaduras normales en lugar de modelos personalizados. Pídele que se desconecte y vuelva a conectarse; el paquete se cargará en su siguiente sesión. (Causa: ...)

El propio jugador de Bedrock también recibe una ventana emergente modal, y la consola del proxy recibe un banner. Si necesitas profundizar más, activa el flujo de depuración (disponible tanto en Velocity como en BungeeCord):

/rspm debug bedrock on

Eso activa las líneas de log verbosas [RSPM-BedrockDebug] de GeyserBinder. Reproduce el problema y luego desactívalo:

/rspm debug bedrock off

La opción se restablece a off al reiniciar el proxy, de modo que no puede quedarse activada accidentalmente.

Actualizar RSPM en una red

Es el mismo jar en cada backend y en el proxy, así que mantén todos los componentes en la misma versión.

La vía manual es: sube la versión del jar del backend, vuelve a copiar ese mismo ResourcePackManager.jar a la carpeta plugins/ del proxy y reinicia el proxy.

RSPM también puede encargarse de la mitad del proxy por sí mismo. Cada backend ofrece su jar de plugin universal al proxy a través de una ruta autenticada (/rspm-update.jar, protegida por un token derivado de la clave de red compartida — la clave en sí nunca se transmite). El proxy valida que el archivo ofrecido sea un jar universal de RSPM completo, con versiones de descriptor de plataforma coincidentes y los puntos de entrada esperados, rechaza las bajadas de versión y verifica los bytes preparados contra el tamaño y el SHA-256 anunciados antes de reemplazar nada. Prepara el mismo jar para el plugin del proxy y, cuando detecta un Geyser alojado en el proxy, también su extensión de Geyser incluida; aplica esos archivos al apagarse el proxy y conserva los archivos anteriores como copias de reversión.

Esto es una frontera de confianza de red autenticada, no una comprobación de procedencia independiente contra Nightbreak: cualquier backend que haya sido aprovisionado con la clave de red compartida es de confianza para ofrecer un jar de RSPM estructuralmente válido de la misma versión o más nuevo. Protege esa clave y trata como infraestructura de confianza a todos los backends que la comparten.

Así que en la práctica, actualizar los backends y luego reiniciar el proxy suele ser suficiente — el proxy habrá preparado el jar correspondiente para sí mismo. Una actualización rechazada registra Rejected backend-offered ResourcePackManager update: ... con el motivo.

Fallos de autenticación de actualizaciones ejecutables

Un HTTP 401 en /rspm-update.jar solo pausa la propagación automática de jars desde ese backend. El sondeo directo del paquete Bedrock y de las asignaciones continúa. La ruta de actualización vuelve a intentarse con una espera progresiva que empieza en un minuto y llega hasta quince minutos. Compara las huellas de las claves de red de /rspm status en ambos lados y verifica que la URL indicada llegue al backend previsto y que las versiones coincidan.

Si las huellas difieren, /rspm status en el proxy indica el procedimiento actual: confirma que se trata del proxy y el backend previstos, detén el backend afectado, haz una copia de seguridad de su plugins/ResourcePackManager/data.yml, elimina solo su entrada networkKey y después arráncalo y entra a través de este proxy para que se aprovisione de nuevo. Conserva el network-key del proxy y cualquier clave de Floodgate. El aviso de consola del 401 en el proxy sigue recomendando copiar key.pem de Floodgate; ese consejo está obsoleto, porque RSPM guarda su propia identidad de red y cambiar key.pem no sustituye una clave de RSPM ya establecida. Conserva las salidas de estado de ambos lados para soporte.

Lo que aún no se admite

• Paquetes Java en redes a través del plugin del proxy. Los clientes de Java reciben paquetes de cada backend directamente a través de la API habitual. No hay un mezclador de paquetes Java del lado del proxy.
• Fusión de paquetes Java entre backends. El paquete Java de cada backend es independiente. Si un jugador cambia de backend, recibe el paquete del nuevo backend.
• Rotación en vivo de la clave de red. Un backend solo adopta una clave si todavía no tiene ninguna y rechaza mensajes de sustitución. Con todos los componentes detenidos, borrar network-key del proxy y networkKey del data.yml de cada backend permite aprovisionar de nuevo. Esto no garantiza la rotación: el proxy puede derivar otra vez la misma clave de key.pem de Floodgate.