CyberPanel ile OpenLiteSpeed'de Cache Doğru Kurulmazsa Ne Olur?

Cache header'larını okumak: X-LiteSpeed-Cache ne söyler

Bir sayfanın cache'den servis edilip edilmediğini öğrenmenin en doğrudan yolu, HTTP yanıt başlıklarını incelemektir. Tarayıcı geliştirici araçlarını açın, Network sekmesinde HTML dokümanına tıklayın ve Response Headers bölümüne bakın. LiteSpeed Cache etkin ve OpenLiteSpeed doğru yapılandırılmışsa X-LiteSpeed-Cache: hit değerini görmeniz beklenir.

Üç temel değer olası durumları özetler. hit, sayfanın cache'den geldiğini ve PHP'nin çalışmadığını gösterir. miss, isteğin cache katmanına ulaştığını ama önbellekte bu sayfa bulunmadığını ifade eder; PHP devreye girmiştir. bypass ise cache'in aktif olarak atlandığını söyler; bir kural veya koşul bunu zorlamıştır.

Komut satırından hızlı bir kontrol için curl kullanılabilir:

curl -sI https://siteniz.com/ | grep -i "x-litespeed\|x-cache"

Yanıtta X-LiteSpeed-Cache başlığı hiç yoksa, isteğin OpenLiteSpeed üzerinden geçmediği ihtimali doğar. Önde duran bir CDN veya harici bir reverse proxy LiteSpeed başlıklarını silerek hem sorunu gizler hem tanılamayı zorlaştırır. Reverse proxy'nin cache davranışını nasıl etkilediği bu nedenle ayrı bir değerlendirme gerektirir.

İlk header okumasında miss ya da bypass görüyorsanız, X-LiteSpeed-Cache-Control başlığına da bakın. Bu başlık no-cache veya private değeri taşıyorsa, sinyalin nereden üretildiğini izlemeniz gerekir. Sıradaki adımlar bu kaynakları sırayla kapatır.

Cookie tabanlı bypass: en sık gözden kaçan neden

LiteSpeed Cache, gelen her isteği işlemeden önce bir bypass listesi değerlendirir. Bu liste hem LSCWP eklenti ayarlarından hem de OpenLiteSpeed'in kendi yapılandırmasından beslenir. Standart kurulumda WooCommerce entegrasyonu, belirli cookie'lerin varlığında cache'i devre dışı bırakır. Sorun, bu kuralın alışveriş sepeti boş ve kullanıcı oturum açmamış olsa bile tetiklenebilmesidir.

Oturumsuz bir ziyarette tarayıcıda şu cookie'lerin varlığını kontrol edin:

• wordpress_logged_in_*
• woocommerce_cart_hash
• woocommerce_items_in_cart
• wp-settings-*
• comment_author_*

Bu cookie'lerden herhangi biri oturumsuz bir istekte bulunuyorsa, eklenti sayfayı her seferinde dinamik rotadan işler. Testi hızlı yapmak için tarayıcıyı incognito modunda açın ve aynı sayfayı ziyaret edin. Incognito'da hit alıyor, normal oturumda bypass görüyorsanız, sorun cookie kalıntısıdır.

CyberPanel panelinde kalıntıları temizlemek için LiteSpeed Cache > Manage > Flush All seçeneğini kullanabilirsiniz. Bu adım tek başına kalıcı çözüm değildir; eklentinin "Do Not Cache Cookies" listesini gözden geçirin ve gerçekten dinamik yanıt gerektiren cookie'leri bu listede tutun, gerisini çıkarın. WooCommerce dışında bazı üçüncü parti form eklentileri veya üyelik araçları da kalıcı cookie yerleştirir; bunların cookie adlarını LSCWP bypass kurallarıyla karşılaştırın.

Cache'in tam anlamıyla devreye girmesi için, oturumsuz bir ziyaretçinin tarayıcısına hiçbir bypass cookie'si ulaşmaması gerekir. Bu koşul sağlandıktan sonra eklenti önbelleği oluşturmaya başlar ve sonraki ziyaretler hit döner.

.htaccess çatışmaları ve rewrite kuralı sorunu

OpenLiteSpeed, Apache'nin .htaccess kurallarını büyük ölçüde destekler; ancak bazı direktifler cache davranışını doğrudan bozar. LiteSpeed Cache eklentisi etkinleştirildiğinde, web köküne belirli rewrite kuralları yazar. Bu kuralların üzerine başka bir eklenti, güvenlik duvarı modülü veya manuel bir düzenleme yazarsa, bypass koşulu oluşur.

Tipik çatışma şablonu şudur: güvenlik odaklı bir eklenti, .htaccess dosyasına Cache-Control: no-store, no-cache direktifi ekler; bu satır LSCWP'nin yazdığı kurallardan önce gelir; sonuçta OpenLiteSpeed her isteği PHP'ye iletir. TTFB yüksek seyreder ama neden olduğu, .htaccess incelenmeden fark edilmez.

Dosyayı incelemek için:

cat /home/kullanici/public_html/.htaccess

