ERR_CONNECTION_TIMED_OUT: Neden Olur, Nasıl Düzeltilir

ERR_CONNECTION_TIMED_OUT ne anlama gelir

Bir tarayıcı bağlantı açarken bir SYN paketi gönderir ve SYN-ACK bekler. Zaman aşımı, ne SYN-ACK ne de kapalı bir portun göndereceği RST olarak hiçbir yanıtın gelmediği anlamına gelir; bu yüzden tarayıcı paketin bir şeye ulaşıp ulaşmadığını bilemez. Bu sessizlik, hedeften gelen hızlı ve kesin bir ret olan ERR_CONNECTION_REFUSED'dan farkıdır. Chromium'un hata listesi bu kodu (-118) "a connection attempt timed out" (bir bağlantı denemesi zaman aşımına uğradı) olarak tanımlar.

İstemcinin işletim sistemi tek denemeden sonra vazgeçmez. İlk SYN sıradan bir paket kaybında yitmiş olabilir diye SYN'i giderek açılan aralıklarla birkaç kez yeniden gönderir. Linux'ta net.ipv4.tcp_syn_retries varsayılan olarak 6'dır ve çekirdek belgeleri son zaman aşımını 131 saniye olarak verir. RFC 9293, TCP'nin bir SYN'i en az 3 dakika yeniden denemesini ister ama uygulamanın daha erken vazgeçmesine izin verir; bu yüzden gördüğünüz bekleme süresi işletim sistemine ve tarayıcıya birlikte bağlıdır. Her iki durumda da bir zaman aşımının görünmesi, çoğunlukla milisaniyeler içinde dönen bir retten çok daha uzun sürer.

Hata nasıl görünür

Chrome, tüm bekleme süresi dolduktan sonra "This site can't be reached" başlığını, ardından "example.com took too long to respond" (example.com yanıt vermesi çok uzun sürdü) metnini ve ERR_CONNECTION_TIMED_OUT kodunu gösterir. Firefox "The connection has timed out" gösterir. Komut satırında dakikalarca beklememek için bir bağlantı zaman aşımı belirleyin:

curl -v --connect-timeout 10 https://example.com/
* Trying 203.0.113.10:443...
* Connection timed out after 10001 milliseconds
curl: (28) Connection timed out after 10001 milliseconds

28 çıkış kodu zaman aşımı demektir; yeni curl sürümleri mesajı farklı ifade eder ama aynı kodu döndürür. --connect-timeout yalnızca bağlantı aşamasını sınırlar; böylece bir bağlantı zaman aşımını yavaş bir yanıttan ayırır. nc -zv -w 5 example.com 443 aynı şekilde "timed out" bildirir; Windows'ta PowerShell'deki Test-NetConnection example.com -Port 443 ise TcpTestSucceeded : False ile biter.

ERR_CONNECTION_TIMED_OUT ile benzer hatalar

Chrome bunların hepsini aynı "This site can't be reached" başlığı altında gösterir; bu yüzden hangisi olduğunu alttaki kod ayırt eder. Satırlar, bir sayfa yüklenirken bunlarla karşılaşma sırasını izler: DNS sorgusundan yanıtın ilk baytına kadar. Parantezli sayılar Chromium'un iç hata kodlarıdır.

Hata	Ağ veya protokol düzeyinde ne oldu	İlk bakılacak yer
ERR_NAME_NOT_RESOLVED (-105)	DNS sorgusu kullanılabilir bir IP adresi döndürmedi, bu yüzden hiç bağlantı denenmedi.	Alan adının DNS kayıtları ve cihazın kullandığı çözümleyici.
ERR_ADDRESS_UNREACHABLE (-109)	İşletim sistemi ya da bir yönlendirici, IP adresine giden bir rota olmadığını bildirdi.	İstemci tarafındaki yönlendirme: VPN rotaları, yerel ağ, IPv6 kurulumu.
ERR_CONNECTION_TIMED_OUT (-118)	SYN paketi gitti ve istemci vazgeçene kadar ne SYN-ACK ne de RST olarak hiçbir şey dönmedi.	Paketleri düşüren güvenlik duvarları ve güvenlik grupları, ana makinenin ayakta olup olmadığı ve DNS'in döndürdüğü IP adresi.
ERR_CONNECTION_REFUSED (-102)	SYN paketi ana makineye ulaştı ve çoğunlukla bir RST ile hemen reddedildi.	O port ve adreste dinleyen bir süreç olup olmadığı ve güvenlik duvarındaki REJECT kuralları.
ERR_CONNECTION_RESET (-101)	Bağlantı açıktı, sonra bir RST onu TLS el sıkışması ya da aktarım sırasında sonlandırdı.	O andaki proxy, WAF ve uygulama günlükleri; istemcinin ağındaki antivirüs, VPN veya filtreleme.
ERR_EMPTY_RESPONSE (-324)	Bağlantı açıldı ve istek gitti, ama sunucu hiç veri göndermeden bağlantıyı kapattı.	Çöken worker'lar veya bilerek kapatılan bağlantılar için sunucu ve proxy hata günlükleri (nginx'in return 444 kuralı).

