ERR_CONNECTION_TIMED_OUT Hatası Nedir, Nasıl Çözülür?

Tarayıcı yirmi-otuz saniye boyunca boş bir sayfada dönüp sonunda ERR_CONNECTION_TIMED_OUT diyorsa, bu bekleme süresinin kendisi en önemli ipucudur. Bağlantı zaman aşımı hatası, gönderdiğiniz paketlere hiçbir cevap dönmediği anlamına gelir. Sunucu "burada kimse yok" bile dememiştir; paketiniz gitmiş ve sessizliğe karışmıştır. Tarayıcı da tanımlı süre dolana kadar bekleyip pes etmiştir.

Türkçe kaynakların neredeyse tamamı bu noktada modem yeniden başlatmayı, ipconfig /flushdns çalıştırmayı ve DNS sunucusu değiştirmeyi öneriyor; birçoğu da sonunda "sitenizin sahibiyseniz hosting sağlayıcınızla iletişime geçin" diyerek konuyu bırakıyor. Oysa teşhis öğretilebilir ve mantığı çok nettir: paket nerede kayboluyor? Bu yazıda önce güvenlik duvarındaki DROP ile REJECT arasındaki farkın neden "zaman aşımı" ile "reddedildi" farkını doğurduğunu anlatacağım, sonra DNS'ten güvenlik duvarına kadar katman katman ilerleyen bir teşhis zinciri kuracağım ve sunucu ayakta olduğu hâlde zaman aşımı üreten daha sinsi sebepleri (yük, conntrack tablosu, MTU, fail2ban) tek tek ele alacağım.

ERR_CONNECTION_TIMED_OUT Ne Anlama Geliyor#

ERR_CONNECTION_TIMED_OUT, TCP el sıkışmasının ilk paketine (SYN) belirlenen süre içinde hiçbir yanıt gelmediği anlamına gelir. Tarayıcı hedef IP'nin 443 portuna SYN gönderir, cevap bekler, gelmeyince belirli aralıklarla tekrar dener ve toplam süre dolduğunda hatayı basar. İşte o "bekleme" hissi bu yeniden denemelerden gelir.

Cevapsızlığın yalnızca üç açıklaması vardır:

1. Paket hedefe hiç ulaşmıyordur. Yol üzerindeki bir noktada (ISS, bulut sağlayıcı güvenlik grubu, ara yönlendirici) düşürülüyordur.
2. Paket ulaşıyor ama sunucu sessizce yutuyordur. Güvenlik duvarında DROP kuralı vardır ya da fail2ban IP'nizi engellemiştir.
3. Sunucu ulaşılamaz durumdadır. Kapalıdır, ağı kopmuştur ya da yükten dolayı yeni bağlantıları kabul edemez hâle gelmiştir.

Bu hatanın kardeşi olan ERR_CONNECTION_REFUSED hatası ise tam tersini söyler: orada cevap gelmiştir, ama cevap "bu portta kimse yok"tur. İki hatayı ayırt etmek, teşhisin yarısını hâlleder — çünkü ikisi tamamen farklı yerlere bakmanızı gerektirir.

DROP ve REJECT Farkı: İki Hatanın Kökeni#

Aynı güvenlik duvarı kuralı, tek bir kelime değiştirdiğinizde ziyaretçiye bambaşka bir hata gösterir. Fark, engellenen pakete ne yapıldığındadır:

• REJECT: Paket engellenir ve karşı tarafa "bu bağlantı kabul edilmiyor" cevabı gönderilir (TCP RST veya ICMP unreachable). Tarayıcı cevabı anında alır ve ERR_CONNECTION_REFUSED der.
• DROP: Paket sessizce çöpe atılır, hiçbir cevap üretilmez. Karşı taraf cevabın kaybolduğunu sanır, yeniden dener, sonunda pes eder ve ERR_CONNECTION_TIMED_OUT der.

Aşağıdaki tablo bu farkın pratikte nasıl göründüğünü özetliyor:

Sistem yöneticileri internete açık sunucularda genellikle DROP tercih eder, çünkü REJECT bir port tarayıcısına "burada bir makine var" bilgisini verir. Yani zaman aşımı hatası çoğu zaman bir arıza değil, kasıtlı bir güvenlik davranışının yan etkisidir — ve sizin IP'niz yanlışlıkla o kuralın kapsamına girmiştir.

