Sitem Açılmıyor: Sorunun Nerede Olduğunu Nasıl Bulurum?

Sitem açılmıyor cümlesi, teknik destek kayıtlarında en sık yazılan ama en az bilgi taşıyan cümledir. Çünkü "açılmıyor" onlarca farklı durumu aynı torbaya koyar: tarayıcı hiç bağlanamıyor olabilir, bağlanıp beyaz ekran dönüyor olabilir, sizde açılmayıp telefonda açılıyor olabilir, ya da alan adı hiç çözümlenmiyordur. Bunların her birinin nedeni de çözümü de birbirinden tamamen farklıdır. Bu yüzden sorunu çözmenin ilk adımı düzeltmeye çalışmak değil, hangi katmanda olduğunuzu belirlemektir.

Bu rehber size bir çözüm listesi vermiyor; bir karar ağacı veriyor. Sırayla beş kontrol yapacağız ve her kontrol elinizdeki ihtimallerin yarısını eleyecek. Sonunda ya sorunu doğrudan çözmüş olacaksınız ya da elinizde "sunucu 443 portunda cevap vermiyor" gibi tek cümlelik, net bir teşhis olacak — ki hosting sağlayıcınıza yazacağınız destek talebinin işe yaraması için ihtiyacınız olan tam olarak budur. Her adımda hem tarayıcıdan hem komut satırından yapabileceğiniz karşılıkları vereceğim, çünkü SSH erişimi olmayan bir kullanıcı da bu akışı sonuna kadar yürütebilmeli.

Teşhise Başlamadan Önce Belirtiyi Netleştirin#

Doğru soruyu sormanın tek yolu, ekranda gördüğünüz şeyi kelimesi kelimesine yazmaktır. "Açılmıyor" yerine şu beş kategoriden hangisine düştüğünüzü belirleyin:

1. Tarayıcı hiç bağlanamıyor. ERR_CONNECTION_REFUSED, ERR_CONNECTION_TIMED_OUT, "Bu siteye ulaşılamıyor" gibi tarayıcı kaynaklı mesajlar.
2. Alan adı bulunamıyor. DNS_PROBE_FINISHED_NXDOMAIN, ERR_NAME_NOT_RESOLVED, "Sunucu IP adresi bulunamadı".
3. Sunucu cevap veriyor ama hata kodu dönüyor. 500, 502, 503, 403, 404 gibi numaralı sayfalar.
4. Güvenlik uyarısı çıkıyor. "Bağlantınız gizli değil", ERR_SSL_PROTOCOL_ERROR, sertifika uyarısı.
5. Sayfa açılıyor ama boş / bozuk. Beyaz ekran, yarım yüklenen tasarım, sonsuz yönlendirme.

Bu ayrım, ilerideki adımların hangisinden başlayacağınızı belirler. İlk iki kategori ağ ve DNS katmanındadır; üçüncü ve beşinci kategori sunucu size cevap verdiği için doğrudan uygulama katmanına atlar; dördüncü kategori ise sertifikaya bakmanız gerektiğini söyler.

Bir de zaman bilgisini not edin: ne zaman çalışıyordu, arada ne değişti? Değişikliğin kendisi çoğu vakada cevabın yarısıdır — alan adı yenilendi mi, nameserver değiştirildi mi, eklenti güncellendi mi, sunucu taşındı mı, fatura ödendi mi?

Adım 1: Site Herkeste mi Kapalı, Sadece Sizde mi#

İlk soru budur ve tek başına ihtimallerin yarısını eler. Yanıtı bulmak için sitenize kendi bağlantınızın dışından erişmeyi deneyin: telefonunuzun mobil verisiyle (Wi-Fi kapalı), farklı bir ağdaki bir arkadaşınızdan, ya da bir çevrimiçi erişilebilirlik kontrol servisiyle.

Sonuç iki türlü olur:

• Başka ağlarda açılıyor, sizde açılmıyor: Sorun sunucuda değil, sizin cihazınızda, ağınızda veya DNS önbelleğinizdedir. Aşağıdaki yerel kontrolleri yapın.
• Hiçbir yerde açılmıyor: Sorun sunucu tarafındadır, Adım 2'ye geçin.

Sadece sizde kapalıysa şu üçünü sırayla deneyin. Önce tarayıcı önbelleğinden bağımsız test için gizli pencere açın ve tüm eklentileri devre dışı bırakın; reklam engelleyiciler ve VPN uzantıları şaşırtıcı sıklıkla suçludur. Sonra işletim sisteminin DNS önbelleğini temizleyin:

ipconfig /flushdns

# macOS
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
# systemd kullanan Linux
sudo resolvectl flush-caches

Üçüncü olarak hosts dosyanızı kontrol edin. Site taşıma sırasında test amacıyla eklenip sonra unutulan bir satır, sizi aylarca eski sunucuya yönlendirebilir. Windows'ta C:\Windows\System32\drivers\etc\hosts, Linux ve macOS'ta /etc/hosts dosyasını açıp alan adınızın geçtiği satırları silin.

Kurumsal bir ağdaysanız güvenlik duvarının siteyi kategorik olarak engellemiş olma ihtimalini de eleyin; bu, "sadece ofiste açılmıyor" vakalarının klasik nedenidir. Modemi yeniden başlatmak da işe yarayabilir, çünkü ev tipi yönlendiricilerin çoğu kendi DNS önbelleğini tutar ve orada takılı kalmış eski bir kayıt tarayıcı temizliğiyle gitmez.

Adım 2: Alan Adı Çözümleniyor mu#

İkinci kontrol, alan adınızın bir IP adresine dönüşüp dönüşmediğidir; bu dönüşüm olmuyorsa sunucunuz çalışıyor olsa bile kimse siteye ulaşamaz. Komut satırından tek satırda test edilir:

dig +short ornek.com
dig +short www.ornek.com

nslookup ornek.com
nslookup www.ornek.com

Sonucu şöyle yorumlayın:

• Hiçbir çıktı yok veya NXDOMAIN dönüyor: Alan adı için A kaydı tanımlı değil, ya da alan adı süresi dolmuş/askıya alınmış olabilir. DNS_PROBE_FINISHED_NXDOMAIN ekranı tam olarak bunun tarayıcıdaki karşılığıdır; ayrıntılı çözüm için NXDOMAIN hatası yazısına bakın.
• Bir IP dönüyor ama yanlış IP: Nameserver'lar hâlâ eski sağlayıcıyı gösteriyor ya da DNS değişikliği yayılmamış olabilir.
• ornek.com çözümleniyor ama www.ornek.com çözümlenmiyor (veya tersi): Eksik olan tek bir kayıttır. Bu, "site bazen açılıyor bazen açılmıyor" şikâyetinin en yaygın nedenidir, çünkü kullanıcıların bir kısmı www'lu adresi yazar.

Alan adının hangi nameserver'lara emanet edildiğini de doğrulayın:

dig NS ornek.com +short
whois ornek.com | grep -i -E "expir|status|name server"

whois çıktısındaki bitiş tarihi geçmişse teşhis tamamlanmıştır: alan adının süresi dolmuştur ve yapılacak tek şey yenilemektir. Bu, yılda bir kez herkesin başına gelen ama en son akla gelen nedendir. Kayıt firmanızın panelinden yenileme yaptıktan sonra çözümlemenin geri gelmesi genellikle kısa sürer.

Nameserver'ları yeni değiştirdiyseniz sabırlı olmanız gereken bir yayılma süresi vardır. Değişikliğin farklı bölgelerde ne durumda olduğunu görmek için dig @8.8.8.8 ornek.com ve dig @1.1.1.1 ornek.com sorgularını karşılaştırın; ikisi farklı IP döndürüyorsa yayılım hâlâ sürüyor demektir. Değişiklik sonrası sitenin bir süre iki farklı sunucudan servis edilmesi normaldir, kalıcı hâle gelirse Adım 3'e geçin.

