Nginx ve Cloudflare’da HTTP/2 ve HTTP/3 (QUIC) Nasıl Etkinleştirilir? WordPress İçin Uçtan Uca Kurulum ve Test Rehberi

Kahven soğumadan: HTTP/2 ve HTTP/3’e beraber bir yolculuk

Hiç başınıza geldi mi? Sabah ofise geldiniz, siteniz açılıyor ama sanki üstüne bir battaniye serilmiş gibi ağır. Trafik var, içerik güzel, sunucu güçlü; ama bir şey eksik. Benim de bir gün tam böyle oldu. Bir yandan kahvemi karıştırırken, diğer yandan ağ tabakasında neyin tıkandığını düşündüm. Sonra “Hadi şu işi kökten çözelim” dedim ve HTTP/2 ile HTTP/3’ün kapısını çaldım. O gün “tarayıcı ile sunucunun aynı dili daha akıcı konuştuğunda” neler değiştiğini kendi gözümle gördüm.

Bu yazıda, WordPress’inizi Nginx üzerinde koştururken ve önünde Cloudflare duruyorken, HTTP/2 ve HTTP/3’ü uçtan uca nasıl ayağa kaldırabileceğinizi anlatacağım. Kafanız karışmasın; konuyu teknik detaylarla boğmadan, adım adım, örneklerle gideceğiz. Nginx tarafında neleri açmanız gerektiğini, Cloudflare panelinde hangi düğmelerin işimize yaradığını, WordPress’in bu değişiklikleri nasıl karşıladığını ve en önemlisi her şeyi nasıl test edip doğrulayacağınızı konuşacağız. Sonunda, sayfalarınızın daha hızlı tepki verdiğini hissettiğinizde, siz de benim gibi bir yudum kahveyi hak edeceksiniz.

HTTP/2 ve HTTP/3’ü anlamak: Aradaki farkı hissetmek

Mesela şöyle düşünün: Şehrin bir ucundan öbür ucuna giderken tek şeritli, ışıklı bir yol yerine, aynı anda birden fazla arabanın akabildiği, tünellerle hızlanan bir hattı kullanıyorsunuz. HTTP/2 tam olarak bu hissi veriyor. Tek bir bağlantı üzerinden aynı anda birden fazla isteği akıtabilmek, bekleme sürelerini kırpıyor. Özellikle WordPress’teki CSS, JS ve görsellerin bir arada geldiği anlarda nefes aldırıyor.

HTTP/3 ise bir adım daha cesur. Klasik TCP yerine UDP üzerine kurulu QUIC protokolünü kullanıyor. Yani sık sık yön değiştiren, bazen mobil, bazen Wi‑Fi ile dolaşan kullanıcılar için bağlantıyı esnek tutuyor. Bağlantı kopar gibi olduğunda bile hemen ayağa kalkıyor ve sayfayı akıtmayı sürdürüyor. “Hangi biri daha hızlı?” diye merak etmek normal, ama pratikte asıl kazanç; daha az beklemek, daha az tıkanmak ve kullanıcıya daha akıcı bir deneyim sunmak.

Burada küçük bir not: Cloudflare kullanıcı ile edge arasında HTTP/3 konuşabiliyor. Edge ile sizin sunucunuz arasında ise çoğu senaryoda HTTP/2 ya da HTTP/1.1 devrede. Bu kötü bir şey değil; tarayıcı tarafında kazanılan akışkanlık zaten hissediliyor. Ama isterseniz, doğrudan Nginx’te deneysel HTTP/3’ü açıp kendi testlerinizi de yapabilirsiniz. Birazdan hepsini göstereceğim.

Hazırlık: WordPress, Nginx ve Cloudflare’i aynı masaya oturtmak

Önce küçük bir hazırlık listesi yapalım, ama bunu bir liste gibi değil, “mutfağa girmeden önce malzemeye göz atmak” gibi düşünün. WordPress’iniz Nginx üzerinde koşuyor ve sitenize geçerli bir TLS sertifikası ile hizmet veriyorsunuz. Sertifika işi zaten hız ve güven için bambaşka bir dünya; Nginx tarafında TLS 1.3, iyi kurgulanmış şifre takımları ve OCSP stapling her zaman dostunuz. Bu konuları daha ayrıntılı kurmak isterseniz, şu rehberdeki pratik adımlar çok iş görüyor: Nginx’te TLS 1.3, OCSP Stapling ve Brotli Nasıl Kurulur? Hızlı ve Güvenli HTTPS’nin Sıcacık Rehberi.

