503 Service Unavailable

Verwendung

Der Statuscode 503 Service Unavailable bedeutet, dass der Server die HTTP-Anfrage aus einem vorübergehenden Grund nicht erfüllen kann. Der Server ist durch einen plötzlichen Anstieg des Datenverkehrs überlastet, die Ressource ist gesperrt, der Server startet neu, oder eine fehlerhafte Firewall-Konfiguration blockiert die Anfrage.

Viele Websites geben während Wartungsarbeiten den Statuscode 503 Service Unavailable zurück. Das ist das empfohlene Vorgehen, um sicherzustellen, dass die Suchrankings nicht beeinträchtigt werden.

Wenn dem Server das Problem bekannt ist, etwa eine gesperrte oder überlastete Ressource, teilt der HTTP-Header Retry-After dem Client mit, wann die Anfrage erneut gesendet werden soll.

Amazon S3 gibt 503 Slow Down zurück, wenn die Anfrageraten die Durchsatzgrenzen pro Präfix überschreiten. Eine plötzliche Spitze oberhalb dieser Schwellenwerte löst eine Drosselung aus, während S3 die Partitionen im Hintergrund skaliert. Das Verteilen der Objekte auf mehrere Präfixe, die Umsetzung eines exponentiellen Backoffs und das schrittweise Steigern der Anfragerate vermeiden den Fehler. S3 berechnet für 503-Antworten keine Gebühren.

Fastly gibt 503 Service Unavailable mit dem Grundtext “Loop detected” zurück, wenn eine Anfrage anscheinend zurück zum selben Fastly-Dienst geleitet wird oder zu viele Fastly-Server durchlaufen hat. Fastly verfolgt die Anzahl der Hops einer Anfrage über die Header Fastly-FF und CDN-Loop. Eine Anfrage wird als Schleife abgewiesen, wenn sie eine dieser Grenzen überschreitet: mehr als drei vorherige Besuche desselben POP für denselben Dienst, mehr als sechs eindeutige Fastly-Dienste im Anfragepfad oder mehr als zwanzig Hops insgesamt über alle Dienste hinweg. Schleifen entstehen häufig, wenn derselbe Hostname sowohl als Domain als auch als Backend eines Dienstes konfiguriert ist und das DNS für diesen Hostnamen auf Fastly auflöst. Die Verwendung eines separaten Origin-Hostnamens (z. B. origin.example.re) oder einer IP-Adresse für das Backend vermeidet die Schleife.

Hinweis

503 bedeutet, dass der Server für alle Clients vorübergehend nicht verfügbar ist (Überlastung, Wartung). 429 bedeutet, dass ein bestimmter Client sein Ratenlimit überschritten hat. Verwenden Sie 429 für die Drosselung einzelner Clients und 503 für serverweite Nichtverfügbarkeit.

SEO-Auswirkung

Googlebot wertet 5xx-Fehler als Signal, die Crawling-Rate für die gesamte Website vorübergehend zu senken. Bereits indexierte URLs bleiben zunächst erhalten, doch eine längere Ausfallzeit führt dazu, dass Google sie aus dem Index entfernt. Jeglicher Inhalt, der mit einer 503-Antwort ausgeliefert wird, wird ignoriert. Google behandelt 500, 502 und 503 identisch. Für geplante Wartungsarbeiten bietet 503 keinen besonderen Vorteil gegenüber anderen 5xx-Codes, auch wenn verbreitete Ratschläge etwas anderes nahelegen. Ein 5xx-Fehler bei der Datei robots.txt ist weitaus gravierender, selbst wenn jede andere Seite der Website 200 zurückgibt. Google stoppt das Crawling für bis zu 12 Stunden und greift anschließend für bis zu 30 Tage auf eine zwischengespeicherte Kopie zurück. Bleibt der Fehler bestehen, nimmt Google die Website vollständig aus dem Index. Bingbot berücksichtigt Retry-After bei 503-Antworten, um erneute Besuche einzuplanen. Dauerhafte 503-Antworten verhindern die Indexierung in Bing.

Beispiel

Der Client fordert eine Ressource an, und der Server antwortet mit 503 Service Unavailable, weil die Ressource vorübergehend nicht verfügbar ist. Der Header Retry-After schlägt vor, die Anfrage nach 30 Minuten erneut zu senden.

Anfrage

GET /latest_quotes HTTP/1.1
Host: example.com