Adım 3: Sunucu Cevap Veriyor mu#

Alan adı doğru bir IP'ye çözümleniyorsa sıradaki soru, o IP'nin web portlarında yaşam belirtisi gösterip göstermediğidir. Önce genel erişilebilirlik:

ping -c 4 ornek.com
traceroute ornek.com

ping cevapsız kalması tek başına sunucunun kapalı olduğunu göstermez; birçok sunucu ve güvenlik duvarı ICMP paketlerini bilerek yanıtsız bırakır. Bu yüzden asıl testi portlar üzerinden yapın:

nc -zv ornek.com 80
nc -zv ornek.com 443

Test-NetConnection ornek.com -Port 443

Sonuçların anlamı şudur:

• Bağlantı reddedildi (connection refused): Sunucuya ulaşıldı ama o portta dinleyen bir servis yok. Web sunucusu (Nginx/Apache) durmuş demektir. Ayrıntı için ERR_CONNECTION_REFUSED hatası yazısı.
• Zaman aşımı (timed out): Paket hiç dönmüyor. Genelde güvenlik duvarı engeli, IP değişikliği ya da sunucunun tamamen kapalı olması. ERR_CONNECTION_TIMED_OUT hatası bu dalın devamıdır.
• Bağlantı açıldı: Sunucu ayakta ve dinliyor. Sorun artık ağ katmanında değil, HTTP katmanında. Adım 4'e geçin.

Ağ yolunda nerede takıldığını görmek için mtr çok daha okunaklı bir araçtır ve kayıp yaşanan atlamayı canlı gösterir; kullanımını ping, traceroute ve mtr ile ağ tanılama yazısında bulabilirsiniz.

SSH erişiminiz varsa sunucunun içinden bakmak birkaç saniyede kesin sonuç verir:

systemctl status nginx
ss -ltnp | grep -E ':80|:443'
df -h

Bu üç komut sırasıyla şunu söyler: web sunucusu çalışıyor mu, 80 ve 443 portlarını gerçekten dinliyor mu, ve disk dolu mu. Üçüncüsünü küçümsemeyin — dolu disk, web sunucusunun log yazamayıp durmasına yol açar ve dışarıdan tam olarak "sunucu cevap vermiyor" gibi görünür.

Adım 4: Sunucu Cevap Veriyor ama Hata Dönüyor#

Bağlantı kuruluyorsa artık HTTP katmanındasınız ve elinizde çok değerli bir ipucu var: durum kodu. Tarayıcı bazen bunu güzelleştirilmiş bir sayfayla gizler, o yüzden ham cevabı görün:

curl -I -L https://ornek.com

curl.exe -I -L https://ornek.com

Dönen ilk satırdaki üç haneli sayı teşhisin kendisidir:

Tüm kodların kısa karşılıklarını tek sayfada görmek isterseniz HTTP durum kodları listesi hızlı bir referanstır; 500, 502 ve 503 gibi sık karşılaşılan kodların her birinin kendi teşhis akışı olduğunu unutmayın.

Hata kayıtlarına bakmak neredeyse her zaman tahmin yürütmekten hızlıdır. cPanel kullanıyorsanız Metrics → Errors ekranı son hataları gösterir; SSH erişiminiz varsa:

sudo tail -n 50 /var/log/nginx/error.log
sudo tail -n 50 /var/log/apache2/error.log
sudo tail -n 50 /home/kullanici/logs/ornek.com.error.log

WordPress kullanıyorsanız ölümcül hatanın metnini görmek için hata raporlamayı geçici olarak açın; wp-config.php içine şunu ekleyin ve teşhis biter bitmez geri alın:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

Bu üç satır, hataları ekranda ziyaretçilere göstermeden wp-content/debug.log dosyasına yazar. Beyaz ekranın altında yatan gerçek hata mesajı orada, dosya adı ve satır numarasıyla birlikte durur.

Adım 5: HTTPS ve Sertifika Kaynaklı Erişim Sorunları#

