Nameserver Değişince Site ve Mail Kapanır mı?

Hosting değiştirmeye karar verdiniz, yeni sağlayıcı size iki satır nameserver adresi verdi ve şimdi o "Kaydet" düğmesine basmaya elinizin gitmediği anı yaşıyorsunuz. Haklısınız: nameserver değişince site kapanır mı sorusu, hosting taşımanın önündeki en büyük psikolojik engeldir ve sorunun kısa cevabı da net değildir. Doğru yapılırsa ziyaretçileriniz hiçbir şey fark etmez; yanlış yapılırsa site birkaç saat "sunucu bulunamadı" verir, daha kötüsü o süre boyunca gelen e-postalar geri döner veya sessizce kaybolur. Fark, düğmeye basma anında değil, ondan önce yaptığınız hazırlıkta gizlidir.

Bu yazıda ns değiştirince mail gelir mi, e-postalar silinir mi, kaç saat kesinti olur gibi soruların hepsini tek bir teknik gerçeğe bağlayacağız: nameserver değişikliği bir "taşıma" değil, otoritenin devridir. Yeni nameserver'da hangi kayıtlar varsa dünya onları görür; eski bölgede kalan hiçbir şey taşınmaz. Buradan hareketle kesintiyi sıfıra indiren sıralı bir plan çıkaracağız: TTL'i önceden düşürme, yeni bölgede tüm kayıtları birebir oluşturma, eski sunucuyu erken kapatmama ve geçişi doğrulama. Türkçe rehberlerin çoğu "propagasyon 4-48 saat sürer, bekleyin" deyip bırakıyor; biz o 48 saati kesintisiz geçirmenin yolunu anlatacağız.

Kısa Cevap: NS Değişikliği Tek Başına Kesinti Yaratmaz#

Nameserver değişikliği, yeni nameserver'da tüm DNS kayıtlarınız hazırsa kesinti yaratmaz. Kesintiyi yaratan şey değişikliğin kendisi değil, yeni DNS bölgesinin eksik olmasıdır.

Bunu şöyle düşünün: alan adınızın nameserver'ı, "bu alan adı hakkındaki soruların cevabını kim veriyor" sorusunun cevabıdır. NS'i değiştirdiğinizde dünya soruyu artık yeni sunucuya sorar. Yeni sunucuda A kaydı varsa site açılır. MX kaydı varsa posta gelir. Yoksa — cevap "bilmiyorum" olur ve tarayıcı DNS_PROBE_FINISHED_NXDOMAIN, gönderen posta sunucusu da "no MX record" hatası verir. Eski nameserver'daki kayıtlar hâlâ orada durur ama artık kimse onlara sormaz.

Kritik nokta şudur: geçiş anında dünyanın bir kısmı eski nameserver'ı, bir kısmı yenisini kullanır. Bu ikili durum saatlerce, bazen bir günden fazla sürer. Eğer iki bölge aynı cevabı veriyorsa kimse bir şey fark etmez; farklı cevap veriyorsa ziyaretçilerin bir kısmı eski siteyi, bir kısmı yenisini görür. Bu ikinci duruma düşerseniz DNS değişti ama site eski sunucuda açılıyor yazısındaki teşhis adımları işinize yarayacaktır.

Nameserver Değişince Teknik Olarak Ne Olur#

Nameserver kaydı DNS bölgenizin içinde değil, alan adı registry'sinde tutulur. Yani .com uzantısı için Verisign'ın, .com.tr için TRABİS'in tuttuğu kayıtta durur. Bu yüzden NS değişikliği, sıradan bir A kaydı değişikliğinden farklı bir yolu izler.

Bir ziyaretçinin tarayıcısı alan adınızı çözerken şu zinciri yürür:

1. Kök sunuculara sorar: ".com.tr uzantısına kim bakıyor?"
2. Uzantının registry sunucusuna sorar: "ornekfirma.com.tr alan adının nameserver'ları neler?"
3. Dönen nameserver'a sorar: "www.ornekfirma.com.tr hangi IP'de?"
4. Dönen IP'ye bağlanır.

