ERR_CONNECTION_RESET Hatası Nedir, Neden Olur?

Tarayıcıda "Bu sayfaya ulaşılamıyor — Bağlantı sıfırlandı" yazısını ve altında ERR_CONNECTION_RESET kodunu gördüğünüzde ilk düşünce genelde "sunucu kapalı" olur. Oysa bu hata, kapalı bir sunucunun verdiği hata değildir. Aksine: bağlantı kurulmuş, taraflar konuşmaya başlamış ve konuşmanın ortasında bir taraf telefonu yüzünüze kapatmıştır. TCP dünyasında bunun karşılığı RST paketidir. Bağlantı sıfırlandı hatası tam olarak "karşı taraftan bir RST geldi, ben de sayfayı çizemedim" demektir.

Bu yazının varlık sebebi şu: Türkçe kaynaklarda ERR_CONNECTION_RESET neredeyse hep genel "internet bağlantı sorunu" başlıklarının altına gömülüyor ve herkese aynı dört madde veriliyor — modemi yeniden başlat, DNS değiştir, önbelleği temizle, VPN'i kapat. Halbuki asıl soru hiç sorulmuyor: bu RST paketini kim gönderdi? Sunucudaki süreç mi çöktü, güvenlik duvarı mı REJECT --reject-with tcp-reset uyguluyor, yoksa TLS el sıkışması sürüm/şifre uyuşmazlığından mı kopuyor? Üçünün ekrandaki görüntüsü birebir aynı, çözümü ise tamamen farklıdır. Aşağıda bu üç şüpheliyi tek tek ayıracak komutları, çıktı örneklerini ve karar noktalarını bulacaksınız.

ERR_CONNECTION_RESET Ne Anlama Gelir#

Kısa cevap: TCP bağlantısı kurulduktan sonra karşı taraftan RST (reset) bayraklı bir paket geldi ve tarayıcı isteği tamamlayamadan bağlantıyı kapattı.

Bunu anlamak için TCP'nin normal akışını hatırlamak yeterli. Tarayıcı önce SYN gönderir, sunucu SYN-ACK ile cevaplar, tarayıcı ACK ile onaylar — bu üçlü el sıkışmadır. Sonra HTTP isteği (veya TLS ClientHello) gider, veri akmaya başlar, iş bitince FIN paketleriyle kibarca kapanır. RST bu akışın hiçbir yerinde "normal" değildir; "bu bağlantıyı tanımıyorum / devam edemiyorum / hemen kapat" anlamına gelen acil durum sinyalidir.

Bu yüzden ERR_CONNECTION_RESET kardeş hatalarından net biçimde ayrılır:

Aradaki farkı kavramak teşhisin yarısıdır. Bağlantının hiç kurulmadığı durumları ERR_CONNECTION_REFUSED hatası ve ERR_CONNECTION_TIMED_OUT hatası yazılarında ayrıca ele alıyoruz; bu yazı sadece "kurulan bağlantının ortada kopması" senaryosuna odaklanıyor.

RST Paketi Kimden Geliyor: Üç Şüpheli#

Bir RST paketi, uçtan uca yoldaki üç noktadan çıkabilir ve tarayıcı hepsini aynı ekranla gösterir:

1. Sunucudaki uygulama/işletim sistemi. PHP-FPM süreci segfault verdi, Node uygulaması SIGKILL yedi, Nginx worker'ı öldü ya da dinleme kuyruğu doldu. Çekirdek, sahibi kalmayan bağlantıya RST basar.
2. Bir güvenlik duvarı ya da filtre. Sunucudaki iptables/nftables kuralı, hosting tarafındaki mod_security/CSF, DDoS temizleme katmanı veya kurumsal ağdaki bir IPS. Bunlar bilinçli olarak REJECT --reject-with tcp-reset gönderir; amaç zaten bağlantıyı hızlıca öldürmektir.
3. TLS katmanı. Bağlantı 443'te kurulur, ClientHello gider, sunucu istemcinin sunduğu protokol sürümü veya şifre paketiyle anlaşamaz. Kibar sunucu alert handshake_failure gönderir; kaba olanı ya da araya giren bir cihaz doğrudan RST atar.

