Mastodon ‘Internal Server Error’ ao Publicar: Etapas de Diagnóstico

Ao tentar publicar uma postagem no Mastodon e ver uma mensagem de “Erro Interno do Servidor”, a postagem geralmente falha. Esse erro significa que o servidor Mastodon encontrou um problema que não conseguiu tratar, não um erro no seu conteúdo ou conexão. A causa é quase sempre do lado do servidor, como um timeout do banco de dados, um limite de taxa mal configurado ou uma falta temporária de recursos. Este artigo explica os motivos técnicos por trás do erro e fornece um processo de diagnóstico passo a passo para identificar e resolver o problema.

Por que o Mastodon Retorna um Erro Interno do Servidor ao Publicar

Um erro HTTP 500 (Erro Interno do Servidor) é uma resposta genérica que indica que o servidor não pode atender à solicitação devido a uma condição inesperada. Quando isso acontece especificamente durante a postagem, o problema está em um dos vários componentes do lado do servidor:

Falha na Conexão com o Banco de Dados

O Mastodon usa PostgreSQL para armazenar todas as postagens, contas e relacionamentos. Quando o servidor de banco de dados está sobrecarregado, inacessível ou atingiu seu limite de conexões, o aplicativo Mastodon não consegue gravar a nova postagem no banco de dados. Isso aciona uma exceção não tratada que se manifesta como um erro 500.

Acúmulo na Fila de Trabalhos do Sidekiq

Após clicar em Publicar, o Mastodon não processa a postagem imediatamente. Ele entrega a tarefa ao Sidekiq, um processador de trabalhos em segundo plano. Se os workers do Sidekiq estiverem travados, quebrados ou sobrecarregados por uma fila de trabalhos pendentes, a postagem nunca é processada. O processo web atinge o tempo limite e retorna um erro 500.

Configuração Incorreta de Limite de Taxa

O Mastodon impõe limites de taxa na postagem para evitar spam. Se a configuração do limite de taxa for muito restritiva ou se o próprio limitador de taxa falhar, postagens legítimas podem ser rejeitadas. Um proxy reverso mal configurado, como Nginx, também pode retornar um erro 502 Bad Gateway, que alguns clientes interpretam como um erro interno.

Disco Cheio

O Mastodon armazena anexos de mídia e arquivos temporários em disco. Quando o disco está cheio, o aplicativo não consegue gravar novos arquivos ou atualizar registros do banco de dados. Essa condição geralmente produz um erro 500 durante qualquer operação de escrita, incluindo postagens.

Etapas de Diagnóstico para Encontrar a Causa Raiz de um Erro de Postagem no Mastodon

Siga estas etapas em ordem. Pare quando encontrar o erro específico. Não pule etapas a menos que tenha certeza de que o componente está saudável.

1. Verifique o log de produção do Mastodon
   Acesse seu servidor via SSH e execute: tail -f /home/mastodon/live/log/production.log. Reproduza o erro postando novamente. Procure linhas contendo RuntimeError, ActiveRecord::ConnectionTimeoutError ou PG::Error. Essas linhas identificam o componente com falha.
2. Verifique se o Sidekiq está em execução
   Execute systemctl status mastodon-sidekiq ou ps aux | grep sidekiq. Se o Sidekiq não estiver em execução, inicie-o com systemctl start mastodon-sidekiq. Um Sidekiq parado significa que os trabalhos em segundo plano nunca são executados, fazendo com que a postagem falhe.
3. Verifique a conectividade com o banco de dados
   No diretório do Mastodon, execute RAILS_ENV=production bin/tootctl db:check. Este comando testa a conexão com o banco de dados. Se falhar, verifique o status do PostgreSQL com systemctl status postgresql e confira as credenciais do banco de dados no arquivo .env.production.
4. Inspecione o uso do disco
   Execute df -h e procure partições com 100% de uso. Se a partição que contém /home/mastodon estiver cheia, libere espaço removendo o cache de mídia antigo: RAILS_ENV=production bin/tootctl media remove. Em seguida, reinicie o processo web do Mastodon: systemctl restart mastodon-web.
