Como Configurar Proxy de Conexão entre ConnectServer e GameServer

Entendendo a Arquitetura ConnectServer → GameServer no S6

O MU Online Season 6 utiliza uma arquitetura de dois estágios para gerenciar conexões de jogadores. O ConnectServer (CS) é o ponto de entrada: ele escuta na porta 44405 e responde ao cliente com a lista de GameServers disponíveis. Quando o jogador seleciona um servidor na tela de login, o cliente fecha a conexão com o CS e abre uma nova conexão diretamente com o GameServer (GS) na porta que foi informada, geralmente 55901 para o primeiro servidor.

Essa separação existe por design: permite que múltiplos GameServers coexistam sob um único ponto de entrada, e facilita a manutenção pois um GS pode ser reiniciado sem derrubar os outros. O problema é que essa separação também cria um ponto onde configurações incorretas de rede causam falhas silenciosas — o cliente conecta no CS, recebe a lista, tenta conectar no GS, e simplesmente não consegue, exibindo apenas "Conectando..." indefinidamente.

A camada de proxy entra nesse fluxo entre o CS e o GS, ou entre o cliente e o CS, dependendo do objetivo: proteção de IP, balanceamento de carga, ou filtragem de pacotes.

Cliente MU
    │
    ▼ porta 44405
ConnectServer
    │ responde com IP:porta do GS
    ▼
    [Proxy Intermediário] ← ponto de configuração deste guia
    │
    ▼ porta 55901
GameServer
    │
    ├── DataServer (porta 55980)
    └── EventChipServer / SubServers

Configurando o ConnectServer para Redirecionar pelo Proxy

Antes de configurar qualquer proxy, o ConnectServer precisa estar apontando para o endereço correto. Abra o arquivo de configuração do CS (normalmente ConnectServer.ini ou ServerInfo.xml dependendo do seu build de S6) e localize a seção de lista de servidores:

; Exemplo de configuração MainServerInfo (formato .ini comum no S6)
[ServerInfo01]
ServerCode    = 0
ServerName    = Lorencia
ServerAddress = 192.168.1.100   ; ← IP do GameServer VISÍVEL pelo cliente
ServerPort    = 55901
ServerType    = 0
MaxUser       = 200
CurrentUser   = 0

Se você está usando um proxy reverso (ex.: HAProxy ou o próprio serviço de proxy do seu build), o ServerAddress deve apontar para o IP do proxy, não diretamente para o GS. O proxy então encaminha para 127.0.0.1:55901 internamente.

Fluxo com proxy:
Cliente → CS (44405) → recebe proxy_ip:55901
Cliente → Proxy (55901) → GameServer (127.0.0.1:55901 interno)

Fluxo sem proxy (direto):
Cliente → CS (44405) → recebe gs_ip:55901
Cliente → GameServer (55901) diretamente

Regras de Firewall Indispensáveis

O firewall é responsável pela maioria das falhas de conexão que parecem ser problema de configuração do servidor. No Windows Server (ambiente mais comum para MU S6), as regras precisam liberar explicitamente as seguintes portas de entrada:

Portas obrigatórias para MU Online S6:
→ TCP 44405   ConnectServer (entrada de clientes)
→ TCP 55901   GameServer principal (GS Code 0)
→ TCP 55902   GameServer secundário (GS Code 1, se houver)
→ TCP 55980   DataServer (comunicação interna GS ↔ DS)
→ TCP 55960   EventChipServer (opcional, eventos especiais)
→ UDP 44405   Alguns builds usam UDP também no CS

Portas do banco de dados (nunca expor ao público):
→ TCP 1433    SQL Server (apenas localhost ou LAN interna)

Para adicionar a regra no Windows Firewall via PowerShell (sem precisar de interface gráfica):

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

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

# Liberar DataServer apenas para IP interno
New-NetFirewallRule -DisplayName "MU DataServer Interno" `
  -Direction Inbound -Protocol TCP -LocalPort 55980 `
  -RemoteAddress 127.0.0.1 -Action Allow

Configurando o Proxy Reverso TCP