Cloudflare tarafında alan adınız ekli, DNS’i Cloudflare’e teslim etmiş durumdasınız. SSL/TLS modunu Full (strict) kullanmanızı tüm kalbimle öneririm; böylece Cloudflare ile origin sunucu arasında da gerçekten şifreli ve doğrulanmış bir hat kurarsınız. WordPress tarafında ise çok özel bir şey yapmanıza gerek yok, ama birazdan bahsedeceğim ufak dokunuşlar işleri pürüzsüzleştiriyor: karışık içerik (mixed content) temizliği, önbellek eklentisi ayarları ve yönetici trafiğinin akıllıca kurgulanması gibi.

Nginx tarafı: HTTP/2’yi sağlam aç, HTTP/3’ü isteğe bağlı dene

HTTP/2’yi Nginx’te etkinleştirmek

Nginx’te HTTP/2 açmak, doğru yere tek bir anahtar eklemek kadar kolay. Önemli olan, “443”’te SSL ile birlikte “http2” parametresini kullanmak. Bir WordPress sanal host’u düşünelim; şu yapı taşları işinizi görür:

server {
    listen 443 ssl http2;
    server_name example.com www.example.com;

    root /var/www/example.com/public;
    index index.php index.html;

    ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

    # TLS ve sıkıştırma gibi ince ayarlar için ilgili rehber:
    # (TLS 1.3, OCSP stapling, Brotli vs.)

    location / {
        try_files $uri $uri/ /index.php?$args;
    }

    location ~ .php$ {
        include fastcgi_params;
        fastcgi_pass unix:/run/php/php8.2-fpm.sock;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        fastcgi_read_timeout 60s;
    }
}

Bu kadar. Tabii, sertifikanız doğru yerde, PHP‑FPM soketiniz doğru yolda olmalı. Bu ayarlarla Nginx gelen HTTPS taleplerine HTTP/2 üzerinden yanıt verecek. Cloudflare origin ile konuşurken çoğu durumda HTTP/2 kullanmayı tercih ediyor, ama bunu “zorunlu” bir anahtarla yönetmiyorsunuz; önemli olan origin’in HTTP/2’yi destekliyor olması. Nginx’in HTTP/2 modül dokümantasyonuna göz atmak isterseniz, resmi kaynaklar net anlatıyor: Nginx HTTP/2 modül dokümanı.

Deneysel: Nginx’te HTTP/3 (QUIC) etkinleştirmek

Şimdi gelelim merak uyandıran tarafa. Nginx, yeni sürümleriyle HTTP/3’ü deneysel olarak destekliyor. Bu, tarayıcı ile doğrudan sizin sunucunuz arasında HTTP/3 konuşmak demek. Eğer Cloudflare’i kapatıp doğrudan origin’e test etmek, ya da Cloudflare devre dışıyken performans ölçmek istiyorsanız, aşağıdaki yapı iş görür. Bunun için Nginx’in QUIC/HTTP/3 modülleriyle derlenmiş olduğundan emin olun.

server {
    # HTTP/2 hattı (TLS üzerinden)
    listen 443 ssl http2;

    # HTTP/3 hattı (QUIC/UDP üzerinden)
    listen 443 quic reuseport;

    server_name example.com www.example.com;

    ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

    # HTTP/3 için TLS 1.3 şart; ALPN otomatik ayarlanır
    ssl_protocols TLSv1.3;

    # Tarayıcıya HTTP/3 alternatifi sun
    add_header Alt-Svc 'h3=":443"; ma=86400; persist=1';

    root /var/www/example.com/public;
    index index.php index.html;

    location / {
        try_files $uri $uri/ /index.php?$args;
    }

    location ~ .php$ {
        include fastcgi_params;
        fastcgi_pass unix:/run/php/php8.2-fpm.sock;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    }
}

Bir not daha: Cloudflare arada olduğunda, tarayıcı ile Cloudflare edge’i HTTP/3 konuşur, Cloudflare ile origin arası ise genellikle HTTP/2/HTTP/1.1 olur. Yani yukarıdaki HTTP/3 ayarı, daha çok Cloudflare’siz doğrudan testler veya ilerideki olası senaryolara hazırlık içindir. HTTP/3 modülü ve direktifler için resmi dokümana göz atabilirsiniz: Nginx HTTP/3 (QUIC) modül dokümanı.

