Site açılmıyor: ping, traceroute ve mtr ile sorunun nerede olduğunu bulmak

Bir site açılmadığında içgüdüsel tepki, sunucuyu yeniden başlatmaktır. Bazen işe yarar, çoğu zaman yaramaz. Çünkü sorun sunucuda olmayabilir. Arada DNS, internet servis sağlayıcınız, bir yönlendirici ya da güvenlik duvarı vardır.

Sorunu bulmanın en hızlı yolu, katmanları aşağıdan yukarıya doğru tek tek kontrol etmektir.

1. Ad doğru IP'ye çözülüyor mu?

dig +short ornek.com

Beklediğiniz IP'yi görüyor musunuz? Boş cevap geliyorsa, ya da eski sunucunun IP'si dönüyorsa sorun DNS'tedir. Farklı çözümleyicilerin ne dediğine de bakın:

dig +short @1.1.1.1 ornek.com
dig +short @8.8.8.8 ornek.com

Biri yeni IP'yi, diğeri eskisini veriyorsa bir önbellek henüz yenilenmemiştir (kaydın TTL süresi dolmamıştır). Beklemek ya da yerel DNS önbelleğinizi temizlemek gerekir.

2. Sunucuya ulaşılabiliyor mu? (ping)

ping -c 4 203.0.113.10

ping hedefe ICMP paketleri gönderir ve cevap süresini ölçer. Üç olası sonuç var:

• Cevap geliyor: Sunucu ayakta ve ağ üzerinden ulaşılabilir.
• Cevap gelmiyor: Sunucu kapalı olabilir, ama bu kesin değildir. Pek çok sunucu ve güvenlik duvarı ICMP'yi bilerek engeller. Ping'in cevap vermemesi tek başına "sunucu kapalı" anlamına gelmez.
• Paket kaybı var (25% packet loss): Yol üzerinde bir yerde sorun vardır. Bu da bizi bir sonraki araca götürür.

3. Yol nerede kopuyor? (traceroute)

traceroute ornek.com          # Linux / macOS
tracert ornek.com             # Windows

traceroute, paketin hedefe giderken geçtiği her yönlendiriciyi (hop) ve her birine ulaşma süresini listeler. Bir noktadan sonra yalnızca * * * görüyorsanız, paketler o noktadan ileri gidemiyor demektir.

Ancak dikkatli yorumlayın. Ara yönlendiricilerin pek çoğu traceroute paketlerine düşük öncelik verir ya da hiç cevap vermez. Ortadaki bir hop'ta * * * görüp sonraki hop'lar normal cevap veriyorsa ortada sorun yoktur. Sorun, son hop'a kadar devam eden kayıp ya da gecikmedir.

4. Sürekli ölçüm: mtr

mtr, ping ile traceroute'u birleştirir ve yolu sürekli ölçer. Aralıklı yaşanan sorunlar için en iyi araçtır:

mtr -rwc 100 ornek.com

Bu komut her hop'a 100 paket gönderir ve bir rapor çıkarır. Rapor şöyle okunur:

HOST                         Loss%   Snt   Last   Avg  Best  Wrst
 1. 192.168.1.1               0.0%   100    0.6   0.7   0.5   2.1
 2. 10.20.0.1                 0.0%   100    6.2   7.0   5.8  14.3
 3. ???                      100.0   100    0.0   0.0   0.0   0.0
 4. ae1.ist.ornek-isp.net     0.0%   100    9.1   9.4   8.7  12.0
 ...
 9. 203.0.113.10             12.0%   100   48.3  52.1  45.0 160.4

Bu örnekte 3. hop'un %100 kayıp göstermesi önemsizdir, çünkü sonraki hop'lar sorunsuz. Ama son hop'taki %12 kayıp gerçek bir sorundur. Kaybın hangi hop'ta başladığına bakın: Sizin modeminizde mi, internet sağlayıcınızda mı, yoksa sunucunun bulunduğu veri merkezinde mi?

Hosting firmanıza destek talebi açacaksanız bu raporu ekleyin. "Site yavaş" demekten çok daha hızlı sonuç alırsınız.

5. Port açık mı?

Sunucuya ulaşılıyor ama site açılmıyorsa, web sunucusunun dinlediği porta bağlanılıp bağlanılamadığına bakın:

nc -vz ornek.com 443

succeeded yazıyorsa port açık. Connection refused ise sunucuya ulaşılıyor ama o portta çalışan bir servis yok demektir (web sunucusu durmuş olabilir). Zaman aşımına uğruyorsa, aradaki bir güvenlik duvarı bağlantıyı sessizce düşürüyordur.

6. Uygulama ne diyor?

Son katman HTTP'nin kendisidir:

curl -sI https://ornek.com

HTTP/2 200 sitenin çalıştığını gösterir. 500, 502, 503 gibi kodlar ağın sorunsuz olduğunu ama uygulamanın hata verdiğini söyler. Bu durumda bakılacak yer artık web sunucusu ve uygulama günlükleridir.

Özet

DNS → ping → traceroute/mtr → port → HTTP. Bu sırayı izlediğinizde "site açılmıyor" şikâyeti birkaç dakika içinde "DNS kaydı eski IP'yi gösteriyor" ya da "PHP-FPM durmuş, 502 veriyor" gibi net bir teşhise dönüşür. Net bir teşhis de sorunun yarısının çözülmesi demektir.