HTTP/3 (QUIC) Hosting’de Aktif mi? Test Rehberi (Adım Adım)

HTTP/3 (QUIC) kullanan bir hosting, aynı sayfayı daha hızlı açma potansiyeli ve ağ koşulları bozulduğunda daha kararlı davranış gibi avantajlar sunar. Ancak “destekliyor” ifadesi tek başına yeterli değildir: Kullanıcı trafiğiniz gerçekten HTTP/3’e geçiyor mu, yoksa altyapı otomatik olarak HTTP/2 veya HTTP/1.1’e mi düşüyor? Bu rehberde HTTP/3’ün aktif olduğunu kanıtlamak için tarayıcıdan başvuracağınız, komut satırından doğrulayacağınız ve gerektiğinde sunucu/edge tarafında kanıt toplayacağınız net test yöntemlerini öğreneceksiniz.

Aşağıdaki adımlar; VDS/VPS, web hosting ve CDN kullanan senaryolarda işe yarayacak şekilde yazıldı. Amaç, “muhtemelen açık” yerine “şu istekte şu protokol kullanıldı” diyebileceğiniz kanıt üretmektir.

HTTP/3 “aktif” demek ne? (Eşleşen protokol kanıtı)

HTTP/3’ün aktif sayılması için isteklerin gerçekten alt katmanda QUIC üzerinden taşınması gerekir. Pratikte bu şu anlama gelir:

• Tarayıcı/istemci bir isteği başlattığında h3 veya QUIC sinyali görürsünüz.
• Sunucu (veya CDN/edge) o isteği HTTP/3’e yönlendirir.
• Geri dönüş (fallback) durumunda ise istek HTTP/2’ye düşer; bu durumda HTTP/3 aktif değildir.

HTTP/3 ile ilgili en kritik nokta şudur: Hosting tarafında destek olsa bile, gerçek kullanıcı oturumları her zaman HTTP/3’e gitmeyebilir. Bu yüzden test, “destek var mı” değil “benim siteme gelen istek HTTP/3 mü?” sorusuna cevap vermelidir.

Testi doğru kurun: önce ön koşullar

HTTP/3 testini yapmadan önce şu koşullar net şekilde sağlanmalıdır. Aksi halde sonuçlar yanıltıcı olur.

1) HTTPS şart

HTTP/3, TLS 1.3 ile birlikte çalışır. HTTP yerine HTTPS üzerinden denediğinizden emin olun.

• https://domain.com ile test edin.

2) Alan adı ve yönlendirme (redirect) zinciri kontrolü

http -> https veya domain değişimleri (www/non-www) test sırasında protokol düşürmeye sebep olabilir.

• Test edeceğiniz URL’yi doğrudan doğru canonical adrese sabitleyin.

3) CDN/Proxy katmanı varsa: edge HTTP/3’e izin veriyor mu?

Cloudflare, Fastly benzeri CDN’ler HTTP/3’ü uç noktada sağlayabilir. Ancak bazı konfigürasyonlarda sadece destek vardır, otomatik kullanım devre dışı olabilir.

• CDN tarafındaki ayarlar ve sertifika durumu belirleyicidir.

Yöntem 1: Tarayıcıda protokol kanıtını yakalayın

Tarayıcılar HTTP/3’ü her zaman “aynen” görünür kılmaz; yine de doğru yerde doğru bilgiyle protokol tespit edebilirsiniz.

Chrome/Edge DevTools ile

1. Siteyi açın: https://domain.com
2. Geliştirici Araçları (DevTools) → Network sekmesi.
3. Sayfayı yenileyin (Network kayıt alacak şekilde).
4. Filtreye document yazın veya ilgili isteği seçin.
5. Sağ panelde protokol satırında HTTP versiyonu/taşıma bilgisi görünür (çoğu sürümde “h3” veya benzeri ifade yer alır).

Beklenen sonuç: Seçtiğiniz doküman isteği HTTP/3 üzerinden geliyorsa “h3” veya HTTP/3’e işaret eden protokol bilgisi görünür.

Yaygın hata: Görünen protokol HTTP/2 ise HTTP/3 aktif değildir ya da fallback olmuştur.