Üçünü ayırmanın anahtarı, hatanın hangi anda oluştuğudur: el sıkışmadan hemen sonra mı, HTTP isteği gönderildikten sonra mı, yoksa yanıtın belirli bir noktasında mı? Aşağıdaki akış tam olarak bunu ölçer.

Hatayı 5 Dakikada Sınıflandıran Teşhis Akışı#

En kısa yol, tarayıcıyı denklemden çıkarıp curl -v ile aynı isteği yapmaktır. Tarayıcı size tek bir kod gösterir; curl kopmanın hangi aşamada olduğunu satır satır söyler.

# 1) Düz HTTP ile dene, ayrıntılı çıktı al
curl -v --max-time 15 http://ornekalanadi.com/

# 2) HTTPS ile dene
curl -v --max-time 15 https://ornekalanadi.com/

# 3) Sadece TCP kurulabiliyor mu, uygulama katmanına hiç girmeden bak
timeout 5 bash -c 'cat < /dev/null > /dev/tcp/ornekalanadi.com/443' && echo "TCP acik" || echo "TCP kurulamadi"

Çıktıyı şu tabloyla eşleştirin:

curl -v çıktısında * TLSv1.3 (OUT), TLS handshake, Client hello (1): satırından sonra kopuyorsa şüpheli üçüncü gruptadır; > GET / HTTP/1.1 satırından sonra kopuyorsa birinci veya ikinci gruptadır. Bu tek ayrım, bundan sonraki bütün adımları belirler.

Sebep 1: Sunucudaki Süreç Çöküyor veya Bağlantıyı Kesiyor#

Sunucuya SSH ile girebiliyorsanız işiniz kolay: RST'in kaynağı genelde loglarda açık açık durur.

# Web sunucusu hata günlüğü (Nginx)
sudo tail -n 100 /var/log/nginx/error.log

# PHP-FPM havuzu ölüyor mu
sudo journalctl -u php8.2-fpm --since "30 min ago" --no-pager

# Çekirdek seviyesinde segfault / OOM killer var mı
sudo dmesg -T | grep -Ei 'segfault|oom|killed process'

Yıllardır en sık gördüğüm üç kalıp şunlardır:

• OOM killer. dmesg çıktısında Out of memory: Killed process 2841 (php-fpm) satırı varsa, bellek dolduğu için çekirdek süreci öldürmüştür; açık bağlantılar RST alır. Çözüm memory_limit değerini gerçekçi bir seviyeye çekmek, PHP-FPM havuzundaki pm.max_children sayısını düşürmek veya sunucunun belleğini artırmaktır.
• Segfault. segfault at ... in libphp gibi bir satır varsa hatalı bir PHP eklentisi (çoğunlukla ioncube, imagick ya da bir opcache sürümü) sürecin bacağını kırıyordur. Eklentiyi devre dışı bırakıp tekrar deneyin.
• Dinleme kuyruğu taşması. Ani trafikte ss çıktısında Send-Q sütunu backlog sınırına dayanmışsa, çekirdek yeni bağlantıları RST ile reddetmeye başlar.

# Dinleyen soketler ve kuyruk doluluğu
ss -ltnp

# Özet sayaçlar: overflow ve reset istatistikleri
netstat -s | grep -Ei 'listen|reset|overflow'

listen queue of a socket overflowed sayacı artıyorsa net.core.somaxconn ve uygulamanın kendi backlog değeri yetersizdir. Bu değerleri kademeli olarak artırın ve her değişiklikten sonra sayacın durup durmadığını ölçün; körlemesine büyük sayı yazmak sorunu gizler, çözmez.

Sebep 2: Güvenlik Duvarı veya Filtre RST Gönderiyor#

Bir güvenlik duvarının paketi sessizce düşürmesiyle (DROP) reddetmesi (REJECT --reject-with tcp-reset) arasındaki fark, kullanıcının gördüğü hatanın ta kendisidir: DROP zaman aşımı üretir, tcp-reset ise doğrudan ERR_CONNECTION_RESET üretir.

