DNS Değişti Ama Site Eski Sunucuda Açılıyor: Neden?

Hosting taşımasının en gergin anı hep aynıdır: dosyaları ve veritabanını yeni sunucuya taşıdınız, nameserver'ları ya da A kaydını değiştirdiniz, panelde "kaydedildi" yazısını gördünüz — ama tarayıcıda siteyi açtığınızda karşınıza hâlâ eski sunucudaki hâli geliyor. Yeni sunucuya yüklediğiniz güncel içerik ortada yok, eski site sanki hiçbir şey olmamış gibi çalışıyor. Bu noktada "DNS değişti ama site eski sunucuda açılıyor" diye aratıp bulduğunuz Türkçe kaynakların neredeyse tamamı size aynı şeyi söyler: "propagasyon 48 saat sürer, bekleyin."

Bu cevap hem eksik hem çoğu zaman yanlıştır. Bekleme süresini belirleyen 48 saat gibi sabit bir kural değil, sizin kendi kayıtlarınıza yazdığınız TTL değeridir ve bunu taşımadan önce düşürmek geçişi kısaltan tek gerçek yöntemdir. Üstelik gördüğünüz eski sitenin sebebi çoğu zaman DNS bile olmaz: tarayıcının kendi DNS önbelleği işletim sistemininkinden ayrı çalışır, HSTS ve sayfa önbelleği DNS ile sürekli karıştırılır, eski sunucudaki sanal makine yapılandırması hâlâ ayakta durur. Bu yazıda zincirdeki her önbellek katmanını tek tek açıyorum, hangisini nasıl temizleyeceğinizi ve değişikliğin gerçekten uygulanıp uygulanmadığını farklı resolver'lardan nasıl kanıtlayacağınızı gösteriyorum.

Zincirde Kaç Ayrı Önbellek Var#

Bir alan adı adresine yazıldığında yanıt tek bir yerden gelmez; en az beş katman devrededir ve her biri bağımsız süreyle kayıt tutar. Sitenin eski sunucudan gelmesinin sebebi, bu katmanlardan herhangi birinin eski cevabı hâlâ tutuyor olmasıdır.

Tablodaki en kritik satır sonuncudan bir öncekidir: nameserver değişikliği ile A kaydı değişikliği aynı hızda yayılmaz. A kaydını değiştiriyorsanız yalnızca o kaydın TTL'i kadar beklersiniz; nameserver'ları değiştiriyorsanız üstteki TLD delegasyonunun TTL'i de devreye girer ve o değer genelde çok daha uzundur, üstelik siz onu değiştiremezsiniz. Bu yüzden aynı taşımada A kaydı 5 dakikada, nameserver 12 saatte oturabilir. Bu ayrımın ayrıntısı için nameserver değiştirme ve nameserver değişince site kapanır mı yazılarına bakabilirsiniz.

TTL: Geçişi Gerçekten Kısaltan Tek Yöntem#

TTL (Time To Live), bir DNS kaydının "bu cevabı kaç saniye önbellekte tutabilirsin" talimatıdır ve saniye cinsinden yazılır. Yaygın varsayılan 14400 (4 saat) veya 86400'dür (24 saat). Bir resolver kaydı aldığında TTL süresi boyunca sizin yaptığınız değişikliği görmez — sorup öğrenmek gibi bir seçeneği yoktur, çünkü zaten sormaz.

Buradan çıkan sonuç şudur: TTL'i değiştirdiğiniz an değil, değiştirmeden önce düşürdüğünüzde işe yarar. Taşıma sırasında TTL'i 300'e çekerseniz o değişikliğin kendisi de eski TTL kadar bekler; yani 24 saatlik TTL'i taşımanın sabahı 5 dakikaya indirmenin hiçbir faydası olmaz.

Doğru sıra şudur:

1. Taşımadan en az 24-48 saat önce ilgili kayıtların (A, AAAA, CNAME, MX) TTL değerini 300 saniyeye düşürün. Nameserver değiştirecekseniz bunu mevcut DNS sağlayıcınızda yapın.
2. Eski TTL süresi kadar bekleyin. Bu süre dolduğunda dünyadaki bütün resolver'lar artık kayıtlarınızı 5 dakikalık ömürle önbelleğe alıyor olur.
3. Taşımayı yapın, kaydı yeni IP'ye çevirin.
4. Değişiklik 5-10 dakikada geniş ölçüde görünür hâle gelir.
5. Geçiş oturduktan sonra TTL'i normal değerine (3600 veya 14400) geri yükseltin. Düşük TTL'i kalıcı bırakmak, otoriter sunucularınıza gereksiz sorgu yükü bindirir.

