Nginx FastCGI Cache ile PHP Sitesini Hızlandırma

Elinizde 4 çekirdekli bir VDS var, PHP-FPM ayarlarını kurcaladınız, OPcache'i açtınız, veritabanına indeks attınız. Ana sayfa hâlâ 700 ms'de açılıyor ve htop ekranında her istekte dört tane php-fpm: pool www satırı birden yanıyor. Sorun tek bir yavaş sorgu değil: aynı içerik, her ziyaretçi için sıfırdan yeniden üretiliyor. Günde 30 bin kez çalıştırılan ve her seferinde aynı HTML'i döndüren bir PHP kodunuz var.

FastCGI Cache tam olarak burada devreye girer. Nginx, PHP-FPM'den dönen tam HTML yanıtını diske yazar ve aynı adres bir daha istendiğinde PHP'yi hiç çalıştırmadan dosyadan servis eder. Yanıt süresi tipik olarak 300-800 ms bandından 5-20 ms bandına iner, PHP-FPM işçi sayısı ihtiyacı düşer, aynı donanım birkaç kat fazla ziyaretçi taşır.

Buraya kadarı her yerde yazıyor. Asıl mesele şu: kopyala-yapıştır bir fastcgi_cache bloğu, bir e-ticaret sitesini iki saatte bozar. Bir müşteri başkasının sepetini görür, giriş yapan kullanıcı çıkış yapmış gibi görünür, yönetim panelinde yaptığınız değişiklik siteye yansımaz. Bu yazıda yapılandırmanın kendisiyle birlikte üç kritik parçayı da veriyoruz: bypass kuralları, HIT/MISS doğrulaması ve içerik güncellenince önbelleği temizleme.

FastCGI Cache Tam Olarak Neyi Önbelleğe Alır?#

FastCGI Cache, Nginx ile PHP-FPM arasındaki hattı dinler. Nginx bir .php isteğini FastCGI protokolüyle PHP-FPM'e iletir; PHP-FPM cevabı üretip geri gönderir. Cache açıkken Nginx bu cevabı ziyaretçiye iletmeden önce bir kopyasını /var/cache/nginx altına yazar. Sonraki istekte PHP-FPM soketine hiç dokunulmaz.

Bu yüzden FastCGI Cache'i diğer önbellek katmanlarıyla karıştırmayın:

Üçü birbirinin alternatifi değil, tamamlayıcısıdır. OPcache yapılandırması PHP'yi hızlandırır; FastCGI Cache PHP'yi devre dışı bırakır. Ama FastCGI Cache yalnızca anonim ziyaretçilere aynı çıktının gittiği sayfalarda güvenlidir. Kişiye özel içerik üreten her adres, birazdan yazacağımız bypass listesine girmek zorundadır.

Ölçek olarak bakalım: 300 ms'lik bir PHP yanıtı ve 100 eşzamanlı ziyaretçi, kabaca 30 PHP-FPM işçisi gerektirir. Aynı trafiği %90 HIT oranıyla karşılayan bir FastCGI Cache, PHP-FPM'e saniyede yalnızca 10 istek bırakır. Bu, pm.max_children değerini büyütmeden kapasiteyi katlamak demektir.

Önbellek Alanını Tanımlama: fastcgi_cache_path ve keys_zone#

İlk adım, önbelleğin nerede duracağını ve ne kadar yer kaplayacağını tanımlamaktır. Bu direktif http bloğuna girer — yani /etc/nginx/nginx.conf içine ya da /etc/nginx/conf.d/fastcgi-cache.conf gibi ayrı bir dosyaya:

fastcgi_cache_path /var/cache/nginx/fastcgi
                   levels=1:2
                   keys_zone=PHPCACHE:100m
                   inactive=60m
                   max_size=2g
                   use_temp_path=off;

fastcgi_cache_key "$scheme$request_method$host$request_uri";

