SSL handshake timed out ne demek?

“SSL handshake timed out”, tarayıcı veya istemcinin HTTPS bağlantısı kurulurken sunucuyla TLS el sıkışmasını belirlenen süre içinde tamamlayamadığı anlamına gelir. Bu hata genellikle sertifikanın geçersiz olduğunu değil, istemci ile sunucunun TLS görüşmesine zamanında yanıt veremediğini gösterir. Sorun; sunucuya erişimi engelleyen güvenlik duvarı, yanlış port, ters proxy, aşırı yük veya TLS yapılandırması nedeniyle oluşabilir.

TLS handshake aşamasında ne olur?​

Yaygın TCP tabanlı TLS akışında istemci önce sunucunun HTTPS portuna bağlanır ve desteklediği TLS sürümleri ile şifreleme seçeneklerini bildirir. Sunucu uygun seçenekleri seçer, sertifikasını gönderir ve bağlantının devamı için gerekli yanıtları verir. Olağan akışta bunun ardından HTTP isteği gönderilir. İstemcinin süre sınırına DNS ve TCP kurulumunu da dahil edip etmediğini kayıtlarından ayırın.

Zaman aşımı, bu aşamalardan birinin hiç yanıt vermemesi veya yanıtın zamanında ulaşmaması demektir. Bu nedenle hata, “HTTP uygulaması hata verdi” anlamından farklıdır; istek çoğu zaman web sunucusuna veya uygulamaya ulaşmadan kesilir.

Somut örnek: yalnızca HTTPS bağlantısının beklemesi​

Örneğin example.com için HTTP bağlantısı yanıt verirken HTTPS bağlantısı bekliyorsa şu olasılıklar öne çıkar:

• 80 numaralı port açık, 443 numaralı port ise güvenlik duvarında engellenmiş olabilir.
• 443 portu açık olsa da arkasındaki Nginx, Apache, yük dengeleyici veya CDN TLS yanıtı üretmiyor olabilir.
• DNS kaydı, istemciyi çalışmayan ya da yanlış yapılandırılmış bir IP adresine yönlendiriyor olabilir.
• Sunucu kaynakları tükendiği için yeni TLS bağlantıları kabul edilemiyor olabilir.
• Bir proxy veya güvenlik cihazı TLS görüşmesini kesip yanıtı geciktiriyor olabilir.

Sertifika alan adıyla uyuşmuyor veya süresi geçmişse çoğu istemci genellikle zaman aşımı değil, sertifika doğrulama hatası gösterir. Ancak ara cihazların davranışı nedeniyle yalnız hata metnine bakarak tek bir neden seçilmemelidir.

Teşhis ve uygulanabilir kontrol sırası​

Önce problemin istemciye mi, sunucuya mı, yoksa aradaki ağa mı ait olduğunu ayırın. Kontrolleri şu sırayla yapın:

1. Aynı adresi farklı bir ağdan ve mümkünse farklı bir istemciden deneyin. Her yerde aynı sonuç alınıyorsa sunucu, DNS veya barındırma katmanını; yalnızca tek ağda görülüyorsa yerel proxy, güvenlik duvarı veya ağ yönlendirmesini inceleyin.
2. Alan adının doğru sunucuya çözümlendiğini kontrol edin. Yakın zamanda DNS veya hosting değiştiyse eski ve yeni hedeflerin karışmadığından emin olun.
3. Sunucudan veya yetkili bir teşhis makinesinden curl -Iv --connect-timeout 10 --max-time 20 https://example.com/ komutunu çalıştırın. Çıktı TLS görüşmesinin hangi aşamada beklediğini gösterir. Verbose çıktıda beklenen aşamayı belirleyin. Curl bağlantı süresi DNS ve TCP/TLS ya da QUIC kurulumunu kapsar; toplam süre ise aktarımı da sınırlar. Sırf zaman aşımı koduna bakarak HTTP’ye hiç ulaşılmadığını varsaymayın.
4. Sunucuda 443 portunun ilgili servis tarafından dinlendiğini ve güvenlik duvarı ile barındırma sağlayıcısının bu porta erişimi engellemediğini kontrol edin. Port açık görünse bile TLS sonlandıran gerçek servisin çalıştığını doğrulayın.
5. Ters proxy, CDN veya yük dengeleyici kullanıyorsanız TLS’nin nerede sonlandırıldığını belirleyin. İstemci ile proxy arasındaki ve proxy ile origin sunucu arasındaki iki bağlantıyı ayrı ayrı test edin.
6. Web sunucusu, proxy ve sistem günlüklerini aynı zaman aralığında inceleyin. Bağlantı hiç görünmüyorsa trafik sunucuya ulaşmıyor olabilir; bağlantı görünüyor fakat TLS tamamlanmıyorsa sertifika zinciri, TLS politikası, kaynak yetersizliği veya ara cihaz ayarlarını inceleyin.
7. Kaynak kullanımı yüksekse çalışan süreçleri, bağlantı limitlerini ve bellek durumunu kontrol edin. Sorun geçici yükten kaynaklanıyorsa hizmeti yeniden başlatmak yalnızca geçici belirtiyi giderir; kalıcı çözüm limitleri ve yük nedenini düzeltmektir.

Sertifika bilgisinin görünmesi el sıkışmasının tamamlandığını tek başına kanıtlamaz. TLS başarı kaydı ve ardından gerçek HTTP yanıtını ayırın; TCP connected satırı yalnız taşıma bağlantısını gösterebilir. Bağlantı “connected” aşamasına gelmeden bekliyorsa port, firewall, proxy veya servis erişilebilirliği önceliklidir.

Belirtiye göre önceliklendirme​

Aynı hata farklı katmanlardan gelebileceği için aşağıdaki ayrım, gereksiz ayar değişikliğini önler.

Sık yapılan hatalar​

• Sertifikayı hemen yenilemek: Sorun yanıt vermeyen 443 portuysa yeni sertifika yüklemek zaman aşımını çözmez.
• Yalnız tarayıcıyı temizlemek: Hata farklı ağlarda ve araçlarda da tekrarlanıyorsa tarayıcı önbelleği ana neden değildir.
• Zaman aşımını sürekli artırmak: Bu, yanıt vermeyen servisi düzeltmez ve istemcilerin daha uzun süre beklemesine yol açar.
• Yalnız origin sunucuyu incelemek: TLS proxy veya CDN üzerinde sonlanıyorsa hata önce o katmanda oluşabilir.
• TLS sürümünü rastgele düşürmek: Eski ve güvensiz protokolleri etkinleştirmek yerine istemci, proxy ve sunucunun ortak desteklediği güvenli yapılandırma belirlenmelidir.

Sorunun kaynağı belirlendikten sonra yalnız ilgili katmanı düzeltin: engelli portu açın, TLS servisini doğru sertifika ve anahtarla çalıştırın, proxy-origin bağlantısını düzeltin veya kaynak tüketimini giderin. Değişiklikten sonra hem doğrudan TLS testiyle hem de gerçek alan adı üzerinden yeniden kontrol yapın.

Sık sorulan sorular​

curl -I ile 405 görmek TLS başarısızlığı mıdır?​

Hayır. -I HTTP HEAD ister; uygulama bu yöntemi desteklemiyorsa 405 dönebilir. Gerçek HTTPS uç noktasından HTTP yanıtı alındıysa isteğin o katmanda işlendiğini gösterir. HEAD reddini el sıkışması zaman aşımı diye yorumlamayın; gerekli yöntemi ayrı deneyin.

Alan adı yerine IP ile denemek neden farklı sonuç verir?​

TLS sunucu adı ve sertifika adı eşleşmesi etkilenebilir; aynı IP birden fazla site barındırabilir. Origin’i incelerken alan adını ve SNI’yi koruyan yetkili bir yöntem kullanın. Curl’ün --resolve veya --connect-to seçenekleri belirli hedefi sınamak için değerlendirilebilir; sertifika doğrulamasını kapatmak sorunu teşhis etmez.