Mevcut TTL'i görmek için dig çıktısındaki ikinci sütuna bakın:

dig A example.com @1.1.1.1

;; ANSWER SECTION:
example.com.		2731	IN	A	203.0.113.10

Buradaki 2731, resolver'ın bu cevabı daha kaç saniye tutacağıdır ve siz sorguyu tekrarladıkça geri sayar. Sıfıra indiğinde resolver kaydı yeniden sorar. Aynı sorguyu iki kez üst üste çalıştırıp sayının azaldığını görmek, kaydın önbellekten geldiğini kanıtlar. TTL mantığının tamamı için ttl nedir dns yazısını okuyun.

Değişiklik Gerçekten Uygulandı mı: Doğru Yerden Doğrulama#

Tarayıcıda siteyi açıp "hâlâ eski" demek bir doğrulama değildir; tarayıcı zincirdeki en yanıltıcı halkadır. Doğrulamayı üç seviyeden yapın.

1. Otoriter sunucudan sorun. Buradan gelen cevap kesindir; önbellek yoktur.

dig NS example.com +short
dig A example.com @ns1.yenisaglayici.com +short

Otoriter sunucu yeni IP'yi veriyorsa değişikliğiniz doğru kaydedilmiş demektir ve geri kalanı sadece zaman meselesidir. Vermiyorsa panelde yanlış kaydı düzenlemişsinizdir — en sık hata, aynı alan adı için iki farklı yerde zone tutulması ve düzenlemenin kullanılmayan zone'da yapılmasıdır.

2. Farklı resolver'lardan sorun. Coğrafi olarak farklı ağlardaki resolver'ların ne gördüğünü karşılaştırın:

dig +short A example.com @1.1.1.1
dig +short A example.com @8.8.8.8
dig +short A example.com @9.9.9.9

Windows'ta dig yoksa PowerShell yeterlidir:

Resolve-DnsName example.com -Server 1.1.1.1 -Type A
Resolve-DnsName example.com -Server 8.8.8.8 -Type A

Üçü de yeni IP'yi veriyorsa DNS tarafı bitmiştir; sizde hâlâ eski site görünüyorsa sorun yerel katmandadır. Farklı bölgelerden toplu kontrol için dns propagasyon kontrol araçları yazısındaki yöntemleri kullanabilirsiniz.

3. Kendi bilgisayarınızın ne gördüğüne bakın.

Resolve-DnsName example.com -Type A
Get-DnsClientCache | Where-Object Entry -like "*example.com*"

İkinci komut Windows'un önbelleğinde tuttuğu kaydı ve kalan TTL'ini gösterir; eski IP buradaysa temizlemeniz yeterlidir.

Tarayıcının Kendi DNS Önbelleği: İşletim Sisteminden Ayrıdır#

ipconfig /flushdns çalıştırdınız, dig yeni IP'yi veriyor ama Chrome hâlâ eski siteyi açıyorsa bunun sebebi şudur: Chromium tabanlı tarayıcılar (Chrome, Edge, Brave, Opera) kendi içinde ayrı bir DNS önbelleği ve ayrıca açık soket havuzu tutar. İşletim sistemi önbelleğini temizlemek buna dokunmaz.

Chrome'da temizleme:

1. Adres çubuğuna chrome://net-internals/#dns yazın.
2. Clear host cache düğmesine basın.
3. Soldaki menüden Sockets bölümüne geçip Flush socket pools deyin. Bu adım önemlidir: DNS kaydı temizlense bile eski sunucuya açık kalan bağlantı yeniden kullanılabilir ve site eski sunucudan gelmeye devam eder.

Edge'de aynı sayfa edge://net-internals/#dns adresindedir. Firefox ayrı bir çözümleyici kullanır ve varsayılan olarak DNS-over-HTTPS etkin olabilir; Firefox'ta about:networking#dns sayfasından Clear DNS Cache diyebilirsiniz. Firefox'ta DoH açıksa sorgular işletim sisteminin resolver'ına hiç uğramaz, doğrudan uzak bir sağlayıcıya gider — bu yüzden Firefox eski, Chrome yeni siteyi gösterebilir. Mekanizma için dns over https tls yazısına bakın.

Kesin sonuç için gizli sekme yerine başka bir cihaz ve başka bir ağ kullanın; telefonunuzun mobil verisi bu iş için en pratik testtir.

Aslında DNS Değil: HSTS, Sayfa Önbelleği ve Servis Çalışanı#

Sık karşılaştığım tablo şudur: DNS her yerde yeni IP'yi veriyor, tarayıcı önbelleği temizlenmiş, buna rağmen eski site geliyor ya da HTTPS hatası alınıyor. Bu noktada sorun DNS değildir.

