Error 503 Service Unavailable: significado y solución

¿Qué es el error HTTP 503?

503 Service Unavailable significa que el servidor, o algo delante de él, no puede atender tu solicitud en este momento: está sobrecargado, en mantenimiento, limitando la tasa de solicitudes o no tiene ningún backend sano al que pasarla. La RFC 9110 lo define como una condición temporal que probablemente desaparezca pasado un tiempo.

El servidor puede añadir un encabezado Retry-After que indica cuánto esperar. A diferencia de un 500, que significa que algo se ha roto, un 503 dice "ahora no", y por eso los sitios lo usan para el mantenimiento programado.

Muchas veces no responde tu servidor web, sino una capa delante de él: un balanceador de carga como HAProxy, una caché como Varnish, una CDN como Cloudflare o un ingress de Kubernetes. El texto exacto te dice cuál (ver más abajo).

Cómo se ve un error 503

El mensaje te dice qué capa respondió. Estos son los más habituales, con el software que los escribe:

Sea cual sea el texto, la respuesta es la misma: esta solicitud no se puede atender ahora mismo, y la capa indicada en la tabla es donde hay que mirar.

Causas comunes del error HTTP 503

Los motivos habituales por los que un servidor, o una capa delante de él, devuelve 503:

• Sobrecarga — se alcanzan los límites de CPU, memoria o conexiones durante un pico de tráfico, una publicación viral o un crawler agresivo
• Mantenimiento programado — el sitio está desconectado a propósito por una actualización o migración; bien hecho, con un encabezado Retry-After
• Ningún backend sano — el balanceador de carga, el proxy o el ingress no tiene ningún servidor operativo al que enviar la solicitud (aplicación caída, comprobaciones de estado fallidas, ningún pod listo)
• Límites de tasa o de conexiones — limit_req y limit_conn de nginx responden 503 por defecto, así que un cliente o crawler muy activo puede provocarlo
• Una aplicación caída o detenida — PHP-FPM, Node.js o Python parado detrás de un servidor web que sigue en marcha; en IIS, un grupo de aplicaciones detenido
• Límites de recursos del hosting — el hosting compartido limita la CPU, la memoria y los procesos por cuenta
• Un plugin, tema o actualización — en WordPress y otros CMS, una mala actualización puede bloquear la aplicación o dejar el sitio atascado en modo mantenimiento
• Un ataque — un DDoS o una avalancha de bots agota los mismos recursos que un pico de tráfico

Solución para visitantes: qué puedes hacer

Si estás visitando el sitio de otra persona, el problema está de su lado. Esto es lo que puedes hacer:

• Espera y vuelve a intentarlo — un 503 está pensado para ser temporal; espera un minuto y recarga una sola vez. Si la página muestra un tiempo de Retry-After o un mensaje de mantenimiento, espera ese tiempo
• Comprueba si está caída para todos — el Verificador de páginas caídas de DNS Robot prueba el sitio desde fuera de tu red
• Mira la página de estado o las redes sociales del sitio — el mantenimiento programado y las caídas suelen anunciarse
• Prueba con otra red — si el sitio carga con datos móviles, o bien una VPN o proxy de tu red habitual está respondiendo con el 503, o bien el sitio está limitando la tasa de solicitudes de tu dirección IP

Solución 1: averigua qué capa envió el 503

Antes de reiniciar nada, mira el mensaje y los encabezados de respuesta: te dicen qué capa respondió. Comprueba desde fuera con el Verificador de encabezados HTTP de DNS Robot o con curl -sI, y fíjate en el encabezado server y en el cuerpo de la página (ver la tabla de arriba).

Después reinicia la capa que está fallando, no solo el servidor web:

# Restart Nginx
sudo systemctl restart nginx

# Restart Apache
sudo systemctl restart apache2      # Debian/Ubuntu
sudo systemctl restart httpd         # CentOS/RHEL

# Restart PHP-FPM
sudo systemctl restart php8.2-fpm    # Adjust version as needed

# Restart Node.js (PM2)
pm2 restart all

# Restart entire server (last resort)
sudo reboot

Si el 503 vuelve a los pocos minutos de un reinicio, la causa sigue ahí: pasa a los recursos y los logs.

Solución 2: verifica los recursos del servidor (CPU, RAM, disco)

Si el servidor está sobrecargado, reiniciar solo proporciona alivio temporal. Comprueba qué está consumiendo los recursos.

# Check CPU and memory usage
top -bn1 | head -20

# Check disk space
df -h

# Check memory in detail
free -m

# Check active connections
ss -s

# Find processes using the most memory
ps aux --sort=-%mem | head -10

# Find processes using the most CPU
ps aux --sort=-%cpu | head -10

Si la CPU o la RAM están por encima del 90%, necesitas optimizar tu aplicación, matar procesos descontrolados o mejorar tu servidor. Si el espacio en disco está lleno, limpia archivos de log, copias de seguridad antiguas o archivos temporales.

