Error ‘internal server error’ de Mastodon al publicar: pasos de diagnóstico

Cuando intentas publicar una publicación en Mastodon y ves un mensaje “Internal Server Error”, la publicación generalmente no se envía. Este error significa que el servidor de Mastodon encontró un problema que no pudo manejar, no un error en tu contenido o conexión. La causa casi siempre está del lado del servidor, como un tiempo de espera de la base de datos, un límite de velocidad mal configurado o una escasez temporal de recursos. Este artículo explica las razones técnicas detrás del error y proporciona un proceso de diagnóstico paso a paso para identificar y resolver el problema.

Por qué Mastodon devuelve un error interno del servidor al publicar

Un error HTTP 500 Internal Server Error es una respuesta genérica que indica que el servidor no puede cumplir la solicitud debido a una condición inesperada. Cuando esto ocurre específicamente durante la publicación, el problema radica en uno de varios componentes del servidor:

Fallo de conexión a la base de datos

Mastodon usa PostgreSQL para almacenar todas las publicaciones, cuentas y relaciones. Cuando el servidor de base de datos está sobrecargado, es inaccesible o ha alcanzado su límite de conexiones, la aplicación Mastodon no puede escribir la nueva publicación en la base de datos. Esto desencadena una excepción no controlada que se manifiesta como un error 500.

Acumulación en la cola de trabajadores de Sidekiq

Después de hacer clic en Publicar, Mastodon no procesa la publicación de inmediato. Delega la tarea a Sidekiq, un procesador de trabajos en segundo plano. Si los trabajadores de Sidekiq están bloqueados, fallan o están abrumados por una cola de trabajos pendientes, la publicación nunca se procesa. El proceso web agota el tiempo de espera y devuelve un error 500.

Configuración incorrecta del límite de velocidad

Mastodon aplica límites de velocidad al publicar para evitar el spam. Si la configuración del límite de velocidad es demasiado estricta o si el limitador de velocidad falla, las publicaciones legítimas pueden ser rechazadas. Un proxy inverso mal configurado como Nginx también puede devolver un 502 Bad Gateway, que algunos clientes interpretan como un error interno.

Agotamiento del espacio en disco

Mastodon almacena archivos adjuntos multimedia y archivos temporales en el disco. Cuando el disco está lleno, la aplicación no puede escribir nuevos archivos ni actualizar registros de la base de datos. Esta condición a menudo produce un error 500 durante cualquier operación de escritura, incluida la publicación.

Pasos de diagnóstico para encontrar la causa raíz de un error de publicación en Mastodon

Sigue estos pasos en orden. Detente cuando encuentres el error específico. No omitas pasos a menos que estés seguro de que el componente está en buen estado.

1. Revisa el log de producción de Mastodon
   Conéctate por SSH a tu servidor y ejecuta: tail -f /home/mastodon/live/log/production.log. Reproduce el error publicando de nuevo. Busca líneas que contengan RuntimeError, ActiveRecord::ConnectionTimeoutError o PG::Error. Estas líneas identifican el componente que falla.
2. Verifica que Sidekiq esté en ejecución
   Ejecuta systemctl status mastodon-sidekiq o ps aux | grep sidekiq. Si Sidekiq no está en ejecución, inícialo con systemctl start mastodon-sidekiq. Un Sidekiq detenido significa que los trabajos en segundo plano nunca se ejecutan, lo que provoca que la publicación falle.
3. Verifica la conectividad de la base de datos
   Desde el directorio de Mastodon, ejecuta RAILS_ENV=production bin/tootctl db:check. Este comando prueba la conexión a la base de datos. Si falla, verifica el estado de PostgreSQL con systemctl status postgresql y comprueba las credenciales de la base de datos en el archivo .env.production.
4. Inspecciona el uso del disco
   Ejecuta df -h y busca particiones con 100% de uso. Si la partición que contiene /home/mastodon está llena, libera espacio eliminando la caché de medios antigua: RAILS_ENV=production bin/tootctl media remove. Luego reinicia el proceso web de Mastodon: systemctl restart mastodon-web.
