Redes proxy (BungeeCord / Waterfall / Velocity)

ResourcePackManager funciona en redes proxy. Hay un único jar — ResourcePackManager.jar — y debes instalar el mismo jar en cada backend y en el proxy. En un backend se ejecuta en rol de backend (fusionar, alojar, enviar, convertir); en un proxy de Velocity o BungeeCord/Waterfall el mismo jar autodetecta el cargador de la plataforma y se ejecuta en rol de proxy (entrega de Bedrock a nivel de red). Los dos roles se enlazan solos: el proxy es el dueño de la clave de red y se la envía a cada backend la primera vez que un jugador se conecta allí — sin jar de proxy específico por plataforma, sin clave que pegar.

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. Sondea el pequeño servidor HTTP de cada backend cada 5 segundos en busca de /bedrock.zip y /mappings.json, prefiriendo ETags fuertes con If-None-Match y manteniendo la compatibilidad con If-Modified-Since para backends más antiguos. Los archivos sin cambios devuelven 304, así que cuestan aproximadamente cero ancho de banda. Cada backend anuncia el puerto HTTP exacto al que se enlazó, por lo que el proxy normalmente da con el puerto correcto automáticamente (consulta 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.

El plugin del proxy solo es útil para jugadores de Bedrock. La entrega del paquete Java en redes sigue ocurriendo por backend a través de la API habitual de setResourcePack / addResourcePack — los clientes de Java ven el paquete del backend en el que estén, según lo que ese backend haya decidido enviar. Si tu red es solo de Java, no necesitas el plugin del proxy.

Configuración — un solo paso (más Floodgate, si quieres Bedrock)

Floodgate

Floodgate es necesario para que los jugadores de Bedrock se autentiquen en el proxy. No es necesario para que RSPM enlace el proxy con sus backends — una red solo de Java puede ejecutar el plugin del proxy sin Floodgate en absoluto.

Si Floodgate sí está instalado en el proxy en el momento en que RSPM arranca allí por primera vez, RSPM siembra su clave de red desde plugins/floodgate/key.pem una única vez, de modo que una red existente que ya funcionaba conserva la misma identidad tras la actualización. Después de ese primer arranque, la clave vive en el propio archivo network-key de RSPM y key.pem no se vuelve a leer nunca.

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/Waterfall 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 proxificado y sin clave prepara una copia byte a byte idéntica de su propio jar en plugins/ResourcePackManager/proxy-extension/ResourcePackManager.jar e imprime esa ruta exacta en la consola. Copiar ese archivo garantiza que el proxy y el backend nunca puedan estar en versiones distintas.

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

Software de proxy	Usa este jar
Velocity	ResourcePackManager.jar
BungeeCord	ResourcePackManager.jar
Waterfall (fork de Bungee)	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/Waterfall.

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.

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.

Sea cual sea la rama que se ejecute, el resultado se escribe en network-key y se reutiliza para siempre. La consola del proxy dice cuál ocurrió (Network key loaded ✓, adopted from Floodgate key.pem o New network key generated). Si el archivo no se puede escribir, el proxy registra un error a nivel [ERROR] — ese estado no es fatal para el arranque actual, pero el siguiente reinicio genera una clave distinta y desenlaza silenciosamente a todos los backends, así que corrige los permisos de la carpeta.

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, Waterfall 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 / Waterfall.
3. paper-global.yml: proxies.velocity.enabled: true — reenvío moderno de Velocity.

El único parámetro que importa específicamente 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 el proxy adivina antes de que un backend haya anunciado el puerto al que realmente se enlazó). El valor por defecto 1 funciona en prácticamente todos los alojamientos. Consulta Autoalojamiento para la historia completa 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 / Waterfall	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 plugin del proxy también escribe un archivo network-key en la misma carpeta. Eso es estado generado, no configuración: no lo edites y no lo copies entre redes distintas. Borrarlo hace que el proxy genere una clave completamente nueva en su siguiente arranque, lo que desenlaza a todos los backends que ya estaban aprovisionados (cada backend conserva la clave antigua y no adoptará un reemplazo). Copiarlo sí es lo correcto en un único caso: dos proxies delante del mismo conjunto de backends, que deben compartir una sola clave.

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

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.

Obtención directa vs respaldo por relevo

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/Waterfall ejecutan el rol de proxy.

Ten en cuenta que el key.pem de Floodgate ya no forma parte de esto. Que falte plugins/floodgate/key.pem en el proxy es un estado totalmente soportado — el proxy genera su propia clave en su lugar. Floodgate sigue siendo necesario para que los jugadores de Bedrock puedan llegar al proxy siquiera.

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 4 ciclos de sondeo vacíos consecutivos, el proxy registra una advertencia única de varias líneas que lista cada backend que sondeó, la URL que intentó y el resultado. 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 backend haya registrado su primera línea Merged Bedrock pack published. RSPM predespliega los mappings de la ejecución anterior en cada arranque del proxy, por lo que esto solo afecta en una instalación completamente nueva — los arranques posteriores tienen algo listo antes de que Geyser escanee.

Advertencias "Duplicate bedrock_identifier" al arrancar el proxy

Dos backends emitieron el mismo identificador de Bedrock para el mismo ítem base. Gana el último que escribe; inofensivo si solo necesitas que un backend proporcione ese ítem. Si ambos backends deben alojar ítems personalizados distintos bajo el mismo ítem base, renombra uno de los modelos Java de origen para que los hashes autogenerados difieran.

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

El proxy dispara un banner de chat a todos los jugadores de Java en línea cuando una sesión de Bedrock se carga sin un paquete de RSPM utilizable:

⚠ [RSPM] Bedrock player Alice connected before the resource pack was ready — they're seeing plain armor stands instead of custom models. Tell them to disconnect and reconnect; the pack will load on their next session. (Cause: ...)

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.

Lo que aún no se soporta

• 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 adopta una clave exactamente una vez y no aceptará un reemplazo por mensaje. Rotarla significa borrar el archivo network-key del proxy y limpiar networkKey del data.yml de cada backend, y luego reiniciarlo todo.