How to Configure Connection Proxy Between ConnectServer and GameServer

Understanding the ConnectServer → GameServer Architecture in S6

MU Online Season 6 uses a two-stage architecture to manage player connections. The ConnectServer (CS) is the entry point: it listens on port 44405 and responds to the client with a list of available GameServers. When the player selects a server from the login screen, the client closes its connection to the CS and opens a new direct connection to the GameServer (GS) on the port that was advertised — typically 55901 for the first server.

This separation exists by design: it allows multiple GameServers to coexist under a single entry point, and simplifies maintenance because one GS can be restarted without affecting the others. The downside is that this separation creates a layer where misconfigured network settings cause silent failures — the client connects to the CS, receives the list, attempts to connect to the GS, and simply hangs on "Connecting..." indefinitely.

The proxy layer enters this flow between the CS and the GS, or between the client and the CS, depending on the goal: IP protection, load balancing, or packet filtering.

MU Client
    │
    ▼ port 44405
ConnectServer
    │ responds with IP:port of GS
    ▼
    [Intermediate Proxy] ← configuration point covered in this guide
    │
    ▼ port 55901
GameServer
    │
    ├── DataServer (port 55980)
    └── EventChipServer / SubServers

Configuring the ConnectServer to Route Through the Proxy

Before setting up any proxy, the ConnectServer must be pointing to the correct address. Open the CS configuration file (typically ConnectServer.ini or ServerInfo.xml depending on your S6 build) and find the server list section:

; Example MainServerInfo configuration (common .ini format in S6)
[ServerInfo01]
ServerCode    = 0
ServerName    = Lorencia
ServerAddress = 192.168.1.100   ; ← GameServer IP VISIBLE to the client
ServerPort    = 55901
ServerType    = 0
MaxUser       = 200
CurrentUser   = 0

If you are using a reverse proxy (e.g. HAProxy or the proxy service built into your build), ServerAddress should point to the proxy IP, not directly to the GS. The proxy then forwards to 127.0.0.1:55901 internally.

Flow with proxy:
Client → CS (44405) → receives proxy_ip:55901
Client → Proxy (55901) → GameServer (127.0.0.1:55901 internal)

Flow without proxy (direct):
Client → CS (44405) → receives gs_ip:55901
Client → GameServer (55901) directly

Essential Firewall Rules

The firewall is responsible for the majority of connection failures that look like server configuration problems. On Windows Server (the most common environment for MU S6), rules must explicitly allow the following inbound ports:

Required ports for MU Online S6:
→ TCP 44405   ConnectServer (client entry point)
→ TCP 55901   Primary GameServer (GS Code 0)
→ TCP 55902   Secondary GameServer (GS Code 1, if present)
→ TCP 55980   DataServer (internal GS ↔ DS communication)
→ TCP 55960   EventChipServer (optional, special events)
→ UDP 44405   Some builds also use UDP on the CS

Database ports (never expose publicly):
→ TCP 1433    SQL Server (localhost or internal LAN only)

Adding rules on Windows Firewall via PowerShell (no GUI required):

# Allow ConnectServer
New-NetFirewallRule -DisplayName "MU ConnectServer" `
  -Direction Inbound -Protocol TCP -LocalPort 44405 -Action Allow

# Allow GameServer
New-NetFirewallRule -DisplayName "MU GameServer" `
  -Direction Inbound -Protocol TCP -LocalPort 55901 -Action Allow

# Allow DataServer only for local address
New-NetFirewallRule -DisplayName "MU DataServer Internal" `
  -Direction Inbound -Protocol TCP -LocalPort 55980 `
  -RemoteAddress 127.0.0.1 -Action Allow

Configuring the TCP Reverse Proxy

For environments where you want to hide the GameServer IP or add a filtering layer, a simple TCP proxy solves the problem. HAProxy is the most widely used tool for this on Linux environments, but on Windows, Nginx with the stream module or even socat can do the job.

