Domain ve Hosting Bağlantısı Sonrası Site Açılmıyorsa Ne Yapmalı?

Domain hosting bağlantısı sonrasında site açılmıyorsa önce sorunun adres, DNS yönlendirmesi veya sunucu katmanında olduğunu ayırmak gerekir. Domain ziyaretçinin tarayıcıya yazdığı adrestir; hosting site dosyalarının çalıştığı ortamdır; DNS ise domaini doğru sunucuya götüren yönlendirme sistemidir.

Bu üç kavramı birbirinden ayırmadan yapılan rastgele kayıt değişiklikleri sorunu büyütebilir. En güvenli yaklaşım, önce nameserver bilgisini, ardından kök alan adı ile www kaydını kontrol etmek; daha sonra görülen hata mesajına göre bir sonraki katmana geçmektir.

Domain, hosting ve DNS birbirinden nasıl ayrılır?

Bir web sitesini ziyaretçinin karşısına çıkaran yapı, tek bir ayardan oluşmaz. Domain, hosting ve DNS farklı görevler üstlenir. Bu ayrımı bir kargo sistemi gibi düşünebilirsiniz: domain adres etiketi, hosting paketin bulunduğu depo, DNS ise kargonun hangi depoya götürüleceğini söyleyen yönlendirme sistemidir.

Domain: Ziyaretçinin yazdığı internet adresi

Domain, insanların bir web sitesine ulaşmak için tarayıcıya yazdığı okunabilir addır. Örneğin example.com bir domain örneğidir. Ziyaretçinin bu adresi yazması, tarayıcıya doğrudan sunucunun fiziksel konumunu vermez. Tarayıcı önce bu alan adının hangi sunucuya karşılık geldiğini öğrenmeye çalışır.

Domaini bir telefon rehberindeki kişi adı gibi düşünebilirsiniz. İnsanlar uzun ve akılda tutulması zor IP adresleri yerine anlamlı bir alan adı kullanır. Ancak bilgisayarların bağlantı kurabilmesi için bu adın bir IP adresiyle veya başka bir alan adıyla eşleştirilmesi gerekir. Bu eşleştirme DNS kayıtları üzerinden yapılır.

Bu nedenle domain kaydının alınmış olması, sitenin otomatik olarak yayında olduğu anlamına gelmez. Domain yalnızca kullanılacak internet adresini sağlar. Bu adresin bir web sunucusuna yönlendirilmesi ve hosting ortamında doğru site dosyalarının bulunması ayrıca gerekir.

Hosting: Site dosyalarının ve sunucu hizmetinin bulunduğu ortam

Hosting, web sitesinin dosyalarının saklandığı ve ziyaretçi isteklerinin işlendiği sunucu ortamıdır. HTML, CSS, JavaScript, görseller, sunucu tarafı kodları ve gerekli yapılandırma dosyaları bu ortamda bulunabilir. Dinamik uygulamalarda veritabanı bağlantısı, çalışma zamanı ayarları ve uygulama günlükleri de hosting tarafında yer alabilir.

Bir domain doğru sunucuya yönlendirilse bile hosting hesabında site dosyaları yoksa beklenen sayfa açılmayabilir. Bunun yerine boş bir sayfa, varsayılan sunucu sayfası, 404 hatası veya sunucu taraflı bir hata görülebilir. Bu durum domainin bozuk olduğunu değil, isteğin ulaştığı sunucuda doğru içeriğin bulunmadığını gösterebilir.

Hosting tarafında ayrıca site kökü olarak adlandırılan klasör önemlidir. Sunucu, gelen isteği belirli bir klasörle eşleştirir. Ana sayfa dosyası yanlış klasöre yüklendiyse veya domain başka bir hosting hesabının site köküne bağlandıysa DNS çözümlemesi başarılı olsa bile ziyaretçiye doğru site sunulmaz.

DNS: Domaini doğru sunucuya ulaştıran çözümleme katmanı

DNS, alan adlarını bilgisayarların bağlantı kurabileceği hedeflere çeviren dağıtık isim çözümleme sistemidir. Tarayıcı example.com adresini açmaya çalıştığında DNS üzerinden bu adın hangi IP adresine veya hedef alan adına karşılık geldiğini sorar.

DNS’i bir navigasyon sistemi gibi düşünebilirsiniz. Domain varış adresidir, hosting hedef binadır, DNS ise navigasyonun “bu adrese gitmek için şu sunucuyu kullan” bilgisidir. Navigasyon yanlış binayı gösteriyorsa doğru siteye ulaşamazsınız; ancak bu, hedef binadaki dosyaların silindiği anlamına gelmez.

DNS katmanında farklı kayıt türleri bulunur. Bu yazının temel teşhisinde özellikle nameserver, A kaydı ve CNAME kaydı önemlidir. Amazon Route 53 DNS kavramları dokümantasyonunda da nameserver, DNS kaydı, alan adı ve alt alan adı arasındaki ilişki ayrı kavramlar olarak açıklanır.

Nameserver neyi belirler?

Nameserver, domain için DNS kayıtlarının hangi DNS hizmeti tarafından yönetileceğini belirleyen sunucu bilgisidir. Başka bir ifadeyle nameserver, “Bu domainin A, CNAME, MX ve diğer DNS kayıtlarını hangi sistemden öğrenmeliyiz?” sorusunun cevabını gösterir.

Bir domainin nameserver değerleri beklenmeyen bir DNS hizmetine işaret ediyorsa, başka bir panelde yaptığınız A veya CNAME değişiklikleri ziyaretçilere yansımayabilir. Çünkü tarayıcıların ve DNS çözümleyicilerin başvurduğu yetkili kayıt alanı, sizin düzenlediğiniz panel değil farklı bir hizmet olabilir.

Bu yüzden nameserver kontrolü, DNS teşhisinin ilk adımlarından biridir. Önce kayıtların nerede yönetildiği anlaşılmalı, ardından A ve CNAME kayıtları o yetkili DNS alanında incelenmelidir.

A kaydı ve CNAME kaydı arasındaki temel fark

A kaydı, bir alan adını IPv4 adresine bağlar. Basitleştirilmiş bir örnekte example.com için A kaydı, ziyaretçinin isteğini belirli bir IPv4 adresindeki web sunucusuna yönlendirir.

CNAME kaydı ise bir alan adını başka bir alan adına yönlendiren takma ad gibi çalışır. Örneğin www.example.com kaydı, başka bir hedef alan adına CNAME ile bağlanabilir. DNS çözümleyici daha sonra hedef alan adının kendi kaydını bulur ve bağlantı için gerekli hedefe ulaşır.

Bu iki kayıt türü aynı işi yapmaz:

• A kaydı doğrudan IPv4 adresi gösterir.
• CNAME kaydı başka bir alan adını hedef gösterir.
• CNAME kullanılan bir ad altında aynı ad için farklı DNS kayıtları bulunamayacağı için çakışan kayıtlar ayrıca kontrol edilmelidir.
• Klasik DNS kurallarında kök alan adına, yani example.com gibi zone apex adına CNAME koyulamaz.
• Bazı DNS hizmetleri kök alan adı için alias, ANAME veya CNAME flattening gibi sağlayıcıya özgü çözümler sunabilir. Bu davranış standart CNAME kuralından ayrı değerlendirilmelidir.

Buradaki önemli nokta, “CNAME hiçbir koşulda kök alan adında kullanılamaz” gibi sağlayıcıdan bağımsız ve aşırı kesin bir cümle kurmamaktır. Klasik DNS uygulamasında kök alan adı için CNAME sınırlaması bulunurken, bazı DNS hizmetleri kendi özel mekanizmalarıyla benzer bir kullanım sağlayabilir. Bu nedenle ilgili DNS hizmetinin resmî dokümantasyonu kontrol edilmelidir.

example.com ile www.example.com aynı adres midir?

example.com ve www.example.com yazım olarak birbirine benzese de DNS açısından iki farklı addır. İlki kök alan adı, ikincisi ise www alt alan adıdır. Ziyaretçi bu iki adresi ayrı ayrı yazabileceği için her ikisinin de doğru şekilde ele alınması gerekir.

Yaygın bir kayıt şeması şu mantığı gösterebilir:

• @ veya kök alan adı: A kaydı ile web sunucusunun IPv4 adresine yönlendirme.
• www: CNAME ile kök alan adına veya hizmetin belirlediği başka bir hedef alan adına yönlendirme.

Buradaki @ işareti birçok DNS panelinde kök alan adını temsil eder. Bazı panellerde ise alan adı boş bırakılır veya alan adı tam biçimde yazılır. Bu arayüz farkı, DNS mantığını değiştirmez; ancak yanlış alana kayıt girilmesini önlemek için panelin kendi açıklaması dikkate alınmalıdır.

Örneğin kök alan adı için doğru A kaydı bulunurken www.example.com için hiçbir kayıt yoksa, biri açılırken diğeri açılmayabilir. Tersi durumda www çalışıyor gibi görünürken kök alan adı yanlış sunucuya gidebilir. Bu nedenle yalnızca tek bir adresi test etmek yerine hem example.com hem de www.example.com biçimi ayrı ayrı kontrol edilmelidir.

Nameserver, A kaydı ve CNAME ayarları nasıl kontrol edilir?

Kontrol sırası, rastgele kayıt değiştirmek yerine sorunun hangi katmanda olduğunu daraltmalıdır. İlk soru şudur: Domain gerçekten beklenen DNS hizmetini mi kullanıyor? İkinci soru: Kök alan adı doğru sunucuyu mu gösteriyor? Üçüncü soru: www alt alan adı eksik, hatalı veya çelişkili bir kayıtla mı tanımlanmış?

1. Nameserver bilgisini doğrulayın

Önce domain yönetim ekranındaki nameserver değerlerini not edin. Ardından DNS kayıtlarının düzenlendiği yönetim alanının, bu nameserver değerlerinin işaret ettiği hizmet olup olmadığını kontrol edin. Domain bir DNS hizmetine yönlendirilmişken kayıtları başka bir hizmetin panelinde değiştiriyorsanız, yaptığınız düzenleme doğru sorgu noktasına ulaşmayabilir.

Şu kontrol sorularını sırayla sorun:

• Nameserver kayıtları beklenen DNS yönetim alanına mı işaret ediyor?
• DNS kayıtlarını düzenlediğiniz panel, domain için yetkili olan hizmet mi?
• Nameserver değerlerinden biri eksik, hatalı yazılmış veya farklı bir yapılandırmaya ait mi?
• Yakın zamanda nameserver değişikliği yapıldıysa, sonuçları farklı ağlardan veya farklı DNS çözümleyicilerden karşılaştırıyor musunuz?

Bu aşamada hemen yeni kayıt eklemek yerine mevcut nameserver değerlerini ve DNS kayıtlarını bir yere kopyalamak daha güvenlidir. Böylece sonraki değişiklik beklenen sonucu vermediğinde önceki duruma dönmek veya hangi değerin değiştiğini karşılaştırmak kolaylaşır.

2. Kök alan adının A kaydını kontrol edin

Kök alan adı için kullanılan A kaydının değeri, sitenin bulunması gereken hosting sunucusunun IPv4 adresiyle eşleşmelidir. Burada yalnızca “bir IP adresi var mı?” sorusu yeterli değildir. IP adresinin doğru hosting hesabına, doğru site köküne ve doğru uygulamaya ait olup olmadığı da önemlidir.

Yanlış IP adresi birkaç farklı belirti oluşturabilir:

• Eski sitenin görünmesi.
• Başka bir hosting hesabına ait varsayılan sayfanın açılması.
• Alan adının sunucuda tanınmaması.
• Beklenmeyen bir 404 veya yönlendirme sayfasının gösterilmesi.

Birden fazla A kaydı bulunması da ayrıca incelenmelidir. Birden fazla kayıt bazı yapılarda bilinçli olarak kullanılabilir; ancak farklı ve çelişkili IP adresleri aynı siteyi hedeflemiyorsa, sonuçlar tutarsız görünebilir. Başlangıç seviyesinde güvenli yaklaşım, hangi kayıtların bilinçli olarak eklendiğini doğrulamadan silme işlemi yapmamaktır.

3. www alt alan adını ayrı kontrol edin

www.example.com için bir CNAME veya A kaydı bulunup bulunmadığını kontrol edin. Kayıt hiç yoksa www adresi çözümlenemeyebilir. Kayıt varsa hedef değerinin doğru yazıldığını, hedef alan adının mevcut olduğunu ve kök alan adıyla beklenen hosting ortamına ulaştığını inceleyin.

www için CNAME kullanılıyorsa, aynı ad altında ayrıca A, AAAA veya başka çakışan kayıtlar bulunması sorun çıkarabilir. CNAME kaydının amacı başka bir alan adını hedeflemek olduğu için, aynı adın birden fazla kayıt türüyle tanımlanıp tanımlanmadığı önemlidir.

Kök alan adı ile www adresinin aynı siteyi göstermesi isteniyorsa, iki adresin de ayrı ayrı sorgulanması gerekir. Birinin doğru sunucuya, diğerinin eski sunucuya gitmesi; ziyaretçilerin kullandığı adrese göre farklı içerik görmesine yol açabilir.

4. Kayıtları değiştirirken kontrollü ilerleyin

DNS düzenlemesinde en sık yapılan hatalardan biri, aynı anda birden fazla alanı değiştirmektir. Böyle bir durumda hangi değişikliğin sorunu çözdüğünü veya yeni bir belirti oluşturduğunu anlamak zorlaşır. Daha güvenli yöntem, aşağıdaki sırayı izlemektir:

1. Mevcut nameserver, A ve CNAME değerlerini not edin.
2. Önce yalnızca sorumlu olduğunuz kaydı belirleyin.
3. Tek bir değişiklik yapın.
4. Kök alan adı ve www adresini ayrı ayrı sorgulayın.
5. Beklenen hedefe ulaşıldığını doğrulamadan ikinci değişikliğe geçmeyin.
6. Değişiklik sonucu farklıysa önceki kayıtla yeni kaydı karşılaştırın.

DNS kayıtlarını komut satırından gözlemlemek için sağlayıcıdan bağımsız bir nslookup örneği kullanılabilir:

# Nameserver kayıtlarını görüntüle
nslookup -type=ns example.com

# Kök alan adının A kaydını sorgula
nslookup -type=a example.com

# www alt alan adının CNAME kaydını sorgula
nslookup -type=cname www.example.com

İlk komut, domain için bildirilen nameserver bilgisini görmeye yardımcı olur. İkinci komut, kök alan adının IPv4 hedefini incelemek için kullanılır. Üçüncü komut www için CNAME yanıtı arar; bu ad A kaydıyla tanımlanmışsa CNAME sonucu yerine farklı bir yanıt görmeniz normal olabilir.

Komut çıktısını yorumlarken yalnızca “cevap geldi” bilgisine bakmayın. Dönen hedefin beklenen DNS hizmetiyle ve hosting sunucusuyla uyumlu olup olmadığını değerlendirin. Alan adı veya hosting yönetimi konusundaki temel kavramları kendi seviyenizden görmek isterseniz, ücretsiz yazılım bilgisi testi üzerinden hangi konularda tekrar yapmanız gerektiğine dair başlangıç noktası oluşturabilirsiniz.

Örnek kayıt şeması nasıl okunur?

Aşağıdaki şema, gerçek bir alan adında uygulanacak kesin değerleri değil, kayıtların görevlerini gösteren temsili bir modeli anlatır:

• Kök alan adı — A: Domaini bir IPv4 adresindeki web sunucusuna bağlar.
• www — CNAME: www.example.com adresini başka bir alan adına bağlar.
• Kök alan adı — CNAME: Klasik DNS uygulamalarında sınırlıdır; kullanılan hizmetin alias veya flattening desteği varsa o hizmetin kuralları ayrıca incelenir.

Bu şemada amaç, “A kaydı her zaman kullanılmalıdır” veya “CNAME her yerde kullanılabilir” sonucuna varmak değildir. Doğru seçim, hedefin IP adresi mi yoksa başka bir alan adı mı olduğuna ve kullanılan DNS hizmetinin desteklediği davranışlara bağlıdır.

Belirtiye göre sorun hangi katmanda olabilir?

Site açılmadığında görülen belirti, teşhisin başlangıç hipotezini oluşturur; tek başına kesin neden değildir. Aynı hata, farklı katmanlarda birbirine benzeyen sonuçlar doğurabilir. Bu nedenle her belirti için önce küçük bir doğrulama testi yapılmalı, ardından bir sonraki adım belirlenmelidir.

Örneğin eski sitenin görünmesi çoğunlukla yanlış IP veya yanlış hosting hesabını düşündürür; ancak farklı bir DNS yanıtı da benzer görüntü oluşturabilir. DNS_PROBE türü hata, HTTP isteği sunucuya ulaşmadan önce alan adı çözümleme aşamasında sorun olabileceğini düşündürür. 404 ve 500 ise genellikle sunucuya bir istek ulaştığını, fakat kaynağın bulunamadığını veya sunucunun isteği işlerken hata verdiğini araştırmayı gerektirir. MDN HTTP durum kodları dokümantasyonunda 404 istemcinin talep ettiği kaynağın bulunamadığını, 500 ise sunucunun isteği işlerken beklenmeyen bir durumla karşılaştığını açıklar.

Tablodaki eşleştirmeleri kesin teşhis olarak değil, ilk karar noktaları olarak kullanın. Aynı anda hem DNS hem hosting hem de tarayıcı önbelleği etkilenmiş olabilir. Bu nedenle hata mesajının yalnızca metnini okumak yerine, alan adının hangi hedefe çözümlendiğini ve sunucunun hangi HTTP yanıtını verdiğini birbirinden ayırmak gerekir.

Özellikle DNS_PROBE ifadelerinde tarayıcı, alan adı için beklenen DNS yanıtını alamadığını bildiriyor olabilir. Bu durumda henüz 404 veya 500 gibi bir HTTP durum koduna ulaşılmamış olabilir. Buna karşılık 404 veya 500 görüntüleniyorsa, istek en azından bir web sunucusuna ulaşmış olabilir; sonraki inceleme DNS yerine dosya yolu, site kökü, uygulama veya sunucu yapılandırmasına kaydırılmalıdır.

Eski sitenin görünmesi de dikkatli yorumlanmalıdır. Bu belirti, alan adının hâlâ eski IP adresine gitmesi anlamına gelebilir; fakat ziyaret edilen cihazın veya ağın daha önce aldığı DNS yanıtını kullanmaya devam etmesi de ihtimaller arasındadır. Bu yüzden tek tarayıcıda yenileme yapmak yerine, aynı alan adının kök ve www biçimlerini ayrı sorgulamak daha açıklayıcıdır.

Nameserver’dan tarayıcı önbelleğine sıralı teşhis akışı

Domain ve hosting bağlantısından sonra site açılmıyorsa en doğru yaklaşım, bütün ayarları aynı anda değiştirmek değil; sorunu katman katman ayırmaktır. Belirti → doğrulama testi → karar → çözüm sırasını izlediğinizde, DNS sorunu ile hosting, SSL veya tarayıcı kaynaklı bir problemi birbirine karıştırmazsınız.

Aşağıdaki akışta her adımın sonunda iki karar verilir: Test doğru sonuç veriyorsa bir sonraki katmana geçilir; yanlış sonuç veriyorsa o katmanda kalınır ve önce ilgili ayar düzeltilir. Böylece henüz doğrulanmamış bir sorunu çözmeye çalışırken çalışan başka bir ayarı bozma ihtimali azalır.

1. Alan adının yazımını ve www/kök alan adı ayrımını kontrol edin

Belirti: Site adresi tarayıcıya yazıldığında sayfa açılmıyor, ancak başka bir adres varyantı kısmen çalışıyor olabilir.

Doğrulama testi: Alan adını iki temel biçimde ayrı ayrı deneyin:

• https://ornekalanadi.com
• https://www.ornekalanadi.com

Buradaki amaç yalnızca yazım hatası aramak değildir. Kök alan adı ile www alt alan adı DNS açısından ayrı adlardır. Biri için A kaydı bulunurken diğeri için CNAME kaydı tanımlanmış olabilir. Ayrıca hosting yapılandırmasında yalnızca bir varyant siteye atanmış olabilir.