ERR_CONNECTION_TIMED_OUT'a ne sebep olur

• Bir güvenlik duvarı paketleri düşürüyor. DROP kuralları, bulut güvenlik grupları ve ufw'nin deny kuralı SYN'i yanıt vermeden çöpe atar. Herkese açık olmaması gereken portlar için olağan kurulumdur ve sunucunun kendisi ayaktayken en yaygın nedendir.
• Ana makine kapalı ya da bağlantısı kesilmiş. Kapatılmış, donmuş veya bağlantısı kopmuş bir sunucu hiç yanıt veremez. Ana makinenin gittiğini bilen bir yönlendirici bunun yerine bir ICMP hatası gönderebilir; Chrome bunu ERR_ADDRESS_UNREACHABLE olarak bildirir.
• DNS yanlış adresi döndürüyor. Taşımadan sonra hâlâ eski bir sunucuyu gösteren bir kayıt, önbelleğe alınmış eski bir IP ya da bir hosts dosyası girdisi tarayıcıyı hiçbir şeyin yanıt vermediği bir adrese gönderir.
• Yolda bir yönlendirme sorunu var. Bozuk bir peering bağlantısı, yanlış yapılandırılmış bir rota ya da bir internet sağlayıcısı kesintisi, paketleri hedef ağa ulaşmadan yolda bırakır; bazen yalnızca bazı bölgeler için.
• Sunucu aşırı yüklenmiş. Dinleme kuyruğu dolduğunda Linux yeni bağlantı denemelerini reddetmek yerine düşürür; bir güvenlik duvarında ya da NAT ana makinesinde dolan bağlantı izleme tablosu da aynısını yapar.
• Ağınız portu engelliyor. Bazı iş yeri, okul ve halka açık Wi-Fi güvenlik duvarları yalnızca 80 ve 443 gibi yaygın portlara izin verir; bu yüzden :8080 veya :8443 üzerindeki bir site orada zaman aşımına uğrar, evde ise açılır.

Sunucu tarafı nedenler ve yapılandırma

Yalnızca 127.0.0.1 üzerinde dinleyen bir hizmet zaman aşımı değil, ret üretir. Dış istemciler zaman aşımına uğruyorsa paketleri porta ulaşmadan bir şey çöpe atıyordur; nerede olduğunu bulmanın en hızlı yolu, başka bir ağdan bağlanırken sunucuda bunları izlemektir:

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

Filtre gelen SYN'leri ve sunucunun SYN-ACK yanıtlarını gösterir. Hiç SYN gelmiyorsa düşürme sunucudan önce gerçekleşiyordur: bir bulut güvenlik duvarı, bir ağ güvenlik duvarı, yönlendirme veya başka bir yeri gösteren DNS. SYN geliyor ama SYN-ACK çıkmıyorsa ana makinedeki bir güvenlik duvarı ya da dolu bir kuyruk bunları çöpe atıyordur. SYN'lere SYN-ACK ile yanıt veriliyorsa sunucu yanıt veriyordur; yanıtlar dönüş yolunda kaybolmuş veya istemci tarafında düşürülmüştür.

Bulut güvenlik grupları ve ağ ACL'leri

Bulut güvenlik duvarları genellikle izin vermedikleri trafiği düşürür; bu yüzden eksik bir gelen kuralı ret değil zaman aşımı üretir. Sunucuya uygulanan kuralları listeleyin:

# AWS: inbound rules of a security group
aws ec2 describe-security-groups --group-ids sg-0123456789abcdef0 --query 'SecurityGroups[].IpPermissions'

# Azure: rules of a network security group
az network nsg rule list --resource-group web-rg --nsg-name web-nsg --output table

