Plan Velocity or BungeeCord networks — backends, try lists, forced hosts — and export a ready config file.
Choose Velocity or BungeeCord, then set how player data is forwarded to your game servers.
Add each server behind the proxy. Lower fallback numbers are tried first when a player joins.
Optional try list for default join order, and forced hosts to send a domain straight to one server.
Comma-separated server names tried in order when a player connects without a forced host.
One per line: domain = server — e.g. survival.example.com = survival
Plan a Velocity or BungeeCord Minecraft network with backends, try lists, and forced hosts — then export a velocity.toml or BungeeCord config.yml ready to drop on your proxy.
Proxy networks send players from a lobby to survival, minigames, or event servers. This planner collects server names, addresses, fallback order, and forced hosts, then writes a config for Velocity or BungeeCord/Waterfall-style setups.
See a simple route overview so staff understand where play.example.com and other hostnames land before you go live.
Velocity modern forwarding needs matching settings on backend Paper servers. Legacy modes exist for older bridges. The planner exposes forwarding choices and warns when forced host names do not match a backend you defined.
Export the file, install it on the proxy host, and keep backend online-mode settings consistent with your chosen forwarding mode.
Open proxy and backend ports carefully — usually only the proxy is public. Point DNS at the proxy, test forced hosts, and confirm try-list order sends players to lobby first. Use the port checklist for firewall commands.
Document each backend’s private address so restarts and host moves do not break the try list.