Karar: Her iki adres de aynı siteyi açıyor ve beklenen HTTPS davranışını gösteriyorsa nameserver kontrolüne geçin. Yalnızca biri açılıyorsa sorun büyük olasılıkla alan adı varyantının DNS kaydı, hosting eşleştirmesi veya yönlendirme yapılandırması katmanındadır.

Çözüm: Kök alan adı ve www adresinin hangi hedefe gitmesi gerektiğini netleştirin. Bir varyantın ana adres, diğerinin yönlendirme adresi olması planlanabilir; ancak bu yönlendirmenin çalışması için her iki adın da önce doğru DNS ve hosting yapılandırmasına ulaşması gerekir.

2. Nameserver kayıtlarının doğru DNS hizmetini gösterdiğini doğrulayın

Belirti: DNS panelinde bir kayıt eklenmiş görünmesine rağmen dışarıdan yapılan sorgularda eski veya farklı sonuçlar alınır.

Doğrulama testi: Alan adının yetkili nameserver kayıtlarını kontrol edin. Nameserver, alan adının DNS kayıtlarının hangi sunuculardan okunacağını belirler. Alan adı bir DNS hizmetine yönlendirilmiş, fakat kayıtlar başka bir DNS panelinde düzenleniyorsa yaptığınız değişiklikler ziyaretçilere ulaşmayabilir.

Kontrol sırasında şu sorulara bakın:

• Alan adı hangi nameserver adreslerini yayınlıyor?
• DNS kayıtlarını değiştirdiğiniz panel, bu nameserver’ların yönettiği bölge mi?
• Yetkili DNS yanıtında beklediğiniz A, CNAME ve diğer kayıtlar görülebiliyor mu?
• Yanıt, eski hosting hedefini veya kullanılmayan bir adresi mi gösteriyor?

Bu testi nslookup veya dig gibi DNS sorgu araçlarıyla yapabilirsiniz. Örneğin aşağıdaki sorgular, alan adının yetkili sunucularını ve temel web kayıtlarını incelemek için kullanılabilir:

dig NS ornekalanadi.com
dig A ornekalanadi.com
dig CNAME www.ornekalanadi.com

Karar: Nameserver’lar beklenen DNS hizmetini gösteriyor ve kayıtlar aynı yönetim alanından okunuyorsa A ve CNAME hedeflerini incelemeye geçin. Nameserver yanlışsa veya değişiklik yaptığınız panel yetkili değilse sorun hâlâ DNS delegasyonu katmanındadır; sonraki adımlara geçmeden önce bu durum düzeltilmelidir.

DNS çözümleyicileri yanıtları önbelleğe alabilir. Bu nedenle aynı alan adı, farklı ağlarda veya farklı cihazlarda bir süre farklı IP adresleriyle çözümlenebilir. Bir kaydın TTL değeri, yanıtın ne kadar süre önbellekte tutulabileceğiyle ilişkilidir; ancak gerçek gözlemlenen sonuç, istemci, işletim sistemi, yerel ağ ve kullanılan çözümleyiciye göre farklılaşabilir. Google Public DNS performans dokümantasyonu da DNS önbelleklerinin birbirinden yalıtılmış çalışabildiğini ve önbellek yenilenmesinin farklı sonuçlar oluşturabileceğini açıklar.

3. A ve CNAME kayıtlarının hedefini karşılaştırın

Belirti: Nameserver doğru görünmesine rağmen alan adı yanlış siteye, varsayılan sunucu sayfasına veya hiç yanıt vermeyen bir hedefe gidiyor.

Doğrulama testi: Kök alan adı için A kaydının hangi IP adresini gösterdiğini, www için CNAME kaydının hangi alan adına yöneldiğini kontrol edin.

• A kaydı: Bir alan adını IPv4 adresine bağlar.
• CNAME: Bir alan adını başka bir alan adına takma ad olarak bağlar.
• www ve kök alan adı: Aynı hedefe gidiyor gibi görünse de DNS’te ayrı ayrı değerlendirilmeleri gerekir.

Karar: A kaydı doğru IP’yi, CNAME kaydı da beklenen hedefi gösteriyorsa hosting hesabı ve site kökü kontrolüne geçin. Kayıtlardan biri eski, eksik veya yanlış bir hedef gösteriyorsa sorun DNS kayıt katmanındadır.

Çözüm: Hosting hizmetinin teknik yönlendirme bilgisinde belirtilen hedefle mevcut kaydı karşılaştırın. Aynı alan adı için birden fazla çelişkili kayıt, yanlış IP’ye giden bir A kaydı veya beklenmeyen bir CNAME zinciri varsa gereksiz kayıtları rastgele silmek yerine hangi varyantın kullanılacağını belirleyerek düzenleyin.

4. Hosting hesabının doğru site köküne işaret ettiğini inceleyin

Belirti: DNS doğru sunucuya ulaşıyor, fakat ekranda başka bir site, boş dizin, varsayılan karşılama sayfası veya beklenmeyen bir uygulama görülüyor.

Doğrulama testi: Hosting tarafında alan adının hangi siteye ve hangi document root ya da site köküne bağlandığını kontrol edin. Site kökü, tarayıcıdan gelen isteğin dosya aramaya başladığı dizindir.

Şu noktaları birlikte değerlendirin:

• Alan adı doğru hosting hesabına mı eklenmiş?
• Alan adı doğru site köküne mi atanmış?
• Ana giriş dosyası beklenen dizinde mi?
• Dosyalar başka bir alt klasöre yüklenmiş olabilir mi?
• www ve kök alan adı aynı site yapılandırmasına mı bağlı?

Karar: Alan adı doğru site kökünü gösteriyor ve dosyalar bu dizinde bulunuyorsa sunucu yanıt kodunu inceleyin. Yanlış hesaba veya yanlış klasöre bağlıysa sorun artık DNS’ten çok hosting eşleştirmesi katmanındadır.

Bu aşamada dosyayı yüklediğiniz klasör ile hosting yapılandırmasında görünen site kökünün aynı olduğunu varsaymayın. Özellikle birden fazla site, alt alan adı veya test klasörü bulunan hesaplarda alan adı doğru sunucuya ulaşsa bile yanlış dizindeki içerik sunulabilir.

5. DNS yanıtını farklı ağ ve cihazlarda karşılaştırın

Belirti: Site bir cihazda açılıyor, başka bir cihazda açılmıyor veya mobil bağlantıda farklı bir sonuç veriyor.

Doğrulama testi: Aynı alan adını mümkünse şu farklı ortamlarda deneyin:

• Ev veya ofis Wi-Fi ağı
• Mobil internet bağlantısı
• Farklı bir cihaz
• Gizli pencere veya farklı bir tarayıcı

