Erro 503 ‘Service Unavailable’ no Mastodon ao se Cadastrar: Causas

O Mastodon retorna um erro 503 Service Unavailable quando você tenta criar uma nova conta e o servidor não consegue processar a solicitação de registro. Esse erro significa que o servidor web da instância está ativo, mas não consegue concluir o fluxo de cadastro devido a um problema no backend. As causas mais comuns incluem um pool de conexões do banco de dados cheio, uma fila de jobs em segundo plano travada e um mecanismo de limitação de taxa que bloqueia novos registros temporariamente. Este artigo explica as causas técnicas por trás do erro 503 durante o cadastro e fornece as etapas para diagnosticar e resolver cada cenário.

Por que o Mastodon Retorna um Erro 503 ao Tentar se Registrar

O Mastodon usa uma arquitetura multiprocesso que combina um servidor web como Puma, um processador de jobs em segundo plano chamado Sidekiq e um banco de dados PostgreSQL. Quando você envia um formulário de registro, o servidor web recebe a solicitação, valida os dados e enfileira um job em segundo plano para enviar um e-mail de confirmação. O servidor web retorna imediatamente uma resposta ao navegador enquanto o Sidekiq processa o job de e-mail de forma assíncrona. Se algum componente dessa cadeia estiver sobrecarregado ou mal configurado, o servidor web não consegue concluir a solicitação e responde com um status 503 Service Unavailable.

O erro 503 indica especificamente que o servidor está temporariamente incapaz de lidar com a solicitação. Diferente de um erro 500 Internal Server Error, que sugere um bug no código, o 503 geralmente aponta para esgotamento de recursos ou um limite de configuração. Os três gatilhos mais frequentes durante o cadastro são uma fila do Sidekiq travada, um pool de conexões do banco de dados cheio e regras de limitação de taxa que bloqueiam o endpoint de registro.

Fila do Sidekiq Travada

O Sidekiq processa jobs de uma fila baseada em Redis. Se o processo do Sidekiq parou, travou ou está com pouca memória, o job de e-mail de confirmação permanece na fila indefinidamente. O servidor web pode atingir o tempo limite aguardando uma confirmação do job e retornar 503. Esse cenário é comum em instâncias menores onde os administradores executam o Sidekiq com memória limitada ou sem um supervisor de processo como systemd.

Esgotamento do Pool de Conexões do Banco de Dados

O servidor web Puma do Mastodon mantém um pool de conexões com o banco de dados. O tamanho padrão do pool é de 5 conexões por worker do Puma. Se muitos usuários acessarem a instância simultaneamente, o pool pode se esgotar. Quando uma solicitação de registro chega, o servidor web não consegue adquirir uma conexão com o banco para inserir o novo registro de usuário e responde com um erro 503.

Limitação de Taxa pelo Rack::Attack

O Mastodon inclui o middleware Rack::Attack para limitar tráfego abusivo. Por padrão, ele limita tentativas de cadastro a 5 solicitações por minuto por endereço IP. Quando você excede esse limite, o Rack::Attack retorna um erro 503 em vez do status padrão 429 Too Many Requests. Esse comportamento é intencional para evitar que bots de registro automatizados sobrecarreguem a instância.

Como Diagnosticar e Corrigir o Erro 503 Durante o Cadastro

As etapas a seguir pressupõem que você tenha acesso administrativo à instância do Mastodon. Se você é um usuário comum tentando se cadastrar, entre em contato com o administrador da instância e compartilhe as etapas abaixo para que ele execute os comandos de diagnóstico.

1. Verifique se o Sidekiq está em execução
   Acesse o servidor via SSH e execute systemctl status mastodon-sidekiq. Se o processo estiver inativo ou falhou, inicie-o com systemctl start mastodon-sidekiq. Ative-o para iniciar na inicialização com systemctl enable mastodon-sidekiq.
2. Inspecione a fila do Sidekiq em busca de jobs travados
   Execute cd /home/mastodon/live && RAILS_ENV=production bin/tootctl sidekiq stats. Observe os contadores “processed” e “failed”. Se o tamanho da fila estiver crescendo ou os jobs não estiverem sendo processados, reinicie o Sidekiq com systemctl restart mastodon-sidekiq.
