ERR_CONNECTION_REFUSED: Ne Anlama Gelir, Nasıl Düzeltilir

ERR_CONNECTION_REFUSED ne anlama gelir

Bir TCP bağlantısı el sıkışmayla başlar: istemci bir SYN paketi gönderir, o porta bağlı bir süreç varsa sunucu SYN-ACK ile yanıt verir. TCP belirtimi olan RFC 9293 diğer durumu da ele alır: hiçbir bağlantıya ait olmayan bir segment karşılığında bir reset alır ve "a SYN segment that does not match an existing connection is rejected by this means" (var olan bir bağlantıyla eşleşmeyen bir SYN segmenti bu yolla reddedilir). Chrome'un ERR_CONNECTION_REFUSED olarak bildirdiği şey bu RST'dir. Aynı RFC, bir bağlantı denemesinin hızlı başarısız olabileceği diğer yol olarak ICMP Port Unreachable mesajını da sayar; bazı güvenlik duvarları RST yerine bununla reddeder ve Linux istemcileri bunu da reddedildi olarak bildirir.

RST, uygulama kodundan değil çekirdeğin TCP yığınından gelir; bu yüzden milisaniyeler içinde ulaşır. Ayrıca o IP adresinde bir şeyin ayakta olduğunu ve yanıt verdiğini gösterir: ya portuna hiçbir şey bağlanmamış ana makinenin kendisi ya da önündeki ve portu reddeden bir güvenlik duvarı. Sunucunun elektriğine ya da ağ bağlantısına bakmadan önce porta ve arkasındaki sürece bakın.

Hata nasıl görünür

Chrome "This site can't be reached" başlığını, ardından "example.com refused to connect" (example.com bağlanmayı reddetti) metnini ve ERR_CONNECTION_REFUSED kodunu gösterir. Firefox "Unable to connect" bildirir ve o adresteki sunucuyla bağlantı kurulamadığını söyler. Komut satırı daha kesin bir tablo verir:

curl -v https://example.com:8443/
* Trying 203.0.113.10:8443...
* connect to 203.0.113.10 port 8443 failed: Connection refused
* Failed to connect to example.com port 8443 after 2 ms: Connection refused
curl: (7) Failed to connect to example.com port 8443 after 2 ms: Connection refused

Çıktı, curl'ün denediği tam IP adresini ve portu verir ve reddi 2 ms sonra bildirir; bu, zaman aşımı olamayacak kadar hızlıdır. 7 çıkış kodu, curl'ün bir adres bulduğu ama ona bağlanamadığı anlamına gelir. nc -zv example.com 8443 aynı "Connection refused" çıktısını verir; Windows'ta PowerShell'deki Test-NetConnection example.com -Port 8443 ise TcpTestSucceeded : False gösterir.

ERR_CONNECTION_REFUSED 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_REFUSED'a ne sebep olur

• O portta dinleyen hiçbir şey yok. Portun sahibi olması gereken web sunucusu, uygulama ya da proxy çalışmıyor veya başka bir port için yapılandırılmış.
• Hizmet çöktü ya da yeniden başlıyor. Sonlanan, çok bellek kullandığı için öldürülen veya bir dağıtım sırasında yeniden başlayan bir süreç portu, bazen yalnızca birkaç saniyeliğine, boşta bırakır.
• Hizmet yanlış adreste dinliyor. 127.0.0.1 adresine bağlı bir sunucu makinenin kendisinden gelen bağlantıları kabul eder, genel adresine gelen her şeyi reddeder.
• Bir güvenlik duvarı kuralı portu reddediyor. REJECT kuralı bir RST ya da ICMP hatasıyla yanıt verir; bu, dışarıdan bakıldığında kapalı bir portla aynıdır. DROP kuralı ise zaman aşımı üretir.
• URL yanlış port ya da şema kullanıyor. Bir yazım hatası, port değişikliğinden önceki eski bir yer imi veya yalnızca 80. portu dinleyen bir sunucuda https:// adresi.
• Yerel bir geliştirme sunucusu çalışmıyor. localhost:3000 adresinin reddedilmesi neredeyse her zaman geliştirme sunucusunun durdurulduğu, açılışta çöktüğü ya da bu oturumda hiç başlatılmadığı anlamına gelir.
• Bir proxy veya VPN yanlış yapılandırılmış. Kapalı bir arka uca yönlendirilmiş bir proxy ya da hiçbir şeyin hizmet vermediği bir porta istek gönderen bir VPN istemcisi bağlantıyı kendi adına reddeder.
• Bir konteyner veya Kubernetes Service yanlış portu gösteriyor. Yayımlanan ya da hedef port, uygulamanın bağlandığı porttan farklıdır; süreç çalışır ve sağlıklı kalır, ama ona yapılan her bağlantı reddedilir.

