Error 503: ¿sobrecarga, mantenimiento o límite del hosting?

Qué significa el error

Con un 503, el servidor web dice: « Estoy aquí, pero ahora mismo no puedo atenderte. » A diferencia del 502, no tiene por qué haber nada roto, y a diferencia del 500, la aplicación no falló. El servidor envía el 503 a propósito, en tres situaciones: está en modo mantenimiento, alcanzó un límite que alguien le fijó (conexiones, workers, ancho de banda, peticiones por segundo) o está tan cargado que rechaza peticiones para no caer del todo. Los buscadores tratan un 503 breve como algo temporal y no desindexan el sitio.

Causas frecuentes

1. Modo mantenimiento que se quedó bloqueado. Durante una actualización, WordPress crea un archivo .maintenance y responde 503 mientras exista. Si la actualización se interrumpe, el archivo se queda, y el error con él. Laravel, Magento y Drupal tienen un interruptor parecido.
2. Sobrecarga. Más peticiones de las que los workers pueden atender: MaxRequestWorkers de Apache alcanzado, pm.max_children de PHP-FPM agotado, o una base de datos tan lenta que cada worker se queda esperando.
3. Un límite del hosting. Los proveedores de hosting compartido limitan los segundos de CPU, los procesos simultáneos o los « entry processes » por cuenta. Límite alcanzado, tu sitio responde 503.
4. Un backend fuera de la rotación. Detrás de un balanceador de carga o de un CDN, 503 significa que ningún backend pasó la comprobación de salud. Cloudflare muestra su propia página 503 cuando el servidor de origen está sobrecargado.
5. Rastreadores y scrapers. Un rastreador que descarga miles de páginas o un ataque de fuerza bruta contra wp-login.php consume los workers; los visitantes reales reciben 503.
6. Disco o memoria llenos. El servicio funciona, pero ya no puede escribir sesiones, caché ni logs; algunas aplicaciones responden entonces con 503.

Si eres visitante

Espera un minuto y recarga; un 503 casi siempre es breve. Si un sitio lleva horas en 503, quien lo gestiona tiene un modo mantenimiento bloqueado o un problema de capacidad; solo esa persona puede actuar.

Si el sitio es tuyo: comprobar primero

Abre el Website down checker para confirmar el 503 desde fuera y ver si lo envió un CDN o tu servidor. Después decide: ¿se lanzó una actualización en los últimos minutos? Si la respuesta es sí, es el modo mantenimiento. Si no, es la capacidad.

En tu propio servidor:

# ¿siquiera funciona el servidor web?
systemctl status nginx
systemctl status apache2

# carga, memoria, disco
uptime
free -m
df -h

# ¿quién está machacando el sitio?
sudo tail -n 5000 /var/log/nginx/access.log | awk '{print $1}' | sort | uniq -c | sort -rn | head

Una carga muy por encima del número de núcleos, una memoria casi agotada o una sola IP con miles de peticiones: cada una explica un 503.

Soluciones en tu propio servidor

1. Salir de un modo mantenimiento bloqueado

WordPress: borra el archivo .maintenance en la raíz del sitio y abre la página. Si la actualización se interrumpió, puede que un plugin o el núcleo hayan quedado a medio instalar; repite la actualización con WP-CLI:

rm /var/www/example.com/.maintenance
wp core verify-checksums
wp plugin update --all

Laravel: php artisan up. Drupal: drush state:set system.maintenance_mode 0.

2. Cortar la avalancha

Bloquea la IP o la red sospechosa y limita después el ritmo de peticiones para que la siguiente no llegue tan lejos.

# bloquear una dirección (Debian/Ubuntu con ufw)
sudo ufw deny from 203.0.113.45

Límite de peticiones en nginx para la página de inicio de sesión:

limit_req_zone $binary_remote_addr zone=login:10m rate=5r/m;

location = /wp-login.php {
    limit_req zone=login burst=5 nodelay;
    include snippets/fastcgi-php.conf;
    fastcgi_pass unix:/run/php/php8.3-fpm.sock;
}

Apache: mod_evasive o mod_qos hacen lo mismo; fail2ban expulsa a los reincidentes.

3. Darle capacidad al servidor

Si la carga viene de visitantes reales y no de un abuso, sube los límites de workers hasta donde lo permita la memoria. Apache (mpm_event): MaxRequestWorkers. PHP-FPM: pm.max_children. Comprueba primero la memoria por worker (ps -ylC php-fpm8.3 --sort:rss), después prueba y recarga:

sudo apachectl configtest && sudo systemctl reload apache2
sudo php-fpm8.3 -t && sudo systemctl reload php8.3-fpm

Activa una caché de páginas (WordPress: un plugin de caché o la caché FastCGI de nginx) para que un pico no arranque PHP en cada petición. Una página en caché cuesta una fracción de milisegundo; sin caché, cientos.

4. Liberar el disco

sudo du -xh --max-depth=1 /var | sort -h | tail
sudo journalctl --vacuum-size=200M
sudo apt clean

Logs antiguos, copias de seguridad en el mismo disco, un log de depuración que no para de crecer: los sospechosos habituales.

5. Detrás de un balanceador de carga

Si todos los backends fallan a la vez en la comprobación de salud, lo roto suele ser la URL de comprobación (página borrada, redirección a HTTPS que no se sigue), no cada backend.

Si el problema está en tu proveedor de hosting

En un hosting compartido no puedes subir ningún límite. Pregunta a tu proveedor de hosting cuál alcanzaste, y si fue tu tráfico u otra cuenta del mismo servidor:

Hola, mi sitio example.com responde « 503 Service Unavailable » desde aproximadamente las 9:10 (UTC). No he lanzado ninguna actualización y el sitio no está en modo mantenimiento. ¿Pueden decirme si mi cuenta alcanzó un límite de recursos (CPU, procesos, memoria) o si el servidor está sobrecargado? Si es mi cuenta: ¿qué límite, y desde cuándo?

Si la respuesta es una y otra vez « límites alcanzados », pon el sitio en caché o pasa a un plan más amplio.

Para que no vuelva a pasar

Un 503 se anuncia: la carga sube, la memoria escasea, una IP empieza a inundar. Las comprobaciones del sitio atrapan el 503 en cuanto aparece; el agente de servidor muestra carga, memoria y disco antes.

¿Caído? Intervenimos. En tu propio servidor o en un hosting compartido con acceso SSH, la intervención rápida libera espacio en disco y reinicia un servicio bloqueado, a precio fijo; la intervención a fondo configura el límite de peticiones y la caché, las 24 horas, todos los días, para que el servidor aguante la próxima vez.