Hangisiyle karşı karşıya olduğunuzu tek komutla doğrulayabilirsiniz:

nmap -Pn -p 80,443 alanadiniz.com

Çıktıda filtered görüyorsanız paketleriniz düşürülüyor (DROP), closed görüyorsanız RST alıyorsunuz (REJECT ya da kapalı servis). Bu tek kelime, hangi bölümden devam edeceğinizi belirler.

Teşhis Sırası: Katman Katman İlerlemek#

Zaman aşımı teşhisinde doğru yöntem, aşağıdan yukarı değil dışarıdan içeri ilerlemektir. Her adım bir sonrakinin ön koşuludur; sırayı bozarsanız yanlış yerde kaybolursunuz.

1. İsim çözümleniyor mu — alan adı doğru IP'yi veriyor mu?
2. Makineye ulaşılıyor mu — ICMP veya TCP seviyesinde bir yanıt var mı?
3. Yolun neresinde kayboluyor — traceroute/mtr hangi atlamada duruyor?
4. Port seviyesinde ne oluyor — 443 açık mı, filtreleniyor mu?
5. Sunucu içinde ne var — güvenlik duvarı, fail2ban, yük, conntrack.

Bunlardan ilk dördü sunucuya hiç girmeden, kendi bilgisayarınızdan yapılır. Beşinciyi yapmak için sunucuya SSH ile bağlanmanız gerekir — ki SSH de zaman aşımı veriyorsa bu zaten çok değerli bir bilgidir: sorun tek bir serviste değil, ağ katmanındadır.

Adım 1: DNS Doğru IP'yi mi Veriyor#

Zaman aşımı hatalarının azımsanmayacak bir kısmı, tarayıcının artık var olmayan bir IP adresine bağlanmaya çalışmasından kaynaklanır. Önce alan adının nereye gittiğini görün:

dig +short alanadiniz.com
dig +short www.alanadiniz.com

Dönen adresi sunucunuzun gerçek IP'siyle karşılaştırın. Uyuşmuyorsa sorun ağda değil DNS'tedir ve doğru yer dns kayıtları hangi panelden değiştirilir sorusudur. Site yakın zamanda taşındıysa yayılma penceresinde olabilirsiniz; süreyi propagasyon süresi dns yazısı açıklıyor.

Hiçbir IP dönmüyorsa sorun tamamen farklıdır ve tarayıcı zaten farklı bir hata verirdi; isim çözümleme hatalarının teşhisi için dig nslookup dns sorgulama yazısına bakın.

Kendi bilgisayarınızda eski bir kayıt takılı kalmış olabilir; önbelleği temizleyip tekrar deneyin:

ipconfig /flushdns

sudo resolvectl flush-caches

Ayrıntı: dns önbellek temizleme.

Adım 2: Sunucu Ayakta mı — ping, traceroute, mtr#

IP doğruysa sıradaki soru makineye ulaşılıp ulaşılmadığıdır, ama burada kritik bir uyarı var: ping'in cevapsız kalması sunucunun kapalı olduğu anlamına gelmez. Birçok sunucu ve bulut sağlayıcısı ICMP trafiğini kasıtlı olarak engeller. Bu yüzden ping'i tek başına delil saymayın.

ping -c 5 203.0.113.10

Cevap geliyorsa makine ayakta ve ağ yolu açık demektir; sorun port seviyesindedir, dördüncü adıma atlayın. Cevap gelmiyorsa yolu izleyin:

mtr -rwzbc 50 alanadiniz.com
traceroute -T -p 443 alanadiniz.com

traceroute -T -p 443 özellikle değerlidir: ICMP yerine TCP kullanır, dolayısıyla ICMP'yi kapatmış sunucularda da anlamlı sonuç verir. Çıktıyı okurken şunlara dikkat edin:

• Son atlamalarda %100 kayıp, öncekilerde temiz yol: Paket hedefe ulaşıyor ama cevap dönmüyor. Şüpheli, hedefin kendisi (güvenlik duvarı veya kapalı makine).
• Ortada bir noktadan sonra hiçbir şey görünmüyor: Ara yönlendiricilerden biri ICMP yanıtlarını kısıtlıyor olabilir; bu tek başına arıza değildir. Yine de aynı noktada tekrarlıyorsa yol üzerinde bir sorun vardır.
• Belirli atlamalarda kayıp ama sonrasında temiz: Bu normaldir. Ara yönlendiriciler ICMP yanıtlarını düşük öncelikli işler; asıl önemli olan son satırdaki kayıp oranıdır.

