Servidor de Tibia fecha sozinho? Principais causas e como resolver

Servidor que fica lento é irritante. Servidor que fecha sozinho é outra categoria de problema: o jogador perde o que estava fazendo, a hunt vai por água abaixo, e se acontecer duas ou três vezes na mesma semana ele simplesmente para de voltar.

E o pior é o diagnóstico. Servidor que cai não deixa a tela aberta para você investigar. Ele fecha, e você chega depois, olhando para uma janela que não existe mais.

A boa notícia é que ele quase sempre avisa antes de morrer. Está tudo no log. O problema é que a maioria dos donos de OTServ nunca aprendeu a ler aquele arquivo, e por isso trata queda como mistério.

Este artigo mostra como usar os logs para achar a causa, cobre as onze causas mais comuns com a assinatura de cada uma, e fecha com um checklist que você pode seguir na ordem quando o servidor cair de novo.

Primeiro: capture a evidência

Não adianta nada diagnosticar sem log. E servidor iniciado com dois cliques no executável perde tudo quando a janela fecha.

Redirecione a saída para arquivo

No Windows, em vez de abrir o executável direto, crie um .bat que grava tudo:

@echo off
theforgottenserver.exe > logs\console.log 2>&1

No Linux, o equivalente:

./tfs > logs/console.log 2>&1

Agora, quando o servidor cair, a última coisa que ele disse fica gravada.

Habilite os logs da própria distribuição

No config.lua, procure as opções de log. A maioria das distribuições permite registrar erro de script separadamente do console geral. Ative.

Guarde o histórico

Não deixe o log ser sobrescrito a cada reinício. Um arquivo por dia é o suficiente e permite comparar comportamento.

Anote o horário

Isso parece bobo e é decisivo. Quando o servidor cair, anote a hora exata. Metade dos diagnósticos deste artigo se resolve cruzando o horário da queda com o que estava acontecendo.

Como ler o log de um servidor que caiu

Abra o arquivo e vá para o final. É lá que está a informação, não no começo.

O que procurar, em ordem

1. As últimas linhas antes do corte. O que o servidor estava fazendo no instante em que parou? Se a última linha é o carregamento de um script, você já tem um suspeito.

2. Repetição. Se a mesma mensagem aparece dezenas ou centenas de vezes antes da queda, é loop. Loop consome recurso até acabar.

3. Palavras que denunciam. Procure por error, failed, cannot, exception, bad allocation, segmentation fault, lost connection.

4. O que muda entre uma queda e outra. Compare o log de duas quedas diferentes. Se as últimas linhas são iguais, você achou o gatilho. Se são completamente diferentes, o problema é de ambiente, não de conteúdo.

Traduzindo as mensagens mais comuns

Esse último caso merece atenção: log que termina no meio de uma linha normal, sem erro nenhum, quase sempre significa que o sistema operacional matou o processo. E o sistema faz isso, na prática, por um motivo só: memória.

As causas, uma a uma

1. Falta de memória

Assinatura: o log corta sem erro, ou termina com bad allocation. A queda costuma acontecer depois de horas no ar, ou no horário de maior movimento.

É a causa número um de queda em OTServ, e a explicação é a natureza do jogo: o mapa fica carregado inteiro na memória. Adicione mapa customizado grande, o MySQL usando memória como cache e o site da comunidade rodando junto, e a conta estoura.

Como confirmar: monitore a memória ao longo do dia. Se ela sobe e nunca desce, e a queda acontece quando ela se aproxima do teto, está confirmado.

No Linux, verifique se o sistema matou o processo:

sudo dmesg | grep -i "killed process"

Se aparecer o nome do seu servidor ali, é falta de memória, sem discussão.

Solução: identifique se o consumo cresce indefinidamente, o que indica vazamento em script, ou se ele estabiliza acima do que o plano oferece, o que indica dimensionamento insuficiente.

2. CPU no limite

Assinatura: queda durante eventos, invasões ou guerras, sempre em momento de pico.

Processador saturado geralmente causa travamento, não queda. Mas quando a saturação é longa o suficiente, sistemas de vigilância derrubam o processo por falta de resposta.

Como confirmar: cruze o horário da queda com o pico de uso. Se o servidor morre sempre em evento e nunca em horário calmo, é isso.

Solução: o gargalo real é quase sempre um script de evento mal otimizado, não a máquina. Investigue o script antes.

3. Scripts com erro em ponto crítico