Parametreleri tek tek açalım, çünkü buradaki her değer üretimde bir davranışa karşılık gelir:

• levels=1:2 — Önbellek dosyalarını iki kademeli alt dizinlere dağıtır. Tek bir dizinde yüz binlerce dosya biriktiğinde dosya sistemi yavaşlar; bu ayar onu engeller.
• keys_zone=PHPCACHE:100m — Anahtarların tutulduğu paylaşımlı bellek alanı. 100 MB kabaca 800 bin anahtar taşır. Bu içerik için değil, indeks için ayrılan RAM'dir; asıl HTML diske yazılır.
• inactive=60m — 60 dakika boyunca hiç istenmeyen kayıt, süresi dolmamış olsa bile silinir. Ziyaret edilmeyen eski sayfalar diski şişirmez.
• max_size=2g — Önbelleğin disk üst sınırı. Aşıldığında Nginx en eski kayıtları atar.
• use_temp_path=off — Nginx'in geçici dosyayı önce başka bir dizine yazıp sonra taşımasını engeller. Aynı disk üzerinde gereksiz kopyalamayı önler, açık tutun.

fastcgi_cache_key ise önbellek kaydının kimliğidir. $scheme sayesinde HTTP ve HTTPS ayrı kayıtlara gider, $host sayesinde aynı sunucudaki farklı alan adları birbirine karışmaz, $request_uri sayesinde her sayfa kendi kaydını alır. Bu dört değişkenden birini çıkarmak, gerçek bir çakışma riskidir: $host olmadan site-a.com ve site-b.com aynı önbellek kaydını paylaşır.

Dizini önce oluşturun ve Nginx kullanıcısına verin:

sudo mkdir -p /var/cache/nginx/fastcgi
sudo chown -R www-data:www-data /var/cache/nginx
sudo nginx -t && sudo systemctl reload nginx

Server Bloğunda FastCGI Cache'i Devreye Alma#

Alan tanımlandıktan sonra sıra, PHP isteklerini karşılayan location bloğunda önbelleği açmaya gelir. Aşağıdaki blok, standart bir PHP-FPM kurulumunun üzerine eklenmiş hâlidir:

location ~ \.php$ {
    include snippets/fastcgi-php.conf;
    fastcgi_pass unix:/run/php/php8.3-fpm.sock;

    fastcgi_cache PHPCACHE;
    fastcgi_cache_valid 200 301 302 10m;
    fastcgi_cache_valid 404 1m;
    fastcgi_cache_min_uses 1;

    fastcgi_cache_bypass $skip_cache;
    fastcgi_no_cache     $skip_cache;

    fastcgi_cache_lock on;
    fastcgi_cache_lock_timeout 5s;
    fastcgi_cache_background_update on;
    fastcgi_cache_use_stale error timeout updating http_500 http_502 http_503 http_504;

    add_header X-Cache $upstream_cache_status always;
}

Üç direktif özellikle dikkat ister:

fastcgi_cache_lock on — Önbellekte olmayan bir sayfaya aynı anda 200 istek geldiğinde, kilit olmadan 200 PHP süreci birden aynı sayfayı üretmeye kalkar. Buna "cache stampede" denir ve genellikle tam da trafik zirvesinde sunucuyu düşürür. Kilit açıkken yalnızca ilk istek PHP'ye gider, diğerleri sonucu bekler.

fastcgi_cache_use_stale — PHP-FPM hata verdiğinde ya da yanıt vermediğinde, süresi dolmuş kaydı servis etmeye devam eder. Veritabanı bir dakikalığına düştüğünde ziyaretçi 502 yerine biraz eski ama çalışan bir sayfa görür. Listedeki updating değeri ise yenileme sırasında beklemeyi engeller.

