ERR_CONNECTION_RESET Hatası Nedir ve Nasıl Çözülür?

ERR_CONNECTION_RESET hatası nedir?

ERR_CONNECTION_RESET, tarayıcı ile web sunucusu arasındaki TCP bağlantısının veri aktarımı tamamlanmadan kapatıldığını gösterir. Kapatma işlemini sunucu, güvenlik duvarı, proxy, VPN, DNS yönlendirmesi, ağ cihazı veya istemci tarafındaki bir yazılım başlatmış olabilir. Hata yalnızca bir siteyi etkiliyorsa sunucu ve DNS tarafına, tüm sitelerde görülüyorsa yerel ağa odaklanırım.

Chrome ve Chromium tabanlı tarayıcılar bu ifadeyi, bağlantının beklenmedik biçimde sıfırlandığını anlatmak için kullanır. Bu, sunucunun kesin olarak kapalı olduğu anlamına gelmez. TCP bağlantısı kurulmuş olabilir; ardından uçlardan biri ya da aradaki bir ağ cihazı RST paketi göndererek oturumu sonlandırmış olabilir.

HTTP katmanına ulaşmadan önce bağlantı kopabildiği için web sunucusunun erişim logunda hiç kayıt görünmeyebilir. Bu ayrım benim için önemli. Log yoksa hemen nginx yapılandırmasına sarılmak yerine DNS, IPv4 ve IPv6, güvenlik duvarı ve ağ yolunu kontrol ederim.

ERR_CONNECTION_RESET neden olur?

Hatanın adı tarayıcıdan geliyor, fakat sebep çoğu zaman tarayıcının içinde bulunmuyor. Aşağıdaki tablo, ilk bakışta hangi katmana yönelmem gerektiğini gösteriyor.

RFC 9293’te tanımlanan TCP davranışında RST, mevcut bir bağlantının beklenmedik biçimde sonlandırılmasında kullanılan kontrol bitlerinden biridir. Tarayıcının gösterdiği hata bu ağ olayının kullanıcı arayüzündeki karşılığıdır. “Reset atan kesinlikle web sunucusudur” demek bu yüzden fazla iddialı olur.

Site mi, internet bağlantısı mı sorunlu nasıl anlaşılır?

Önce sorunun kapsamını daraltın. Aynı alan adını telefondaki mobil veriyle, başka bir Wi-Fi bağlantısıyla ve mümkünse farklı bir cihazla açın. Yalnızca kendi bilgisayarınızda görülüyorsa tarayıcı, yerel DNS, VPN veya güvenlik yazılımı öne çıkar. Farklı ağlarda da görülüyorsa sunucu, DNS veya hosting tarafını incelemek gerekir.

Terminalde ilk baktığım çıktılar genellikle dig ve curl olur:

dig +short A example.com
dig +short AAAA example.com
curl -IvsS --connect-timeout 10 https://example.com/

İlk iki satır IPv4 ve IPv6 adreslerini gösterir. curl çıktısında hangi adrese bağlanıldığını, TLS görüşmesinin başlayıp başlamadığını ve bağlantının nerede kesildiğini görebilirsiniz. -I yalnızca HTTP başlıklarını ister; -v ise teşhis için ayrıntılı bağlantı bilgisini açar.

IPv4 ve IPv6’yı ayrıca deneyin:

curl -4Iv https://example.com/
curl -6Iv https://example.com/

curl -4 başarılı, curl -6 reset ile bitiyorsa A kaydı ve IPv4 yolu sağlamken AAAA kaydı, IPv6 yönlendirmesi veya sunucunun IPv6 dinleme ayarı sorunlu olabilir. Tarayıcı bazen IPv6’yı seçtiği için hata yalnızca belirli bağlantılarda görünür.

DNS çözülüyor ama bağlantı kurulamıyorsa

DNS’in doğru IP’yi döndürmesi, o IP’deki 443 portunun erişilebilir olduğu anlamına gelmez. Alan adı, eski bir sunucunun adresine veya yanlış bir AAAA kaydına gidiyor olabilir. DNS TTL süresi dolana kadar bazı istemciler eski cevabı önbelleğinde tutabilir; her hatayı “DNS yayılması” diye açıklamak yine de doğru değildir.

Sunucunun kendi tarafından dinleyen portları kontrol ederim:

sudo ss -lntp | grep -E ':(80|443)'
sudo systemctl status nginx --no-pager

Burada 0.0.0.0:443 IPv4 üzerinde, [::]:443 ise IPv6 üzerinde dinleme olduğunu gösterebilir. Yalnızca birini görüyorsanız DNS kayıtları ile servis dinleme adreslerinin aynı protokolü destekleyip desteklemediğine bakın.

ERR_CONNECTION_RESET sunucu tarafında nasıl çözülür?

Sunucuya SSH ile erişebiliyorsanız çözümü rastgele servis yeniden başlatmakla başlatmayın. Önce semptomu ve zamanı kaydedin. Log okumadan yeniden başlatmak problemi gizleyebilir; özellikle bağlantı sayısı, kernel mesajı veya WAF engeli gibi geçici kanıtlar kaybolabilir.

1. Nginx veya Apache loglarını inceleyin

Nginx kullanıyorsanız alan adına ait erişim ve hata loglarını izleyin:

sudo tail -f /var/log/nginx/access.log /var/log/nginx/error.log

İstek erişim logunda oluşuyor, fakat istemci reset alıyorsa sorun proxy, upstream uygulama veya yanıt üretimi sırasında olabilir. Hiç kayıt oluşmuyorsa trafik nginx’e ulaşmadan önce kesiliyor olabilir. Apache kullanan sistemlerde dağıtıma göre /var/log/apache2/ veya /var/log/httpd/ altını kontrol edin.

Son hata kayıtlarını daha kontrollü görmek için:

sudo journalctl -u nginx --since '15 minutes ago' --no-pager
sudo nginx -t

nginx -t yapılandırma sözdizimini doğrular; mevcut bağlantıların neden koptuğunu açıklamaz. Test geçse bile upstream uygulaması çökmüş, dosya tanıtıcısı sınırı dolmuş veya kernel bağlantıları reddediyor olabilir.

2. Uygulama servisini ve upstream bağlantısını kontrol edin

Reverse proxy arkasında çalışan PHP-FPM, Node.js, Python veya başka bir uygulama yanıt vermiyorsa nginx istemciye beklenmeyen bir hata döndürebilir. Uygulama portunu ve servis durumunu ayrı kontrol edin:

sudo ss -lntp
sudo systemctl --failed
sudo journalctl -u php8.2-fpm --since '30 minutes ago' --no-pager

Buradaki servis adı sisteminizde farklı olabilir. Ubuntu üzerinde PHP sürümüne göre php8.1-fpm veya php8.3-fpm görmeniz normaldir. Nginx’in proxy_pass ya da fastcgi_pass hedefi gerçekten dinleyen soket veya porta işaret etmeli.

3. Güvenlik duvarı ve fail2ban kayıtlarına bakın

Tek bir istemcinin bağlantısı kesiliyor, başka bir ağdan site açılıyorsa engelleme ihtimali yükselir. SSH portunu değiştirmeyi güvenlik çözümü saymam; fail2ban ve nftables kurallarını gerçekten okumak, yanlış engellemeyi buldurur.

sudo nft list ruleset
sudo fail2ban-client status
sudo fail2ban-client status sshd

Üretim sisteminde kuralı görmeden silmek yerine önce kaynak IP’yi, zinciri ve sayaçları not edin. WAF, CDN veya hosting panelindeki güvenlik katmanı da aynı şekilde incelenmeli. Bir istemci IP’sinin ban listesinde olması, tarayıcıdaki reset mesajını açıklayabilir.

4. Kaynak limitlerini ve kernel mesajlarını inceleyin

Web sunucusu dosya tanıtıcısı, bellek veya bağlantı kuyruğu limitlerine dayanmışsa hata düzensiz görünebilir. Aşağıdaki komutlar tek başına teşhis koymaz; hangi yöne bakacağınızı söyler:

free -h
uptime
sudo dmesg -T | tail -n 80
sudo ss -s

dmesg içinde bellek yetersizliği, ağ sürücüsü veya bağlantı tablosu ile ilgili kayıtlar aranabilir. ss -s bağlantı durumlarının özetini verir.

