ERR_CONNECTION_REFUSED: Bunun Anlamı ve Tamamen Nasıl Düzeltileceği

ERR_CONNECTION_REFUSED hatası, tarayıcınızın bir web sunucusuna bağlantı isteği gönderdiği ve o sunucunun bunu aktif olarak reddettiği anlamına gelir — görmezden gelmedi, ancak TCP el sıkışmasını açıkça reddetti. Bu, zaman aşımından (ERR_CONNECTION_TIMED_OUT) veya DNS hatasından (ERR_NAME_NOT_RESOLVED) temelde farklı bir başarısızlık modudur ve kök nedeni teşhis ederken bu ayrım son derece önemlidir.

Pratik anlamda, Chrome “Bu siteye ulaşılamıyor. ERR_CONNECTION_REFUSED” gösterdiğinde, bu üç şeyden birini ifade eder: hedef sunucu istenen portta dinlemiyor, bir güvenlik duvarı veya güvenlik katmanı istemcinize bir TCP RST (sıfırlama) paketi gönderiyor veya yerel ağ yığınız yanlış yapılandırılmış ve isteği sunucuya ulaşmadan önce yanlış yönlendiriyor. Bu üç kategoriden hangisinin durumunuza uygulandığını belirlemek, bir çözüme giden en hızlı yoldur.

TCP Seviyesi Mekaniklerini Anlamak

Çoğu tarayıcı sorun giderme kılavuzu ERR_CONNECTION_REFUSED öğesini belirsiz bir “ağ sorunu” olarak ele alır. Değildir. TCP katmanında, reddedilen bir bağlantı, sunucunun (veya bir aracının) tarayıcınızın SYN paketine yanıt olarak bir RST/ACK paketi gönderdiği anlamına gelir. Bu açık bir reddetme, sessiz bir düşüş değildir.

Bu ayrım pratik bir tanı çıkarımına sahiptir: bağlantı bir güvenlik duvarı tarafından sessizce bırakılıyorsa, ERR_CONNECTION_TIMED_OUT görürsünüz. Reddedilen bir bağlantı, bir şeyin aktif olarak yanıt verdiği anlamına gelir — bu, ana bilgisayarın ağ düzeyinde erişilebilir olduğu, ancak hedef bağlantı noktasındaki hizmetin kullanılamadığı veya engellendiği anlamına gelir.

Yaygın bağlantı noktası düzeyindeki nedenler şunları içerir:

• Web sunucusu işlemi (Apache, Nginx, Node.js) çökmüş veya durdurulmuş
• Sunucu standart olmayan bir bağlantı noktasında dinliyor ve URL bunu belirtmiyor
• Ana bilgisayar tabanlı bir güvenlik duvarı (iptables, ufw, Windows Defender Firewall) bağlantı noktası 80 veya 443 üzerindeki bağlantıları reddediyor
• Ters proxy (HAProxy, Nginx, Cloudflare) yanlış yapılandırılmış ve yukarı akışta RST paketleri döndürüyor
• Proxy arkasındaki uygulama çökmüş, proxy’nin iletilecek bir arka uç yok

Kök Nedenler: Yapılandırılmış Bir Analiz

İstemci Tarafı Nedenleri

Sunucu Tarafı Nedenleri

Adım Adım Tanılama ve Düzeltme Kılavuzu

Adım 1: Sorunun Genel mi Yoksa Yerel mi Olduğunu Belirleyin

Herhangi bir yerel ayarı değiştirmeden önce, sitenin herkes için mi yoksa sadece sizin için mi kapalı olduğunu belirleyin. Bu araçları kullanın:

• downforeveryoneorjustme.com — basit açık/kapalı kontrolü
• isitdownrightnow.com — yanıt süresi geçmişini içerir
• ping.pe — hedefi birden fazla küresel konumdan aynı anda pingler

Site harici düğümlerden erişilebilir ancak makinenizden erişilemiyorsa, sorun yereldir. Küresel olarak erişilemiyorsa, sorun sunucu tarafındadır ve sizin kontrolünüz dışındadır — site yöneticisine başvurun veya bekleyin.

