IPv6-only sunucular hosting geleceği mi? Net teknik rehber

IPv6-only sunucular, 2026’da giderek daha sık konuşuluyor. Çünkü bazı ağlarda IPv4 adresleri tükenirken IPv6 geçişi hız kazanıyor. Bu yazıda IPv6-only mimarinin ne anlama geldiğini, teknik kazanımları ve gerçek operasyon risklerini net şekilde ele alacağım. Ayrıca Türkiye’de erişim kalitesini ölçmek için uygulanabilir test adımlarını paylaşacağım.

IPv6-only nedir, tam olarak neyi değiştirir?

IPv6-only demek, sunucunun yalnızca IPv6 adresi üzerinden erişilebilir olmasıdır. Yani sunucu tarafında (VDS/VPS/dedicated) genellikle: - IPv4 (A/AAAA karışımı değil) dinlenmez veya yönlendirilmez. - DNS’te AAAA kaydı kullanılır; A kaydı ya hiç yoktur ya da kullanılmaz. - Trafik akışı tamamen IPv6 üzerinden çalışır.

Bu yaklaşım, klasik “dual-stack” (IPv4 + IPv6 birlikte) mimariden farklıdır. Dual-stack’te erişim hem IPv4 hem IPv6 üzerinden yapılabildiği için uyumluluk daha yüksektir. IPv6-only’da ise erişim, hedef kullanıcının ağının IPv6 kalitesine doğrudan bağlı olur.

IPv6-only mimariyi kim seçer?

IPv6-only çoğunlukla şu nedenlerle tercih edilir: - IPv4 maliyeti ve adres yönetim yükünü azaltmak - IPv6’ya geçen mobil operatör/İSS ağlarında daha öngörülebilir erişim sağlamak - Sunucu tarafında ağ katmanını basitleştirmek

Ancak bu gerekçeler, “her sistemde doğru” anlamına gelmez. Aşağıdaki bölümlerde performans ve operasyon etkilerini net karşılaştıracağım.

IPv6-only’ın avantajları: nerede gerçekten kazanırsınız?

IPv6-only yaklaşımının faydaları, doğru senaryoda daha net görünür.

1) IPv4 adres tükenmesi ve NAT yükü azalır

IPv4 tarafında bazı ağlar yoğun NAT kullandığında aynı kullanıcıdan çıkan farklı istekler farklı davranabilir. IPv6-only senaryoda NAT katmanı zorunlu olmaz; bu da bazı durumlarda ağ düzeyinde daha tutarlı bağlantı davranışı sağlar.

2) Daha temiz DNS yönlendirme mantığı

DNS tarafında sadece AAAA kaydına odaklanmak; yanlış A kaydı, yanlış yönlendirme ve “hangi IP’den geliyor” karmaşasını azaltır. Özellikle çoklu alt alan adı kullanan yapılarda yönetim sadeleşir.

3) Bazı kullanıcılar için gecikme düşebilir (her zaman değil)

IPv6’nın daha kısa yol seçimiyle sonuçlandığı ağlar olur. Ama bu otomatik garanti değildir. Türkiye’de hangi kullanıcının hangi erişim sağlayıcısını kullandığı, hatta kullanıcının LTE/5G ağı, gecikmeyi değiştirebilir.

IPv6-only’ın riskleri: tek problemi doğru ölçmezsen operasyon aksar

IPv6-only, “çalışır” olmak ile “her kullanıcıda tutarlı çalışır” olmak arasında fark yaratır.

1) IPv6 erişimi zayıf kullanıcılar sitenize ulaşamaz

IPv6-only’da IPv4 fallback yoktur. Kullanıcının hattında IPv6 etkin değilse, web sitesi açılmayabilir ya da çok uzun süre bağlantı deneme yapılabilir. Bu, özellikle: - Şirket ağları (kurumsal firewall/NAT politikaları) - Bazı kampüs ağları - IPv6’yı kısmen kullanan mobil/ISS kombinasyonları

gibi alanlarda görünür.

2) CDN/WAF/Load balancer entegrasyonu dikkat ister

Sunucu IPv6-only olsa bile, ön plandaki CDN/WAF/Load balancer katmanı IPv6-only ile uyumlu olmalıdır. En yaygın sorunlar şunlardır: - CDN tarafında AAAA trafiği düzgün iletilmiyor - Origin (sunucu) bağlantısı IPv6 ile kuruluyor ama sertifika/SNI/host header eşleşmesi eksik - Health check IPv4 üzerinden bekleniyor (ve IPv6-only origin “down” sanılıyor)

3) Log, izleme ve hata ayıklama alışkanlıkları değişir

Operasyon ekibi IPv6 log formatı, istemci IP görünümü, trafik sınıflandırması gibi konularda hazırlıklı olmalıdır. IPv4-only’da alışılan “IP bazlı hızlı teşhis” bazı araçlarda farklı görünür.

IPv6-only mı dual-stack mi? Kararı senaryoya göre verin

Aşağıdaki tablo, net bir seçim yaklaşımı sağlar.

Net kural: geçişi “tam kesmeden” yapın

En sağlam yaklaşım, önce dual-stack ile ölçüm yapıp ardından keskin geçişin etkisini doğrulamaktır. IPv6-only’a geçmeden önce şu kontrol noktalarını tamamlayın.

Türkiye’de gerçek kullanıcı erişimini nasıl test edersiniz? (adım adım)