fastcgi_cache_background_update on — Süresi dolmuş bir kayıt istendiğinde ziyaretçiye eski kopyayı hemen verir, yeni kopyayı arka planda üretir. Süre dolumunun kullanıcıya yansımasını neredeyse tamamen ortadan kaldırır. Nginx 1.11.10 ve sonrası için geçerlidir; Ubuntu 24.04'ün 1.24 sürümünde mevcuttur.

PHP-FPM tarafında havuz ayarlarınız hâlâ önemlidir — HIT olmayan istekleri o karşılıyor. Soket seçimi, pm modu ve timeout değerleri için Nginx ve PHP-FPM yapılandırması yazısındaki hesapları temel alabilirsiniz.

fastcgi_cache_valid ile Hangi Yanıt Ne Kadar Saklanır?#

fastcgi_cache_valid hangi HTTP durum kodunun ne kadar süreyle saklanacağını belirler. Tek bir "doğru" süre yoktur; içeriğin değişme sıklığına göre karar verirsiniz:

Ayrı bir satır yazmadığınız durum kodları hiç önbelleğe alınmaz — 500 ve 502 gibi hata yanıtlarının varsayılan olarak saklanmaması iyi bir şeydir, dokunmayın.

Uzun süre yazmaktan çekinmeyin: bir sonraki bölümde anlatacağımız purge mekanizmasını kurduysanız, içerik değiştiği anda kaydı zaten silersiniz. Purge yoksa süreyi kısa tutmak, "güncelleme ne zaman görünür" sorusunun tek cevabı hâline gelir.

Bir tuzak: fastcgi_ignore_headers Cache-Control Expires Set-Cookie; satırını rehberlerde sık görürsünüz. Bu satır, uygulamanın "beni önbelleğe alma" demesini Nginx'e görmezden gelmesini söyler. Set-Cookie başlığını yok saymak, oturum çerezi taşıyan bir yanıtın diske yazılması demektir; o kayıt sonraki ziyaretçiye gittiğinde başkasının oturumunu devralabilir. Bu satıra ihtiyacınız olduğunu düşünüyorsanız, önce bypass kurallarınızı düzeltin.

Bypass Kuralları: Giriş Yapmış Kullanıcı, Sepet ve Yönetim Paneli#

Bu bölüm, FastCGI Cache'in en çok atlanan ve en pahalıya patlayan kısmı. Kişiye özel bir sayfa önbelleğe alındığında, o sayfa sonraki herkese servis edilir.

Gerçek hayatta gördüğümüz üç bozulma:

1. Sepet karışması — İlk ziyaretçinin sepet sayfası önbelleğe girer, ondan sonra siteye giren herkes o sepeti görür. Ödeme adımına kadar giden vakalar var.
2. Oturum yanılsaması — Giriş yapmış kullanıcı, anonim ziyaretçi için üretilmiş "Giriş Yap" başlıklı sayfayı görür. Kullanıcı çıkış yapmış sanır, tekrar giriş yapar, aynı sayfayı yine görür.
3. Panelde değişiklik yok — Yönetim panelinde yaptığınız düzenleme kaydediliyor ama sitede görünmüyor; çünkü panel POST'u işleniyor, önbellek ise eski GET yanıtını vermeye devam ediyor.

Çözüm, önbelleği devre dışı bırakacak koşulları bir $skip_cache değişkeninde toplamaktır. Bu blok server bloğunun içine, location bloklarından önce yazılır:

set $skip_cache 0;

# POST istekleri ve sorgu dizesi olan adresler asla önbelleklenmez
if ($request_method = POST) { set $skip_cache 1; }
if ($query_string != "")    { set $skip_cache 1; }

# Yönetim paneli, API uçları ve dinamik adresler
if ($request_uri ~* "/wp-admin/|/wp-json/|/xmlrpc.php|wp-.*\.php|/feed/|sitemap(_index)?\.xml") {
    set $skip_cache 1;
}

