Connection timed out hatası: Ağ mı yoksa sunucu mu?

Site açılmıyor ve tarayıcı birkaç saniye sonra ERR_CONNECTION_TIMED_OUT diyor. Ya da SSH bağlanıyorsunuz ve bir süre bekledikten sonra ssh: connect to host x.x.x.x port 22: Connection timed out mesajını görüyorsunuz. Bu hata "Connection refused" hatasından farklıdır ve bu fark, tüm sorun giderme yolunu belirler. refused hatasında hedef sunucu yanıt verir ve bu portun açık olmadığını söyler; yani paket hedefe ulaşmıştır. timed out hatasında ise hiçbir yanıt dönmez ve paketin nerede kaybolduğunu bilemezsiniz. Yani ilk iş, sunucu yapılandırmasını değiştirmek değil, kaybolma noktasını bulmaktır.

Doğru test sırası: alt katmandan üste doğru

Çoğu yönetici doğrudan servisi yeniden başlatmaya veya logları kontrol etmeye gider. Sorunun ağ yolunda mı yoksa makinenin kendisinde mi olduğunu henüz bilmiyorken bu, zaman kaybıdır. Aşağıdaki sırayı takip edin; her adım ancak önceki adım yanıt verdiğinde anlam kazanır.

1. Alan adı çözümlemesi (DNS) doğru yapılıyor mu?
2. Paket hedefe ulaşıyor mu? (ping ve traceroute)
3. Belirli port açık mı? (nc veya telnet)
4. Servis o portta dinliyor mu? (ss ve servis logu)
5. Güvenlik duvarı veya sanal ana makine isteği engelliyor mu?

Birinci adım: her şeyden önce DNS'i kontrol edin

Alan adı yanlış bir IP'ye çözümlenirse, sonraki tüm testler anlamsızdır. Önce hangi IP'nin döndüğüne bakın:

dig +short example.com A
dig +short example.com AAAA

Dönen IP, sunucunuzun gerçek IP'sinden farklıysa sorun ağ değildir; sorun DNS kaydıdır. A kaydı tam olarak sunucunun IP'sine işaret etmelidir ve IPv6 etkin değilse AAAA kaydını silin. Yanlış bir AAAA, tarayıcının önce IPv6'ya gitmesine, yanıt alamamasına ve timeout sonrası IPv4'e dönmesine neden olur. Kayıtları ve DNS yayılımını kontrol etmek için DNS ve ağ sorgulama aracını kullanın.

İkinci adım: ping ve traceroute neyi kanıtlar

ping yalnızca ICMP paketinin gidip döndüğünü söyler. Birçok sunucu ICMP'yi kapatmıştır ve servis tamamen sağlıklıyken ping yanıt vermez. Yani ping almamak kesin bir kanıt değildir. Ancak ping yanıt veriyorsa, ağ yolu hedefe kadar açıktır ve sorunu üst katmanlarda aramalısınız.

ping -c 4 185.10.20.30
traceroute -T -p 443 example.com
mtr -rwzc 20 example.com

traceroute'ta yıldızların başladığı yer önemlidir. Son atlama kadar yıldız görüyor ve sonrasında hiçbir şey yoksa, muhtemelen hedef güvenlik duvarı ICMP'yi drop ediyor. Yolun ortasında yıldız çıkıp sonra devam ediyorsa, o yönlendirici yalnızca ICMP'ye yanıt vermiyor ve sorun yok. mtr traceroute'tan daha iyidir çünkü zaman içinde packet loss'u gösterir; ara bir atlamada kalıcı loss genellikle yolda gerçek bir sorun olduğu anlamına gelir.

Üçüncü adım: port testi, çoğu teşhisin yanlış yapıldığı yer

İşte burada ICMP ile TCP arasındaki farkı gözetmeniz gerekir. Güvenlik duvarı ICMP'yi açık bırakıp 443 portunu kapatabilir. Tersi de mümkündür. Bu yüzden port testini ayrı yapın:

nc -vz -w 5 example.com 443
nc -vz -w 5 example.com 22
curl -v --connect-timeout 5 https://example.com

nc 443 portunda da timeout veriyor ama 22 portu açıksa, sorun neredeyse kesinlikle güvenlik duvarı veya Security Group'tur, web servisi değil. Her iki port da timeout veriyor ama ping yanıt veriyorsa, bir drop kuralınız veya üst ACL'iniz var demektir. Her iki port da refused veriyorsa, güvenlik duvarı açıktır ve servis dinlemiyor; burada sorun sunucu içindedir.

Burada hata yapıyorlar