NS değişikliği 2. adımdaki cevabı değiştirir. Bu cevabın da bir TTL'i vardır ve uzantıya göre genellikle 24 ila 48 saat arasındadır — üstelik bu değeri siz kontrol edemezsiniz, uzantıyı yöneten kurum belirler. İşte "propagasyon 48 saat sürebilir" cümlesinin gerçek kaynağı budur: sizin A kaydınızın TTL'i 300 saniye olsa bile, NS delegasyonunun önbelleği çok daha uzun yaşar.

Değişikliğin registry'ye ne zaman işlendiğini görmek için delegasyonu doğrudan sorgulayın:

dig NS ornekfirma.com.tr +trace
dig NS ornekfirma.com.tr @8.8.8.8 +short

+trace çıktısı, kökten başlayarak hangi sunucunun hangi cevabı verdiğini adım adım gösterir; registry'nin hâlâ eski nameserver'ları döndürdüğünü buradan net olarak görürsünüz. Windows tarafında aynı bilgiyi şöyle alırsınız:

nslookup -type=ns ornekfirma.com.tr 8.8.8.8

Zincirin mantığını daha ayrıntılı görmek isterseniz nameserver değiştirme ve DNS propagasyon kontrol araçları yazıları bu adımları örneklerle açıyor.

Kesintinin Asıl Kaynağı: Yeni Bölgede Eksik Kayıtlar#

Nameserver değişikliğinde yaşanan kesintilerin neredeyse tamamı, yeni DNS bölgesinde eksik kayıt bırakılmasından kaynaklanır. Yeni sağlayıcı, alan adını hesabınıza eklediğinizde genellikle otomatik bir bölge oluşturur — ama bu bölge yalnızca kendi sunucusunu bilir.

Otomatik oluşturulan tipik bir bölgede şunlar bulunur: @ ve www için A kaydı, kendi mail sunucusuna işaret eden bir MX kaydı, kendi ürettiği bir SPF ve belki bir ftp/cpanel alt alan adı. Bulunmayanlar ise şunlardır ve kesintiyi yaratan tam olarak bunlardır:

• Kurumsal e-posta sağlayıcınızın MX kayıtları
• E-posta doğrulama TXT kayıtları (SPF, DKIM selector, DMARC)
• Google Search Console, Microsoft ve benzeri servislerin doğrulama TXT kayıtları
• Alt alan adları: blog, panel, api, crm, vpn, webmail gibi başka IP'lere işaret eden kayıtlar
• CNAME'ler: CDN, yardım masası, form servisi, e-posta pazarlama takip alt alan adı
• SRV kayıtları (özellikle Microsoft tabanlı yapılarda autodiscover ve _sip)
• CAA kaydı — varsa ve taşınmazsa yeni SSL sertifikası üretiminiz reddedilebilir

Bu yüzden geçişten önce yapılacak ilk iş, eski bölgenin tam bir envanterini çıkarmaktır. Eski sağlayıcının panelinde "zone dosyasını dışa aktar" seçeneği varsa kullanın. Yoksa kayıtları tek tek sorgulayın:

for t in A AAAA MX TXT NS CNAME SRV CAA SOA; do
  echo "--- $t ---"
  dig $t ornekfirma.com.tr +short
done

Alt alan adlarını bu şekilde bulamazsınız çünkü DNS'te "bana tüm kayıtları listele" diye bir sorgu (zone transfer, AXFR) dışarıya açık değildir. Alt alan adlarının listesini eski panelin zone editöründen almak zorundasınız. Bunu atlarsanız site ve mail çalışırken crm.ornekfirma.com.tr sessizce ölür ve bunu ancak birkaç gün sonra bir çalışanınız fark eder. DNS zone dosyası yazısındaki kayıt türleri listesi, envanteri çıkarırken kontrol listesi olarak kullanılabilir.

E-postalar Neden Silinmez Ama Kaybolabilir#

Nameserver değişikliği posta kutularınızdaki mevcut e-postaları silmez. Mesajlar sunucunun diskinde durur ve DNS'in onlarla hiçbir ilgisi yoktur. Ama geçiş sırasında yeni gelen postaları kaybedebilirsiniz ve bu, kalıcı bir kayıptır.