Sadece kendi tarayıcınızla test etmek yanıltır. Hedef, Türkiye içindeki farklı ağlardan (operatör/ISS) gerçek erişimi ölçmektir.

1) DNS kontrolü: A ve AAAA kaydı durumunu netleştirin

• Alan adınızda AAAA kaydı doğru IPv6 adresine işaret ediyor mu?
• IPv6-only’a geçiyorsanız A kaydı tamamen kaldırılır mı, yoksa bir süre açık mı tutulur?

DNS doğrulama için tarayıcı yerine komut satırı daha tutarlı sonuç verir.

Örnek test: - dig AAAA ornek.com - dig A ornek.com

2) IPv6 bağlantı kontrolü: curl ile menzil testi

Aşağıdaki yaklaşım, TCP seviyesinde IPv6 erişimini görmenizi sağlar. - curl -6 -I https://ornek.com/ - Hata görmüyorsanız IPv6 üzerinden HTTP durum kodu dönüyor demektir.

IPv6-only hedefliyorsanız aynı zamanda şunu kontrol edin: - curl -4 -I https://ornek.com/ IPv4 üzerinden cevap almamanız beklenen davranıştır.

3) CDN/WAF varsa “client-IP vs origin-IP” yolunu doğrulayın

Cloudflare, Fastly benzeri CDN’lerde şu sorular kritik olur: - CDN ile origin arasında IPv6 bağlantı kuruluyor mu? - Origin health check IPv6 ile mi yapılıyor? - Hangi edge lokasyonlarında AAAA trafiği gerçekten çalışıyor?

Bu kısmı sağlayıcı arayüzündeki “health check / origin connectivity” bölümünden ve log örneklerinden doğrulayın.

4) Tarayıcı testi yerine TTFB ve hata oranlarını kıyaslayın

IPv6 geçişinin performans etkisini “sayfa açılıyor” ile ölçmek yetersizdir. En azından şu metrikleri 2-7 gün arası karşılaştırın: - TTFB (Time to First Byte) - İlk sayfa yükleme süresi (en azından RUM/analitik tarafında) - IPv6 üzerinden 4xx/5xx hata oranı

TTFB düşüşü her zaman gelmez; bazı ağlarda IPv4 daha hızlı kalabilir. O yüzden metrik şarttır.

5) Loglarda istemci IP versiyonunu ayrıştırın

Sunucunuzda erişim logları IPv6 istemcileri ayrı gösterecek şekilde tutulmalıdır. Böylece: - IPv6 yapan kullanıcı sayısı - IPv4 denemesi (başarısız mı?) - Hangi uçta hata var

netleşir.

IPv6-only’a geçerken kontrol listesi: “hazır” olup olmadığınızı sayısal görün

Aşağıdaki listeyi tamamlamadan geçiş yapmayın.

DNS ve sertifika

• AAAA kaydı doğru çalışıyor
• Sertifika (TLS) SNI ile doğru host adını alıyor
• CDN/WAF tarafında AAAA trafiği etkin

Reverse proxy / web sunucusu

• Nginx/Caddy/HAProxy gibi bileşenlerde IPv6 listener tanımlı
• HTTP redirect mantığı (HTTP->HTTPS) IPv6’da da aynı davranıyor
• HSTS ayarları IPv6 üzerinden de tutarlı

Uygulama ve bağlantılar

• Uygulama doğru base URL ile çalışıyor (IPv6 literal kullanımından kaçının)
• Veritabanı bağlantısı dual-stack mi IPv6-only mı? Uygulama tarafında yanlış IP ailesi kullanılmıyor
• Queue/Cache servisleri (Redis/Memcached) IPv6 adresinden erişiliyor

İzleme ve hata yönetimi

• Monitöring (uptime check) IPv6 ile doğru endpoint’i kontrol ediyor
• Loglar IPv6 formatını doğru kaydediyor
• Alert eşikleri IPv6 kaynaklı gecikme artışlarını yanlış alarm saymıyor

Sık yapılan yanlışlar: IPv6-only’ı “fark etmeden” kırmak

1) Sadece sunucuya IPv6 açıp DNS’te AAAA’yı eksik/yanlış bırakmak. 2) IPv6-only origin’e giden CDN health check’in yanlış protokol/yanlış IP ailesini beklemesi. 3) Redirect/URL üretiminde IPv4 literal IP kullanılması (ör. http://203.x.x.x) . 4) Analytics/RUM konfigürasyonunda client IP parsing’in IPv6’da bozulması.

Sonuç: IPv6-only hosting geleceği mi? Evet; ama “ölçümden sonra”

IPv6-only, hosting ekosisteminin yönünü temsil ediyor: IPv4 fallback’in ortadan kalkması, ağ modernizasyonunu hızlandırıyor ve yönetimi sadeleştiriyor. Ancak tek bir testle karar vermek yerine, Türkiye’de farklı ağlardan erişim ve performans metriklerini doğruladığınızda net bir fayda görürsünüz.

Aksiyon önerisi: Önce dual-stack ile 7 gün boyunca TTFB ve hata oranlarını ölçün; AAAA trafiği stabilse, CDN/WAF ve health check entegrasyonları hazırsa IPv6-only’a kademeli geçiş planlayın. Bu sırayla hem “erişim kırılmasını” önlersiniz hem de gerçek kullanıcı verisiyle karar verirsiniz.