HTTP 503 Service Unavailable: Bedeutung und Lösung

Was ist HTTP-Fehler 503?

503 Service Unavailable bedeutet, dass der Server oder etwas davor Ihre Anfrage gerade nicht bearbeiten kann: Er ist überlastet, in Wartung, begrenzt die Anfragen oder hat kein funktionierendes Backend, an das er sie weiterreichen könnte. RFC 9110 definiert ihn als vorübergehenden Zustand, der sich nach einer Weile voraussichtlich auflöst.

Der Server kann einen Retry-After-Header mitsenden, der angibt, wie lange Sie warten sollen. Anders als ein 500, der bedeutet, dass etwas kaputt ist, sagt ein 503 „jetzt nicht“. Deshalb nutzen Websites ihn für geplante Wartungen.

Oft antwortet gar nicht Ihr Webserver, sondern eine Ebene davor: ein Load Balancer wie HAProxy, ein Cache wie Varnish, ein CDN wie Cloudflare oder ein Kubernetes-Ingress. Der genaue Wortlaut verrät, welche (siehe unten).

Wie ein 503-Fehler aussieht

Die Meldung verrät, welche Ebene geantwortet hat. Hier die häufigsten, mit der Software, die sie ausgibt:

Egal wie die Meldung lautet, die Aussage ist dieselbe: Diese Anfrage kann gerade nicht bedient werden, und die in der Tabelle genannte Ebene ist der Ort, an dem Sie nachsehen müssen.

Häufige Ursachen des HTTP-Fehlers 503

Die üblichen Gründe, warum ein Server oder eine Ebene davor 503 zurückgibt:

• Überlastung — CPU-, Speicher- oder Verbindungslimits sind bei einer Traffic-Spitze, einem viralen Beitrag oder einem aggressiven Crawler erreicht
• Geplante Wartung — die Website ist absichtlich offline für ein Update oder eine Migration; richtig gemacht, mit einem Retry-After-Header
• Kein funktionierendes Backend — Load Balancer, Proxy oder Ingress haben keinen funktionierenden Server, an den sie die Anfrage senden könnten (abgestürzte App, fehlgeschlagene Health Checks, keine bereiten Pods)
• Rate- oder Verbindungslimits — limit_req und limit_conn von nginx antworten standardmäßig mit 503, daher kann ein aktiver Client oder Crawler ihn auslösen
• Eine abgestürzte oder gestoppte Anwendung — PHP-FPM, Node.js oder Python steht hinter einem laufenden Webserver still; unter IIS ein gestoppter Anwendungspool
• Ressourcenlimits des Hostings — Shared Hosting begrenzt CPU, Speicher und Prozesse pro Account
• Ein Plugin, Theme oder Update — bei WordPress und anderen CMS kann ein fehlerhaftes Update die App abstürzen lassen oder die Seite im Wartungsmodus festhalten
• Ein Angriff — eine DDoS-Attacke oder Bot-Flut erschöpft dieselben Ressourcen wie eine Traffic-Spitze

Lösung für Besucher: Was Sie tun können

Wenn Sie die Seite eines anderen besuchen, liegt das Problem bei ihm. Das können Sie tun:

• Warten und erneut versuchen — ein 503 ist als vorübergehend gedacht; warten Sie eine Minute und laden Sie die Seite einmal neu. Zeigt die Seite eine Retry-After-Zeit oder eine Wartungsmeldung, warten Sie so lange
• Prüfen, ob die Seite für alle down ist — DNS Robots Website-Down-Checker testet die Seite von außerhalb Ihres Netzwerks
• Statusseite oder Social-Media-Kanäle der Website ansehen — geplante Wartungen und Ausfälle werden meist angekündigt
• Ein anderes Netzwerk probieren — lädt die Seite über mobile Daten, antwortet entweder ein VPN oder Proxy in Ihrem üblichen Netzwerk mit dem 503, oder die Website begrenzt die Anfragen Ihrer IP-Adresse

Lösung 1: Herausfinden, welche Ebene den 503 gesendet hat

Bevor Sie etwas neu starten, sehen Sie sich die Meldung und die Antwort-Header an: Sie verraten, welche Ebene geantwortet hat. Prüfen Sie von außen mit DNS Robots HTTP-Header-Checker oder curl -sI und achten Sie auf den server-Header und den Text der Seite (siehe Tabelle oben).

Starten Sie dann die Ebene neu, die ausfällt, nicht nur den Webserver:

# Restart Nginx
sudo systemctl restart nginx

# Restart Apache
sudo systemctl restart apache2      # Debian/Ubuntu
sudo systemctl restart httpd         # CentOS/RHEL

# Restart PHP-FPM
sudo systemctl restart php8.2-fpm    # Adjust version as needed

# Restart Node.js (PM2)
pm2 restart all

# Restart entire server (last resort)
sudo reboot

Kehrt der 503 innerhalb weniger Minuten nach einem Neustart zurück, besteht die Ursache weiter: Gehen Sie zu Ressourcen und Logs über.

Lösung 2: Serverressourcen prüfen (CPU, RAM, Festplatte)

Wenn der Server überlastet ist, bringt ein Neustart nur vorübergehend Abhilfe. Prüfen Sie, was die Ressourcen verbraucht.

# Check CPU and memory usage
top -bn1 | head -20

# Check disk space
df -h

# Check memory in detail
free -m

# Check active connections
ss -s

# Find processes using the most memory
ps aux --sort=-%mem | head -10

# Find processes using the most CPU
ps aux --sort=-%cpu | head -10

Wenn CPU oder RAM bei 90 % oder mehr liegen, müssen Sie Ihre Anwendung optimieren, unkontrollierte Prozesse beenden oder Ihren Server aufrüsten. Wenn der Festplattenspeicher voll ist, bereinigen Sie Log-Dateien, alte Backups oder temporäre Dateien.

Lösung 3: Fehlerprotokolle prüfen

Logs verraten Ihnen genau, warum der 503 auftrat. Lesen Sie die letzten Zeilen mit den folgenden Befehlen und suchen Sie darin nach diesen Einträgen:

# Nginx error log
tail -50 /var/log/nginx/error.log

# Apache error log
tail -50 /var/log/apache2/error.log      # Debian/Ubuntu
tail -50 /var/log/httpd/error_log         # CentOS/RHEL

# PHP-FPM log
tail -50 /var/log/php8.2-fpm.log

# WordPress debug log (if WP_DEBUG_LOG is enabled)
tail -50 /var/www/html/wp-content/debug.log

# System log
tail -50 /var/log/syslog

„limiting requests“ oder „limiting connections“ (nginx) — limit_req oder limit_conn hat die Anfrage abgelehnt; es antwortet mit 503, solange Sie nicht limit_req_status oder limit_conn_status setzen.

„max_children“ (PHP-FPM, z. B. „server reached pm.max_children setting“) — alle PHP-Worker sind belegt: Apache antwortet dann mit 503, nginx mit 502 oder 504.

„AH01114“ / „failed to make connection to backend“ (Apache mod_proxy) — Apache konnte das Backend nicht erreichen und antwortete mit 503.

„Too many connections“ (MySQL) — das Verbindungslimit der Datenbank ist erschöpft.

nginx' „no live upstreams“ und „upstream timed out“ gehören zu 502 Bad Gateway und 504 Gateway Timeout, nicht zu 503.

Lösung 4: Plugins und Themes deaktivieren (WordPress / CMS)

Bei WordPress und anderen CMS kann ein ressourcenhungriges Plugin PHP-Worker oder die Ressourcenlimits Ihres Hosters ausschöpfen, was einen 503 ergibt (ein Plugin, das abstürzt, ergibt stattdessen einen 500). Begann der 503 nach einem Plugin-Update oder einer Installation, beginnen Sie mit diesem Plugin.

Wenn Sie keinen Zugriff auf das WordPress-Dashboard haben, deaktivieren Sie Plugins über das Dateisystem oder die Datenbank.

# Disable all plugins by renaming the plugins folder
cd /var/www/html/wp-content
mv plugins plugins_disabled

# If the site loads, rename it back and re-enable plugins one by one
mv plugins_disabled plugins

# To disable a single plugin
mv plugins/problem-plugin plugins/problem-plugin.disabled

Nachdem Sie das fehlerhafte Plugin identifiziert haben, aktualisieren Sie es, ersetzen Sie es durch eine Alternative oder kontaktieren Sie den Plugin-Entwickler. Überprüfen Sie auch, ob Ihre PHP-Version kompatibel ist — einige Plugins funktionieren nicht mehr, wenn der Server PHP aktualisiert.

