HTTP 503 Service Unavailable: wer liefert den Fehler?

So sieht die Meldung aus

limiting requests, excess: 20.640 by zone "perip", client: 198.51.100.7, server: example.com, request: "GET /api/ HTTP/1.1"

Häufige Ursachen

• limit_req oder limit_conn greift – nginx antwortet dann standardmäßig mit 503.
• Anwendung im Wartungsmodus, z. B. Nextcloud mit maintenance => true.
• Load Balancer (HAProxy, Cloud-LB) findet keinen gesunden Backend-Server.
• PHP-FPM- oder App-Worker voll ausgelastet, Warteschlange läuft über.
• Dienst nach Update oder Neustart noch nicht bereit.

Prüfen

1. Header prüfen: Server und Retry-After zeigen, wer antwortet
   curl -sSI https://example.com/ | head -n 5Kopieren
2. Rate-Limit-Treffer im error.log suchen
   grep -E 'limiting (requests|connections)' /var/log/nginx/error.log | tail -n 5Kopieren
3. Limits und feste 503-Antworten in der Konfiguration finden
   nginx -T 2>/dev/null | grep -nE 'limit_req|limit_conn|return 503'Kopieren
4. Ausgefallene Dienste anzeigen
   systemctl --failedKopieren

Lösung

• Bei Rate-Limits burst und nodelay sinnvoll setzen und mit limit_req_status 429; den passenden Code zurückgeben.
• Wartungsmodus der Anwendung beenden, z. B. occ maintenance:mode --off.
• Health-Checks am Load Balancer prüfen: Pfad, Port und erwarteten Statuscode.
• Worker-Anzahl an RAM und Last anpassen, z. B. pm.max_children bei PHP-FPM.
• Dienst neu starten und im Journal prüfen, warum er nicht bereit war.

Häufige Fragen

Was ist der Unterschied zwischen 502 und 503?

502 heißt: Das Backend hat ungültig oder gar nicht geantwortet. 503 heißt: Der Dienst ist bewusst oder wegen Überlast vorübergehend nicht verfügbar.

Schadet ein 503 dem Google-Ranking?

Kurzzeitig nicht – 503 ist genau dafür gedacht. Hält er über Tage an, entfernt Google Seiten aus dem Index. Setzen Sie bei Wartung einen Retry-After-Header.