Tek IP Üzerinde Birden Fazla HTTPS Site Barındırmak: SNI Nedir?

Tek IP Üzerinde Birden Fazla HTTPS Site: Neden Bu Kadar Önemli Hale Geldi?

Bir sunucu planlarken elinizde çoğu zaman sınırlı sayıda IPv4 adresi, buna karşılık onlarca alan adı ve proje olur. Özellikle ajanslar, SaaS uygulamaları ve çok markalı yapılar için "Her site için ayrı IP mi almalıyım, yoksa tek IP üzerinde birden fazla HTTPS site barındırabilir miyim?" sorusu çok sık karşımıza çıkıyor. Modern tarayıcıların neredeyse tamamı Server Name Indication (SNI) desteğine sahip olduğu için, doğru kurgulanmış bir mimariyle tek IP üzerinde çok sayıda TLS/SSL korumalı siteyi problemsiz şekilde yayınlamak mümkün.

Bu noktada iki kritik başlık var: SNI'nin teknik olarak nasıl çalıştığını anlamak ve hangi senaryolarda hâlâ ayrı IP (dedicated IP) kullanmanın mantıklı olduğunu doğru tespit etmek. Özellikle IPv4 adreslerinin pahalanması ve kıt hale gelmesiyle birlikte, IP adresi stratejisi doğrudan maliyet kalemine dönüştü. IPv4 tükenmesi ve fiyat artışları hakkında yazdığımız detaylı rehberde de anlattığımız gibi, gereksiz IP tüketmek artık lüks. Bu yazıda SNI kavramını sade bir dille açacağız, tek IP üzerinde çoklu HTTPS mimarilerini örnekleyeceğiz ve hangi durumlarda SNI yerine ayrı IP veya farklı SSL stratejilerine yönelmeniz gerektiğini netleştireceğiz.

SNI Nedir? Kısa, Net ve Teknik Olarak Doğru Tanım

SNI (Server Name Indication), TLS el sıkışması (TLS handshake) sırasında istemcinin bağlanmak istediği alan adını (hostname) sunucuya göndermesini sağlayan bir uzantıdır. Yani tarayıcı, "Ben example.com'a bağlanmak istiyorum" bilgisini daha TLS oturumu kurulmadan önce sunucuya iletir.

Bu bilgi sayesinde web sunucusu (Nginx, Apache, LiteSpeed vb.), aynı IP ve port üzerinde birden fazla sanal host tanımlayabilir ve her biri için farklı bir sertifika sunabilir. Klasik dünyada HTTPS için "1 IP = 1 sertifika/site" kuralı pratikte geçerliyken, SNI ile birlikte "1 IP = sınırsız sayıda HTTPS site" mümkün hâle geldi.

SNI olmasaydı tarayıcı, TLS oturumunu başlatırken bağlanmak istediği alan adını söyleyemeyeceği için sunucu ya tek bir ortak sertifika sunmak zorunda kalırdı (SAN veya wildcard) ya da her farklı sertifika için ayrı bir IP kullanmak durumunda olurdu. SNI bu darboğazı çözen standarttır ve modern HTTPS ekosisteminin temel parçalarından biridir.

SNI Nasıl Çalışır? (Adım Adım Teknik Akış)

1. Klasik HTTPS ve IP = Sertifika Eşlemesi Sorunu

HTTPS bağlantı şu sırayla ilerler:

• Tarayıcı, hedef sunucunun IP adresine 443 numaralı port üzerinden TCP bağlantısı açar.
• Tarayıcı, TLS "ClientHello" mesajını gönderir ve sunucudan sertifikasını ister.
• Sunucu bir sertifika gönderir, el sıkışma tamamlanır ve şifreli HTTP trafiği başlar.

SNI öncesinde tarayıcı, ClientHello mesajında hangi alan adına gitmek istediğini söylemezdi. Sunucu da hangi hostname için hangi sertifikayı göndermesi gerektiğini bilemezdi. Çözüm olarak, aynı IP üzerinde yalnızca tek bir sertifika sunmak pratikte zorunlu hale gelmişti.

2. SNI ile Ekstra Bilgi: Hangi Hostname'e Gideceğim

SNI, TLS protokolüne eklenmiş bir uzantıdır. Tarayıcı ClientHello mesajına küçük bir alan daha ekler:

• "server_name: example.com"

Yani TLS el sıkışması daha başlarken, sunucuya "Ben şu hostname için geliyorum" demiş olur. Sunucu da bu bilgiyi kullanarak doğru sanal hostu ve sertifikayı seçebilir.

3. Web Sunucusu Tarafı: Sanal Host ve Sertifika Eşlemesi

Sunucu tarafında Nginx veya Apache gibi yazılımlar, SNI bilgisini kullanarak vhost tablosu üzerinden doğru yapılandırmayı seçer. Çok basitleştirilmiş bir Nginx örneğiyle bakalım:

server {
    listen 443 ssl http2;
    server_name site1.com www.site1.com;
    ssl_certificate     /etc/ssl/site1.crt;
    ssl_certificate_key /etc/ssl/site1.key;
}

server {
    listen 443 ssl http2;
    server_name site2.com www.site2.com;
    ssl_certificate     /etc/ssl/site2.crt;
    ssl_certificate_key /etc/ssl/site2.key;
}

Her iki server bloğu da aynı IP ve portta dinliyor olabilir. Gelen istekteki SNI alanında site1.com yazıyorsa birinci blok, site2.com yazıyorsa ikinci blok devreye girer. Böylece tek IP üzerinde, tamamen farklı sertifikalara sahip birden fazla HTTPS siteyi sorunsuz yayınlayabilirsiniz.

Tek IP Üzerinde Birden Fazla HTTPS Site Barındırmanın Avantajları

SNI desteği, pratikte şu kazanımları sağlar:

• IPv4 tasarrufu: Her site için ayrı IP almak zorunda kalmazsınız. IPv4 fiyatlarının ciddi şekilde yükseldiği dönemde bu çok somut bir maliyet avantajı sağlar. Detay için IPv4 adres fiyatları ve bütçenizi koruma stratejileri yazımıza da göz atabilirsiniz.
• Daha sade ağ mimarisi: Az sayıda IP ile onlarca site yönetmek, güvenlik duvarı, NAT ve yönlendirme kurallarını sadeleştirir.
• Reseller ve ajanslar için ölçeklenebilirlik: Onlarca müşteriniz varsa, her biri için ayrı IP yönetmek yerine SNI ile tek IP üzerinde çoklu site barındırma daha yönetilebilir olur.
• SSL otomasyonu ile uyum: Let's Encrypt ve ACME istemcileri ile otomatik sertifika yenileme kurduğunuzda SNI, her alan adının kendi sertifikasıyla aynı IP üzerinde yaşamasına izin verir. Bu mimarileri Let's Encrypt ile ücretsiz SSL kurulumu ve otomatik yenileme rehberimizde uygulamalı anlattık.
• Esneklik: Farklı siteler için farklı türde sertifikalar (DV, OV, EV, Wildcard, SAN) kullanabilirsiniz. Özellikle çok alan adlı yapılarda Wildcard mı SAN (Multi-Domain) mi? yazımızdaki stratejilerle SNI'yi birlikte düşünmek iyi sonuç verir.

Hangi Durumlarda SNI Sorun Çıkarabilir?

Gerçek hayatta SNI'nin problem yaratma ihtimali, hedef kitlenizin teknolojik profilinden doğrudan etkilenir. Modern tarayıcılar (Chrome, Firefox, Safari, Edge) ve güncel işletim sistemleri SNI'yi uzun süredir destekliyor. Yine de bazı senaryolarda dikkatli olmanız gerekiyor.

1. Eski Tarayıcı ve İşletim Sistemleri

Aşağıdaki ortamlar SNI desteği açısından risklidir:

• Windows XP üzerindeki eski Internet Explorer sürümleri
• Android 2.x vb. çok eski mobil işletim sistemleri
• Dahili tarayıcıya sahip eski gömülü cihazlar (set-top box, akıllı TV'lerin ilk nesilleri vb.)

Bu ortamlar, TLS el sıkışması sırasında SNI bilgisi göndermez. Sunucu, hangi hostname için sertifika sunması gerektiğini bilemez ve yanlış sertifika sunarsa kullanıcı sertifika hatası görür. Eğer hedef kitleniz çok eski cihazlar kullanıyorsa (örneğin belli yaş grubu için geliştirilmiş özel cihazlar, müze kioskları, kurumsal intranet PC'leri), bu cihazların SNI desteğini mutlaka test etmelisiniz.

2. Eski Kütüphaneler Kullanan API İstemcileri

Tarayıcılar dışında, SNI desteği olmayan istemciler de sorun çıkarabilir:

• Eski Java sürümleri ile yazılmış uygulamalar (özellikle Java 6 ve öncesi)
• Legacy ortamda çalışan, güncellenmemiş cURL / OpenSSL sürümleri
• Gömülü sistemlerde kullanılan minimal TLS istemcileri

Bu tür istemciler, HTTPS tabanlı bir API&#39ye bağlanırken de SNI göndermeyebilir. Eğer tek IP üzerinde çoklu alan adı için API sunuyorsanız, bu istemciler hangi hosta gittiğini söylemeden bağlanacağı için yanlış sertifika ile karşılaşabilir. Kritik entegrasyonlarınız varsa (ödeme geçidi, bankacılık, muhasebe servisleri vb.), canlıya çıkmadan mutlaka SNI uyumluluk testi yapın.

3. E-posta Protokolleri ve Diğer TLS Kullanım Alanları

SNI ağırlıklı olarak HTTPS dünyasında yaygın. E-posta tarafında (SMTP, IMAPS, POP3S) SNI desteği hâlâ tarayıcılar kadar homojen değil. Birçok modern e-posta istemcisi SNI gönderse de, yıllardır güncellenmeyen masaüstü e-posta yazılımları veya gömülü çözümler sorun çıkarabiliyor.

Bu nedenle e-posta altyapısında genellikle alan adı başına ayrı IP + ayrı sertifika yaklaşımı tercih edilir. Zaten e-posta tarafında IP itibarını yönetmek için bile çoğu zaman dedicated IP ısıtma ve e-posta itibarı yönetimi gibi stratejilere ihtiyaç duyulur. Yani e-posta özelinde SNI yerine IP tabanlı ayrışma hâlâ daha pratik olabilir.

4. Yük Dengeleyiciler, Proxy'ler ve SSL Offload Cihazları

Modern load balancer yazılımları (HAProxy, Nginx, Envoy vb.) ve donanımları SNI desteğine sahip. Ancak eski nesil SSL offload cihazları veya kurumsal reverse proxy ürünleri hâlâ SNI&#39yi düzgün işlemeyebiliyor.

Örneğin; edge tarafında eski bir cihazınız, arka tarafta ise çoklu domain barındırdığınız bir web sunucunuz varsa, aradaki TLS terminasyon noktasının SNI desteğinden emin olmanız gerekir. Aksi halde uçta doğru sertifika sunulsa bile, back-end bağlantıda hostname bilgisi kaybolabilir ve istenmeyen sertifika/host eşleşmeleri ortaya çıkabilir.

5. Uyumsuzluk Durumunda Alternatif: Ortak Sertifika (SAN veya Wildcard)

Eğer hedef kitlenizde SNI desteklemeyen önemli bir kitle varsa ama yine de tek IP üzerinde kalmak istiyorsanız, bir alternatif de çok alan adını kapsayan tek bir sertifika kullanmaktır:

• Birden fazla alan adı için SAN (Subject Alternative Name) sertifikası
• Aynı alan adının tüm alt alanları için wildcard sertifika (örneğin *.example.com)

Bu senaryoda sunucu, SNI desteği olmasa bile herkese aynı sertifikayı sunar ve sertifikanın içinde tüm alan adları tanımlı olduğu için hata oluşmaz. Ancak bu yaklaşımın da yönetilebilirlik ve güvenlik açısından artı/eksi yönleri var; bunları detaylı şekilde Wildcard SSL mi SAN sertifika mı? makalemizde irdeledik.

Hangi Durumda Hâlâ Ayrı IP (Dedicated IP) Tercih Etmelisiniz?

SNI çok güçlü olsa da, her zaman "her şeyi tek IP'ye toplayalım" demek doğru değil. Aşağıdaki durumlarda ayrı IP kullanmak hâlâ mantıklı:

• Eski cihaz ve yazılım kitlesi yüksekse: Müşterilerinizin önemli bir kısmı XP çağında kalmış cihazlar veya güncellenmeyen özel yazılımlar kullanıyorsa, kritik siteleri ayrı IP üzerinde barındırmak daha güvenlidir.
• Kurumsal SLA ve uyumluluk gereksinimleri: Bazı kurumsal sözleşmeler, "müşteriye ayrılmış IP" şartı içerebiliyor. Bu durumda sözleşme gereği dedicated IP kullanmak zorunda kalabilirsiniz.
• E-posta itibarı yönetimi: Yukarıda da değindiğimiz gibi e-posta altyapısında IP itibarı kritik. Bu yüzden transactional veya pazarlama e-postaları için genellikle web sitesinden ayrı bir IP (hatta bazen ayrı sunucu) kullanılmasını öneriyoruz.
• Güvenlik ve izolasyon gerekçeleri: Bazı kurumlar, kritik uygulamaların IP seviyesinde de izole olmasını ister. Bu durumda SNI ile IP paylaşımı yerine, ayrı IP üzerinde minimal yüzey alanı ile yayın yapmak daha uygun olabilir.

Özetle: Web siteleri için modern tarayıcı hedefliyorsanız SNI ile tek IP üzerinde çoklu HTTPS mimarisi gayet sağlıklı. Ancak uyumluluk, e-posta itibarı veya özel güvenlik ihtiyaçları devreye giriyorsa, IP stratejinizi buna göre karma modelde kurgulamalısınız.

Uygulamalı Örnek: Nginx ile SNI Tabanlı Çoklu HTTPS Site

Şimdi tek IP üzerinde iki farklı HTTPS siteyi Nginx ile nasıl tanımlayacağımıza bakalım. Varsayalım ki sunucunuzun IP adresi 203.0.113.10 ve aşağıdaki iki alan adınız var:

• site1.com
• site2.com

DNS tarafında her iki alan adı da aynı IP&#39ye A kaydı olarak yönlendiriliyor:

site1.com.   300  IN A  203.0.113.10
site2.com.   300  IN A  203.0.113.10

Sunucu tarafında ise Nginx konfigürasyonu şu şekilde olabilir:

server {
    listen 443 ssl http2;
    server_name site1.com www.site1.com;

    ssl_certificate     /etc/ssl/site1/fullchain.pem;
    ssl_certificate_key /etc/ssl/site1/privkey.pem;

    root /var/www/site1;
    index index.php index.html;
}

server {
    listen 443 ssl http2;
    server_name site2.com www.site2.com;

    ssl_certificate     /etc/ssl/site2/fullchain.pem;
    ssl_certificate_key /etc/ssl/site2/privkey.pem;

    root /var/www/site2;
    index index.php index.html;
}

Her iki server bloğu da aynı IP ve portu dinliyor. Aradaki fark yalnızca server_name ve kullanılan sertifikalar. Tarayıcı, SNI ile hangi hostname'e geldiğini söylediği için Nginx doğru bloğu seçebiliyor.

Benzer şekilde Apache tarafında da <VirtualHost *:443> tanımlarıyla, her sanal host için farklı sertifika ve ServerName yapılandırabilirsiniz. Bu tür yapılandırmaları daha geniş HTTPS bağlamında ele aldığımız modern HTTPS için SSL/TLS protokol güncellemeleri rehberimize de göz atmanızı öneririz.

SNI ile Birlikte Dikkat Etmeniz Gereken Diğer HTTPS Ayarları

Tek IP üzerinde birden fazla HTTPS site barındırırken, yalnızca sertifika ve SNI ayarlarını yapmak yetmez. Aşağıdaki başlıklar da önemlidir:

• TLS sürümleri: TLS 1.0 ve 1.1 artık güvenli kabul edilmiyor. Sunucuda TLS 1.2 ve mümkünse TLS 1.3 açık olmalı, zayıf şifre paketleri kapatılmalı.
• HTTP/2 ve HTTP/3: Birçok modern tarayıcı, HTTP/2 ve HTTP/3 (QUIC) ile ciddi performans kazanımı sağlar. Çoklu site mimarisinde de bu protokolleri aktif etmek, Core Web Vitals açısından önemlidir. Detaylar için HTTP/2 ve HTTP/3 desteğinin SEO ve Core Web Vitals etkileri yazımıza bakabilirsiniz.
• HSTS ve güvenlik başlıkları: Birden fazla siteyi aynı IP&#39de tuttuğunuzda, her site için ayrı HSTS, CSP ve diğer HTTP güvenlik başlıklarını tanımlamayı unutmayın. Hepsini tek bir global config yerine, site bazlı vhost config&#39lerinde yönetmek daha kontrol edilebilir olur.
• OCSP stapling ve sertifika zinciri: Sertifikalarınızın zincir dosyalarını (intermediate CA) doğru ekleyin ve mümkünse OCSP stapling kullanın. Bu, tarayıcı tarafında güvenlik ve performans açısından pozitif etki yaratır.

DCHost Altyapısında SNI Desteği ve Önerilen Mimari

DCHost olarak sunduğumuz paylaşımlı hosting, VPS, dedicated sunucu ve colocation hizmetlerinin tamamında SNI desteği varsayılan olarak açıktır. Yani ister tek bir kurumsal siteniz olsun, ister onlarca WordPress, WooCommerce veya özel yazılım barındırın; tek IP üzerinde farklı alan adları için ayrı ayrı TLS/SSL sertifikaları kullanabilirsiniz.

Özellikle ajanslar ve çok markalı yapılar için sık kullandığımız mimari şöyle:

• Müşteri siteleri tek veya birkaç güçlü VPS/dedicated sunucu üzerinde gruplanıyor.
• Her müşteri alan adı, aynı IP veya az sayıda IP üzerinde SNI ile ayrıştırılıyor.
• Sertifikalar Let's Encrypt/ACME otomasyonu ile düzenli ve otomatik olarak yenileniyor.
• Gerekli görülen kritik projelere (e-ticaret, ödeme sistemleri, yüksek cirolu mağazalar) isteğe bağlı olarak dedicated IP atanıyor.

Bu yaklaşım hem IPv4 maliyetlerini kontrol altında tutmanızı hem de ölçeklenebilir bir SSL mimarisi kurmanızı sağlıyor. Eğer çok sayıda alan adınız varsa ve otomatik SSL yönetimini de işin içine katmak istiyorsanız, ACME ve DNS-01 challenge tabanlı gelişmiş senaryoları anlattığımız Let's Encrypt wildcard SSL otomasyonu rehberi de iyi bir tamamlayıcı olacaktır.

Özet ve Yol Haritası: SNI ile IP Stratejinizi Nasıl Netleştirebilirsiniz?

Tek IP üzerinde birden fazla HTTPS site barındırmak, günümüz altyapılarında istisna değil, neredeyse varsayılan pratik hâline geldi. SNI sayesinde tarayıcılar, TLS el sıkışması aşamasında bağlanmak istedikleri alan adını sunucuya bildiriyor ve web sunucusu da bu bilgiyle doğru sertifikayı seçebiliyor. Böylece eskiden olduğu gibi "her site için ayrı IP" zorunluluğu büyük ölçüde ortadan kalkmış durumda.

Yine de mimari tasarlarken şu soruları kendinize sormanız önemli:

• Hedef kitlenizde ciddi oranda eski cihaz veya yazılım var mı?
• Hangi siteler kurumsal SLA veya uyumluluk gereksinimleri nedeniyle dedicated IP istemekte?
• E-posta itibarı yönetimi için hangi alan adları ayrı IP gerektiriyor?
• SSL otomasyonu (Let's Encrypt, ACME) ve çok alan adlı sertifikalarla nasıl bir kombinasyon kuracaksınız?

Eğer bu soruların yanıtı kafanızda net değilse, mevcut altyapınızı ve alan adı portföyünüzü birlikte gözden geçirip hem maliyet hem de esneklik açısından optimum bir IP/SNI stratejisi kurgulayabiliriz. DCHost'ta paylaşımlı hosting, VPS, dedicated sunucu ve colocation seçeneklerimizde SNI desteği standart olarak sunuluyor; geriye yalnızca ihtiyaçlarınıza en uygun mimariyi birlikte tasarlamak kalıyor. Projeleriniz için en doğru yaklaşımı konuşmak isterseniz, teknik ekibimizle detaylı bir kapasite ve mimari değerlendirme yapmaktan memnuniyet duyarız.