HTTP/3 (QUIC) hosting’de aktif mi? Test rehberi

HTTP/3 (QUIC) hâlâ “her yerde aktif” seviyesinde değil. Aynı hosting altyapısında bile tarayıcıya göre farklı yol (HTTP/2, HTTP/1.1) seçilebiliyor ya da QUIC yalnızca belirli bölgelerde/deney noktalarında devreye giriyor. Bu yazıda, HTTP/3’ün gerçekten çalıştığını kanıtlayan test yöntemlerini; tarayıcı göstergesi, curl, sunucu/CDN logları ve yapılandırma doğrulaması şeklinde adım adım göreceksiniz. Böylece “panelde var ama sitede yok” senaryosunu hızlıca ayıklarsınız.

HTTP/3’ün neden “panelde var” olsa bile görünmeyebileceği

HTTP/3’ü test etmeden önce şu gerçekleri bilmek işinizi kolaylaştırır:

• HTTP/3, QUIC üzerinden çalışır. UDP (genelde 443/udp) trafiği gerekir.
• Bazı kurulumlarda HTTP/3 yalnızca belirli CDN POP’larında veya yalnızca belirli alan adlarında etkin olur.
• Tarayıcı önceki denemeler ve ağ koşullarına göre HTTP/2’de kalabilir.
• Sunucu arkasında reverse proxy (Nginx/HAProxy/Traefik) veya CDN varsa, HTTP/3’ün “uçtan uca” çalışması için her katmanın destek vermesi gerekir.

Bu yüzden hedefiniz sadece “sağlayıcı HTTP/3 destekliyor mu?” değil; alan adınız için HTTP/3 trafiği gerçekten akıyor mu? olmalı.

Test hazırlığı: doğru hedefi ve doğru koşulları seçin

Testi hatasız yapmak için aşağıdaki koşulları sağlayın:

• Alan adı: Mümkünse test edeceğiniz gerçek hostname’i kullanın (ör. www.ornek.com). DNS’te CNAME/ALIAS varsa bile aynı host üzerinden test yapın.
• TLS: HTTP/3 için TLS gerekir. Sertifikanız güncel olmalıdır.
• Port/erişim: QUIC için UDP 443 gerekir. Sunucu güvenlik duvarı (ufw/iptables), provider firewall’ı veya VPS/VDS tarafındaki kısıtlar UDP’yi engelliyorsa HTTP/3 düşer.
• Lokasyon: Aynı test, farklı ülkelerden farklı sonuç verebilir. En az iki lokasyonla (aynı operatör + farklı operatör ya da Türkiye + yurt dışı) kontrol edin.

Sunucu paneli yerine “gerçek istek” ölçün

Kontrol paneli bazen “HTTP/3 aktif” diye etiket görünebilir. Ancak en güvenilir kanıt, alan adınıza gelen HTTP yanıtında kullanılan protokoldür. Bu yüzden testleri mutlaka gerçek istekle yapın.

Yöntem 1: Tarayıcıda protokol göstergesiyle doğrulayın

Tarayıcı tabanlı yöntem, hızlı eleme sağlar. Yine de tek başına %100 kanıt saymak yerine diğer kanıtlarla eşleştirin.

1) Chrome/Edge tabanlı tarayıcıda DevTools (Geliştirici Araçları) açın. 2) Network sekmesine geçin. 3) Sayfayı yeniden yükleyin. 4) İstek satırında veya detaylarda Protocol değerini arayın.

Aradığınız durumlar: - HTTP/3 için genelde “h3” benzeri bir etiket veya “HTTP/3” görünür. - Eğer “h2” görürseniz, HTTP/3 o anda devrede değil demektir.

Not: Bazı tarayıcılar HTTP/3 başarısız denemesi sonrası otomatik olarak HTTP/2’ye geri dönebilir. Bu yüzden tek bir denemeden hüküm vermeyin.

Yöntem 2: curl ile HTTP/3 kullanımı kanıtlayın (net ve teknik)

CLI ile test etmek, en net protokol bilgisini verir. Aşağıdaki komutlar HTTP/3’ü zorlar.

curl ile zorlayarak deneme

Sunucunuzun alan adına göre değişmeden çalışır:

curl -v --http3 https://www.ornek.com/ -o /dev/null

• Çıktıda “HTTP/3” veya “h3” kullanımına dair satırlar görmelisiniz.
• HTTP/3 başarısız olursa curl çoğu senaryoda hata verir ya da fallback davranışı gösterebilir.

Alternatif: HTTP/2 mi HTTP/3 mü karşılaştırın

Aynı endpoint için:

curl -v --http2 https://www.ornek.com/ -o /dev/null
curl -v --http1.1 https://www.ornek.com/ -o /dev/null

HTTP/3 aktifken genelde HTTP/2 testinde HTTP/2 görürsünüz; HTTP/3 testinde ise HTTP/3 görünmelidir. Bu ikisi arasındaki farkı aynı anda doğrulayın.

curl çıktısında kritik ipuçları

Şunları arayın: - Protokol satırı: “HTTP/3” / “h3” - QUIC ile ilgili handshake/connection logları

Eğer test sürekli HTTP/3’e geçmiyor ve HTTP/2’de kalıyorsa; UDP/443 engeli, CDN/proxy desteği eksikliği veya TLS/konfigürasyon hatası olabilir.

Yöntem 3: QUIC trafiğini ve düşüş nedenini UDP seviyesinde kontrol edin

Bu yöntem özellikle kendi VDS/VPS’nizde reverse proxy veya edge katmanı kurduysanız faydalıdır.

