ERR_CONNECTION_RESET: Nedenleri ve Çözümleri

ERR_CONNECTION_RESET ne anlama gelir

El sıkışma sırasında ortaya çıkan ERR_CONNECTION_REFUSED'dan farklı olarak reset, TCP el sıkışması başarılı olduktan sonra gelir: TLS el sıkışması sırasında, istek gönderilirken ya da yanıtın yarısında. Yoldaki bir şey ya da uç noktalardan biri, bağlantıyı anında bitiren bir RST segmenti gönderir. Chromium'un hata listesi bu kodu (-101) "a connection was reset (corresponding to a TCP RST)" (bir bağlantı sıfırlandı, bir TCP RST'ye karşılık gelir) olarak tanımlar. Sunucu, bir yük dengeleyici, bir güvenlik duvarı ve kendi bilgisayarınızdaki yazılımların hepsi bir tane gönderebilir ve tarayıcı, kim gönderirse göndersin aynı RST'yi görür.

Normal bir TCP kapatma, her yönde bir FIN alışverişidir; iki tarafın da kuyruğa aldığı veriyi göndermeyi bitirmesine izin verir. RST bunu atlar ve havadaki her şeyi çöpe atar; bir indirmenin ya da uzun bir API yanıtının ortasındaki reset, kesik bir sonuç bırakmasının nedeni budur. RFC 9293, TCP'nin kendisinin ne zaman reset gönderdiğini anlatır. Burada iki kural en çok önem taşır: artık var olmayan bir bağlantıya ulaşan segment reset alır ve alınan veri hâlâ okunmamışken bir bağlantıyı kapatan ana makine "SHOULD send a RST to show that data was lost" (verinin kaybolduğunu göstermek için bir RST göndermelidir). İkinci kural yaygın bir yükleme hatasını açıklar: bir yüklemeyi reddeden ve gövdenin tamamını okumadan soketi kapatan sunucu istemciyi resetler; istemci de sunucunun hata sayfasını hiç görmez.

Hata nasıl görünür

Chrome, "This site can't be reached" başlığı altında "The connection was reset" (bağlantı sıfırlandı) metnini ve ERR_CONNECTION_RESET kodunu gösterir; bazen sayfanın bir kısmı çoktan çizilmişken. Firefox "The connection was reset" gösterir. curl bunu 56 çıkış koduyla bildirir:

curl -sS -o /dev/null http://example.com/export.csv
curl: (56) Recv failure: Connection reset by peer

HTTPS üzerinde tam ifade curl ve TLS kütüphanesi sürümlerine göre değişir, ama çıkış kodu resetin ne zaman geldiğini söyler. 35 kodu resetin TLS el sıkışması sırasında olduğu anlamına gelir; bu da ağ filtrelerini veya TLS denetimini düşündürür. 56 kodu ise resetin sonrasında veri alınırken olduğu anlamına gelir; bu da çökmeleri, boyut sınırlarını ve zaman aşımlarını düşündürür. Bir isteğin başlamasından sonra hep aynı bayt sayısında ya da hep aynı saniyede gelen bir reset, rastgele bir ağ aksaklığına değil, yoldaki sabit bir sınıra işaret eder.

ERR_CONNECTION_RESET 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_RESET'e ne sebep olur

• Bir güvenlik duvarı, IPS veya WAF bağlantıyı ortasında bitiriyor. İçeriğe ya da istek hızına bakan kurallar el sıkışmadan sonra devreye girer; bazıları bir hata sayfası döndürmek yerine bağlantıyı resetle sonlandıracak şekilde ayarlıdır.
• Sunucu adına göre ağ filtrelemesi. Site adını TLS el sıkışmasından okuyan filtreler (bazı şirket, okul ve ulusal filtreler dahil) bir reset enjekte ederek siteleri engeller. Bazı internet sağlayıcıları ve mobil operatörler de trafik yönetiminin parçası olarak bağlantıları resetler.
• Antivirüs yazılımı ya da şirket proxy'si tarafından yapılan TLS denetimi. Belirli bir sitede veya büyük bir yanıtta başarısız olan HTTPS taraması, açık bir mesajla hata vermek yerine çoğunlukla bağlantıyı resetler.
• Bir sunucu süreci istek sırasında ölüyor. Bir uygulama çökmesi, bellek yetersizliği nedeniyle sonlandırma ya da dağıtım sırasında bir worker'ın yeniden başlaması, sürecin tuttuğu soketleri kapatır. İstemci bir reset görür ya da hiçbir şey gönderilmemişse ve kapanış temizse ERR_EMPTY_RESPONSE görür.
• Sunucunun kabul ettiğinden büyük bir yükleme. Sunucu bir hatayla yanıt verir ve tarayıcı gövdeyi hâlâ gönderirken bağlantıyı kapatır; okunmamış veri bir reseti tetikler.
• Yük dengeleyicilerde ve NAT cihazlarında boşta kalma zaman aşımları. Cihazın zaman aşımından uzun süre boşta kalan bir bağlantı unutulur ve üzerindeki bir sonraki paket reset alır. WebSocket'ler, sunucu tarafından gönderilen olaylar (server-sent events) ve long polling bundan en çok etkilenenlerdir.
• VPN'lerde, tünellerde ve PPPoE bağlantılarında yol MTU sorunları. Yol MTU keşfinin dayandığı ICMP mesajları engellendiğinde tam boyutlu paketler kaybolur, küçükler geçer. El sıkışma başarılı olur, aktarım takılır ve hangi taraf önce vazgeçerse tarayıcı bir reset ya da zaman aşımı gösterir.

Sunucu tarafı nedenler ve yapılandırma

Reset tarayıcıya ulaştığında, tarayıcının kendi bağlantısını tutan ya da yolunda duran bir şeyden gelmiştir: web sunucusu, önündeki yük dengeleyici veya CDN uç katmanı, bir ağ cihazı ya da ziyaretçinin makinesindeki yazılım. Bir ters proxy'yi resetleyen bir arka uç genellikle ziyaretçi için bir 502 Bad Gateway'e dönüşür; bu yüzden sunucu tarafındaki arama uç katmandan başlar ve içeri doğru ilerler.

Çöken veya öldürülen worker'lar

# Kernel out-of-memory kills in the last hour
sudo journalctl -k --since "1 hour ago" | grep -i -E "out of memory|killed process"

# Restarts and crashes of a systemd service
sudo journalctl -u myapp --since "1 hour ago" --no-pager

PHP-FPM çöken alt süreçleri kendi günlüğüne yazar, örneğin WARNING: [pool www] child 2817 exited on signal 11 (SIGSEGV) after 12.481935 seconds from start. Zaman damgalarını resetin gerçekleştiği anla eşleştirin.

Yükleme boyutu sınırları

nginx, client_max_body_size değerinden (varsayılan 1 MB) büyük istek gövdelerini 413 hatasıyla reddeder ve belgeleri tarayıcıların bu hatayı doğru gösteremediği konusunda uyarır; ziyaretçiler çoğu zaman bunun yerine bir reset alır. Sınırı yüklemelerin yapıldığı yerde artırın:

# nginx: http, server, or location context
client_max_body_size 50m;

# Apache: limit in bytes (52428800 = 50 MiB)
LimitRequestBody 52428800

Bir proxy ile arka ucu arasındaki keep-alive zaman aşımları

Bir ters proxy, arka uca açık boşta bağlantıları yeniden kullanmak için tutar. Arka uç boştaki bir bağlantıyı önce kapatırsa, proxy bir sonraki isteği arka ucun az önce kapattığı bir bağlantıya gönderebilir ve karşılığında reset alabilir. nginx bu durumda recv() failed (104: Connection reset by peer) while reading response header from upstream kaydını düşer, Apache ise (104)Connection reset by peer: ... AH01102: error reading status line from remote server yazar. Ziyaretçi genellikle reset yerine aralıklı bir 502 görür. Kural şudur: arka ucun boşta kalma zaman aşımı proxy'ninkinden uzun olmalıdır:

upstream app {
    server 127.0.0.1:3000;
    keepalive 16;
    keepalive_timeout 30s;   # shorter than the backend's idle timeout
}

server {
    listen 80;
    location / {
        proxy_pass http://app;
        proxy_http_version 1.1;          # needed before nginx 1.29.7
        proxy_set_header Connection "";  # needed before nginx 1.29.7
    }
}

Node.js varsayılan olarak boştaki keep-alive bağlantılarını 5 saniye sonra kapatır; bu, nginx upstream keepalive_timeout değerinin 60 saniyelik varsayılanından çok daha kısadır. Bu yüzden değeri proxy'nin kullandığının üstüne çıkarın:

const http = require('node:http');
const server = http.createServer((req, res) => res.end('ok'));
server.keepAliveTimeout = 65000; // default is 5000 ms
server.listen(3000);

Yük dengeleyiciler ve uzun ömürlü bağlantılar

Katman 4 yük dengeleyiciler ve NAT ağ geçitleri her bağlantıyı izler ve boştakileri unutur. AWS, Network Load Balancer'ın varsayılan olarak 350 saniye veri gelmeyen bir TCP bağlantısını izlemeyi bıraktığını ve bundan sonra iki taraftan biri veri gönderirse istemcinin bir TCP RST aldığını belgelemektedir. Uzun ömürlü bağlantıları, yoldaki en kısa boşta kalma zaman aşımından daha sık gönderilen WebSocket ping çerçeveleri veya uygulama kalp atışlarıyla meşgul tutun. Düz TCP keepalive, ancak zamanlayıcısını düşürürseniz işe yarar; çünkü Linux ilk yoklamayı göndermeden önce varsayılan olarak 2 saat bekler (net.ipv4.tcp_keepalive_time).

Bilerek yapılan resetler ve Docker

nginx'in reset_timedout_connection on; ayarı, nginx'in zaman aşımına uğrayan bağlantıları ve standart olmayan 444 koduyla kapatılan bağlantıları normal biçimde kapatmak yerine resetlemesini sağlar. Kapalıyken return 444; genellikle ERR_EMPTY_RESPONSE olarak görünür. Bir Docker ana makinesinde, yayımlanmış bir porta ana makinenin kendisinden yapılan curl: (56) Recv failure: Connection reset by peer çıktısı genellikle, konteynerdeki uygulamanın 127.0.0.1 üzerinde ya da -p eşlemesinin söylediğinden başka bir portta dinlediği anlamına gelir; bu eşlemeyi ERR_CONNECTION_REFUSED rehberi ele alır.

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

• Her konumdan aynı noktada reset. O URL'de sunucudaki ya da uç katmandaki bir boyut sınırı, bir zaman aşımı veya bir çökme. Tam isteği yeniden üretin ve o ana ait günlükleri okuyun.
• Yalnızca bir ülkeden veya ağdan reset. O ağdaki filtreleme ya da o bölgeye hizmet veren bozuk bir uç düğüm.
• Rastgele konumlardan aralıklı resetler. Çöken worker'lar, yük dengeleyicinin arkasındaki tek bir sağlıksız sunucu veya boşta kalma zaman aşımı yarışları.
• Yalnızca TLS el sıkışması sırasında reset. O yoldaki TLS denetimi veya ada göre filtreleme ya da TLS sonlandırıcının kendisi. Aynı ana makineye düz HTTP çoğu zaman çalışır.
• Her kontrol noktasından sorunsuz, yalnızca sizde reset. Antivirüs, bir VPN, bir proxy veya internet sağlayıcınız.

HTTP denetleyicisi isteği aynı anda birçok konumdan gönderir ve her birinden sonucu gösterir; böylece sitenin geneline yayılan bir reset ile tek bir ağa bağlı olanı ayırt edebilirsiniz.

ERR_CONNECTION_RESET nasıl düzeltilir

Ziyaretçiyseniz

1. Başka bir ağ deneyin; örneğin Wi-Fi yerine mobil veri. Site orada açılıyorsa neden cihazınızda veya ağınızdadır.
2. Antivirüsünüzdeki HTTPS taramasını kapatın (genellikle "web koruması" ya da "SSL/TLS taraması" altında listelenir) ve yeniden deneyin. Bu işe yararsa, taramayı kapalı bırakmak yerine siteyi bir istisna listesine ekleyin.
3. Varsa VPN'i veya proxy'yi devre dışı bırakın ve yeniden yükleyin. Reset duruyorsa VPN ya da proxy bağlantıyı araya girerek kesiyor veya yanlış işliyordur.
4. Yönlendiricinizi veya modeminizi yeniden başlatın; eskimiş bağlantı durumunu temizlemek için.
5. Windows'ta Winsock'u sıfırlayın. Yönetici olarak açılmış bir Komut İstemi'nde netsh winsock reset komutunu çalıştırın ve yeniden başlatın. Kaldırılmış güvenlik veya VPN yazılımlarından kalan ağ kancalarını silebilir.
6. Chrome'un açık bağlantılarını kapatın. chrome://net-internals/#sockets sayfasını açın, "Flush socket pools" düğmesine tıklayın ve yeniden yükleyin.
7. VPN veya mobil hotspot kullanıyorsanız yol MTU'sunu test edin. Sisteminize uygun komutu çalıştırın (sırasıyla Windows, Linux, macOS):

   ping -f -l 1472 example.com
   ping -M do -s 1472 example.com
   ping -D -s 1472 example.com

   Ping "needs to be fragmented" ya da "message too long" hatasıyla başarısız olursa veya yanıt gelmezse, geçene kadar boyutu küçültün; o boyut artı 28, yol MTU'nuzdur. VPN'in veya ağ arayüzünün MTU'sunu bu değere ayarlamak resetleri durdurabilir.

Siteyi siz işletiyorsanız

1. Yeniden üretin ve ölçün. Resetin nerede gerçekleştiğini curl -sS -o /dev/null -w '%{size_download} bytes %{time_total}s\n' https://example.com/path ile not edin. Tekrarlanabilir bir bayt sayısı veya süre bir sınıra işaret eder.
2. Uygulama ve çekirdek günlüklerini kontrol edin; o anda bir çökme, bellek yetersizliği nedeniyle sonlandırma veya yeniden başlatma olup olmadığına bakın.
3. WAF ve IPS günlüklerini inceleyin. Belirli yüklere ya da hızlara uyan bağlantıları resetleyen bir kural, güvenlik günlüğüne bakana kadar bir ağ arızasından ayırt edilemez.
4. Her adımdaki boyut sınırlarını ve zaman aşımlarını kontrol edin: client_max_body_size, yük dengeleyicinin boşta kalma zaman aşımları ve yukarıdaki keep-alive ayarları.
5. Her değişiklikten sonra güvenle yeniden yükleyin: sudo nginx -t && sudo systemctl reload nginx yapılandırmayı yürürlüğe girmeden önce doğrular.

ERR_CONNECTION_RESET nasıl önlenir

Yalnızca yük altında, yalnızca büyük yanıtlarda ya da yalnızca belirli ağlardan ortaya çıkan bir reset, hızlı bir elle kontrolde nadiren görünür. Sürekli HTTP izleme, isteği 158 şehirdeki 300'den fazla kontrol noktasından belirli aralıklarla tekrarlar; böylece aralıklı veya bölgesel bir reset örüntüsü görünür hâle gelir ve HostTracker kontroller başarısız olmaya başlar başlamaz e-posta, SMS, sesli arama, Slack, Telegram ve daha fazlasıyla uyarı gönderir.

Sık sorulan sorular

ERR_CONNECTION_RESET hacklendiğim anlamına mı gelir?

Hayır. Bu hata hemen her zaman bir ağ cihazına, bir güvenlik duvarı kuralına, antivirüs müdahalesine ya da sunucu tarafındaki bir çökmeye işaret eder; cihazınıza yönelik bir saldırıya değil.

Dosya yüklerken neden ERR_CONNECTION_RESET alıyorum?

Dosya büyük olasılıkla sunucunun kabul ettiğinden büyüktür. Sunucu gövdeyi reddeder, hepsini okumadan bağlantıyı kapatır ve tarayıcı hata sayfası yerine bir reset alır. Site sahibinin yükleme sınırını, örneğin nginx'in client_max_body_size değerini, artırması gerekir.

Bu neden yalnızca büyük dosya indirmelerinde oluyor?

Büyük aktarımlar daha uzun sürer ve daha çok veri taşır; bu yüzden bir proxy zaman aşımına, bir güvenlik duvarındaki ya da yük dengeleyicideki boyut sınırına veya içeriği denetleyen bir filtreye takılma olasılıkları daha yüksektir. Bunların her biri, küçük bir isteğin daha önce bitireceği bir bağlantıyı yarıda kesebilir.

Bir WebSocket ya da uzun istek birkaç dakika boşta kaldıktan sonra neden düşüyor?

Yoldaki bir yük dengeleyici, NAT cihazı veya proxy boştaki bağlantıyı unuttu ve bir sonraki paket reset aldı. Yoldaki en kısa boşta kalma zaman aşımından daha sık ping veya kalp atışı gönderin.

Kendi antivirüsüm buna neden olabilir mi?

Evet. TLS trafiğini araya girip yeniden şifreleyen HTTPS taraması bazen belirli sitelerde veya büyük yanıtlarda başarısız olur ve bağlantıyı geçirmek yerine resetler.

Reset, zaman aşımından daha mı kötüdür?

Kendi başına değil. Reset, bir şeyin bağlantıyı etkin biçimde bitirdiği anlamına gelir; bu da çoğunlukla zaman aşımından daha kolay teşhis edilir, çünkü zaman aşımında hiçbir şey dönmez ve paketlerin hedefe ulaşıp ulaşmadığını bile bilemezsiniz.

Reset neden her seferinde aynı noktada oluyor?

Resetten önce hep aynı bayt sayısı ya da geçen süre, rastgele bir arızadan çok bir proxy zaman aşımı, azami gövde boyutu veya boşta kalma zaman aşımı gibi sabit bir sınıra işaret eder.

Bir mobil operatör bağlantılarımı resetleyebilir mi?

Bazı operatörler, özellikle yoğun hücrelerde veya video gibi yüksek bant genişlikli aktarımlarda, ağ yönetiminin bir parçası olarak bağlantıları resetler. Aynı istek Wi-Fi üzerinden güvenilir biçimde çalışıyor ama mobil veride resetleniyorsa operatör güçlü bir adaydır.

Kaynaklar ve ek okumalar

• Chromium net error list: CONNECTION_RESET (-101) ve yukarıdaki tablodaki diğer kodların tanımları.
• RFC 9293, Transmission Control Protocol: reset üretimini anlatan bölüm 3.5.2 ve okunmamış veriyle bir bağlantıyı kapatmayı anlatan bölüm 3.6.
• nginx core module: client_max_body_size ve reset_timedout_connection.
• AWS: Network Load Balancer TCP idle timeout: boşta izleme ve süre dolduktan sonra gönderilen RST.