Wie man den Cloudflare-Fehler 520 behebt: Vollständiger Diagnose- und Lösungsleitfaden

Cloudflare Error 520 ist ein HTTP-Statuscode, der zurückgegeben wird, wenn Cloudflares Edge-Netzwerk eine leere, unerwartete oder anderweitig nicht interpretierbare Antwort von Ihrem Ursprungsserver erhält. Im Gegensatz zu einem 502 oder 504, die einen Gateway-Timeout oder einen fehlerhaften Gateway anzeigen, ist ein 520 Cloudflares Auffangfehler für Antworten, die außerhalb jeder anerkannten HTTP-Spezifikation liegen – was bedeutet, dass der Ursprungsserver technisch gesehen geantwortet hat, aber das Zurückgesendete ungültig, abgeschnitten oder strukturell fehlerhaft war.

Aus praktischer Sicht bedeutet Error 520, dass die TCP-Verbindung zwischen Cloudflare und Ihrem Ursprungsserver hergestellt wurde, aber der HTTP-Layer-Handshake fehlgeschlagen ist. Der Benutzer sieht eine Cloudflare-Fehlerseite mit der Meldung "Web server is returning an unknown error" – und Ihre Website ist für ihn effektiv offline.

Was Error 520 auslöst: Grundursachen erklärt

Das Verständnis des genauen Fehlermodus ist unerlässlich, bevor Sie eine Konfiguration ändern. Error 520 ist kein einzelnes Problem – es ist eine Symptomklasse. Die folgenden Ursachen sind die häufigsten, geordnet nach Häufigkeit in Produktionsumgebungen.

Ursprungsserver gibt einen leeren Antwort-Body ohne HTTP-Statuszeile zurück. Dies ist der häufigste Auslöser. Apache oder Nginx kann mitten in einer Antwort abstürzen und Cloudflare mit einem offenen TCP-Socket ohne eintreffende Daten zurücklassen.

Firewall oder Sicherheitssoftware blockiert Cloudflares IP-Bereiche. Tools wie ModSecurity, Fail2Ban, CSF (ConfigServer Security & Firewall) oder Plugins auf Anwendungsebene wie Wordfence können Pakete von Cloudflares Ausgangs-IPs stillschweigend verwerfen, wodurch die Verbindung ohne eine ordnungsgemäße HTTP-Antwort zurückgesetzt wird.

SSL/TLS-Handshake-Mismatch zwischen Cloudflare und dem Ursprung. Wenn Cloudflare auf den Modus „Full (Strict)” eingestellt ist, Ihr Ursprungsserver jedoch ein abgelaufenes, selbstsigniertes oder falsch konfiguriertes Zertifikat hat, schlägt die TLS-Aushandlung fehl, bevor HTTP-Daten ausgetauscht werden.

Fehlerhafte oder überdimensionierte HTTP-Antwort-Header. Cloudflare erzwingt ein hartes Limit von 32 KB für Antwort-Header. Jeder einzelne Header oder kombinierte Header-Satz, der dieses Limit überschreitet, verursacht einen 520. Dies ist ein häufiger Grenzfall bei schlecht geschriebenen PHP-Anwendungen, die große Sitzungsdaten oder Debug-Ausgaben in Header schreiben.

Absturz des Ursprungsserver-Prozesses oder OOM (Out-of-Memory) Kill. Wenn der Webserver-Worker-Prozess (z. B. ein Nginx-Worker oder PHP-FPM-Pool) mitten in einer Anfrage vom Linux-OOM-Killer beendet wird, bricht die Verbindung abrupt ab.

Ausnahmen auf Anwendungsebene, bevor Header gesendet werden. Ein fataler PHP-Fehler, eine unbehandelte Python-Ausnahme oder ein Node.js-Absturz, der auftritt, bevor res.writeHead() aufgerufen wird, führt zu einer leeren Antwort, die Cloudflare nicht parsen kann.