Sunucu tarafında UDP/443 erişimi var mı?

Sunucu üzerinde (root yetkisiyle) firewall kurallarını kontrol edin:

• ufw kullanıyorsanız: ufw status
• iptables/nftables kullanıyorsanız: UDP 443 için ACCEPT kuralı var mı bakın.

HTTP/3’ün düşmesi çoğu zaman “UDP 443 engeli” ya da “proxy QUIC’i upstream’e taşımıyor” kaynaklıdır.

Packet capture ile görsel kanıt alın (opsiyonel ama güçlü)

Sunucuda kısa süreli test sırasında QUIC trafiği gözlemlenebilir. Örnek fikir: - tcpdump ile UDP 443 paketleri var mı bakın.

Bu yaklaşım, “curl HTTP/3 denedi ama neden olmadı?” sorusuna doğrudan cevap üretir. Ancak işlem sisteminizde ek izin gerektirebilir.

Yöntem 4: CDN / reverse proxy loglarıyla kesinleştirin

Siteniz bir CDN arkasındaysa (Türkiye’de yaygın kurulumlar dahil), HTTP/3 desteği iki yerde önem kazanır: 1) CDN edge HTTP/3’ü kabul ediyor mu? 2) CDN-to-origin bağlantısı (gerekirse) HTTP/2 veya HTTP/1.1 olabilir; fakat edge’den kullanıcıya HTTP/3 olmalıdır.

Loglarda arayacağınız alanlar

CDN veya reverse proxy loglarında şu tür alan adları görünebilir: - protocol / http_version - quic / h3 - user-agent değil, istek meta bilgisinde protokol

Örnek kontrol yaklaşımı: - Testinizi yapın (curl --http3 ile) - Loglarda aynı zaman damgasına denk gelen istek satırını bulun - O satırın protokol alanında HTTP/3 (h3) görünüyor mu doğrulayın

Nginx / HAProxy / Traefik gibi katmanlar kullanıyorsanız

Eğer origin tarafında Nginx/HAProxy/Traefik var ise, HTTP/3 desteği ve UDP yönlendirmesi ayrı bir konudur. “Web server HTTP/3’e izin veriyor mu?” sorusunu şu şekilde netleştirin:

• Reverse proxy kendisi QUIC’i terminate ediyor mu?
• CDN HTTP/3’ü terminallerse, origin’e tekrar QUIC taşınmasına gerek kalmayabilir.
• CDN-to-origin arasında mutlaka destekli bir protokol var mı?

Bu noktada en doğru yaklaşım: edge katmanında HTTP/3 kanıtını almak ve origin loglarındaki protokol beklentisini buna göre okumaktır.

“Aktif mi?” sorusunu tek sayfada netleştiren kontrol listesi

Aşağıdaki tablo, test sonucunuza göre bir sonraki hamleyi doğrudan belirler.

HTTP/3’ü gerçekten “aktif” saymak için gereken net kriterler

HTTP/3’ü aktif kabul etmek için şu kriterler bir araya gelmelidir:

• Aynı domain/hostname üzerinden, curl --http3 denemesinde protokol HTTP/3 olarak raporlanmalı.
• İsteğin zaman damgasına denk gelen CDN/reverse proxy loglarında ilgili satır protokolü h3/HTTP3 göstermeli.
• UDP engeli yoksa ve birden fazla lokasyonda testte görülüyorsa, aktivasyon güvenilir sayılır.

En sık hatalar ve pratik çözüm yolları

1) UDP 443 engeli

VDS/VPS firewall veya güvenlik grubu UDP’yi kapattığında HTTP/3 düşer. Çözüm: UDP 443 için gerekli izinleri verin ve yeniden test edin.

2) Yanlış hostname test edilmesi

Bazı sağlayıcılarda HTTP/3 yalnızca www üzerinde çalışır. Çözüm: hem kök (ornek.com) hem www.ornek.com ayrı ayrı test edin.

3) Edge katmanı farklı davranıyor

CDN kurduysanız origin tarafındaki web server ayarları tek başına sonucu belirlemez. Çözüm: kullanıcıya görünen edge protokolünü (log + curl) temel alın.

4) TLS sertifikası veya zinciri sorunu

HTTP/3’te TLS, hatta daha sıkı doğrulama adımlarına takılır. Çözüm: tam zincir (chain) ve yenileme tarihlerini kontrol edin.

5) Tarayıcı cache etkisi

Tarayıcı geçmiş denemeleri protokol seçimini etkileyebilir. Çözüm: testten önce hard reload yapın ya da farklı tarayıcı profili kullanın.

Sonuç: Doğru kanıtla karar verin

HTTP/3’ün “aktif” olup olmadığını anlamanın en sağlam yolu, panel etiketine bakmak değil; curl ile HTTP/3 zorlayıp protokol bilgisini almak ve mümkünse CDN/reverse proxy loglarıyla aynı zaman diliminde doğrulamaktır. Uygulayacağınız aksiyon sırası şudur: (1) curl -v --http3 ile tek endpoint testi yapın, (2) tarayıcı Network’te protokolü karşılaştırın, (3) lokasyon veya kısa süreli tekrar ile tutarlılığı kontrol edin, (4) sonuç alamıyorsanız UDP/443 ve edge/proxy konfigürasyonunu hedefleyin. Böylece NetKıyas gibi karşılaştırma platformlarında “HTTP/3 destek var” iddialarını gerçek trafik verisiyle netleştirirsiniz.