Rehber 22 Ağustos 2026 · 6 dakika okuma

WordPress’te HTTP/2 ve HTTP/3 desteği nasıl açılır? Net adımlar

WordPress’te HTTP/2 ve HTTP/3’ü doğru şekilde etkinleştirmek için sunucu ve CDN tarafı adımlarını, doğrulama testlerini ve sık hataları öğrenin.

WordPress sitelerinde sayfa açılış süresini etkileyen en kritik katmanlardan biri taşımadır (transport layer). HTTP/2 ve HTTP/3, özellikle çoklu isteklerde gecikmeyi azaltır ve modern TLS/QUIC altyapısıyla daha stabil performans hedefler. Bu yazıda, WordPress’te HTTP/2 ve HTTP/3’ün nasıl açılacağını; Nginx/Apache, Cloudflare/CDN ve WordPress önbellekleme ile birlikte nasıl doğrulayacağınızı net adımlarla öğreneceksiniz. Ayrıca “açtım ama çalışmıyor” senaryolarında kontrol edilecek noktaları listeleyeceğiz.

HTTP/2 ve HTTP/3: WordPress’e ne kazandırır?

HTTP/2 (RFC 7540) çoğunlukla aynı bağlantı üzerinden çoklu istekleri verimli taşır; HTTP/3 ise QUIC (UDP) tabanlıdır ve bağlantı kurulumu ile paket kaybı durumlarında daha iyi davranış hedefler. WordPress tarafında çekirdek bir değişiklik gerekmez; asıl iş sunucu (ve varsa CDN) katmanındadır.

WordPress’te HTTP/2/3’ün etkisi, sitenin yükleme davranışına bağlıdır: - Sayfada CSS/JS ve görsel sayısı fazlaysa çoklu istekler artar → HTTP/2 daha fazla fark yaratır. - Mobil/oynayan ağ koşullarında bağlantı yeniden kurulumu ve paket kaybı varsa → HTTP/3 avantaj sağlayabilir. - CDN kullanıyorsanız sonuçlar çoğunlukla CDN’in HTTP sürümünü nasıl tuttuğuna bağlıdır.

Adım 1: Site URL’inizi ve kaynaklarınızı doğru sınıflandırın

İlk adım, HTTP sürümünü kim belirliyor netleştirmektir: - Kullanıcıdan gelen trafiği direkt sunucu mu alıyor? - Yoksa CDN/Proxy (ör. Cloudflare) ön planda mı? - Sunucu türü nedir: Nginx mi Apache mi? Managed bir ortam mı (ör. panel sağlayıcısı) yoksa kendi yapılandırmanız mı var?

Aşağıdaki mini kontrol listesiyle ilerleyin: - Domain’in DNS’inde proxy var mı (CDN’in ara katmanı)? - Web sunucusu loglarında “HTTP/2” davranışı görünüyor mu? - WordPress’te kullandığınız cache eklentisi sayfayı sadece HTML mi önbelleğe alıyor, yoksa ayrıca “preload/push” gibi transport ayarları yapıyor mu?

Bu ayrımı doğru yapmazsanız HTTP/2/3’ü açtığınızı sanıp CDN ile çakışma yaşayabilirsiniz.

Adım 2: HTTP/2’yi açma (Nginx ve Apache)

HTTP/2 çoğu kurulumda TLS (HTTPS) gerektirir. Bu nedenle önce sertifikanın sağlam şekilde takılı olduğundan emin olun.

Nginx (HTTP/2)

Genellikle Nginx’te HTTP/2, listen direktifiyle açılır.

server bloğunuzda şu mantık bulunmalıdır: - listen 443 ssl http2;

Örnek şablon (sürüm ve path’ler sizde farklı olabilir):

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

  ssl_certificate /path/fullchain.pem;
  ssl_certificate_key /path/privkey.pem;
}

Apache (HTTP/2)

Apache’de HTTP/2 modülü gerekiyorsa (ortama göre) etkinleştirilir ve sanal host yapılandırmasında uyarlanır. - 2.4.26 ve üzeri ile çoğu modern dağıtımda mod_http2 desteklenir. - Hedef: HTTPS vhost içinde HTTP/2’yi aktif etmek.

Apache tarafında komutlar dağıtıma göre değişebilir. Kritik olan nokta: HTTPS vhost yapılandırmanızın HTTP/2 modunu çağırdığını görmenizdir.

Adım 3: HTTP/3’ü açma (CDN varsa “asıl kontrol” oradadır)