Bu araçların çıktısını doğru okumak başlı başına bir beceridir; ağ tanılama ping traceroute mtr yazısı bu okumayı ayrıntılı anlatıyor.

Farklı bir ağdan da test edin. Aynı adres mobil veriden açılıyor, ofisten açılmıyorsa sorun sizin ağınızda ya da sizin genel IP'nizin sunucuda engellenmiş olmasındadır.

Adım 3: Port Seviyesinde Test#

Makine ping'e cevap veriyor ama site açılmıyorsa, sorun tam olarak port seviyesindedir ve bunu ölçmek saniyeler alır:

nc -zvw3 alanadiniz.com 443
nc -zvw3 alanadiniz.com 80
curl -v --connect-timeout 10 https://alanadiniz.com

curl -v çıktısı size tam olarak nerede takıldığınızı gösterir:

*   Trying 203.0.113.10:443...
* connect to 203.0.113.10 port 443 failed: Connection timed out

Bu satır, TCP bağlantısının hiç kurulamadığını söyler. Buna karşılık şu çıktı çok farklı bir anlam taşır:

*   Trying 203.0.113.10:443...
* Connected to alanadiniz.com (203.0.113.10) port 443
* TLS handshake, Client hello (1):

ve sonra takılıyorsa, TCP kurulmuş ama TLS el sıkışması tamamlanamamıştır. Bu artık ağ değil, sertifika/şifreleme sorunudur ve teşhis yolu ssl hataları çözümü yazısındadır. Bu ayrımı yapmadan güvenlik duvarı kurallarını kurcalamak, olmayan bir sorunu aramak demektir.

80 açık ama 443 zaman aşımı veriyorsa (ya da tersi), tek bir portun engellendiğini bilirsiniz; bu, güvenlik duvarı kuralına doğrudan işaret eden çok güçlü bir sinyaldir. Port tarama yöntemlerinin tamamı açık port taraması nmap yazısında.

Adım 4: Güvenlik Duvarı Kurallarını Okumak#

Sunucuya bir şekilde erişebiliyorsanız (SSH açıksa ya da sağlayıcının konsolundan giriyorsanız), bu adım sorunun en sık çözüldüğü yerdir. Üç ayrı katmanı ayrı ayrı kontrol etmeniz gerekir; biri temiz diye diğerini atlamayın.

1. İşletim sistemi güvenlik duvarı.

ufw status numbered
iptables -L INPUT -n -v --line-numbers

Aradığınız satır şuna benzer:

8   9421  565260  DROP  tcp  --  *  *  0.0.0.0/0  0.0.0.0/0  tcp dpt:443

pkts sütunundaki sayı (buradaki 9421) artıyorsa kural şu anda aktif olarak trafik kesiyordur. Bunu doğrulamak için komutu 10 saniye arayla iki kez çalıştırıp sayıyı karşılaştırın. Kuralı numarasıyla kaldırın:

iptables -D INPUT 8
ufw delete 8

Ayrıca varsayılan politikayı da kontrol edin. Chain INPUT (policy DROP) yazıyorsa, açıkça izin verilmemiş her şey düşürülür; bu durumda eksik olan bir DROP kuralı değil, eksik bir ALLOW kuralıdır:

ufw allow 80/tcp
ufw allow 443/tcp
ufw reload

Kural mantığının tamamı için ufw güvenlik duvarı ve iptables temelleri yazıları elinizin altında olsun.

2. Bulut sağlayıcı güvenlik grubu. Bu katman işletim sisteminin dışındadır ve iptables -L çıktısında hiç görünmez. Sunucu içinde her şey doğru göründüğü hâlde dışarıdan erişilemiyorsa, ilk bakılacak yer burasıdır. Yeni açılan sunucularda varsayılan kural setinin yalnızca SSH'a izin verdiği, 80/443'ün elle açılması gerektiği çok yaygındır.