Cloudflare tarafı: HTTP/3’ü aç, TLS’i sağlam tut, kenarda sihir yap

HTTP/3’ü Cloudflare panelinden etkinleştirmek

Cloudflare’da HTTP/3 açma kısmı çok basit. Panelde ilgili alan adını seçtikten sonra Network bölümünde “HTTP/3 (with QUIC)” anahtarını etkinleştirmeniz yeterli. Böylece tarayıcı ile Cloudflare edge’i arasında HTTP/3 konuşulmaya başlar. Kullanıcı, özellikle mobil ağlarda, daha seri bir yüklenme hisseder. Bu anahtarın yanında kimi zaman 0‑RTT veya benzeri seçenekler de görürsünüz; hepsini aynı anda açmak yerine, birer birer deneyip ölçerek gitmenizi öneririm. Cloudflare’ın konuya dair detaylı yazıları da “bu nasıl çalışıyor?” merakını tatmin eder: curl ile HTTP/3 testi gibi pratik kaynaklar ve Cloudflare’ın teknik paylaşımları bakış açısı kazandırır.

TLS ayarlarında, “Always Use HTTPS” ve “Automatic HTTPS Rewrites” genellikle işleri kolaylaştırır. Ama WordPress’te eski içeriklerde hâlâ http ile başlayan bağlantılarınız varsa, önce bunları temizlemek iyi olur. Çünkü bu seçenekler bazen sihirli görünse de, kökten bir düzeltmenin yerini tutmaz. Origin tarafında “Full (strict)” ile sağlam bir zincir kurduğunuzda içiniz rahat eder.

WAF ve cache ayarlarına ufak bir dokunuş

Performans ne kadar güzel olursa olsun, WordPress’i bot’ların yıpratmasına izin vermek istemezsiniz. Cloudflare’ın WAF kuralları ve oran sınırlama (rate limiting) ayarları burada hayat kurtarıyor. Eğer bu konuyu daha önce didiklemek istiyorsanız, şu rehber çok işe yarıyor: Cloudflare WAF Kuralları ve Oran Sınırlama ile WordPress’i Bot’lardan Nasıl Korursun?. Ayrıca kenar önbellekleme kurallarıyla (Edge Rules) birlikte HTTP/2/HTTP/3 hattının verdiği hız birleşince, sayfalarınız adeta “takılmadan akan” bir hal alıyor. İleri seviye kurallara ilham ararsanız, CDN Önbellekleme, Cache‑Control ve Edge Kuralları yazısındaki örnekler tam yerine oturuyor.

Test ve doğrulama: Hem tarayıcıda hem terminalde içimize sinene kadar

Tarayıcıyla hızlı kontrol

İlk provayı tarayıcıda yapmayı seviyorum. Geliştirici araçlarını açın, Network sekmesinde isteklere bakın. “Protocol” veya benzeri bir sütunda “h2”, “h3” gibi ibareleri görürsünüz. Cloudflare açıkken kullanıcı tarafında “h3” ibaresi belirdiğinde tebessüm etmek serbest. Görmüyorsanız panik yok; bazen tarayıcılar deneme‑yanılmayla protokol seçer, önbelleği temizleyip bir daha deneyin.

curl ile komut satırında protokolü dürtmek

curl, bu işin cep telefonu. HTTP/2 için:

curl -I --http2 https://example.com

Yanıtta “HTTP/2 200” görürseniz tamamdır. HTTP/3 için curl sürümünüzün HTTP/3 destekli olduğundan emin olun; sonra:

curl -I --http3 https://example.com

Yanıtta “HTTP/3 200” görmek, tarayıcının göreceği manzaranın bir özetidir. curl ile HTTP/3 hakkında kısa ama net bir sayfayı merak edenler için: curl HTTP/3 rehberi.

Nginx’den emin olmak: error.log ve access.log

Origin’in HTTP/2’ye açık olduğunu teyit etmek için Nginx loglarına bakmak iyi gelir. Erişim günlüklerinde “HTTP/2” notlarını ve bağlantı özetlerini görebilirsiniz. Cloudflare aradayken origin’in HTTP/3 konuşmasını beklemeyin; kullanıcı edge’e HTTP/3 ile gelirken, edge sizinle çoğunlukla HTTP/2 üzerinden konuşur. Bu ayrım normaldir.