5. Revise os logs de erro do Nginx
   Se você usa Nginx como proxy reverso, verifique /var/log/nginx/error.log em busca de erros 502 ou 504. Eles indicam que o processo web do Mastodon atingiu o tempo limite ou travou. Aumente os valores de timeout do proxy na configuração do Nginx: proxy_read_timeout 120s; e proxy_send_timeout 120s;.
6. Reinicie todos os serviços do Mastodon
   Execute systemctl restart mastodon-web mastodon-sidekiq mastodon-streaming. Isso limpa o estado temporário e redefine conexões obsoletas. Após reiniciar, tente postar novamente. Se o erro desaparecer, a causa foi um problema transitório de recursos.
7. Monitore o uso de recursos durante a postagem
   Use htop ou top enquanto tenta postar. Procure picos de CPU ou memória que façam o processo web ser morto pelo OOM killer. Se o processo web do Mastodon desaparecer após um pico, aumente a memória do sistema ou reduza o número de workers do Sidekiq em .env.production.

Se o Erro Interno do Servidor Persistir Após o Diagnóstico Básico

A Postagem Falha Apenas com Anexos de Mídia

Se postagens apenas com texto forem bem-sucedidas, mas postagens com imagens ou vídeos falharem, o problema provavelmente é o processamento de mídia. Verifique se ffmpeg e libvips estão instalados e atualizados. Execute which ffmpeg e ffmpeg -version. Se estiverem faltando, instale-os com seu gerenciador de pacotes. Verifique também se o diretório mastodon-media tem as permissões corretas: chown -R mastodon:mastodon /home/mastodon/live/public/system.

O Erro Ocorre Apenas para uma Conta ou Conteúdo Específico

Se apenas uma conta acionar o erro, ela pode ter dados corrompidos. Use o painel de administração do Mastodon para revisar a conta e considere suspendê-la e recriá-la. Se o erro acontecer com caracteres específicos, como emojis ou scripts não latinos, a codificação do banco de dados pode estar incompleta. Certifique-se de que o banco de dados PostgreSQL use codificação UTF-8: SHOW server_encoding;.

O Erro Aparece Intermitentemente

Erros 500 intermitentes geralmente apontam para esgotamento de recursos sob carga. Verifique o número de usuários simultâneos em sua instância. Se a instância estiver sobrecarregada, considere adicionar mais workers do Sidekiq ou atualizar o hardware do servidor. Você também pode ativar o registro de requisições no Nginx para correlacionar os timestamps dos erros com picos de tráfego.

Erro Interno do Servidor no Mastodon vs. Códigos de Status HTTP Relacionados

Item	500 Erro Interno do Servidor	502 Bad Gateway
Significado	O aplicativo Mastodon falhou ao processar a requisição	O proxy reverso (Nginx) não conseguiu alcançar o processo web do Mastodon
Causa típica	Timeout do banco de dados, falha do Sidekiq, disco cheio	Processo web do Mastodon parado ou porta inacessível
Onde diagnosticar	Logs production.log do Mastodon e logs do Sidekiq	Nginx error.log e systemctl status mastodon-web
Abordagem de correção	Reiniciar serviços, liberar disco, corrigir conexão com banco	Reiniciar processo web, verificar binding de porta no .env.production

Esses dois erros geralmente aparecem juntos. Um 502 no navegador pode ser registrado como um 500 no log do aplicativo. Sempre verifique tanto os logs do proxy reverso quanto os logs do aplicativo Mastodon para obter uma visão completa.

Agora você pode identificar sistematicamente por que o Mastodon retorna um Erro Interno do Servidor ao publicar. Comece com o log de produção, depois verifique o Sidekiq, o banco de dados e o espaço em disco. Se o erro persistir, isole se ele está relacionado a mídia, a uma conta específica ou à carga de tráfego. Para monitoramento contínuo, configure rotação de logs e alertas no arquivo production.log usando uma ferramenta como logwatch ou um cron job simples que procure por “500” a cada cinco minutos.