5. Revisa los logs de errores de Nginx
   Si usas Nginx como proxy inverso, revisa /var/log/nginx/error.log en busca de errores 502 o 504. Estos indican que el proceso web de Mastodon agotó el tiempo de espera o falló. Aumenta los valores de tiempo de espera del proxy en tu configuración de Nginx: proxy_read_timeout 120s; y proxy_send_timeout 120s;.
6. Reinicia todos los servicios de Mastodon
   Ejecuta systemctl restart mastodon-web mastodon-sidekiq mastodon-streaming. Esto borra el estado temporal y restablece las conexiones obsoletas. Después de reiniciar, intenta publicar de nuevo. Si el error desaparece, la causa fue un problema transitorio de recursos.
7. Monitorea el uso de recursos durante la publicación
   Usa htop o top mientras intentas publicar. Busca picos de CPU o memoria que hagan que el proceso web sea eliminado por el OOM killer. Si el proceso web de Mastodon desaparece después de un pico, aumenta la memoria del sistema o reduce el número de trabajadores de Sidekiq en .env.production.

Si el error interno del servidor persiste después del diagnóstico básico

La publicación falla solo con archivos adjuntos multimedia

Si las publicaciones solo de texto tienen éxito pero las publicaciones con imágenes o videos fallan, el problema probablemente sea el procesamiento de medios. Verifica que ffmpeg y libvips estén instalados y actualizados. Ejecuta which ffmpeg y ffmpeg -version. Si faltan, instálalos con tu gestor de paquetes. También verifica que el directorio mastodon-media tenga los permisos correctos: chown -R mastodon:mastodon /home/mastodon/live/public/system.

El error ocurre solo para una cuenta o contenido de publicación específico

Si solo una cuenta desencadena el error, la cuenta puede tener datos corruptos. Usa el panel de administración de Mastodon para revisar la cuenta y considera suspenderla y volver a crearla. Si el error ocurre con caracteres de texto específicos, como emoji o escrituras no latinas, la codificación de la base de datos puede estar incompleta. Asegúrate de que la base de datos PostgreSQL use codificación UTF-8: SHOW server_encoding;.

El error aparece de forma intermitente

Los errores 500 intermitentes a menudo apuntan al agotamiento de recursos bajo carga. Verifica el número de usuarios concurrentes en tu instancia. Si la instancia está sobrecargada, considera agregar más trabajadores de Sidekiq o actualizar el hardware del servidor. También puedes habilitar el registro de solicitudes en Nginx para correlacionar las marcas de tiempo de los errores con los picos de tráfico.

Error interno del servidor de Mastodon vs códigos de estado HTTP relacionados

Elemento	500 Internal Server Error	502 Bad Gateway
Significado	La propia aplicación Mastodon no pudo procesar la solicitud	El proxy inverso (Nginx) no pudo alcanzar el proceso web de Mastodon
Causa típica	Tiempo de espera de la base de datos, fallo de Sidekiq, disco lleno	Proceso web de Mastodon detenido o puerto inaccesible
Dónde diagnosticar	production.log de Mastodon y logs de Sidekiq	error.log de Nginx y systemctl status mastodon-web
Enfoque de solución	Reiniciar servicios, liberar disco, corregir la conexión a la base de datos	Reiniciar el proceso web, verificar el enlace de puerto en .env.production

Estos dos errores a menudo aparecen juntos. Un 502 en el navegador puede registrarse como un 500 en el log de la aplicación. Revisa siempre tanto los logs del proxy inverso como los logs de la aplicación Mastodon para obtener la imagen completa.

Ahora puedes identificar sistemáticamente por qué Mastodon devuelve un error interno del servidor al publicar. Comienza con el log de producción, luego revisa Sidekiq, la base de datos y el espacio en disco. Si el error persiste, aísla si se relaciona con medios, una cuenta específica o la carga de tráfico. Para el monitoreo continuo, configura la rotación de logs y alertas en el archivo production.log usando una herramienta como logwatch o un simple trabajo cron que busque “500” cada cinco minutos.