Her ortamda yalnızca sayfanın açılıp açılmadığını değil, çözümlenen IP adresini ve görülen hata mesajını da karşılaştırın. Bir ağ eski IP’yi, diğeri yeni IP’yi döndürebilir. Bunun nedeni yalnızca tarayıcı önbelleği olmayabilir; işletim sistemi veya ağdaki DNS çözümleyicisi de önceki yanıtı tutuyor olabilir.

Karar: Tüm ağ ve cihazlarda aynı DNS yanıtı görülüyorsa sunucu yanıt kodu ve dosya yapılandırmasına geçin. Sonuçlar farklıysa sorun büyük olasılıkla DNS önbellekleme veya DNS çözümleyiciler arasındaki güncelleme farkı katmanındadır.

Çözüm: Kayıtları tekrar tekrar değiştirmek yerine önce hangi ağın hangi yanıtı verdiğini not edin. Aşırı sayıda değişiklik yapmak, teşhis sırasında birden fazla eski ve yeni sonucun karışmasına yol açabilir. Farklı istemcilerdeki sonuçlar benzer hâle geldikten sonra sonraki katmana geçmek daha sağlıklıdır.

6. Sunucu yanıt kodunu ve dosya yapılandırmasını okuyun

Belirti: Alan adı doğru hedefe ulaşıyor, fakat tarayıcı bir HTTP hata kodu gösteriyor, boş sayfa döndürüyor veya uygulama beklenmedik şekilde kapanıyor.

Doğrulama testi: Tarayıcı geliştirici araçlarının Network bölümünden ana isteğin durum kodunu inceleyin. Ayrıca ana giriş dosyasının, yönlendirme kurallarının ve uygulamanın çalışma ayarlarının doğru olup olmadığını kontrol edin.

• 200 benzeri başarılı yanıt varsa sunucu isteği karşılıyor; sorun sayfa içeriğinde veya tarayıcı tarafındaki kaynaklarda olabilir.
• 404 görülüyorsa istenen yol veya dosya bulunamıyor olabilir.
• 500 görülüyorsa sunucu, uygulama veya çalışma zamanı yapılandırmasında hata aranmalıdır.
• Hiç HTTP yanıtı alınamıyorsa bağlantı, DNS, sunucu erişimi veya TLS katmanı yeniden değerlendirilmelidir.

Karar: Sunucu anlamlı bir HTTP yanıtı veriyorsa DNS katmanından çıkıp hosting ve uygulama yapılandırmasına odaklanın. Yanıt alınamıyorsa SSL/HTTPS kontrolüne geçmeden önce sunucuya erişimin gerçekten kurulup kurulmadığını doğrulayın.

7. SSL ve HTTPS kontrolünü yapın

Belirti: Alan adı bazen açılıyor, ancak tarayıcı güvenlik uyarısı gösteriyor; yalnızca www veya yalnızca kök alan adı çalışıyor; HTTP ile HTTPS arasında yönlendirme döngüsü oluşuyor.

Doğrulama testi: Kök alan adı ve www varyantlarını ayrı ayrı HTTPS ile açın. Sertifikanın kapsadığı alan adlarını, geçerlilik durumunu ve tarayıcının gösterdiği hata açıklamasını kontrol edin.

Karar: Sertifika alan adıyla eşleşiyor, geçerli görünüyor ve HTTPS isteği doğru sayfaya ulaşıyorsa tarayıcı önbelleğine geçin. Sertifika yalnızca bir varyantı kapsıyorsa sorun SSL yapılandırması katmanındadır. HTTPS isteği sürekli başka bir HTTPS adresine yönleniyorsa yönlendirme kuralı veya sunucu arkasındaki proxy/TLS ayarı incelenmelidir.

Bu adımda DNS’in doğru olması tek başına yeterli değildir. DNS yalnızca alan adının hangi hedefe çözümleneceğine yardımcı olur; tarayıcının güvenli bağlantı kurabilmesi için sunucunun uygun sertifikayı sunması ve HTTPS isteğini doğru işlemesi gerekir.

8. Tarayıcı ve yerel DNS önbelleğini temizleyin

Belirti: DNS ve sunucu ayarları başka cihazlarda doğru görünmesine rağmen tek bir tarayıcıda eski sayfa, eski hata veya eski yönlendirme görülüyor.

Doğrulama testi: Önce gizli pencerede veya farklı bir tarayıcıda deneyin. Sayfa burada doğru açılıyorsa sorun büyük ihtimalle tarayıcı önbelleği, çerezler, service worker veya daha önce kaydedilmiş yönlendirme davranışıyla ilgilidir.

Geliştirici araçlarında önbelleği geçici olarak devre dışı bırakıp sayfayı yeniden yüklemek, tarayıcının kayıtlı yanıtı yerine sunucudan yeni bir yanıt istemesine yardımcı olabilir. HTTP önbelleği, daha önce alınan yanıtları tekrar kullanabildiği için değişiklikler her zaman anında görünmeyebilir. MDN HTTP önbellekleme dokümantasyonu, tarayıcı önbelleğinin yanıtları sonraki isteklerde yeniden kullanabildiğini ve yeniden yükleme davranışlarının önbellek politikalarından etkilenebileceğini açıklar.

Karar: Önbellek devre dışı bırakıldığında veya farklı tarayıcıda site açılıyorsa sorun istemci katmanındadır. Her ortamda aynı hata görülüyorsa önbelleği temizlemek çözüm olmayacaktır; önceki DNS, hosting veya SSL adımlarına geri dönülmelidir.

Çözüm: Tarayıcının siteye ait önbellek verilerini temizleyin, gerekiyorsa geliştirici araçlarından service worker kaydını kontrol edin ve işletim sisteminin yerel DNS önbelleğini yenileyin. DNS önbelleği temizlense bile kullanılan ağın çözümleyicisi eski yanıtı tutuyor olabilir; bu yüzden sonucu başka bir ağda tekrar karşılaştırın.

Karar ağacını tek cümlede uygulama yöntemi

Her adımda şu soruyu sorun: “Bu test, isteğin bir sonraki katmana geçtiğini kanıtlıyor mu?” Alan adı doğru yazılmıyorsa DNS’e geçmeyin; nameserver yanlışsa A kaydını değiştirmeyin; DNS doğru hedefe ulaşıyorsa tarayıcı önbelleğini suçlamadan önce HTTP yanıtını okuyun; HTTPS uyarısı varsa sertifika ve yönlendirmeyi, sayfa açılıyor fakat kaynaklar eksikse karma içerik ihtimalini inceleyin.