Solución 3: revisa los logs de error

Los logs te dicen exactamente por qué ocurrió el 503. Lee las últimas líneas con los comandos de abajo y busca en ellas lo siguiente:

# Nginx error log
tail -50 /var/log/nginx/error.log

# Apache error log
tail -50 /var/log/apache2/error.log      # Debian/Ubuntu
tail -50 /var/log/httpd/error_log         # CentOS/RHEL

# PHP-FPM log
tail -50 /var/log/php8.2-fpm.log

# WordPress debug log (if WP_DEBUG_LOG is enabled)
tail -50 /var/www/html/wp-content/debug.log

# System log
tail -50 /var/log/syslog

"limiting requests" o "limiting connections" (nginx) — limit_req o limit_conn rechazó la solicitud; responde 503 salvo que configures limit_req_status o limit_conn_status.

"max_children" (PHP-FPM, p. ej. "server reached pm.max_children setting") — todos los workers de PHP están ocupados: Apache responde 503, mientras que nginx responde 502 o 504.

"AH01114" / "failed to make connection to backend" (Apache mod_proxy) — Apache no pudo llegar al backend y respondió 503.

"Too many connections" (MySQL) — se agotó el límite de conexiones de la base de datos.

Los "no live upstreams" y "upstream timed out" de nginx pertenecen a 502 Bad Gateway y 504 Gateway Timeout, no al 503.

Solución 4: desactiva plugins y temas (WordPress / CMS)

En WordPress y otros CMS, un plugin pesado puede agotar los workers de PHP o los límites de recursos de tu hosting, lo que da un 503 (un plugin que se bloquea da un 500). Si el 503 empezó tras actualizar o instalar un plugin, empieza por ese.

Si no puedes acceder al panel de administración de WordPress, desactiva los plugins desde el sistema de archivos o la base de datos.

# Disable all plugins by renaming the plugins folder
cd /var/www/html/wp-content
mv plugins plugins_disabled

# If the site loads, rename it back and re-enable plugins one by one
mv plugins_disabled plugins

# To disable a single plugin
mv plugins/problem-plugin plugins/problem-plugin.disabled

Después de identificar el plugin defectuoso, actualízalo, reemplázalo con una alternativa o contacta al desarrollador del plugin. También verifica si tu versión de PHP es compatible: algunos plugins fallan cuando el servidor actualiza PHP.

¿Atascado en "Briefly unavailable for scheduled maintenance"? WordPress crea un archivo .maintenance en la raíz del sitio durante las actualizaciones y lo ignora cuando tiene más de 10 minutos. Bórralo para volver antes; si el mensaje sigue, busca un archivo wp-content/maintenance.php o una copia en caché de la página.

Solución 5: aumenta los límites de PHP y del servidor

Si tu servidor se queda sin workers PHP o alcanza los límites de memoria, necesitas aumentar los límites en tu configuración.

; PHP-FPM pool (e.g. /etc/php/8.2/fpm/pool.d/www.conf); the default ships with pm.max_children = 5
pm = dynamic
pm.max_children = 50
pm.start_servers = 10
pm.min_spare_servers = 5
pm.max_spare_servers = 20
pm.max_requests = 500

; php.ini (defaults: memory_limit = 128M, max_execution_time = 30)
memory_limit = 256M
max_execution_time = 300

Reinicia PHP-FPM después (sudo systemctl restart php8.2-fpm, con tu versión) para que se carguen los nuevos límites.

Solución 6: revisa tu CDN o balanceador de carga

Si usas Cloudflare, otra CDN o un balanceador de carga, el 503 puede venir de ellos y no de tu servidor.

La regla de Cloudflare (su guía del error 503):

• La página contiene "cloudflare" o "cloudflare-nginx" — la generó Cloudflare: comprueba si un Worker supera sus límites de CPU o memoria y contacta después con el soporte de Cloudflare con la salida de /cdn-cgi/trace
• Sin marca de Cloudflare — tu servidor de origen devolvió el 503 y Cloudflare lo reenvió: revisa los logs del origen y pregunta a tu hosting si limita la tasa de las direcciones IP de Cloudflare

Con HAProxy, un balanceador de carga en la nube o un ingress de Kubernetes, revisa los backends: un 503 ahí suele significar que ningún backend pudo atender la solicitud (en un Application Load Balancer de AWS, que el grupo de destino no tiene destinos registrados). La Consulta DNS de DNS Robot confirma que tu dominio sigue apuntando donde esperas.

Solución 7: verifica ataques DDoS o de bots

Un pico repentino de tráfico de bots o un ataque DDoS puede sobrecargar tu servidor. Revisa tus logs de acceso en busca de patrones sospechosos.

# Count requests per IP in the last 1000 lines
tail -1000 /var/log/nginx/access.log | awk '{print $1}' | sort | uniq -c | sort -rn | head -20