WordPress’in gözüyle: yönetici ve ön yüz

WordPress admin paneli bazen önbellek ve güvenlik katmanlarına hassas olabilir. Admin trafiğini Cloudflare’da önbellek dışı bırakmak, robot kurallarını da abartmamak iyi bir denge sağlar. Önyüzde ise tam sayfa önbellekleme ile HTTP/2/HTTP/3’ün sağladığı bağlantı avantajı birleşince sonuç gerçekten tatlı oluyor. “Bu işi nasıl kurarım?” derseniz, adım adım örnekleriyle şurada anlattım: WordPress’te Tam Sayfa Önbellekleme Nasıl Kurulur?.

Ufak ama etkili dokunuşlar: WordPress, önbellek ve kritik yollar

Karışık içerik (mixed content) ve HTTPS temizlikleri

HTTP/2/HTTP/3 ne kadar güzel olursa olsun, sayfanızda http ile başlayan görseller veya script’ler varsa tarayıcı huzursuz olur. Temizlemenin en garantili yolu; veritabanında eski adresleri https ile güncellemek ve tema ayarlarında kalan kırıntıları bulup düzeltmek. Bazı eklentiler geçici çözümler sunsa da, kökten temizlediğinizde bir daha uğraşmazsınız.

Önbellek: kenarda ve origin’de aynı şarkıyı söylemek

Cloudflare üzerinde statik dosyaları gönül rahatlığıyla önbelleğe alabilirsiniz. WordPress’te ise sayfa önbelleği, HTML’nin “hazır” halde beklemesini sağlar. Nginx FastCGI Cache ile çok hafif ve etkili bir yapı kurabilirsiniz. WooCommerce gibi dinamik sepeti olan projelerde, belirli çerezleri göz ardı ederek, sepet ve ödeme adımlarını önbellek dışında tutmak gerekir. Kenar kuralları ile bu dengeyi rahatça kurabiliyorsunuz; bir bakış daha isterseniz, Edge kurallarıyla tam isabet ayarlar bölümündeki örnek akışlar tam buna hizmet eder.

Güvenlik katmanı: hızla kavga etmeyen koruma

WAF kurallarını çok sıkılaştırıp trafiği boğmak yerine, WordPress’e musallat olan kötü niyetli akışları kibarca dışarıda bırakmak daha sağlıklı. Bot’ları sakinleştiren eşik değerleri, admin giriş denemelerini sınırlayan kurallar ve ülke bazlı akıllı filtreler çoğu projede “gürültüyü” kesiyor. Bu düzeni kurarken performans da elinizle artıyor; çünkü sunucu gereksiz işlerle yorulmuyor. Bu dengeyi kurmanın pratik bir hikâyesi için: WAF ve Bot Koruması: Cloudflare, ModSecurity ve Fail2ban’ı Aynı Masada Barıştırmak.

Adım adım senaryolar: Uçtan uca kısa bir kurgu

Senaryo 1: Cloudflare önünde Nginx/WordPress, hedef HTTP/2 + HTTP/3

Önce Nginx’te “listen 443 ssl http2;” ile HTTP/2’yi açıyorsunuz. TLS 1.3 ve OCSP stapling gibi hız/güven ayarlarını tamamlıyorsunuz. Cloudflare panelinde HTTP/3 anahtarını etkinleştiriyorsunuz. WordPress’te karışık içerikleri temizliyor, önbelleği akıllı kurallarla devreye alıyorsunuz. Tarayıcı DevTools’ta “h3” göründüğünde, terminalde de “curl -I –http3” komutuyla doğruluyorsunuz. Origin log’larında HTTP/2 satırları görülüyor; bu normal. Sonra sayfa geçişlerine baktığınızda, özellikle mobilde, daha akıcı bir deneyim hissetmeye başlıyorsunuz.

Senaryo 2: Cloudflare devre dışı, Nginx’te HTTP/3’ü doğrudan denemek

DNS’i geçici olarak doğrudan origin’e işaretleyip Nginx’te “listen 443 quic reuseport;” ve Alt‑Svc başlığını ekliyorsunuz. curl ve modern tarayıcılarla HTTP/3’ü doğruluyorsunuz. Bu senaryo, ölçüm yapmak, kıyaslamayı gözünüzle görmek ve “acaba ağ koşullarımda ne fark var?” sorusuna cevap aramak için güzel. Yeniden Cloudflare’i devreye aldığınızda, kullanıcı‑edge arası HTTP/3 zaten sizin adınıza çalışmayı sürdürüyor.