Hängt die Seite bei „Briefly unavailable for scheduled maintenance“? WordPress legt bei Updates eine .maintenance-Datei im Stammverzeichnis der Seite an und ignoriert sie, sobald sie älter als 10 Minuten ist. Löschen Sie sie, um früher wieder online zu sein; bleibt die Meldung, suchen Sie nach einer Datei wp-content/maintenance.php oder einer zwischengespeicherten Kopie der Seite.

Lösung 5: PHP- und Serverlimits erhöhen

Wenn Ihrem Server die PHP-Worker ausgehen oder er an Speicherlimits stößt, müssen Sie die Limits in der Konfiguration erhöhen.

; PHP-FPM pool (e.g. /etc/php/8.2/fpm/pool.d/www.conf); the default ships with pm.max_children = 5
pm = dynamic
pm.max_children = 50
pm.start_servers = 10
pm.min_spare_servers = 5
pm.max_spare_servers = 20
pm.max_requests = 500

; php.ini (defaults: memory_limit = 128M, max_execution_time = 30)
memory_limit = 256M
max_execution_time = 300

Starten Sie PHP-FPM danach neu (sudo systemctl restart php8.2-fpm, mit Ihrer Version), damit die neuen Limits geladen werden.

Lösung 6: CDN oder Load Balancer prüfen

Wenn Sie Cloudflare, ein anderes CDN oder einen Load Balancer nutzen, kann der 503 von dort statt von Ihrem Server kommen.

Cloudflares Regel (der 503-Leitfaden von Cloudflare):

• Die Seite enthält „cloudflare“ oder „cloudflare-nginx“ — Cloudflare hat sie erzeugt: Prüfen Sie, ob ein Worker seine CPU- oder Speicherlimits überschreitet, und wenden Sie sich dann mit der Ausgabe von /cdn-cgi/trace an den Cloudflare-Support
• Kein Cloudflare-Hinweis — Ihr Ursprungsserver hat den 503 geliefert und Cloudflare hat ihn weitergereicht: Prüfen Sie die Logs des Ursprungsservers und fragen Sie Ihren Hoster, ob er die IP-Adressen von Cloudflare drosselt

Bei HAProxy, einem Cloud-Load-Balancer oder einem Kubernetes-Ingress prüfen Sie die Backends: Ein 503 bedeutet dort meist, dass kein Backend die Anfrage annehmen konnte (bei einem AWS Application Load Balancer, dass die Zielgruppe keine registrierten Ziele hat). DNS Robots DNS Lookup bestätigt, dass Ihre Domain noch dorthin zeigt, wo Sie es erwarten.

Lösung 7: Auf DDoS- oder Bot-Angriffe prüfen

Ein plötzlicher Anstieg des Traffics durch Bots oder ein DDoS-Angriff kann Ihren Server überlasten. Prüfen Sie Ihre Zugriffsprotokolle auf verdächtige Muster.

# Count requests per IP in the last 1000 lines
tail -1000 /var/log/nginx/access.log | awk '{print $1}' | sort | uniq -c | sort -rn | head -20

# Requests per minute (use -f1-4 for per second)
awk '{print $4}' /var/log/nginx/access.log | cut -d: -f1-3 | uniq -c | sort -rn | head -10

# Block an abusive IP (-I puts the rule first, before any ACCEPT rules)
sudo iptables -I INPUT -s 1.2.3.4 -j DROP

# Or in nginx's server block:
# deny 1.2.3.4;

Sendet eine Adresse oder ein kleiner Bereich Tausende von Anfragen, sperren Sie sie in der Firewall. Hinter Cloudflare oder einem anderen CDN sorgen Sie zuerst dafür, dass Ihre Logs die echte Besucher-IP zeigen (set_real_ip_from plus real_ip_header CF-Connecting-IP in nginx), sonst sperren Sie das CDN statt des Angreifers. Bei einem großen Angriff filtern Cloudflares Modus „I'm Under Attack“ oder der DDoS-Schutz Ihres Hosters den Traffic, bevor er Sie erreicht.

Lösung 8: Datenbankverbindungsprobleme beheben

Wenn der Datenbank die Verbindungen ausgehen oder sie stoppt, kann die Anwendung davor ausfallen. Manche Apps antworten mit 503; WordPress zeigt stattdessen „Error establishing a database connection“. Prüfen Sie die Datenbank direkt:

# Check if MySQL/MariaDB is running (the unit is mysqld on RHEL, mariadb for MariaDB)
sudo systemctl status mysql

# Restart MySQL
sudo systemctl restart mysql