En sık gördüğüm hata: yönetici portu sunucu güvenlik duvarında açıyor, ufw status da allow diyor, ama yine de timeout alıyor. Nedeni, üst güvenlik duvarının (bulut Security Group veya veri merkezi ACL'i) hâlâ kapalı olması ve trafiğin makineye hiç ulaşmamasıdır. İşareti, sunucuda tcpdump ile o port için hiçbir paket görmemenizdir. Paket ulaşmıyorsa, sunucu içindeki yapılandırmada yapılan her değişiklik faydasızdır.

tcpdump -ni eth0 'tcp port 443 and tcp[tcpflags] & tcp-syn != 0'

Dışarıdan istek gönderirken bu komut boş çıktı veriyorsa, trafik sunucuya ulaşmadan önce drop edilmiştir. Tersine, SYN görüyor ama SYN-ACK dönmüyorsa, sorun makine içindedir: ya servis dinlemiyor ya da yerel güvenlik duvarı drop ediyor.

Dördüncü adım: servis gerçekten portta dinliyor mu

ss -tlnp | grep -E ':80|:443'
systemctl status nginx
journalctl -u nginx --since "10 min ago"

Local Address sütununa dikkat edin. 127.0.0.1:443 yazıyorsa, servis yalnızca loopback üzerinde dinliyor ve dışarıdan erişilemez. 0.0.0.0:443 veya [::]:443 olmalıdır. Bu durumu, yeniden kurulum veya nginx.conf dosyası değişikliğinden sonra ortaya çıkan yapılandırmalarda çok görüyorum.

Belirti karşılaştırması: hangi test neyi eler

Sorun sizin tarafınızda olmadığında

Testler trafiğin sunucuya ulaştığını, servisin dinlediğini ve güvenlik duvarının açık olduğunu gösteriyor ama yine de dışarıdan timeout alıyorsanız, sorun uluslararası yolda veya hedef taraftaki filtrededir. Burada sunucu yapılandırmasını değiştirmek hiçbir işe yaramaz. Testi birkaç farklı coğrafi noktadan yapın ve sonucu altyapı sağlayıcınızın desteğine iletin; atlamayı tam belirten mtr çıktısı en çok yardımcı olur.

Maliyetle ilgili bir not: portu tüm IP'lere açık bırakmak test için en kolay yoldur ama geçici olmalıdır. 22 veya 3306 gibi yönetim portlarını sorun giderme için 0.0.0.0/0 adresine açıp kapatmayı unutursanız, kimlik doğrulama loglarında otomatik saldırılar görürsünüz. Test için kendi IP'nizi /32 maskesiyle sınırlayın.

Sunucunuz yönetilen bir Linux hosting üzerinde çalışıyorsa, bu yolun bir kısmı (üst güvenlik duvarı ve ACL) sizin kontrolünüzde değildir ve port durumunu dışarıdan doğrulaması için destekten yardım istemelisiniz. Özel sunucu üzerinde genellikle bu katmanlara daha tam erişiminiz olur ve tcpdump'ı kendiniz alabilirsiniz.

Sık sorulan sorular

Connection timed out ile Connection refused arasındaki fark nedir?

refused hatasında hedef sunucu bu portun kapalı olduğunu aktif olarak yanıtlar; yani paket hedefe ulaşmıştır ve sorun içeridedir. timed out hatasında hiçbir yanıt gelmez ve paket yolda veya güvenlik duvarında drop edilmiştir. Bu fark, servise mi yoksa ağa mı gideceğinizi belirler.

Neden ping yanıt veriyor ama site açılmıyor?

Çünkü ping ICMP protokolünü kullanır, site ise 443 portunda TCP kullanır. Güvenlik duvarı ICMP'yi açık tutup 443 portunu kapalı tutabilir. Yani başarılı ping yalnızca ağ yolunun hedefe kadar açık olduğunu söyler, web servisinin erişilebilir olduğunu değil.

Sunucu güvenlik duvarının mı yoksa üst güvenlik duvarının mı suçlu olduğunu nasıl anlarım?

Sunucuda tcpdump alın ve aynı anda dışarıdan istek gönderin. Hiçbir SYN paketi ulaşmadıysa, üst güvenlik duvarı trafiği drop etmiştir. SYN ulaştı ama SYN-ACK dönmediyse, yerel güvenlik duvarı veya servis sorunludur.

AAAA kaydı timeout'a neden olabilir mi?

Evet. AAAA kaydı varsa ama sunucu IPv6 üzerinde dinlemiyorsa, tarayıcı önce IPv6'ya gider, yanıt alamaz ve timeout sonrası IPv4'e döner. IPv6 kurmadıysanız AAAA kaydını silin.

Sonraki adım belli: önce dig, sonra mtr, sonra port üzerinde nc. Bu üçü yanıt vermeden sunucu yapılandırmasına dokunmayın.