# Requests per minute (use -f1-4 for per second)
awk '{print $4}' /var/log/nginx/access.log | cut -d: -f1-3 | uniq -c | sort -rn | head -10

# Block an abusive IP (-I puts the rule first, before any ACCEPT rules)
sudo iptables -I INPUT -s 1.2.3.4 -j DROP

# Or in nginx's server block:
# deny 1.2.3.4;

Si una dirección o un rango pequeño envía miles de solicitudes, bloquéalo en el firewall. Detrás de Cloudflare u otra CDN, haz primero que tus logs muestren la IP real del visitante (set_real_ip_from más real_ip_header CF-Connecting-IP en nginx), o bloquearás la CDN en lugar del atacante. Para un ataque grande, el modo "I'm Under Attack" de Cloudflare o la protección DDoS de tu hosting filtra el tráfico antes de que llegue a ti.

Solución 8: soluciona problemas de conexión con la base de datos

Cuando la base de datos se queda sin conexiones o se detiene, la aplicación que está delante puede fallar. Algunas apps responden 503; WordPress muestra en su lugar "Error establishing a database connection". Comprueba la base de datos directamente:

# Check if MySQL/MariaDB is running (the unit is mysqld on RHEL, mariadb for MariaDB)
sudo systemctl status mysql

# Restart MySQL
sudo systemctl restart mysql

# Check current connections vs limit
mysql -e "SHOW STATUS LIKE 'Threads_connected';"
mysql -e "SHOW VARIABLES LIKE 'max_connections';"

# Increase max connections (temporary)
mysql -e "SET GLOBAL max_connections = 200;"

# Check for long-running queries
mysql -e "SHOW PROCESSLIST;" | head -20

Si encuentras muchas conexiones dormidas, tu aplicación no está cerrando las conexiones de la base de datos correctamente. Si las consultas de larga duración están bloqueando a otras, optimiza esas consultas o mátalas para desbloquear la base de datos.

Solución 9: contacta a tu proveedor de hosting

Si estás en hosting compartido, WordPress administrado o una plataforma como Squarespace, Wix o Shopify, puede que no tengas acceso a los logs del servidor ni la capacidad de reiniciar servicios. En estos casos, el 503 puede estar causado por la infraestructura del proveedor de hosting.

Contacta al soporte de tu proveedor de hosting y proporciona:

• La URL exacta que devuelve 503
• Cuándo empezó el error — anota la fecha y la hora
• Qué cambió — ¿instalaste un plugin, actualizaste un tema o cambiaste configuraciones de DNS?
• Si es intermitente o constante — errores 503 intermitentes sugieren límites de recursos; errores 503 constantes sugieren un bloqueo o configuración incorrecta

503 vs otros errores HTTP

El error 503 se confunde frecuentemente con otros errores de servidor. Así es como se diferencian.

La diferencia clave: un 503 está pensado para ser temporal, y un encabezado Retry-After puede indicar durante cuánto tiempo. Para el rastreo, Google trata igual los errores 5xx y 429: sus crawlers reducen el ritmo, y las URL indexadas se conservan un tiempo pero acaban eliminándose si los errores continúan (Google Search Central).

Para los errores del lado del proxy, consulta 502 Bad Gateway y 504 Gateway Timeout; para los límites de tasa, 429 Too Many Requests.

Cómo prevenir errores 503

La prevención es mejor que apagar incendios. Estas son las mejores prácticas para evitar errores 503.

• Monitoriza los recursos del servidor — Configura alertas para CPU > 80%, RAM > 85% y disco > 90%. Herramientas como UptimeRobot, Pingdom o Grafana proporcionan notificaciones instantáneas.
• Usa una CDN — Cloudflare, Fastly o AWS CloudFront almacenan en caché los recursos estáticos y absorben picos de tráfico, reduciendo la carga en el servidor de origen.
• Activa la caché — Usa Redis, Memcached o Varnish para almacenar en caché consultas a la base de datos y páginas renderizadas. Usuarios de WordPress: instala un plugin de caché como WP Super Cache o W3 Total Cache.
• Auto-escalado — Si usas hosting en la nube (AWS, GCP, Azure, DigitalOcean), configura el auto-scaling para añadir más servidores durante picos de tráfico.
• Limita la tasa de bots — Configura Nginx o Cloudflare para limitar la tasa de crawlers y scrapers agresivos antes de que sobrecarguen tu servidor.
• Optimiza las consultas de la base de datos — las consultas lentas mantienen conexiones y workers ocupados. Añade índices, optimiza los joins y guarda los resultados en caché con Redis o Memcached.
• Usa una página de mantenimiento adecuada — Durante los despliegues, devuelve 503 con un encabezado Retry-After en vez de dejar que el servidor se bloquee. Esto preserva el SEO e informa a los usuarios.
• Mantén el software actualizado — Actualiza tu CMS, plugins, PHP y base de datos a las últimas versiones estables para evitar errores conocidos y problemas de seguridad.