503 Service Unavailable

Was dieser Fehler bedeutet und wie du ihn erkennst

• Der Browser, API-Client oder das Monitoring-Tool meldet 503 Service Unavailable oder Service Temporarily Unavailable.
• Der Fehler tritt bei hohem Traffic auf und verschwindet, wenn die Nachfrage sinkt.
• Die Website bleibt nach einem CMS-Update oder Deployment nicht verfügbar, weil der Wartungsmodus nicht beendet wurde.
• Der Fehler besteht fort, während eine benötigte Datenbank, ein Cache-Dienst oder eine Upstream-API nicht verfügbar ist.
• Nur bestimmte URLs, Clients, Anfrage-Muster oder Backends erhalten 503-Antworten, beispielsweise aufgrund von Rate Limiting, einer WAF-Regel, Routing oder eines fehlerhaften Health Checks des Load Balancers.
• Response-Header oder eine von einem Proxy erzeugte Fehlerseite weisen darauf hin, dass die Anfrage die Anwendung möglicherweise nicht erreicht hat.

Hauptursachen nach Wahrscheinlichkeit

1. Serverüberlastung — CPU, Speicher, aktive Verbindungen, Webserver-Worker, PHP-FPM-Worker oder Datenbankverbindungen sind durch die normale Nachfrage oder eine Traffic-Spitze erschöpft.
2. Nicht beendeter Wartungsmodus — Ein CMS-Update oder Deployment aktiviert ein Wartungs-Flag, entfernt es nach einer Unterbrechung jedoch nicht. In WordPress kann dies eine verwaiste Datei .maintenance sein.
3. Nicht verfügbare erforderliche Abhängigkeit — Die Anwendung kann eine Datenbank, eine Cache-Schicht oder eine interne API, die für die Verarbeitung der Anfrage benötigt wird, nicht erreichen. Die Abhängigkeit kann allgemein verfügbar, vom Host oder Netzwerk der Anwendung aus jedoch nicht erreichbar sein.
4. Absichtliches Rate Limiting oder WAF-Verhalten — Ein Rate Limiter oder eine Web Application Firewall kann 503-Antworten zurückgeben, wenn der Traffic einen Grenzwert überschreitet oder einer Sicherheitsregel entspricht.
5. Fehlerhafter Health Check des Load Balancers — Ein Check kann gesunde Backend-Instanzen als nicht verfügbar markieren, weil er den falschen Pfad verwendet oder den falschen Response-Code erwartet.
6. Proxy- oder Upstream-Konfigurationsproblem — Ein Reverse Proxy, CDN oder Upstream-Dienst kann den 503 erzeugen, bevor die Anwendung die Anfrage erhält.

So behebst du den Fehler

1. Ermitteln, welche Schicht den 503 erzeugt hat

Prüfen Sie die Response-Header und vergleichen Sie die Logs der Anwendung, des Webservers, des Reverse Proxys, des CDN oder der WAF sowie des Load Balancers. Ermitteln Sie, ob die Antwort von der Anwendung stammt oder erzeugt wurde, bevor die Anfrage sie erreicht hat. So vermeiden Sie Änderungen an Anwendungseinstellungen, wenn die blockierende Schicht an anderer Stelle liegt.

2. Ressourcenauslastung zum Zeitpunkt des Fehlers prüfen

Prüfen Sie CPU, Speicher, aktive Verbindungen, Webserver-Worker, gegebenenfalls PHP-FPM-Worker und Datenbankverbindungen. Verwenden Sie schreibgeschützte Monitoring-Tools wie top oder htop, Hosting-Dashboards und Infrastruktur-Monitoring, um festzustellen, ob ein Limit erreicht wurde.

• Wenn eine Ressource nahezu ausgelastet war, behandeln Sie den Vorfall als Überlastungs- oder Kapazitätsproblem.
• Wenn die Ressourcennutzung normal war, untersuchen Sie den Wartungsstatus, Abhängigkeiten, Rate Limits, WAF-Regeln und Health Checks.

3. Unvollständigen Wartungsstatus beenden

Stellen Sie bei WordPress sicher, dass das Update abgeschlossen ist oder die Website sich tatsächlich im Wartungsmodus befinden soll. Verbinden Sie sich anschließend per SFTP und prüfen Sie im Stammverzeichnis der Website, ob eine Datei namens .maintenance vorhanden ist. Wenn das Update abgeschlossen wurde, die Datei aber noch vorhanden ist, entfernen Sie sie und testen Sie die Website erneut. Das Entfernen der Datei ändert den Wartungsstatus der Website. Führen Sie dies daher nicht während eines aktiven Updates oder Deployments durch.