Sunucu tarafı nedenler ve yapılandırma

Sunucuda ss -ltnp ile başlayın. Dinleyen her TCP soketini adresi, portu ve sahibi olan süreçle listeler; böylece aşağıdaki durumlardan hangisinde olduğunuzu gösterir:

sudo ss -ltnp
State   Recv-Q  Send-Q  Local Address:Port  Peer Address:Port  Process
LISTEN  0       511     127.0.0.1:3000      0.0.0.0:*          users:(("node",pid=812,fd=19))
LISTEN  0       511     0.0.0.0:80          0.0.0.0:*          users:(("nginx",pid=640,fd=6))

Burada nginx 80. portta her IPv4 adresinden bağlantı kabul ederken, 3000. porttaki uygulama yalnızca makinenin kendisinden gelenleri kabul eder. Listede görünmeyen bir portu hiçbir şey dinlemiyor demektir.

nginx ve Apache listen yönergeleri

nginx'te listen 443 ssl; tüm adreslerde IPv4 bağlantılarını kabul eder; IPv6 için ayrı bir satır gerekir. Alan adının bir AAAA kaydı varsa ve sunucu yalnızca IPv4'te dinliyorsa, IPv4 çalışırken IPv6 bağlantıları reddedilir. http:// üzerinden açılıp https:// üzerinden reddedilen bir sitede genellikle 443'te hiç dinleyici yoktur:

server {
    listen 443 ssl;
    listen [::]:443 ssl;
    server_name example.com;
    ssl_certificate     /etc/ssl/example.com/fullchain.pem;
    ssl_certificate_key /etc/ssl/example.com/privkey.pem;
}

Değişiklikleri sudo nginx -t && sudo systemctl reload nginx ile uygulayın. Apache'de her port için <VirtualHost *:443> bloğuna ek olarak bir Listen satırı gerekir (örneğin ports.conf ya da httpd.conf içinde Listen 443); eşleşen bir Listen satırı olmayan sanal ana makine hiçbir zaman soket almaz. Yeniden başlatmadan önce sudo apachectl configtest ile kontrol edin.

Node.js ve geliştirme sunucuları

Kimin bağlanabileceğini host argümanı belirler. Argümanı atlamak, IPv6 varsa Node.js'in belirtilmemiş IPv6 adresi olan :: üzerinde, yoksa 0.0.0.0 üzerinde dinlemesini sağlar:

// Only connections from the same machine
server.listen(3000, '127.0.0.1');

// Connections on every IPv4 address
server.listen(3000, '0.0.0.0');

Birçok geliştirme sunucusu varsayılan olarak yalnızca localhost'a bağlanır; Flask'ın flask run komutu ve Vite bunlardandır. Aynı Wi-Fi ağındaki bir telefon veya başka bir bilgisayar, onları flask run --host=0.0.0.0 ya da vite --host ile başlatana kadar reddedilir.

Docker port yayımlama

-p host:container bir ana makine portunu bir konteyner portuna eşler. Konteyner tarafı, uygulamanın konteyner içinde dinlediği port olmalıdır ve uygulama orada 127.0.0.1 değil 0.0.0.0 üzerinde dinlemelidir:

# Host port 8080 on all host addresses -> container port 80
docker run -d --name web -p 8080:80 nginx

# Published on the host's loopback only: other machines are refused
docker run -d --name web-local -p 127.0.0.1:8080:80 nginx

# Show the ports a running container publishes
docker port web

Compose'ta aynı eşleme ports: ["8080:80"] biçimindedir. Konteyner tarafı ya da içerideki bağlama adresi yanlış olduğunda dış istemciler genellikle reddedilir; Docker ana makinesinin kendisindeki curl ise çoğu zaman bunun yerine Connection reset by peer veya Empty reply from server bildirir, çünkü Docker'ın proxy'si yerel bağlantıyı kabul eder ve ancak sonra konteynere ulaşamaz.