Sunucudaki kuralları kontrol edin:

# iptables kuralları, paket sayaçlarıyla
sudo iptables -L -n -v --line-numbers | grep -i reject

# nftables kullanan sistemlerde
sudo nft list ruleset | grep -i reset

# fail2ban sizi kendi sunucunuzdan banlamış olabilir
sudo fail2ban-client status
sudo fail2ban-client status sshd

Burada çok sık atlanan bir ayrıntı var: hata herkeste değil, sadece bazı ziyaretçilerde çıkıyorsa neredeyse kesinlikle IP tabanlı bir engelleme vardır. Kendi ofisinizden site açılmıyor ama mobil veriden açılıyorsa, ofis IP'niz banlanmıştır. Bu durumda çözüm sunucuyu kurcalamak değil, ilgili IP'yi listeden çıkarmak ve kalıcı beyaz listeye almaktır; kural yazımının tamamı için iptables ile güvenlik duvarı yazısına bakabilirsiniz.

Paylaşımlı hostingde ise kural genelde sizde değil, sunucu genelinde çalışan bir WAF/mod_security katmanındadır. Belirti çok tipiktir: site normalde açılır, ama belirli bir işlemde — yazı kaydederken, form gönderirken, eklenti güncellerken — bağlantı sıfırlanır. Bu, isteğin gövdesindeki bir kalıbın kurala takıldığını gösterir. Bu durumda hosting panelinizin hata günlüklerine bakın; cPanel'in Errors ekranı hangi kuralın tetiklendiğini genelde kural kimliğiyle ([id "941100"] gibi) birlikte yazar.

RST'in gerçekten yoldan mı geldiğini kanıtlamak isterseniz sunucuda paket yakalayın:

# Sunucuya gelen/giden RST paketlerini izle
sudo tcpdump -i any -nn 'tcp[tcpflags] & tcp-rst != 0' -c 20

İstemci bağlantıyı denerken sunucuda hiçbir RST görünmüyorsa, paketi kesen sizin sunucunuz değil, aradaki bir cihazdır (ISP, kurumsal IPS, DDoS temizleme katmanı).

Sebep 3: TLS El Sıkışması Ortada Kopuyor#

HTTPS'te bağlantı sıfırlandı hatasının en sinsi hali budur, çünkü sunucu ayakta, port açık, güvenlik duvarı temizdir — sadece iki taraf ortak bir dil bulamamıştır.

Test etmenin en net yolu OpenSSL ile sürümleri tek tek zorlamaktır:

# Sunucu hangi sürümleri kabul ediyor, tek tek deneyin
openssl s_client -connect ornekalanadi.com:443 -servername ornekalanadi.com -tls1_2 </dev/null
openssl s_client -connect ornekalanadi.com:443 -servername ornekalanadi.com -tls1_3 </dev/null

# Sunucunun desteklediği şifre paketlerini listele
nmap --script ssl-enum-ciphers -p 443 ornekalanadi.com

Çıktıda Cipher is (NONE) ve hemen ardından Connection reset by peer görüyorsanız teşhis nettir: istemcinin sunduğu şifre paketlerinden hiçbiri sunucuda etkin değildir. Bu iki yönde de olabilir:

• Sunucu fazla katı. TLS 1.0/1.1 kapatılmış, yalnızca modern şifreler bırakılmıştır. Doğru olan budur — ama eski bir POS cihazı, eski bir Android telefon ya da eski bir cURL sürümü bağlanmaya çalışınca RST yer. "Sitem bazı müşterilerde açılmıyor" şikâyetinin klasik sebebi.
• Sunucu fazla eski. Yeni tarayıcılar TLS 1.0/1.1'i tamamen bıraktı; sunucunuz sadece bunları destekliyorsa artık hiçbir güncel tarayıcı bağlanamaz.

Nginx tarafında doğru başlangıç noktası şudur:

server {
    listen 443 ssl;
    server_name ornekalanadi.com;

    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_prefer_server_ciphers off;
    ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384;
    ssl_session_cache shared:SSL:10m;
    ssl_session_timeout 1d;
}