Kendi altyapısını yöneten sunucu yöneticileri için, küresel olarak erişilemeyen bir site, web sunucusu işlemi, güvenlik duvarı kuralları ve yukarı akış ağına acil bir araştırma gerektirir. VPS Hosting ortamı çalıştırıyorsanız, önce sunucunuzun işlem listesini ve güvenlik duvarı yapılandırmasını kontrol edin.

Adım 2: Sunucunun Gerçekten Dinlediğini Doğrulayın (Sunucu Yöneticileri İçin)

Söz konusu sunucuyu yönetiyorsanız, SSH ile bağlanın ve hangi portlarda neyin dinlediğini doğrulamak için aşağıdakileri çalıştırın:

sudo ss -tlnp | grep -E ':80|:443'

80 veya 443 portunun çıktısı boşsa, web sunucusu işleminiz çalışmıyor. Yeniden başlatın:

# For Nginx
sudo systemctl restart nginx

# For Apache
sudo systemctl restart apache2

# Check status
sudo systemctl status nginx

Ayrıca güvenlik duvarınızın gelen bağlantıları engellemediğini doğrulayın:

# Check iptables rules
sudo iptables -L INPUT -n -v

# If using ufw
sudo ufw status verbose

443 portu engelleniyorsa, izin verin:

sudo ufw allow 443/tcp
sudo ufw allow 80/tcp
sudo ufw reload

Dedicated Servers çalıştıran yöneticiler için, barındırma sağlayıcınızın yukarı akış güvenlik duvarının veya güvenlik grubu kurallarının portu ağ çeperinde engelleyip engellemediğini de kontrol edin — bu, işletim sistemi düzeyindeki güvenlik duvarından ayrıdır.

Adım 3: Yönlendiriciye Yeniden Başlayın ve Yerel Ağ Durumunu Temizleyin

İstemci tarafı sorunları için, yönlendirici yeniden başlatması NAT tablolarını, DHCP kiralamalarını ve geçici yönlendirme hatalarını temizler. Yönlendiricinin fişini 30 saniye çıkarın, ardından yeniden takın. Bu, hata herhangi bir yapılandırma değişikliği olmadan aniden ortaya çıktığında özellikle etkilidir.

Adım 4: DNS Önbelleğini Temizleyin

Eski veya kullanımdan kaldırılmış bir IP adresine işaret eden eski bir DNS önbellek girişi, istemci tarafında ERR_CONNECTION_REFUSED en yaygın nedenlerinden biridir. Önbelleğe alınan IP’deki sunucu artık hedef siteyi çalıştırmıyor olabilir.

• Windows’ta:

ipconfig /flushdns

• macOS’ta (Ventura, Sonoma ve çoğu modern sürüm):

sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

• Linux’ta (systemd-resolved):

sudo systemd-resolve --flush-caches

Temizledikten sonra, etki alanının şimdi hangi IP’ye çözümlendiğini doğrulayın:

nslookup example.com
# or
dig +short example.com

Bunu sitenin bilinen IP’si ile karşılaştırın. Farklıysa, DNS yayılması hala devam ediyor olabilir.

Adım 5: Tarayıcı Önbelleğini ve Çerezleri Temizleyin

Google Chrome’da chrome://settings/clearBrowserData adresine gidin veya klavye kısayolunu kullanın:

• Windows/Linux: Ctrl + Shift + Delete
• macOS: Cmd + Shift + Delete

Zaman aralığını Tüm zamanlar olarak ayarlayın, Önbelleğe alınan resimler ve dosyalar ile Çerezler ve diğer site verileri seçeneğini işaretleyin, ardından Verileri temizle seçeneğine tıklayın. Yeniden test etmeden önce Chrome’u tamamen yeniden başlatın (sadece sekmeyi değil).

Verileri temizlemeden daha hızlı bir test için, bir Gizli pencere açın (Ctrl + Shift + N). Site Gizli pencerede yüklüyse ancak normal pencerede yüklenmiyorsa, önbelleğe alınan bir kaynak veya bir tarayıcı uzantısı suçludur.

Adım 6: Proxy Ayarlarını Denetleyin ve Devre Dışı Bırakın