Assinatura: queda reproduzível, ligada a uma ação específica. Alguém usa um item, entra numa área, abre uma janela, e o servidor morre.

Nem todo erro de Lua derruba servidor. A maioria só registra e segue. Mas erro dentro de um evento de sistema, ou script que entra em recursão infinita, derruba.

Como confirmar: este é o caso mais fácil de todos, porque é reproduzível. Reproduza numa cópia de teste e observe o log.

Solução: corrija ou desative o script. Se veio de terceiro e você não entende, remova primeiro e conserte depois. Servidor no ar vale mais que funcionalidade.

4. Mods e datapack incompatíveis

Assinatura: cascata de erros de script logo ao subir, ou queda logo nos primeiros minutos, geralmente depois de você ter instalado algo novo.

Datapack precisa ser da mesma versão da distribuição. Datapack de TFS 1.2 rodando em TFS 1.5 vai chamar funções que mudaram de nome ou deixaram de existir.

Como confirmar: o log ao subir vai estar cheio de erro mencionando função desconhecida. E a pergunta decisiva: o que mudou desde a última vez que funcionou?

Solução: não tem conserto por remendo. Use o datapack correto para a sua versão. Se o mod é essencial, procure a versão dele compatível.

5. Banco de dados indisponível

Assinatura: MySQL server has gone away ou erro de conexão no log. Muitas vezes o servidor de jogo cai junto com o banco.

O MySQL pode cair por conta própria, geralmente por falta de memória, ou fechar conexões ociosas por tempo limite.

Como confirmar: olhe o log do próprio MySQL. Se ele registra reinício no mesmo horário, o banco caiu primeiro e levou o jogo junto.

Solução: se o banco cai por memória, você tem um problema de dimensionamento com dois consumidores brigando pela mesma máquina. Se é tempo limite de conexão, ajuste o wait_timeout.

6. Corrupção de dados

Assinatura: queda sempre no mesmo ponto, envolvendo o mesmo personagem, a mesma casa ou a mesma área do mapa.

Corrupção acontece principalmente depois de queda mal resolvida ou desligamento abrupto. Uma tabela do banco fica inconsistente, ou o arquivo de mapa fica com setor danificado.

Como confirmar: se a queda envolve sempre o mesmo elemento, teste isolando. Verifique as tabelas do banco:

CHECK TABLE players;
REPAIR TABLE players;

Solução: restaure de backup. E aqui vale o lembrete que ninguém quer ouvir depois: backup guardado na mesma máquina não é backup.

7. Máquina inadequada

Assinatura: quedas frequentes sem padrão identificável, com todo o resto já descartado.

Este é o último da fila de suspeitos, não o primeiro. Mas existe: máquina com memória insuficiente para o projeto, disco lento causando tempo esgotado em operação de escrita, ou ambiente muito compartilhado onde o desempenho oscila por causa dos vizinhos.

Como confirmar: você já eliminou memória vazando, script quebrado, datapack incompatível e banco caindo, e as quedas continuam sem padrão.

8. Firewall e portas

Assinatura: o servidor não caiu, mas ninguém consegue entrar. Do lado de fora, parece a mesma coisa.

Vale separar isso do resto, porque muita gente reporta "servidor caiu" quando o processo está de pé e saudável.

Se o console está rodando normalmente e mesmo assim ninguém conecta, o problema é rede: porta fechada no firewall do sistema, no firewall do provedor, ou IP errado no config.lua.

Como confirmar: o processo está rodando? Se sim, não é queda.

Solução: as duas portas do OTServ precisam estar abertas, a 7171 para login e a 7172 para o jogo. O passo a passo está em como abrir uma porta na sua VPS e, no Linux, em como ativar o firewall e liberar portas.

9. Ataque DDoS

Assinatura: inacessibilidade súbita, com o processo do servidor rodando normalmente e uso de processador baixo.

A assinatura que distingue ataque de sobrecarga é essa: a máquina não está trabalhando mais, mas está inalcançável.

Como confirmar: olhe o tráfego de entrada. Salto brusco sem aumento correspondente de jogadores é o indicador.

Solução: mitigação precisa acontecer na rede, antes de chegar na sua máquina. A diferença entre proteção real e simples descarte de tráfego está em como proteger o servidor de Tibia contra DDoS.

10. Atualização mal feita

Assinatura: funcionava ontem, não funciona hoje, e alguma coisa foi atualizada no meio.

Pode ser a distribuição, o datapack, o MySQL ou o próprio sistema operacional. Atualização de MySQL com mudança de comportamento padrão é uma armadilha clássica.

