Could not connect to a default or fallback server means BungeeCord is running but could not hand the player to any permitted entry target. The cause is usually priorities, backend state, address/port, firewalling, forwarding, or protocol compatibility.

Do not expose the backend port to the internet for debugging. Test from the proxy's perspective and keep all other sources blocked. The complete BungeeCord setup guide shows the secure target state.

Diagnostic tree

Does every priorities name exist under servers?
├─ no -> fix names and capitalization
└─ yes
   Is at least one target fully started?
   ├─ no -> solve the backend startup error
   └─ yes
      Can the proxy reach this exact address and port?
      ├─ no -> check address, allocation, route, and firewall
      └─ yes
         Do forwarding and versions match?
         ├─ no -> align the configuration
         └─ yes -> inspect the first concrete proxy/backend stack trace

1. Compare priorities with servers

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

listeners:
  - priorities:
      - lobby

lobby, Lobby, and lobby are different keys. Every priorities entry must exist under servers. With multiple targets, BungeeCord tries them in order; verify that a broken first target does not hide a separate error on the next fallback.

2. Confirm the backend fully started

A container marked “running” is not enough. Read the backend log through its ready message. Common startup blockers include:

  • EULA not accepted;
  • wrong Java image;
  • broken or incompatible plugin JAR;
  • world or mod errors;
  • port already in use;
  • server listening on another allocation.

Then test the concrete servers.<name>.address. Pinging a host does not prove the Minecraft TCP port is available.

3. Check the address from the proxy

Inside a proxy container, 127.0.0.1 points back to that proxy container. Use it only if backend and proxy demonstrably share a network namespace. Separate hosting instances require a backend address the proxy can reach.

Error Typical meaning
Connection refused nothing listens on the target port or a rule actively rejects it
timeout route/firewall drops traffic, target hangs, or address is wrong
Unknown host DNS or hostname error
Address already in use duplicate listener or allocation conflict

At game-serverhosting, the active backend guard protects the verified BungeeCord paths. When the proxy is stopped or its concrete source is missing, the backend path intentionally remains drop-only. Start the assigned proxy and let the source reconcile instead of removing the protection.

4. Check the firewall precisely

The firewall must prove both statements:

  1. the assigned proxy can reach the backend TCP port;
  2. an independent source cannot reach it.

If both fail, verify proxy assignment and source resolution. If both work, the backend is exposed. Allowing a whole shared-hosting or Docker subnet is not a safe fix.

5. Compare forwarding values

For classic BungeeCord with Paper/Spigot:

  • proxy online_mode: true;
  • proxy ip_forward: true;
  • backend server.properties with online-mode=false;
  • backend spigot.yml with settings.bungeecord: true;
  • Paper proxies.bungee-cord.online-mode: true when the proxy authenticates online.

If you wish to use IP forwarding... commonly indicates inconsistent proxy/backend settings. Because changing them can change UUIDs, create a backup and follow the secure forwarding guide.

6. Isolate versions and plugins

Compare client, proxy, and backend protocol versions. An open TCP port can still reject the Minecraft join. Start with a lobby free of newly added proxy plugins where possible. Put BungeeCord plugins on the proxy and Bukkit/Paper plugins on backends; the plugin guide explains the layers.

Do not remove production plugins blindly. Back up plugins/ and configuration, change one variable in a clone, and retain a rollback.

7. Check DNS after the direct proxy path

First test the public proxy IP and port. If that works but the domain fails, inspect A/AAAA and SRV separately. The SRV target hostname must resolve to the proxy. Follow the domain/SRV guide.

Final verification

The incident is resolved only when TCP, Minecraft ping, and a real lobby join through the proxy pass. Repeat the independent negative test against the backend. Use the backup and rollback workflow before migrations. Add crossplay only afterward, testing TCP separately from Geyser UDP.

Primary sources