# Google Cloud: firewall rules in the current project
gcloud compute firewall-rules list

AWS ağ ACL'leri durumsuzdur (stateless); bu yüzden gelen kuralına ek olarak geçici portlardaki (1024-65535) dönüş trafiği için bir giden kuralı da gerekir. Eksik bir dönüş kuralı da zaman aşımı gibi görünür.

Ana makine güvenlik duvarları

# Default policy and DROP rules with packet counters
sudo iptables -L INPUT -n -v --line-numbers

# ufw: "deny" drops without replying; allow the port explicitly
sudo ufw status verbose
sudo ufw allow 443/tcp

# nftables
sudo nft list ruleset | grep -n -E "drop|policy"

Chain INPUT (policy DROP) başlığı, açıkça izin verilmeyen her şeyin düşürüldüğü anlamına gelir. Her yeniden denemenizde paket sayacı artan bir DROP kuralı, bağlantılarınızı düşüren kuraldır.

DNS kayıtları

Alan adının kendi ad sunucularının yayımladığı adresi, genel çözümleyicilerin döndürdüğüyle ve sunucunun gerçek IP'siyle karşılaştırın:

dig +short NS example.com
dig +short A example.com @ns1.example-dns.net
dig +short A example.com @1.1.1.1

Yetkili yanıt doğruysa ve bir çözümleyici hâlâ eski adresi döndürüyorsa kaydın TTL süresi henüz dolmamıştır. Planlı bir taşımadan önce ayarlanan düşük bir TTL bu beklemeyi kısaltır:

example.com.      300  IN  A      203.0.113.10
www.example.com.  300  IN  CNAME  example.com.

Eskimiş bir AAAA kaydını fark etmek daha zordur: Chrome kısa bir gecikmeden sonra paralel olarak bir IPv4 denemesi başlatır; bu yüzden tarayıcılar siteyi açabilirken yalnızca IPv6 kullanan istemciler ve kontroller zaman aşımına uğrar.

Aşırı yüklenmiş Linux sunucuları

Dinleyen bir soketin accept kuyruğu dolduğunda Linux yeni SYN'leri resetlemek yerine düşürür, çünkü tcp_abort_on_overflow varsayılan olarak kapalıdır. İstemciler yavaş bağlantılar ve zaman aşımları görür. Kuyruk net.core.somaxconn ile (Linux 5.4'ten beri varsayılan 4096) ve uygulamanın istediği backlog ile sınırlıdır; listen yönergesi backlog= ayarlamıyorsa nginx 511 ister.

# Listen queues: Recv-Q is the current accept queue, Send-Q its limit
ss -ltn

# Counters of overflowed queues and dropped SYNs
nstat -az TcpExtListenOverflows TcpExtListenDrops

# Connection-tracking table full on a firewall or NAT host
sudo journalctl -k | grep -i "nf_conntrack: table full"

Backlog'u (örneğin listen 443 ssl backlog=4096;) yalnızca uygulamanın bağlantıları geç kabul etmesine yol açan sorunu düzeltmeyle birlikte artırın.

Kubernetes

İki ayar trafiği reddetmek yerine düşürür. externalTrafficPolicy: Local ile kube-proxy, Service için hazır pod'u olmayan bir düğümde dış trafiği iletmez; bu yüzden o düğümün NodePort'una yapılan bağlantılar zaman aşımına uğrar. Bulut yük dengeleyiciler bunu önlemek için düğümlerin sağlık kontrolünü yapar, ama doğrudan bir NodePort'a bağlanan istemciler yapmaz. Trafiğe izin vermeyen bir NetworkPolicy de ağ eklentisine bağlı olarak genellikle onu düşürür.

Dışarıdan nasıl görünür

