ERR_CONNECTION_REFUSED Hatası Nedir, Nasıl Düzeltilir?

Tarayıcıda ERR_CONNECTION_REFUSED gördüğünüzde aslında elinizde çok değerli bir bilgi vardır: sunucu makinesi ayaktadır, ağ üzerinden ona ulaşılabilmektedir, ama istediğiniz portta dinleyen bir servis yoktur ya da bir kural bağlantıyı açıkça geri çevirmiştir. "Bağlantı reddedildi" ifadesi bu yüzden kötü bir haber değil, iyi bir ipucudur — sorunun nerede olmadığını bile söyler. Sunucu tamamen kapalı olsaydı bu hatayı değil, zaman aşımı hatasını görürdünüz.

Türkçe kaynakların büyük kısmı bu hataya ziyaretçi gözüyle bakar ve modem yeniden başlatmayı, VPN kapatmayı, DNS değiştirmeyi önerir. Sunucusu bağlantıyı reddeden bir site sahibi için bunların hiçbiri işe yaramaz. Bu yazı sunucu tarafından yazılmıştır: önce "reddedildi" ile "zaman aşımı" arasındaki teknik farkı kuracağız, sonra systemctl, ss ve güvenlik duvarı komutlarıyla dört adımlık bir teşhis zinciri kuracağız, en sonda da SSH, MySQL ve panel portlarında aynı hatayı üreten klasik senaryoları tek tek çözeceğiz.

ERR_CONNECTION_REFUSED Ne Anlama Geliyor#

ERR_CONNECTION_REFUSED, TCP el sıkışmasının ilk adımında sunucudan RST (reset) paketi döndüğü anlamına gelir. Tarayıcınız hedef IP'nin 443 numaralı portuna SYN paketi gönderir; karşı taraf "bu portta dinleyen kimse yok" cevabını RST ile verir; tarayıcı bunu saniyenin altında öğrenir ve hatayı basar. Hatanın anında çıkması, saniyelerce beklemeden gelmesi bu yüzdendir.

Buradan çıkan üç kesin bilgi vardır:

1. DNS çözümlemesi başarılı olmuştur. Tarayıcı bir IP adresi bulabilmiştir, yoksa DNS_PROBE_FINISHED_NXDOMAIN veya ERR_NAME_NOT_RESOLVED görürdünüz.
2. Ağ yolu açıktır. Paketiniz hedefe ulaşmış ve cevap dönmüştür. Yolda kaybolsaydı zaman aşımı alırdınız.
3. Sorun, hedef makinede o porttadır. Ya orada dinleyen servis yoktur, ya servis çökmüştür, ya da bir kural bağlantıyı REJECT ile geri çevirmektedir.

Yani hata mesajı size "sunucuya ulaştım ama kapıyı çalınca içeriden 'burada kimse yok' cevabı geldi" diyor. Bundan sonraki iş, o kapının arkasına bakmaktır.

Reddedildi ile Zaman Aşımı Arasındaki Fark#

Bu ikisi aynı sorunun iki farklı görünümü değil, tamamen farklı iki durumdur ve karıştırıldıklarında saatler boşa gider. Fark, güvenlik duvarının paketi nasıl işlediğinden doğar:

Pratik kural: anında gelen hata "makine ayakta, kapı kapalı"; bekleyip gelen hata "cevap veren yok" demektir. Sayfa 30 saniye dönüp sonra hata veriyorsa bu yazı sizin sorununuz değildir, ERR_CONNECTION_TIMED_OUT hatası yazısına geçin. Bağlantı kurulduktan sonra ortada kesiliyorsa ERR_CONNECTION_RESET hatası yazısı doğru adrestir.

Bu ayrımı ölçmenin en hızlı yolu curl ile süreyi görmektir:

curl -v --connect-timeout 10 https://alanadiniz.com

Çıktı hemen Connection refused diyorsa RST almışsınızdır. On saniye sayıp Connection timed out diyorsa paketleriniz sessizce düşürülmüştür.

Ziyaretçi Tarafı mı, Sunucu Tarafı mı#

Bu ayrımı yapmak altmış saniye sürer ve yapmadan sunucuya dokunmayın. Sunucu tarafındaki bir sorun herkeste görülür; ziyaretçi tarafındaki sorun yalnızca bir cihazda veya bir ağda görülür.

1. Aynı adresi mobil veri üzerinden telefonunuzdan açın (ev/ofis ağını devre dışı bırakır).
2. Farklı bir tarayıcıda ve gizli sekmede deneyin (eklenti ve önbelleği devre dışı bırakır).
3. Komut satırından IP'ye doğrudan gidin:

curl -I -H "Host: alanadiniz.com" http://SUNUCU_IP_ADRESI

Üçü de aynı hatayı veriyorsa sorun sunucudadır; bir sonraki bölümden devam edin. Sadece sizin bilgisayarınızda oluyorsa yerel sebeplere bakmanız gerekir; bunları en aşağıdaki "Ziyaretçi tarafında yapılabilecekler" bölümünde topladım.

Bir uyarı: alan adınız Cloudflare gibi bir ara katmandan geçiyorsa (turuncu bulut açıksa) ziyaretçi sizin sunucunuza değil, ara katmana bağlanır. Bu durumda kaynak sunucu bağlantıyı reddettiğinde ziyaretçi ERR_CONNECTION_REFUSED değil, bir hata sayfası görür — ayrıntı için cloudflare 520 521 522 hataları yazısına bakın. Yani ERR_CONNECTION_REFUSED görüyorsanız, tarayıcı doğrudan sizin IP'nize bağlanmaya çalışıyor demektir.

Adım 1: Web Sunucusu Servisi Çalışıyor mu#

İlk kontrol her zaman servisin durumu olmalıdır, çünkü vakaların yarısından fazlası burada biter. Sunucunuza SSH ile bağlanın ve dağıtımınıza göre şu komutlardan uygun olanı çalıştırın:

systemctl status nginx
systemctl status apache2      # Debian/Ubuntu
systemctl status httpd        # RHEL/AlmaLinux/CloudLinux

Active: active (running) görüyorsanız servis ayaktadır, ikinci adıma geçin. Active: failed ya da inactive (dead) görüyorsanız suçluyu bulmuşsunuz demektir. Servisi başlatmadan önce neden durduğunu öğrenin:

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

En sık gördüğüm üç mesaj ve anlamları:

nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use)

Port 80'i başka bir süreç tutuyor. Çoğunlukla Apache ile Nginx aynı anda kurulu ve ikisi de 80'e bağlanmaya çalışıyor. Hangi sürecin tuttuğunu ikinci adımdaki ss komutuyla bulun.

nginx: [emerg] cannot load certificate "/etc/letsencrypt/live/alanadiniz.com/fullchain.pem"

Sertifika dosyası yok ya da okunamıyor. Genellikle sertifika yenilenirken silinmiş ya da alan adı yapılandırmadan kaldırılmış demektir; ssl otomatik yenileme yazısındaki kontroller bu durumu kalıcı olarak çözer.

nginx: [emerg] unknown directive "..." in /etc/nginx/sites-enabled/alanadiniz.conf:24

Yapılandırmada yazım hatası var. Servis yeniden başlatılana kadar eski yapılandırmayla çalışmaya devam eder; bu yüzden hata çoğu zaman siz dosyayı düzenledikten günler sonra, sunucu yeniden başlatıldığında ortaya çıkar.

Yapılandırmayı başlatmadan önce her zaman sınayın:

nginx -t
apachectl configtest

Sınama temizse servisi başlatın ve açılışta otomatik başlaması için etkinleştirin:

systemctl start nginx
systemctl enable nginx

enable adımını atlamak, sunucu yeniden başladığında aynı hatanın geri gelmesinin bir numaralı sebebidir. Servis birimlerinin nasıl çalıştığını systemd servis yönetimi yazısında ayrıntılı bulabilirsiniz.

Adım 2: Port Gerçekten Dinleniyor mu#

Servis "çalışıyor" görünse bile doğru adres ve portta dinlemiyor olabilir; bunu görmenin tek yolu dinleyen soketleri listelemektir.

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

Sağlıklı bir çıktı şuna benzer:

LISTEN 0 511 0.0.0.0:80   0.0.0.0:*  users:(("nginx",pid=812,fd=6))
LISTEN 0 511 [::]:443     [::]:*     users:(("nginx",pid=812,fd=7))

Şu çıktı ise sorunlu:

LISTEN 0 511 127.0.0.1:80  0.0.0.0:*  users:(("nginx",pid=812,fd=6))

Buradaki 127.0.0.1 kritik. Servis yalnızca kendi üzerinden erişilebilir durumda, dışarıdan gelen hiçbir bağlantıyı kabul etmez — sunucuda curl localhost çalışır ama tarayıcıdan ERR_CONNECTION_REFUSED gelir. Bu ayrımı yapmayan çok fazla saat harcanır. Düzeltmek için yapılandırmadaki dinleme adresini düzenleyin:

server {
    listen 80;
    listen [::]:80;
    server_name alanadiniz.com www.alanadiniz.com;
    root /var/www/alanadiniz.com;
}

ss çıktısında 443 satırı hiç yoksa HTTPS yapılandırması yüklenmemiştir; site http:// ile açılıp https:// ile reddediliyorsa teşhis budur. Soket listeleme komutlarının ayrıntısı için açık portları listeleme ss netstat yazısına bakabilirsiniz.

Portu başka bir sürecin kaptığından şüpheleniyorsanız:

ss -tlnp 'sport = :80'
fuser -v 80/tcp

Adım 3: Güvenlik Duvarı ve REJECT Kuralları#

Servis doğru portta dinliyorsa sıradaki şüpheli güvenlik duvarıdır ve burada aradığınız şey özellikle REJECT kurallarıdır. DROP kuralı zaman aşımı üretir, REJECT ise tam olarak bu yazının konusu olan "reddedildi" hatasını üretir.

UFW kullanıyorsanız:

ufw status verbose

Beklenen çıktıda 80 ve 443 satırları ALLOW IN olarak görünmelidir. Görünmüyorsa ekleyin:

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

Kural yönetiminin tamamı için ufw güvenlik duvarı yazısı elinizin altında olsun. Doğrudan iptables kullanıyorsanız kuralları sayaçlarıyla birlikte okuyun:

iptables -L INPUT -n -v --line-numbers

Şuna benzer bir satır arıyorsunuz:

5  1240  74400  REJECT  tcp  --  *  *  0.0.0.0/0  0.0.0.0/0  tcp dpt:443 reject-with icmp-port-unreachable

pkts sayacı (buradaki 1240) artıyorsa bu kural aktif olarak trafiğinizi kesiyor demektir. Numarasıyla silin:

iptables -D INPUT 5

Değişikliği kalıcı hâle getirmeyi unutmayın; aksi halde ilk yeniden başlatmada kural geri gelir. Kural mantığını tazelemek için iptables ile güvenlik duvarı yazısı iyi bir başvurudur.

Üçüncü bir katmanı da unutmayın: bulut sağlayıcıların panelindeki güvenlik grubu kuralları işletim sisteminin dışındadır ve ufw status çıktısında görünmez. Sunucu içinde her şey doğru görünüyorsa panelden gelen kuralları kontrol edin.

Adım 4: Doğru IP'ye mi Bağlanıyorsunuz#

Sunucu tarafında her şey doğruysa geriye tek ihtimal kalır: tarayıcınız başka bir makineye bağlanıyordur. Alan adının hangi IP'ye gittiğini doğrulayın:

dig +short alanadiniz.com
dig +short www.alanadiniz.com

Dönen IP, üzerinde çalıştığınız sunucunun IP'si değilse, DNS henüz güncellenmemiş ya da yanlış kayıt girilmiştir. Sunucunun kendi genel IP'sini şöyle görebilirsiniz:

ip -4 addr show scope global | grep inet

DNS tarafında kaydın nasıl okunacağını dig nslookup dns sorgulama yazısı ayrıntılandırıyor. Yeni taşınmış bir sitede yayılma süresi de devrede olabilir; propagasyon süresi dns yazısı bu bekleme penceresini açıklıyor.

Sunucu dışından port seviyesinde test için:

nc -zv alanadiniz.com 443
nmap -Pn -p 80,443,22 alanadiniz.com

nmap çıktısındaki closed durumu RST aldığınızı (reddedildi), filtered durumu ise paketin düşürüldüğünü (zaman aşımı) gösterir. Bu tek kelime, hangi yazıya devam edeceğinizi söyler. Tarama araçlarının kullanımı açık port taraması nmap yazısında.

Sık Karşılaşılan Senaryolar ve Çözümleri#

Aşağıdaki senaryolar, aynı hatanın web dışındaki servislerde nasıl göründüğünü ve ilk bakılacak yeri özetliyor:

SSH için: Varsayılan port değiştirilmişse bağlantıyı portla kurun ve gerekirse güvenlik duvarında o portu açın:

ssh -p 2222 kullanici@sunucu-ip
ufw allow 2222/tcp

Portu değiştirmeden önce yeni portu güvenlik duvarında açmayı unutmak, kendinizi sunucudan kilitlemenin klasik yoludur; ssh bağlantısı ve güvenliği yazısındaki sıralamaya uyun.

MySQL için: Uzaktan bağlantı reddediliyorsa çoğunlukla sunucu yalnızca yerel arayüzü dinliyordur. /etc/mysql/mysql.conf.d/mysqld.cnf içinde:

[mysqld]
bind-address = 0.0.0.0

Bunu yapmadan önce şunu bilin: veritabanını internete açmak ciddi bir güvenlik kararıdır. Çoğu durumda doğru çözüm bind adresini değiştirmek değil, bir SSH tüneli kurmaktır — bkz. ssh tüneli port yönlendirme ve remote mysql uzaktan bağlantı.

Fail2ban devreye girmiş olabilir: Sunucuya art arda başarısız bağlantı denemesi yaptıysanız IP'niz banlanmış olabilir. Farklı bir ağdan bağlanıp kontrol edin:

fail2ban-client status sshd
fail2ban-client set sshd unbanip 203.0.113.10

Ziyaretçi Tarafında Yapılabilecekler#

Hata yalnızca sizin cihazınızda görülüyorsa ve site başka ağlardan açılıyorsa, sorun yereldir ve şu sırayla ilerlenir. Bunların hiçbiri sunucusu bağlantı reddeden bir site sahibine yaramaz; ama tanı "yalnızca bende" ise doğru liste budur:

1. Yerel proxy ayarını kapatın. Windows'ta Ayarlar → Ağ ve İnternet → Proxy altındaki elle tanımlı proxy, kapalı bir yerel porta yönlendiriyorsa her site bu hatayı verir.
2. VPN veya güvenlik yazılımını geçici olarak kapatın. Bazı güvenlik paketleri kendi yerel proxy'sini araya sokar ve servisi çöktüğünde tüm trafiği reddeder.
3. DNS önbelleğini temizleyin. Site yeni taşındıysa eski IP'ye gidiyor olabilirsiniz: ipconfig /flushdns (Windows), sudo resolvectl flush-caches (Linux). Ayrıntı: dns önbellek temizleme.
4. Tarayıcı eklentilerini gizli sekmede devre dışı bırakarak sınayın. İçerik engelleyiciler bazı adresleri yerel olarak reddeder.
5. hosts dosyanızı kontrol edin. Geliştirme sırasında eklenmiş bir satır (127.0.0.1 alanadiniz.com) unutulduğunda, siteyi kendi bilgisayarınızdaki kapalı porta yönlendirirsiniz. Windows'ta C:\Windows\System32\drivers\etc\hosts, Linux/macOS'te /etc/hosts.

Beşinci madde, geliştiricilerin en sık düştüğü tuzaktır ve site başka herkeste açıldığı için teşhisi zordur.

Sıkça Sorulan Sorular#

ERR_CONNECTION_REFUSED sunucumun kapalı olduğu anlamına mı gelir#

Hayır, tam tersine sunucunun ayakta olduğunu gösterir. Bu hata, gönderdiğiniz TCP paketine karşı taraftan bir RST cevabı geldiği anlamına gelir; cevap verebilmesi için makinenin çalışıyor ve ağa bağlı olması gerekir. Makine tamamen kapalı olsaydı hiçbir cevap dönmez ve zaman aşımı hatası alırdınız. Yani sorun makinede değil, o portta dinleyen servistedir.

Reddedildi ile zaman aşımı arasındaki farkı nasıl anlarım#

En hızlı ayrım süredir: reddedildi hatası neredeyse anında, zaman aşımı ise onlarca saniye bekledikten sonra gelir. Kesin doğrulama için nmap -Pn -p 443 alanadiniz.com komutunu çalıştırın; closed sonucu reddedildiğinizi, filtered sonucu paketlerinizin sessizce düşürüldüğünü gösterir. Bu fark güvenlik duvarındaki REJECT ve DROP eylemlerinden doğar. Hangisiyle karşı karşıya olduğunuzu bilmek, doğru komutları çalıştırmanızı sağlar.

Sunucuda curl localhost çalışıyor ama site dışarıdan açılmıyor#

Bu, servisin yalnızca yerel arayüzü dinlediğinin klasik göstergesidir. ss -tlnp çıktısında dinleme adresi 127.0.0.1:80 şeklindeyse, sunucu kendi içinden gelen bağlantıları kabul eder ama dışarıdan gelenleri reddeder. Yapılandırmadaki dinleme satırını 0.0.0.0 veya tüm arayüzleri kapsayacak biçimde düzeltip servisi yeniden başlatmanız gerekir. İkinci olasılık güvenlik duvarının o portu REJECT ile kesmesidir; kural listesindeki paket sayaçları bunu doğrular.

Hatayı yalnızca ben görüyorsam ne yapmalıyım#