# WooCommerce: sepet, ödeme, hesabım
if ($request_uri ~* "/sepet|/odeme|/hesabim|/cart|/checkout|/my-account|/wc-api/") {
    set $skip_cache 1;
}

# Giriş yapmış kullanıcı, yorum yazan, parola korumalı içerik
if ($http_cookie ~* "comment_author|wordpress_[a-f0-9]+|wp-postpass|wordpress_logged_in|woocommerce_items_in_cart|woocommerce_cart_hash|wp_woocommerce_session_") {
    set $skip_cache 1;
}

Çerez kontrolü listenin en kritik satırı. wordpress_logged_in çerezi tarayıcıda varsa kullanıcı giriş yapmış demektir ve o isteğin yanıtı ne okunmalı ne de yazılmalıdır. Bunun için fastcgi_cache_bypass (okuma) ve fastcgi_no_cache (yazma) direktiflerinin ikisini birden aynı değişkene bağladığımıza dikkat edin. Yalnızca bypass yazarsanız, giriş yapmış kullanıcının kişiselleştirilmiş sayfası önbelleğe yazılmaya devam eder; asıl sızıntı oradan olur.

WordPress kullanmıyorsanız kendi uygulamanızın oturum çerezi adını (PHPSESSID, laravel_session, _myapp_session gibi) listeye ekleyin. Emin değilseniz tarayıcının geliştirici araçlarında Application → Cookies sekmesine bakın; giriş yaptığınızda beliren çerez hangisiyse odur.

Uyarı: if direktifi Nginx'te sınırlı bir yapıdır ve location içinde beklenmedik davranabilir. Yukarıdaki kullanım (set ile değişken atama) desteklenen ve güvenli olan biçimdir; aynı bloklara return veya rewrite eklemeyin.

X-Cache Başlığıyla HIT/MISS Doğrulaması#

Yapılandırmayı kaydettiniz, Nginx'i yeniden yüklediniz. Peki gerçekten çalışıyor mu? Bunu tahmin etmeyin, ölçün. add_header X-Cache $upstream_cache_status always; satırı sayesinde her yanıt kendi durumunu söyler:

# İlk istek: MISS bekleriz
curl -sI https://ornek.com/hakkimizda/ | grep -i x-cache

# İkinci istek: HIT bekleriz
curl -sI https://ornek.com/hakkimizda/ | grep -i x-cache

# Bypass testi: giriş çerezi taşıyan istek BYPASS dönmeli
curl -sI -H "Cookie: wordpress_logged_in_abc=deneme" https://ornek.com/ | grep -i x-cache

# Yanıt süresi karşılaştırması
curl -o /dev/null -s -w "%{time_total}s\n" https://ornek.com/hakkimizda/

$upstream_cache_status değişkeninin alabileceği değerler ve anlamları:

Doğrulamanın ikinci yarısı çoğu zaman atlanır: HIT görmek yetmez, HIT görmemesi gereken sayfaların BYPASS döndüğünü de kanıtlamalısınız. Devreye almadan önce şu üç adımı mutlaka yapın:

1. Sitede giriş yapın, bir sayfayı açın, geliştirici araçlarında X-Cache başlığının BYPASS olduğunu görün.
2. Gizli sekmede aynı sayfayı açın, HIT görün ve giriş yapmış kullanıcının adının görünmediğini doğrulayın.
3. Sepete ürün ekleyin, sepet sayfasını açın, BYPASS olduğunu doğrulayın; sonra gizli sekmede sepet sayfasını açıp boş geldiğini görün.

Üçünü de geçtiyseniz önbelleğiniz üretime hazırdır. Bir tanesi bile takılıyorsa $skip_cache bloğuna dönün.

Canlıya alırken add_header X-Cache satırını bırakabilirsiniz; bilgi sızdıran bir başlık değildir ve ileride sorun ararken çok işinize yarar. Rahatsız ediyorsa sadece kendi IP'niz için açacak şekilde map ile koşullandırın.