1. Alan adının yazımını, kök alan adı ve www varyantlarını karşılaştırın.
2. Nameserver kayıtlarının doğru DNS hizmetini gösterdiğini doğrulayın.
3. A ve CNAME kayıtlarının hedeflerini kontrol edin.
4. Hosting hesabı ile document root eşleşmesini inceleyin.
5. DNS yanıtını farklı ağ ve cihazlarda karşılaştırın.
6. HTTP durum kodunu, ana giriş dosyasını ve yönlendirme kurallarını kontrol edin.
7. SSL sertifikası, HTTPS yönlendirmesi ve karma içerik belirtilerini inceleyin.
8. Tarayıcı ve yerel DNS önbelleğini temizleyip testi tekrarlayın.

SSL ve HTTPS sorunları nasıl ayırt edilir?

HTTP ve HTTPS arasındaki temel fark, HTTPS’in tarayıcı ile sunucu arasındaki bağlantıyı TLS ile güvenli hâle getirmesidir. Bu nedenle bir alan adı DNS üzerinden doğru sunucuya yönelse bile sertifika yanlışsa site açılırken güvenlik uyarısı görülebilir. DNS sorunu ile sertifika sorununu ayırmanın en kolay yolu, sayfanın hiç açılmadığını mı, yoksa açılmadan önce tarayıcının sertifika uyarısı mı verdiğini gözlemlemektir.

HTTP ile HTTPS neyi değiştirir?

HTTP bağlantısında tarayıcı, web sunucusundan içeriği doğrudan ister. HTTPS’te buna ek olarak güvenli bağlantı kurulması ve sunucunun kimliğinin sertifika aracılığıyla doğrulanması gerekir. Sertifika doğrulanamazsa tarayıcı bağlantıyı riskli kabul edebilir.

Bu yüzden şu iki durum birbirinden ayrılmalıdır:

• Alan adı çözümlenmiyor: DNS, nameserver veya ağ katmanında sorun aranır.
• Alan adı açılıyor fakat güvenlik uyarısı veriyor: Sertifika, alan adı eşleşmesi, geçerlilik veya HTTPS yapılandırması incelenir.

Sertifika alan adıyla eşleşiyor mu?

Bir TLS sertifikasının, ziyaret edilen alan adını kapsaması gerekir. Kök alan adı ile www alt alan adı ayrı değerlendirildiği için sertifikanın her iki varyantı da kapsayıp kapsamadığına bakılmalıdır.

Örneğin kullanıcı https://www.ornekalanadi.com adresini açıyor, ancak sertifika yalnızca ornekalanadi.com için düzenlenmişse tarayıcı ad eşleşmesi uyarısı verebilir. Tersi durumda da aynı sorun yaşanabilir. Sertifika ayrıntılarında kapsanan alan adlarını ve alternatif adları kontrol edin.

Doğrulama testi: Tarayıcıdaki kilit veya güvenlik simgesinden sertifika bilgilerini açın. Ziyaret edilen adres ile sertifikada kapsanan adların uyumlu olup olmadığını ve sertifikanın geçerli tarih aralığında bulunup bulunmadığını inceleyin.

Karar: Alan adı eşleşmiyor veya sertifika geçerli değilse sorun DNS’te değil, TLS sertifikası ya da sunucu yapılandırmasındadır. Sertifika doğru görünüyorsa HTTPS yönlendirmesi ve sayfa içindeki kaynaklar kontrol edilmelidir.

HTTPS yönlendirmesi neden döngü oluşturabilir?

Birçok site HTTP isteklerini HTTPS’e yönlendirir. Bu davranışın amacı ziyaretçiyi güvenli bağlantıya taşımaktır. Ancak sunucu, proxy veya uygulama HTTPS isteğini yanlış algılarsa istek sürekli olarak aynı ya da benzer adrese yönlendirilebilir.

Belirti: Tarayıcı “çok fazla yönlendirme”, “redirect loop” veya benzeri bir hata gösterir.

Doğrulama testi: HTTP ve HTTPS adreslerinin hangi adımlarla birbirine yönlendiğini tarayıcının Network bölümünden ya da HTTP başlıklarını gösteren bir araçtan inceleyin. Yönlendirme zincirinde aynı adresin tekrar tekrar görülmesi, kural çakışmasına işaret edebilir.

Karar: Yönlendirme döngüsü varsa sorun tarayıcı önbelleğine geçmeden önce sunucu, proxy veya uygulamanın HTTPS’i nasıl algıladığı katmanında çözülmelidir. Kesin çözüm; kullanılan sunucu yazılımına, ters proxy düzenine ve uygulama ayarlarına bağlıdır. Bu nedenle rastgele yönlendirme kuralları eklemek yerine mevcut kuralların hangi koşulda çalıştığı incelenmelidir.

Sayfa açılıyor fakat görseller veya betikler yüklenmiyorsa karma içerik nedir?

Sayfanın ana belgesi HTTPS üzerinden açıldığı hâlde bazı görsel, stil dosyası, yazı tipi veya betik dosyası HTTP adresinden çağrılıyorsa karma içerik oluşur. Bu durumda ana sayfa açılabilir, ancak bazı parçalar tarayıcı tarafından engellenebilir veya uyarıyla gösterilebilir.

Belirti: Metin görünür, fakat görseller eksiktir; menü çalışmaz; stil dosyası uygulanmaz veya geliştirici araçlarında “mixed content” uyarıları görülür.

Doğrulama testi: Tarayıcının geliştirici araçlarında Console ve Network bölümlerini açın. http:// ile başlayan kaynak isteklerini, engellenen dosyaları ve güvenlik uyarılarını arayın.

Çözüm: Aynı alan adındaki kaynakları mümkünse HTTPS URL’leriyle çağırın. Harici bir kaynağın HTTPS sürümü varsa onu kullanın. Uygulamanın oluşturduğu bağlantılar, CSS içindeki arka plan görselleri, JavaScript dosyaları ve form adresleri de ayrıca kontrol edilmelidir.

Tarayıcılar karma içeriğin türüne göre isteği otomatik olarak HTTPS’e yükseltebilir veya güvenli sayfadan HTTP kaynağı yüklemeyi engelleyebilir. Bu nedenle “sayfa açıldı” sonucu, bütün kaynakların doğru yüklendiği anlamına gelmez. MDN karma içerik rehberi, geliştirici konsolundaki uyarıların bu tür kaynakları teşhis etmek için kullanılabileceğini belirtir.

Özetle, güvenlik uyarısı görülen bir sayfada DNS’i tekrar tekrar değiştirmek çoğu zaman doğru ilk adım değildir. Önce sertifikanın ziyaret edilen alan adıyla eşleşmesini, geçerliliğini, HTTPS yönlendirmesini ve sayfa içindeki kaynakların güvenli bağlantı kullanıp kullanmadığını ayırarak inceleyin.

Hosting tarafında boş sayfa, 404 ve 500 hataları nasıl incelenir?

