www'lu mu www'suz mu? Hangisini Kullanmalısınız?

Yeni bir site kurdunuz, alan adını hostinge bağladınız, SSL sertifikası da yerinde. Tarayıcıya siteniz.com yazıyorsunuz, açılıyor. Sonra bir müşteriniz "www'lu hâli çalışmıyor" diye yazıyor ya da tam tersi — www.siteniz.com gayet iyi, siteniz.com bağlantı hatası veriyor. www'lu mu www'suz mu sorusunun altında yatan gerçek şudur: bunlar tarayıcının aynı gördüğü iki yazım biçimi değil, DNS açısından tamamen farklı iki host adıdır. Biri için tanımladığınız kayıt diğerini otomatik olarak kapsamaz. "www olmadan site açılmıyor" şikâyetinin nedeni neredeyse her zaman budur.

Bu yazıda ikisi arasındaki teknik farkı, apex (naked domain) adreste CNAME kullanamamanın CDN kurulumunu neden zorlaştırdığını, çerezlerin apex'te tüm alt alan adlarına yayılmasının ne anlama geldiğini, wildcard SSL ve HSTS preload etkilerini, hangi tarafı seçerseniz seçin Search Console'da nasıl doğrulama yapacağınızı ve yönlendirmeyi nginx, Apache, cPanel ve DNS seviyesinde nasıl doğru kuracağınızı adım adım anlatıyorum. Karar tablosuyla birlikte, "hangisi daha iyi" sorusuna somut bir cevap alacaksınız.

www'lu ve www'suz Adres Teknik Olarak Ne Kadar Farklı#

siteniz.com ve www.siteniz.com DNS hiyerarşisinde farklı iki düğümdür. siteniz.com bölgenin kökü, yani apex (aynı zamanda zone apex, naked domain, root domain, bare domain denir). www ise o bölgenin altındaki sıradan bir alt alan adıdır — teknik olarak blog, mail veya panel ile aynı statüdedir. www'nun tek ayrıcalığı, tarihsel gelenek gereği web sunucusuna verilen isim olmasıdır.

Bunu doğrulamak kolay. İki sorgu çalıştırın:

dig +short siteniz.com A
dig +short www.siteniz.com A

İlkinden IP dönerken ikincisinden hiçbir şey dönmüyorsa, www için hiçbir kayıt yoktur ve tarayıcı DNS_PROBE_FINISHED_NXDOMAIN benzeri bir hata verir. Sorunu "hostingde bir arıza var" diye aramaya başlamadan önce bu iki satırı çalıştırmak, saatler kazandırır. Konuyu daha derinlemesine görmek isterseniz dig ve nslookup ile DNS sorgulama yazısı sorgu türlerini tek tek gösteriyor.

Kayıt tipi tarafında da bir asimetri var:

Bu tablonun ikinci ve son satırı, kararın büyük kısmını tek başına belirler.

Apex (Naked) Domain Neden CNAME Kabul Etmez#

Kısa cevap: DNS standardı, bir isimde CNAME varsa o isimde başka hiçbir kayıt bulunmasına izin vermez. Apex'te ise zorunlu olarak SOA ve NS kayıtları bulunur; e-posta kullanıyorsanız MX, doğrulama yapıyorsanız TXT kayıtları da oradadır. Dolayısıyla apex'e CNAME koymak kuralı ihlal eder ve otoriter sunucu kaydı reddeder.

Pratikte bunun sonucu şudur: CDN, yük dengeleyici veya PaaS sağlayıcıları size genellikle hedef.saglayici.net gibi bir hostname verir, IP vermez. Çünkü arkadaki IP'ler değişir. www için bu bir CNAME ile çözülür:

www    IN    CNAME    hedef.saglayici.net.

Apex için aynı şeyi yapamazsınız. Üç çıkış yolu vardır:

1. ALIAS / ANAME / CNAME flattening — DNS sağlayıcınızın kendi çözümü. Kayıt kullanıcıya CNAME gibi görünür, sorgu geldiğinde sağlayıcı hedefi kendisi çözüp A kaydı olarak döner. Standart bir kayıt tipi değildir, her sağlayıcıda bulunmaz. Detayı ALIAS ve ANAME kaydı yazısında var.
2. Sabit A kaydı — Hedefin IP'sini elle yazarsınız. Sağlayıcı IP değiştirdiğinde siteniz düşer; kendi sunucunuz gibi IP'si sabit bir yapıda sorun değildir, CDN önünde risklidir.
3. Apex'i yönlendirmeye ayırmak — siteniz.com sadece 301 üreten küçük bir uçtur, gerçek trafik www'da yaşar. En dayanıklı yaklaşımdır ve büyük sitelerin www tercih etme sebebi budur.