Kubernetes Service'leri

Bir Service'in port değeri çağıranların bağlandığı porttur; targetPort ise pod içindeki sürecin dinlediği port olmalıdır. Pod'un containerPort alanı, targetPort ona adıyla başvurmadıkça çoğunlukla bilgilendiricidir:

apiVersion: v1
kind: Service
metadata:
  name: web
spec:
  selector:
    app: web
  ports:
    - port: 80
      targetPort: 8080

Service'in arkasındaki hiçbir pod hazır değilse (seçici hiçbir şeyle eşleşmiyor ya da her pod readiness probe'unda başarısız oluyor), kube-proxy varsayılan iptables modunda Service'e gelen bağlantıları reddeder ve çağıranlar bir ret görür. Bir ingress controller'ın arkasında aynı durum genellikle 503'e dönüşür. kubectl get endpointslices -l kubernetes.io/service-name=web hazır uç noktaların olup olmadığını, kubectl describe pod -l app=web ise başarısız probe'ları gösterir.

Güvenlik duvarları

Ana makine güvenlik duvarları reddedebilir ya da düşürebilir ve aradaki fark ziyaretçilerin hangi hatayı alacağını belirler. ufw'de deny paketleri düşürür (istemcide zaman aşımı olur), reject ise hemen yanıt verir (istemci reddedilir):

sudo ufw status verbose
sudo ufw allow 443/tcp

# iptables: rules with packet counters; watch REJECT lines while you retry
sudo iptables -L INPUT -n -v --line-numbers

# nftables
sudo nft list ruleset | grep -n reject

Her yeniden denemenizde paket sayacı artan bir REJECT kuralı, sizi reddeden kuraldır.

Ters proxy'ler ve PHP-FPM

Ret, bir ters proxy ile arka ucu arasında gerçekleştiğinde ziyaretçi ERR_CONNECTION_REFUSED'ı hiç görmez. nginx reddi günlüğe yazar ve tarayıcıya bunun yerine bir 502 Bad Gateway döndürür:

2026/10/13 09:14:02 [error] 640#640: *1532 connect() failed (111: Connection refused) while connecting to upstream, client: 198.51.100.7, server: example.com, request: "GET / HTTP/1.1", upstream: "http://127.0.0.1:3000/", host: "example.com"

PHP'de aynı satır genellikle, PHP-FPM havuzu bir Unix soketinde dinlerken (listen = /run/php/php8.3-fpm.sock) nginx'te fastcgi_pass 127.0.0.1:9000; yazılı olduğu ya da PHP-FPM'in çalışmadığı anlamına gelir. İki tarafın da aynı adresi göstermesini sağlayın.

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

Aynı anda birçok konumdan yapılan kontroller genellikle şu örüntülerden birine uyar:

• Her konumdan, anında reddediliyor. Hizmet kapalı, yanlış adrese bağlı ya da sunucudaki bir REJECT kuralı herkesi kapsıyor. ss -ltnp ile başlayın.
• Bazı konumlardan reddediliyor, diğerlerinden kabul ediliyor. Kontrol noktaları farklı makinelere ulaştı ya da farklı kurallarla karşılaştı: birkaç A kaydından biri hizmetin olmadığı bir sunucuyu gösteriyor, bir güvenlik duvarı kuralı belirli kaynak aralıklarını reddediyor ya da fail2ban gibi bir yasak listesi bu adresleri reddediyor.
• Her yerde kabul ediliyor, yalnızca sizin ağınız hariç. Ret yerel: cihazınızdaki bir proxy veya VPN, o portu reddeden bir şirket güvenlik duvarı ya da bir yönlendirici kuralı.
• 80. port kabul ediliyor, 443. port reddediliyor. Sunucuda HTTPS dinleyicisi yok ve her https:// bağlantısı ya da HSTS yükseltmesi kapalı porta çarpıyor.
• Bazı kontroller reddediliyor, bazıları zaman aşımına uğruyor. Birden fazla IP adresi veya kural söz konusu; her kontrol noktasının bağlandığı IP adresini karşılaştırın.

Port denetleyicisi, girdiğiniz ana makine ve porta birçok konumdan bir TCP bağlantısı açar ve her biri için bağlantının kabul edilip edilmediğini, reddedilip reddedilmediğini ya da zaman aşımına uğrayıp uğramadığını bildirir.