Senaryo şudur: NS'i değiştirdiniz, yeni bölgede MX kaydı yeni hosting sunucusuna işaret ediyor (otomatik oluşturuldu), oysa kurumsal e-postanız hâlâ eski sistemde. Dünyanın DNS'i güncellendikçe gönderenler postayı yeni hosting sunucusuna teslim etmeye başlar. Yeni sunucu alan adını "yerel" bildiği için postayı kabul eder ve kimsenin bakmadığı, henüz oluşturulmamış kutulara yönlendirir; oradan da catch-all ayarına göre ya bir çöp kutusuna düşer ya da sessizce silinir. Gönderen taraf hiçbir hata görmez — mesaj başarıyla teslim edilmiş görünür. Bu, geçişlerin en sinsi hasarıdır çünkü kimse fark etmez.

Bunu önlemenin yolu tek: NS'i değiştirmeden önce yeni bölgede MX kayıtlarını gerçek posta sağlayıcınıza göre elle yazın ve yeni hosting sunucusunda alan adının posta yönlendirmesini "uzak" olarak işaretleyin. Postanın nereye teslim edildiğini teşhis etmenin ayrıntıları için e-postalarım gelmiyor: MX kaydı kontrol rehberi yazısına bakabilirsiniz; oradaki yönlendirme ayarı bölümü tam olarak bu senaryoyu anlatıyor.

İkinci bir kayıp kaynağı da posta kutularının kendisidir. E-postaları da yeni sunucuya taşıyorsanız, taşıma işlemi (IMAP senkronizasyonu veya sunucu düzeyinde yedek geri yükleme) NS değişikliğinden önce tamamlanmalıdır. Aksi halde geçiş süresince bir kısım mesaj eski sunucuya, bir kısmı yenisine düşer ve iki kutuyu birleştirmek zorunda kalırsınız.

Kesintisiz Geçiş Planı: Doğru Sıralama#

Aşağıdaki sıralama, kesintiyi sıfıra indiren standart plandır. Adımların sırası önemlidir; herhangi birini öne almak kesinti riskini geri getirir.

1. Envanteri çıkarın (geçişten 3-7 gün önce). Eski bölgedeki tüm kayıtları listeleyin: A, AAAA, MX, TXT, CNAME, SRV, CAA ve tüm alt alan adları. Ekran görüntüsü değil, metin olarak kaydedin.
2. TTL'i düşürün (geçişten en az 24-48 saat önce). Eski bölgedeki tüm kayıtların TTL'ini 300 saniyeye indirin. Bunu neden yaptığımızı bir sonraki bölümde ayrıntısıyla anlatıyorum.
3. Yeni hosting hesabını hazırlayın. Site dosyalarını ve veritabanını taşıyın, yeni sunucuda çalıştığını doğrulayın. Bunu DNS'e dokunmadan, hosts dosyanıza satır ekleyerek test edebilirsiniz:

Linux ve macOS'ta /etc/hosts, Windows'ta C:\Windows\System32\drivers\etc\hosts dosyasına şu satırı ekleyin:

203.0.113.45   ornekfirma.com.tr www.ornekfirma.com.tr

Bu satırla yalnızca sizin bilgisayarınız yeni sunucuya bağlanır; ziyaretçiler etkilenmez. Sitenin yeni sunucuda gerçekten çalıştığını görmeden geçişe başlamayın.

4. Yeni nameserver'da bölgeyi tam olarak kurun. Envanterdeki her kaydı yeni sağlayıcının DNS panelinde oluşturun. A kayıtlarının IP'sini yeni sunucuya çevirin; MX, TXT ve CNAME kayıtlarını birebir eski değerleriyle yazın.
5. Yeni bölgeyi NS değişmeden test edin. Yeni nameserver'ı doğrudan sorgulayın:

dig A ornekfirma.com.tr @ns1.yeni-saglayici.com +short
dig MX ornekfirma.com.tr @ns1.yeni-saglayici.com +short
dig TXT ornekfirma.com.tr @ns1.yeni-saglayici.com +short

Cevaplar beklediğiniz gibiyse geçebilirsiniz. Bu adım, tüm planın en değerli kısmıdır ve neredeyse hiç yapılmaz.

6. Nameserver'ı değiştirin. Alan adı panelinizden yeni NS adreslerini girin. Alan adı transfer kilitli ise sorun değil — NS değişikliği kilitten etkilenmez.
7. Eski sunucuyu açık bırakın. En az 72 saat, mümkünse bir hafta. Sebebini aşağıda ayrı bir başlıkta anlatıyorum.
8. SSL sertifikasını yeni sunucuda üretin. Doğrulama DNS veya HTTP üzerinden yapıldığı için, propagasyon tamamlanmadan sertifika üretimi başarısız olabilir; ilk denemede olmazsa birkaç saat sonra tekrarlayın.
9. Doğrulayın ve TTL'i normale çekin. Kontrol listesi yazının sonunda.