Pratik doğrulama

• Network kayıtlarında ilk sayfa isteğini (ör. HTML dokümanı) kontrol edin.
• Aynı oturumda birden fazla istekte farklı protokoller görülebilir; asıl ölçüt doküman (ana istek) tarafıdır.

Yöntem 2: curl ile doğrudan “HTTP/3 kullanıldı mı?” test edin

Komut satırı, en net ve tekrarlanabilir doğrulama yöntemidir.

curl ile HTTP/3 denemesi

Aşağıdaki komut; curl’un HTTP/3 yeteneğini kullanarak isteği zorlamayı hedefler:

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

Bazı sistemlerde --http3 desteklenmeyebilir. O durumda curl sürümünüz HTTP/3 derlenmiş olmalıdır.

Çıktıda arayacağınız ifadeler

• “HTTP/3” veya “h3” benzeri bir protokol göstergesi
• Alternatif olarak QUIC ile ilgili bir işaret

Beklenen sonuç: Protokol HTTP/3 olarak raporlandığında, bu istek gerçekten QUIC üzerinden taşınmıştır.

fallback yakalama (önemli)

HTTP/3 başarısız olursa istek HTTP/2/1.1’e düşebilir. Bunu netleştirmek için şu yaklaşımı uygulayın:

• Önce --http3 ile deneyin.
• Sonra yine aynı URL için --http2 ile deneyin.
• Çıktıları karşılaştırın.

Örnek:

curl -I --http3 https://domain.com/
curl -I --http2 https://domain.com/

Yöntem 3: “Gerçek kullanıcıya en yakın” test (coğrafya ve ISP etkisi)

HTTP/3’ün aktif görünmesi; bölgeye, ISP’ye, yerel ağ koşullarına ve edge’in erişilebilirliğine bağlıdır.

Bu nedenle tek bir coğrafyada bakmak yerine en az iki farklı ağdan test yapın:

• Mobil internet (4G/5G) üzerinden
• Sabit hat (ev/iş interneti) üzerinden
• Mümkünse farklı şehirlerden

Beklenen sonuç: HTTP/3 her yerde aynı anda çalışır; ama pratikte edge kapasitesi/rota değişimleri nedeniyle bir bölgede HTTP/3 görülürken diğer bölgede fallback görülebilir. Bu durumda “tam aktif” değil “kısmi aktif” teşhisi koyabilirsiniz.

Yöntem 4: CDN / Reverse proxy / Load balancer tarafında sinyal

VPS veya kendi reverse proxy’nizi çalıştırıyorsanız (Nginx/Apache/Haproxy gibi), HTTP/3 konfigürasyonu ile loglardan doğrulama yapabilirsiniz.

Not: Bu adım sağlayıcıdan sağlayıcıya ve kullandığınız edge yazılımına göre değişir. Aşağıdaki mantık, hangi bileşende HTTP/3 bittiğini bulmanıza yardım eder.

Hangi bileşen HTTP/3’ü bitiriyor?

Genellikle şu senaryolardan biri vardır:

• CDN/Edge bitiriyor: İstemci QUIC ile CDN’e gelir, origin HTTP/2/1.1 görür.
• Reverse proxy bitiriyor: İstemci QUIC ile doğrudan sizin Nginx/Haproxy katmanıza gelir.
• Her iki durumda da kontrol gerekir: Hem edge hem origin logları farklı protokoller gösterebilir.

Loglardan hedefleyin

Arama yapacağınız log anahtar kelimeleri genellikle şunlardır:

• h3
• quic
• http3
• (Nginx tarafında) QUIC stream/UDP ile ilgili satırlar
• (Haproxy tarafında) QUIC ile ilgili session işaretleri

Örnek mantık: - Reverse proxy loglarında “HTTP/3 kabul edildi” türü bir satır görürseniz aktifliği kanıtlamış olursunuz. - Origin web server loglarında HTTP/2/1.1 görmeniz tek başına sorun değildir; HTTP/3 CDN/reverse proxy’de bitiyor olabilir.

Net doğrulama planı: “doğru test, doğru sonuç” sırası