ERR_CONNECTION_REFUSED nasıl düzeltilir

Ziyaretçiyseniz

1. URL'yi ve portu doğrulayın. Bir yazım hatası, eski bir yer imi ya da sitenin artık kullanmadığı bir portu hâlâ gösteren bir bağlantı olup olmadığına bakın.
2. Bir proxy olup olmadığını kontrol edin. Windows'ta Ayarlar > Ağ ve İnternet > Proxy bölümünü açın. macOS'ta scutil --proxy komutunu çalıştırın veya ağ bağlantınızın proxy ayarlarını açın. Chrome'da chrome://net-internals/#proxy tarayıcının kullandığı proxy'yi gösterir.
3. VPN'inizi kapatın ve yeniden yükleyin. Site bundan sonra açılıyorsa neden VPN yapılandırmasıdır.
4. Başka bir ağ deneyin; örneğin Wi-Fi yerine mobil veri. Böylece yerel bir güvenlik duvarı ya da yönlendirici kuralı elenir.
5. Bir dakika bekleyip yeniden deneyin. Site sahibi dağıtımın ortasındaysa ya da bir hizmeti yeniden başlatıyorsa port yalnızca birkaç saniye boşta kalmış olabilir.

Reddedilen adres localhost ise

1. Portu dinleyen bir şey olup olmadığına bakın. macOS veya Linux'ta lsof -nP -iTCP:3000 -sTCP:LISTEN, Windows'ta netstat -ano | findstr :3000 ya da PowerShell'de Get-NetTCPConnection -LocalPort 3000 -State Listen çalıştırın.
2. Sunucuyu başlatın ve çıktısının ilk satırlarını okuyun. Açılışta çöken bir geliştirme sunucusu (bir sözdizimi hatası, eksik bir ortam değişkeni, zaten kullanımda olan bir port) nedenini orada yazar ve sonra çıkar.
3. Adres ailesini eşleştirin. Hata ::1 adresini anıyorsa istemci IPv6 loopback'i denemiş, sunucu ise yalnızca 127.0.0.1 üzerinde dinliyordur. İstemcide http://127.0.0.1:3000 kullanın ya da sunucunun ikisinde de dinlemesini sağlayın (Node.js'te host argümanını atlamak genellikle bunu yapar).

Siteyi siz işletiyorsanız

1. Sürecin çalıştığını ve beklenen porta bağlı olduğunu doğrulayın:

   sudo ss -ltnp | grep ':443'

   Boş bir sonuç, hiçbir şeyin dinlemediği anlamına gelir; hizmeti başlatın veya yapılandırılmış portunu düzeltin.
2. Hizmet durumunu ve günlükleri kontrol edin:

   systemctl status nginx
   journalctl -u nginx -n 50 --no-pager

   Çöken ya da başarısız olan bir birim burada, çoğunlukla çıkış nedeniyle birlikte görünür.
3. Bağlama adresini kontrol edin. ss çıktısındaki 127.0.0.1:443, dış istemcilerin reddedildiği anlamına gelir; 0.0.0.0 ve [::] üzerinde ya da genel adreste dinleyin.
4. REJECT kurallarını ve port eşlemelerini yukarıdaki güvenlik duvarı, Docker ve Kubernetes komutlarıyla kontrol edin.
5. Yeniden başlatın ve dışarıdan test edin. Portun ss -ltnp çıktısında göründüğünü ve başka bir ağdan yapılan bağlantının başarılı olduğunu doğrulayın.

ERR_CONNECTION_REFUSED nasıl önlenir

Çalışmayan bir süreç kendi arızasını bildiremez; bu yüzden çöken bir hizmet veya yanlışlıkla kalmış bir REJECT kuralı çoğu zaman ilk olarak ziyaretçilerin tarayıcılarında reddedilen bağlantılar olarak görünür. Port izleme, bir ziyaretçinin yapacağı gibi, ağın dışından belirli aralıklarla porta bağlanır ve bir kontrol başarısız olduğunda e-posta, SMS, sesli arama, Slack, Telegram ve diğer kanallarla uyarı gönderir. 158 şehirdeki 300'den fazla kontrol noktasından yapılan kontrollerle, yalnızca tek bir bölgeyi veya birkaç sunucudan yalnızca birini etkileyen bir ret de ortaya çıkar.

Sık sorulan sorular