Verbindungsreset durch Ursprung (TCP RST). Der Ursprungsserver setzt die TCP-Verbindung aktiv zurück, was Cloudflare als unbekannte Antwort interpretiert.

Error 520 vs. andere Cloudflare 5xx-Fehler

Die Unterscheidung von 520 von ähnlichen Cloudflare-Fehlern verhindert verschwendeten Diagnoseaufwand.

Wenn Sie 521 sehen, läuft Ihr Webserver-Prozess nicht. Wenn Sie 524 sehen, läuft Ihre Anwendung, ist aber zu langsam. Wenn Sie 520 sehen, läuft der Server und antwortet – aber was er zurücksendet, ist fehlerhaft.

Schritt-für-Schritt-Lösung für Error 520

Schritt 1: Ursprungsserver-Zustand und Konnektivität überprüfen

Bevor Sie Cloudflare anfassen, bestätigen Sie, dass der Ursprungsserver aktiv ist und der Webserver-Daemon läuft.

Überprüfen Sie, ob der Webserver-Prozess aktiv ist:

# For Nginx
sudo systemctl status nginx

# For Apache
sudo systemctl status apache2

# For LiteSpeed
sudo systemctl status lsws

Testen Sie die direkte Konnektivität zur Ursprungs-IP und umgehen Sie dabei Cloudflares Proxy. Rufen Sie Ihre Ursprungs-IP aus dem Cloudflare-DNS-Dashboard ab und testen Sie sie dann direkt:

curl -I --resolve yourdomain.com:80:YOUR_ORIGIN_IP http://yourdomain.com/
curl -I --resolve yourdomain.com:443:YOUR_ORIGIN_IP https://yourdomain.com/

Wenn curl einen gültigen HTTP-Status zurückgibt (200, 301 usw.), ist der Ursprungsserver funktionsfähig und das Problem liegt in der Kommunikationsschicht zwischen Cloudflare und dem Ursprung. Wenn curl eine leere Antwort oder einen Verbindungsreset zurückgibt, liegt das Problem auf der Ursprungsseite.

Systemressourcendruck überprüfen:

# Memory usage
free -h

# CPU load
uptime

# Check for OOM kills in the last boot
dmesg | grep -i "oom|killed process"

# Check for PHP-FPM pool exhaustion
sudo systemctl status php8.1-fpm

Schritt 2: Fehlerprotokolle des Ursprungsservers untersuchen

Die Protokolle des Ursprungsservers sind die wertvollste einzelne Diagnosequelle. Überspringen Sie diesen Schritt nicht.

Für Nginx:

sudo tail -n 100 /var/log/nginx/error.log
sudo tail -n 100 /var/log/nginx/access.log

Für Apache:

sudo tail -n 100 /var/log/apache2/error.log
sudo tail -n 100 /var/log/apache2/access.log

Achten Sie insbesondere auf:

• [crit]– oder [emerg]-Level-Einträge
• upstream prematurely closed connection (Nginx + PHP-FPM)
• Premature end of script headers (Apache + CGI/PHP)
• worker_connections are not enough (Nginx-Worker-Limit erreicht)
• PHP-Fehler, die im Webserver-Fehlerprotokoll protokolliert werden

Vergleichen Sie Protokoll-Zeitstempel mit dem Zeitpunkt, zu dem die 520-Fehler aufgetreten sind. Cloudflares Dashboard unter Analytics > Traffic zeigt Zeitstempel von 520-Spitzen, die Sie zur Korrelation verwenden können.

Schritt 3: Cloudflare-IP-Bereiche in Ihrer Firewall auf die Whitelist setzen

Wenn eine Firewall Cloudflares Ausgangs-IPs blockiert, wird die Verbindung stillschweigend zurückgesetzt. Cloudflare veröffentlicht seine aktuellen IP-Bereiche unter https://www.cloudflare.com/ips/.

Für UFW (Ubuntu/Debian):