Önce mobil veri üzerinden telefonunuzla siteyi açarak sorunun ağınıza özgü olup olmadığını doğrulayın. Site orada açılıyorsa sırasıyla yerel proxy ayarını, VPN veya güvenlik yazılımını, DNS önbelleğini ve hosts dosyanızı kontrol edin. Geliştirme sırasında hosts dosyasına eklenip unutulan bir satır, siteyi kendi bilgisayarınızdaki kapalı bir porta yönlendirdiği için tam olarak bu hatayı üretir. Bu kontrolleri yapmadan sunucu yapılandırmasına dokunmayın.

Nginx yeniden başlamıyor ve port zaten kullanımda diyor#

Bu mesaj, 80 veya 443 numaralı portu başka bir sürecin tuttuğu anlamına gelir. ss -tlnp 'sport = :80' komutuyla portu tutan sürecin adını ve PID'sini görün; çoğu vakada aynı makinede hem Apache hem Nginx kuruludur ve ikisi de aynı porta bağlanmaya çalışmaktadır. Çözüm, kullanmadığınız servisi durdurup açılıştan kaldırmak ya da ikisini farklı portlarda çalıştırıp önüne bir ters vekil koymaktır. Durumu kalıcı düzeltmeden servisi zorla başlatmaya çalışmak aynı hatayı tekrar üretir.

Alan adı yeni taşındıysa bu hatayı görmek normal mi#

Evet, taşıma sırasında bu hata sık görülür ve sebebi genellikle DNS'in henüz eski IP'yi göstermesidir. Eski sunucuda servisler kapatıldığı için o IP'ye gelen istekler reddedilir ve tarayıcı ERR_CONNECTION_REFUSED verir. dig +short alanadiniz.com çıktısını yeni sunucunun IP'siyle karşılaştırarak bunu saniyeler içinde doğrulayabilirsiniz. Doğru yaklaşım, DNS tamamen yeni adrese oturana kadar eski sunucuyu kapatmamaktır.

Güvenlik duvarında kuralı sildim ama hata devam ediyor#

Bu durumda büyük olasılıkla birden fazla güvenlik katmanı vardır. İşletim sistemindeki ufw veya iptables kurallarının dışında, bulut sağlayıcınızın panelindeki güvenlik grubu ayrı bir filtre uygular ve sunucu içindeki komutlarda hiç görünmez. Ayrıca CSF gibi ek güvenlik duvarı yazılımları kendi kural setini yönetir ve ufw ile çakışabilir. Katmanları tek tek doğrulayın; sunucu içinden curl -I http://127.0.0.1 çalışıp dışarıdan çalışmıyorsa sorun kesinlikle bir filtreleme katmanındadır.

Kapanış#

ERR_CONNECTION_REFUSED hatası, doğru okunduğunda teşhisi en kolay ağ hatalarından biridir. Anında gelmesi size makinenin ayakta olduğunu, sorunun tek bir portta yoğunlaştığını söyler. Bundan sonrası dört adımlık sabit bir zincirdir: servis çalışıyor mu (systemctl status), doğru adres ve portta dinliyor mu (ss -tlnp), güvenlik duvarında REJECT kuralı var mı (ufw status, iptables -L -n -v), ve tarayıcı gerçekten sizin sunucunuza mı bağlanıyor (dig +short). Bu dördünü sırayla uyguladığınızda vakaların neredeyse tamamı çözülür; en sık suçlular ise yeniden başlatılmamış bir servis, 127.0.0.1 üzerinde kalmış bir dinleme adresi ve açılışta etkinleştirilmemiş bir birimdir.

Bu kontrolleri her seferinde elle yapmak yerine sunucunun kendini toparlamasını istiyorsanız, izleme ve otomatik yeniden başlatma kurmak doğru yatırımdır; yapılandırmayı kod hâline getirmek için ansible ile sunucu otomasyonu yazısı iyi bir başlangıçtır. Kendi sunucunuzu yönetiyor ve bu tür teşhisleri kendiniz yapmak istiyorsanız kaynakları size ayrılmış bir VDS sunucu tam kontrol verir; servis izleme, güvenlik duvarı düzeni ve güncellemeleri devretmek isterseniz sunucu yönetimi hizmeti bu yükü üstlenir. Sunucu yönetmek yerine yalnızca sitenizle ilgilenmek istiyorsanız, servislerin ayakta tutulması sağlayıcı tarafında olan bir paylaşımlı hosting paketi çoğu proje için yeterlidir; taşınma sırasında kesinti yaşamamak içinse site taşıma hizmeti DNS geçişini planlı biçimde yürütür.