HTTP/3’ün açılması, çoğu senaryoda iki yolla olur: 1) CDN/Proxy üzerinden otomatik: Örneğin Cloudflare gibi bir servis HTTP/3’ü uçtan uca yönetebilir. 2) Sunucuda doğrudan: Nginx quic / Apache http3 veya uygulama ile uyumlu destek gerektirir.

Türkiye’de özellikle performans için yaygın olan yaklaşım CDN kullanmaktır. Eğer trafik CDN üzerinden geçiyorsa, çoğu zaman HTTP/3’ü sunucuda değil, CDN panelinde açarsınız.

Cloudflare örneği (HTTP/3)

Cloudflare’da HTTP/3 davranışı genellikle aşağıdaki şekilde yönetilir: - SSL/TLS ayarları “Full” veya “Full (strict)” olacak şekilde HTTPS tutarlılığını sağlamak - HTTP/3 seçeneğini etkinleştirmek

Burada önemli detay: CDN ile origin (kendi sunucunuz) arasındaki bağlantı HTTP/2/3 olmak zorunda değildir. Kullanıcı- CDN arası HTTP/3 olabilir. Sonuçları doğrularken mutlaka hedefin “kullanıcıdan tarayıcıya görünen protokol” olduğunu kontrol edin.

Origin sunucuda doğrudan HTTP/3

Eğer CDN kullanmıyorsanız ya da HTTP/3’ü doğrudan origin’de istiyorsanız: - Sunucu yazılımının HTTP/3/QUIC’i desteklemesi gerekir. - UDP 443 trafiğinin açık olması gerekir. - Güvenlik duvarı (iptables/ufw) ve sağlayıcı tarafında UDP engeli olmamalıdır.

Net uygulama adımları şunlardır: - UDP 443 açık mı? (Gerekirse port kontrol testi) - Sunucuda QUIC uyumlu konfigürasyon aktif mi? - Sertifika geçerli mi? (HTTP/3 için de TLS sertifikası temeldir.)

Adım 4: WordPress katmanında yapmanız gerekenler

HTTP/2/3 çoğunlukla transport katmanıdır; WordPress eklentileri genellikle bunu “açmaz”. Yine de HTTP/2/3’ü çalışır ve tutarlı tutmak için WordPress tarafında net ayarlar yapmanız gerekir.

1) Siteyi kesinlikle HTTPS yapın

HTTP/2/3’ün çalışmasının ön koşulu HTTPS’tir. - WordPress Ayarlar → Genel: Site URL ve WordPress URL https ile başlıyor mu? - .htaccess veya Nginx redirect ile HTTP→HTTPS kesin mi?

2) Cache eklentisi ve “preload/push” çakışmalarını kontrol edin

Bazı cache eklentileri veya CDN ayarları yanlış yapılandırıldığında tarayıcı aynı anda çakışan yönlendirmeler görebilir. - Gereksiz yeniden yönlendirme döngüsü olmamalı. - Aynı kaynağı hem farklı host header ile hem de farklı protokolle çekmeye zorlamamalı.

3) URL tutarlılığı: WAF/Proxy varsa doğru Host header

CDN kullanıyorsanız origin’in Host header’ı doğru iletildiğinden emin olun. Aksi halde: - 301/302 zinciri oluşur - Protokol doğrulaması yanıltıcı görünür

Adım 5: Doğrulama testleri (“Açtım ama çalışmıyor” için net kontrol)

HTTP/2/3’ün gerçekten aktif olup olmadığını ölçmeden değişiklik yapmak risklidir. Doğrulama için üç pratik yöntem kullanın.

1) Tarayıcı geliştirici araçları

  • Chrome/Edge: Network sekmesinde isteğin “Protocol” bilgisini kontrol edin.
  • Beklenen:
  • HTTP/2 için: “h2” görünür
  • HTTP/3 için: “h3” veya benzeri gösterim (tarayıcıya göre isim değişebilir)

2) Online protokol test araçları

Çeşitli araçlar URL’in hangi HTTP sürümüyle yanıtlandığını gösterir. Kullanırken şu noktayı unutmayın: - Testi her zaman gerçek sayfa URL ile yapın (ana sayfa çoğu zaman farklı cache davranışı gösterebilir).

3) Sunucu loglarında doğrulama

  • Nginx’te HTTP/2 requestleri ve bağlantı davranışı loglara düşebilir.
  • CDN kullanıyorsanız CDN analitik/edge logları daha anlamlı olur.