# Download Cloudflare IPv4 ranges and whitelist them
for ip in $(curl -s https://www.cloudflare.com/ips-v4); do
  sudo ufw allow from $ip to any port 80,443 proto tcp
done

# Repeat for IPv6
for ip in $(curl -s https://www.cloudflare.com/ips-v6); do
  sudo ufw allow from $ip to any port 80,443 proto tcp
done

sudo ufw reload

Für CSF (ConfigServer Firewall):

Fügen Sie Cloudflares IP-Bereiche zu /etc/csf/csf.allow hinzu und starten Sie dann CSF neu:

sudo csf -r

Für ModSecurity: Wenn Sie vermuten, dass ModSecurity der Verursacher ist, überprüfen Sie das Audit-Protokoll:

sudo tail -n 200 /var/log/modsec_audit.log

Suchen Sie nach Regelübereinstimmungen mit Cloudflare-IP-Adressen. Sie können Cloudflare-IPs in Ihrer ModSecurity-Konfiguration auf die Whitelist setzen oder die Direktive SecRemoteRules verwenden, um sie auszuschließen.

Wichtiger Hinweis: Deaktivieren Sie niemals dauerhaft Ihre Firewall oder ModSecurity. Setzen Sie nur Cloudflares veröffentlichte IP-Bereiche auf die Whitelist und aktivieren Sie alle Sicherheitskontrollen sofort nach dem Testen wieder.

Schritt 4: HTTP-Antwort-Header prüfen und korrigieren

Fehlerhafte oder überdimensionierte Header sind eine häufig übersehene Ursache für 520-Fehler. Verwenden Sie curl mit ausführlicher Ausgabe, um genau zu überprüfen, was Ihr Ursprung sendet:

curl -v --resolve yourdomain.com:443:YOUR_ORIGIN_IP https://yourdomain.com/ 2>&1 | head -80

Achten Sie auf:

• Header mit Nicht-ASCII-Zeichen oder Steuerzeichen
• Set-Cookie-Header mit extrem langen Werten (häufig bei PHP-Sitzungsfehlkonfigurationen)
• Fehlende oder fehlerhafte Content-Type-Header
• Doppelte Content-Length-Header mit widersprüchlichen Werten

Wenn Sie eine PHP-Anwendung betreiben, überprüfen Sie php.ini auf output_buffering-Einstellungen. Ein deaktivierter Ausgabepuffer in Kombination mit einem fatalen Fehler mitten in einer Antwort kann zu einer teilweisen Header-Übertragung führen.

Speziell für WordPress-Websites: Plugins, die große Datenmengen in HTTP-Header einfügen (einige Sicherheits- oder Caching-Plugins tun dies), können die Header-Größe über Cloudflares 32-KB-Limit hinaus treiben. Überprüfen Sie aktive Plugins und testen Sie im abgesicherten Modus.

Schritt 5: Cloudflare SSL/TLS-Konfiguration validieren

Ein SSL-Mismatch zwischen Cloudflare und dem Ursprung ist eine häufige Quelle von 520-Klasse-Fehlern, die sich als generischer unbekannter Fehler tarnt.

Navigieren Sie zu Cloudflare Dashboard > SSL/TLS > Overview und überprüfen Sie den Verschlüsselungsmodus:

Wenn Ihr Ursprung ein selbstsigniertes Zertifikat verwendet und Cloudflare auf Full (Strict) eingestellt ist, schlägt der TLS-Handshake fehl. Installieren Sie entweder ein gültiges Zertifikat am Ursprung (ein kostenloses Let’s Encrypt-Zertifikat funktioniert) oder wechseln Sie vorübergehend in den Full-Modus, während Sie das Zertifikat reparieren.

Wenn Sie ein ordnungsgemäß vertrauenswürdiges Zertifikat für Ihren Ursprungsserver benötigen, eliminieren SSL-Zertifikate von einer vertrauenswürdigen CA das Problem mit selbstsignierten Zertifikaten vollständig und sind mit Cloudflares Full (Strict)-Modus kompatibel.

Schritt 6: Cloudflare-Proxy für gezielte Diagnose pausieren

Das vorübergehende Entfernen von Cloudflare aus dem Anfragepfad isoliert, ob das Problem in Cloudflares Konfiguration oder auf dem Ursprungsserver liegt.

Methode 1: Proxy für einen bestimmten DNS-Eintrag deaktivieren

Klicken Sie im Cloudflare-DNS-Dashboard auf das orangefarbene Cloud-Symbol neben Ihrem A- oder CNAME-Eintrag, um es grau zu machen. Dies umgeht Cloudflares Proxy, während die DNS-Auflösung über Cloudflare erhalten bleibt. Die DNS-Propagation dauert bis zu 5 Minuten.

Methode 2: Cloudflare global für die Domain pausieren

Navigieren Sie zu Cloudflare Dashboard > Overview > Advanced Actions > Pause Cloudflare on Site. Dies leitet den gesamten Datenverkehr direkt zu Ihrem Ursprung.

Testen Sie Ihre Website nach dem Pausieren. Wenn sie korrekt lädt, liegt das Problem in Cloudflares Konfiguration. Wenn sie immer noch fehlschlägt, liegt das Problem unabhängig von Cloudflare auf dem Ursprungsserver.

Aktivieren Sie Cloudflare sofort nach dem Testen wieder – ein pausiertes Cloudflare bedeutet, dass Ihre Website den DDoS-Schutz, CDN-Caching und WAF-Abdeckung verliert.

Schritt 7: DNS-Eintragsgenauigkeit überprüfen

Ein falsch konfigurierter DNS-A-Eintrag, der auf eine falsche oder veraltete IP-Adresse zeigt, veranlasst Cloudflare, Datenverkehr an den falschen Server zu proxyen, der eine unerwartete Antwort zurückgibt.

Im Cloudflare-DNS-Dashboard:

• Überprüfen Sie, ob der A-Eintrag für Ihre Root-Domain (@) auf Ihre aktuelle Ursprungsserver-IP zeigt
• Überprüfen Sie, ob der CNAME für www korrekt aufgelöst wird
• Wenn Sie kürzlich Server migriert haben, bestätigen Sie, dass die alte IP nirgendwo mehr referenziert wird

Bestätigen Sie, an welche IP Cloudflare tatsächlich Datenverkehr sendet:

dig +short yourdomain.com @1.1.1.1

Vergleichen Sie dies mit Ihrer tatsächlichen Ursprungsserver-IP. Wenn sie sich unterscheiden, aktualisieren Sie den DNS-Eintrag in Cloudflare.

Schritt 8: Ursprungsserver-Ressourcen skalieren

Wenn Ihr Ursprungsserver dauerhaft unter hoher Last steht, treten 520-Fehler während Verkehrsspitzen sporadisch auf, wenn Worker-Prozesse erschöpft sind und Verbindungen abgebrochen werden.

Ressourcenerschöpfung diagnostizieren:

# Check Nginx worker connections
sudo nginx -T | grep worker_connections

# Check PHP-FPM pool limits
cat /etc/php/8.1/fpm/pool.d/www.conf | grep -E "pm.|max_children"

# Monitor real-time connections
ss -s

Tuning-Optionen ohne Hardware-Upgrade:

• worker_connections in /etc/nginx/nginx.conf erhöhen
• pm.max_children in der PHP-FPM-Pool-Konfiguration erhöhen
• Nginx-Direktive keepalive für Upstream-Verbindungen aktivieren
• Objekt-Caching (Redis oder Memcached) implementieren, um den Datenbankdruck zu reduzieren
• Cloudflares Cache Everything-Seitenregel aktivieren, um die Bereitstellung statischer Assets auszulagern

Für Anwendungen, die über eine gemeinsam genutzte Infrastruktur hinausgewachsen sind, gibt Ihnen die Migration zu einer VPS-Hosting-Umgebung die volle Kontrolle über Worker-Prozesslimits, Speicherzuweisung und TCP-Tuning auf Kernel-Ebene – von denen keines in gemeinsam genutzten Plänen verfügbar ist.

Wenn Ihre Anwendung rechenintensive Workloads verarbeitet (ML-Inferenz, Videoverarbeitung, große Datensatzoperationen), die intermittierende Worker-Abstürze verursachen, lagert GPU-Hosting diese Aufgaben von Ihren Webserver-Prozessen aus und eliminiert eine häufige Quelle von Abstürzen mitten in Antworten.

Schritt 9: Cloudflare-Firewall- und Sicherheitsregeln überprüfen

Cloudflares eigene Sicherheitsfunktionen können gelegentlich die legitime Ursprungskommunikation stören, insbesondere wenn benutzerdefinierte Firewall-Regeln oder WAF-Regeln falsch konfiguriert sind.

Überprüfen Sie Cloudflare Dashboard > Security > WAF > Custom Rules auf Regeln, die Anfragen abfangen könnten, bevor sie den Ursprung erreichen. Überprüfen Sie auch Security > Settings > Browser Integrity Check – in seltenen Fällen kann dies zu unerwartetem Verhalten bei bestimmten User-Agents oder automatisierten Anfragen führen.

Überprüfen Sie das Security > Events-Protokoll, um zu sehen, ob Cloudflare Anfragen blockiert oder herausfordert, die Ihren Ursprung erreichen sollten.

Schritt 10: An Ihren Hosting-Anbieter oder Cloudflare-Support eskalieren

Wenn alle oben genannten Schritte ohne Lösung erschöpft wurden, eskalieren Sie mit präzisen Informationen.

Wenn Sie Ihren Hosting-Anbieter kontaktieren, geben Sie an:

• Die genauen Zeitstempel der 520-Vorkommen (aus Cloudflare Analytics)
• Relevante Auszüge aus Ihrem Webserver-Fehlerprotokoll
• Die Ausgabe von curl -v gegen Ihre Ursprungs-IP
• Aktuelle Ressourcennutzungsmetriken (CPU, RAM, Verbindungsanzahl)

Anbieter, die verwaltete Infrastruktur auf Dedizierten Servern betreiben, können Diagnosen auf Kernel-Ebene, Paketmitschnitte (tcpdump) und Socket-Level-Inspektionen durchführen, die in gemeinsam genutzten Umgebungen nicht verfügbar sind.

Wenn Sie den Cloudflare-Support kontaktieren, fügen Sie hinzu:

• Ihre Ray-ID von der 520-Fehlerseite (sichtbar im Cloudflare-Fehler-HTML)
• Eine HAR-Datei, die während des Fehlers aus Chrome DevTools aufgezeichnet wurde
• Ihren aktuellen SSL/TLS-Modus und alle benutzerdefinierten Firewall-Regeln

Die Ray-ID ist entscheidend – sie ermöglicht es Cloudflares Ingenieuren, den genauen Edge-Node-Protokolleintrag für Ihre fehlgeschlagene Anfrage abzurufen.

Erweiterte Diagnose: Den genauen Fehler mit tcpdump erfassen

Für anhaltende oder intermittierende 520-Fehler, die der Standardfehlerbehebung widerstehen, zeigt ein Paketmitschnitt auf dem Ursprungsserver genau, was auf der TCP/HTTP-Ebene passiert, wenn Cloudflare eine Verbindung herstellt.

# Capture traffic from Cloudflare IPs on port 443
sudo tcpdump -i eth0 -w /tmp/cloudflare_capture.pcap 'src net 103.21.244.0/22 or src net 103.22.200.0/22 or src net 103.31.4.0/22 or src net 104.16.0.0/13 or src net 104.24.0.0/14' and port 443

Öffnen Sie die resultierende .pcap-Datei in Wireshark und filtern Sie nach tcp.flags.reset == 1, um TCP-RST-Pakete zu identifizieren, die darauf hinweisen, dass der Ursprung Verbindungen aktiv zurücksetzt. Filtern Sie nach http, um alle teilweisen HTTP-Antworten zu untersuchen, die gesendet werden.

Diese Analyseebene identifiziert definitiv, ob der 520 durch einen Firewall-RST, einen Anwendungsabsturz mitten in einer Antwort oder einen TLS-Fehler verursacht wird.

Error 520 verhindern: Proaktive Maßnahmen

Reaktive Fehlerbehebung ist kostspielig. Diese Maßnahmen reduzieren die Wahrscheinlichkeit des Auftretens von 520 erheblich.

Cloudflare Health Checks implementieren. Konfigurieren Sie unter Traffic > Health Checks einen Health Check gegen Ihren Ursprung. Cloudflare warnt Sie, bevor Benutzer 520-Fehler sehen.

Cloudflares Always Online-Funktion aktivieren (unter Caching > Configuration). Obwohl es das zugrunde liegende Problem nicht behebt, stellt es Benutzern während Ursprungsausfällen zwischengespeicherte Versionen Ihrer Seiten bereit und verhindert einen vollständigen Dienstausfall.

Ursprungsserver-Überwachung einrichten mit Tools wie UptimeRobot, Pingdom oder einer selbst gehosteten Lösung wie Uptime Kuma. Überwachen Sie die Ursprungs-IP direkt (nicht die Cloudflare-proxied Domain), um Ursprungsfehler unabhängig von Cloudflare zu erkennen.

Cloudflare-IP-Whitelisting automatisieren. Cloudflares IP-Bereiche ändern sich gelegentlich. Verwenden Sie einen Cron-Job, um Ihre Firewall-Whitelist zu aktualisieren:

# /etc/cron.weekly/update-cloudflare-ips
#!/bin/bash
CF_IPS=$(curl -s https://www.cloudflare.com/ips-v4)
# Add logic to update UFW/CSF/iptables rules

Cloudflares Authenticated Origin Pulls verwenden. Diese Funktion konfiguriert Ihren Ursprung so, dass er nur HTTPS-Verbindungen akzeptiert, die Cloudflares Client-Zertifikat vorlegen, und blockiert alle direkten Anfragen an den Ursprung, die den Proxy umgehen. Dies eliminiert auch eine Klasse von 520-Fehlern, die durch Nicht-Cloudflare-Datenverkehr verursacht werden, der Ihren Ursprung trifft und Sicherheitssoftware-Antworten auslöst.

Für Teams, die mehrere Domains und Webanwendungen verwalten, bietet ein VPS mit cPanel zentralisierten Protokollzugriff, Firewall-Verwaltung und SSL-Zertifikatsverwaltung für alle gehosteten Domains – was die Zeit bis zur Diagnose von 520-Ereignissen erheblich reduziert.

Entscheidungsmatrix: Ihr spezifisches 520-Szenario diagnostizieren

Technische Schlüssel-Checkliste

Bevor Sie den Support eskalieren, bestätigen Sie, dass Sie jeden der folgenden Punkte abgeschlossen haben:

• Überprüft, dass der Ursprungs-Webserver-Prozess läuft (systemctl status)
• Direkte Ursprungskonnektivität mit curl -v --resolve getestet, Cloudflare umgehend
• Ursprungs-Fehlerprotokolle für die genauen Zeitstempel der 520-Ereignisse überprüft
• Bestätigt, dass Cloudflare-IP-Bereiche in allen aktiven Firewalls auf der Whitelist stehen (UFW, CSF, iptables, ModSecurity)
• Validiert, dass Antwort-Header unter 32 KB liegen und keine fehlerhaften Werte enthalten
• Bestätigt, dass der Cloudflare-SSL/TLS-Modus mit dem Ursprungszertifikattyp übereinstimmt
• Überprüft, dass DNS-A-Einträge auf die korrekte, aktuelle Ursprungs-IP zeigen
• Systemspeicher und CPU auf OOM-Kills oder Ressourcenerschöpfung überprüft
• Die Ray-ID von der 520-Fehlerseite für die Cloudflare-Support-Eskalation erfasst
• Cloudflare Security Events-Protokoll auf WAF-Regelinterferenzen überprüft

Häufig gestellte Fragen

Was ist der Unterschied zwischen Cloudflare Error 520 und Error 521?

Error 521 bedeutet, dass Cloudflare die IP Ihres Ursprungsservers erfolgreich erreicht hat, aber der Webserver-Prozess die TCP-Verbindung abgelehnt hat – typischerweise weil Nginx oder Apache nicht läuft. Error 520 bedeutet, dass die TCP-Verbindung hergestellt wurde, aber die HTTP-Antwort leer, abgeschnitten oder fehlerhaft war. Wenn Sie 521 sehen, starten Sie Ihren Webserver. Wenn Sie 520 sehen, läuft der Server, sendet aber fehlerhafte Antworten.

Kann Error 520 durch Cloudflare selbst verursacht werden, nicht durch den Ursprungsserver?

Selten, aber ja. Probleme mit Cloudflare-Edge-Nodes können 520-Fehler verursachen, die beim direkten Zugriff auf den Ursprung nicht reproduzierbar sind. Überprüfen Sie cloudflarestatus.com auf aktive Vorfälle. Wenn der Ursprung über direktes curl korrekt antwortet und Cloudflares Statusseite einen aktiven Vorfall anzeigt, warten Sie, bis Cloudflare ihn behebt, anstatt Änderungen an Ihrem Server vorzunehmen.

Warum tritt Error 520 nur intermittierend und nicht konsistent auf?

Intermittierende 520-Fehler deuten fast immer auf Ressourcenerschöpfung hin – PHP-FPM-Worker-Pools, denen verfügbare Kinder ausgehen, Nginx, das worker_connections-Limits erreicht, oder der Linux-OOM-Killer, der Prozesse unter Speicherdruck beendet. Diese Bedingungen treten bei Lastspitzen auf und lösen sich auf, wenn der Datenverkehr abnimmt, was das intermittierende Muster erzeugt. Konsistente 520-Fehler weisen auf ein Konfigurationsproblem hin.

Behebt das Pausieren von Cloudflare Error 520?

Das Pausieren von Cloudflare entfernt es aus dem Anfragepfad. Wenn Ihre Website nach dem Pausieren funktioniert, liegt das Problem in Cloudflares Konfiguration (SSL-Modus, WAF-Regeln, DNS-Einträge). Wenn Ihre Website nach dem Pausieren immer noch fehlschlägt, liegt das Problem auf dem Ursprungsserver. Das Pausieren von Cloudflare ist ein Diagnoseschritt, keine Lösung – es entfernt den DDoS-Schutz und das CDN-Caching, solange es aktiv ist.

Wie finde ich die Ray-ID, um einen 520-Fehler an Cloudflare zu melden?

Die Ray-ID wird am unteren Rand der Cloudflare-520-Fehlerseite angezeigt, die Benutzern gezeigt wird. Sie sieht aus wie eine 16-stellige hexadezimale Zeichenkette (z. B. 7a3f2b9c1d4e8f0a). Sie finden sie auch im CF-Ray-Antwort-Header, der in Chrome DevTools unter dem Netzwerk-Tab sichtbar ist. Fügen Sie diese ID immer bei, wenn Sie ein Cloudflare-Support-Ticket öffnen – sie ermöglicht es Cloudflare-Ingenieuren, den genauen Edge-Protokolleintrag für Ihre fehlgeschlagene Anfrage abzurufen.