Gece vardiyalarından birinde istemciler bağlantı kopması bildiriyordu. İlk bakışta nginx’e odaklandım, fakat ncdu ile baktığımda /var bölümünün loglarla dolduğunu gördüm; uygulamanın logrotate ayarı unutulmuştu. Disk tamamen dolmadan log rotasyonunu düzelttim, ardından nginx logunda yeni bağlantıların normale döndüğünü doğruladım. O olaydan beri disk kullanımını CPU kadar erken kontrol ediyorum.

Tarayıcıda ve bilgisayarda hangi adımlar denenebilir?

Sunucuda sorun görünmüyorsa istemci tarafında şu sırayı izleyin:

1. Sayfayı gizli pencerede açın ve uzantıları geçici olarak devre dışı bırakın.
2. VPN, kurumsal proxy ve antivirüsün HTTPS tarama özelliğini geçici olarak kapatıp tekrar deneyin.
3. Farklı bir DNS çözümleyicisiyle karşılaştırma yapın; önce mevcut DNS yanıtını kaydedin.
4. Modem ve yerel ağ cihazlarını yeniden başlatmadan önce başka bir ağdan test edin.
5. İşletim sisteminin tarih-saat ayarını ve sistem proxy ayarını kontrol edin.

Tarayıcı önbelleğini temizlemek bazen işe yarar, fakat bu adım ağ seviyesindeki reset’i onarmaz. Aynı URL curl ile de reset veriyorsa sorun büyük ihtimalle yalnızca tarayıcı önbelleği değildir.

Windows ve Linux DNS önbelleği

Windows’ta DNS önbelleğini temizlemek için:

ipconfig /flushdns

Linux’ta önbellekleme servisine göre komut değişir. systemd-resolved kullanılıyorsa:

sudo resolvectl flush-caches
resolvectl statistics

Bu komutlar yalnızca yerel DNS önbelleğini temizler. Alan adının yanlış IP’ye işaret eden kaydını düzeltmez; kayıt panelindeki A veya AAAA değerini ayrıca doğrulamak gerekir.

Bir IPv6 hatasını nasıl ayırt ederim?

IPv6 tarafındaki sorunlar, IPv4 bağlantısı çalışan bir sistemde kolayca gözden kaçar. Benzer durumda önce iki protokolü ayrı ayrı test ederim; tarayıcının hangi yolu seçtiğini tahmin etmek yerine çıktıya bakmak daha hızlıdır.

$ curl -4I https://ornek-site.test
HTTP/2 200

$ curl -6I https://ornek-site.test
curl: (35) Recv failure: Connection reset by peer

Bu çıktı, HTTP başlıklarının IPv4 yolundan geldiğini ve IPv6 tarafında TLS veya HTTP aşamasına ulaşmadan bağlantının kapandığını gösterir. AAAA kaydı eski VPS’i gösteriyor olabilir; IPv6 firewall kuralı eksik kalmış veya web servisi yalnızca IPv4 adresinde dinliyor olabilir.

DNS yapılandırmasını değiştirirken A, AAAA, CDN origin adresi ve sunucunun gerçek dinleme adresini birlikte kontrol edin. Alan adı yapısı için Alt Alan Adı (Subdomain) Nedir? Kullanım Rehberi yazısındaki kayıt mantığı da yardımcı olabilir; kritik nokta, her alt alan adının doğru IP ailesine gitmesidir.

Proxy, VPN ve MTU bağlantıyı neden sıfırlayabilir?

VPN veya kurumsal proxy, istemci ile web sunucusu arasına yeni bir ağ katmanı ekler. Tünel içindeki MTU değeri doğru ayarlanmadığında büyük paketler parçalanabilir ya da sessizce düşebilir. Bazı cihazlar ICMP mesajlarını engellediği için bağlantı, tarayıcı tarafında genel bir reset hatasına dönüşebilir.

Yol hakkında fikir edinmek için:

mtr -rwzc 50 example.com

Bu satırdaki -r rapor biçimini, -w geniş çıktıyı, -c 50 ise gönderilecek test sayısını belirler. MTR’deki tek bir ara düğümde görülen kayıp, sonraki düğümlerde kayıp yoksa gerçek uçtan uca kayıp olmayabilir; bazı yönlendiriciler teşhis paketlerine düşük öncelik verir. Yalnızca tabloya bakıp ISS’yi suçlamak yerine son hedefteki kayba odaklanın.