Sık yapılan hatalar (Net sebepler ve çözümler)

Aşağıdaki durumlarda “HTTP/3 açıldı sanıyorum ama tarayıcı görüyor mu?” konusu sık patlar.

  • Hâlâ HTTP’den HTTPS’e redirect var ve tekrar yönlendiriyor:
  • Çözüm: Tek seferlik redirect kuralı kurun, cache cache-control davranışını da kontrol edin.

  • CDN açık ama HTTP/3 kapalı:

  • Çözüm: CDN panelinde HTTP/3’ü etkinleştirin, sonra farklı cihaz ve ağdan test edin.

  • Origin UDP 443 kapalı (CDN yoksa):

  • Çözüm: Güvenlik duvarı/ACL kuralını UDP 443 ile güncelleyin.

  • Sertifika yanlış zincir (chain) veya geçerli değil:

  • Çözüm: Full chain sertifikayı doğru dosyadan verin.

  • Birden fazla “front” katmanı çakışması:

  • Örnek: Cloudflare proxy + ek bir reverse proxy daha.
  • Çözüm: Trafik yolunu sadeleştirin; protokolün hangi noktada belirlendiğini belirleyin.

HTTP/2 vs HTTP/3: Karar tablosu (hangi durumda hangisi?)

Aşağıdaki tablo, hedefe göre neye öncelik vereceğinizi hızlı belirler.

Durum Öncelik Net neden
Sitenizde çok sayıda CSS/JS ve görsel istek var HTTP/2 Aynı bağlantı üzerinden çoklu istekleri verimli taşır.
CDN kullanıyor ve performans hedefi yüksek HTTP/3 CDN’in edge tarafında protokolü daha kolay aktive edebilirsiniz.
CDN kullanmıyorsunuz ve UDP trafiği kontrolünüz yok HTTP/2 UDP/QUIC altyapısı olmadan HTTP/3 istikrarsız kalır.
Mobil ağlarda paket kaybı sık HTTP/3 QUIC tasarımı bağlantı toparlanmasını hedefler.
Yalnızca “teknik olarak çalışıyor” değil, stabilite önemli HTTP/2 sonra HTTP/3 HTTP/2 daha yaygın; HTTP/3’te UDP/ayar kaynaklı sorunlar çıkabilir.

Uygulama planı: 30-40 dakikada net ilerleme

  • 10 dk: DNS ve trafik yolunu netleştir (CDN var mı, origin mi?).
  • 10 dk: HTTP/2’yi aç ve HTTPS’te redirect zincirini kontrol et.
  • 10-15 dk: HTTP/3’ü CDN panelinden aç (varsa) veya origin’de UDP 443/QUIC desteğini doğrula.
  • 5-10 dk: Tarayıcı Network ile “Protocol” bilgisini doğrula.

Bu planın ardından protokol doğru görünmüyorsa, hatayı genellikle şu sırayla ararsınız: redirect zinciri → CDN/setting → UDP/QUIC → sertifika zinciri → reverse proxy çakışması.

Sonuç: HTTP/2’yi temel yapın, HTTP/3’ü kontrollü devreye alın

WordPress’te HTTP/2/HTTP/3 desteğini açmak, çoğu zaman WordPress eklentisinden değil sunucu ve/veya CDN ayarlarından yürür. İlk aksiyonunuz HTTPS’i ve HTTP/2’yi doğru şekilde aktive etmek; ikinci aksiyonunuz ise CDN varsa HTTP/3’ü etkinleştirip tarayıcıda protokolü doğrudan doğrulamak olmalı. Değişiklikleri yaptıktan sonra bir “protokol doğrulama” testi (tarayıcı Network ya da HTTP versiyon test aracı) çalıştırın; görünmüyorsa UDP/redirect/sertifika gibi kök nedenlere geri dönün. Bu sırayı izlediğinizde, karar vermeyi zorlaştıran belirsizlik yerine ölçülebilir bir kontrol elde edersiniz.

Etiketler: #wordpress #http2 #http3 #hosting #nginx #apache #cdn

Hosting karşılaştırması yapmaya hazır mısın?

100+ firmanın fiyatlarını tek tıkla karşılaştır, en uygun paketi bul.

Hosting Karşılaştır →

İlgili Yazılar

0 ürün seçildi
NetKıyas AI
Hosting danışmanınız
Merhaba! Ben NetKıyas yapay zekâ asistanı. Hosting, VDS, VPS veya sunucu seçiminde size yardımcı olabilirim. Ne arıyorsunuz?