Aşağıdaki sırayı izlerseniz, test sonucunu tek seferde netleştirirsiniz.

1. Test edeceğiniz URL’yi kesinleştirin: https://domain.com/ (redirect zincirsiz)
2. curl ile --http3 denemesi yapın.
3. curl çıktısında HTTP/3/h3 ifadesini doğrulayın.
4. Aynı oturum/aynı URL için tarayıcı Network’te doküman isteğini kontrol edin.
5. Farklı bir ağdan tekrar edin (mobil vs sabit).
6. Varsa reverse proxy/CDN loglarında h3/quic anahtarlarını arayın.

Bu sıranın avantajı: Tek bir araç “yanıltıcı” rapor verse bile diğer araçlar birlikte tabloyu düzeltir.

Karşılaştırma tablosu: hangi test neyi kanıtlar?

Aşağıdaki tablo, her yöntemin “kanıt gücünü” pratikte nasıl yorumlayacağınızı gösterir.

Sık görülen sorunlar ve net teşhis

HTTP/3 testi sırasında en çok karşılaşılan problemler ve nasıl ayırt edeceğiniz aşağıdadır.

Sorun 1: curl --http3 başarısız, HTTP/2 geliyor

Net teşhis: HTTP/3 yolu açılamıyor ya da edge/sertifika/port tarafında eksik var.

• Önce HTTPS doğruluğunu kontrol edin.
• CDN/edge ayarlarında HTTP/3’ü etkinleştirin.
• Güvenlik duvarı/port erişimi açısından UDP 443 trafiğini engellemeyin.

Sorun 2: Tarayıcı bazen HTTP/3 gösteriyor, bazen göstermiyor

Net teşhis: Oturum başlatma sırasında farklı rota veya cache/fallback dinamiği var.

• Farklı ağlarda test edin.
• Aynı URL’de birkaç kez deneme yapın.
• Mümkünse temiz oturum (incognito) ile kontrol edin.

Sorun 3: Origin loglarında HTTP/1.1/HTTP/2 görünüyor

Net teşhis: HTTP/3 CDN veya reverse proxy’de bitiyor.

• “Origin HTTP/2 görüyorsa HTTP/3 yoktur” sonucu çıkarmayın.
• HTTP/3’ü bitiren katmanın loglarına bakın.

HTTP/3 aktifliği için sağlayıcıya/konfigürasyona dair kontrol listesi

HTTP/3’ü gerçekten aktif yapmak için sağlayıcıdan veya kendi altyapınızdan beklemeniz gereken net başlıklar:

• CDN/edge HTTP/3 (QUIC) desteği ve etkinliği
• TLS 1.3 ve HTTPS zorlaması
• UDP 443 erişimi (engelleme yok)
• Gerekli reverse proxy parametreleri (HTTP/3 listener vb.)
• Doğru domain ve redirect düzeni

Ne yaparsanız en hızlı sonuca ulaşırsınız?

Eğer amacınız “benim sitem için HTTP/3 gerçekten çalışıyor mu?” ise en hızlı rota şudur:

• curl -I --http3 https://domain.com/ komutunu çalıştırın.
• Çıktıda HTTP/3/h3 işaretini görün.
• Aynı URL’yi mobil veri ve sabit hatla tekrar edin.
• CDN/reverse proxy kullanıyorsanız loglarda h3/quic arayın.

Bu dört adım, çoğu senaryoda tek başına yeterli olur. Eğer HTTP/3 görünmüyorsa, sorunun yeri (CDN mi, reverse proxy mi, UDP erişimi mi, TLS mi) bu adımlarla daralır.

Sonuç olarak: HTTP/3’ün “aktif” olduğunu kanıtlayan test, tarayıcıdan alınan protokol işaretiyle + curl --http3 çıktısıyla başlar ve gerekiyorsa log doğrulamasıyla tamamlanır. Aksiyona dönük önerim; önce komut satırıyla (curl) hızlı bir kanıt alın, ardından tarayıcı Network ve farklı ağ testiyle tutarlılığı doğrulayın. Bu şekilde altyapınızda HTTP/3’ün gerçekten QUIC üzerinden çalıştığını net şekilde raporlayabilirsiniz.