Buradaki asıl mesele "hangisi güzel görünüyor" değil, ileride CDN, WAF veya yük dengeleme eklemek istediğinizde elinizde manevra alanı kalıp kalmadığıdır.

Çerezler: Apex'te Yazılan Çerez Tüm Alt Alan Adlarına Yayılır#

Bir çerez siteniz.com üzerinde Domain=siteniz.com ile yazıldığında, tarayıcı onu blog.siteniz.com, panel.siteniz.com, cdn.siteniz.com gibi tüm alt alan adlarına gönderir. www.siteniz.com üzerinde Domain niteliği olmadan yazılan çerez ise yalnızca o hostta kalır.

Bunun üç somut sonucu var:

• Statik dosya isteklerinde gereksiz yük. Aynı alan adı altındaki bir statik alt alan adına yapılan her istek, oturum çerezini de taşır. Yüzlerce görsel isteği düşünüldüğünde bu, hiçbir işe yaramayan bir başlık trafiğidir.
• Önbellekleme kalitesi. Ara katmanlar ve CDN'ler, çerez taşıyan istekleri farklı ele alır; kimi yapılandırmalarda çerezli yanıt hiç önbelleğe alınmaz.
• Güvenlik yüzeyi. Panel, staging veya müşteri paneli gibi alt alan adlarınız varsa, apex'te tanımlanan geniş kapsamlı bir oturum çerezi hepsine gider. Alt alan adlarından biri üçüncü tarafa ait bir uygulamayı barındırıyorsa, bu istenmeyen bir paylaşımdır.

www kullanmak bu yayılmayı otomatik olarak engellemez — uygulamanız yine Domain=siteniz.com yazabilir — ama varsayılan davranış www tarafında dar kapsamlıdır ve bu iyi bir varsayılandır. Alt alan adı oluşturma planlıyorsanız bu detayı en baştan hesaba katın.

CDN, WAF ve Yük Dengeleme Tarafında Farkı Ne Zaman Hissedersiniz#

CDN'e geçiş anında hissedersiniz. www tarafında iş tek satırdır: CNAME'i sağlayıcının verdiği hostname'e çevirirsiniz, bitmiştir. Apex tarafında ise sağlayıcınızın ALIAS desteği yoksa IP yazmak zorunda kalırsınız; sağlayıcı IP havuzunu güncellediğinde kimse size haber vermez ve site bir sabah 522 benzeri bir hatayla karşılaşır.

Aynı sorun bir felaket senaryosunda da çıkar. Sunucunuz düştü, trafiği ikinci bir makineye almak istiyorsunuz. www CNAME ise hedefi değiştirip TTL kadar beklemek yeterlidir. Apex'te A kaydını değiştirmek de mümkündür ama çoklu bölge, sağlık kontrolü ve otomatik devretme senaryolarında CNAME esnekliği aranır. Trafiğin coğrafi olarak en yakın düğüme yönlendirilmesi konusunda anycast DNS yazısındaki mantık, apex kısıtıyla birlikte okununca anlamlı hâle gelir.

Not: DNS seviyesinde saklanan gerçek şudur — ziyaretçinin adres çubuğunda ne gördüğü ile isteğin hangi altyapıya düştüğü ayrı şeylerdir. www'yu CDN'e verip apex'i sadece 301'e ayırmak, bu ikisini birbirinden temiz biçimde ayırmanın en yaygın yoludur.

SEO Açısından Fark Var mı#

Arama motorları açısından www'lu ve www'suz sürüm arasında doğal bir üstünlük yoktur; önemli olan ikisinden birinin tek kanonik adres olarak seçilmesi ve diğerinin ona 301 ile yönlendirilmesidir. Sorun, seçim yapmamaktır.

İkisi de aynı içeriği 200 koduyla döndürüyorsa şu olur:

• Aynı sayfa iki ayrı URL'de indekslenir, iç linkleriniz ikiye bölünür.
• Dış bağlantıların bir kısmı www'ya, bir kısmı apex'e gelir; otorite tek adreste toplanmaz.
• Search Console'da trafik iki mülke dağılır, raporlar yanıltıcı olur.
• Sosyal paylaşım sayaçları ve bazı analitik entegrasyonları ikiye böler.

Çözüm iki katmanlıdır ve ikisi birden gereklidir: sunucu seviyesinde 301 yönlendirme ve HTML'de <link rel="canonical"> etiketi. Yönlendirme kullanıcıyı ve botu tek adrese taşır, canonical ise yönlendirmeyi atlayan durumlar (parametreli URL'ler, sayfalama, harici kopyalar) için niyeti açıkça bildirir.

<link rel="canonical" href="https://www.siteniz.com/urunler/kirmizi-canta" />

Canonical'ın mutlak URL ve seçtiğiniz şema (https) ile yazılması önemlidir. http:// yazılı bir canonical, sitesi HTTPS'e taşınmış onlarca kurulumda gördüğüm sessiz hatalardan biridir. HTTPS yönlendirme yazısında bu geçişin tam yapılandırması var.

Hangisini Seçmelisiniz: Karar Tablosu#

Ortada kesin bir "doğru" yok; durumunuza göre değişir.

Son satırın altını çiziyorum: yıllardır gördüğüm en pahalı karar, çalışan bir sitede kanonik tarafı "daha modern görünsün" diye değiştirmektir. Yönlendirme doğru kurulursa kayıp sınırlı olur ama sıfır olmaz; geçiş sonrası birkaç hafta boyunca sıralamalarda oynama normaldir. Sebepsiz yapmayın.

Yönlendirmeyi Doğru Kurma#

Kural: tek adımda, 301 ile, doğru şemaya. Zincir yapmayın.

nginx#

Ayrı bir server bloğu açın; if ile yönlendirme yapmaktan kaçının.

# apex -> www (HTTP ve HTTPS birlikte)
server {
    listen 80;
    listen 443 ssl;
    server_name siteniz.com;

    ssl_certificate     /etc/letsencrypt/live/siteniz.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/siteniz.com/privkey.pem;

    return 301 https://www.siteniz.com$request_uri;
}

server {
    listen 443 ssl;
    server_name www.siteniz.com;
    root /var/www/siteniz/public;
    # ...
}

Dikkat edilecek nokta: yönlendirme yapan bloğun da geçerli bir sertifikaya ihtiyacı vardır. Sertifika yalnızca www için alınmışsa, tarayıcı apex'e girildiğinde 301'i görmeden önce sertifika hatası verir. Bu, "yönlendirme kurdum ama kullanıcılar uyarı alıyor" şikâyetinin bir numaralı sebebidir.

Apache / .htaccess#

RewriteEngine On

# apex -> www + https, tek adımda
RewriteCond %{HTTP_HOST} ^siteniz\.com$ [NC]
RewriteRule ^(.*)$ https://www.siteniz.com/$1 [R=301,L]

# www üzerinde http -> https
RewriteCond %{HTTPS} !=on
RewriteCond %{HTTP_HOST} ^www\.siteniz\.com$ [NC]
RewriteRule ^(.*)$ https://www.siteniz.com/$1 [R=301,L]

İki kuralı ayrı yazmak, http://siteniz.com isteğinin https://siteniz.com → https://www.siteniz.com şeklinde iki sıçrama yapmasını engeller. Kuralları elle yazmak istemiyorsanız htaccess yönlendirme üretici aracıyla bloğu üretip dosyaya yapıştırabilirsiniz; kural mantığının tamamı htaccess yönlendirme yazısında.

cPanel#

cPanel kullanıyorsanız üç ekran işinizi görür:

1. Zone Editor → www için A veya CNAME kaydının var olduğundan emin olun. Yoksa apex'e A kaydı, www'ya siteniz.com. hedefli CNAME ekleyin.
2. Domains → Redirects → Type Permanent (301), kaynak alan adı apex, hedef https://www.siteniz.com/, "Only redirect with www" seçeneğini işaretlemeyin (yönü ters çevirir).
3. SSL/TLS Status → Sertifikanın hem apex hem www için düzenlendiğini kontrol edin. AutoSSL genelde ikisini birden kapsar; kapsamıyorsa yeniden çalıştırın.

