Could not connect to a default or fallback server significa que BungeeCord está funcionando, pero no pudo transferir al jugador a ningún destino de inicio permitido. La causa suele estar en priorities, el estado del backend, la dirección/puerto, el firewall, el forwarding o la compatibilidad de protocolo.

No abras el puerto del backend a todo internet para depurar el error. Prueba desde la perspectiva del proxy y sigue permitiendo únicamente su ruta verificada. El pilar de configuración de BungeeCord muestra el objetivo seguro.

Árbol de diagnóstico

¿Existe cada nombre de priorities bajo servers?
├─ no -> corrige el nombre y las mayúsculas/minúsculas
└─ sí
   ¿Al menos un destino está completamente iniciado?
   ├─ no -> resuelve el error de inicio del backend
   └─ sí
      ¿El proxy alcanza exactamente esa dirección y ese puerto?
      ├─ no -> revisa dirección, asignación, ruta y firewall
      └─ sí
         ¿Coinciden el forwarding y las versiones?
         ├─ no -> corrige la configuración de forma consistente
         └─ sí -> revisa el primer stacktrace concreto de proxy/backend

1. Comparar priorities con servers

servers:
  lobby:
    address: <LOBBY-ADRESSE>:<PORT>
    restricted: false

listeners:
  - priorities:
      - lobby

lobby, Lobby y lobby no son la misma clave. Cada entrada en priorities debe existir bajo servers. Con varios destinos, BungeeCord los prueba en orden; un primer destino roto no debe ocultar también el segundo fallback.

2. Iniciar realmente el backend

Un estado de contenedor «running» no es suficiente. Lee el log del backend hasta el mensaje de finalización. Los bloqueos de inicio típicos son:

  • EULA no aceptada;
  • imagen de Java incorrecta;
  • JAR de plugin dañado o incompatible;
  • error de mundo/mod;
  • puerto ya en uso;
  • el servidor escucha en otra asignación.

Después, prueba la servers.<name>.address concreta. Un ping a la IP del host no demuestra que el puerto TCP de Minecraft sea accesible.

3. Comprobar la dirección desde la perspectiva del proxy

127.0.0.1 en el contenedor del proxy apunta al propio contenedor del proxy. Úsalo solo si el backend y el proxy comparten de forma comprobada el mismo namespace de red. Con instancias separadas necesitas la dirección del backend accesible desde el proxy.

Patrones de error:

Mensaje Significado típico
Connection refused nada escucha en el puerto de destino o una regla lo rechaza activamente
Timeout la ruta o el firewall descarta paquetes, el destino está colgado o la dirección es incorrecta
Unknown host error de DNS/nombre de host
Address already in use listener duplicado/conflicto de puerto

En game-serverhosting, el guard activo del backend protege las rutas de BungeeCord comprobadas. Si el proxy está detenido o falta su origen concreto, la ruta del backend permanece intencionadamente en modo solo-drop. Inicia el proxy correcto y espera la reevaluación, en lugar de eliminar la regla de protección.

4. Comprobar el firewall con precisión

El firewall debe cumplir dos condiciones a la vez:

  1. el proxy correspondiente alcanza el puerto TCP del backend;
  2. un origen independiente no lo alcanza.

Si ambas fallan, revisa primero la asignación concreta del proxy y la resolución del origen. Si ambas funcionan, el backend está desprotegido. Habilitar el acceso para toda una subred de shared hosting o de Docker no es una reparación limpia.

5. Comparar los valores de forwarding

Para BungeeCord clásico con Paper/Spigot:

  • Proxy online_mode: true;
  • Proxy ip_forward: true;
  • Backend server.properties con online-mode=false;
  • Backend spigot.yml con settings.bungeecord: true;
  • Paper proxies.bungee-cord.online-mode: true, si el proxy autentica en modo online.

Un mensaje como If you wish to use IP forwarding... suele indicar una configuración inconsistente entre proxy y backend. Modifica estos valores solo después de hacer una copia de seguridad y siguiendo la guía de seguridad del forwarding, debido a posibles cambios de UUID.

6. Aislar versión y plugins

Compara el protocolo del cliente, el proxy y el backend. Un puerto TCP abierto puede seguir rechazando un join. Si es posible, empieza con una lobby sin plugins de proxy añadidos recientemente. Instala plugins de BungeeCord solo en el proxy y plugins de Bukkit/Paper solo en los backends; la guía de plugins explica los niveles.

No elimines plugins a ciegas de un entorno de producción. Haz una copia de seguridad de plugins/ y de la configuración, cambia una variable en una copia y revierte si falla.

7. Comprobar el dominio solo después de la ruta directa

Prueba primero la IP pública del proxy junto con el puerto. Si funciona, pero el dominio no, examina A/AAAA y SRV por separado. El nombre de destino SRV debe apuntar al proxy. Usa la guía de dominio/SRV.

Comprobación final

El error solo está resuelto cuando el TCP, el ping de Minecraft y un join real a la lobby a través del proxy están en verde. Repite después la prueba negativa independiente hacia el backend. Para una reestructuración o un cambio de versión, usa antes la ruta de copia de seguridad y rollback. El crossplay llega solo después; el TCP y Geyser-UDP se comprueban por separado.

FAQ

¿Qué significa exactamente el mensaje?

Que el propio BungeeCord está funcionando y ha aceptado al jugador, pero no pudo transferirlo a ningún destino de inicio permitido. Por tanto, el proxy no es la fuente del error — la causa está en priorities, en el estado del backend, en la dirección y el puerto, en el firewall, en el forwarding o en la versión del protocolo.

¿Puedo usar 127.0.0.1 como dirección del backend?

Solo si el proxy y el backend comparten de forma comprobada el mismo namespace de red. En el contenedor del proxy, 127.0.0.1 apunta al propio contenedor del proxy, no al backend. Con instancias separadas necesitas la dirección bajo la cual el proxy realmente alcanza el backend.

Connection refused o timeout: ¿cuál es la diferencia?

Connection refused significa que nada escucha en el puerto de destino o que una regla lo rechaza activamente: normalmente un backend no iniciado o un puerto incorrecto. Un timeout apunta a una ruta o un firewall que descarta paquetes, a un destino colgado o a una dirección incorrecta.

¿Debería abrir brevemente el puerto del backend para depurar el error?

No. Un puerto de backend abierto en modo offline permite que cualquier persona se haga pasar por cualquier jugador. Prueba en su lugar desde la perspectiva del proxy. Si la ruta del backend permanece bloqueada aunque el proxy esté en funcionamiento, revisa la asignación concreta del proxy — y no elimines la regla de protección.

El puerto TCP es accesible, pero el join sigue fallando: ¿a qué se debe?

Un puerto abierto solo demuestra que algo está escuchando. Si el join sigue fallando después, compara la versión de protocolo del cliente, el proxy y el backend, y prueba con una lobby sin plugins de proxy añadidos recientemente. Comprueba también si hay plugins de BungeeCord instalados por error en un backend.

Fuentes primarias