HSTS. Site daha önce Strict-Transport-Security başlığı gönderdiyse tarayıcı, alan adını belirli bir süre boyunca zorunlu HTTPS listesinde tutar. Yeni sunucuda sertifika henüz kurulmadıysa tarayıcı HTTP'ye düşmeyi reddeder ve "bağlantınız gizli değil" ekranı çıkar; kullanıcı bunu "DNS güncellenmedi" sanır. Chrome'da chrome://net-internals/#hsts sayfasındaki Delete domain security policies alanına alan adını yazarak yerel kaydı silebilirsiniz — ama bu yalnızca sizin tarayıcınızı düzeltir. Kalıcı çözüm, yeni sunucuda geçerli sertifikayı DNS'i çevirmeden önce hazırlamaktır.

Sayfa ve CDN önbelleği. Site bir CDN veya proxy arkasındaysa ziyaretçiye giden içerik CDN'in kenar düğümünden gelir; siz origin IP'sini değiştirseniz bile CDN eski içeriği sunmaya devam edebilir. Bu durumda yapılacak iş DNS beklemek değil, CDN panelinden önbelleği temizlemektir.

Servis çalışanı (service worker). PWA yapısındaki sitelerde tarayıcıya kurulmuş bir servis çalışanı sayfayı ağdan hiç istemeden kendi önbelleğinden verebilir. Geliştirici araçları → Application → Service Workers bölümünden Unregister, ardından Storage → Clear site data ile temizlenir.

Eski sunucu hâlâ ayakta. Belki de en can sıkıcı olasılık: DNS gerçekten yeni sunucuya gidiyordur ama yeni sunucudaki sanal ana makine (vhost) yapılandırması alan adını tanımadığı için varsayılan siteye düşüyordur ve siz eski görünümü orada görüyorsunuzdur. Bunu ayırmak için aşağıdaki yöntemi kullanın.

DNS'e Hiç Dokunmadan Yeni Sunucuyu Test Etmek#

Taşımalarda en çok işe yarayan ve Türkçe kaynaklarda neredeyse hiç geçmeyen yöntem budur: DNS'i değiştirmeden önce yeni sunucuyu, sanki DNS çevrilmiş gibi test edersiniz. curl ile tek satırda:

curl -sI --resolve example.com:443:198.51.100.20 https://example.com
curl -s --resolve example.com:443:198.51.100.20 https://example.com | head -40

--resolve parametresi yalnızca o istek için isim çözümlemesini elle sabitler; sistemin DNS'i etkilenmez. Yanıt başlığındaki Server, X-Powered-By gibi alanlar ve HTML çıktısı yeni sunucudan gelir. Böylece "site yeni sunucuda düzgün açılıyor mu" sorusunu DNS'i çevirmeden yanıtlarsınız.

Tarayıcıyla test etmek isterseniz hosts dosyasını kullanın. Windows'ta C:\Windows\System32\drivers\etc\hosts, macOS/Linux'ta /etc/hosts dosyasına şu satırı ekleyin:

198.51.100.20    example.com www.example.com

Ardından ipconfig /flushdns çalıştırıp tarayıcıda siteyi açın; yalnızca sizin bilgisayarınız yeni sunucuya gider. Testi bitirince satırı silmeyi unutmayın — unutulmuş bir hosts satırı, DNS gerçekten değiştikten sonra bile sizi eski IP'ye kilitler ve "bende hâlâ eski site açılıyor" şikâyetinin en sinsi sebebidir.

Sıralama şu şekilde olduğunda taşıma kesintisiz geçer:

1. Yeni sunucuya kurulum ve içerik aktarımı yapılır.
2. --resolve veya hosts ile yeni sunucu doğrulanır, SSL sertifikası hazırlanır.
3. TTL düşürülür ve eski TTL kadar beklenir.
4. Eski sunucuda yazma işlemleri durdurulur, son veritabanı senkronu alınır.
5. A kaydı veya nameserver değiştirilir.
6. Eski sunucu en az bir hafta ayakta bırakılır; gecikmeli resolver'lardan gelen ziyaretçiler kesinti yaşamaz.

Beşinci ve altıncı adım birlikte düşünülmelidir: eski sunucuyu hemen kapatırsanız, henüz eski IP'yi gören ziyaretçiler bağlantı hatası alır. Bu sırada eski sunucuda alınan siparişler veya form kayıtları da yeni sunucuya geçmez; bu yüzden geçiş penceresinde eski sunucuyu salt okunur hâle getirmek ya da yeni adrese yönlendirmek en temiz yoldur.