DNS seviyesinde yönlendirme#

Bazı DNS sağlayıcıları "URL yönlendirme" / "web forwarding" kaydı sunar. Bu gerçek bir DNS kaydı değil, sağlayıcının küçük bir HTTP sunucusudur. Kullanışlıdır ama iki dezavantajı var: yönlendirmenin HTTPS bacağı sağlayıcının sertifikasına bağımlıdır ve yanıt kodunu her zaman kontrol edemezsiniz. Kendi sunucunuz varken sunucu seviyesinde yapmak daha temizdir.

Yönlendirmeyi doğrulama#

curl -sI http://siteniz.com | head -n 4
curl -sI https://siteniz.com | head -n 4
curl -sI http://www.siteniz.com | head -n 4

Her birinde tek bir HTTP/1.1 301 ve doğru Location: görmelisiniz. İki 301 üst üste geliyorsa zinciri kırın. Sonsuz döngüye girdiyseniz tarayıcı ERR_TOO_MANY_REDIRECTS hatası verir; en yaygın sebebi, hem sunucuda hem uygulama (WordPress gibi) içinde çakışan iki yönlendirme kuralı olmasıdır.

SSL, Wildcard Sertifika ve HSTS Preload Etkisi#

Sertifika tarafında kural nettir: yönlendirmenin başlangıç noktası da sertifika kapsamında olmalıdır. Yani apex'ten www'ya yönlendiriyorsanız sertifikanız hem siteniz.com hem www.siteniz.com isimlerini taşımalıdır. Let's Encrypt bunu tek sertifikada iki SAN ismi olarak verir:

certbot certonly --nginx -d siteniz.com -d www.siteniz.com
openssl x509 -in /etc/letsencrypt/live/siteniz.com/cert.pem -noout -text | grep -A1 "Subject Alternative Name"

Çıktıda iki ismi de görmelisiniz. Let's Encrypt ücretsiz SSL yazısı yenileme kurulumunu da anlatıyor.

Wildcard sertifika (*.siteniz.com) konusunda çok yapılan bir hata var: wildcard, apex'i kapsamaz. *.siteniz.com yalnızca tek seviyeli alt alan adlarını (www, blog, panel) kapsar; siteniz.com'un kendisini kapsamaz, a.b.siteniz.com'u da kapsamaz. Bu yüzden wildcard sertifikalar neredeyse her zaman apex ismi ek SAN olarak eklenerek düzenlenir. Ayrıntısı wildcard SSL nedir yazısında.

HSTS tarafı daha kalıcı sonuçlar doğurur. Strict-Transport-Security başlığını includeSubDomains ile yayınlarsanız, tarayıcı tüm alt alan adlarını HTTPS'e zorlar:

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

Bunu apex'te yayınladığınız anda, henüz sertifikası olmayan bir alt alan adı (eski bir test.siteniz.com gibi) tarayıcıda tamamen erişilemez hâle gelir ve kullanıcı uyarıyı tıklayıp geçemez. Preload listesine girmek ise geri dönüşü aylar süren bir taahhüttür. Önce tüm alt alan adlarınızın sertifikalı olduğundan emin olun, max-age değerini küçük başlatıp kademeli artırın. HSTS nedir yazısı bu geçişi güvenli sırayla yapmayı anlatıyor.

Google Search Console'da Her İki Tarafı Doğrulama#

Kanonik tarafı seçtiniz diye diğerini görmezden gelmeyin. Search Console'da iki seçenek var ve hangisini kullandığınız fark yaratır:

• Alan adı (Domain) mülkü — DNS'e bir TXT kaydı eklenerek doğrulanır. siteniz.com ve tüm alt alan adlarını, hem http hem https şemasını tek mülkte toplar. www/www'suz ayrımıyla uğraşmak istemiyorsanız doğru seçim budur.
• URL öneki mülkü — https://www.siteniz.com/ gibi tam bir önek doğrular. Yalnızca o şema ve o hostu kapsar.

Domain mülkü için doğrulama TXT kaydı DNS panelinize eklenir:

@    IN    TXT    "google-site-verification=XXXXXXXXXXXXXXXXXXXX"

Kayıt apex'e (@) eklenir, www'ya değil. Ekledikten sonra yayılmayı kontrol edin:

dig +short TXT siteniz.com

