How to install and set up a standalone ConnectServer in MU Online

The ConnectServer is the most misunderstood — and most critical — piece of a MU Online server. It doesn't run maps, calculate damage, or store characters: its only job is to be the front door. When the player opens the client, it's the ConnectServer that delivers the server list, shows each server's load, and, on clicking a server, redirects the connection to the IP and port of the right GameServer. Because it is the only piece exposed to the internet before login, it is also the first target for attacks and the point where 90% of "won't connect" errors are born. This tutorial explains the ConnectServer's role in detail and shows how to install and configure it standalone, on its own machine and port, the way production servers do.

What the ConnectServer is

Think of the ConnectServer as the reception desk of a building with several floors (the GameServers). The visitor (the client) doesn't go straight up to a floor: they pass through reception, see the list of available floors, and are directed to the chosen one. The real flow is:

1. The client opens and reads ServerList.dat, which contains the ConnectServer's IP and port.
2. The client connects to the ConnectServer (the public port, e.g., 44405).
3. The ConnectServer returns the server list — each registered GameServer, with its name and occupancy percentage.
4. The player picks a server; the ConnectServer responds with that GameServer's IP:port.
5. The client disconnects from the ConnectServer and connects directly to the GameServer to log in and play.

In other words: after redirecting, the ConnectServer leaves the stage. That is what makes isolating it possible — it is lightweight, holds no game state, and can live on its own.

Why isolate the ConnectServer

Running the ConnectServer separate from the GameServer brings concrete advantages:

• Security: the GameServer's real IP stays hidden until the redirection. Floods and scans hit the isolated ConnectServer first, protecting the game server.
• Availability: you can restart the GameServer (patch, tweak, crash) without taking down the server selection screen. The player sees "server offline" instead of "won't connect."
• Scale: a single ConnectServer can list several GameServers, even on different machines. This is how you build a multi-channel or multi-realm server.
• Attack mitigation: you can place a firewall, rate-limit, or anti-DDoS protection only in front of the ConnectServer, without touching the GameServer.

On a local test server, everything runs on the same machine (127.0.0.1) and isolation doesn't matter. In production, isolating it is the professional standard.

Prerequisites

