Configurar mtaserver.conf do MTA:SA do zero — guia completo
Aprenda a configurar cada opção do mtaserver.conf no Multi Theft Auto do zero, com explicação técnica de portas, ASE, password, módulos e recursos.
O mtaserver.conf é o arquivo central de configuração de qualquer servidor Multi Theft Auto: San Andreas. Ele define desde detalhes operacionais básicos como porta e número de slots até comportamento de rede, módulos carregados, recursos que sobem no boot e como o servidor se anuncia na master list pública. Editar esse arquivo sem entender cada bloco costuma resultar em servidor que não aparece in-game, lag inexplicável ou crashes no startup.
Este tutorial é pra quem está montando um servidor MTA:SA do zero — seja num VPS Linux, dedicado Windows ou ambiente local — e precisa entender o que cada linha do mtaserver.conf faz, com valores recomendados pra produção. Tempo estimado de execução: 25 a 40 minutos, dependendo de quantos blocos opcionais você ativa.
A premissa é que você já tem o servidor MTA instalado (pacote multitheftauto-server no Linux ou release oficial do mtasa.com no Windows) e consegue iniciar o processo mta-server ao menos uma vez antes de editar a configuração definitiva.
Pré-requisitos
Servidor MTA:SA versão 1.6 ou superior instalado. Acesso ao filesystem do servidor (SSH/SFTP ou RDP). Editor de texto que respeite quebras de linha do XML (vim, nano, VS Code, Notepad++). Três portas UDP liberadas no firewall: a porta do servidor, ASE e HTTP interno.
mods/deathmatch/mtaserver.conf XML 22003/UDP porta+123 22005/TCP O arquivo fica em mods/deathmatch/mtaserver.conf relativo à raiz da instalação. Toda mudança exige restart do processo mta-server pra surtir efeito, com poucas exceções aplicáveis em runtime via console.
Bloco de identidade e visibilidade
Essa seção define como seu servidor aparece pros jogadores na master list e como ele responde a queries externas. São as primeiras tags do XML logo após <config>.
Defina o nome público e a descrição que aparecem na master list:
<servername>Meu Servidor RP BR</servername>
<serverip>auto</serverip>Use auto em serverip quase sempre — o MTA detecta o IP externo via STUN. Só fixe o IP manualmente se o servidor estiver atrás de NAT complexo e você souber qual endereço público anunciar. Nome de servidor é limitado a 96 caracteres; emojis e cor codes (#FF0000) funcionam mas atrapalham busca textual.
Configure as portas de rede:
<serverport>22003</serverport>
<maxplayers>64</maxplayers>
<httpserver>1</httpserver>
<httpport>22005</httpport>serverport é UDP — é por onde o gameplay trafega. maxplayers define quantos slots simultâneos. httpserver=1 ativa o HTTP embutido pra entregar resources pros clientes durante o join; httpport é TCP e geralmente fica em serverport+2.
Ative o anúncio na master list (ASE):
<ase>1</ase>
<allow_gta3_img_mods>none</allow_gta3_img_mods>
<donotbroadcastlan>0</donotbroadcastlan>ase=1 faz seu servidor aparecer no browser in-game. A porta ASE é automaticamente serverport+123 (UDP) — precisa estar aberta no firewall, senão a master list não consegue confirmar que o servidor está vivo e remove ele da lista após alguns minutos.
Servidor MTA exige três portas abertas: a serverport (UDP), a porta ASE = serverport+123 (UDP) e a httpport (TCP). Esquecer ASE é o erro mais comum — o servidor sobe, conecta localmente, mas nunca aparece na lista pública.
Segurança e controle de acesso
Aqui você define password, ACLs, anti-cheat e quem pode administrar via console remoto. É a seção que mais varia entre servidor de produção e servidor de desenvolvimento.
Defina a password (opcional) e o modo de acesso:
<password></password>
<minclientversion>1.6.0-9.22790.0</minclientversion>
<recommendedclientversion></recommendedclientversion>Deixe <password></password> vazio pra servidor público. Pra whitelist privada, coloque uma senha forte (16+ caracteres). minclientversion força o cliente a estar atualizado — útil pra evitar bugs já corrigidos; o formato exato vem do release do MTA que você quer exigir.
Configure o anti-cheat e detecções:
<ac>1,2</ac>
<disableac></disableac>
<enablesd>12,28,32</enablesd>ac ativa categorias de anti-cheat — 1,2 cobre os checks padrão recomendados. enablesd ativa special detections numerados; a lista oficial está na wiki do MTA. Em servidores de desenvolvimento, deixe disableac com os IDs que você precisa desligar pra testar mods.
Configure o acesso remoto via web admin:
<httpdosthreshold>20</httpdosthreshold>
<verifyclientsettings>-1</verifyclientsettings>
<bandwidthreductionmode>medium</bandwidthreductionmode>httpdosthreshold limita requisições por segundo no HTTP interno pra mitigar flood. bandwidthreductionmode pode ser none, medium ou maximum — em servidor com muitos jogadores, medium é o sweet spot entre consumo de banda e responsividade.
A senha em mtaserver.conf é só pra entrar no servidor. Quem pode rodar comandos administrativos vem do mods/deathmatch/acl.xml. Nunca deixe o grupo Admin com a senha default serveradmin — qualquer um na internet sabe que existe e tenta brute force diariamente.
Performance e logs
Esta seção controla quanto recurso o servidor consome e como ele registra atividade. Valores ruins aqui causam lag percebido mesmo com hardware sobrando.
Defina os limites de tickrate e voice:
<voice>0</voice>
<voice_samplerate>1</voice_samplerate>
<voice_quality>4</voice_quality>
<fpslimit>36</fpslimit>fpslimit é o tickrate do servidor — 36 é o padrão e funciona pra maioria. Aumentar pra 60 ou 100 melhora precisão de sincronização em deathmatch competitivo, mas dobra/triplica o uso de CPU. voice=0 desativa chat de voz; ative só se o gameplay depender disso.
Configure os arquivos de log:
<logfile>logs/server.log</logfile>
<authserialloglevel>2</authserialloglevel>
<authserialgroups>Admin,Moderator</authserialgroups>
<loadfailurelogfile>logs/load_errors.log</loadfailurelogfile>
<scriptdebugloglevel>0</scriptdebugloglevel>
<htmllogfile>logs/server.html</htmllogfile>
<acllogfile>logs/acl.log</acllogfile>Logs separados ajudam debug. scriptdebugloglevel=0 desliga log verbose de scripts Lua — ative 2 ou 3 só em desenvolvimento porque enche disco rápido. authserialloglevel=2 registra autenticações dos grupos privilegiados; útil pra auditoria.
Defina diretórios e crash dumps:
<crashdumpfile>logs/crashdump.log</crashdumpfile>
<filterduplicatelogfilelines>1</filterduplicatelogfilelines>
<backup_path>backups</backup_path>
<backup_interval>3</backup_interval>
<backup_copies>10</backup_copies>backup_interval=3 faz backup do mods/deathmatch/ a cada 3 dias mantendo 10 cópias. Em servidor de produção, considere apontar backup_path pra um volume separado ou rodar rsync externo — backup no mesmo disco do servidor não protege contra falha física.
Módulos e recursos iniciais
A última seção do XML define o que carrega no boot: módulos C++ (extensões binárias) e os resources Lua que viram o gameplay.
Liste módulos binários que devem carregar:
<module src="mta_mysql.dll" />
<module src="ml_sockets.dll" />Substitua .dll por .so no Linux. Módulos comuns: mta_mysql pra conexão MySQL nativa (mais rápida que dbConnect puro), ml_sockets pra TCP/UDP raw, ml_base64. Cada módulo precisa estar em mods/deathmatch/modules/ pra ser encontrado.
Defina quais resources sobem automaticamente:
<resource src="admin" startup="1" protected="0" />
<resource src="webadmin" startup="1" protected="0" />
<resource src="resourcemanager" startup="1" protected="0" />
<resource src="mapmanager" startup="1" protected="0" />
<resource src="meu-gamemode" startup="1" protected="0" />startup="1" carrega no boot do servidor. protected="1" impede que comandos in-game parem o resource — use em resources críticos (admin, ACL). A ordem importa: dependências devem ser declaradas antes dos resources que dependem delas.
Se o servidor tem 100+ slots, configure httpdownloadurl apontando pra um nginx/CDN externo que espelha o diretório mods/deathmatch/resources/. Os clientes baixam de lá em vez de saturar o HTTP interno do MTA — reduz CPU do processo e melhora velocidade de join. O mirror precisa ser atualizado a cada deploy de resource novo.
Verificação
Depois de salvar o mtaserver.conf, valide a configuração antes de abrir pro público. Inicie o servidor em foreground pra ver os logs:
cd /opt/mta-server
./mta-server
No Windows, rode MTA Server.exe direto pelo terminal pra ver o output. Procure por estas linhas no startup:
[INFO] Server started and is ready to accept connections!
[INFO] Listening on 0.0.0.0:22003 (UDP)
[INFO] HTTP server started on port 22005
[INFO] Querying master server...
[INFO] Master server registration successful
Se a última linha aparecer como failed ou timed out, é firewall na porta ASE. Teste do lado de fora usando nc -u -z SEU_IP 22126 (se serverport=22003, ASE=22126). Após sucesso, conecte do MTA cliente em seu-ip:22003 e confirme que o servidor aparece na master list em até 5 minutos.
Resolução de problemas
Servidor sobe mas não aparece na lista
A causa mais comum é firewall bloqueando a porta ASE (UDP serverport+123). A master list envia query nessa porta a cada poucos minutos pra confirmar que o servidor está vivo. Sem resposta, ele é removido da lista. Verifique ufw status no Linux ou Windows Firewall, e também o firewall do provedor de hospedagem — em VPS, ambas as camadas precisam liberar a porta.
”Could not load module” no startup
O caminho do módulo no <module src="..." /> é relativo a mods/deathmatch/modules/. Confirme que o arquivo existe lá e que a extensão bate com o SO (.dll Windows, .so Linux). Módulos compilados pra versão antiga do MTA não carregam em 1.6+ — sempre baixe a build correspondente à versão exata do seu servidor.
Resource não inicia mesmo com startup=“1”
Cheque logs/load_errors.log — o motivo costuma estar lá. Erros comuns: dependência declarada em meta.xml que não existe, arquivo Lua com syntax error que impede o parse, ACL bloqueando ações do resource. Rode refresh no console do servidor depois de corrigir.
Próximos passos
Com o mtaserver.conf configurado, o próximo passo natural é ajustar acl.xml pra criar grupos administrativos com permissões granulares — nunca use a senha default serveradmin. Depois, configure backups externos via rsync ou volume separado, e considere espelhar resources num CDN se planeja escalar pra 100+ slots.
Pra deploy em produção, vale dimensionar a infraestrutura pelo tickrate desejado: 36fps cabe folgado num VPS de 2 vCPU, enquanto 100fps em deathmatch competitivo pede 4+ vCPU dedicadas. Se você está colocando um servidor MTA:SA no ar, o plano de hospedagem de jogos da Hostini já vem com proteção DDoS na borda e IPs brasileiros com baixa latência pro Sudeste, que é onde está a maioria dos jogadores de MTA no Brasil.
Por fim, monitore métricas de longo prazo: uso de CPU por tickrate, tráfego de saída por jogador conectado e tamanho dos logs. Servidor MTA bem configurado consome surpreendentemente pouco — se o consumo está alto, quase sempre é um resource Lua mal escrito, não o mtaserver.conf.
Perguntas frequentes
Posso rodar dois servidores MTA na mesma máquina?
Sim. Cada instância precisa de uma cópia separada do diretório do servidor e portas distintas em serverport, httpport e ase. Lembre de mudar também o servername pra diferenciar na master list e abrir as 3 portas no firewall pra cada instância.
Qual a diferença entre httpserver e httpdownloadurl?
httpserver=1 sobe um HTTP interno do MTA na porta httpport pra entregar resources pros clientes. Se você setar httpdownloadurl com um CDN/nginx externo, o cliente baixa de lá em vez do servidor — reduz CPU e banda do processo MTA, mas exige manter o mirror sincronizado.
Por que meu servidor não aparece na lista in-game mesmo com ase=1?
Quase sempre é firewall na porta ASE (serverport+123 por padrão, UDP). A master list precisa receber resposta nessa porta pra listar você. Verifique iptables/ufw e, em VPS, o firewall do painel do provedor — ambos precisam permitir a porta UDP do ASE.
Devo deixar voice=1 em produção?
Só se for parte do gameplay. Voice consome banda razoável (cerca de 8 kbps por jogador falando) e adiciona CPU pra mixagem. Em servidores grandes (200+ slots) sem mecânica de voz, deixe voice=0 pra economizar recursos.
O que acontece se eu não definir uma password no mtaserver.conf?
O servidor fica público — qualquer um na master list pode entrar. Pra servidor de desenvolvimento ou whitelist, defina uma password forte. Em servidor público de produção, mantenha vazio mas configure ACL e anti-cheat (ac) corretamente pra mitigar abuso.
Posso editar o mtaserver.conf com o servidor rodando?
Pode editar, mas a maioria das opções só recarrega no próximo restart. Mudanças em maxplayers, password e algumas ACL podem ser aplicadas via comandos do console sem restart. Pra mudanças em portas, módulos ou httpserver, restart é obrigatório.