TTL'i Önceden Düşürmek: Geçişin En Az Bilinen Adımı#

TTL'i geçişten önce düşürmek, geri dönüş süresini saatlerden dakikalara indirir ve bu, planın en çok atlanan adımıdır.

TTL (Time To Live), bir DNS kaydının çözümleyicilerde ne kadar süre önbellekte tutulacağını saniye cinsinden söyler. Varsayılan değer çoğu panelde 14400 (4 saat) veya 86400 (24 saat)'tür. Şimdi şu senaryoyu düşünün: NS'i değiştirdiniz, yeni sunucuda beklenmedik bir hata çıktı ve geri dönmek istiyorsunuz. Eski A kaydının TTL'i 86400 ise, geri döndüğünüzde bile kayıtlar bir gün boyunca önbellekte kalmaya devam eder. Yani hatanız 24 saat yaşar.

TTL'i 300 saniyeye düşürmüş olsaydınız, geri dönüşünüz 5 dakikada etkili olurdu. Bu yüzden profesyonel geçiş planında TTL düşürme adımı, geçişten en az bir TTL süresi kadar (yani mevcut TTL 24 saatse en az 24 saat) önce yapılır — çünkü eski TTL'in kendisi de önbellektedir ve yeni düşük değerin dünyaya yayılması eski TTL kadar sürer. Bu ayrıntı da neredeyse hiçbir yerde yazmaz.

Bir uyarı: TTL düşürmek NS delegasyonunun kendi TTL'ini etkilemez. Registry tarafındaki NS kaydının süresi uzantıyı yöneten kurumun belirlediği değerdir ve bunu değiştiremezsiniz. TTL düşürmenin faydası, geçiş sonrasında kendi bölgenizdeki kayıtları hızlı düzeltebilmenizdir. TTL mantığının tamamı için TTL nedir yazısına bakın.

Eski Sunucuyu Ne Zaman Kapatabilirsiniz#

Eski sunucuyu, dünyanın tamamı yeni nameserver'a geçtiğini doğrulayana kadar kapatmayın; pratikte bu en az 72 saat, güvenli tarafta bir haftadır.

Sebebi şu: NS delegasyonunun önbelleği uzun yaşar ve bazı kurumsal ağlar, mobil operatörler ve eski cihazlar TTL'e uymaz. Siz "propagasyon bitti" derken ziyaretçilerinizin küçük bir yüzdesi hâlâ eski IP'ye gidiyor olabilir. Eski sunucu ayaktaysa o ziyaretçiler eski (ama çalışan) siteyi görür — kötü ama katlanılabilir. Eski sunucu kapalıysa ERR_CONNECTION_REFUSED veya zaman aşımı görürler.

Bu süre boyunca eski sunucuda yapmanız gerekenler:

• Siteyi kapatmayın, ama içerik yönetimini durdurun. İki farklı sunucuda iki farklı veritabanına yazılan yorum/sipariş kaybolur.
• E-postayı "uzak" olarak işaretleyin ya da eski sunucudaki alan adını tamamen kaldırın. Aksi halde eski IP'yi gören gönderenler postayı oraya bırakmaya devam eder.
• Eski posta kutularını silmeyin. Geçiş süresince oraya düşmüş mesajlar olabilir; kapatmadan önce IMAP ile son bir senkronizasyon yapın.
• Log'ları izleyin. Eski sunucunun erişim log'unda trafik sıfıra indiğinde gerçekten güvenle kapatabilirsiniz:

tail -f /home/kullanici/access-logs/ornekfirma.com.tr | grep -v "bot\|crawler"

E-ticaret sitesi taşıyorsanız bu ek bir kural getirir: geçiş penceresini gecenin en sakin saatine alın ve eski sunucuda sipariş almayı kapatın. İki sunucuda paralel sipariş almak, hangi veritabanının doğru olduğunu belirsizleştirir ve muhasebe açısından geri dönülmez bir karışıklık yaratır.

Geçiş Sonrası Doğrulama Kontrol Listesi#