Pratik öneri: Domain mülkünü açın, ayrıca kanonik tarafınız için bir URL öneki mülkü daha açın. Domain mülkü size bütün resmi verir; URL öneki mülkü ise yönlendirmenin gerçekten çalışıp çalışmadığını gösterir, çünkü yönlendirilen taraf için gösterim sayısı zamanla sıfıra yaklaşmalıdır. Yaklaşmıyorsa yönlendirmede boşluk vardır. TXT ile doğrulama yönteminin ayrıntıları TXT ile alan adı doğrulama yazısında.

Bir de sitemap detayı var: sitemap.xml içindeki tüm URL'ler kanonik host ile yazılmalıdır. www'ya yönlendirdiğiniz hâlde sitemap'te apex URL'leri listeliyorsanız, her tarama isteği önce bir 301 harcar.

Sık Yapılan Beş Hata#

1. Sadece bir tarafa A kaydı açmak. www kaydı yoksa "www olmadan site açılmıyor"un tersi yaşanır. Her iki isim de DNS'te çözülmeli, sonra biri diğerine 301 vermeli.
2. 302 kullanmak. Geçici yönlendirme, arama motoruna "asıl adres hâlâ eski" der. Kalıcı taşımada her zaman 301.
3. Yönlendirmeyi uygulama içinde ve sunucuda aynı anda kurmak. WordPress'te Site Adresi www'lu, nginx'te apex'e yönlendiriliyorsa döngü kaçınılmazdır. Bir katman seçin.
4. Yönlendiren tarafı sertifikasız bırakmak. Kullanıcı 301'i görmeden sertifika uyarısıyla karşılaşır ve çoğu geri döner.
5. Karma içerik. HTTPS'e geçerken sayfa içi mutlak http:// bağlantıları kalırsa tarayıcı mixed content hatası verir; kilit simgesi kırılır. Veritabanında arama-değiştirme yapıp mutlak URL'leri güncelleyin.

Sıkça Sorulan Sorular#

www kullanmak siteyi yavaşlatır mı#

Hayır, ölçülebilir bir yavaşlama yaratmaz. Aradaki tek ek maliyet, yanlış tarafa gelen isteğin bir 301 yanıtı kadar gecikmesidir ve bu tipik olarak milisaniyelerle ifade edilir. Aksine, statik içeriği çerezsiz bir hostta sunma imkânı verdiği için büyük sitelerde www yapılandırması genellikle daha hızlı sonuç üretir. Gerçek performans farkı yönlendirmede değil, önbellekleme ve CDN kurulumundadır.

Zaten yayında olan bir sitede www tercihini değiştirmeli miyim#

Teknik bir zorunluluk yoksa değiştirmeyin. İndekslenmiş, dış bağlantı almış bir sitede kanonik host değiştirmek, doğru 301 kurulsa bile geçiş döneminde sıralama oynamalarına yol açar ve tüm iç bağlantıların, sitemap'in, canonical etiketlerinin, analitik mülklerinin ve reklam hedeflerinin güncellenmesini gerektirir. Değiştirmeye değecek tek senaryo, apex'te CNAME kısıtı yüzünden CDN veya yük dengeleme kuramıyor olmanızdır.

Apex adrese neden CNAME ekleyemiyorum#

Çünkü DNS standardı, bir isimde CNAME varsa aynı isimde başka kayıt bulunmasını yasaklar; apex'te ise SOA ve NS kayıtları zorunlu olarak vardır. Bu yüzden otoriter sunucu apex'e CNAME eklemeyi reddeder. Sağlayıcınız ALIAS, ANAME veya CNAME flattening adıyla bir çözüm sunuyorsa aynı sonucu alabilirsiniz; sunmuyorsa hedefin IP'sini A kaydı olarak yazmanız ya da apex'i yalnızca yönlendirme için kullanmanız gerekir.

İki adres de açılıyorsa bu SEO'ya zarar verir mi#

Evet, ikisi de 200 kodu döndürüyorsa aynı içerik iki URL'de indekslenir ve bağlantı değeri bölünür. Google çoğu zaman birini kendi seçer ama bu seçimi siz yapmadığınız sürece hangi tarafın seçileceği garanti değildir ve raporlarınız ikiye bölünür. Sunucu seviyesinde 301 yönlendirme kurup HTML'e mutlak bir canonical etiketi eklemek, sorunu kalıcı olarak çözer.

