ERR_CONNECTION_CLOSED: ne anlama gelir ve nasıl düzeltilir

ERR_CONNECTION_CLOSED ne anlama gelir

Chromium, CONNECTION_CLOSED (-100) hatasını "A connection was closed (corresponding to a TCP FIN)" (bir bağlantı kapatıldı, bir TCP FIN paketine karşılık gelir) olarak tanımlar. FIN, bir TCP bağlantısını düzenli biçimde bitirmenin yoludur: gönderen tarafın gönderecek başka verisi kalmadığını bildirir. Ani yol ise sıfırlamadır (reset) ve Chrome bunu ERR_CONNECTION_RESET olarak bildirir. ERR_CONNECTION_CLOSED durumunda bağlantı nazikçe sonlandırılmıştır, ama Chrome'un hâlâ TLS el sıkışmasını ya da yanıtı beklediği bir anda.

Chrome bu kodu erken kapanan her bağlantı için kullanmaz. Kaynak kodu, hiç bayt göndermeden kapanan düz bir HTTP/1.x bağlantısını iki şekilde ele alır. Bağlantı yeniyse Chrome ERR_EMPTY_RESPONSE bildirir. Bağlantı daha önceki bir istekten yeniden kullanılıyorsa Chrome ERR_CONNECTION_CLOSED'ı korur ve koddaki bir yorum nedenini söyler: sunucunun, isteği almadan önce soketi kapatmış olması "çok daha olasıdır" (much more likely). Chrome bu durumda isteği başka bir bağlantıdan yeniden gönderir; bu yüzden ziyaretçi yalnızca bu durumdan dolayı nadiren hata görür.

Pratikte hata sayfası çoğunlukla HTTPS'te görünür. Karşı taraf TLS el sıkışması sürerken bağlantıyı kapatırsa Chrome genellikle ERR_CONNECTION_CLOSED bildirir. Aynı kod, bir HTTP/2 bağlantısı karşı tarafça kapatıldığında da kullanılır ve o bağlantıda bekleyen tüm istekler başarısız olur. RFC 9113, bir uç noktanın HTTP/2 bağlantısını kapatmadan önce bir GOAWAY çerçevesi göndermesi gerektiğini (SHOULD) söyler; böylece karşı taraf hangi isteklerin işlendiğini bilir. GOAWAY göndermeden kapatan bir sunucu ya da yük dengeleyici, tarayıcıyı bu hatayla baş başa bırakır.

Hata nasıl görünür

Chrome, "This site can't be reached" başlığı altında "example.com unexpectedly closed the connection" metnini ve ERR_CONNECTION_CLOSED kodunu gösterir. Bağlantıyı, proxy'yi ve güvenlik duvarını kontrol etmenizi ve Windows Ağ Tanılama'yı çalıştırmanızı önerir. Firefox, TLS el sıkışması sırasında oluşan bir kapanmayı genellikle PR_END_OF_FILE_ERROR koduyla "Secure Connection Failed" olarak bildirir. Komut satırı daha fazla ayrıntı verir:

curl -sS http://example.com/
curl: (52) Empty reply from server

curl -sS https://example.com/
curl: (35) TLS connect error: error:0A000126:SSL routines::unexpected eof while reading

İlk durum, yeni bir bağlantıdaki düz bir HTTP isteğidir ve Chrome bunu ERR_EMPTY_RESPONSE olarak gösterir. İkincisi TLS el sıkışması sırasındaki bir kapanmadır; ifade TLS kütüphanesine göre değişir, bu örnek OpenSSL 3'ten gelir. openssl s_client aynı olayı "SSL handshake has read 0 bytes" ile birlikte "unexpected eof while reading" olarak gösterir:

openssl s_client -connect example.com:443 -servername example.com </dev/null

Yeniden kullanılan ve sunucu tarafından kapatılan bir bağlantı, iki URL tek bir bağlantıyı paylaştığında curl -v çıktısında görünür. curl ölü bağlantıyı fark edip yeniden dener; Chrome da aynısını yapar:

* Connection died, retrying a fresh connect (retry count: 1)

ERR_CONNECTION_CLOSED 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. Parantezli sayılar Chromium'un iç hata kodlarıdır.