• A MU server already built and working (if you don't have one yet, see the server creation tutorial).
• Access to your emulator's package (IGCN, MuEMU, X-Team, Season 6, etc.) containing the ConnectServer executable.
• A public IP (or a VPS) if the server is online; or 127.0.0.1 for local testing.
• Permission to open ports in the system firewall and in the provider/router NAT.
• Your emulator's ServerList.dat editing tool (the file is usually encrypted).
• A backup of the configuration files before any changes.

Files and ports involved

The names and numbers vary by emulator — treat the values below as examples and confirm them in your package.

> Watch out for the name collision: there is a ServerList.dat on the server (which the ConnectServer uses to know which GameServers to list) and another ServerList.dat on the client (which tells the game where the ConnectServer is). They are different files with the same name — don't confuse them.

Step 1 — Locate and prepare the executable

In the emulator package, the ConnectServer is usually in its own folder (ConnectServer/, CS/, or similar), with the executable and a .ini or .dat configuration file. If you are going to isolate it on another machine/VM, copy the entire ConnectServer folder there, keeping the structure. It generally doesn't need MySQL or the game data — it is self-sufficient.

Step 2 — Configure the ConnectServer (ports and listening)

Open the ConnectServer's main config. On many emulators it is a .ini in the style below — the key names vary, but the concept is the same:

[ConnectServer]
; Port the CLIENT connects on (the same as the client's ServerList.dat)
ConnectServerPort = 44405

; Port the GameServers REGISTER on with the ConnectServer
GameServerListPort = 55557

; Data/response port used internally
DataPort = 55901

; Maximum number of simultaneous inbound connections
MaxConnections = 1000

; Show each server's load (%) in the list
ShowServerLoad = 1

• ConnectServerPort is the public port — the one the player actually reaches. It needs to be open in the firewall and the NAT.
• GameServerListPort is how each GameServer "introduces itself" to the ConnectServer. If the ConnectServer and GameServer are on different machines, this port needs to be reachable between them (internal network or opened).
• MaxConnections is your first line of defense against flooding — tune it to the size of the server.

Save it and leave the restart for after you configure the list.

Step 3 — Register the GameServers in the ConnectServer's list

The ConnectServer needs to know which servers to advertise. This usually lives in a ServerList.dat (server side) or in a section of the config itself. Each line defines a server on the selection screen:

[ServerList]
; Code | Displayed name | GameServer IP | GameServer port
0 | ViciadosMU - Season 6 | 200.100.50.10 | 55901
1 | ViciadosMU - PvP      | 200.100.50.11 | 55901

This is where the redirection happens: the IP and port in this list are exactly where the client is sent when the player picks that server. If you isolated the ConnectServer, the IP here is the GameServer's (another machine), not the ConnectServer's own. Getting this wrong is the number-one cause of "selects the server and can't get in."

Step 4 — Adjust the GameServer's IpAddress

On the other side, the GameServer also needs to correctly advertise the IP on which it accepts connections. In the GameServer config (this varies: GameServerInfo.dat, GameServer.ini, an [ServerInfo] section) there is an address key:

[GameServerInfo]
; IP the GameServer advertises to the ConnectServer and the client
IpAddress = 200.100.50.10

; Port the GameServer accepts players on (matches the CS list)
GameServerPort = 55901

; Address:port of the ConnectServer where this GameServer registers
ConnectServerIp = 200.100.50.20
ConnectServerPort = 55557

Golden rule for IpAddress:

• Local/test server: 127.0.0.1.
• Online server: the public IP the player's client can reach — never 127.0.0.1 or the internal LAN IP, or only you (on the same machine) will be able to get in.

ConnectServerIp closes the triangle: it is where this GameServer registers. Since the ConnectServer is isolated, this IP is the ConnectServer machine's.

Step 5 — Configure the client's ServerList.dat

Now the player's side. The client's ServerList.dat points the game to the ConnectServer. It is almost always encrypted — use your emulator's tool (ServerList Editor) and don't edit it in Notepad, or the client rejects the file.

Configure:

• IP: the public IP (or 127.0.0.1 in a local test) of the ConnectServer's machine — never the GameServer's.
• Port: the same ConnectServerPort from Step 2 (e.g., 44405).

If you change the ConnectServer's IP or port later, you need to redistribute the updated ServerList.dat to players through the launcher — otherwise they keep hitting the old address.

Step 6 — Open the ports in the firewall and NAT

Isolation only works with the network opened. Open:

• On the ConnectServer machine's firewall: the public port (44405) and the registration port (55557).
• In the NAT/router or the VPS panel: forward the public port 44405 to the ConnectServer machine.
• Between the ConnectServer and GameServer (if on different machines): make sure 55557 and 55901 can talk over the internal network.

On Windows, an example of opening ports from the command line:

; PowerShell / Command Prompt as administrator
netsh advfirewall firewall add rule name="MU ConnectServer" dir=in action=allow protocol=TCP localport=44405
netsh advfirewall firewall add rule name="MU GameServer Reg" dir=in action=allow protocol=TCP localport=55557

Step 7 — Startup order and testing

The order matters. Start the services in this sequence:

1. ConnectServer first (reception needs to be up to receive registrations).
2. GameServer(s) next — each one will register with the ConnectServer via ConnectServerIp:55557.
3. Confirm in the ConnectServer console that the GameServers appeared as connected.

Then test from the client side:

1. Open the client and reach the server selection screen — the list should load (proof that the ConnectServer responded).
2. Check that the load (%) appears, indicating the GameServers are registered.
3. Pick a server: the client should redirect and reach login (proof that the list's IP:port is correct).
4. Log in and enter the game (proof that the GameServer's IpAddress is reachable).

Common errors and fixes

Best practices for production

• A VM just for the ConnectServer. It is lightweight; a small machine handles it, and the isolation is worth the cost.
• Never expose the GameServer's port directly to the public unless necessary — let the ConnectServer be the public face.
• Monitor the console of the ConnectServer: GameServer registration drops show up there before the player complains.
• Version the client's ServerList.dat. Every IP/port change requires redistributing it through the launcher.
• Document the port map (44405 public, 55557 registration, 55901 data). This saves hours when you migrate to a new VPS.

Launch checklist

• ConnectServer folder isolated on its own machine/VM.
• Ports configured in the .ini (public 44405, registration 55557, data 55901).
• GameServers registered in the ConnectServer's list with the correct IP:port.
• GameServer's IpAddress using the public IP (never 127.0.0.1 in production).
• GameServer's ConnectServerIp/Port pointing to the isolated ConnectServer.
• Client's ServerList.dat pointing to the ConnectServer's IP:port.
• Ports opened in the firewall and forwarded in the NAT/VPS.
• Boot order tested (ConnectServer → GameServer → client).
• Full flow validated: the list loads, redirects, and logs into the game.

With the ConnectServer isolated and tested, you have a solid, scalable network foundation: adding a new GameServer becomes just one more line in the list and a registration pointing to the same reception. From here, the natural next step is to harden that public port with anti-DDoS protection and rate-limiting, since it is the only face of your server exposed to the internet.

Frequently asked questions