E-posta Tarafını Unutmayın#

Nameserver değiştirdiğinizde yalnızca web trafiği taşınmaz; MX, SPF, DKIM ve DMARC kayıtları da yeni DNS sağlayıcısındaki zone'dan okunur. Yeni zone'a bu kayıtları kopyalamadıysanız alan adınızın e-postası sessizce durur — üstelik site çalıştığı için kimse fark etmez, gönderenler birkaç gün boyunca kuyrukta bekleyen iletiler yüzünden geri dönüş almaz.

Kontrol basittir:

dig MX example.com +short
dig TXT example.com +short
dig TXT selector1._domainkey.example.com +short

MX kaydı eski sunucuyu gösteriyorsa ve postalar orada birikiyorsa, geçiş sırasında gelen iletiler yeni sunucuya kendiliğinden taşınmaz; kutuları elle aktarmanız gerekir. Bu senaryonun ayrıntısını epostaları yeni sunucuya taşıma ve epostalarım gelmiyor mx sorunu yazılarında bulabilirsiniz.

Belirti–Neden Eşleşme Tablosu#

Ne Kadar Beklemek Gerçekten Gerekir#

Yaygın "48 saat" rakamı, kayıtların TTL'inin 24-48 saat olduğu döneme ait bir alışkanlıktır ve bugün çoğu senaryoda geçerli değildir. Gerçek beklenti şudur:

• A/CNAME kaydı değişimi, TTL 300 ise: çoğu resolver 5-15 dakikada yeni değeri verir.
• A/CNAME kaydı değişimi, TTL 14400 ise: en geç 4 saat.
• Nameserver değişimi: otoriter tarafta anında, ama delegasyon TTL'i yüzünden pratikte 4-24 saat.
• İnatçı azınlık: TTL'e uymayan, kendi asgari süresini dayatan resolver'lar ve uzun süre açık kalmayan modemler yüzünden küçük bir kesim daha uzun süre eski cevabı görebilir. Eski sunucuyu bir hafta ayakta tutmanın sebebi budur.

Propagasyonun matematiğini ve neden "yayılma" kelimesinin aslında yanıltıcı olduğunu propagasyon süresi dns yazısında ayrıntılandırdım; kısaca DNS bir yayın değildir, her resolver kendi TTL'i dolunca kendi başına yeniden sorar.

Sıkça Sorulan Sorular#

DNS değişikliği ne kadar sürede aktif olur#

Süreyi belirleyen tek şey değişiklikten önce geçerli olan TTL değeridir; taşımadan önce TTL'i 300 saniyeye düşürdüyseniz çoğu resolver 5-15 dakika içinde yeni kaydı görür. TTL 14400 (4 saat) ise en geç 4 saat, 86400 ise 24 saat beklemeniz gerekir. Nameserver değiştiriyorsanız buna üst seviyedeki delegasyon TTL'i de eklenir ve bu değer sizin kontrolünüzde değildir, bu yüzden 24 saati bulabilir.

TTL'i şimdi düşürsem geçiş hızlanır mı#

Hayır, TTL'i taşımanın hemen öncesinde düşürmek işe yaramaz çünkü bu değişikliğin kendisi de eski TTL süresi kadar önbellekte bekler. Resolver'lar elindeki kaydın ömrü dolmadan yeni TTL'i öğrenemez. TTL indirimi, taşımadan en az bir eski-TTL süresi kadar önce yapıldığında anlamlıdır; pratikte taşımadan 24-48 saat önce düşürüp taşıma bittikten sonra eski değerine geri çıkarmak doğru yöntemdir.

Site bende eski, başkasında yeni açılıyor ne yapmalıyım#

Bu, DNS tarafının büyük ölçüde tamamlandığını ve sorunun sizin cihazınızda kaldığını gösterir. Sırayla işletim sistemi önbelleğini temizleyin, tarayıcıda chrome://net-internals/#dns sayfasından host önbelleğini ve soket havuzunu boşaltın, hosts dosyasında unutulmuş bir satır olup olmadığına bakın ve modeminizi yeniden başlatın. Bunlar sonuç vermezse cihazın kullandığı resolver'ı geçici olarak 1.1.1.1 yapıp tekrar deneyin.

Nameserver değişimiyle A kaydı değişimi arasındaki fark nedir#