Hata	Ağ veya protokol düzeyinde ne oldu	İlk bakılacak yer
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 sunucunun ayakta olup olmadığı.
ERR_SSL_PROTOCOL_ERROR (-107)	Karşı taraf yanıt verdi ama verisi geçerli TLS değildi; örneğin bir TLS portunda düz HTTP.	Portun gerçekte konuştuğu protokol ve sunucunun TLS ayarları.
ERR_CONNECTION_CLOSED (-100)	Karşı taraf bir FIN gönderdi. Chrome tam bir yanıt alamadı; çoğunlukla TLS el sıkışması sırasında ya da bir HTTP/2 bağlantısında.	Sitenin önündeki uç katman: varsayılan sunucu blokları, yük dengeleyici, proxy, güvenlik duvarı, güvenlik yazılımı.
ERR_CONNECTION_RESET (-101)	Bağlantı açıktı, sonra bir RST onu el sıkışma 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)	Yeni bir HTTP/1.x bağlantısı açıldı, istek gitti ve sunucu hiç veri göndermeden bağlantıyı kapattı.	Çöken worker'lar ve bilerek kapatılan bağlantılar (nginx'in return 444 kuralı).
ERR_CONNECTION_ABORTED (-103)	Yerel ağ yığını, gönderdiği veri hiç onaylanmadığı için vazgeçti.	Hattaki paket kaybı, kararsız bir Wi-Fi bağlantısı veya aktarımın ortasında trafiği düşüren bir güvenlik duvarı.

ERR_CONNECTION_CLOSED'a ne sebep olur

• Hepsini yakalayan bir sunucu bağlantıyı kapatıyor. İstek, ana bilgisayar adını tanımayan bir sunucu bloğuna ulaştı (örneğin server_name içindeki bir yazım hatası yüzünden ya da DNS hâlâ eski bir sunucuyu gösterdiği için) ve bu blok bağlantıyı kapatacak şekilde ayarlı.
• Bir güvenlik duvarı, proxy veya filtre bağlantıyı sonlandırıyor. Güvenlik cihazları, okul ve şirket ağları, ebeveyn denetimleri ve bazı ulusal filtreler bağlantıyı sıfırlamak yerine kapatabilir; tek bir sitede başarısız olan TLS denetimi de aynısını yapar.
• Boşta bekleyen bir bağlantı yanlış anda kapatılıyor. Bir sunucu ya da yük dengeleyici, tarayıcı tam o bağlantıdan istek gönderirken boşta kalan keep-alive bağlantısını kapatır. RFC 9112 buna izin verir: bir istemci, sunucu veya proxy bir bağlantıyı istediği zaman kapatabilir.
• Bir sunucu süreci duruyor. Bir çökme, bellek yetersizliği nedeniyle sonlandırma (OOM kill), yeniden başlatılan bir worker ya da dağıtım sırasındaki yeniden başlatma, sürecin soketlerini kapatır.
• Bir HTTP/2 bağlantısı GOAWAY olmadan bitiyor. Boşta kalma sınırları ve bağlantı başına istek sınırları, çok sayıda istek taşıyan bağlantıları kapatır.
• Sunucunun TLS uç noktası pes ediyor. ClientHello'da başarısız olan bir TLS kütüphanesi ya da aşırı yüklü veya yeniden başlayan bir TLS sonlandırıcısı, el sıkışmayı düz bir kapatmayla bitirebilir.
• Ziyaretçinin bilgisayarındaki bir yazılım araya giriyor. Antivirüsün HTTPS taraması, bir VPN, bir proxy ayarı ya da alan adını yanlış sunucuya yönlendiren eski bir hosts dosyası girdisi.

Sunucu tarafı nedenler ve yapılandırma

Uçtan içeri doğru ilerleyin: önce CDN veya yük dengeleyici, sonra web sunucusu, sonra uygulama. Her bir adımda, tarayıcıdan gelen bağlantının orada bitip bitmediğini öğrenin.

FIN'i kimin gönderdiğine bakın

Sunucuda, hatayı yeniden üretirken yalnızca FIN veya RST bayrağı taşıyan paketleri yakalayın:

sudo tcpdump -ni any 'tcp port 443 and (tcp[tcpflags] & (tcp-fin|tcp-rst) != 0)'

