How to configure the JoinServer on your MU Online server

The JoinServer is one of the most misunderstood pieces of a MU Online server — and, not by coincidence, one of the biggest headaches when something "almost works": the player logs in, sees the server list, chooses a channel, but freezes at "connecting" or gets in without being able to form a party with someone on another GameServer. This service is the intermediary that validates the login session and stitches together the communication between the various GameServers of the same world. Configured correctly, it is invisible; configured wrong, it takes down party, guild, and cross-server events without giving a clear error. This tutorial explains the role of the JoinServer, how to configure it, how to link it to the GameServer and the ConnectServer, and how to test each end.

What the JoinServer is

In the MU Online connection flow there are three back-end services that the player never sees directly, but on which everything depends: ConnectServer, JoinServer, and GameServer (plus the database). The JoinServer sits in the middle of that chain. Its central function is to validate the login session — when the player authenticates the account, it is the JoinServer that confirms that session is valid and keeps it coherent while the player moves through the world. In addition, it centralizes session data that needs to be seen by more than one GameServer at the same time.

It is this centralization that gives the JoinServer its "cross-server" role: because all the GameServers of the same world point to the same JoinServer, information such as party, guild, and certain events can be recognized across different channels. Without it, each GameServer would be an isolated island.

The JoinServer's role in party, guild, and events

It's worth detailing why so much depends on it:

• Party across channels: when two players are on distinct GameServers of the same world, it is the JoinServer that recognizes both sessions and allows the party to be formed and maintained.
• Guild and alliances: guild data queried by different GameServers passes through this session layer; if the JoinServer is not aligned, members "vanish" from the guild when switching channels.
• Cross-server events: events that gather players from different channels (depending on the emulator) use the JoinServer's session coherence to know who is who.
• Session stability: it prevents duplicate sessions and helps drop ghost logins, keeping the "who is online" base coherent.

> Golden rule: if a feature works within a GameServer but breaks between GameServers, the JoinServer (or the route to it) is the first place to investigate.

Prerequisites

• A MU server already installed and running locally or on a VPS (see the server creation tutorial).
• Access to the configuration files of the JoinServer, the GameServer, and the ConnectServer.
• The IP of the machine where the JoinServer will run (127.0.0.1 if everything is local; internal/external IP if distributed).
• Permission to open ports in the firewall of the machine/VPS.
• A backup of the configuration files before any change.

Files and ports involved

The file names and ports vary by emulator (IGCN, MuEMU, X-Team, and derivatives). Treat the values below as examples and always check your MuServer's standard:

The JoinServer's port is almost always an internal port, used in the conversation between the JoinServer and the GameServer — it is not the port the game client connects to. This is a constant source of confusion: opening only the client port and forgetting the internal one makes the server "start up" but the GameServers don't talk to the JoinServer.

Step 1 — Locate and open the JoinServer configuration

1. Go to your MuServer folder and locate the JoinServer's executable and configuration file (something like JoinServer.exe + JoinServer.ini, or a JoinServer folder with a config file).
2. Open the configuration file in a plain text editor (Notepad++ is ideal — it avoids corrupting the encoding).
3. Identify the main keys: listening port, bind IP, and the list/registry of GameServers this JoinServer will serve.

Not every emulator exposes the three things in the same file — in some, the GameServer list is in a separate file (ServerList/GameServerList). Note where each one is.

Step 2 — Define the listening port and IP

In the JoinServer file, define the internal port and the bind IP. A typical block looks like this (the exact format varies by emulator):

[JoinServer]
; IP the JoinServer listens on. 0.0.0.0 = all interfaces
IPAddress = 0.0.0.0
; Internal port used by the GameServers to connect
Port = 55970
; Connection to the accounts database
DBServer = 127.0.0.1
DBName = MuOnline

• Use 0.0.0.0 in IPAddress to listen on all interfaces when the GameServers are on different machines; use 127.0.0.1 if everything is local.
• Note the Port — it will need to be identical in each GameServer's configuration.
• Confirm the database details: the JoinServer normally also touches the accounts base to validate the session.

Save the file keeping the original encoding (usually ANSI). Saving as UTF-8 with BOM can keep the service from starting.

Step 3 — Register the GameServers in the JoinServer