Example HAProxy configuration for transparent GameServer proxying:

# /etc/haproxy/haproxy.cfg — stream section for MU Online S6

frontend mu_connectserver
    bind *:44405
    mode tcp
    default_backend cs_backend

backend cs_backend
    mode tcp
    server cs_local 127.0.0.1:44415_internal check

frontend mu_gameserver
    bind *:55901
    mode tcp
    default_backend gs_backend

backend gs_backend
    mode tcp
    server gs_local 127.0.0.1:55911_internal check inter 5s rise 2 fall 3

In this setup, HAProxy listens on the public ports and forwards traffic to processes running on internal ports (renamed to avoid conflicts). The GameServer and ConnectServer are configured to bind only to 127.0.0.1 with different ports (e.g. 55911 instead of 55901), and the proxy handles the public binding.

Diagnosing Common Connection Problems

When connections fail, diagnosis follows a specific order:

Step 1: Verify the process is running
→ netstat -an | findstr "44405"   (must show LISTENING)
→ netstat -an | findstr "55901"   (must show LISTENING)

Step 2: Check external reachability
→ telnet YOUR_PUBLIC_IP 44405     (must connect without error)
→ telnet YOUR_PUBLIC_IP 55901     (must connect without error)

Step 3: Check ConnectServer logs
→ File ConnectServer.log — search for "GameServer connected"
→ If GS does not appear as connected to CS, problem is between them

Step 4: Inspect the ServerList the CS is sending
→ Wireshark on the client: filter by "tcp.port == 44405"
→ The CS response packet must contain a valid public IP

Step 5: Check DataServer
→ If GS connects to CS but players freeze at login,
  DS may be failing — check port 55980 and DS logs

Handling Multiple GameServers

S6 supports multiple GameServers, each with its own maps. Each GS has a unique ServerCode and can host different map sets. A typical distribution in a well-configured S6 server looks like this:

GameServer 0 (Lorencia, Noria, Devias, Dungeon 3 floors)
    → port 55901

GameServer 1 (Atlans 3 floors, Tarkan, Icarus, Lost Tower 7 floors)
    → port 55902

GameServer 2 (Aida, Karutan, Kanturu 3 floors, Raklion, Vulcanus)
    → port 55903

GameServer 3 (Kalima 1-7, Land of Trials, Crywolf Fortress, Acheron)
    → port 55904

Each GameServer requires its own entry in ServerList.dat and its own firewall rule. The ConnectServer manages all of them and shows the player a real-time list with current occupancy — which is why the CS needs a stable connection to each GS to report CurrentUser correctly.

When Crywolf Fortress is hosted on a dedicated GS, keep in mind that a failed Crywolf event (when Balgass is not defeated) is precisely what triggers Loch's Feather drops from Balgass — an ingredient needed alongside the Jewel of Creation to craft Level 3 Wings. This directly affects server economy, so stability of the GS hosting Crywolf is operationally significant.

Continuous Connection Monitoring

After completing the setup, implement basic monitoring to detect disconnections between the CS and the GameServers before players notice:

# Simple PowerShell script to check if processes are listening
# Save as check-mu-ports.ps1 and schedule in Task Scheduler

$ports = @(44405, 55901, 55902, 55980)
$timestamp = Get-Date -Format "yyyy-MM-dd HH:mm:ss"

foreach ($port in $ports) {
    $conn = netstat -an | Select-String ":$port\s+.*LISTENING"
    if (-not $conn) {
        # Port not listening — write to log
        Add-Content -Path "C:\MUServer\logs\monitor.log" `
            -Value "$timestamp - ALERT: port $port is NOT LISTENING"
    }
}

Scheduling this script every 2 minutes in Windows Task Scheduler gives you a history of exactly when each process went down, which is essential for diagnosing intermittent drops that are difficult to reproduce manually.

Perguntas frequentes