One Port for Multiple Minecraft Servers: This Go Tool Is Lightweight to Deploy
Anyone who runs a Minecraft server will eventually run into port-related issues.
Suppose you have one server and plan to run a survival server, a minigame server, and a creative server at the same time. Minecraft servers use port 25565 by default, and the three services cannot bind to the same port simultaneously. You would have to change them to 25566, 25567, and 25568, then tell players:
“Connect to :25566 for survival, :25567 for minigames, and :25568 for creative.”
As the number of ports increases, players quickly have trouble remembering them. Even more troublesome, you also need to expose multiple ports to the public Internet, which increases both firewall configuration complexity and security risks.
BungeeCord and Velocity can solve this problem, but they are complete Minecraft proxy platforms in their own right, including plugin systems, permission management, cross-server teleportation, chat forwarding, and cross-server communication. The more comprehensive the feature set, the greater the configuration and resource overhead.
If your needs are simple—you only want players to connect through a single port and route requests to different backend servers based on the domain name—infrared may be worth a look. It only handles proxying and status placeholders; it does not build a complete multi-server ecosystem.
What Is infrared?
infrared is a Minecraft reverse proxy tool written in Go that also supports status placeholder servers. According to the project page, as of the time of this review, it has 855 stars on GitHub and is licensed under AGPL-3.0. Project page
Its purpose is straightforward: allowing multiple Minecraft servers to share a single public port. The project README describes it as a reverse proxy and status placeholder, rather than a full-featured server network platform. Official README
Its operating model is similar to reverse proxies such as Nginx and HAProxy. infrared listens on the public 25565 port. When a player connects, the target server address is included in the request. infrared then selects a backend according to its domain-matching rules and forwards the connection to the corresponding internal address.
For example, suppose you have two domains:
survival.example.comcreative.example.com
Both domains resolve to the public address of the same server, and infrared listens on port 25565. infrared can then forward the first domain to 25566 on the internal network and the second domain to 25567.
Players who connect to survival.example.com will enter the survival server, while those who connect to creative.example.com will enter the creative server. The entire process requires remembering only the domain names, without entering port numbers.
Core Features
infrared does not have a long feature list, but each feature is focused on the needs of port proxying.
Reverse proxying is its core function. The configuration file can specify domains and backend addresses, supports wildcard matching, and allows multiple domains to point to the same backend. The configuration structure provided in the official documentation is relatively simple: in most cases, you only need to specify a list of domains and the backend server address. Proxy configuration documentation
Status response caching is used to handle server list refreshes from Minecraft clients. When a player refreshes the server list, the client sends a ping request to the server to retrieve information such as the MOTD, player count, and latency. If many players refresh their server lists at the same time, the backend server has to process many duplicate status requests.
infrared can cache status responses returned by the backend. Subsequent requests of the same type can use the cached result directly, reducing the number of ping requests that the backend server needs to handle.
It also supports PROXY Protocol. When enabled, the backend server can obtain the player’s real IP address instead of seeing only infrared’s address. This is useful for servers that need to log player IPs, enforce IP allowlists, or perform access statistics. However, the backend server must also be configured correctly and trust PROXY Protocol information received from the proxy. The current infrared documentation states that PROXY Protocol v2 is supported. PROXY Protocol documentation
The rate limiter can restrict connection frequency by IP address. For example, it can limit the number of new connections created by the same IP within a given time window, reducing the impact of high-frequency pings and connection requests on the server. It can serve as a basic rate-limiting layer, but it cannot replace professional DDoS mitigation or upstream protection. Rate limiter documentation
Status Placeholder Server
infrared also provides a practical feature called a status placeholder server.
Consider the following situation: multiple Minecraft servers are running on one machine, but some servers are started only during events or may be undergoing maintenance, so they are not online all the time.
When a backend service is offline, players typically see only “Unable to connect to server” in the server list. This message provides little information, and players cannot tell whether the server is temporarily under maintenance or has been permanently shut down.
The status placeholder feature can return an alternative status when the backend is unavailable. You can change the MOTD to “Server under maintenance, please try again later,” set the online player count to 0, and show players a server entry with a clear explanation instead of a simple connection failure.
Note that status placeholders primarily address status display in the server list. They are not a queuing system and do not automatically implement a cross-server lobby, waiting queue, or player-kick logic. When players actually try to join, the backend must still be available. If you need a queue or maintenance lobby, you will need to use other server-side tools as well.
For Minecraft communities with multiple subservers, this type of status display is useful. Whether the backend is running normally, temporarily offline, or under maintenance, players can see relatively consistent information.
Why Go?
infrared uses Go primarily because it is simple to deploy.
The official build instructions use the following command:
CGO_ENABLED=0 go build -ldflags "-s -w" -o ./out/infrared ./cmd/infrared
Here, CGO_ENABLED=0 disables CGO, while -s -w removes some symbol and debugging information. After compilation, the result is a standalone binary that can be run directly, without installing Java or another runtime environment on the target server. Official build instructions
However, the actual binary size varies depending on the version, system architecture, and compilation parameters. A more accurate description is that it is a lightweight deployment tool, rather than claiming that “a few hundred KB” is a fixed size across all platforms and versions.
Go’s goroutines are also well suited to network proxy scenarios. A proxy needs to handle many connections concurrently, and goroutines generally have lower creation and scheduling costs than traditional heavyweight threads. In addition, infrared itself only handles domain routing, status responses, and rate limiting, so it has fewer functions to maintain at runtime, making its overall resource usage relatively easy to control.
Of course, Go does not mean zero memory usage. The number of connections, number of backends, cache size, and actual traffic volume all affect resource consumption. Its advantages are low baseline overhead and few dependencies. Deployment also does not require preparing an additional Java runtime environment.
Comparison with Similar Tools
Minecraft proxy tools serve different purposes.
BungeeCord is one of the earlier full-featured proxy solutions. It covers a broad range of functionality, including a plugin system, cross-server teleportation, chat forwarding, and permission synchronization, making it suitable for building large server networks. However, it requires maintaining a more complete proxy platform, so its configuration and runtime overhead increase accordingly.
Velocity is a modern alternative to BungeeCord, with better performance and extensibility. It likewise provides a plugin system and full cross-server proxy capabilities. For server networks that require a lobby, cross-server teleportation, global chat, and unified permissions, Velocity is generally a better fit.
infrared is not in the same product category. It has no plugin ecosystem and does not handle cross-server teleportation, global chat, or unified permissions. Its primary purpose is to forward connections based on domain names and return status placeholder information when a backend is unavailable.
If you want to build a complete multi-server network, you should consider Velocity or BungeeCord. If you only want multiple backends to share a single public port, infrared is simpler.
The project README also lists another similar tool, mc-router. mc-router is also written in Go, but its official README places greater emphasis on Kubernetes and Docker service discovery, automatic scaling, and other features, making it more suitable for containerized deployment scenarios. mc-router project page
Deployment Methods
infrared can run directly as a binary and also provides a Docker image.
For a direct deployment, download the appropriate version for your operating system, prepare the configuration file, and run the program. The official documentation currently lists build artifacts for platforms including Linux, Windows, and macOS. If you do not want to install Docker on the server, this approach is more straightforward. Official deployment documentation
For Docker deployment, you can use the haveachin/infrared image. The official example maps 25565 on the host to 25565 in the container, then mounts the local configuration directory at /etc/infrared in the container. Once configured, start the container. Docker Compose deployment instructions
The configuration file uses YAML format. Proxy rules are generally placed in the proxies directory, with each rule specifying a domain-matching pattern and the corresponding backend address. Once configured, infrared starts and listens on the port, allowing players to access different servers through different domain names.
The official documentation site is infrared.dev. It includes information on global configuration, proxy rules, PROXY Protocol, and the rate limiter.
Suitable Use Cases
infrared is best suited to the following situations.
Multiple Minecraft servers are running on a physical or cloud server, with each service distinguished by a different domain name while only one Minecraft port is exposed to the public Internet.
Backend servers are not running all day and need to display a clear MOTD to players during maintenance or downtime instead of simply showing a connection failure.
You want to add a basic rate-limiting layer in front of the backend to reduce the impact of a large number of high-frequency connection requests on the Minecraft server.
You need a lightweight gateway with low resource usage and do not require a plugin system, cross-server lobby, or global permissions.
It is not suitable for scenarios that require complete cross-server functionality. If players need to teleport directly from a survival server to a minigame server, use global chat, share permissions, or implement complex lobby and queue logic through plugins, infrared cannot accomplish these tasks on its own. In that case, you should use Velocity, BungeeCord, or another full-featured proxy platform.
infrared’s strength is precisely that it does not try to solve every problem. It limits its scope to domain routing, status response caching, PROXY Protocol, and basic rate limiting, keeping configuration and deployment lightweight.
For administrators who simply want multiple Minecraft servers to share a single public port, it is easier to get started with than a full-featured proxy platform. You do not need to learn a plugin system first or build a cross-server communication architecture. Once you have the domain names, backend addresses, and YAML configuration ready, it can run.