# Check current connections vs limit
mysql -e "SHOW STATUS LIKE 'Threads_connected';"
mysql -e "SHOW VARIABLES LIKE 'max_connections';"

# Increase max connections (temporary)
mysql -e "SET GLOBAL max_connections = 200;"

# Check for long-running queries
mysql -e "SHOW PROCESSLIST;" | head -20

Wenn Sie viele schlafende Verbindungen sehen, schließt Ihre Anwendung Datenbankverbindungen nicht ordnungsgemäß. Wenn lang laufende Abfragen andere blockieren, optimieren Sie diese Abfragen oder beenden Sie sie, um die Datenbank zu entlasten.

Lösung 9: Hosting-Anbieter kontaktieren

Wenn Sie Shared Hosting, Managed WordPress-Hosting oder eine Plattform wie Squarespace, Wix oder Shopify nutzen, haben Sie möglicherweise keinen Zugriff auf Serverprotokolle und können keine Dienste neu starten. In diesen Fällen kann der 503-Fehler durch die Infrastruktur des Hosting-Anbieters verursacht werden.

Kontaktieren Sie den Support Ihres Hosting-Anbieters und geben Sie an:

• Die genaue URL, die 503 zurückgibt
• Wann der Fehler aufgetreten ist — notieren Sie Datum und Uhrzeit
• Was sich geändert hat — haben Sie ein Plugin installiert, ein Theme aktualisiert oder DNS-Einstellungen geändert?
• Ob der Fehler sporadisch oder dauerhaft auftritt — sporadische 503-Fehler deuten auf Ressourcenlimits hin; dauerhafte 503-Fehler deuten auf einen Absturz oder eine Fehlkonfiguration hin

503 im Vergleich zu anderen HTTP-Fehlern

Der 503-Fehler wird oft mit anderen Serverfehlern verwechselt. So unterscheiden sie sich.

Der entscheidende Unterschied: Ein 503 ist als vorübergehend gedacht, und ein Retry-After-Header kann angeben, für wie lange. Beim Crawling behandelt Google 5xx- und 429-Fehler gleich: Seine Crawler werden langsamer, und indexierte URLs bleiben eine Weile erhalten, werden aber schließlich entfernt, wenn die Fehler anhalten (Google Search Central).

Zu den proxyseitigen Fehlern siehe 502 Bad Gateway und 504 Gateway Timeout; zu Rate-Limits 429 Too Many Requests.

So verhindern Sie 503-Fehler

Vorbeugung ist besser als Brandbekämpfung. Hier sind bewährte Methoden, um 503-Fehler zu vermeiden.

• Serverressourcen überwachen — Richten Sie Benachrichtigungen für CPU > 80 %, RAM > 85 % und Festplatte > 90 % ein. Tools wie UptimeRobot, Pingdom oder Grafana bieten sofortige Warnmeldungen.
• Ein CDN verwenden — Cloudflare, Fastly oder AWS CloudFront speichern statische Ressourcen zwischen und fangen Traffic-Spitzen ab, wodurch die Last auf dem Ursprungsserver reduziert wird.
• Caching aktivieren — Verwenden Sie Redis, Memcached oder Varnish, um Datenbankabfragen und gerenderte Seiten zwischenzuspeichern. WordPress-Nutzer: Installieren Sie ein Caching-Plugin wie WP Super Cache oder W3 Total Cache.
• Auto-Scaling einrichten — Wenn Sie Cloud-Hosting (AWS, GCP, Azure, DigitalOcean) nutzen, konfigurieren Sie Auto-Scaling, um bei Traffic-Spitzen automatisch weitere Server hinzuzufügen.
• Bots begrenzen — Konfigurieren Sie Nginx oder Cloudflare, um aggressive Crawler und Scraper zu drosseln, bevor sie Ihren Server überlasten.
• Datenbankabfragen optimieren — langsame Abfragen halten Verbindungen und Worker belegt. Fügen Sie Indizes hinzu, optimieren Sie Joins und speichern Sie Ergebnisse in Redis oder Memcached zwischen.
• Eine korrekte Wartungsseite verwenden — Geben Sie bei Deployments 503 mit einem Retry-After-Header zurück, anstatt den Server abstürzen zu lassen. Das bewahrt SEO und informiert die Nutzer.
• Software aktuell halten — Aktualisieren Sie CMS, Plugins, PHP und Datenbank auf die neuesten stabilen Versionen, um bekannte Bugs und Sicherheitslücken zu vermeiden.