Andere Plattformen und Deployment-Tools verwenden möglicherweise eine Flag-Datei oder eine Umgebungsvariable. Prüfen Sie den Update- oder Deployment-Prozess, um festzustellen, wodurch der Wartungsmodus aktiviert wird und ob der Bereinigungsschritt nach einem unterbrochenen Prozess ausgeführt wurde.

4. Abhängigkeiten vom Anwendungsserver aus testen

Stellen Sie sicher, dass die Datenbank, die Cache-Schicht wie Redis oder Memcached und die benötigten internen Dienste laufen und vom Anwendungsserver aus erreichbar sind. Prüfen Sie Verbindungsfehler, Authentifizierungsfehler, Timeouts und Einträge in den Dienst-Logs.

Eine Abhängigkeit kann grundsätzlich funktionieren, vom jeweiligen Host der Anwendung aus jedoch aufgrund von Netzwerkzugriff, Zugangsdaten, Routing oder eines dienstseitigen Fehlers nicht erreichbar sein.

5. Echte Überlastung beheben

Ermitteln Sie die begrenzende Ressource, bevor Sie Einstellungen erhöhen. Der Engpass kann bei CPU, Speicher, Datenbankverbindungen, Webserver-Verbindungen oder PHP-FPM-Workern liegen.

Reduzieren Sie zur kurzfristigen Entlastung aufwendige Verarbeitung, erhöhen Sie ein Limit nur, wenn der Host ausreichend freie Kapazität hat und die Änderung autorisiert ist, oder aktivieren Sie Caching für geeignete Seiten. Bei wiederkehrender Nachfrage sollten Sie ein CDN oder eine Cache-Schicht und zusätzliche Backend-Kapazität in Betracht ziehen, statt Limits wiederholt anzuheben.

6. Rate Limits, WAF-Regeln und Health Checks des Load Balancers prüfen

Prüfen Sie die Logs von Nginx, Apache, dem CDN oder anderen Proxy- und Sicherheitskomponenten auf Regeln, die absichtlich 503-Antworten zurückgeben. Kontrollieren Sie die Pfade der Health Checks, die erwarteten Statuscodes und die Backend-Registrierung. Wenn nur bestimmte URLs, Clients oder Backends ausfallen, kann diese Information dabei helfen, Traffic-Steuerung oder Routing von einem vollständigen Website-Ausfall zu unterscheiden.

7. Reparatur überprüfen

Wiederholen Sie die fehlgeschlagene Anfrage und prüfen Sie die Logs der Anwendung, des Proxys und der Abhängigkeiten. Stellen Sie sicher, dass normale Anfragen erfolgreich sind, und testen Sie nach Möglichkeit unter einem ähnlichen Traffic-Niveau oder zu einer ähnlichen Tageszeit. Vergewissern Sie sich, dass die Lösung die auslösende Bedingung behebt und nicht nur ein vorübergehendes Symptom beseitigt.

Vorbeugung und Überprüfung der Lösung

• Stellen Sie sicher, dass Deployment- und Update-Skripte Wartungs-Flags in einem Bereinigungs- oder finally-Schritt entfernen, auch nach Teilfehlern.
• Überwachen Sie CPU, Speicher, aktive Verbindungen, Workerauslastung und Datenbankverbindungen und richten Sie Warnungen ein, bevor die Kapazität erschöpft ist.
• Cachen Sie geeignete Seiten und Datenbankoperationen, damit Traffic-Spitzen weniger Backend-Kapazität verbrauchen.
• Testen Sie die Health Checks des Load Balancers gegen den richtigen Pfad und den erwarteten Response-Code.
• Prüfen Sie Änderungen an Rate Limits und der WAF, damit absichtliche 503-Antworten von Dienstausfällen unterschieden werden können.
• Halten Sie Anwendungs-, Proxy-, Abhängigkeits- und Infrastruktur-Logs für denselben Zeitraum verfügbar, damit Fehler korreliert werden können.
• Überprüfen Sie die Website nach einer Reparatur unter Bedingungen, die denen beim ursprünglichen Auftreten des Fehlers möglichst ähnlich sind.

Häufig gestellte Fragen