Flags [F.] içeren bir satır FIN, Flags [R] veya [R.] ise bir sıfırlamadır. İlk FIN, istemcinin ilk paketlerinin hemen ardından sunucu adresinden geliyorsa, bağlantıyı sunucu ya da önündeki uç katman kapatıyordur. İstemciden bu makineye hiç paket ulaşmıyorsa, bağlantı buraya gelmeden önce kapatılıyordur.

Hepsini yakalayan sunucu blokları ve yanlış IP adresleri

Birçok nginx kurulumunda, bilinmeyen ana bilgisayar adlarını reddeden bir varsayılan sunucu bulunur. nginx belgeleri, standart olmayan 444 kodunun "bir yanıt başlığı göndermeden bağlantıyı kapattığını" söyler:

server {
    listen 443 ssl default_server;
    ssl_certificate     /etc/ssl/default/fullchain.pem;
    ssl_certificate_key /etc/ssl/default/privkey.pem;
    return 444;   # bağlantıyı kapat, hiçbir şey gönderme
}

Bu blok kendi başına doğrudur. Gerçek siteniz başka hiçbir bloğa uymuyorsa sorun olur: server_name içinde bir yazım hatası, eksik bir www adı veya DNS'in yanlış makineyi gösterdiği bir alan adı. Ziyaretçiler o zaman kapatılmış bir bağlantı alır; bu ERR_CONNECTION_CLOSED ya da ERR_EMPTY_RESPONSE olarak görünebilir. Sunucunun hangi adlara yanıt verdiğini listeleyin ve DNS başka bir şey söylese bile tek bir sunucuyu doğrudan test edin:

sudo nginx -T | grep -n server_name
dig +short example.com
curl -vk --resolve example.com:443:203.0.113.10 https://example.com/

--resolve seçeneği curl'ün verdiğiniz adrese bağlanmasını sağlar, ama doğru ana bilgisayar adını göndermeye devam eder. Bir adres çalışıp diğeri bağlantıyı kapatıyorsa, ikincisi siteyi sunmayan bir sunucuya çıkıyor demektir. Bir web sitesini kimin barındırdığı rehberi, bir adresin hangi sağlayıcıya ait olduğunu nasıl bulacağınızı gösterir.

Keep-alive ve boşta kalma zaman aşımları

Öndeki bir proxy, boşta kalan bir arka uç bağlantısını arka uçtan önce bırakmalıdır. Arka uç önce kapatırsa, proxy bir sonraki isteğini zaten kapanmış bir bağlantıdan gönderebilir. Aynısı bir yük dengeleyici ile hedefleri arasında da geçerlidir. AWS, Application Load Balancer için varsayılan boşta kalma zaman aşımının 60 saniye olduğunu belgeler ve uygulamanın boşta kalma zaman aşımının daha uzun olmasını önerir; aksi halde ziyaretçi bir 502 Bad Gateway alabilir. Node.js varsayılan olarak boşta kalan bağlantıları 5 saniye sonra kapatır, bu değerin çok altında:

const http = require('node:http');
const server = http.createServer(app);
server.keepAliveTimeout = 65 * 1000;   // yük dengeleyicinin 60 sn boşta kalma zaman aşımından uzun
server.listen(3000);

nginx boşta kalan istemci bağlantılarını varsayılan olarak 75 saniye tutar (keepalive_timeout 75s;). Bir arka uç yanıt göndermeden bağlantıyı kapattığında nginx şunu günlüğe yazar: upstream prematurely closed connection while reading response header from upstream. ERR_CONNECTION_RESET rehberi bu sorunun proxy tarafını daha ayrıntılı ele alır.

Çökmeler ve yeniden başlatmalar

sudo journalctl -k --since "1 hour ago" | grep -i -E "out of memory|killed process"
sudo journalctl -u myapp --since "1 hour ago" --no-pager

Bir worker'ın ölümünü veya yeniden başlamasını, başarısız isteklerin zaman damgalarıyla eşleştirin. Bir çökme iki hatadan birini üretebilir: süreç soketleri kapanırken okunmamış verisi olup olmadığına göre istemci bir FIN ya da bir RST görür.

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