A kaydı değişikliği yalnızca o kaydın TTL'i kadar önbellekte kalır ve tek bir kaydı etkiler; nameserver değişikliği ise alan adının bütün DNS yönetimini başka bir sunucuya devrettiği için üst seviyedeki delegasyon kayıtlarının da güncellenmesini gerektirir. Bu yüzden nameserver değişimi daha uzun sürer ve daha risklidir: yeni zone'a MX, TXT, alt alan adı kayıtlarını eksiksiz kopyalamadıysanız e-posta ve doğrulama kayıtları kaybolur. Yalnızca sunucu değiştiriyorsanız çoğu zaman nameserver'a hiç dokunmadan sadece A kaydını güncellemek yeterlidir.

Eski sunucuyu ne zaman kapatabilirim#

Değişiklikten sonra en az bir hafta beklemek güvenlidir; TTL'e uymayan resolver'lar, uzun süre yeniden başlatılmamış modemler ve iç DNS sunucuları yüzünden gecikmeli ziyaretçiler olabilir. Bu süre içinde eski sunucudaki erişim kayıtlarını izleyerek trafiğin sıfıra düşüp düşmediğini görebilirsiniz. Eski sunucuda yazma işlemi yapılmasını engellemek için siteyi salt okunur moda almak veya yeni adrese yönlendirmek, iki sunucuda ayrı ayrı sipariş/form kaydı oluşmasını önler.

Propagasyon kontrol siteleri güvenilir mi#

Farklı bölgelerdeki resolver'ların ne gördüğünü hızlıca göstermeleri açısından faydalıdır ama tek başına yeterli değildir. Bu araçlar genellikle sabit bir resolver listesi kullanır ve sizin ziyaretçilerinizin kullandığı resolver'ları kapsamayabilir. En kesin doğrulama, otoriter sunucuya doğrudan sorgu atmak (dig A example.com @ns1.saglayici.com) ve ardından birkaç genel resolver'ı elle karşılaştırmaktır.

Cloudflare kullanıyorum, DNS değişikliği neden görünmüyor#

Cloudflare'de kaydın turuncu bulut (proxy) modunda olması durumunda ziyaretçi sizin origin IP'nizi hiç görmez; DNS her zaman Cloudflare'in IP adreslerini döndürür. Bu yüzden origin IP'sini değiştirdiğinizde dışarıdan bakınca hiçbir şey değişmemiş gibi görünür, oysa trafik gerçekten yeni sunucuya gitmektedir. Eski içerik geliyorsa sebep DNS değil, kenar önbelleğidir; Cloudflare panelinden önbelleği temizlemeniz veya geliştirme modunu açmanız gerekir.

Değişiklikten sonra site açılmıyor, ne kontrol etmeliyim#

Önce dig A example.com @1.1.1.1 ile kaydın gerçekten yeni IP'yi verdiğini doğrulayın; veriyorsa sorun DNS'te değil, sunucudadır. Ardından curl -sI https://example.com ile dönen HTTP durum kodunu ve sertifika hatası olup olmadığını kontrol edin. Sunucuda alan adı için sanal ana makine tanımı eksikse varsayılan sayfa, sertifika yoksa güvenlik uyarısı, servis çalışmıyorsa bağlantı reddi alırsınız; bu senaryolardan biri için sunucu ip adresi bulunamadı hatası yazısındaki ayrım tablosu da işinize yarar.

Kapanış#

DNS değişikliğinden sonra sitenin eski sunucudan gelmesi bir arıza değil, tasarımın doğal sonucudur: her katman elindeki cevabı TTL süresi boyunca tutar ve bu süre dolana kadar sizin yaptığınız değişikliği bilmez. Yapılacak iş beklemek değil, önce nerede takıldığını ölçmektir — otoriter sunucudan sorup değişikliğin kaydedildiğini doğrulayın, birkaç genel resolver'ı karşılaştırın, sonra kendi cihazınızın önbelleğini ve tarayıcının ayrı DNS/soket havuzunu temizleyin. Hâlâ eski görüntü geliyorsa ihtimal büyük olasılıkla DNS dışıdır: HSTS, CDN önbelleği, servis çalışanı ya da unutulmuş bir hosts satırı.

Bir sonraki taşımada bu yazının tamamını gereksiz kılmanın yolu ise tek cümlede özetlenebilir: TTL'i taşımadan 24-48 saat önce düşürün, yeni sunucuyu --resolve ile DNS'e dokunmadan test edin, sertifikayı önceden hazırlayın ve eski sunucuyu bir hafta ayakta bırakın. Bu geçişi kendiniz yürütmek istemiyorsanız site taşıma hizmeti kesintisiz aktarımı üstlenir; yeni bir barındırma ortamı arıyorsanız hosting paketleri ve daha yüksek kaynak gerektiren projeler için sanal sunucu seçeneklerine, alan adı ve DNS kayıtlarını tek panelden yönetmek için alan adı hizmetleri sayfasına bakabilirsiniz.