ERR_CONNECTION_REFUSED, bir güvenlik duvarının beni engellemesiyle aynı şey mi?

Olabilir. Bir güvenlik duvarı REJECT kuralı, kapalı bir portla aynı hızlı reddi üretir; bu yüzden tarayıcı ikisini ayırt edemez. DROP kuralı ise bunun yerine zaman aşımı üretir.

Bu neden yalnızca localhost'ta oluyor?

Neredeyse her zaman yerel geliştirme sunucusunun o terminalde çalışmadığı, durdurulduğu ya da bir kod veya yapılandırma hatası yüzünden açılışta çöktüğü için. Genellikle başlattığınız terminalde bir hata mesajı olup olmadığına bakın, sonra portun sahibi olan süreci lsof veya netstat ile kontrol edin.

Neden "connect ECONNREFUSED ::1" alıyorum?

Node.js 17'den beri DNS sorguları adresleri sistemin verdiği sırayla döndürür ve birçok sistemde localhost önce IPv6 adresi ::1'e çözülür. Sunucu yalnızca 127.0.0.1 üzerinde dinlerken ::1 adresini deneyen bir istemci reddedilir. İstemciyi 127.0.0.1 adresine yönlendirin ya da sunucunun :: üzerinde de dinlemesini sağlayın.

Bir VPN ERR_CONNECTION_REFUSED'a neden olabilir mi?

Evet. Trafiği bir proxy veya ağ geçidi üzerinden yönlendiren bir VPN, hedef sunucu sağlıklı olsa bile kendi arka ucu kapalıysa ağ geçidi adına bağlantıları reddedebilir.

ERR_CONNECTION_REFUSED, web sitesinin herkes için kapalı olduğu anlamına mı gelir?

Zorunlu olarak değil. Bu sonuca varmadan önce ikinci bir ağdan test edin ya da birden fazla konumdan bir kontrol çalıştırın. Yanlış yapılandırılmış tek bir güvenlik duvarı kuralı veya yerel bir VPN, site herkes için çalışırken aynı hatayı üretebilir.

curl http:// üzerinden çalışırken tarayıcı neden reddedildi gösteriyor?

Tarayıcı 443. porta bağlanıyor olabilir. Site daha önce bir HSTS başlığı gönderdiyse Chrome bağlanmadan önce http:// adresini https:// olarak yeniden yazar; bu yüzden 80. port yanıt verse bile HTTPS dinleyicisi olmayan bir sunucu reddedilir. chrome://net-internals/#hsts bir alan adının HSTS girdisi olup olmadığını gösterir.

Aşırı yüklenmiş bir sunucu bağlantıları reddedebilir mi?

Linux'ta genellikle hayır. Dinleyen bir soketin kuyruğu dolduğunda çekirdek, varsayılan olarak yeni bağlantı denemelerini sıfırlamak yerine düşürür (tcp_abort_on_overflow ayarı kapalıdır); bu yüzden aşırı yüklenmiş bir sunucu ret yerine yavaş bağlantılar ve zaman aşımları üretir.

Reddedilme ile sıfırlanma arasındaki fark nedir?

Reddedilme, hedefin el sıkışmayı reddettiği, dolayısıyla hiçbir bağlantının var olmadığı anlamına gelir. Sıfırlanma ise bir bağlantının kurulduğu ve sonra yarı yolda sunucu, bir proxy ya da yoldaki başka bir şey tarafından yıkıldığı anlamına gelir.

Hangi sürecin dinliyor olması gerektiğini nasıl bulurum?

Uygulamanın yapılandırması ve açılış günlüğü, bağlandığı portu söyler. Bu port URL'deki porttan farklıysa ikisinden birini değiştirerek aynı olmalarını sağlayın, sonra ss -ltnp ile doğrulayın.

Kaynaklar ve ek okumalar

• Chromium net error list: CONNECTION_REFUSED (-102) ve yukarıdaki tablodaki diğer kodların tanımları.
• RFC 9293, Transmission Control Protocol: TCP'nin ne zaman reset gönderdiğini anlatan bölüm 3.5.2 ve bir bağlantı denemesinin nasıl başarısız olduğunu anlatan bölüm 3.8.3.
• Docker: port publishing and mapping: -p sözdizimi ve yalnızca localhost'ta yayımlama.
• Kubernetes: Service: port ve targetPort değerlerinin trafiği pod'lara nasıl yönlendirdiği.