Ekranda "Bağlantınız gizli değil" ya da sertifika uyarısı çıkıyorsa sunucunuz büyük olasılıkla çalışıyor; sorun sadece TLS katmanındadır. En sık üç nedenden biridir: sertifikanın süresi dolmuştur, sertifika sitenin alan adıyla eşleşmiyordur (www'lu ya da www'suz hâli kapsanmıyordur), ya da ara sertifika zinciri eksik yüklenmiştir.

Zinciri ve süreyi komut satırından doğrulayın:

echo | openssl s_client -connect ornek.com:443 -servername ornek.com 2>/dev/null | openssl x509 -noout -dates -subject -issuer

Çıktıdaki notAfter tarihi geçmişse tek yapmanız gereken sertifikayı yenilemektir. subject satırındaki alan adı sizin adresinizle uyuşmuyorsa yanlış sertifika kurulmuş demektir. Tarayıcıda "sertifika geçerli ama site yine de yüklenmiyor" durumu varsa büyük ihtimalle karışık içerik (mixed content) sorunu yaşıyorsunuzdur: sayfa HTTPS ile geliyor ama içindeki bazı dosyalar HTTP ile çağrılıyordur.

Karışık içerik sorununda tarayıcının geliştirici konsolu size hangi dosyanın HTTP ile çağrıldığını satır satır söyler; düzeltme, o adresleri HTTPS'e çevirmektir. Sonsuz yönlendirme döngüsüne giriyorsanız (ERR_TOO_MANY_REDIRECTS) neden genelde HTTPS zorlamasının hem sunucuda hem uygulamada aynı anda tanımlanmış olmasıdır; iki taraftan birini kaldırmak döngüyü bitirir.

Beş Sık Senaryo ve Hızlı Çözümleri#

Aşağıdakiler, yıllar içinde en çok tekrarlandığını gördüğüm ve teşhis akışının belirli bir noktasında düğümlenen vakalardır.

Senaryo 1 — "Dün akşam çalışıyordu, sabah kapalıydı, hiçbir şey yapmadım." Neredeyse her zaman bir süre bitişidir: alan adı, hosting paketi ya da SSL sertifikası. Önce whois ile alan adı tarihine, sonra hosting panelinizdeki hesap durumuna bakın. Ödeme gecikmesi nedeniyle askıya alınan hesaplarda panel girişi genelde açık kalır ve bildirimler bölümü nedeni açıkça yazar.

Senaryo 2 — "Eklenti güncelledim, site beyaz ekran." Adım 4'teki hata raporlamayı açın; hangi eklentinin hangi satırda patladığını göreceksiniz. Panele giremiyorsanız FTP ile wp-content/plugins klasöründeki ilgili eklenti dizinini yeniden adlandırmak eklentiyi devre dışı bırakır ve site geri gelir.

Senaryo 3 — "Sitem bende açılmıyor, müşterilerimde açılıyor." Adım 1'in tam kapsamıdır: yerel DNS önbelleği, hosts dosyası ya da bir tarayıcı eklentisi. Farklı bir cihaz ve farklı bir ağ ile doğrulayın, sonra yerel temizliği yapın.

Senaryo 4 — "Sunucuyu taşıdık, bazı ziyaretçiler eski siteyi görüyor." DNS yayılımı sürüyor demektir. Yeni A kaydının TTL değerini taşıma öncesinde düşürmek bu süreyi kısaltır; taşıma sırasında eski sunucuyu bir süre daha ayakta tutmak da veri kaybını önler. Doğru sıra şudur: önce TTL'i düşür, sonra içeriği taşı, en son nameserver'ı değiştir.

Senaryo 5 — "Site bazen açılıyor bazen 503 veriyor." Bu bir kaynak sorunudur, bağlantı sorunu değil. Trafik arttıkça hesap ya da sunucu limitine çarpıyorsunuz. Panelinizin kaynak kullanım grafiğine bakın; veritabanı kaynaklıysa bağlantı limitine çarpıyor olabilirsiniz ve bu durumda hata kayıtlarında MySQL kaynaklı satırlar görürsünüz.

