LiteSpeed Cache QUIC.cloud bağlantı hatası, WordPress sitesinin LiteSpeed Cache eklentisi üzerinden QUIC.cloud API’sine erişemediğini veya alan adını doğrulayamadığını gösterir. Hata; Domain Key alma, QUIC.cloud hesabına bağlanma, CDN etkinleştirme ya da görsel optimizasyonu gibi işlemlerde ortaya çıkabilir. cPanel barındırma ortamlarında en sık nedenler PHP cURL/SSL doğrulama sorunu, sunucunun dışarı doğru 443 numaralı porta erişememesi, hatalı DNS-CDN yönlendirmesi veya alan adının dış dünyadan ulaşılamamasıdır. Bu rehber, sorunu rastgele önbellek temizleyerek değil; hata kapsamını ayırıp DNS, HTTPS, WordPress ve sunucu erişimini kontrollü biçimde doğrulayarak çözmeye odaklanır.
Belirti ve kapsam: Hata hangi aşamada oluşuyor?
Önce hatanın eklenti ile QUIC.cloud arasındaki yönetim bağlantısında mı, yoksa QUIC.cloud’un ziyaretçi isteğini sitenin origin sunucusuna ulaştırmasında mı gerçekleştiğini belirleyin. Bu iki durum aynı görünse de çözüm adımları farklıdır.
| Belirti | Muhtemel kapsam | İlk kontrol |
|---|---|---|
| Domain Key istenemiyor veya bağlantı kurulamadı mesajı | WordPress/PHP sunucusundan QUIC.cloud API erişimi | PHP cURL, DNS çözümleme, dışa açık TCP 443 |
| Domain Key var fakat QUIC.cloud hesabına bağlama başarısız | Alan adı eşleşmesi veya hesap yetkilendirmesi | Doğru WordPress URL’si, eski anahtar ve hesap ilişkisi |
| CDN açıldıktan sonra site 52x, zaman aşımı veya origin hatası veriyor | QUIC.cloud’dan origin sunucuya erişim | DNS kaydı, origin HTTPS, güvenlik duvarı/WAF |
| Görsel optimizasyonu ya da kritik CSS kuyruğu ilerlemiyor | API iletişimi, geri çağrı veya kuyruk işlemi | Eklenti durumu, WordPress cron, PHP hata günlüğü |
LiteSpeed Cache QUIC.cloud bağlantı hatası için hızlı teşhis özeti
- WordPress Yönetim Paneli’nde LiteSpeed Cache altındaki QUIC.cloud/Domain Key durumunu ve gösterilen hata metnini kaydedin.
- Sitenin ayarlardaki WordPress adresi ve site adresinin, kullanılan alan adı ile HTTPS şemasını doğru gösterdiğini doğrulayın.
- Origin alan adının genel DNS üzerinden doğru IP’ye çözüldüğünü ve HTTPS ile açıldığını kontrol edin.
- Sunucuda hem DNS çözümlemesini hem de
https://api.quic.cloudiçin dışarı giden HTTPS erişimini sınayın. - Komut satırındaki PHP ile web sunucusunun kullandığı PHP’nin farklı yapılandırmalara sahip olabileceğini unutmayın; cPanel’de asıl belirleyici web PHP’sidir.
- CDN DNS kaydı veya güvenlik duvarı kuralı değiştirmeden önce mevcut kayıtları ve kuralları dışa aktarın ya da not edin.
Olası nedenler ve güvenli teşhis yöntemleri
1. PHP cURL veya CA sertifika doğrulaması çalışmıyor
LiteSpeed Cache, QUIC.cloud ile iletişim için WordPress’in HTTP istek altyapısını kullanır. PHP’de cURL uzantısının kapalı olması, güncel olmayan CA sertifika paketi veya TLS doğrulama sorunu bağlantıyı engelleyebilir. WordPress Yönetim Paneli’ndeki Araçlar > Site Sağlığı > Bilgi bölümünden PHP cURL desteğini kontrol edin. Site Sağlığı ekranındaki loopback veya REST API uyarıları da ayrıca incelenmelidir.
SSH erişiminiz varsa, sunucunun ağ erişimini aşağıdaki komutlarla kontrol edin. Bu kontroller yapılandırma değiştirmez.
getent ahosts api.quic.cloud
curl -I --connect-timeout 10 https://api.quic.cloud
openssl s_client -connect api.quic.cloud:443 -servername api.quic.cloud </dev/nullgetent adı çözümleyemiyorsa sorun DNS resolver tarafındadır. curl zaman aşımına uğruyorsa dışarı giden trafik, proxy veya ağ politikası incelenmelidir. openssl s_client çıktısında sertifika doğrulama hatası görülürse sunucunun CA paketi ve sistem saati kontrol edilmelidir.
RHEL türevi cPanel sunucularında aşağıdaki komutlar, ilgili bileşenlerin görünürlüğü için kullanılabilir:
rpm -q ca-certificates curl
php -m | grep -i '^curl$'
timedatectl statusBu komutlardaki php, çoğu zaman CLI PHP ikilisidir. cPanel’in EasyApache 4 veya CloudLinux altındaki web PHP sürümü farklı olabilir. Bu nedenle CLI’da cURL görünse bile Site Sağlığı’nda sorun varsa, ilgili cPanel hesabının seçili PHP sürümü ve etkin uzantıları MultiPHP Manager veya Select PHP Version üzerinden kontrol edilmelidir. Paylaşımlı hosting kullanıcıları bu aşamada sağlayıcıdan, hesap PHP’sinde cURL ve güncel CA sertifika zinciri doğrulamasını istemelidir.
2. Sunucunun dışa açık HTTPS erişimi engelleniyor
QUIC.cloud IP adresleri sabit kalmayabileceği için yalnızca tek bir IP’yi izin listesine eklemek kalıcı bir yaklaşım değildir. Öncelikle sunucunun dışarı doğru TCP/443 erişiminin; ağ güvenlik duvarı, egress politikası, kurumsal proxy veya hosting sağlayıcısı kısıtlaması tarafından engellenmediğini doğrulayın. CSF, işletim sistemi güvenlik duvarı veya veri merkezi firewall’ında değişiklik yapma yetkiniz varsa bile önce mevcut kural setini yedekleyin ve kısa bir bakım penceresinde çalışın.
Sunucu bir çıkış proxy’si kullanıyorsa, web sunucusu PHP’sinin proxy üzerinden internete çıkacak şekilde ayrıca yapılandırılması gerekebilir. Sadece SSH oturumundaki curl komutunun çalışması, PHP-FPM, LiteSpeed PHP veya Apache modülünün aynı ağ yolunu kullandığını kesin olarak kanıtlamaz.
3. Domain Key, alan adı veya hesap eşleşmesi bozulmuş
Alan adı www sürümüne taşındığında, HTTP’den HTTPS’ye geçirildiğinde, klon ortamından canlı ortama veritabanı aktarıldığında ya da birden fazla QUIC.cloud hesabı kullanıldığında kayıt eşleşmesi bozulabilir. WordPress’te Ayarlar > Genel altında yer alan WordPress adresi ve Site adresini kontrol edin. Bu adresler, ziyaretçilerin kullandığı kanonik alan adı ve doğru https:// şemasıyla uyumlu olmalıdır.
Ardından LiteSpeed Cache ayarlarından mevcut Domain Key durumunu kontrol edin. Anahtarı hemen silmek yerine, önce ilgili alan adının doğru QUIC.cloud hesabında kayıtlı olup olmadığını doğrulayın. Eski bir test veya klon siteden kalan anahtar şüphesi varsa, değişiklik öncesinde mevcut yapılandırmanın ekran görüntüsünü alın. Gerekirse eklentinin kendi arayüzündeki Domain Key yenileme/yeniden isteme akışını kullanın; WordPress veritabanında eklenti seçeneklerini doğrudan silmek, çalışan CDN veya optimizasyon eşleşmesini gereksiz yere bozabilir.
4. DNS, HTTPS veya origin erişimi QUIC.cloud doğrulamasını engelliyor
QUIC.cloud CDN kullanımında ziyaretçi DNS kayıtları QUIC.cloud yönlendirmesine geçebilir; ancak origin sunucunun da erişilebilir kalması gerekir. Yanlış A/AAAA kaydı, eski IPv6 kaydı, kapalı 443 portu, geçersiz origin sertifikası veya IP tabanlı erişim kısıtlaması origin bağlantısını bozabilir.
Alan adını hem yerel resolver ile hem de yetkili DNS sonucu açısından inceleyin:
dig +short example.com A
dig +short example.com AAAA
dig +short www.example.com CNAME
curl -I --connect-timeout 10 https://example.com/example.com yerine gerçek alan adınızı yazın. AAAA kaydı varsa ama sunucuda IPv6 hizmeti yoksa, bazı ziyaretçiler ve servisler başarısız bağlantı yaşayabilir. CDN kurulumu sırasında gereken DNS hedefini QUIC.cloud kontrol panelinin o an gösterdiği değerle birebir karşılaştırın; tahmine dayalı CNAME veya IP kaydı kullanmayın. DNS değişiklikleri öncesinde TTL değerini ve mevcut kayıtları kaydedin. Yanlış DNS değişikliği erişim kesintisi oluşturabileceğinden, bunu düşük trafikli bir bakım penceresinde uygulayın.
5. WAF, Basic Auth veya bot koruması origin isteğini reddediyor
Sunucunun ModSecurity kuralı, uygulama güvenlik duvarı, ülke/IP engeli, Basic Authentication veya bakım modu, QUIC.cloud’un origin’e ulaşmasını engelleyebilir. Özellikle CDN etkinleştirildikten sonra hata görülüyorsa erişim günlükleri belirleyicidir. cPanel sunucularında Apache günlüklerinin konumu kurulum ve kullanıcıya göre değişebilir; WHM/cPanel günlük arayüzünü veya sunucu yöneticinizin belirttiği log yolunu kullanın. LiteSpeed Enterprise kullanılıyorsa web sunucusu günlük konumları Apache’den farklı olabilir.
İnceleme sırasında şu zaman damgalarını eşleştirin: eklentideki hata zamanı, web erişim günlüğündeki HTTP durum kodu ve ModSecurity/WAF olayı. Tanı için korumayı tüm site için kalıcı biçimde kapatmayın. Gerekliyse yalnızca doğrulanmış kural veya istek davranışı için dar kapsamlı ve geri alınabilir bir istisna oluşturun.
Güvenli adım adım çözüm sırası
- Hata metnini sınıflandırın. Domain Key/API hatası mı, CDN-origin hatası mı olduğunu belirleyin. Eklenti sürümünü, WordPress sürümünü ve hata zamanını not edin.
- WordPress URL tutarlılığını düzeltin. Site adresleri, zorunlu HTTPS yönlendirmesi ve kanonik alan adı aynı hedefi göstermelidir. Yönetim URL’sini değiştirecekseniz önce veritabanı ve dosya yedeği alın.
- PHP HTTP kapasitesini doğrulayın. Site Sağlığı’nda cURL, REST API ve loopback uyarılarını giderin. Eksik cURL veya sertifika paketi için cPanel/hosting yöneticisinden hesap PHP’sine yönelik işlem talep edin.
- Sunucu çıkışını test edin.
api.quic.cloudDNS ve HTTPS testleri başarısızsa firewall, egress filtreleme, proxy ve resolver ayarlarını inceleyin. Başarılı sonuç almadan Domain Key işlemini tekrarlamayın. - Domain Key eşleşmesini yenileyin. Doğru QUIC.cloud hesabını doğruladıktan sonra LiteSpeed Cache arayüzündeki güvenli yenileme akışını kullanın. Aynı alan adını farklı hesaplarda eşzamanlı yönetmemeye dikkat edin.
- CDN kullanılıyorsa DNS ve origin’i doğrulayın. Kontrol panelindeki güncel DNS hedefini uygulayın; A, AAAA ve CNAME kayıtlarındaki çakışmaları giderin. Origin HTTPS sertifikası ve 443 erişimi geçerli olmalıdır.
- Son olarak önbelleği kontrollü temizleyin. Bağlantı düzeldikten sonra LiteSpeed Cache üzerinden site önbelleğini temizleyin ve önemli sayfalarda oturum açmamış ziyaretçi testi yapın. Sorunun nedenini bulmadan tüm eklenti ayarlarını sıfırlamayın.
Çözümü doğrulama
Doğrulama, yalnızca eklentide yeşil bir durum görmekten ibaret olmamalıdır. LiteSpeed Cache ekranında Domain Key’in etkin olduğunu ve QUIC.cloud hesabıyla bağlantının kurulduğunu kontrol edin. Ardından tarayıcının gizli penceresinde ana sayfa, giriş sayfası ve dinamik bir sayfayı açın. CDN etkinse DNS çözümlemesinin hedeflenen kaydı döndürdüğünü ve HTTPS sertifikasının alan adıyla eşleştiğini yeniden test edin.
curl -I https://example.com/
curl -sS -o /dev/null -w 'HTTP: %{http_code}\nTLS: %{ssl_verify_result}\n' https://example.com/İkinci komutta TLS: 0, cURL tarafında sertifika doğrulamasının başarılı olduğunu ifade eder. HTTP durumunu sitenizin beklenen davranışına göre yorumlayın; ana sayfada 200 veya yönlendirme senaryosunda beklenen 301/302 görülebilir. Yönetici oturumunda görünen yanıt başlıklarını, herkese açık sayfa önbelleği kanıtı olarak tek başına değerlendirmeyin.
Tekrarını önleme
- WordPress, LiteSpeed Cache, PHP ve sistem CA sertifika paketlerini planlı bakım pencerelerinde güncel tutun.
- DNS kayıtlarında değişiklik yönetimi uygulayın; CDN etkinleştirme öncesi A, AAAA, CNAME ve TTL değerlerini kaydedin.
- Sunucu çıkış trafiğinde TCP/443 için gereksiz kısıtlama olmadığını düzenli kontrol edin.
- WAF değişikliklerini kural bazında belgelendirin; genel koruma kapatma yönteminden kaçının.
- Canlı siteye taşınan klonlarda URL, Domain Key ve QUIC.cloud hesap ilişkisini yayına almadan önce gözden geçirin.
Sonuç
LiteSpeed Cache QUIC.cloud bağlantı hatası çoğunlukla tek bir önbellek sorunu değildir; PHP’nin dış HTTPS erişimi, Domain Key eşleşmesi, DNS ve origin güvenliği birlikte değerlendirilmelidir. Önce hata katmanını ayırmak, ardından değişiklik yapmadan ağ ve TLS testlerini çalıştırmak; gereksiz ayar sıfırlamalarını ve kesinti riskini azaltır.
Sık sorulan sorular
QUIC.cloud bağlantısı için sunucuda LiteSpeed Web Server zorunlu mu?
LiteSpeed Cache eklentisinin bazı işlevleri farklı web sunucularında çalışabilir; ancak önbellekleme ve sunucu entegrasyonunun kapsamı kullanılan altyapıya göre değişir. QUIC.cloud bağlantı hatasında öncelik, WordPress/PHP’nin API’ye HTTPS üzerinden erişebilmesidir.
cURL komutu SSH’de çalışıyor, ancak eklenti hâlâ bağlanamıyor. Neden?
SSH’deki CLI PHP veya sistem cURL ile web isteğini çalıştıran PHP farklı sürüm, uzantı, kullanıcı izni ya da proxy ayarı kullanabilir. WordPress Site Sağlığı ve ilgili cPanel hesabının web PHP yapılandırması ayrıca kontrol edilmelidir.
Domain Key’i silip yeniden oluşturmak sorunu kesin çözer mi?
Hayır. Sorun DNS, TLS, firewall veya PHP cURL kaynaklıysa anahtarı yenilemek tek başına sonuç vermez. Önce API erişimi ve doğru hesap/alan adı eşleşmesi doğrulanmalıdır.
CDN DNS kaydını değiştirdikten sonra hata hemen düzelir mi?
DNS yayılım süresi TTL, resolver önbelleği ve kayıt türüne göre değişir. Değişikliği hem genel DNS sorgusuyla hem de gerçek HTTPS isteğiyle doğrulayın.
ModSecurity’yi kapatmak güvenli bir çözüm müdür?
Kalıcı ve genel kapsamlı kapatma önerilmez. Loglarda doğrulanan belirli bir yanlış pozitif varsa, yalnızca ilgili kural için dar kapsamlı, geri alınabilir bir istisna değerlendirilmelidir.
