Türkiye (Türkçe)
Almanya (German)
Worldwide (English)
Cloudflare Tunnel 'Healthy' görünse bile kullanıcı 502 alabilir; bu durumda connector Cloudflare'a bağlıdır fakat cloudflared local origin'e ulaşamıyordur.
Halkalı merkez mahallesi fatih cd ozgur apt no 46 , Küçükçekmece , İstanbul , 34303 , TR
Cloudflare Tunnel x509, unknown authority ve 502 origin TLS hatalarını originServerName, caPool, protocol/port ve cloudflared loglarıyla teşhis edin.
Cloudflare Tunnel 'Healthy' görünse bile kullanıcı 502 alabilir; bu durumda connector Cloudflare'a bağlıdır fakat cloudflared local origin'e ulaşamıyordur.
Cloudflare, sertifika hostname'i ile service URL hostname'i uyuşmadığında `originServerName` kullanılmasını belgeler.
Private/self-signed CA için Cloudflare `caPool` ile custom CA trust yapılandırmasını belgeler; `noTLSVerify` production için önerilen ilk çözüm değildir.
Cloudflare Tunnel 1033, Cloudflare'ın o tunnel için sağlıklı connector bulamadığı duruma işaret eder. 502 ise tunnel connector Cloudflare'a ulaşmış olabilir fakat cloudflared configured local service'e bağlanamaz. Dashboard 'Healthy' iken 502 görmek bu yüzden çelişki değildir.
Bu ayrım teşhisin yönünü belirler: 1033'te connector process/network/credentials; 502'de service URL, port, protocol ve origin TLS incelenir.
cloudflared tunnel info TUNNEL_ADIsystemctl status cloudflaredTunnel config'te `service: https://localhost:8443` yazıyorsa önce cloudflared'ın çalıştığı host/container network namespace'inden aynı adrese curl yapın. Docker container içinde `localhost`, host makine değil container'ın kendisidir.
Containerized cloudflared kullanıyorsanız reverse proxy ile aynı Docker network'e bağlamak ve service URL'de container/service adını kullanmak gerekebilir. 'Tunnel healthy' bilgisi Docker içindeki origin routing'in doğru olduğunu kanıtlamaz.
curl -vk https://localhost:8443/docker network lsdocker inspect cloudflaredOrigin 8080 portunda düz HTTP konuşurken config'te `https://localhost:8080` yazarsanız cloudflared TLS handshake bekler ve malformed HTTP response/connection error görebilirsiniz. Ters durumda HTTPS servisine HTTP ile gitmek de yanlış protokoldür.
Port numarasından protokol tahmin etmeyin. Local `curl -v http://...` ve `curl -vk https://...` testleriyle servisin gerçekte ne konuştuğunu belirleyin.
curl -v http://localhost:8080/curl -vk https://localhost:8443/Origin sertifikası `app.internal.example.com` için verilmiş ama service URL `https://localhost:8443` ise TLS doğrulamasında hostname uyuşmazlığı olur. Cloudflare bu senaryoda origin request ayarındaki `originServerName` ile sertifikada beklenen hostname'in belirtilmesini belgeler.
Bu ayar sertifikanın kimlik kontrolünü kapatmaz; aksine hangi hostname'e göre doğrulanacağını açıkça belirtir. Production için `noTLSVerify` açmaktan daha doğru yaklaşımdır.
cloudflared tunnel ingress validate`x509: certificate signed by unknown authority` hostname sorunundan farklıdır. Sertifika adı doğru olabilir ancak cloudflared private CA'yı güvenilir kök olarak bilmiyordur. Cloudflare custom CA certificate bundle yolunu `caPool` üzerinden tanımlamayı destekler.
CA bundle PEM formatında doğru root/intermediate chain'i içermeli ve cloudflared process/container bu dosyayı okuyabilmelidir. Docker'da host path'i config'e yazmak yetmez; dosyanın container içine mount edilmiş olması gerekir.
openssl verify -CAfile /etc/cloudflared/origin-ca.pem origin-cert.pemCloudflare dokümanı TLS verification'ı kapatmayı seçenek olarak gösterse de production için bunu son çare olarak konumlandırır. `noTLSVerify` sertifika doğrulamasını atlayarak yanlış origin/MITM riskini artırır.
Kalıcı çözüm doğru hostname için sertifika, `originServerName` veya private CA'yı `caPool` ile güvenilir hale getirmektir. Teşhis sırasında geçici bypass kullanılsa bile neden ve geri dönüş planı açık olmalıdır.
Config YAML değiştikten sonra `cloudflared tunnel ingress validate` ile syntax/ingress kuralını doğrulayın; ardından service restart ve log takibi yapın. Yanlış sıradaki catch-all ingress kuralı doğru hostname'i başka origin'e gönderebilir.
Logda artık x509 hatası yok fakat 502 devam ediyorsa TCP connect, protocol/port veya application response katmanına geçin. Tek bir hata mesajına takılı kalmadan katmanlı ilerleyin.
cloudflared tunnel ingress validatejournalctl -u cloudflared -n 200 --no-pager| Belirti | Öncelik |
|---|---|
| Error 1033 | Connector Cloudflare'a bağlı mı? |
| Healthy + 502 | cloudflared → local origin erişimi |
| x509 valid for X not Y | originServerName / cert hostname |
| x509 unknown authority | Private CA trust / caPool |
Komutları üretim sistemine uygulamadan önce bağlamı doğrulayın, yedek ve geri dönüş planı oluşturun. DNS, TLS, recovery, Docker veya WordPress ayarlarında birden fazla değişkeni aynı anda değiştirmek kök nedeni görünmez hale getirir.
Hayır. Healthy connector'ın Cloudflare'a bağlı olduğunu gösterebilir; cloudflared local origin'e ulaşamıyorsa yine 502 oluşur.
Production için tercih edilen çözüm değildir. Doğru sertifika/hostname veya private CA trust kurulmalıdır.
Container içindeki localhost aynı container'ı ifade eder. Origin başka container/host ise ortak network ve doğru service adı/IP gerekir.
Sorun hosting, VPS, Docker, Cloudflare, Windows veya WordPress altyapınızda devam ediyorsa hata çıktısı ve mevcut mimariyle birlikte teknik destek kaydı oluşturabilirsiniz.