İçerik Güncellenince Önbelleği Temizleme#

Bir yazıyı düzenlediniz, kaydettiniz, sitede görünmüyor. fastcgi_cache_valid süresi dolana kadar beklemek üretimde kabul edilebilir bir cevap değil. İki yol var.

Yöntem 1: Dosyayı doğrudan silmek#

Nginx her kaydı, fastcgi_cache_key değerinin MD5 özetiyle adlandırılmış bir dosyaya yazar ve levels=1:2 kuralıyla alt dizinlere dağıtır. Hangi dosya olduğunu hesaplayabilirsiniz:

# Anahtarı kurun: $scheme + $request_method + $host + $request_uri
KEY="httpsGETornek.com/hakkimizda/"
HASH=$(printf '%s' "$KEY" | md5sum | cut -d' ' -f1)

# levels=1:2 -> son karakter / ondan önceki iki karakter / tam hash
DIR="/var/cache/nginx/fastcgi/${HASH: -1}/${HASH: -3:2}"
sudo rm -f "$DIR/$HASH"

Tüm önbelleği boşaltmak için ise dizini süpürmek yeterlidir. Dizinin kendisini silmeyin, içindekileri silin:

sudo find /var/cache/nginx/fastcgi -type f -delete

Bu komut güvenlidir; Nginx yeniden başlatmaya gerek duymaz, eksik kayıtları bir sonraki istekte yeniden üretir. Ancak zirve trafikte tüm önbelleği birden silmek, PHP-FPM'e ani bir yük bindirir — fastcgi_cache_lock açıksa bu darbe büyük ölçüde yumuşar.

Yöntem 2: fastcgi_cache_purge modülü#

Açık kaynak Nginx'te purge yeteneği yerleşik değildir; Debian ve Ubuntu bunu dinamik modül olarak sunar:

sudo apt install nginx-extras
# veya yalnızca modül:
sudo apt install libnginx-mod-http-cache-purge

Modül yüklendikten sonra ayrı bir location bloğu tanımlarsınız:

location ~ /purge(/.*) {
    allow 127.0.0.1;
    allow 203.0.113.10;   # yalnızca sunucu ve yönetim IP'niz
    deny all;
    fastcgi_cache_purge PHPCACHE "$scheme$request_method$host$1";
}

⚠️ allow/deny satırlarını atlamayın. Herkese açık bir purge adresi, saniyede yüzlerce istekle önbelleğinizi sürekli boşaltarak sunucuyu PHP'ye boğmak için kullanılabilir — düşük maliyetli bir hizmet dışı bırakma vektörüdür.

Purge çağrısını uygulamaya bağlamak, çözümün son parçasıdır. WordPress tarafında Nginx Helper eklentisi yazı kaydedildiğinde ilgili adresleri otomatik purge eder. Kendi uygulamanızda ise içeriği kaydeden kodun sonuna, değişen adresler için birer purge isteği ekleyin. Uygulama katmanında yaptığınız Redis/nesne önbelleği temizliğiyle karıştırmayın; ikisi ayrı katmanlardır ve ayrı ayrı temizlenmeleri gerekir — nesne önbelleği ve Redis tarafını da güncel tutun.

Deploy sonrası ise sıra önemlidir: önce kod yüklenir, sonra OPcache sıfırlanır, en son FastCGI Cache boşaltılır. Ters sırada yaparsanız, OPcache eski kodu derlemişken FastCGI Cache yeniden dolar ve eski çıktıyı bir tur daha yaşatırsınız.

Sık Karşılaşılan Bozulmalar ve Çözümleri#

Son bir ölçüm alışkanlığı: HIT oranınızı bilin. Nginx erişim kaydına $upstream_cache_status ekleyip günlük olarak sayın. %85'in altındaki bir oran, genellikle fazla geniş yazılmış bir bypass kuralına ya da sorgu dizesi eklentileriyle sonsuz çoğalan adreslere işaret eder.