Para ambientes onde você quer ocultar o IP do GameServer ou adicionar uma camada de filtragem, um proxy TCP simples resolve o problema. O HAProxy é a ferramenta mais usada para isso em ambientes Linux, mas no Windows o Nginx com módulo stream ou até mesmo o socat cumprem o papel.

Exemplo de configuração HAProxy para proxy transparente do GameServer:

# /etc/haproxy/haproxy.cfg — seção stream para 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:44405_interno check

frontend mu_gameserver
    bind *:55901
    mode tcp
    default_backend gs_backend

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

Nessa configuração, o HAProxy escuta nas portas públicas e repassa o tráfego para os processos rodando em portas internas (renomeadas para evitar conflito). O GameServer e o ConnectServer são configurados para escutar apenas em 127.0.0.1 com portas diferentes (ex.: 55901_interno = 55911), e o proxy cuida do bind público.

Diagnóstico de Problemas Comuns de Conexão

Quando a conexão falha, o diagnóstico segue uma ordem específica:

Passo 1: Verificar se o processo está rodando
→ netstat -an | findstr "44405"   (deve mostrar LISTENING)
→ netstat -an | findstr "55901"   (deve mostrar LISTENING)

Passo 2: Verificar conectividade externa
→ telnet SEU_IP_PUBLICO 44405     (deve conectar sem erro)
→ telnet SEU_IP_PUBLICO 55901     (deve conectar sem erro)

Passo 3: Verificar logs do ConnectServer
→ Arquivo ConnectServer.log — procurar por "GameServer connected"
→ Se o GS não aparece conectado ao CS, o problema é entre eles

Passo 4: Verificar o ServerList que o CS está enviando
→ Wireshark no cliente: filtrar por "tcp.port == 44405"
→ O pacote de resposta do CS deve conter IP público válido

Passo 5: Verificar DataServer
→ Se o GS conecta no CS mas jogadores travam no login,
  o DS pode estar falhando — verificar porta 55980 e logs do DS

Considerações sobre Múltiplos GameServers

O S6 suporta múltiplos GameServers com seus respectivos mapas. Cada servidor de jogo tem um ServerCode único e pode hospedar mapas diferentes. A distribuição padrão em um servidor S6 bem configurado fica assim:

GameServer 0 (Lorencia, Noria, Devias, Dungeon 3 andares)
    → porta 55901

GameServer 1 (Atlans 3 andares, Tarkan, Icarus, Lost Tower 7 andares)
    → porta 55902

GameServer 2 (Aida, Karutan, Kanturu 3 andares, Raklion, Vulcanus)
    → porta 55903

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

Cada GameServer precisa de sua própria entrada no ServerList.dat e sua própria regra de firewall. O ConnectServer gerencia todos eles e apresenta ao jogador a lista com ocupação em tempo real — por isso o CS precisa de conexão estável com cada GS para reportar o CurrentUser correto.

Quando o Crywolf Fortress é hospedado em um GS dedicado, lembre que a falha no evento Crywolf (quando Balgass não é derrotado) é justamente o gatilho para a queda das Loch's Feathers — ingrediente necessário para as Wings de Nível 3 junto com o Jewel of Creation. Isso afeta diretamente a economia do servidor, então a estabilidade do GS que hospeda Crywolf é crítica.

Monitoramento Contínuo da Conexão entre Processos

Após configurar tudo, implemente monitoramento básico para detectar desconexões entre o CS e os GameServers antes que os jogadores percebam:

# Script PowerShell simples para checar se processos estão escutando
# Salvar como check-mu-ports.ps1 e agendar no Task Scheduler

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

foreach ($porta in $portas) {
    $conn = netstat -an | Select-String ":$porta\s+.*LISTENING"
    if (-not $conn) {
        # Porta não está escutando — registrar no log
        Add-Content -Path "C:\MUServer\logs\monitor.log" `
            -Value "$timestamp - ALERTA: porta $porta nao esta LISTENING"
    }
}

Agendar esse script a cada 2 minutos no Task Scheduler do Windows garante um histórico de quando cada processo caiu, o que é essencial para diagnosticar quedas intermitentes que são difíceis de reproduzir manualmente.

Perguntas frequentes