DNS doğru hedefe ulaştığı hâlde sorun devam ediyorsa teşhis hosting ve sunucu yapılandırmasına geçer. Bu aşamada amaç, isteğin sunucuya ulaşıp ulaşmadığını ve sunucunun doğru dosya ya da uygulamayı çalıştırıp çalıştırmadığını ayırmaktır. Boş sayfa her zaman DNS hatası değildir; yanlış site kökü, eksik giriş dosyası, uygulama hatası veya sunucu yapılandırması da benzer bir belirti oluşturabilir.

Önce doğru site kökünü ve ana giriş dosyasını kontrol edin

Bir alan adı sunucuya ulaştığında sunucu, yapılandırılmış site kökünde isteğin karşılığı olan dosyayı arar. Bu kök klasör yanlışsa dosyalar sunucuda bulunmasına rağmen ziyaretçiye gösterilmeyebilir.

• Alan adı doğru hosting hesabına mı bağlı?
• Alan adı doğru document root dizinini mi kullanıyor?
• Ana giriş dosyası beklenen klasörde mi?
• Dosyalar bir alt klasöre yüklenmiş olabilir mi?
• Yönlendirme dosyası, istekleri farklı bir klasöre veya uygulama yoluna mı taşıyor?

Birden fazla site veya test sürümü bulunuyorsa yanlış hosting hesabına bağlanma ihtimali özellikle incelenmelidir. DNS doğru IP adresini gösterse bile sunucu, alan adını yanlış sanal host veya yanlış site tanımıyla eşleştirebilir.

Boş sayfayı statik HTML testiyle ayırın

Boş sayfanın uygulamadan mı, yoksa sunucuya erişimden mi kaynaklandığını anlamak için site köküne geçici ve basit bir statik HTML dosyası yerleştirilebilir. Dosyanın adı örneğin dns-test.html olsun:

<!doctype html>
<html lang="tr">
<head>
  <meta charset="utf-8">
  <title>Sunucu Testi</title>
</head>
<body>
  <h1>Sunucuya erişiliyor</h1>
  <p>Statik HTML dosyası başarıyla yüklendi.</p>
</body>
</html>

Dosyayı gerçekten yapılandırılmış site köküne yükledikten sonra https://ornekalanadi.com/dns-test.html adresini deneyin.

• Test dosyası açılıyorsa: DNS ve temel sunucu erişimi çalışıyor olabilir. Sorun ana giriş dosyasında, uygulamada, yönlendirme kurallarında veya çalışma zamanı yapılandırmasında aranmalıdır.
• Test dosyası da açılmıyorsa: Yanlış site kökü, yanlış hosting hesabı, alan adı eşleştirmesi, sunucu erişimi veya HTTPS yapılandırması yeniden incelenmelidir.
• Test dosyası 404 veriyorsa: Dosya yanlış klasöre yüklenmiş olabilir veya alan adı farklı bir site köküne bakıyor olabilir.
• Test dosyası 500 veriyorsa: Sunucu yapılandırması, yönlendirme kuralı veya dosyayı işleyen çalışma ortamında daha genel bir hata olabilir.

Test tamamlandıktan sonra dosyayı kaldırın. Bu dosya teşhis amacı taşır; sitenin kalıcı giriş dosyası olarak kullanılmamalıdır.

404 hatası neyi gösterir?

404 Not Found, sunucunun istenen kaynak için mevcut bir gösterim bulamadığını veya kaynağın varlığını açıklamamayı tercih ettiğini ifade eder. RFC 9110 HTTP Semantics içinde 404 durumu bu çerçevede tanımlanır.

404 gördüğünüzde şu ayrımı yapın:

• Yalnızca belirli bir sayfa 404 veriyorsa URL yolu, dosya adı, büyük-küçük harf farkı veya uygulama rotası yanlış olabilir.
• Ana alan adı da 404 veriyorsa document root, ana giriş dosyası veya alan adı-site eşleştirmesi incelenmelidir.
• Statik test dosyası açılıyor, uygulama sayfaları 404 veriyorsa sunucuya erişim vardır; sorun uygulama yönlendirmeleri veya eksik dosya yapısındadır.

Dosya adlarında büyük-küçük harf farklarını da kontrol edin. Yerel bilgisayarınızda çalışan bir yol, sunucudaki dosya sistemi davranışı nedeniyle farklı değerlendirilebilir. Ayrıca uygulamanın kullandığı rewrite kuralları, isteği beklenmeyen bir yola yönlendiriyor olabilir.

500 hatası neyi gösterir?

500 Internal Server Error, sunucunun isteği işlerken beklenmeyen bir durumla karşılaştığını gösteren sunucu taraflı bir hata sınıfıdır. Bu hata DNS’in alan adını çözemediğini değil, isteğin sunucuya ulaştıktan sonra işlenemediğini düşündürür.

500 hatasında inceleme başlıkları şunlardır:

• Uygulama yapılandırma dosyasındaki biçim veya değer hataları
• Eksik ortam değişkenleri
• Uyumsuz çalışma zamanı veya eklenti
• Yanlış dosya izinleri
• Bozuk yönlendirme kuralları
• Uygulamanın erişemediği veritabanı ya da harici servis
• Sunucu hata kayıtlarında görülen istisna veya başlatma hataları

500 hatasını çözmek için önce hata kayıtlarına bakın; yalnızca tarayıcıdaki genel mesajdan neden çıkarmaya çalışmayın. Hata kayıtları mevcut değilse uygulama günlüklerini, sunucu günlüklerini ve son yapılan yapılandırma değişikliklerini karşılaştırın. Değişiklikleri tek tek geri almak, hangi ayarın hatayı tetiklediğini bulmayı kolaylaştırır.

Boş sayfa, 404 ve 500 arasındaki hızlı ayrım

Bu üç belirtiyi aynı kategoriye koymayın. 404 çoğunlukla istenen kaynağın bulunmasıyla, 500 ise sunucunun isteği işlerken hata vermesiyle ilgilidir. Boş sayfa ise görünür bir HTTP hata kodu olmadan uygulamanın içerik üretememesi gibi farklı nedenlerden kaynaklanabilir. Teşhiste ilk ayrım, her zaman ana isteğin gerçekten hangi HTTP yanıtını verdiğini öğrenmektir.

Kontrol listesini uyguladıktan sonra hangi adım atılmalı?

Kontrollerin sonunda amaç, her ayarı değiştirmek değil, sorunun hangi katmanda bulunduğunu kesinleştirmektir. DNS çözümlemesi başarısızsa nameserver ve DNS kayıtlarında kalın; yanlış site geliyorsa hedef IP adresini ve hosting hesabını doğrulayın; sunucu yanıt verdiği hâlde sayfa bulunamıyorsa site kökü ile URL yolunu inceleyin. Böylece aynı ayarı tekrar tekrar değiştirerek yeni sorunlar oluşturmazsınız.

Bulguya göre tek bir sonraki adım seçin