Değişiklikten sonra nginx -t ile sözdizimini doğrulayıp systemctl reload nginx deyin. El sıkışmanın adım adım nasıl işlediğini ve hangi aşamada hangi mesajın gittiğini görmek isterseniz TLS handshake nasıl çalışır yazısı bu bölümün teorik karşılığıdır.

Bir uyarı: SNI göndermeyen eski istemciler de aynı sonucu üretir. openssl s_client komutunu -servername olmadan çalıştırıp RST alıyor, -servername ile alamıyorsanız sorun istemcinin SNI desteğidir, sunucunuzda değil.

Yanıtın Ortasında Kopan Bağlantılar: MTU, Proxy ve Tampon#

Sayfanın bir kısmı yüklenip sonra "bağlantı sıfırlandı" veriyorsa, ya da özellikle büyük dosya yüklerken hata alıyorsanız, şüpheli listesi değişir.

En sık sebep MTU uyuşmazlığıdır. VPN, PPPoE veya tünelli bağlantılarda paket boyutu yol boyunca küçülür; "don't fragment" bayraklı büyük paketler düşer ve bağlantı ortada takılır. Test:

# 1472 = 1500 MTU - 28 bayt basliklar. Basarisizsa kademeli kucultun.
ping -M do -s 1472 -c 3 ornekalanadi.com
ping -M do -s 1400 -c 3 ornekalanadi.com

1472 başarısız, 1400 başarılıysa yolda MTU daralması vardır. Sunucu tarafında MSS clamping bunu kapatır:

sudo iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

İkinci sık sebep, ters vekil sunucu (reverse proxy) ile arka uç arasındaki zaman aşımı ve tampon ayarlarıdır. Nginx arkasında PHP-FPM veya Node çalışıyorsa, arka uç yanıt vermeyi bitiremeden Nginx bağlantıyı kapatır:

proxy_connect_timeout 60s;
proxy_send_timeout    300s;
proxy_read_timeout    300s;
proxy_buffer_size     16k;
proxy_buffers         8 16k;
client_max_body_size  64m;

Yükleme sırasında kopmalarda client_max_body_size özellikle önemlidir; küçük kaldığında bazı yapılandırmalarda düzgün bir 413 yerine doğrudan bağlantı kesme davranışı görülür. Değeri PHP tarafındaki post_max_size ve upload_max_filesize ile birlikte, üçünü de aynı üst sınıra hizalayarak ayarlayın.

Ziyaretçi Tarafında Sorun Olduğunda Ne Yapmalı#

Hata sadece sizin cihazınızda çıkıyor ve site başka ağlardan sorunsuz açılıyorsa, sunucuya dokunmayın — sorun yerel ağdadır.

Sırasıyla şunları deneyin:

1. Mobil veriye geçin. Açılıyorsa sorun ISP'nizde, modeminizde veya kurum ağındadır. Bu tek adım, saatlerce yanlış yerde arama yapmanızı engeller.
2. Antivirüs/güvenlik yazılımının HTTPS taramasını kapatın. Bu yazılımlar araya girip TLS bağlantısını yeniden kurar; sertifika veya sürüm uyuşmazlığında bağlantıyı RST ile keserler.
3. VPN veya vekil sunucuyu devre dışı bırakın. MTU sorunlarının bir numaralı kaynağıdır.
4. Tarayıcı profilini eleyin. Gizli sekmede ve eklentiler kapalıyken deneyin; hâlâ varsa tarayıcı suçlu değildir.
5. Ağ yığınını sıfırlayın. Windows'ta:

netsh winsock reset
netsh int ip reset
ipconfig /flushdns

Komutlardan sonra bilgisayarı yeniden başlatın. Bu adımların hiçbiri sunucu kaynaklı bir RST'i çözmez; sadece istemci tarafını temize çıkarmak içindir. Kopmanın yol üzerinde nerede yaşandığını görmek isterseniz mtr -rwzbc 50 ornekalanadi.com komutunu çalıştırın — paket kaybının hangi atlamada başladığını atlama atlama gösterir.

