503 Service Unavailable
Uso
El código de estado 503 Service Unavailable significa que el servidor no puede completar la solicitud HTTP por un motivo temporal. Puede que el servidor esté sobrecargado por un aumento repentino de tráfico, que el recurso esté bloqueado, que el servidor se esté reiniciando o que una configuración incorrecta del cortafuegos esté bloqueando la solicitud.
Muchos sitios devuelven el código de estado 503 Service Unavailable durante las tareas de mantenimiento, que es el enfoque recomendado para garantizar que las posiciones en los buscadores no se vean afectadas.
Cuando el servidor conoce el problema, por ejemplo un recurso bloqueado o sobrecargado, la cabecera HTTP Retry-After informa al cliente de cuándo debe reenviar la solicitud.
Amazon S3 devuelve 503 Slow Down cuando las tasas de solicitud superan los límites de rendimiento por prefijo. Un pico repentino por encima de esos umbrales activa la limitación mientras S3 escala las particiones en segundo plano. Distribuir los objetos entre varios prefijos, implementar una espera exponencial e incrementar gradualmente las tasas de solicitud evita el error. S3 no cobra por las respuestas 503.
Fastly devuelve 503 Service Unavailable con el texto de motivo “Loop detected” cuando una solicitud parece volver a enrutarse al mismo servicio de Fastly o ha atravesado demasiados servidores de Fastly. Fastly rastrea los saltos de la solicitud mediante las cabeceras Fastly-FF y CDN-Loop. Una solicitud se rechaza como bucle cuando supera cualquiera de estos límites: más de tres visitas previas al mismo POP para el mismo servicio, más de seis servicios únicos de Fastly en la ruta de la solicitud o más de veinte saltos en total entre todos los servicios. Los bucles se producen habitualmente cuando el mismo nombre de host se configura a la vez como dominio y como backend de un servicio, y el DNS de ese nombre de host resuelve a Fastly. Usar un nombre de host de origen independiente (por ejemplo, origin.example.re) o una dirección IP para el backend evita el bucle.
Nota
503 significa que el servidor no está disponible temporalmente para todos los clientes (sobrecarga, mantenimiento). 429 significa que un cliente concreto superó su límite de tasa. Use 429 para la limitación por cliente y 503 para la indisponibilidad de todo el servidor.
Impacto en SEO
Googlebot interpreta los errores 5xx como una señal para reducir temporalmente la velocidad de rastreo en todo el sitio. Las URL indexadas previamente se conservan al principio, pero una inactividad prolongada hace que Google las elimine del índice. Cualquier contenido devuelto con una respuesta 503 se ignora. Google trata 500, 502 y 503 de forma idéntica. 503 no tiene ninguna ventaja especial frente a otros códigos 5xx para el mantenimiento planificado, pese a que los consejos habituales sugieran lo contrario. Un error 5xx en el archivo robots.txt es mucho más grave, incluso si todas las demás páginas del sitio devuelven 200. Google detiene el rastreo hasta 12 horas y después recurre a una copia en caché durante un máximo de 30 días. Si el error persiste, Google desindexa el sitio por completo. Bingbot respeta Retry-After en las respuestas 503 para programar sus siguientes visitas. Las respuestas 503 persistentes impiden la indexación en Bing.
Ejemplo
El cliente solicita un recurso y el servidor responde con un 503 Service Unavailable porque el recurso no está disponible temporalmente. La cabecera Retry-After sugiere reenviar la solicitud pasados 30 minutos.
Solicitud
GET /latest_quotes HTTP/1.1
Host: example.comRespuesta
HTTP/1.1 503 Service Unavailable
Content-Type: text/html; charset=UTF-8
Content-Length: 124
Retry-After: 1800
<html>
<head>
<title>Resource Busy</title>
</head>
<body>
<p>Try again after 30 minutes.</p>
</body>
</html>Cómo solucionarlo
Determine si el 503 es intencionado (modo de mantenimiento) o imprevisto (sobrecarga, caída). Un 503 intencionado acompañado de una cabecera Retry-After no requiere depuración, solo esperar a que termine el mantenimiento.
Para los errores 503 imprevistos, compruebe estas causas habituales:
Agotamiento de los recursos del servidor. Ejecute top, htop o vmstat en el servidor. Un uso elevado de CPU o de memoria significa que al servidor le falta capacidad. En Apache, el registro de errores muestra “server reached MaxRequestWorkers setting” cuando todas las ranuras de trabajadores están ocupadas. Aumente MaxRequestWorkers (y ServerLimit para el MPM prefork) en la configuración de Apache. En nginx, aumente worker_connections en el bloque events.
Caída del pool de aplicaciones. Si PHP-FPM, Gunicorn o un gestor de procesos similar se cierra bajo carga, el servidor web se queda sin backend para atender las solicitudes. Revise los registros del gestor de procesos y aumente después el tamaño del pool (pm.max_children en PHP-FPM, —workers en Gunicorn).
Agotamiento del pool de conexiones. Cuando los pools de conexiones a la base de datos o a una API externa se quedan sin conexiones, la aplicación se ve obligada a rechazar nuevas solicitudes. Aumente el tamaño del pool en la configuración de la aplicación y confirme que las conexiones se liberan correctamente después de usarlas.
Limitación de tasa. Los módulos limit_req y limit_conn de nginx devuelven 503 (o un estado personalizado) cuando se superan los umbrales. Revise las directivas limit_req_zone y limit_conn_zone. Aumente los valores de burst o añada nodelay para absorber los picos de tráfico.
Fallo de la comprobación de estado del equilibrador de carga. Una comprobación de estado fallida retira el servidor de la rotación. En AWS ALB/NLB, consulte el estado de los destinos en la consola. En los bloques upstream de nginx, revise los ajustes max_fails y fail_timeout.
Reinicio provocado por un despliegue. Los despliegues progresivos con demasiado pocas instancias provocan breves ventanas de 503. Aumente el número mínimo de instancias en buen estado o utilice despliegues blue-green.
Limitación de AWS S3 (503 Slow Down). S3 limita las solicitudes que superan los límites de tasa de solicitudes por prefijo. Distribuya los objetos entre varios prefijos usando prefijos de clave aleatorizados (por ejemplo, hex-hash/original-key). Implemente una espera exponencial que comience en 1 segundo. Incremente las tasas de solicitud de forma gradual en lugar de enviar tráfico en ráfagas. Si está correctamente configurado, el SDK de AWS reintenta automáticamente las respuestas 503 SlowDown aplicando espera exponencial.
Ante picos de tráfico, añada una CDN o una capa de caché para descargar las solicitudes estáticas. Configure monitorización y alertas sobre la tasa de 503 para que las limitaciones de recursos salgan a la luz antes de una caída total.
Referencias de código
.NET
HttpStatusCode.ServiceUnavailableRust
http::StatusCode::SERVICE_UNAVAILABLERails
:service_unavailableGo
http.StatusServiceUnavailableSymfony
Response::HTTP_SERVICE_UNAVAILABLEPython3.5+
http.HTTPStatus.SERVICE_UNAVAILABLEJava
java.net.HttpURLConnection.HTTP_UNAVAILABLEApache HttpComponents Core
org.apache.hc.core5.http.HttpStatus.SC_SERVICE_UNAVAILABLEAngular
@angular/common/http/HttpStatusCode.ServiceUnavailable