# BEGIN LiteSpeed ile # END LiteSpeed blokları arasındaki satırlara dokunmayın. Bu blok dışında no-cache, no-store veya Pragma: no-cache içeren satırlar görüyorsanız, kaynağını tespit edin ve kaldırın. Kaynağın hangi eklenti olduğundan emin değilseniz, eklentileri birer birer devre dışı bırakıp .htaccess dosyasını karşılaştırmak en güvenilir yöntemdir.

Bazı eski WordPress güvenlik rehberlerinde önerilen Options -Indexes gibi satırlar genellikle zararsızdır; asıl sorun, açıkça önbelleği engelleyen header direktifleri olduğunda ortaya çıkar. Eğer site hız sorununu bir güvenlik eklentisi kurduktan sonra fark ettiyseniz, bu eklentinin .htaccess'e ne yazdığını kontrol etmek ilk adım olmalıdır.

Dizin izinleri ve cache yazma hatası

LSCWP, önbellek dosyalarını varsayılan olarak /home/kullanici/public_html/wp-content/cache/ dizinine yazar. CyberPanel kurulumlarında bu dizin, PHP sürecinin çalıştığı kullanıcıyla farklı bir sahipliğe atanmış olabilir. Bu durumda eklenti, her önbellek oluşturma denemesini sessizce başarısız sayar ve her isteği dinamik rotadan işler. Hata mesajı görmezsiniz; TTFB yüksek kalmaya devam eder.

Sahiplik ve izin durumunu kontrol edin:

ls -la /home/kullanici/public_html/wp-content/cache/

Dizin yoksa, PHP süreci hiç önbellek dosyası yazamamış demektir. Dizin varsa sahipliğe bakın; kullanici:kullanici yerine root ya da farklı bir kullanıcı görüyorsanız, yazma izni yoktur.

Düzeltme için:

chown -R kullanici:kullanici /home/kullanici/public_html/wp-content/cache/
chmod 755 /home/kullanici/public_html/wp-content/cache/

Bu değişikliği uyguladıktan sonra LiteSpeed Cache panelinden tüm önbelleği temizleyin, ardından birkaç farklı sayfayı ziyaret edin ve header'ları yeniden okuyun. İzin sorunu çözüldüyse, birkaç ziyaret sonrasında hit almaya başlarsınız. CyberPanel'de kullanıcı adı değişikliği veya yeniden kurulum sonrasında bu sorun tekrarlayabilir; bu yüzden kurulum sonrası kontrol listesine dizin sahipliği doğrulamasını eklemek pratik bir alışkanlıktır.

ESI yapılandırması: ne zaman gerekli, ne zaman gereksiz

ESI (Edge Side Includes), bir sayfanın statik bölümlerini önbellekte tutarken dinamik parçalarını ayrı istekle çekmeyi sağlar. Giriş yapmış kullanıcılara gösterilen kişiselleştirilmiş karşılama alanı, aktif sepet sayacı veya üyelik durumuna bağlı içerik blokları, ESI olmadan sayfanın tamamının cache dışında kalmasına yol açar. ESI bu sorunu çözer: statik gövde önbellekten gelir, yalnızca dinamik parça ayrıca çekilir.

CyberPanel + OpenLiteSpeed kurulumunda ESI'yi etkinleştirmek için LSCWP ayarlarında LiteSpeed Cache > Advanced > ESI > Enable ESI seçeneğini açmanız gerekir. Bu adım tek başına yeterli değildir; dinamik bölümleri de doğru şekilde işaretlemeniz gerekir. WordPress widget sistemiyle entegre çalışan alanlar için LSCWP'nin ESI widget listesini kullanabilirsiniz.

ESI'nin gereksiz olduğu durumlar pratikte daha yaygındır. Blog yazıları, kategori listeleri, statik içerik sayfaları ve ürün detay sayfalarının büyük bölümü kişiselleştirilmiş içerik barındırmaz; bunlar için ESI açmak, sayfa yüklenme sürecine gereksiz ek istekler ekler. Her ESI çağrısı ayrı bir HTTP isteği üretir ve bu durum toplam yük süresini artırabilir. LiteSpeed Cache'in gerçekte ne fark yarattığını anlamak için önce ESI olmadan temel önbelleklemenin doğru çalıştığını doğrulamak gerekir; ESI, temel sorunları çözdükten sonra değerlendirilen bir optimizasyon adımıdır.

ESI ters etki yarattığında belirtisi nettir: önbelleğe alınan sayfalarda bile yük süresi beklenenden yüksektir ve Network sekmesinde ek fragment istekleri görünür. ESI'yi devre dışı bırakıp farkı ölçmek, gerçekten gerekli olup olmadığını gösterir.

OpenLiteSpeed yapılandırma dosyasında cache bölümü

LSCWP eklentisi WordPress tarafından kurulumu yönetir; ancak OpenLiteSpeed'in kendi yapılandırma dosyasında cache modülünün etkin olup olmadığını doğrudan kontrol etmek, bazı durumlarda zaman kazandırır. CyberPanel'de OLS yönetim paneline https://sunucu-ip:7080 adresinden erişilir.