3. fail2ban ve benzeri otomatik engelleyiciler. Sunucuya art arda başarısız giriş denemesi yapıldıysa (WordPress giriş denemeleri, FTP, SSH) IP'niz otomatik olarak engellenmiş olabilir. Klasik belirti şudur: site herkeste açılıyor, sadece sizde zaman aşımı veriyor — çünkü fail2ban varsayılan olarak DROP kullanır.

fail2ban-client status
fail2ban-client status sshd
fail2ban-client set sshd unbanip 203.0.113.10
iptables -L f2b-sshd -n

Kendi IP'nizi kalıcı olarak beyaz listeye almak, bu tuzağa tekrar düşmemenin en pratik yoludur.

Sunucu Ayakta Ama Yine de Zaman Aşımı#

Güvenlik duvarı temizse ve servis çalışıyorsa geriye daha sinsi bir grup sebep kalır; bunlar Türkçe kaynaklarda neredeyse hiç geçmez ama sahada sıkça görülür.

Sunucu aşırı yük altında. Yük çok yükseldiğinde yeni bağlantılar kuyrukta bekler ve tarayıcı el sıkışmayı tamamlayamadan pes eder. Belirtisi, hatanın kesintili olmasıdır: bazı istekler açılır, bazıları zaman aşımı verir.

uptime
top -bn1 | head -15
dmesg -T | tail -20

uptime çıktısındaki yük ortalaması çekirdek sayınızın çok üstündeyse teşhis budur. dmesg çıktısında Out of memory: Killed process satırı görüyorsanız, çekirdek bellek yetersizliğinden servisleri öldürüyor demektir. Süreç ve yük okumanın ayrıntısı süreç izleme ps top htop yazısında.

Bağlantı takip tablosu (conntrack) dolmuş. Yoğun trafik veya bir saldırı sırasında çekirdeğin bağlantı tablosu dolar ve yeni bağlantılar sessizce düşürülür — tam olarak zaman aşımı üreten bir davranış.

sysctl net.netfilter.nf_conntrack_count net.netfilter.nf_conntrack_max
dmesg | grep -i conntrack

nf_conntrack: table full, dropping packet satırını görüyorsanız kesin teşhistir. Kalıcı çözüm için çekirdek parametrelerini ayarlamak gerekir; sysctl ile kernel optimizasyonu yazısı doğru değerleri anlatıyor.

Dinleme kuyruğu (backlog) taşmış. SYN paketleri geliyor ama servis kabul edecek kapasitede değilse kuyruk taşar:

ss -ltn
netstat -s | grep -i -E 'listen|SYNs to LISTEN'

SYNs to LISTEN sockets dropped sayacı artıyorsa, sunucu gelen bağlantıları kabul edemiyordur.

MTU / parça sorunu. Nadir ama teşhisi zor bir durumdur: küçük paketler geçer, büyük paketler düşer. Belirtisi çok tipiktir — ping çalışır, TCP bağlantısı kurulur, ama sayfa yüklenirken takılır. Test:

ping -M do -s 1472 -c 3 alanadiniz.com
ping -M do -s 1400 -c 3 alanadiniz.com

Birincisi başarısız, ikincisi başarılıysa yol üzerinde MTU sorunu vardır. Tünel (VPN, WireGuard) arkasındaki sunucularda sık görülür.

DDoS veya taşkın trafik. Sunucunun bant genişliği ya da paket işleme kapasitesi doluysa meşru istekler de düşer. Erişim kayıtlarında olağandışı yoğunluk görüyorsanız, filtrelemeyi sunucuya ulaşmadan yapmak gerekir; başlangıç için botnet nedir ve captcha bot koruması yazıları konuyu açıyor.

Paketlerin gerçekten gelip gelmediğini kesin olarak görmek isterseniz, sunucuda dinleyin ve aynı anda dışarıdan bağlanmayı deneyin:

tcpdump -ni any 'tcp port 443 and host SIZIN_IP_ADRESINIZ'

• Hiçbir paket görünmüyorsa: Trafik sunucuya hiç ulaşmıyor. Şüpheli, bulut güvenlik grubu veya yol üzerindeki bir filtre.
• SYN geliyor ama SYN-ACK dönmüyorsa: Paket geliyor ama sunucu içinde düşürülüyor. Şüpheli, işletim sistemi güvenlik duvarı veya fail2ban.
• SYN-ACK dönüyor ama bağlantı ilerlemiyorsa: Dönüş yolunda sorun var; asimetrik yönlendirme veya MTU.