Here lies the secret of cross-server. The JoinServer needs to know which GameServers it serves. In many emulators there is a list like this:

[GameServerList]
; Code = IP : Port
0 = 127.0.0.1:55901
1 = 127.0.0.1:55902
2 = 127.0.0.1:55903

• Each line corresponds to a GameServer (channel) of the same world.
• The Code here must match the server code defined inside each GameServer.
• For party and guild to work across channels, all the GameServers that should share a session must be in this list, pointing to the same JoinServer.

If a GameServer is not listed (or has the wrong IP/port), it will still start, but stays "deaf" to the rest of the world — players on it don't form parties with the others.

Step 4 — Point each GameServer to the JoinServer

Now close the loop from the other side. In each GameServer's configuration, locate the keys that point to the JoinServer and align them with Step 2:

[GameServerInfo]
ServerCode = 0
; JoinServer address (same machine or internal IP)
JoinServerIP = 127.0.0.1
JoinServerPort = 55970

• JoinServerIP and JoinServerPort must be exactly the IP and port configured in the JoinServer.
• ServerCode must match the Code registered in the JoinServer's list (Step 3).
• Repeat for all GameServers, changing only the ServerCode (and each one's client port).

This is the most common mistake of all: a GameServer pointing to a different port or IP than the JoinServer. It works in isolation, but breaks everything cross-server.

Step 5 — Link to the ConnectServer

The ConnectServer is the client's entry point: it shows the server list and forwards the player to the chosen GameServer. The JoinServer does not talk directly to the client, but the chain is only coherent if all three are aligned:

1. In the ConnectServer, confirm that the server list points to the correct client IPs/ports of the GameServers.
2. Make sure the ServerCode values used in the ConnectServer, the GameServers, and the JoinServer's list refer to the same servers.
3. Recommended startup order: database → JoinServer → GameServers → ConnectServer. Starting the GameServer before the JoinServer usually generates a connection error at boot.

Step 6 — Open ports in the firewall

Even with everything correct in the files, the firewall may block the internal conversation.

1. Open the JoinServer's internal port (e.g., 55970) for connections coming from the GameServers.
2. If the JoinServer and GameServers are on different machines, open the port in the inbound firewall of the JoinServer machine and ensure a route between them.
3. Also open the client ports of the GameServers and the ConnectServer, so the player can connect.
4. On a VPS, remember there may be a firewall in the provider's panel in addition to the Windows firewall.

Step 7 — Test the full chain

1. Start the services in the correct order and confirm, in the consoles, that each GameServer reports a successful connection to the JoinServer.
2. Log in with an account, view the server list, and connect to a channel — the login should complete without freezing at "connecting".
3. Log in with two accounts on different GameServers of the same world and try to form a party. If it works, cross-server is OK.
4. Test guild: create/join a guild and check that members appear when switching channels.
5. Leave the server running for a few minutes and watch for disconnections or strange reconnections in the JoinServer logs.

Common errors and fixes

Operational best practices

• Document the port map (JoinServer, each GameServer, ConnectServer) in a spreadsheet — it saves hours of future debugging.
• Keep the GameServer list synchronized whenever you add a new channel: register it in the JoinServer, in the ConnectServer, and adjust the ServerCode.
• Monitor the JoinServer logs — repeated connection drops from a GameServer indicate network, firewall, or a port conflict.
• Back up the configs before each change; one wrong character takes the service down at boot.

Configuration checklist

• JoinServer listening port and IP defined and noted.
• All the world's GameServers registered in the JoinServer's list.
• Each GameServer pointing to the correct JoinServer IP/port.
• ServerCode consistent between JoinServer, GameServers, and ConnectServer.
• ConnectServer with the correct server list.
• Ports opened in the OS and provider firewall (if VPS).
• Boot order respected (DB → JoinServer → GameServers → ConnectServer).
• Party and guild tested between different GameServers.

With the JoinServer aligned, you have your world's session backbone working — and the foundation to scale. The natural next step is to add new GameServers (channels) reusing exactly this same map: register the channel in the JoinServer's list, point the new GameServer to the same internal port, and replicate the ServerCode across the chain. Done once carefully, expanding becomes routine.

Frequently asked questions