log_format cached '$remote_addr - $upstream_cache_status "$request" $status';
access_log /var/log/nginx/access.log cached;

Bu satırlarla birlikte, sitenizin hızını artık tahminle değil rakamla yönetiyorsunuz. Sıkıştırma katmanını da eklemek isterseniz Nginx gzip ve Brotli sıkıştırma yazısı doğal bir devam noktasıdır; sıkıştırma önbellekten dönen yanıtlara da uygulanır ve iki kazanç birbirinin üstüne biner.

Sıkça Sorulan Sorular#

FastCGI Cache ile Varnish arasındaki fark nedir?#

İkisi de tam sayfa önbelleği yapar ama Varnish ayrı bir servistir, Nginx'in önünde çalışır ve VCL adında kendi yapılandırma diline sahiptir. FastCGI Cache ise Nginx'in içindedir; ek bir süreç, ek bir port ve ek RAM istemez. Karmaşık kural setlerine, ESI'ye veya çok katmanlı mimariye ihtiyacınız yoksa FastCGI Cache tek sunuculu kurulumlarda neredeyse her zaman daha basit ve yeterlidir.

WordPress'te eklenti kullanmak yerine neden Nginx tarafında önbellek yapayım?#

Eklenti tabanlı önbellekler HTML'i diske yazar ama isteği yine de PHP başlatarak karşılar; WordPress çekirdeği yüklenir, eklenti çalışır, dosya okunur. FastCGI Cache'te istek PHP'ye hiç ulaşmaz. Pratikte aradaki fark 60-120 ms'lik bir taban maliyettir ve trafiğin yoğun olduğu anlarda PHP-FPM işçi havuzunuzu tamamen serbest bırakır.

Önbellek süresini çok uzun tutarsam ne olur?#

Purge mekanizması kurulmuşsa hiçbir sorun olmaz; içerik değiştiği anda ilgili kayıt silinir ve bir sonraki ziyaretçi yeni sürümü görür. Purge yoksa uzun süre, "güncellemem neden görünmüyor" şikâyetlerinin doğrudan sebebi olur. Kural şu: önce purge'ü kurun, sonra süreyi uzatın.

Sitem HTTPS ve HTTP'yi birlikte kullanıyor, önbellek karışır mı?#

fastcgi_cache_key içinde $scheme varsa karışmaz; HTTP ve HTTPS istekleri ayrı kayıtlara yazılır. Bu değişkeni anahtardan çıkarırsanız, HTTP üzerinden üretilmiş bir sayfa HTTPS ziyaretçisine servis edilebilir ve sayfa içindeki mutlak bağlantılar karışık içerik uyarısı üretir. Anahtarı sadeleştirmeye çalışırken $scheme ve $host değişkenlerini asla çıkarmayın.

Önbelleği temizledikten sonra Nginx'i yeniden başlatmam gerekir mi?#

Hayır. Önbellek dosyalarını sildiğinizde Nginx eksik kayıtları bir sonraki istekte kendiliğinden yeniden üretir; reload ya da restart gerekmez. Yalnızca fastcgi_cache_path gibi yapılandırma satırlarını değiştirdiğinizde nginx -t ile doğrulayıp systemctl reload nginx çalıştırmanız yeterlidir.

Bypass kuralları doğru mu, nasıl emin olurum?#

Yapılandırmayı okuyarak değil, deneyerek. Giriş yapıp bir sayfada X-Cache: BYPASS gördüğünüzü, aynı sayfayı gizli sekmede açtığınızda HIT aldığınızı ve gizli sekmedeki çıktıda kullanıcı adınızın geçmediğini ayrı ayrı doğrulayın. E-ticaret sitesinde aynı testi sepet ve ödeme sayfaları için tekrarlayın. Bu üç kontrolü geçmeyen bir yapılandırmayı canlıya almayın.