Wildcard sertifika apex adresi de kapsar mı#

Hayır, *.siteniz.com yalnızca tek seviyeli alt alan adlarını kapsar, siteniz.com'un kendisini kapsamaz. Bu yüzden wildcard sertifikalar genellikle apex ismi ayrı bir SAN girdisi olarak eklenerek düzenlenir. Sertifikanızın hangi isimleri taşıdığını openssl x509 -noout -text çıktısındaki Subject Alternative Name bölümünden doğrulayabilirsiniz; yönlendirmenin başladığı isim orada yoksa kullanıcı 301'i görmeden sertifika uyarısı alır.

www yönlendirmesi e-posta ayarlarını etkiler mi#

Hayır, HTTP yönlendirmesi e-posta akışına dokunmaz. E-posta yönlendirmesi MX kayıtlarıyla belirlenir ve bunlar apex isimde tanımlıdır; web trafiğini www'ya yönlendirmeniz MX kaydını değiştirmez. Ancak apex'teki DNS kayıtlarıyla oynarken MX, SPF ve DKIM TXT kayıtlarını yanlışlıkla silmemeye dikkat edin — apex bölgesinde yapılan toplu düzenlemeler sırasında en sık kaybedilen kayıtlar bunlardır.

HSTS başlığını hangi tarafta yayınlamalıyım#

Kanonik tarafta, yani kullanıcının sonunda kaldığı hostta yayınlayın; yönlendiren tarafa da eklemek zararsızdır ama tarayıcı zaten yönlendirmeyi izleyecektir. includeSubDomains yönergesini eklemeden önce tüm alt alan adlarınızın geçerli sertifikaya sahip olduğunu doğrulayın, aksi hâlde sertifikasız bir alt alan adı tarayıcıda tamamen erişilemez hâle gelir. max-age değerini küçük başlatıp kademeli artırmak, geri dönüşü olan bir yol bırakır.

DNS değişikliğinden sonra ne kadar beklemeliyim#

Beklenecek süreyi kaydın TTL değeri belirler; tipik olarak 300 ile 3600 saniye arasındadır ve değişiklik öncesinde TTL'i düşürürseniz geçiş çok daha hızlı olur. Kendi tarafınızda hemen görmek için işletim sisteminizin ve tarayıcınızın DNS önbelleğini temizleyin, ardından dig +short www.siteniz.com ile otoriter sunucudan doğrudan sorgulayın. Ziyaretçilerin tamamının yeni kaydı görmesi, ara çözücülerin önbellek davranışına bağlı olarak birkaç saati bulabilir.

Kapanış#

www'lu mu www'suz mu sorusunun cevabı "hangisi daha güzel" değil, "hangisi size manevra alanı bırakıyor" sorusudur. İkisi de DNS'te ayrı hostlardır; her ikisi için de kayıt tanımlamak, birini kanonik seçip diğerini tek adımda 301 ile ona yönlendirmek ve canonical etiketiyle bunu HTML'de tekrar beyan etmek zorunludur. Apex'te CNAME kullanılamaması, ileride CDN veya yük dengeleme ekleyeceğiniz her senaryoda karşınıza çıkar; çerez kapsamının apex'te tüm alt alan adlarına yayılması ise çok alt alan adlı yapılarda hem performans hem güvenlik tarafında sonuç doğurur. Halihazırda yayında olan bir sitede tercihi değiştirmek ise teknik bir zorunluluk yoksa gereksiz risktir.

Bu kurulumu kendiniz yapmak yerine hazır gelmesini istiyorsanız: alan adını kaydettiğiniz yerden yönetmek en az sorun çıkaran yoldur, alan adı kayıt ve yönetim sayfasından bakabilirsiniz. Yönlendirmenin başladığı tarafın da sertifikalı olması gerektiği için hem apex hem www ismini kapsayan bir sertifika şart; SSL sertifikası sayfasında hangi tipin size uyduğunu görebilirsiniz. Paylaşımlı ortamda çalışıyorsanız Zone Editor ve 301 ekranlarının hazır geldiği web hosting paketleri, kendi nginx yapılandırmanızı yazmak istiyorsanız VDS sunucu tarafı bu yazıdaki tüm örnekleri birebir uygulayabileceğiniz ortamı verir.