Sorun giderme: Ufak tefek pürüzleri tatlıya bağlamak

HTTP/2 görünmüyor mu?

Çoğu zaman SSL bölümünde “http2” parametresinin unutulması yüzünden olur. Nginx’i yeniden yükledikten (reload) sonra hâlâ sonuç alamıyorsanız, ara katmanda bir ters vekil (proxy) veya güvenlik duvarı olup olmadığını kontrol edin. Cloudflare kullanıyorsanız, origin’in HTTP/2 desteği olsa bile erişim günlüklerinde HTTP/1.1 satırları da görebilirsiniz; bu anlık koşullar ve bağlantı tercihleriyle ilgilidir.

HTTP/3 bir var bir yok mu?

Tarayıcılar bağlantı koşullarına göre protokol seçer. İlk istekte HTTP/2, sonra HTTP/3’e geçiş gibi davranışlar normaldir. Cloudflare’da HTTP/3 anahtarının açık olduğundan, tarayıcınızın güncel olduğundan ve kurumsal ağınızda UDP/443’e izin verildiğinden emin olun. Nginx’te doğrudan HTTP/3 deniyorsanız, sürüm ve derleme seçeneklerinin doğru olduğundan emin olmak şarttır.

WordPress admin yavaşladı mı?

Admin için önbellek dışında kalacak kurallar tanımlayın. Cloudflare üzerinde “/wp-admin/” ve “/wp-login.php” için önbellek devre dışı kalmalı. Bazı güvenlik eklentileri aşırı korumacı davranıp her istekte ekstra gecikme yaratabilir; ayarlarını sadeleştirip tekrar deneyin. Kalan yavaşlık genelde veritabanı sorgularıdır; onu da başka bir gün uzun uzun konuşuruz.

Bonus: İlerisi için küçük bir yol haritası

HTTP/2/HTTP/3 raylarını döşedikten sonra, sunucu optimizasyonlarıyla farkı katlayabilirsiniz. Örneğin PHP‑FPM, OPcache ve kuyruk sistemlerini bir arada ele alan şu rehber üretim ortamlarında çok iş görür: Prod ortam optimizasyonu pratikleri. Her ne kadar başlığı Laravel dese de, prensiplerin önemli bir kısmı WordPress için de yol gösterici.

Kapanış: Hız sadece sayı değil, hissedilen bir akış

Bugün birlikte, Nginx ve Cloudflare tarafında HTTP/2 ve HTTP/3’ü açıp, WordPress’in de bu akışa zarifçe katılmasını sağladık. Aslında yaptığımız şey basit: tarayıcı ile sunucu arasındaki konuşmayı daha akıcı, daha esnek ve daha az bekleyen bir hale getirmek. Küçücük dokunuşların sayfa hissiyatını nasıl değiştirdiğini görmek her zaman keyif veriyor. Özellikle mobilde, düşük kaliteli ağlarda ve yoğun trafik anlarında fark daha belirgin hissediliyor.

Son tavsiye: Değişiklikleri tek seferde değil, adım adım yapın. Önce Nginx’te HTTP/2’yi açın, sonra Cloudflare’da HTTP/3’ü etkinleştirin, ardından WordPress’te önbellek ve karışık içerik temizliklerini tamamlayın. Her adım sonrası tarayıcı ve curl ile testi ihmal etmeyin. İçinize sinmeyen bir şey olursa geri alması daha kolay olur. Umarım bu rehber, elinizi korkak alıştırmadan deneme yapabilmeniz için yeterince sıcak ve anlaşılır olmuştur. Bir dahaki yazıda daha ince ayarlarla, belki de farklı senaryolarda tekrar buluşuruz; şimdilik kahve molası serbest.

Kaynaklarına göz atmak isteyenlere not: Nginx dokümanları, HTTP/2 ve HTTP/3 modüllerini sade anlatıyor. Meraklısına bağlantıları bırakıyorum: Nginx HTTP/2 modülü ve Nginx HTTP/3 (QUIC) modülü. Ayrıca terminalde hızlı denemeler için curl HTTP/3 sayfası pratik ipuçları sunuyor.