Cloudflare 521 Web Server Is Down: Reale Docker-Portainer-, Nginx- und SSL-Lösung

Laut aktueller Cloudflare-Dokumentation entsteht 521, wenn der Origin-Webserver Verbindungen von Cloudflare ablehnt. Häufige Ursachen sind ein nicht laufender Origin-Webserver oder blockierte Cloudflare-Anfragen.

Bei Full oder Full (strict) verbindet Cloudflare den Origin per HTTPS. Der Origin muss deshalb aktiv HTTPS anbieten. In unserem realen Portainer-Fall lief das Backend auf 9443, aber die öffentliche Reverse-Proxy-/443-Schicht war noch nicht bereit.

Cloudflare Edge → Origin :443 → connection refused → 521

Ist Portainer selbst down, zuerst den Container reparieren. Liefert localhost 9443 während 521 jedoch HTTP 200, ist das Backend gesund und das Problem liegt höher: Nginx, TLS, Firewall oder Cloudflare-Origin-Pfad.

Diese Trennung verhindert den unsicheren Workaround, Port 9443 öffentlich zu öffnen. Wir ließen 9443 lokal und ergänzten Nginx.

docker ps --filter name='^/portainer$'

curl -k -I https://127.0.0.1:9443

Vor tieferer 521-Analyse prüfen, ob der Hostname auf den gewünschten Origin auflöst. Ein falscher A/AAAA-Record führt zu Port- und Firewall-Prüfungen auf dem falschen Server.

Wir prüften portainer.ekasunucu.com über Cloudflare- und Google-DNS. DNS-only kann während der Diagnose direkten Origin-Zugriff vereinfachen, ist aber kein allgemeines Muss für Zertifikate.

dig +short A portainer.ekasunucu.com @1.1.1.1

dig +short A portainer.ekasunucu.com @8.8.8.8

Cloudflare weist bei 521 darauf hin, dass bei Full/Full (strict) die Origin-Anwendung aktiv auf dem benötigten HTTPS-Port lauschen muss. Für normales HTTPS ist das Port 443.

Portainer selbst lief nur lokal auf 9443. Cloudflare kann dieses private Backend nicht direkt verwenden; es brauchte einen öffentlichen Origin-Webserver auf 443.

ss -lntp | grep -E ':443|:9443'

Statt Port 9443 öffentlich zu machen, wurde Nginx als Origin-Webserver eingesetzt. portainer.ekasunucu.com wird an https://127.0.0.1:9443 weitergeleitet.

Da Portainer lokal ein selbstsigniertes Zertifikat nutzt, gilt proxy_ssl_verify off nur für diesen localhost-Hop. Öffentliches Origin-TLS wird mit Let's Encrypt in Nginx terminiert.

apt-get update && apt-get install -y nginx

proxy_pass https://127.0.0.1:9443;

proxy_ssl_verify off;

Für die Portainer-Weboberfläche sollten Proxy- und WebSocket-Upgrade-Header erhalten bleiben. Wir leiteten HTTP/1.1, Upgrade, Connection, Host und X-Forwarded weiter.

Das ist von der grundlegenden 521-Verbindungsablehnung getrennt. Verschwindet 521, aber Live-Verbindungen funktionieren nicht, Proxy-Header prüfen.

proxy_http_version 1.1;

proxy_set_header Host $host;

proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

proxy_set_header Upgrade $http_upgrade;

proxy_set_header Connection $connection_upgrade;

Lokale Origin-Tests vor erneuter Cloudflare-Aktivierung verkürzen die Fehlersuche. nginx -t, Service-Status und ein Host-Header-Request prüfen getrennte Ebenen.

Nach Einrichtung unseres Reverse Proxys lieferte der lokale Nginx-Request 200. Damit funktionierten Portainer-Backend und Nginx unabhängig von Cloudflare.

nginx -t

systemctl is-active nginx

curl -sS -o /dev/null -w '%{http_code}\n' -H 'Host: portainer.ekasunucu.com' http://127.0.0.1/

Während der Let's-Encrypt-Phase lief der reale Certbot-snap-Download von core24 in einen TCP-Timeout. Das war kein Fortsetzen des 521-Problems, sondern ein separates ausgehendes Netzwerkproblem zum Snap-CDN.

Nach Erholung der Netzwerkverbindung funktionierte der erneute Certbot-Versuch. Mehrere Fehler nicht ohne Beweis derselben Ursache zuordnen.

snap install certbot --classic

snap changes

journalctl -u snapd --no-pager -n 100

Nach funktionierendem Nginx-HTTP-vHost holte Certbot --nginx das Zertifikat für portainer.ekasunucu.com. Danach konnte der Origin auf 443 ein gültiges Zertifikat ausliefern.

Damit sind die Kernvoraussetzungen für zertifikatsvalidierende Cloudflare-Modi erfüllt: HTTPS auf 443, nicht abgelaufenes Zertifikat und Hostname-Match.

certbot --nginx -d portainer.ekasunucu.com

curl -I https://portainer.ekasunucu.com

certbot renew --dry-run

Cloudflare empfiehlt aktuell Full (strict), wenn möglich. Dabei wird Edge-to-Origin verschlüsselt und das Origin-Zertifikat auf Gültigkeit und Hostname geprüft.

Ein öffentlich vertrauenswürdiges Zertifikat wie Let's Encrypt kann diese Anforderungen erfüllen. Vor Full (strict) Origin-443 und Zertifikatkette testen, sonst können andere SSL-Fehler entstehen.

Visitor HTTPS → Cloudflare → HTTPS + certificate validation → Nginx origin :443

Unser Fall war der fehlende Origin-Reverse-Proxy, aber Cloudflare nennt blockierte Cloudflare-Anfragen ebenfalls als häufige 521-Ursache. Firewalls, Rate Limits oder Security-Software können legitime Cloudflare-Verbindungen ablehnen.

Ist Nginx auf 443 gesund und direkte Origin-Tests funktionieren, aber 521 bleibt, Firewall, fail2ban, CSF/LFD, Rate Limits oder Provider-Sicherheitslayer prüfen. Offizielle aktuelle Cloudflare-IP-Ranges verwenden.

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

journalctl -u nginx --no-pager -n 100

iptables -S

nft list ruleset

521 bedeutet, dass der Origin die Cloudflare-Verbindung ablehnt. 522 ist ein Verbindungs-Timeout. 525 bedeutet SSL-Handshake-Fehler, 526 ein ungültiges Origin-Zertifikat bei Zertifikatsvalidierung.

Damit ändert sich die Diagnose: Webserver/Listener/Firewall bei 521, Erreichbarkeit/Timeout bei 522 und TLS/Zertifikatskette bei 525/526.

521 → connection refused / origin down

522 → origin connection timeout

525 → SSL handshake failed

526 → invalid SSL certificate

Die schnellste Methode trennt die Ebenen nacheinander: DNS, lokales Backend, Nginx-Konfiguration/Service, 443-Listener und zuletzt echte HTTPS-Domain.

521 nicht durch öffentliches Freigeben des Backend-Ports lösen. Stattdessen die korrekte Origin-Webserver-Schicht vervollständigen.

dig +short A portainer.ekasunucu.com

curl -k -I https://127.0.0.1:9443

nginx -t && systemctl is-active nginx

ss -lntp | grep -E ':443|:9443'

curl -I https://portainer.ekasunucu.com

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