Tekrarlayan Kesintileri Otomatik Yakalamak#

Hata "arada bir" çıkıyorsa, siz bakarken hiç çıkmaz. Bu yüzden en pratik yöntem, kopmayı sizin yerinize kaydeden küçük bir betiktir:

#!/usr/bin/env bash
# rst-izle.sh — belirli araliklarla istek atar, sadece basarisizligi kaydeder
set -uo pipefail
HEDEF="https://ornekalanadi.com/"
LOG="/var/log/rst-izle.log"

while true; do
  KOD=$(curl -s -o /dev/null -w '%{http_code}' --max-time 15 "$HEDEF")
  CIKIS=$?
  if [ "$CIKIS" -ne 0 ] || [ "$KOD" = "000" ]; then
    printf '%s curl_exit=%s http=%s\n' "$(date -Is)" "$CIKIS" "$KOD" >> "$LOG"
  fi
  sleep 30
done

curl çıkış kodu 56 veya 35 satırlarını gördüğünüz anda saatleri sunucu loglarıyla karşılaştırın: aynı dakikada bir OOM kaydı, bir PHP-FPM yeniden başlatması veya bir fail2ban banı varsa fail sizindir. Betik yazarken hata yönetimini doğru kurmak için bash fonksiyon ve hata yönetimi yazısındaki set -euo pipefail ve tuzak (trap) kalıplarını kullanın.

Sıkça Sorulan Sorular#

ERR_CONNECTION_RESET sunucunun kapalı olduğu anlamına mı gelir#

Hayır, tam tersine sunucunun cevap verdiği anlamına gelir. Sunucu tamamen kapalı olsaydı ya bağlantı hiç kurulamayacağı için ERR_CONNECTION_REFUSED ya da paketler cevapsız kaldığı için ERR_CONNECTION_TIMED_OUT alırdınız. Bağlantı sıfırlandı hatası, TCP el sıkışmasının tamamlandığını ve ardından bir tarafın RST paketi gönderdiğini gösterir. Yani makine ayakta; ya üzerindeki uygulama çöküyor ya bir filtre araya giriyor ya da TLS katmanı anlaşamıyor.

Aynı site telefondan açılıyor bilgisayardan açılmıyorsa sebep ne olabilir#

Bu tablo neredeyse her zaman istemci tarafını işaret eder. En sık üç sebep, bilgisayardaki güvenlik yazılımının HTTPS trafiğini araya girerek taraması, aktif bir VPN/vekil sunucunun MTU'yu daraltması ve ofis ağındaki bir güvenlik cihazının belirli içerikleri RST ile kesmesidir. Telefonda mobil veri kullanıyorsanız tamamen farklı bir ağdan çıktığınız için bu üç etkenin hiçbiri devrede olmaz. Bilgisayarda gizli sekme, antivirüs kapalı ve VPN kapalı halde tekrar deneyin; düzeliyorsa sunucuya hiç dokunmanıza gerek yok.

Sadece dosya yüklerken bağlantı sıfırlanıyor bunun sebebi nedir#

Yükleme sırasında kopma genelde boyut sınırı veya MTU kaynaklıdır. Web sunucusunda client_max_body_size, PHP tarafında upload_max_filesize ve post_max_size değerleri düşükse istek gövdesi sınırı aştığı anda bağlantı kesilebilir. İkinci ihtimal, ağ yolundaki MTU daralmasıdır; küçük istekler geçerken büyük paketler düştüğü için sorun sadece yüklemede görünür. ping -M do -s 1472 testi başarısız oluyorsa MTU tarafına, sunucu loglarında boyut uyarısı varsa limitlere bakın.

RST paketinin sunucudan mı yoldan mı geldiğini nasıl anlarım#

Sunucuda paket yakalayarak kesin sonuca ulaşırsınız. Sunucuda sudo tcpdump -i any -nn 'tcp[tcpflags] & tcp-rst != 0' komutunu çalıştırıp aynı anda istemciden isteği tekrarlayın. Sunucu bu RST'i kendisi üretiyorsa çıktıda kaynak adres olarak sunucunun IP'sini görürsünüz. İstemci hata alıyor ama sunucuda hiçbir RST kaydı yoksa paketi kesen aradaki bir cihazdır: ISP, kurumsal güvenlik duvarı, DDoS temizleme katmanı veya CDN.

