Sitem açılmıyor: DNS mi, sunucu mu, sertifika mı?

Site açılmadığında üç ayrı katmandan biri bozulmuştur: alan adının doğru yere işaret etmesi, sunucunun yanıt vermesi ve bağlantının şifrelenmesi. Üçü benzer şekilde "açılmıyor" görünür ama üçü tamamen farklı yerde çözülür. Aşağıdaki sıra, en ucuz kontrolden başlayarak hangisi olduğunu birkaç dakikada söyler.

Tarayıcıdaki mesaj katmanı gösterir

Teşhise tahminle değil ekrandaki metinle başlayın.

1. Sadece sizde mi açılmıyor?

Bu kontrol bedavadır ve vakaların azımsanmayacak kısmını kapatır. Telefonunuzun mobil verisinden ve bir gizli sekmeden deneyin. Tarayıcı önbelleği, HSTS kaydı ve işletim sisteminin DNS önbelleği eski bilgiyi saatlerce tutabilir; sadece sizde açılmıyorsa sunucuda arayacak bir şey yoktur.

2. Alan adı doğru IP'ye mi bakıyor?

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

Windows'ta karşılığı nslookup ornek.com komutudur.

Alan adınız bir CDN veya proxy arkasındaysa dig size sunucunuzun adresini değil o servisin adresini döndürür; bu normaldir ve tek başına hata değildir. Ama o durumda teşhis bir katman daha uzar: proxy sunucunuza ulaşamıyorsa hata sizin sunucunuzdan değil aradaki katmandan geliyor olabilir. Proxy'yi geçici olarak devre dışı bırakmak veya 3. adımdaki doğrudan IP testini yapmak bu ikisini ayırır.

Dönen adres beklediğiniz sunucunun adresi değilse teşhis DNS'te biter. Üç sık sebep var: kaydı yeni değiştirdiniz ve TTL süresi dolmadı, alan adının ad sunucuları hâlâ eski sağlayıcıyı gösteriyor, ya da — en sinsisi — alan adının süresi doldu. Üçüncüsünde sunucuda hiçbir şey bozuk değildir; kayıt firmanızın panelinden bakın.

3. Sunucu yanıt veriyor mu?

DNS'i tamamen devre dışı bırakıp sunucuyu doğrudan sorgulayabilirsiniz. Bu, teşhisteki en keskin tek adımdır:

curl -I http://185.137.98.29
curl -I -H "Host: ornek.com" http://185.137.98.29

İkinci komut isteği doğru alan adıyla ama doğrudan IP'ye gönderir. Buradan yanıt geliyorsa sunucu da site de ayaktadır ve sorun kesin olarak DNS tarafındadır. Yanıt gelmiyorsa 4. adıma geçin.

Sunucuya SSH ile de giremiyorsanız önce erişimi çözün: sunucuma bağlanamıyorum

4. Web servisi çalışıyor mu?

systemctl status nginx
ss -tulpn | grep -E ':80|:443'
nginx -t

"Bağlantı reddedildi" hatasının arkasındaki sebep neredeyse her zaman burada görünür: servis durmuştur veya bir yapılandırma değişikliğinden sonra yeniden başlatılmamıştır. nginx -t yapılandırmayı uygulamadan sınar; hata varsa satır numarasını verir.

Servis başlamıyorsa akla gelmeyen bir sebebi eleyin: dolu disk. Log yazamayan bir web sunucusu açılmaz ve hata mesajı bunu doğrudan söylemez. Kontrolü ve güvenli temizliği: disk doldu

5. Sertifika

Sertifika sorunları tarayıcıda korkutucu görünür ama teşhisi kolaydır:

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

Çıktıdaki notAfter tarihi geçmişse sertifikanın süresi dolmuştur. Let's Encrypt kullanıyorsanız üç sebep sık görülür: yenileme görevi çalışmıyordur, doğrulama için gereken 80 portu güvenlik duvarında kapatılmıştır, ya da alan adı artık o sunucuya bakmadığı için doğrulama başarısız olmuştur.

subject satırındaki alan adı istediğinizle uyuşmuyorsa sertifika yanlış alan adı içindir — en sık hâli, sertifikanın yalnızca kök alan adını kapsayıp www ile açıldığında hata vermesidir.

6. Hâlâ bulamadıysanız: loglar

journalctl -u nginx -n 50 --no-pager
tail -n 100 /var/log/nginx/error.log

500 ve 502 hatalarının sebebi burada yazar. 502, web sunucusunun arkadaki uygulamaya (PHP-FPM, Node, uygulama sunucusu) ulaşamadığı anlamına gelir; o sürecin çalışıp çalışmadığını ayrıca kontrol edin. Sık rastlanan bir başka kök sebep, veritabanının yanıt vermemesidir: MySQL performans ayarları

Ne zaman destek talebi açmalı

Şu durumlarda kendi başınıza ilerleyecek yer kalmamıştır:

• curl ile doğrudan IP'ye yanıt alamıyorsunuz ve sunucuya konsoldan da giremiyorsunuz.
• DNS doğru, servis çalışıyor, sertifika geçerli — ama dışarıdan hâlâ erişilemiyor.
• Web hosting kullanıyorsanız ve sorun servis seviyesindeyse: sunucu servislerine erişiminiz zaten yoktur, doğrudan talep açmak en hızlı yoldur.

Talebe alan adını, hata mesajının tam metnini, dig +short çıktısını ve sorunun başladığı saati ekleyin. Kesintinin taahhüt kapsamında ne anlama geldiği ayrı bir konudur: uptime ve SLA

Sorun tekrar ediyorsa ve sebebi kaynak sınırıysa, sitenin hangi katmanda barınması gerektiği sorusuna dönmek gerekir. WordPress için hazırlanmış yapılandırmalarda sınırlar farklıdır; iki seçeneğin sınırlarını ve aylık tutarını yan yana görmek isterseniz: hangisi sitenize daha uygun, güncel fiyatlarla