Hosting Sağlayıcınıza Ne Yazmalısınız#

Teşhis akışını tamamladıysanız elinizde bir destek talebini birkaç saatten birkaç dakikaya indirecek bilgiler var demektir. İyi bir talep şu beş maddeyi içerir:

1. Tam alan adı ve hata veren tam URL (ana sayfa mı, tek bir sayfa mı).
2. Ekranda çıkan mesajın birebir metni ya da HTTP durum kodu.
3. Sorunun ne zaman başladığı ve o tarihte yapılan değişiklik.
4. Sorunun kimde görüldüğü: sadece sizde mi, farklı ağlardan da mı.
5. Yaptığınız testlerin çıktısı: dig +short sonucu, curl -I çıktısının ilk satırı, port testi sonucu.

Bu maddeler olmadan gönderilen "sitem açılmıyor" mesajı, karşı taraftaki mühendisi sizin az önce yaptığınız beş adımı baştan yapmaya zorlar. Beşinci maddedeki üç satırı yapıştırmak, süreci genellikle tek turda bitirir.

Sıkça Sorulan Sorular#

Site sadece bende açılmıyorsa ne yapmalıyım#

Önce sorunun gerçekten yerel olduğunu doğrulayın: telefonunuzun mobil verisiyle, Wi-Fi kapalıyken siteyi açmayı deneyin. Açılıyorsa sorun sunucuda değil sizin tarafınızdadır ve sırasıyla şunları temizleyin: tarayıcı önbelleği ve çerezler, işletim sisteminin DNS önbelleği, hosts dosyasındaki eski test kayıtları. Reklam engelleyici eklentileri ve VPN bağlantılarını da geçici olarak kapatın, çünkü ikisi de tek bir alan adını sessizce engelleyebilir. Kurumsal bir ağdaysanız güvenlik duvarının siteyi kategori bazlı engellemediğinden emin olun.

Alan adının süresinin dolduğunu nasıl anlarım#

Alan adı sorgulama komutuyla bitiş tarihini doğrudan görebilirsiniz: komut satırında whois alanadiniz.com çalıştırıp çıktıdaki bitiş veya Expiry Date satırına bakın. Tarih geçmişse alan adı çözümlenmeyi durdurur ve tarayıcı "sunucu IP adresi bulunamadı" benzeri bir mesaj verir. Süresi dolan alan adları belirli bir süre boyunca sahibi tarafından yenilenebilir durumda kalır, sonrasında ek ücretli kurtarma dönemine girer. Bu yüzden fark ettiğiniz anda kayıt firmanızın panelinden yenilemeyi yapmak en ucuz ve en hızlı çözümdür.

Ping cevap vermiyor, sunucu kapalı mı demek#

Hayır, tek başına bunu göstermez. Çok sayıda sunucu ve ağ güvenlik duvarı ICMP paketlerini bilinçli olarak yanıtsız bırakır; bu bir arıza değil, yaygın bir güvenlik tercihidir. Gerçek testi web portları üzerinden yapmalısınız: 80 ve 443 portlarına bağlantı kurulup kurulmadığını kontrol edin. Port açılıyorsa sunucu ayaktadır ve sorun HTTP katmanındadır; port reddediliyorsa web servisi durmuş, zaman aşımına uğruyorsa büyük olasılıkla güvenlik duvarı engeli veya IP değişikliği vardır.

Beyaz ekran görüyorum, hata kodu yok, nereden başlamalıyım#

Beyaz ekran genellikle ölümcül bir PHP hatasının kullanıcıya gösterilmeden bastırılması sonucu oluşur. İlk yapılacak iş hata mesajını görünür kılmaktır: WordPress kullanıyorsanız wp-config.php içinde hata kaydını dosyaya yazacak şekilde açın ve wp-content/debug.log dosyasını okuyun. Diğer uygulamalarda sunucunun hata kayıt dosyasına bakmak aynı bilgiyi verir. Genellikle karşınıza dosya adı ve satır numarasıyla birlikte suçlu eklenti, tema ya da bellek limiti çıkar; teşhis biter bitmez hata gösterimini kapatmayı unutmayın.