• Her konumdan zaman aşımı. Ana makine kapalı, bir güvenlik duvarı veya güvenlik grubu portu herkes için düşürüyor ya da DNS her yerde ölü bir adresi gösteriyor.
• Yalnızca bazı bölgelerden zaman aşımı. O ağlarla ana makine arasındaki bir yönlendirme veya peering sorunu, belirli ülkeleri veya adres aralıklarını düşüren bir güvenlik duvarı kuralı ya da birkaç A kaydından birinin ölü bir sunucuyu göstermesi.
• Ping yanıt veriyor, port zaman aşımına uğruyor. Ana makine ayakta ve bir güvenlik duvarı o portu düşürüyor. Başarısız bir ping tek başına az şey kanıtlar, çünkü birçok ana makine ping'i engeller.
• Bir port yanıt veriyor, diğeri zaman aşımına uğruyor. Bir güvenlik duvarı kuralı yalnızca o portu kapsıyor; örneğin HTTPS açıldıktan sonra 443 için izin kuralının eksik olması.
• Her yerde kabul ediliyor, yalnızca sizde zaman aşımı. Sizin ağınız: bir giden güvenlik duvarı, internet sağlayıcısı engeli, eskimiş bir DNS veya hosts dosyası girdisi ya da bir VPN.
• Yük altında aralıklı zaman aşımları. Dolu dinleme kuyrukları veya dolu bir bağlantı izleme tablosu.

Port denetleyicisi birçok konumdan bir TCP bağlantısı açar ve her biri için bağlantının kabul edilip edilmediğini, reddedilip reddedilmediğini ya da zaman aşımına uğrayıp uğramadığını bildirir; böylece tek bir yoldaki düşürme, her yerde kapalı olan bir ana makineden ayrışır.

ERR_CONNECTION_TIMED_OUT nasıl düzeltilir

Ziyaretçiyseniz

1. Farklı bir ağ deneyin; örneğin mobil veri. Böylece yönlendiriciniz, internet sağlayıcınızın rotası veya bir iş yeri güvenlik duvarı elenir.
2. DNS önbelleğinizi temizleyin; eski, erişilemeyen bir adres tutuyor olabilir. Sisteminize uygun komutu çalıştırın (sırasıyla Windows, macOS, systemd-resolved kullanan Linux):

   ipconfig /flushdns
   sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
   resolvectl flush-caches

   Chrome'da ayrıca chrome://net-internals/#dns sayfasını açın ve "Clear host cache" düğmesine tıklayın.
3. hosts dosyanızı kontrol edin (Windows'ta C:\Windows\System32\drivers\etc\hosts, macOS ve Linux'ta /etc/hosts); alan adını ölü bir adrese sabitleyen eski bir girdi olabilir.
4. Bir VPN'i veya proxy'yi geçici olarak devre dışı bırakın. Erişilemeyen şey bir VPN'in çıkış düğümü olabilir.
5. Yönlendiricinizi yeniden başlatın; takılmış yönlendirme ya da bağlantı durumunu temizlemek için.

Siteyi siz işletiyorsanız

1. Ana makinenin ayakta olduğunu doğrulayın; sunucunun kendisindeki bir kabuktan değil, sağlayıcının konsolundan veya başka bir makineden.
2. Dışarıdan bağlanırken tcpdump ile SYN'leri izleyin; yukarıda gösterildiği gibi. Böylece paketlerin sunucuya ulaşıp ulaşmadığını öğrenirsiniz.
3. Güvenlik gruplarını, ağ ACL'lerini ve ana makine güvenlik duvarlarını eksik bir izin kuralı ya da portta bir DROP kuralı için kontrol edin.
4. DNS yanıtlarını AAAA kayıtları dahil sunucunun gerçek adresiyle karşılaştırın.
5. Yolu TCP üzerinden izleyin:

   mtr --tcp --port 443 example.com
   sudo traceroute -T -p 443 example.com

   TCP izi, ICMP veya UDP iz sondalarını engelleyen güvenlik duvarlarını aşabilir. İzlemenin durduğu yer bir ipucudur, kanıt değildir; çünkü birçok yönlendirici iz sondalarına hiç yanıt vermez.
6. Zaman aşımları yalnızca yük altında görünüyorsa kuyruk ve conntrack sayaçlarını kontrol edin.

ERR_CONNECTION_TIMED_OUT nasıl önlenir

Düşürülen bir paket sunucunun günlüklerinde hata bırakmaz, çünkü sunucudaki hiçbir şey isteği almamıştır. Ağın dışından yapılan port ve HTTP kontrolleri, erişilemeyen bir ana makineyi ya da düşürülen bir portu başladığı anda yakalar; HostTracker bunları 158 şehirdeki 300'den fazla kontrol noktasından çalıştırır ve ziyaretçiler bildirmeden önce e-posta, SMS, sesli arama, Slack, Telegram ve daha fazlasıyla uyarı gönderir. Bir port kontrolünün yanına ping izleme eklemek, sessizleşenin ana makinenin tamamı mı yoksa yalnızca port mu olduğunu hemen gösterir.

