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.
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
WooCommerce Hosting’de Yüksek Trafiği Kaldırma Rehberi
WooCommerce’te yüksek trafiği güvenli ve hızlı yönetmek için cache, CDN, veritabanı, ölçekleme ve test adımlarını net karşılaştırmalarla öğrenin.
SSH Key ile Şifre Girişi Devre Dışı: Net Güvenlik Rehberi
SSH key kullanarak şifre tabanlı girişi devre dışı bırakın. Doğru ayar dosyaları, doğrulama adımları ve kilitlenmeyi önleyen yöntemleri görün.
TTFB (Time to First Byte) Nedir? Nasıl Düşürülür?
TTFB (Time to First Byte) nedir, ölçümü nasıl yapılır ve hosting/VDS tarafında hangi ayarlarla düşürülebilir? Net teşhis adımları.
İlk domain yatırımı için mantıklı uzantılar: Net karşılaştırma
İlk domain yatırımında hangi uzantılar daha mantıklı? .com, .net, .org, ülke uzantıları ve yeni TLD’lerin SEO/marka etkilerini net kıyaslayın.