Bu üç satır, saatlerce sürebilecek bir teşhisi üç dakikaya indirir.

Ziyaretçi Tarafında Zaman Aşımı#

Site başka herkeste açılıyor ve yalnızca sizde zaman aşımı veriyorsa, sorun büyük olasılıkla sizin ağınızdadır ya da IP'niz sunucu tarafında engellenmiştir. Sırayla şunları deneyin:

1. Mobil veriye geçin. Site orada açılıyorsa sorun ev/ofis ağınızdadır ya da genel IP'niz engellenmiştir. İkincisini doğrulamak için sunucudaki fail2ban ve güvenlik duvarı kayıtlarına bakılması gerekir.
2. VPN'i açıp kapatarak sınayın. VPN açıkken çalışıp kapalıyken çalışmıyorsa, IP'niz engellenmiş demektir — bu, tanının kendisidir.
3. Yerel güvenlik duvarınızı kontrol edin. Kurumsal ağlarda 80/443 dışındaki portlar (SSH 22, panel 2083 gibi) sıklıkla kapalıdır.
4. Modem/yönlendirici yeniden başlatın. Uzun süre açık kalan cihazlarda NAT tablosu dolabilir; bu, klasik tavsiyenin gerçekten işe yaradığı tek durumdur.
5. DNS önbelleğini temizleyin ve farklı bir çözümleyici deneyin. Eski IP'ye gidiyorsanız zaman aşımı almanız normaldir.

Bu adımların hiçbiri işe yaramıyor ve site herkeste kapalıysa, sorun kesinlikle sunucu tarafındadır; yukarıdaki dört adıma dönün.

Sıkça Sorulan Sorular#

Zaman aşımı ile bağlantı reddedildi arasındaki fark nedir#

Temel fark, sunucudan cevap gelip gelmemesidir. Bağlantı reddedildi hatasında sunucu size açıkça bir RST paketi göndermiştir, yani makine ayaktadır ve sorun sadece o porttadır; hata anında gelir. Zaman aşımında ise hiçbir cevap dönmemiştir, tarayıcı belirli bir süre bekleyip pes etmiştir. Bu ayrım güvenlik duvarındaki REJECT ve DROP eylemlerinden doğar ve hangi komutları çalıştıracağınızı doğrudan belirler.

Ping çalışıyor ama site açılmıyor, bu ne demek#

Bu, ağ yolunun açık ama sorunun port seviyesinde olduğu anlamına gelir. ICMP paketleriniz hedefe ulaşıp geri dönebiliyorsa makine ayaktadır ve yönlendirme doğrudur; ancak 80 veya 443 portuna gelen TCP paketleri ya güvenlik duvarında düşürülüyordur ya da web sunucusu servisi çalışmıyordur. nc -zvw3 alanadiniz.com 443 komutuyla portu doğrudan test edin. Sonuç zaman aşımıysa güvenlik duvarına, anında reddedildiyse servis durumuna bakmalısınız.

Ping cevap vermiyorsa sunucum kapalı mıdır#

Hayır, bu sonuç tek başına yeterli kanıt değildir. Birçok sunucu ve bulut sağlayıcısı ICMP trafiğini güvenlik gerekçesiyle engeller, dolayısıyla ping'e cevap vermeyen bir makine gayet sağlıklı çalışıyor olabilir. Daha güvenilir test traceroute -T -p 443 alanadiniz.com gibi TCP tabanlı bir yoklamadır. Sunucunun gerçekten ayakta olup olmadığını kesin öğrenmenin yolu ise sağlayıcının panelindeki konsol erişimidir.

Site herkeste açılıyor ama bende zaman aşımı veriyor#

Bu tabloda en olası açıklama, IP adresinizin sunucu tarafında engellenmiş olmasıdır. fail2ban ve benzeri araçlar başarısız giriş denemelerinden sonra IP'yi DROP kuralıyla engeller ve DROP tam olarak zaman aşımı üretir. Hızlı doğrulama için mobil veriye geçin ya da VPN açın; site orada açılıyorsa teşhis kesinleşir. Sunucuya erişiminiz varsa fail2ban-client status çıktısındaki yasaklı IP listesine bakın ve kendi adresinizi beyaz listeye alın.