Sık sorulan sorular

Chrome ERR_CONNECTION_TIMED_OUT göstermeden önce ne kadar bekler?

Sabit bir tarayıcı zamanlayıcısına değil, çoğunlukla işletim sisteminin TCP ayarlarına bağlıdır. Linux'ta çekirdek varsayılan olarak SYN'i 6 kez yeniden gönderir ve yaklaşık iki dakika sonra vazgeçer; diğer sistemler farklı deneme sayıları kullanır. Bir iki saniye içinde çıkan bir hata neredeyse hiçbir zaman zaman aşımı değildir.

Site telefonumda açılıyor ama dizüstü bilgisayarımda neden zaman aşımına uğruyor?

Bu genellikle dizüstü bilgisayarın ağ yoluna özgü bir şeye işaret eder: bir iş yeri güvenlik duvarı, bir VPN istemcisi ya da erişilemeyen bir adresi gösteren önbelleğe alınmış bir DNS veya hosts dosyası girdisi.

Ping çalışıyor ama site neden zaman aşımına uğruyor?

Ping ICMP kullanır; site ise 80 veya 443. porta bir TCP bağlantısı gerektirir. Bir güvenlik duvarı birine izin verip diğerini düşürebilir; bu yüzden çalışan bir ping yalnızca ana makinenin ayakta olduğunu kanıtlar.

Neden yalnızca 8080 veya 8443 gibi bir portta zaman aşımı oluyor?

Bulunduğunuz ağ muhtemelen yalnızca yaygın portlara izin veriyordur. Birçok iş yeri ve halka açık ağ, 80 ve 443 dışındaki her şeye giden bağlantıları düşürür; bu yüzden aynı URL evden veya mobil veriden çalışır.

Bir DNS sorunu, DNS hatası yerine ERR_CONNECTION_TIMED_OUT'a yol açabilir mi?

Evet; DNS başarıyla çözümlüyor ama bu arada kapatılmış eski bir sunucu gibi hiçbir şeyin yanıt vermediği bir adres döndürüyorsa. Sorgu başarılı olur ve o adrese yapılan bağlantı denemesi zaman aşımına uğrar.

Bir web sitesi IP'mi zaman aşımıyla engelleyebilir mi?

Evet. Bir sunucu veya güvenlik duvarı, yasaklı adreslerden ya da bütün ülkelerden gelen trafiği düşürebilir ve düşürülen paketler sizin için ölü bir sunucudan tam olarak ayırt edilemez. Site mobil veride açılıyor ama ev bağlantınızdan açılmıyorsa site sahibine adresinizin engellenip engellenmediğini sorun.

ERR_CONNECTION_TIMED_OUT her tarayıcıda aynı mı?

Neden aynıdır ama ifade farklıdır. Microsoft Edge, Chromium üzerine kuruludur ve aynı kodu gösterir; Firefox ise "The connection has timed out" gösterir.

Zaman aşımı her zaman sunucunun kapalı olduğu anlamına mı gelir?

Hayır. Bağlantı denemesine hiçbir şeyin yanıt vermediği anlamına gelir; bu, bir güvenlik duvarının onu düşürdüğü, arada bir yerde rotanın bozuk olduğu ya da gerçek sunucu sağlamken DNS'in yanlış adresi gösterdiği anlamına da gelebilir.

Site neden bende zaman aşımına uğruyor ama aynı ağdaki bir iş arkadaşımda açılıyor?

Yalnızca sizin makinenizde bulunan, cihaz başına bir VPN istemcisine, önbelleğe alınmış bir DNS girdisine, bir hosts dosyası satırına veya bir tarayıcı proxy ayarına bakın. Paylaşılan bir ağ sorunu genellikle ağdaki herkesi etkiler; bu yüzden iki cihaz arasındaki fark, birine işaret eder.

Kaynaklar ve ek okumalar

• Chromium net error list: CONNECTION_TIMED_OUT (-118) ve yukarıdaki tablodaki diğer kodların tanımları.
• RFC 9293, Transmission Control Protocol: bağlantı hatalarını ve bir SYN'in ne kadar süre yeniden denendiğini anlatan bölüm 3.8.3.
• Linux kernel IP sysctl documentation: tcp_syn_retries, tcp_abort_on_overflow ve somaxconn.
• Kubernetes: virtual IPs and service proxies: trafik politikalarının Service trafiğini nasıl yönlendirdiği veya düşürdüğü.