DNS değişikliği yaptım, site ne zaman açılır#

Yayılma süresi, değiştirdiğiniz kaydın TTL değerine ve ziyaretçinin kullandığı çözümleyicinin önbelleğine bağlıdır. Bu yüzden herkes için aynı anda değil, kademeli olarak açılır: bazı ziyaretçiler yeni sunucuyu dakikalar içinde görürken bazıları eski kaydı bir süre daha kullanmaya devam eder. Süreci kısaltmanın en etkili yolu değişiklikten önce TTL değerini düşürmektir; sonrasında düşürmek geç kalmış bir müdahaledir. Kendi tarafınızda yeni kaydı görüp görmediğinizi anlamak için DNS önbelleğinizi temizleyip alan adını yeniden sorgulayın.

Hosting hesabım askıya alınmışsa site nasıl görünür#

Askıya alınmış hesaplarda genellikle sitenin kendisi yerine sağlayıcının bilgilendirme sayfası ya da bir hata kodu döner; en yaygın olanı 403 ve 503'tür. Askıya alma sebebi ödeme gecikmesi olabileceği gibi kaynak aşımı, kötü amaçlı yazılım tespiti ya da spam gönderimi de olabilir. Panelinize giriş yapabiliyorsanız hesap durumu ve bildirimler bölümü nedeni açıkça yazar. Sebebi çözmeden yapılan yeniden aktifleştirme talepleri genelde reddedilir, bu yüzden önce bildirimdeki gerekçeyi gidermek gerekir.

Site açılıyor ama çok yavaş, bu da aynı sorun mu#

Farklı bir sorundur ve farklı bir yöntemle teşhis edilir. Erişilemezlik sorunlarında ağ, DNS ve servis durumunu kontrol edersiniz; yavaşlıkta ise sunucunun ilk baytı gönderme süresi, veritabanı sorgu süreleri, görsel boyutları ve önbellekleme durumu incelenir. Yine de iki konu birbirine komşudur: kaynak limitine yaklaşan bir sunucu önce yavaşlar, sonra aralıklı olarak 503 vermeye başlar. Bu yüzden aralıklı erişim sorunu yaşıyorsanız performans tarafını da incelemek gerekir.

Kapanış#

"Sitem açılmıyor" bir sorun değil, bir belirtidir; ve o belirtinin altında birbirinden tamamen bağımsız beş katman yatar. Bu yazıdaki akışı sırayla uyguladığınızda — önce sizde mi herkeste mi, sonra alan adı çözümleniyor mu, sonra sunucu porttan cevap veriyor mu, sonra hangi HTTP kodunu dönüyor, en sonda sertifika sağlam mı — her adım ihtimallerin bir kısmını kesin olarak eler. Böylece rastgele çözüm denemek yerine, elinizde tek cümlelik net bir teşhisle ya doğrudan düzeltmeyi yapar ya da doğru kişiye doğru soruyu sorarsınız. Teşhisi hızlandırmanın en iyi yolu ise hazırlıklı olmaktır: güncel bir yedeğiniz, panel erişim bilgileriniz ve son yapılan değişikliklerin kaydı elinizin altında olsun.

Bu tür kesintileri kendi başınıza yönetmek yerine altyapıyı üstlenecek birini istiyorsanız, teknik desteğin yanınızda olduğu bir web hosting paketi çoğu küçük ve orta ölçekli site için doğru başlangıçtır; sunucu işletimini ve izlemeyi tümüyle devretmek isterseniz sunucu yönetimi hizmetinden yararlanabilirsiniz. Bir arıza anında en çok işinize yarayacak şey ise düzenli yedekleme olacaktır — çünkü geri dönebileceğiniz bir noktanız varsa hiçbir hata kalıcı değildir.