• Her konumdan, el sıkışma sırasında kapatılıyor: sunucu veya uç katman bilinmeyen ya da bozuk TLS bağlantılarını kapatıyordur. Varsayılan sunucuyu, istenen ad için sertifikayı ve DNS kayıtlarını kontrol edin.
• Yalnızca bazı konumlardan kapatılıyor: DNS'in döndürdüğü birkaç IP adresinden biri siteyi barındırmıyor, o bölgedeki bir CDN düğümü sağlıksız ya da o ağdaki bir filtre bağlantıyı kapatıyor.
• Düz HTTP çalışıyor, HTTPS kapanıyor: sorun sertifika, sunucu adının işlenişi veya sunucunun önündeki bir sonlandırıcı gibi TLS katmanındadır. SSL handshake failed rehberi el sıkışmanın kendisini ele alır.
• Ara sıra, rastgele kapanıyor: boşta kalma zaman aşımları, yeniden başlatılan worker'lar veya bir yük dengeleyicinin arkasındaki tek bir sağlıksız sunucu.
• Her kontrol noktasından sorunsuz, yalnızca sizde kapanıyor: neden sizin ağınızda veya cihazınızdadır; antivirüs, VPN, proxy, hosts dosyası veya internet sağlayıcınız gibi.

HTTP denetleyicisi, bir sunucunun HTTP durumunu, yanıt süresini ve erişilebilirliğini dünyanın dört bir yanındaki konumlardan kontrol eder; böylece sitenin geneline yayılan bir kapanma ile tek bir ağa bağlı olanı ayırt edebilirsiniz.

ERR_CONNECTION_CLOSED nasıl düzeltilir

Ziyaretçiyseniz

1. Sayfayı bir iki kez yeniden yükleyin. Sunucunun az önce kapattığı bir bağlantı, bir sonraki denemede yenisiyle değiştirilir.
2. Başka bir ağ deneyin; örneğin Wi-Fi yerine mobil veri. Site açılıyorsa neden ağınızda veya cihazınızdadır.
3. VPN'i ve varsa proxy'yi kapatın. Windows'ta Ayarlar > Ağ ve İnternet bölümündeki proxy sayfasını açın. macOS'ta proxy ayarlarını görmek için scutil --proxy komutunu çalıştırın.
4. Antivirüsünüzde HTTPS taramasını duraklatın (çoğunlukla web koruması veya SSL/TLS taraması denir) ve yeniden deneyin. Bu işe yararsa, taramayı kapalı bırakmak yerine site için bir istisna ekleyin.
5. Chrome'un bağlantılarını sıfırlayın. chrome://net-internals/#sockets sayfasını açın ve "Close idle sockets" ile "Flush socket pools" düğmelerine tıklayın. Aynı sayfanın "DNS" sekmesinde "Clear host cache" düğmesine tıklayın.
6. Windows'ta ağ yığınını yenileyin. Aşağıdakileri yönetici olarak açılmış bir Komut İstemi'nde çalıştırın, sonra yeniden başlatın:

   ipconfig /flushdns
   netsh winsock reset
   netsh int ip reset

7. hosts dosyasını kontrol edin; alan adını başka bir sunucuya yönlendiren eski bir girdi olabilir: Windows'ta C:\Windows\System32\drivers\etc\hosts, macOS ve Linux'ta /etc/hosts.
8. Eklentileri devre dışı bırakın veya gizli pencere kullanın. Hata kayboluyorsa eklentileri tek tek yeniden açın.

Siteyi siz işletiyorsanız

1. Hatayı ağınızın dışından yeniden üretin: curl -v https://example.com/ ve openssl s_client ile. El sıkışma sırasındaki bir kapanma TLS uç noktasını, istekten sonraki bir kapanma web sunucusunu veya uygulamayı işaret eder.
2. DNS'in hangi adresi döndürdüğüne bakın ve her adresi --resolve ile test edin.
3. FIN'i tcpdump ile yakalayın ve hangi adımın gönderdiğini görün.
4. Her adımın günlüklerini okuyun: yük dengeleyici veya CDN, web sunucusunun hata günlüğü, uygulama günlüğü ve hata sayfası döndürmek yerine bağlantıları kapatan WAF veya IPS kuralları. Hata anında upstream hatalarına, çökmelere ve yeniden başlatmalara bakın.
5. Sunduğunuz adlar için sunucu bloklarını, sertifikaları ve varsayılan sunucuları kontrol edin. Güvenle yeniden yüklemek için: sudo nginx -t && sudo systemctl reload nginx.
6. Boşta kalma zaman aşımlarını hizalayın: arka ucun keep-alive zaman aşımı, önündeki proxy'nin veya yük dengeleyicinin zaman aşımından uzun olmalıdır.