3. Monitore o uso de conexões do banco de dados
   Execute sudo -u mastodon psql -d mastodon_production -c "SELECT count(*) FROM pg_stat_activity WHERE state = 'active';". Se a contagem estiver próxima ao tamanho do pool definido em config/database.yml, aumente o valor do pool. Por exemplo, altere pool: 5 para pool: 10 e reinicie o Puma com systemctl restart mastodon-web.
4. Revise os logs do Rack::Attack
   Verifique o arquivo de log do Mastodon em /home/mastodon/live/log/production.log em busca de linhas contendo “Rack::Attack”. Se você encontrar entradas como “Rack::Attack: throttled POST /auth” para seu endereço IP, o limitador de taxa está bloqueando seu registro. Aguarde um minuto e tente novamente, ou peça ao administrador para aumentar o limite em config/initializers/rack_attack.rb.
5. Verifique a conectividade com o Redis
   Execute redis-cli ping. Se a resposta não for “PONG”, reinicie o Redis com systemctl restart redis-server. O Sidekiq não funciona sem uma conexão Redis ativa.

Se o Mastodon Ainda Mostrar o Erro 503 Após a Correção Principal

Registro Desativado na Instância

O administrador da instância pode ter desativado o registro de novos usuários no painel de administração. Navegue até Preferências > Administração > Configurações do Servidor > Registros e certifique-se de que “Registro aberto” esteja marcado. Se estiver desmarcado, o servidor retornará um erro 503 para todas as tentativas de cadastro.

Tempo Limite do Worker do Puma

Se o tempo limite do worker do Puma for muito baixo, uma solicitação de registro que acione uma consulta lenta ao banco de dados pode ser encerrada antes de ser concluída. Verifique o arquivo config/puma.rb para a configuração worker_timeout. O padrão é 60 segundos. Aumente para 120 segundos se você observar timeouts frequentes durante horários de pico.

Espaço em Disco do Sistema de Arquivos Cheio

O Mastodon grava arquivos de log e arquivos temporários no disco. Se o disco estiver cheio, o servidor web não consegue gravar no log e retorna 503. Execute df -h para verificar o uso do disco. Se alguma partição estiver acima de 90% de uso, libere espaço rotacionando logs com logrotate -f /etc/logrotate.d/mastodon ou excluindo arquivos de mídia antigos com bin/tootctl media remove.

Erro 503 no Mastodon vs Outros Códigos de Status HTTP Durante o Cadastro

Item	503 Service Unavailable	429 Too Many Requests	500 Internal Server Error
Descrição	Servidor temporariamente não consegue lidar com a solicitação devido a sobrecarga ou manutenção	Cliente enviou muitas solicitações em um determinado período	Servidor encontrou uma condição inesperada que impediu o atendimento da solicitação
Causa típica	Fila do Sidekiq travada, pool do banco cheio, limitação de taxa	Limite de throttling do Rack::Attack excedido	Bug no código da aplicação, gems faltando ou configuração corrompida
Aparece durante o cadastro	Sim	Sim, mas o Mastodon pode retornar 503 em vez de 429	Raramente durante o cadastro, mais comum em outros endpoints
Resolução	Reiniciar o Sidekiq, aumentar o pool do banco, aguardar reset do limite de taxa	Aguardar um minuto e tentar novamente, ou aumentar o limite de throttling	Verificar logs da aplicação e corrigir o erro subjacente de código ou configuração

Depois de resolver o erro 503, você pode concluir com sucesso o processo de registro no Mastodon. Comece reiniciando o serviço Sidekiq, pois uma fila de jobs travada é a causa mais frequente. Se o erro persistir, aumente o tamanho do pool de conexões PostgreSQL em config/database.yml e verifique se o espaço em disco não está esgotado. Para administradores que desejam prevenir futuros erros 503, configure monitoramento com uma ferramenta como Prometheus para alertar sobre a profundidade da fila do Sidekiq e o uso de conexões do banco antes que atinjam níveis críticos.