Como confirmar: a pergunta de sempre. O que mudou?

Solução: teste atualização em ambiente separado antes de aplicar em produção. E tenha como voltar atrás.

11. Falta de debug adequado

Este não é causa de queda, é causa de você não conseguir resolver as outras dez.

Sem log gravado em arquivo, sem histórico e sem anotar horário, todo diagnóstico vira tentativa e erro.

Se você chegou até aqui e não tem nenhum log, comece por aí. Configure a captura, espere a próxima queda e volte para este artigo com dados na mão.

Checklist de diagnóstico

Siga na ordem quando o servidor cair. Cada passo elimina um grupo de causas.

Passo 1: o processo está rodando? Se estiver, não é queda, é rede. Vá para firewall e portas.

Passo 2: o que dizem as últimas linhas do log? Erro explícito aponta o culpado. Corte sem erro sugere falta de memória.

Passo 3: o que mudou desde a última vez que funcionou? Script novo, mod, atualização, mudança no config.lua. Se algo mudou, comece por aí.

Passo 4: é reproduzível? Se você consegue derrubar de propósito, é script ou dado corrompido. Isole numa cópia de teste.

Passo 5: existe padrão de horário? Sempre em pico sugere recurso. Sempre na madrugada sugere tarefa agendada ou backup. Sempre depois de X horas no ar sugere vazamento de memória.

Passo 6: a memória estava no limite? Verifique o histórico. No Linux, cheque se o sistema matou o processo.

Passo 7: o banco estava de pé? Confira o log do MySQL no mesmo horário.

Passo 8: o tráfego de entrada estava anormal? Se sim, e o processador estava tranquilo, foi ataque.

Passo 9: nada explicou? Aí sim, avalie a máquina.

Perguntas frequentes

Meu servidor fecha sem nenhuma mensagem. Por onde começo?

Log que corta sem erro é, na maioria esmagadora das vezes, falta de memória. O sistema mata o processo antes que ele consiga registrar qualquer coisa.

Como sei se é vazamento de memória ou plano pequeno?

Pelo formato da curva. Vazamento sobe continuamente e nunca estabiliza. Plano pequeno estabiliza num patamar alto e derruba nos picos.

Preciso reiniciar o servidor todo dia?

Não deveria. Se precisa, existe um vazamento não resolvido. O reinício programado é gestão de sintoma, útil enquanto você investiga, mas não é conserto.

Um script ruim pode derrubar o servidor inteiro?

Pode, e é comum. Erro dentro de evento de sistema, recursão infinita ou loop que consome memória derrubam o processo.

Vale trocar de VPS se o servidor cai muito?

Só depois de descartar script, datapack incompatível, banco e vazamento de memória. Trocar de máquina com o problema não resolvido leva o problema junto.

Como evito perder dados quando o servidor cai?

Backup automático e frequente do banco de dados, guardado fora da máquina do servidor. É a única resposta que funciona.

Quando realmente vale migrar de VPS

Depois de tudo isso, existe o cenário legítimo. Vale trocar de máquina quando as três condições abaixo forem verdadeiras ao mesmo tempo:

Você já eliminou as causas de software. Scripts revisados, datapack compatível, banco com manutenção, sem vazamento de memória identificado.

O consumo estabiliza acima do que o plano oferece. A memória não vaza, ela simplesmente precisa de mais espaço do que existe. Ou o processador vive no limite mesmo em operação normal.

O ambiente oscila sem relação com a sua carga. Se o desempenho varia em horários que não têm nada a ver com a quantidade de jogadores, o problema está embaixo de você.

Nesse ponto, três características fazem diferença real para OTServ: clock alto por núcleo, porque a lógica do jogo é concentrada e responde à frequência mais que à quantidade de núcleos. SSD NVMe, porque save do mundo e consulta ao banco são picos de escrita que disco lento transforma em tempo esgotado. E proteção DDoS na rede, porque servidor de jogo é alvo constante e mitigação feita dentro da própria máquina chega tarde demais.

É essa a configuração dos planos de host de Tibia da WyzeHost: AMD Ryzen 9, SSD NVMe, proteção DDoS inclusa e máquinas no Brasil, com upgrade sem perda de arquivo caso o servidor cresça.

Para dimensionar sem exagerar, o detalhamento por cenário está em como escolher a VPS para o seu servidor de Tibia. E se o seu problema é lentidão e não queda, o diagnóstico específico está em como reduzir o lag em servidores de Tibia.