Antwort

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>

Behebung

Stellen Sie zunächst fest, ob der 503 beabsichtigt (Wartungsmodus) oder ungeplant (Überlastung, Absturz) ist. Ein beabsichtigter 503 in Verbindung mit einem Retry-After-Header erfordert keine Fehlersuche, sondern nur das Abwarten des Wartungsendes.

Prüfen Sie bei ungeplanten 503-Fehlern diese häufigen Ursachen:

Erschöpfte Serverressourcen. Führen Sie top, htop oder vmstat auf dem Server aus. Eine hohe CPU- oder Speicherauslastung bedeutet, dass dem Server die Kapazität fehlt. In Apache zeigt das Fehlerprotokoll “server reached MaxRequestWorkers setting”, wenn alle Worker-Plätze belegt sind. Erhöhen Sie MaxRequestWorkers (und ServerLimit beim prefork MPM) in der Apache-Konfiguration. Erhöhen Sie in nginx worker_connections im events-Block.

Absturz des Anwendungs-Pools. Wenn PHP-FPM, Gunicorn oder ein ähnlicher Prozessmanager unter Last beendet wird, bleibt dem Webserver kein Backend zur Bearbeitung der Anfragen. Prüfen Sie die Protokolle des Prozessmanagers und erhöhen Sie anschließend die Pool-Größe (pm.max_children in PHP-FPM, —workers in Gunicorn).

Erschöpfter Verbindungspool. Wenn Verbindungspools zur Datenbank oder zu externen APIs leerlaufen, muss die Anwendung neue Anfragen ablehnen. Erhöhen Sie die Pool-Größe in der Anwendungskonfiguration und stellen Sie sicher, dass Verbindungen nach der Nutzung ordnungsgemäß freigegeben werden.

Ratenbegrenzung. Die nginx-Module limit_req und limit_conn geben 503 (oder einen benutzerdefinierten Status) zurück, wenn Schwellenwerte überschritten werden. Überprüfen Sie die Direktiven limit_req_zone und limit_conn_zone. Erhöhen Sie die burst-Werte oder ergänzen Sie nodelay, um Verkehrsspitzen abzufangen.

Fehlgeschlagene Health-Checks des Load-Balancers. Ein fehlschlagender Health-Check nimmt den Server aus der Rotation. Prüfen Sie bei AWS ALB/NLB den Zustand der Targets in der Konsole. Überprüfen Sie in nginx-upstream-Blöcken die Einstellungen max_fails und fail_timeout.

Durch Deployment ausgelöster Neustart. Rolling Deployments mit zu wenigen Instanzen verursachen kurze 503-Zeitfenster. Erhöhen Sie die Mindestanzahl gesunder Instanzen oder setzen Sie Blue-Green-Deployments ein.

AWS-S3-Drosselung (503 Slow Down). S3 drosselt Anfragen, die die Anfrageratengrenzen pro Präfix überschreiten. Verteilen Sie Objekte mit zufälligen Schlüsselpräfixen (z. B. hex-hash/original-key) auf mehrere Präfixe. Implementieren Sie einen exponentiellen Backoff beginnend bei 1 Sekunde. Steigern Sie die Anfragerate schrittweise, statt Burst-Verkehr zu senden. Bei korrekter Konfiguration wiederholt das AWS SDK 503-SlowDown-Antworten automatisch mit Backoff.

Fügen Sie bei Verkehrsspitzen ein CDN oder eine Caching-Schicht hinzu, um statische Anfragen auszulagern. Richten Sie Monitoring und Alarmierung für 503-Raten ein, damit Ressourcenengpässe sichtbar werden, bevor es zu einem vollständigen Ausfall kommt.

Code-Referenzen

.NET

HttpStatusCode.ServiceUnavailable

Rust

http::StatusCode::SERVICE_UNAVAILABLE

Rails

:service_unavailable

http.StatusServiceUnavailable

Symfony

Response::HTTP_SERVICE_UNAVAILABLE

Python3.5+

http.HTTPStatus.SERVICE_UNAVAILABLE

Java

java.net.HttpURLConnection.HTTP_UNAVAILABLE

Apache HttpComponents Core

org.apache.hc.core5.http.HttpStatus.SC_SERVICE_UNAVAILABLE

Angular

@angular/common/http/HttpStatusCode.ServiceUnavailable