Türkei (Türkisch)
Germany (German)
Worldwide (English)
Ein Cloudflare Tunnel kann Healthy anzeigen, während Nutzer 502 erhalten; dann ist der Connector mit Cloudflare verbunden, cloudflared erreicht aber den lokalen Origin nicht.
Halkali Merkez Viertel Fatih Str. Ozgur Apt. No. 46, Kucukcekmece, Istanbul, 34303, TR
Cloudflare-Tunnel-x509-, Unknown-Authority- und 502-Origin-TLS-Fehler mit originServerName, caPool, Protokoll/Port und Logs diagnostizieren.
Ein Cloudflare Tunnel kann Healthy anzeigen, während Nutzer 502 erhalten; dann ist der Connector mit Cloudflare verbunden, cloudflared erreicht aber den lokalen Origin nicht.
Cloudflare dokumentiert `originServerName`, wenn der Zertifikat-Hostname nicht mit dem Service-URL-Hostname übereinstimmt.
Für private/self-signed CAs dokumentiert Cloudflare `caPool`; `noTLSVerify` ist keine empfohlene erste Produktionslösung.
Cloudflare Tunnel 1033 bedeutet, dass Cloudflare keinen gesunden Connector findet. 502 kann auftreten, obwohl der Connector online ist, aber cloudflared den konfigurierten lokalen Service nicht erreicht. Healthy plus 502 ist daher kein Widerspruch.
Das bestimmt die Diagnose: bei 1033 Connector-Prozess, Netzwerk und Credentials; bei 502 Service-URL, Port, Protokoll und Origin-TLS.
cloudflared tunnel info TUNNEL_ADIsystemctl status cloudflaredSteht `service: https://localhost:8443` in der Konfiguration, genau diese Adresse aus demselben Host/Netzwerk-Namespace wie cloudflared testen. In Docker bezeichnet localhost den Container selbst, nicht den Host.
Bei containerisiertem cloudflared muss ggf. dasselbe Docker-Netzwerk wie der Reverse Proxy verwendet und der Service-/Containername angesprochen werden. Tunnel Health beweist keine korrekte Docker-Origin-Route.
curl -vk https://localhost:8443/docker network lsdocker inspect cloudflaredSpricht der Origin auf Port 8080 nur HTTP, während `https://localhost:8080` konfiguriert ist, erwartet cloudflared TLS und kann malformed responses melden. Auch die umgekehrte Protokollverwechslung ist falsch.
Protokoll nicht nur aus der Portnummer ableiten. Mit lokalen curl-Tests feststellen, was der Service tatsächlich spricht.
curl -v http://localhost:8080/curl -vk https://localhost:8443/Ist das Zertifikat für app.internal.example.com ausgestellt, die Service-URL aber https://localhost:8443, scheitert die Hostname-Prüfung. Cloudflare dokumentiert `originServerName`, um den erwarteten Zertifikatsnamen anzugeben.
Diese Einstellung deaktiviert die Zertifikatsprüfung nicht, sondern gibt den zu prüfenden Hostnamen an. Für Produktion ist das besser als TLS-Verifikation abzuschalten.
cloudflared tunnel ingress validate`x509: certificate signed by unknown authority` ist etwas anderes als Hostname-Mismatch. Der Name kann stimmen, aber cloudflared vertraut der privaten CA nicht. Cloudflare unterstützt einen Custom-CA-Bundle-Pfad über `caPool`.
Das CA-Bundle muss Root/Intermediate im PEM-Format enthalten und für den cloudflared-Prozess/Container lesbar sein. In Docker reicht ein Host-Pfad nicht; die Datei muss in den Container gemountet werden.
openssl verify -CAfile /etc/cloudflared/origin-ca.pem origin-cert.pemCloudflare bietet das Abschalten der TLS-Verifikation an, positioniert es aber als letzte Option. Dadurch wird die Identität des Origins nicht mehr sauber geprüft.
Die dauerhafte Lösung ist ein passendes Zertifikat, `originServerName` oder eine über `caPool` vertraute private CA. Ein diagnostischer Bypass braucht klaren Grund und Rückfallplan.
Nach YAML-Änderungen Ingress-Regeln validieren, Service neu starten und Logs prüfen. Eine falsch platzierte Catch-all-Regel kann den Host trotz korrekter TLS-Einstellungen zu einem anderen Origin schicken.
Verschwindet x509, 502 bleibt aber, zu TCP-Konnektivität, Protokoll/Port und Application Response wechseln. Schichtweise weiterdiagnostizieren.
cloudflared tunnel ingress validatejournalctl -u cloudflared -n 200 --no-pager| Symptom | Priorität |
|---|---|
| Error 1033 | Ist ein gesunder Connector mit Cloudflare verbunden? |
| Healthy + 502 | cloudflared → lokaler Origin |
| x509 valid for X not Y | originServerName / Zertifikat-Hostname |
| x509 unknown authority | Private-CA-Vertrauen / caPool |
Vor Änderungen in Produktion Kontext, Backup und Rückfallplan prüfen. Bei DNS, TLS, Recovery, Docker oder WordPress nicht mehrere Variablen gleichzeitig ändern, da sonst die Ursache schwerer zu isolieren ist.
Nein. Healthy kann nur die Cloudflare-Verbindung des Connectors bestätigen; der lokale Origin kann weiterhin unerreichbar sein.
Für Produktion nicht bevorzugt. Richtiges Zertifikat/Hostname oder Private-CA-Vertrauen konfigurieren.
Im Container bezeichnet localhost denselben Container. Für anderen Container/Host korrektes Netzwerk und Service-Name/IP verwenden.
Wenn das Problem in Hosting-, VPS-, Docker-, Cloudflare-, Windows- oder WordPress-Infrastruktur weiter besteht, können Sie mit Fehlerausgabe und Architektur einen technischen Supportfall erstellen.