Kapanan bağlantıları erken yakalamak

Kapanan bağlantılar çoğunlukla tek bir bölgeyi ya da birkaç sunucudan yalnızca birini etkiler ve kendi ağınızdan yapılan hızlı bir kontrol ikisini de kaçırabilir. HostTracker web sitelerini 2004'ten beri izliyor ve 158 şehirdeki 300'den fazla kontrol noktasından kontrol ediyor. E-posta, SMS, sesli arama, Slack, Telegram ve daha fazlasıyla uyarı gönderir; böylece "yalnızca iki bölgeden kapanıyor" gibi bir örüntü, ziyaretçi şikayetlerinde değil kontrol sonuçlarında ortaya çıkar.

Sık sorulan sorular

ERR_CONNECTION_CLOSED ile ERR_CONNECTION_RESET arasındaki fark nedir?

Closed, karşı tarafın bir TCP bağlantısının düzenli sonu olan FIN gönderdiği anlamına gelir. Reset ise karşı tarafın bağlantıyı hemen sonlandıran ve yoldaki verileri çöpe atan bir RST gönderdiği anlamına gelir. İkinci durumu reset rehberi ele alır.

ERR_CONNECTION_CLOSED benim hatam mı, web sitesinin mi?

Mesajdan anlaşılmaz. Siteyi başka bir ağdan açın ya da birden fazla konumdan bir kontrol çalıştırın. Orada açılıyorsa sorun cihazınızda veya ağınızdadır. Her yerde başarısız oluyorsa bağlantıları site ya da uç katmanı kapatıyordur.

Neden yalnızca HTTPS sitelerinde oluyor?

TLS el sıkışması, Chrome'un kapanmış bir bağlantıyla karşılaştığı yaygın bir yerdir; çünkü bir güvenlik duvarının, varsayılan sunucunun ya da TLS sonlandırıcının alışverişi bitirmeye karar verebileceği ilk adım budur. Yeni bir bağlantıdaki düz HTTP ise bunun yerine ERR_EMPTY_RESPONSE olarak bildirilir.

Yeniden yükleme neden bazen işe yarıyor?

Bir sunucu, tam Chrome onu yeniden kullanırken boşta kalmış bir keep-alive bağlantısını kapattığında, bir sonraki deneme yeni bir bağlantı kullanır. Chrome bu isteklerin çoğunu kendiliğinden yeniden dener; hata sayfası yalnızca yeniden deneme de başarısız olduğunda görünür.

Bir VPN veya antivirüs ERR_CONNECTION_CLOSED'a neden olabilir mi?

Evet. İkisi de tarayıcı ile site arasında durur. Bir VPN ağ geçidi ya da şirket proxy'si reddetmek üzere ayarlandığı bağlantıları kapatabilir; antivirüsün HTTPS taraması da bir bağlantıyı denetleyemediğinde sonlandırabilir.

Tarayıcı önbelleğini temizlemek işe yarar mı?

Genellikle hayır, çünkü HTTP önbelleği işin içinde değildir. Devrede olan bağlantı havuzları ve DNS önbelleğidir. chrome://net-internals içindeki "Flush socket pools" ve "Clear host cache" düğmelerini kullanın.

localhost'ta neden ERR_CONNECTION_CLOSED alıyorum?

Geliştirme sunucusu büyük olasılıkla isteği işlerken çöktü veya yeniden başladı. Çalıştığı terminalde bir istisna ya da çıkış mesajı olup olmadığına bakın.

Kaynaklar ve ek okumalar

• Chromium net error list: CONNECTION_CLOSED (-100) ve yukarıdaki tablodaki diğer kodların tanımları.
• RFC 9112, HTTP/1.1: hatalar ve zaman aşımları hakkında bölüm 9.5, bağlantıyı kapatma hakkında bölüm 9.6.
• RFC 9113, HTTP/2: GOAWAY çerçevesi hakkında bölüm 6.8, bağlantı yönetimi hakkında bölüm 9.1.
• nginx rewrite module: return yönergesi ve özel 444 kodu.