Geçiş "bitti" demek için aşağıdaki maddelerin tamamının yeşil olması gerekir. Sadece siteyi tarayıcıda açıp görmek yeterli değildir; tarayıcınızın kendi DNS önbelleği sizi kolayca kandırır.

1. NS delegasyonu güncel mi: dig NS ornekfirma.com.tr @8.8.8.8 +short yeni sunucuları dönmeli.
2. A kaydı doğru IP'yi mi veriyor: dig A ornekfirma.com.tr +short yeni sunucunun IP'sini dönmeli.
3. www ve köksüz adres ikisi de açılıyor mu: Tarayıcıda hem ornekfirma.com.tr hem www.ornekfirma.com.tr denenmeli.
4. MX doğru mu: dig MX ornekfirma.com.tr +short beklediğiniz posta sunucusunu dönmeli.
5. Gerçek bir test maili gelmeli. Dış bir adresten kendinize yazın; yalnızca DNS sorgusuna güvenmeyin.
6. SPF/DKIM/DMARC kayıtları yerinde mi: dig TXT ornekfirma.com.tr +short çıktısında v=spf1 satırı görünmeli.
7. SSL geçerli mi: Tarayıcıda kilit simgesi ve sertifika alan adı doğru olmalı; karışık içerik uyarısı olmamalı.
8. Alt alan adları çalışıyor mu: Envanterdeki her alt alan adını tek tek açın.
9. Yönlendirmeler korunmuş mu: Eski .htaccess veya nginx yönlendirme kurallarınız yeni sunucuya taşındı mı, 301'ler hâlâ çalışıyor mu.
10. Arama konsolu hata veriyor mu: Geçişten 48 saat sonra tarama hatalarını kontrol edin.

Bunlardan biri kırmızıysa panik yapıp NS'i geri almayın; büyük ihtimalle eksik olan tek bir kayıttır ve TTL'i 300'e düşürdüğünüz için düzeltmeniz 5 dakikada yayılır. Coğrafi olarak dağıtık bir DNS altyapısının bu yayılmayı nasıl hızlandırdığını merak ediyorsanız anycast DNS nedir yazısı konuya iyi bir giriş.

Sıkça Sorulan Sorular#

Nameserver değiştirince sitem kaç saat kapalı kalır#

Doğru hazırlıkla sıfır saat kapalı kalır. Kesinti, yeni nameserver'da kayıtlar eksik olduğunda ortaya çıkar; tüm kayıtlar önceden birebir oluşturulduysa ziyaretçi hangi nameserver'a düşerse düşsün aynı çalışan cevabı alır. Eski sunucuyu da açık bırakırsanız, geçiş dönemindeki karışık durumda bile hiç kimse hata sayfası görmez. Hazırlıksız yapılan bir değişiklikte ise kesinti 4 saatten 48 saate kadar uzayabilir.

Nameserver değişince e-postalarım silinir mi#

Hayır, mevcut e-postalarınız silinmez. DNS kayıtları yalnızca postanın hangi sunucuya teslim edileceğini belirler; posta kutularınızdaki mesajlar sunucunun diskinde durur ve DNS değişikliğinden etkilenmez. Ancak yeni bölgede MX kaydı yanlışsa, geçiş süresince gelen yeni mesajlar yanlış sunucuya teslim edilip kaybolabilir. Posta kutularını da taşıyorsanız senkronizasyonu NS değişikliğinden önce tamamlayın.

Nameserver değişikliğini geri alabilir miyim#

Evet, nameserver değişikliği her zaman geri alınabilir; eski nameserver adreslerini panele tekrar yazmanız yeterlidir. Geri dönüşün etkili olması, registry'deki NS kaydının önbellek süresi kadar zaman alır ve bu genellikle birkaç saattir. Geri dönüş ihtimalini kolaylaştırmak için eski DNS bölgesini silmeyin ve eski sunucuyu kapatmayın. Bu iki şeyi koruduğunuz sürece geçiş tersine çevrilebilir bir işlemdir.

Nameserver değişikliği alan adı transferi anlamına gelir mi#

Hayır, bu iki işlem tamamen farklıdır. Nameserver değişikliği yalnızca alan adınızın DNS kayıtlarını kimin yönettiğini değiştirir; alan adının kayıtlı olduğu firma aynı kalır. Alan adı transferi ise alan adının sahipliğinin başka bir kayıt firmasına taşınmasıdır ve EPP kodu, transfer kilidinin açılması gibi ek adımlar gerektirir. Hosting değiştirmek için transfer yapmanız gerekmez, nameserver değişikliği yeterlidir.