Sunucuda site açılıyor ama dışarıdan zaman aşımı alıyorum#

Bu durumda servis çalışıyor demektir ve sorun kesinlikle bir filtreleme katmanındadır. Sunucu içinden curl -I http://127.0.0.1 çalışıp dışarıdan çalışmıyorsa üç katmanı sırayla kontrol edin: işletim sistemi güvenlik duvarı, bulut sağlayıcının güvenlik grubu ve varsa ek güvenlik yazılımları. Bulut güvenlik grupları sunucu içindeki komutlarda hiç görünmediği için en sık atlanan katmandır. tcpdump ile 443 portunu dinleyip dışarıdan bağlanmayı denemek, paketin sunucuya ulaşıp ulaşmadığını kesin olarak gösterir.

Zaman aşımı süresi neden bu kadar uzun#

Bekleme süresi, TCP'nin cevapsız kalan SYN paketlerini artan aralıklarla yeniden denemesinden kaynaklanır. İlk denemeden sonra birkaç saniye, sonra daha uzun aralıklarla tekrar denenir ve toplam süre işletim sisteminin ayarına göre yirmi saniyeden yetmiş beş saniyeye kadar çıkabilir. Bu süre bir arıza değil, ağdaki geçici paket kayıplarına karşı tasarlanmış bir toleranstır. Testlerinizde beklememek için curl --connect-timeout 10 gibi kısa bir sınır kullanabilirsiniz.

Cloudflare arkasındaki sitede zaman aşımı görürsem ne yapmalıyım#

Cloudflare gibi bir ara katman kullanıyorsanız, ziyaretçi doğrudan sunucunuza değil o katmana bağlanır. Bu durumda kaynak sunucunuz yanıt vermediğinde ziyaretçi tarayıcı hatası değil, ara katmanın ürettiği bir hata sayfası görür; ayrıntı için cloudflare 520 521 522 hataları yazısına bakın. Buna rağmen ERR_CONNECTION_TIMED_OUT alıyorsanız, tarayıcınız muhtemelen ara katmana değil doğrudan sunucu IP'sine gidiyordur. Yerel hosts dosyanızda unutulmuş bir satır olup olmadığını kontrol edin.

Kapanış#

ERR_CONNECTION_TIMED_OUT hatası, "sunucuma ulaşamıyorum" cümlesinin teknik karşılığıdır ve teşhisi tahminle değil, katman katman ilerleyerek yapılır. Sıra bellidir: alan adı doğru IP'yi mi veriyor, makineye TCP seviyesinde ulaşılıyor mu, yolun neresinde kayboluyor, port filtreleniyor mu, ve sunucu içinde hangi katman paketi düşürüyor. Anahtar kavram DROP ile REJECT farkıdır; sessizce düşürülen bir paket zaman aşımı, açıkça geri çevrilen bir paket ise reddedildi hatası üretir. nmap çıktısındaki filtered veya closed kelimesi bu ayrımı size tek bakışta verir. Güvenlik duvarı temizse yükü, conntrack tablosunu ve MTU'yu kontrol edin — bunlar sunucu ayakta göründüğü hâlde bağlantı kurdurmayan sinsi sebeplerdir.

Bu kontrolleri her seferinde elle yapmak yerine yapılandırmanızı kod hâline getirip tekrarlanabilir kılmak isterseniz ansible ile sunucu otomasyonu yazısı iyi bir başlangıç noktasıdır. Güvenlik duvarı kurallarını, izlemeyi ve servis sağlığını kendiniz yönetmek istiyorsanız kaynakları size ayrılmış bir VDS sunucu tam kontrol verir; bu yükü devretmek isterseniz sunucu yönetimi hizmeti kural düzenini ve izlemeyi üstlenir. Zaman aşımlarının kaynağı taşkın trafik ya da saldırıysa, filtrelemeyi sunucuya ulaşmadan yapan bir DDoS koruma katmanı doğru yatırımdır. Sunucu yönetmekle uğraşmak istemiyorsanız, ağ ve servis sağlığının sağlayıcı tarafında tutulduğu bir paylaşımlı hosting paketi çoğu proje için fazlasıyla yeterlidir.