Bağlantı sıfırlandı hatası SSL sertifikasının süresi dolduğu için çıkar mı#

Hayır, süresi dolmuş sertifika farklı bir hata üretir. Sertifika geçersizse tarayıcı bağlantıyı kurar, sertifikayı okur ve size güvenlik uyarısı gösterir; bu ERR_CERT_DATE_INVALID gibi bir sertifika hatasıdır, bağlantı sıfırlanması değildir. TLS kaynaklı bir RST, sertifikanın içeriğiyle değil, protokol sürümü ve şifre paketi anlaşmasıyla ilgilidir. Yani sunucu ile istemci daha sertifikayı konuşacak aşamaya bile gelemeden kopmuştur.

Paylaşımlı hostingde bu hatayı ben çözebilir miyim#

Kısmen çözebilirsiniz, çünkü RST'in kaynağına göre yetkiniz değişir. Uygulama kaynaklı çöküşleri, bellek limiti aşımlarını ve yükleme boyutu sınırlarını kendi panelinizden düzeltebilirsiniz. Buna karşılık sunucu genelindeki güvenlik duvarı kuralları, IP banları ve TLS protokol ayarları sağlayıcının yetkisindedir. Hata belirli bir işlemde tekrarlanıyorsa hata günlüklerinden ilgili kaydı alıp destek ekibine iletin; kural kimliğiyle birlikte gönderilen bir talep genellikle ilk yanıtta çözülür.

Bu hata SEO ve arama sıralamamı etkiler mi#

Evet, kalıcı hale gelirse etkiler. Arama motoru tarayıcıları da tıpkı ziyaretçiler gibi bağlantı sıfırlanması yaşar ve sayfayı alamadan geri döner; tekrarlayan başarısız taramalar tarama bütçesinin düşmesine ve mevcut sayfaların dizinde eskimesine yol açar. Tek seferlik, birkaç dakikalık bir kesinti anlamlı bir zarar vermez. Ancak günlerce süren aralıklı kopmalar hem tarama sıklığını hem de kullanıcı davranış sinyallerini olumsuz etkiler; bu nedenle aralıklı hataları da kalıcı hata gibi ele almak gerekir.

Kapanış#

ERR_CONNECTION_RESET bir "internet sorunu" değil, kurulmuş bir bağlantının bilinçli ya da zorunlu olarak koparıldığının kanıtıdır. Bu yüzden çözümün ilk adımı da bir ayar değiştirmek değil, RST'in kaynağını tespit etmektir: curl -v çıktısında kopmanın TLS ClientHello'dan mı yoksa HTTP isteğinden sonra mı olduğunu görmek, üç şüpheliden ikisini tek hamlede eler. Ardından sunucu loglarında OOM/segfault izi, güvenlik duvarında REJECT --reject-with tcp-reset kuralı ve openssl s_client ile protokol uyumu sırayla kontrol edilir. Bu sıralamayı bozmadan ilerlediğinizde hata, tahmin oyunu olmaktan çıkıp beş on dakikalık bir teşhise dönüşür.

Bu tanılamayı yapabilmek için sunucunun loglarına, güvenlik duvarına ve TLS yapılandırmasına erişmeniz gerekir; paylaşımlı bir ortamda bu erişimin bir kısmı sağlayıcıdadır. Kendi kurallarınızı, kendi çekirdek parametrelerinizi ve kendi TLS sürümlerinizi yönetmek istiyorsanız VDS sunucu paketleri bu kontrolü size verir; kurulum, sertleştirme ve günlük izleme kısmını başkasının üstlenmesini tercih ediyorsanız sunucu yönetimi hizmeti bu yükü devralır. Kopmaların kaynağı hacim tabanlı saldırılarsa DDoS koruma katmanı trafiği sunucunuza ulaşmadan temizler ve RST üreten filtreleme yükünü sunucunuzun üzerinden alır.