Yönetim panelinde Virtual Hosts > siteniz > Rewrite bölümüne gidin. Enable Rewrite seçeneğinin açık olduğundan emin olun; kapalıysa LiteSpeed Cache'in yazma kuralları işlemez ve tüm istekler PHP'ye düşer. Bu ayar CyberPanel arayüzü üzerinden oluşturulmuş sitelerde genellikle varsayılan olarak açıktır, ancak manuel yapılandırılmış sanallaştırılmış alan adlarında kapalı kalabilir.

Aynı panelde Module > Cache bölümünü kontrol edin. LiteSpeed önbellek modülü burada aktif olarak listelenmiyorsa, .htaccess üzerinden yapılan yönlendirme kuralları çalışmaz. Modülü etkinleştirdikten sonra lswsctrl restart komutuyla sunucuyu yeniden başlatın:

lswsctrl restart

Sunucu yeniden başlatmadan yapılan yapılandırma değişiklikleri çoğu zaman etkili olmaz; bu adımı atlamak, sorunun düzelmediği izlenimi verir ve gereksiz arama döngüsü başlatır. Performans sorununu tanılarken hangi katmana bakılacağı konusu da bu nedenle yapılandırma doğrulamasını kapsama alır.

Cache sonrası TTFB ölçümü ve doğrulama

Cache devreye girdiğinde TTFB'de beklenen düşüş, arka planda ne kadar PHP ve veritabanı işlemi gerçekleştiğine bağlıdır. Genel kural şudur: PHP işleme ve veritabanı sorguları ortalamanın üzerinde olan siteler, cache devreye girince daha belirgin bir düşüş yaşar. Buna karşın PHP işleme süresi zaten düşük olan sitelerde fark daha küçük olur.

Doğrulama için aynı sayfayı üç farklı koşulda ölçün. İlk ziyarette (miss) TTFB normalden yüksek olacaktır; önbellek henüz oluşmaktadır. İkinci ziyarette (hit) değerin düştüğünü görmelisiniz. Üçüncü ölçümü incognito modunda yapın; cookie veya oturum etkisini dışarda bırakmanızı sağlar.

TTFB hala yüksekse ve header hit dönüyorsa, sorun artık cache katmanında değildir. Zinciri bir adım geri götürün: sunucu donanımı, PHP-FPM yapılandırması, veritabanı yük durumu veya ağ gecikmesi incelenmelidir. WordPress performans optimizasyonuna nereden başlanacağı konusu bu ayrımı somut örneklerle ele alır.

Cache devredeyken FCP ve LCP metriklerinin iyileşmemesi de ayrı bir değerlendirme gerektirir. TTFB düştüğünde render zinciri otomatik kısalmaz; render-blocking kaynaklar, font yüklemesi veya görseller gecikmede belirleyici olmaya devam eder. TTFB düştüğü halde FCP yüksek kalmaya devam ediyorsa, sorun başka bir katmandadır ve ayrı bir tanılama gerektirir.

CyberPanel'e özgü durumlar ve sık yapılan hatalar

CyberPanel, OpenLiteSpeed'i kendi yönetim katmanıyla sarmaladığından, doğrudan sunucu yapılandırmasına müdahale etmek çoğu zaman panel arayüzü üzerinden yapılan işlemlerin üzerine yazılmasına yol açar. Örneğin, OLS yönetim panelinden elle eklenen bir cache kuralı, CyberPanel bir sonraki yapılandırma güncellemesinde bu değeri sıfırlayabilir. Kalıcı değişiklikler için CyberPanel arayüzündeki LiteSpeed seçeneklerini kullanmak daha güvenlidir.

Sık karşılaşılan bir diğer durum, birden fazla alan adı aynı sunucuda barındırılıyorken hatalı sanal ana bilgisayar eşleşmesidir. Her alan adının ayrı bir cache bölümü gerektirdiği ancak paylaşılan bir cache dizininin tanımlandığı durumlarda, bir sitenin önbelleği diğerinin yanıtlarıyla karışabilir. Sunucu yazılımı seçiminin performansa etkisini incelerken bu tür paylaşımlı yapıların nasıl davrandığına da bakmak gerekir.

SSL sertifika yenileme sonrasında cache'in durması da bildirilen durumlar arasındadır. Let's Encrypt sertifika yenilemesi sırasında CyberPanel, OpenLiteSpeed'i yeniden başlattığında cache modülünün etkinlik durumu zaman zaman değişir. Sertifika yenilemesi sonrasında header kontrolü yapmayı alışkanlık haline getirin.

PHP sürümü değiştirildikten sonra da benzer bir reset yaşanabilir. CyberPanel, PHP sürümünü değiştirme sırasında sanal ana bilgisayar yapılandırmasını yeniden oluşturur; bu işlem cache ile ilgili direktifleri etkileyebilir. Aylık hız takibi alışkanlığı bu tür sessiz değişiklikleri zamanında fark etmenizi sağlar.