DNS çözümlemiyorsa, hosting dosyalarına veya uygulama koduna geçmeden önce nameserver ve kayıt katmanında kalın. Alan adının DNS yönetiminin hangi hizmette olduğunu netleştirin. Kayıtları bir panelde değiştirip başka bir panelde kontrol etmek, özellikle yeni başlayanlarda sık görülen bir karışıklıktır.

Yanlış site geliyorsa, sorun genellikle “site dosyası yok” anlamına gelmez. Alan adı başka bir IP adresine gidiyor olabilir veya doğru sunucuda alan adı yanlış hosting hesabına eşlenmiş olabilir. Bu durumda önce çözümlenen IP adresini, ardından hosting panelindeki alan adı ve site kökü eşleşmesini karşılaştırın.

Sunucu yanıt veriyor ama dosya bulunamıyorsa, 404 hatasını DNS sorunu gibi ele almayın. Alan adı doğru sunucuya ulaşmış olabilir; ancak ana giriş dosyası beklenen klasörde olmayabilir, URL yolu yanlış olabilir ya da yönlendirme kuralı isteği farklı bir adrese taşıyor olabilir.

500 hatası veya boş sayfa varsa, sunucu günlükleri en değerli kanıttır. Son değiştirilen yapılandırma dosyası, uygulama ortam değişkenleri, dosya izinleri, bağımlılık sürümleri veya veritabanı bağlantısı gibi noktaları sırayla inceleyin. Hata kaydı görülmeden rastgele dosya silmek ya da tüm ayarları yeniden yazmak teşhisi zorlaştırır.

Sorun yalnızca HTTPS tarafındaysa, DNS ve hosting bağlantısını tamamen baştan kurmak yerine sertifika ile yönlendirmeyi ayırarak değerlendirin. Sertifika alan adıyla eşleşiyor mu, www ve kök alan adı kapsam içinde mi, HTTPS isteği doğru siteye mi yönleniyor sorularını ayrı ayrı yanıtlayın. Paneldeki sertifika ve yönlendirme seçenekleri hizmete göre değişebileceği için kullanılan DNS yönetim hizmetinin ve hosting panelinin güncel resmî yardım belgeleri ayrıca incelenmelidir.

Son kontrol listesi

• Değişiklik yapmadan önce mevcut ayarı kaydedin. Nameserver, A kaydı, CNAME, yönlendirme ve SSL ayarlarının mevcut hâlini not almak, gerektiğinde geri dönüşü kolaylaştırır.
• Tek seferde tek katmanı değiştirin. Aynı anda DNS kaydını, site kökünü ve HTTPS yönlendirmesini değiştirmeyin. Aksi hâlde hangi işlemin sonucu etkilediğini anlayamazsınız.
• Aynı testi farklı ağda tekrarlayın. Mümkünse farklı bir internet bağlantısı, farklı cihaz veya gizli tarayıcı penceresi kullanın. Böylece yerel önbellek ile genel erişim sorununu birbirinden ayırabilirsiniz.
• Alan adının kök hâlini ve www sürümünü ayrı ayrı deneyin.
• HTTP ve HTTPS adreslerini ayrı ayrı kontrol edin.
• Tarayıcıdaki hata mesajını, test saatini ve denenen adresi kaydedin.
• Bir ayarı değiştirdikten sonra hemen yeni bir ayara geçmek yerine aynı kontrol adımlarını yeniden uygulayın.

Bu adımlardan sonra hâlâ net bir bulgu elde edilemiyorsa, elinizdeki kayıtlarla hosting destek ekibine veya DNS yönetim hizmetinin desteğine başvurun. İletilecek bilgiler arasında alan adı, görülen hata, kullanılan adres, test edilen ağ, çözümlenen IP adresi ve son yapılan değişiklik bulunmalıdır. Parola, özel anahtar veya gizli erişim bilgilerini destek talebine eklemeyin.

Sık Sorulan Sorular

Domain doğru hosting hesabına bağlı olduğu halde neden eski site görünüyor?

Alan adı doğru sunucuya gidiyor olsa bile hosting tarafında alan adı yanlış site köküyle eşleşmiş olabilir. Ayrıca tarayıcı veya yerel DNS önbelleği daha önce görülen içeriği gösterebilir. Önce farklı ağda ve gizli pencerede test yapın; sonuç aynıysa hosting hesabındaki alan adı eşlemesini, varsayılan siteyi ve dosyaların bulunduğu kök klasörü inceleyin.

Kök alan adı açılırken www neden açılmıyor?

Kök alan adı ile www, DNS açısından ayrı adlar gibi değerlendirilebilir. Kök alan adı için doğru A kaydı bulunurken www için CNAME veya uygun bir A kaydı eksik olabilir. Her iki adresin de doğru hedefe çözümlendiğini, hosting tarafında her ikisinin de tanımlı olduğunu ve HTTPS sertifikasının iki adı da kapsadığını kontrol edin.

DNS_PROBE hatası ile 404 hatası arasındaki temel fark nedir?

DNS_PROBE türü hata, tarayıcının alan adını kullanılabilir bir sunucu adresine çözümlemekte zorlandığını gösterir. 404 ise istek bir web sunucusuna ulaştıktan sonra istenen sayfa, dosya veya URL yolunun bulunamadığını belirtir. Bu nedenle DNS_PROBE hatasında nameserver ve kayıtlar; 404 hatasında site kökü, dosya yolu ve yönlendirmeler incelenir.

SSL kurulduktan sonra tarayıcı neden güvenlik uyarısı göstermeye devam eder?

Sertifika kurulmuş olsa bile sertifika ile açılan alan adı eşleşmeyebilir, sertifika zinciri eksik olabilir veya sayfa içindeki bazı kaynaklar hâlâ güvenli olmayan HTTP adreslerinden yüklenebilir. Kök alan adı ve www sürümünü ayrı ayrı test edin. Ayrıca HTTPS yönlendirmesinin doğru siteye gittiğini ve tarayıcının gösterdiği uyarının sertifika mı yoksa sayfa içeriği mi kaynaklı olduğunu ayırt edin.

DNS ayarlarını değiştirdikten sonra sorun yalnızca benim bilgisayarımda görünüyorsa ne kontrol etmeliyim?

Gizli pencerede veya farklı bir tarayıcıda deneyin, tarayıcı önbelleğini ve ilgili çerezleri temizleyin. Ardından farklı bir internet bağlantısından aynı alan adını açın. Diğer ağlarda site çalışıyorsa bilgisayarın, modem yönlendiricinin veya işletim sisteminin DNS önbelleğinde eski bir kayıt tutuluyor olabilir. Yerel DNS önbelleğini yeniledikten sonra testi tekrar edin.

Doğru katmanı belirleyip tek değişiklikle ilerlemek, domain ve hosting bağlantısı sonrasındaki sorunları panik yapmadan çözmenin en güvenli yoludur.