VPN kapalıyken site açılıyor, VPN açıkken reset alıyorsanız VPN sunucusunun çıkış IP’si engellenmiş, tünel MTU’su uyumsuz veya proxy TLS trafiğini bozuyor olabilir. VPS tarafında paket boyutlarıyla oynarken ölçüm yapmadan kalıcı sysctl ayarı eklemeyin. Bir ayarı kopyalayıp her makineye uygulamak, ağ sorununu çözmek yerine yeni bir tane üretebilir.

Hosting müşterileri için kontrol sırası

Paylaşımlı hosting veya VPS kullanıyorsanız her katmana erişiminiz olmayabilir. Destek talebine yalnızca “site açılmıyor” yazmak yerine aşağıdaki bilgileri eklemek çözümü hızlandırır:

• Hatanın görüldüğü tam alan adı ve URL.
• İlk görüldüğü tarih-saat ve mümkünse saat dilimi.
• Mobil veri, ev interneti ve VPN ile sonuçların karşılaştırması.
• IPv4 ve IPv6 testlerinin sonucu.
• Tarayıcı, işletim sistemi ve hata ekranının tam metni.
• curl -Iv çıktısında bağlantının hangi aşamada koptuğu.

Sunucu kaynaklı trafik yoğunluğu veya DDoS şüphesi varsa bağlantı sayısı ve bant genişliği de incelenmelidir. Bu noktada DDoS Saldırısı Nedir? VPS Koruma Rehberi yazısındaki trafik ve rate limit yaklaşımıyla birlikte düşünmek gerekir. Sadece portu değiştirmek ya da sunucuyu yeniden başlatmak saldırı trafiğini ortadan kaldırmaz.

Siteye ait dosyaları değiştirmeden önce yedek ve geri dönüş planı hazırlayın. Nginx yapılandırmasında küçük bir hata için nginx -t çalıştırmadan reload vermek, bağlantı hatasını büyütebilir. Üretimde sade bir çalışma sıram var: gözlemle, tek değişiklik yap, config testini çalıştır, sonra kontrollü reload et.

Hangi çözüm ne zaman işe yarar?

“Chrome’u silip yeniden kurun” gibi öneriler ancak diğer testler istemciyi işaret ediyorsa anlamlıdır. Hata kodu tek başına yeterli kanıt değildir; aynı reset mesajı, yanlış IPv6 kaydından bozuk bir VPN tüneline kadar farklı nedenlerle ortaya çıkabilir.

Sık Sorulan Sorular

ERR_CONNECTION_RESET virüs belirtisi midir?

Tek başına bu hata bir virüs belirtisi değildir. VPN, antivirüsün HTTPS denetimi, yerel proxy, güvenlik duvarı veya karşı sunucu bağlantıyı kesmiş olabilir; şüpheli başka belirtiler varsa güvenlik taraması ayrıca yapılmalıdır.

ERR_CONNECTION_RESET ile ERR_CONNECTION_REFUSED arasındaki fark nedir?

ERR_CONNECTION_REFUSED genellikle hedefte bağlantının kabul edilmediğini, örneğin portta servis dinlemediğini gösterir. ERR_CONNECTION_RESET ise kurulmuş ya da kurulmakta olan bağlantının RST ile kapatıldığını anlatır; iki hata da ağ katmanındaki farklı olayların tarayıcıya yansımasıdır.

Sunucuyu yeniden başlatmak bu hatayı çözer mi?

Bazen geçici bir servis kilitlenmesini düzeltir, fakat kök nedeni ortadan kaldırmaz. Önce nginx, uygulama, firewall ve kernel loglarını kaydedin; aksi halde yeniden başlatma sırasında teşhis için gerekli kanıtı kaybedebilirsiniz.

ERR_CONNECTION_RESET sadece tek bir web sitesinde görülüyorsa ne yapmalıyım?

Önce alan adının A ve AAAA kayıtlarını, ardından mobil veri ve IPv4/IPv6 bağlantılarını karşılaştırın. Diğer siteler açılıyor ve aynı alan adı farklı ağlarda da çalışmıyorsa site sahibi ya da hosting sağlayıcısı sunucu, CDN ve güvenlik duvarı loglarını incelemelidir.

Kaynaklar

• RFC 9293 – Transmission Control Protocol — rfc-editor.org
• NGINX – Official Documentation — nginx.org