Yanlış yapılandırılmış veya ölü bir proxy sunucusu, tüm web sitelerinde aynı anda ERR_CONNECTION_REFUSED sık nedenlerinden biridir. Chrome varsayılan olarak sistem proxy ayarlarını kullanır.

• Windows’ta:

Ayarlar > Sistem > Proxy adresine gidin ve “Proxy sunucusu kullan” seçeneği bilginiz olmadan etkinleştirilmişse devre dışı bırakın. Alternatif olarak, yükseltilmiş bir Komut İsteminden bunu çalıştırın:

netsh winhttp reset proxy

• macOS’ta

Sistem Ayarları > Ağ adresine gidin, etkin arabiriminizi seçin, Ayrıntılar seçeneğine tıklayın, ardından Proxy’ler sekmesine tıklayın ve etkin tüm proxy protokollerinin işaretini kaldırın.

Proxy’yi devre dışı bıraktıktan sonra siteyi test edin. Yüklüyse, proxy yapılandırmanız sorunun nedeni idi. Bunu doğru şekilde yeniden yapılandırın veya tamamen kaldırın.

Adım 7: DNS Çözümleyicinizi Değiştirin

İSS’nizin varsayılan DNS çözümleyicisi yanlış sonuçlar döndürüyor, bir kesinti yaşıyor veya belirli etki alanlarını aktif olarak engelliyor olabilir. Genel bir çözümleyiciye geçmek bu değişkeni ortadan kaldırır.

Önerilen genel DNS çözümleyicileri:

• Windows’ta (PowerShell aracılığıyla):

Set-DnsClientServerAddress -InterfaceAlias "Wi-Fi" -ServerAddresses ("1.1.1.1","1.0.0.1")

• macOS’ta:

Sistem Ayarları > Ağ > [Arabiriminiz] > Ayrıntılar > DNS adresine gidin, mevcut girişleri kaldırın ve 1.1.1.1 ile 1.0.0.1 ekleyin.

• Linux’ta (systemd-resolved):

/etc/systemd/resolved.conf dosyasını düzenleyin:

[Resolve]
DNS=1.1.1.1 1.0.0.1
FallbackDNS=8.8.8.8 8.8.4.4

Ardından çözümleyiciyi yeniden başlatın:

sudo systemctl restart systemd-resolved

Adım 8: Güvenlik Duvarını ve Antivirüsü Geçici Olarak Devre Dışı Bırakın

Bazı antivirüs ürünleri ve ana bilgisayar tabanlı güvenlik duvarları HTTPS trafiğini yerel bir proxy aracılığıyla keser ve denetim motoru başarısız olduğunda veya hedef etki alanı bir engel listesinde olduğunda RST paketleri gönderebilir. Bunları geçici olarak devre dışı bırakmak (yalnızca tanılama amaçları için) bunların nedeni olup olmadığını doğrular.

Güvenlik yazılımını devre dışı bırakmak hatayı çözerse, yazılımı devre dışı bırakmak yerine hedef etki alanı için belirli bir istisna ekleyin. Test ettikten sonra hemen yeniden etkinleştirin.

Adım 9: Farklı Bir Tarayıcı ve Ağ ile Test Edin

URL’yi Firefox, Edge veya Safari’de test edin. Başka bir tarayıcıda yüklüyse, sorun Chrome’a özgüdür — muhtemelen bozuk bir profil, arızalı bir uzantı veya Chrome’a özgü bir proxy ayarı. Sorunu izole etmek için yeni bir Chrome profili oluşturmayı deneyin.

Site tüm tarayıcılarda başarısız olursa, mobil hotspot’a geçin. Mobil veriler üzerinden yüklüyse, ISS’niz veya ev yönlendiricisi sorunun kaynağıdır.

Adım 10: SSL/TLS Yapılandırma Sorunlarını Kontrol Edin (Sunucu Yöneticileri)

Yanlış yapılandırılmış bir SSL sertifikası, sunucunun çökmesine veya TLS bağlantılarını reddetmesine neden olabilir; Chrome bunu bazı uç durumlarda sertifika hatası yerine ERR_CONNECTION_REFUSED olarak bildirir. Komut satırından test etmek için aşağıdakileri kullanın:

curl -vI https://yourdomain.com

Ayrıntılı çıktıda TLS el sıkışma aşamasını arayın. Buradaki bir hata, sertifika veya şifre paketi sorununu gösterir. Ayrıca şu şekilde test edebilirsiniz:

openssl s_client -connect yourdomain.com:443 -servername yourdomain.com

SSL sertifikanız süresi dolmuşsa veya yanlış yapılandırılmışsa, bunu yenilemek veya değiştirmek sorunu çözer. SSL Sertifikalarınız geçerli, düzgün şekilde zincirlenmiş ve doğru sunucu arayüzüne yüklenmiş olduğundan emin olun.

ERR_CONNECTION_REFUSED vs. Benzer Tarayıcı Hataları

Bu hatanın ilgili hatalardan nasıl farklı olduğunu anlamak yanlış tanılamayı önler:

Gelişmiş Edge Case’ler ve Tuzaklar

1) IPv6 vs. IPv4 çözümleme çatışmaları:

Bir alan adı IPv6 adresine çözümlenirse ancak ağınız IPv6’yı düzgün şekilde desteklemiyorsa, Chrome IPv6 bağlantısı deneyebilir, bu reddedilir ve ardından IPv4’e hızlı bir şekilde geri dönüş yapamayabilir. Ağ adaptöründe IPv6’yı geçici olarak devre dışı bırakmak bunu doğrulayabilir. Linux’ta, curl -4 https://example.com ile IPv4’ü zorlayabilirsiniz.

2) Cloudflare veya CDN önbelleğe alınan eski kaynak hataları:

Bir site Cloudflare kullanıyorsa ve kaynak sunucu kapanırsa, Cloudflare bir süre için önbelleğe alınan bir sürümü sunabilir, ardından 521 (kaynak bağlantıyı reddetti) veya 522 hataları döndürmeye başlayabilir; Chrome bunları hata nasıl proxy yapıldığına bağlı olarak ERR_CONNECTION_REFUSED olarak gösterebilir.

3) Localhost geliştirme ortamları:

Geliştiriciler localhost:3000 veya benzer adreslerine erişirken sık sık ERR_CONNECTION_REFUSED görmektedir. Neden neredeyse her zaman geliştirme sunucusu işleminin çalışmadığı, çöktüğü veya 127.0.0.1‘e bağlandığı ancak beklenenden farklı bir porta bağlandığıdır. Aslında neyin dinlediğini doğrulamak için ss -tlnp | grep node (veya ilgili işlem) komutunu çalıştırın.

4) E-posta sunucusu port çatışmaları:

Web uygulamanızla aynı sunucuda E-posta Barındırma çalıştırıyorsanız, SMTP (25, 587), IMAP (993) ve HTTP/HTTPS (80, 443) arasındaki port çatışmalarının web sunucusunun bağlanmasını başarısız kılmadığından emin olun.

5) Paylaşılan barındırma sınırlamaları:

Paylaşılan Web Barındırma ortamlarında, bir bağlantı reddi, barındırma sağlayıcısının sunucusunun aşırı yüklü olduğunu, hesabın askıya alındığını veya alan adının DNS’inin doğru paylaşılan IP’ye işaret etmediğini gösterebilir. Hesap durumu ve DNS yapılandırması için barındırma kontrol panelinizi kontrol edin.

Pratik Karar Matrisi: Hangi Düzeltmeyi Önce Uygulamalı

Verimli bir şekilde önceliklendirmek için bu kontrol listesini kullanın:

• Hata tüm web sitelerinde aynı anda görünüyor — Önce proxy ayarlarını ve VPN/firewall yapılandırmasını kontrol edin
• Hata yalnızca bir belirli alan adında görünüyor — Sitenin global olarak kapalı olup olmadığını kontrol edin; ardından DNS önbelleğini temizleyin
• Hata yalnızca Chrome’da görünüyor, diğer tarayıcılarda değil — Chrome önbelleğini temizleyin, uzantıları devre dışı bırakın veya yeni bir Chrome profili oluşturun
• Hata yalnızca ağınızda görünüyor, mobil veriye bağlı değil — Yönlendiriciye yeniden başlayın; ISS düzeyinde DNS veya firewall’ı kontrol edin
• Hata sunucu yapılandırması değişikliğinden sonra görünüyor — Web sunucusu işlem durumunu, port bağlamalarını ve sunucudaki firewall kurallarını kontrol edin
• Hata yük altında aralıklı olarak görünüyor — Sunucudaki kaynak tükenmesini araştırın (dosya tanımlayıcıları, bellek, bağlantı sınırları)
• Hata yalnızca HTTPS’de görünüyor, HTTP’de değil — SSL sertifikası geçerliliğini ve TLS yapılandırmasını araştırın
• Hata DNS ayarları değiştirildikten sonra görüldü — DNS değişikliklerini geri alın ve önbelleği temizleyin; yeni çözümleyiciye ulaşılabilir olduğunu doğrulayın

SSS

1) ERR_CONNECTION_REFUSED ve ERR_CONNECTION_TIMED_OUT arasındaki fark nedir?

ERR_CONNECTION_REFUSED, sunucunun (veya bir güvenlik duvarının) aktif olarak bir TCP sıfırlama paketi göndererek bağlantıyı hemen reddettiği anlamına gelir. ERR_CONNECTION_TIMED_OUT, zaman aşımı süresi içinde yanıt alınmadığı anlamına gelir — paketler sessizce bırakılmıştır. Reddedilen bir bağlantı daha hızlı görünür ve aktif bir reddi gösterirken, zaman aşımı bir yönlendirme veya güvenlik duvarı DROP kuralını gösterir.

2) ERR_CONNECTION_REFUSED, süresi dolmuş bir SSL sertifikası tarafından neden olunabilir mi?

Dolaylı olarak, evet. Bazı sunucu konfigürasyonlarında, süresi dolmuş veya yanlış yapılandırılmış bir SSL sertifikası, web sunucusu işleminin başlangıçta başarısız olmasına veya TLS bağlantılarını işlerken çökmesine neden olur ve bu da port 443’te hiçbir dinleyicinin olmamasıyla sonuçlanır. Chrome daha sonra ERR_CONNECTION_REFUSED bildirir çünkü hiçbir şey dinlemiyor, temel nedeni bir sertifika sorunu olsa da.

3) ERR_CONNECTION_REFUSED neden yalnızca bir belirli web sitesinde görünür?

Hata tek bir etki alanıyla sınırlıysa, en olası nedenler şunlardır: hedef sunucunun web hizmeti çökmüştür, sunucunun güvenlik duvarı IP aralığınızı engellemektedir, etki alanının DNS kayıtları hiçbir hizmetin çalışmadığı eski bir IP adresine işaret etmektedir veya site kapatılmıştır. Nedeni belirlemek için farklı bir ağdan veya sunucudan curl -v https://thatdomain.com kullanın.

4) localhost’ta ERR_CONNECTION_REFUSED nasıl düzeltebilirim?

Uygulama sunucusu çalışmıyor veya istediğiniz porttan farklı bir porta bağlı. Linux/macOS’ta ss -tlnp veya Windows’ta netstat -ano | findstr :PORT ile neyin dinlendiğini doğrulayın. Uygulama sunucusu işlemini başlatın ve beklenen portta 0.0.0.0 veya 127.0.0.1‘e bağlı olduğundan emin olun.

5) DNS temizlemesi her zaman ERR_CONNECTION_REFUSED’yi düzeltir mi?

Yalnızca kök nedeni, hizmetin artık çalışmadığı bir IP adresine işaret eden eski bir DNS önbellek girişi olduğunda. Sunucu kapalıysa, güvenlik duvarı bağlantıyı engellemekteyse veya proxy yanlış yapılandırılmışsa, DNS temizlemesinin hiçbir etkisi olmayacaktır. DNS’in gerçekten sorun olup olmadığını doğrulamak için temizlemeden önce ve sonra dig veya nslookup kullanarak DNS çözümlemesini doğrulayın.