Nameserver değişmeden önce yeni sunucuyu test edebilir miyim#

Evet, bilgisayarınızın hosts dosyasına alan adı ile yeni sunucunun IP adresini içeren bir satır ekleyerek test edebilirsiniz. Bu yöntem yalnızca sizin makinenizi etkiler, ziyaretçiler etkilenmez ve DNS'e hiç dokunulmaz. Böylece site, form gönderimleri, veritabanı bağlantısı ve yönlendirmeler gerçek alan adıyla test edilebilir. Test bittiğinde satırı silmeyi unutmayın, aksi halde geçiş sonrasında hep eski IP'ye gitmeye devam edersiniz.

İki nameserver seti aynı anda tanımlı olabilir mi#

Teknik olarak yazılabilir ama bunu yapmamalısınız. Farklı sağlayıcılara ait iki nameserver seti aynı anda tanımlıysa çözümleyiciler ikisinden birine rastgele sorar ve iki bölge farklı cevap veriyorsa ziyaretçiler tesadüfen farklı sunuculara düşer. Bu durum, teşhis edilmesi en zor DNS problemlerinden biridir çünkü sorun kimi kullanıcıda görülür kimi kullanıcıda görülmez. Nameserver setini tek seferde ve tamamen değiştirin.

TTL'i düşürmeyi unuttum, yine de geçiş yapabilir miyim#

Yapabilirsiniz ama geri dönüş penceresi uzun olur. TTL düşürülmediyse mevcut kayıtlar çözümleyicilerde varsayılan süre kadar, genellikle 4 ila 24 saat kalır ve bu süre boyunca yaptığınız düzeltmeler herkese ulaşmaz. Geçişi yine de yapabilirsiniz; koşul, yeni bölgede kayıtların eksiksiz olması ve eski sunucunun açık kalmasıdır. Acele etmiyorsanız TTL'i düşürüp bir gün bekleyip öyle geçmek her zaman daha güvenlidir.

Nameserver değişince SSL sertifikam geçersiz olur mu#

Nameserver değişikliği mevcut SSL sertifikanızı geçersiz kılmaz; sertifika sunucuda kurulu dosyadır ve DNS ile ilgisi yoktur. Ancak site yeni bir sunucuya taşınıyorsa sertifikanın da o sunucuya kurulması gerekir, aksi halde ziyaretçiler sertifika uyarısı alır. Otomatik sertifika kullanıyorsanız yeni sunucuda üretim, DNS yeni IP'yi gösterdikten sonra çalışır. Ayrıca CAA kaydınız varsa yeni bölgeye taşımayı unutmayın, aksi halde sertifika üretimi reddedilebilir.

Kapanış#

Nameserver değişikliği, korkulduğu kadar riskli bir işlem değil; sadece sırası olan bir işlem. Kesintiyi yaratan şey düğmeye basmak değil, yeni bölgeyi eksik bırakmaktır. Bu yüzden planın kalbi üç adımdır: geçişten önce eski bölgenin tam envanterini çıkarmak, TTL'i bir gün önceden 300 saniyeye düşürmek ve yeni nameserver'ı NS değişmeden doğrudan sorgulayarak test etmek. Bu üçünü yaptıysanız geri kalan her şey rutindir; yapmadıysanız hangi sağlayıcıyı seçerseniz seçin aynı kesintiyi yaşarsınız.

Geçişi kendiniz yönetmek istemiyorsanız ya da e-ticaret gibi kesintinin doğrudan maliyeti olan bir yapı taşıyorsanız, taşımayı planlı bir işe dönüştürmek en akıllıcası. Site taşıma hizmeti envanter çıkarma, DNS bölgesi kurma ve doğrulama adımlarını üstlenir; alan adı ve DNS yönetimini tek panelde toplamak isterseniz alan adı hizmetleri sayfasına bakabilirsiniz. Yeni ev arıyorsanız paylaşımlı yapılar için hosting paketleri, kendi kaynaklarınızı ve DNS'inizi tam kontrol etmek istiyorsanız VDS sunucu seçenekleri geçiş sonrası için doğru başlangıç noktalarıdır.