ERR_CONNECTION_REFUSED Hatası: Port ve Güvenlik Duvarı Engelleri

ERR_CONNECTION_REFUSED, istemcinin hedef sunucuya bağlantı kurmaya çalıştığı ancak bağlantının kabul edilmediği durumlarda tarayıcıda görülebilen bir bağlantı hatasıdır. Web sitesinin 80 veya 443 portunda servis vermemesi, uygulamanın durması, yanlış port kullanılması, servisin yalnızca 127.0.0.1 üzerinde dinlemesi veya güvenlik kurallarının erişimi engellemesi soruna yol açabilir.

Bu nedenle hata yalnızca “site çalışmıyor” şeklinde değerlendirilmemelidir. Sorunun hangi katmanda oluştuğunu belirlemek gerekir.

ERR_CONNECTION_REFUSED Hatası Nedir?

Bir web sitesine erişirken tarayıcı yalnızca alan adını açmaz. Basitleştirilmiş biçimde süreç şu şekilde ilerler:

Alan adı → DNS çözümlemesi → IP adresi → hedef port → TCP bağlantısı → web sunucusu/uygulama → HTTP(S) yanıtı

Örneğin:

https://example.com
        │
        ├── DNS → 203.0.113.10
        │
        └── TCP → 203.0.113.10:443

https://example.com
        │
        ├── DNS → 203.0.113.10
        │
        └── TCP → 203.0.113.10:443

DNS doğru IP adresini döndürse bile 443/TCP üzerinde bağlantıyı kabul eden bir servis yoksa HTTPS bağlantısı kurulamaz.

Bu ayrım önemlidir. ERR_CONNECTION_REFUSED her zaman DNS problemi anlamına gelmez. DNS çözümlemesi başarılı olmuş ancak sonraki bağlantı aşaması başarısız olmuş olabilir.

ERR_CONNECTION_REFUSED Neden Olur?

Hatanın kesin nedeni altyapıya göre değişse de sunucu tarafında öncelikle servis, port, bind adresi ve güvenlik kuralları incelenmelidir.

Web Sunucusu veya Uygulama Çalışmıyor

İlk kontrol edilmesi gereken noktalardan biri ilgili servisin gerçekten çalışıp çalışmadığıdır.

NGINX için:

sudo systemctl status nginx

sudo systemctl status nginx

Apache’nin servis adı Debian/Ubuntu sistemlerinde genellikle:

sudo systemctl status apache2

sudo systemctl status apache2

RHEL türevlerinde ise genellikle:

sudo systemctl status httpd

sudo systemctl status httpd

Servis durmuşsa nedenini anlamadan sürekli yeniden başlatmak yerine logları incelemek daha doğru bir yaklaşımdır.

Örneğin:

sudo journalctl -u nginx --since "30 minutes ago"

sudo journalctl -u nginx --since "30 minutes ago"

NGINX yapılandırmasını ayrıca şu komutla doğrulayabilirsiniz:

sudo nginx -t

sudo nginx -t

Bir yapılandırma hatası servisin başlamasını engelliyorsa yalnızca firewall üzerinde port açmak problemi çözmez.

Yanlış Porta Bağlantı Kuruluyor

HTTP’nin standart portu TCP 80, HTTPS’in standart portu ise TCP 443’tür. Ancak Node.js, Python, Java, yönetim paneli veya özel web uygulamaları 3000, 5000, 8000, 8080 gibi farklı portlarda çalışabilir.

Örneğin uygulama 8080 üzerinde çalışırken kullanıcı doğrudan:

http://sunucu-ip

http://sunucu-ip

adresini açarsa istemci varsayılan olarak 80 numaralı porta yönelir.

Doğru test:

http://sunucu-ip:8080

http://sunucu-ip:8080

olabilir.

Ancak uygulamanın gerçekten hangi portu kullandığı mutlaka sunucu üzerinden doğrulanmalıdır.

Servis Yalnızca Localhost Üzerinde Dinliyor

En sık gözden kaçan durumlardan biri budur.

Bir uygulama şu adreste çalışıyor olabilir:

127.0.0.1:3000

127.0.0.1:3000

Bu durumda aynı sunucudan:

curl http://127.0.0.1:3000

curl http://127.0.0.1:3000

başarılı olabilir.

Fakat dışarıdaki bir istemci:

http://SUNUCU_IP:3000

http://SUNUCU_IP:3000

üzerinden uygulamaya doğrudan erişemeyebilir.

Linux üzerinde dinleme adreslerini görmek için:

sudo ss -lntp

sudo ss -lntp

Belirli bir portu kontrol etmek için:

sudo ss -lntp | grep ':3000'

sudo ss -lntp | grep ':3000'

Çıktıda şu iki yapı aynı anlama gelmez:

127.0.0.1:3000

127.0.0.1:3000

ve

0.0.0.0:3000

0.0.0.0:3000

İlki IPv4 localhost arayüzüyle sınırlı bir dinlemeyi, ikincisi ise IPv4 tarafındaki tüm yerel arayüzlerde dinlemeyi ifade eder.

Burada uygulamayı doğrudan internete açmak her zaman doğru çözüm değildir. Örneğin Node.js uygulamasını localhost üzerinde tutup NGINX’i 443 portundan reverse proxy olarak kullanmak güvenlik ve mimari açısından daha uygun olabilir.

Güvenlik Duvarı Portu Engelliyor

Sunucudaki servis doğru portta çalışıyor olsa bile güvenlik duvarı dış bağlantıları engelleyebilir.

Burada kritik ayrım şudur:

Servisin portu dinlemesi ile portun internetten erişilebilir olması aynı şey değildir.

Örneğin:

ss -lntp

ss -lntp

çıktısında 0.0.0.0:8080 görülmesi uygulamanın yerel sistemde portu dinlediğini gösterir. Fakat UFW, firewalld veya altyapının ağ güvenlik politikası 8080/TCP trafiğini engelliyorsa istemci yine bağlantı kuramaz.

NAT veya Ağ Güvenlik Kuralları Erişimi Engelliyor

Sunucu üzerinde firewall kuralı doğru olsa bile sorun daha üst bir ağ katmanında bulunabilir.

Özellikle sanal sunucu ve bulut mimarilerinde şu katmanlar ayrı ayrı değerlendirilmelidir:

İnternet
   │
   ▼
Ağ / sağlayıcı güvenlik kuralı
   │
   ▼
NAT / yönlendirme
   │
   ▼
Sunucu firewall
   │
   ▼
Dinlenen TCP portu
   │
   ▼
Uygulama

İnternet
   │
   ▼
Ağ / sağlayıcı güvenlik kuralı
   │
   ▼
NAT / yönlendirme
   │
   ▼
Sunucu firewall
   │
   ▼
Dinlenen TCP portu
   │
   ▼
Uygulama

Bir portu yalnızca işletim sistemi firewall’ında açmak, diğer katmanlardaki engelleri otomatik olarak kaldırmaz.

ERR_CONNECTION_REFUSED Hatasının Kaynağı Nasıl Bulunur?

Rastgele firewall kuralları eklemek yerine bağlantı zincirini sırayla test etmek daha güvenli ve hızlıdır.

1. DNS ve IP Adresini Kontrol Edin

Öncelikle alan adının hangi IP adresine çözümlendiğini kontrol edin.

Linux/macOS:

dig example.com

dig example.com

veya:

nslookup example.com

nslookup example.com

Windows:

Resolve-DnsName example.com

Resolve-DnsName example.com

Alan adı eski veya yanlış IP adresine gidiyorsa doğru sunucudaki firewall ayarlarını değiştirmenin bir faydası olmayacaktır.

2. Port Erişimini Test Edin

Linux/macOS sistemlerden TCP bağlantısı test edilebilir:

nc -vz example.com 443

nc -vz example.com 443

Windows PowerShell üzerinde:

Test-NetConnection example.com -Port 443

Test-NetConnection example.com -Port 443

HTTPS servisini uygulama seviyesinde test etmek için:

curl -v https://example.com/

curl -v https://example.com/

kullanılabilir.

Bu testler farklı katmanlar hakkında bilgi verir. curl HTTP/HTTPS seviyesinde daha fazla ayrıntı sağlarken nc veya Test-NetConnection doğrudan TCP portuna erişimi değerlendirmede kullanışlıdır.

3. Sunucuda Dinlenen Portları Kontrol Edin

Linux:

sudo ss -lntp

sudo ss -lntp

Örneğin yalnızca 443 portu:

sudo ss -lntp | grep ':443'

sudo ss -lntp | grep ':443'

Burada hiçbir sonuç çıkmıyorsa öncelikle firewall yerine ilgili servisin neden 443 portunda dinlemediği araştırılmalıdır.

Bir web sunucusu 443’te dinlemiyorsa güvenlik duvarına 443 allow kuralı eklemek tek başına web sitesini erişilebilir hale getirmez.

4. Web Servisinin Durumunu Kontrol Edin

NGINX:

sudo systemctl status nginx

sudo systemctl status nginx

Apache:

sudo systemctl status apache2

sudo systemctl status apache2

IIS kullanılan Windows Server sistemlerinde PowerShell üzerinden örneğin:

Get-Service W3SVC

Get-Service W3SVC

ile World Wide Web Publishing Service durumu kontrol edilebilir.

Uygulamanın servis yöneticisi farklıysa ilgili process veya service ayrıca incelenmelidir.

Linux Sunucuda Firewall ve Port Kontrolü

Linux dağıtımına göre kullanılan güvenlik duvarı yönetim aracı değişebilir. Bir sistemde UFW kullanılırken diğerinde firewalld veya doğrudan nftables kuralları bulunabilir.

UFW Kurallarını Kontrol Etme

UFW durumunu görüntülemek için:

sudo ufw status verbose

sudo ufw status verbose

Kuralları numaralarıyla görmek için:

sudo ufw status numbered

sudo ufw status numbered

Örneğin bir web sunucusunda TCP 80 ve 443 portlarına gerçekten ihtiyaç varsa:

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

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

UFW belirli port ve protokoller için allow ve deny kuralları tanımlamayı destekler.

Güvenlik uyarısı: Bir portu yalnızca hata ortadan kalksın diye internete açmayın. Portun hangi servise ait olduğunu ve erişimin gerçekten herkese açık olması gerekip gerekmediğini doğrulayın.

Örneğin yönetim amaçlı özel bir servis yalnızca belirli bir IP adresinden erişilecekse daha dar bir kural tercih edilebilir:

sudo ufw allow from 203.0.113.25 to any port 8080 proto tcp

sudo ufw allow from 203.0.113.25 to any port 8080 proto tcp

Buradaki 203.0.113.25 yalnızca örnek IP adresidir; gerçek yetkili kaynak adresiyle değiştirilmelidir.

firewalld Kontrolü

firewalld kullanılan bir sistemde aktif yapılandırmayı görmek için:

sudo firewall-cmd --get-active-zones

sudo firewall-cmd --get-active-zones

Ardından ilgili zone için kuralları inceleyebilirsiniz:

sudo firewall-cmd --zone=public --list-all

sudo firewall-cmd --zone=public --list-all

Örneğin 443/TCP’nin kalıcı olarak açılması gerekiyorsa:

sudo firewall-cmd --zone=public --permanent --add-port=443/tcp
sudo firewall-cmd --reload

sudo firewall-cmd --zone=public --permanent --add-port=443/tcp
sudo firewall-cmd --reload

Ancak doğru zone’un public olduğunu varsaymayın. Önce ilgili ağ arayüzünün hangi zone’a bağlı olduğunu kontrol edin.

Windows Server’da Port ve Firewall Kontrolü

Windows Server’da öncelikle hedef portun dinlenip dinlenmediğini kontrol edebilirsiniz:

Get-NetTCPConnection -LocalPort 443 -State Listen

Get-NetTCPConnection -LocalPort 443 -State Listen

Belirli bir uzak sunucudaki portu test etmek için:

Test-NetConnection example.com -Port 443

Test-NetConnection example.com -Port 443

Gerekli olduğu doğrulanan bir TCP portu için Windows Defender Firewall kuralı PowerShell üzerinden oluşturulabilir. Örneğin 443/TCP:

New-NetFirewallRule `
  -DisplayName "Allow HTTPS 443" `
  -Direction Inbound `
  -Protocol TCP `
  -LocalPort 443 `
  -Action Allow

New-NetFirewallRule `
  -DisplayName "Allow HTTPS 443" `
  -Direction Inbound `
  -Protocol TCP `
  -LocalPort 443 `
  -Action Allow

Microsoft’un New-NetFirewallRule cmdlet’i inbound veya outbound firewall kuralları oluşturmayı; protokol, yerel port, uzak adres ve profil gibi koşullar tanımlamayı destekler.

Yönetim portlarında mümkün olduğunda kuralı kaynak IP ile sınırlandırmak daha güvenlidir. Örneğin:

New-NetFirewallRule `
  -DisplayName "Allow App 8080 From Admin IP" `
  -Direction Inbound `
  -Protocol TCP `
  -LocalPort 8080 `
  -RemoteAddress 203.0.113.25 `
  -Action Allow

New-NetFirewallRule `
  -DisplayName "Allow App 8080 From Admin IP" `
  -Direction Inbound `
  -Protocol TCP `
  -LocalPort 8080 `
  -RemoteAddress 203.0.113.25 `
  -Action Allow

Yine 203.0.113.25 gerçek bir yönetici IP’si değil, dokümantasyon amacıyla kullanılan örnek değerdir.

Docker, Reverse Proxy ve Localhost Kaynaklı Sorunlar

ERR_CONNECTION_REFUSED yalnızca klasik web sunucularında görülmez. Container ve reverse proxy mimarilerinde bağlantı zincirinin birden fazla port içermesi teşhisi zorlaştırabilir.

Örneğin:

İstemci
   │
 HTTPS :443
   ▼
NGINX
   │
 HTTP :3000
   ▼
Node.js uygulaması

İstemci
   │
 HTTPS :443
   ▼
NGINX
   │
 HTTP :3000
   ▼
Node.js uygulaması

Bu mimaride 443 dışarıya açıkken 3000 portunun internete açık olması gerekmeyebilir. NGINX, localhost veya özel container ağı üzerinden uygulamaya bağlanabilir.

NGINX çalışıyor ancak upstream uygulaması durmuşsa problem tarayıcıya her zaman doğrudan ERR_CONNECTION_REFUSED olarak yansımayabilir; reverse proxy bağlantıyı kabul ettiği için kullanıcı bunun yerine 502 Bad Gateway gibi bir HTTP yanıtı görebilir.

Bu ayrım teşhis açısından değerlidir:

Tarayıcı hedef web sunucusuna hiç bağlanamıyorsa bağlantı katmanını; reverse proxy bağlantıyı kabul ediyor fakat backend’e ulaşamıyorsa upstream uygulamasını araştırın.

Docker kullanıyorsanız çalışan container’ları ve yayınlanan portları kontrol edin:

docker ps

docker ps

Örneğin uygulama container içinde 3000 portunda çalışıyor olabilir ancak host’a hiçbir port publish edilmemiş olabilir.

Docker Compose yapılandırmasında şu iki kavramı da karıştırmamak gerekir:

• Container’ın kendi içinde dinlediği port
• Host üzerinden dışarı yayınlanan port

Reverse proxy aynı Docker ağı içerisindeyse uygulama portunun herkese açık biçimde host’a publish edilmesi gerekmeyebilir.

Connection Refused ile Timeout Arasındaki Fark

Bu iki durum aynı değildir ve hata ayıklarken önemli ipuçları verir.

Özellikle güvenlik duvarlarında trafiğin drop edilmesi ile aktif biçimde reject edilmesi istemci tarafında farklı davranışlara yol açabilir. Bu nedenle tarayıcıdaki hata mesajından tek başına kesin firewall teşhisi koymak yerine port ve servis testleri yapılmalıdır.

Güvenlik Açısından Port Açarken Nelere Dikkat Edilmeli?

Bir ERR_CONNECTION_REFUSED sorununu çözmenin en riskli yollarından biri güvenlik duvarını tamamen kapatmaktır.

Örneğin üretim sunucusunda yalnızca test amacıyla bile kontrolsüz biçimde tüm inbound trafiği açmak gereksiz risk oluşturabilir.

Bunun yerine minimum erişim yaklaşımı uygulanmalıdır:

1. Hangi servisin erişilebilir olması gerektiğini belirleyin.
2. TCP mi UDP mi kullanıldığını doğrulayın.
3. Yalnızca gerekli portu açın.
4. Mümkünse yönetim servislerini kaynak IP ile sınırlandırın.
5. Hem IPv4 hem IPv6 yapılandırmasını kontrol edin.
6. Sunucu firewall’ının yanında ağ seviyesindeki güvenlik kurallarını inceleyin.
7. Değişiklikten sonra portu dışarıdan yeniden test edin.

SSH, RDP, veritabanı veya yönetim paneli gibi servislerin gereksiz yere tüm internete açılması, bir web sitesindeki bağlantı problemini çözmek için uygun bir yöntem değildir.

ERR_CONNECTION_REFUSED Çözüm Kontrol Listesi

Sorunu sistematik biçimde teşhis etmek için şu sırayı kullanabilirsiniz:

1. Alan adı doğru IP adresine gidiyor mu?
2. Doğru protokol ve porta mı bağlanılıyor?
3. Sunucu erişilebilir durumda mı?
4. İlgili web sunucusu veya uygulama çalışıyor mu?
5. Hedef TCP portunda gerçekten bir process dinliyor mu?
6. Servis 127.0.0.1 yerine gerekli ağ arayüzünde dinliyor mu?
7. Sunucu firewall’ı bağlantıya izin veriyor mu?
8. Sağlayıcı veya ağ seviyesinde ikinci bir firewall/ACL var mı?
9. NAT veya port forwarding yapılandırması doğru mu?
10. Docker kullanılıyorsa port mapping veya container ağı doğru mu?
11. Reverse proxy kullanılıyorsa upstream IP ve port doğru mu?
12. IPv4 ve IPv6 yollarında farklı bir yapılandırma problemi var mı?
13. Değişikliklerden sonra bağlantı farklı bir ağdan tekrar test edildi mi?

Bu sıra önemli bir avantaj sağlar: güvenlik duvarını gereksiz yere değiştirmeden önce uygulamanın gerçekten bağlantı kabul edip etmediğini ortaya çıkarır.

Sonuç

ERR_CONNECTION_REFUSED hatasında yalnızca tarayıcı önbelleğini temizlemek veya DNS ayarlarını değiştirmek sunucu tarafındaki asıl problemi çözmeyebilir. Özellikle VDS, VPS ve dedicated sunucularda teşhis; DNS → IP → port → firewall → dinleyen servis → uygulama zinciri üzerinden yapılmalıdır.

Sunucuda önce ss, Test-NetConnection veya benzeri araçlarla port durumunu kontrol edin; ardından web servisinin çalıştığını ve doğru ağ arayüzünde dinlediğini doğrulayın. Firewall kuralını ise ancak ilgili portun gerçekten dış erişime açılması gerektiğinden emin olduktan sonra değiştirin.

Web uygulamanızı kendi sunucu ortamınızda çalıştırmayı planlıyorsanız Hostider’ın ilgili sunucu çözümlerini değerlendirirken yalnızca kaynak miktarını değil; işletim sistemi, web sunucusu, ağ ve güvenlik duvarı yapılandırmasının uygulamanızın gereksinimleriyle uyumunu da dikkate alabilirsiniz.

5. Sıkça Sorulan Sorular

ERR_CONNECTION_REFUSED ne demek?

ERR_CONNECTION_REFUSED, istemcinin hedef sunucu ve porta bağlantı kurma girişiminin kabul edilmediğini ifade eder. Web servisi çalışmıyor, yanlış port kullanılıyor veya ağ/güvenlik yapılandırması bağlantıyı engelliyor olabilir. Kesin nedeni belirlemek için hedef port ve sunucudaki dinleyen servisler kontrol edilmelidir.

ERR_CONNECTION_REFUSED hatası DNS kaynaklı olabilir mi?

DNS yanlış IP adresini döndürüyorsa kullanıcı yanlış sunucuya yönlendirilebilir ve burada bağlantı reddedilebilir. Ancak hata doğrudan bir DNS çözümleme hatasıyla aynı değildir. dig, nslookup veya Resolve-DnsName ile alan adının doğru IP’ye çözümlendiği kontrol edilmelidir.

Bir portun açık olup olmadığını nasıl kontrol edebilirim?

Linux/macOS tarafında nc -vz alanadi 443, Windows’ta ise Test-NetConnection alanadi -Port 443 kullanılabilir. Sunucunun kendisinde ss -lntp komutu hangi TCP portlarında servis dinlendiğini gösterir. Yerel olarak dinlenen bir portun internetten erişilebilir olduğunun ayrıca test edilmesi gerekir.

Firewall’u kapatmak ERR_CONNECTION_REFUSED hatasını çözer mi?

Firewall gerçekten engelleme yapıyorsa geçici olarak etkisi olabilir ancak güvenlik duvarını tamamen kapatmak önerilen çözüm değildir. Doğru yöntem, hangi port ve protokole ihtiyaç olduğunu belirleyerek yalnızca gerekli trafiğe izin veren kural oluşturmaktır.

Port açık olduğu halde neden bağlantı kurulamıyor?

Uygulama yalnızca 127.0.0.1 üzerinde dinliyor olabilir veya sunucu dışındaki bir firewall, ACL, NAT ya da yönlendirme kuralı bağlantıyı engelleyebilir. Container kullanılan ortamlarda host-container port eşlemesi de ayrıca kontrol edilmelidir.

Localhost’ta çalışan uygulamaya neden dışarıdan erişemiyorum?

127.0.0.1 loopback adresidir ve yalnızca aynı sistem üzerinden erişim için kullanılır. Uygulamanın doğrudan dış bağlantı kabul etmesi gerekiyorsa uygun ağ arayüzünde dinlemesi gerekir. Alternatif olarak NGINX gibi bir reverse proxy üzerinden uygulamaya güvenli biçimde trafik aktarılabilir.

ERR_CONNECTION_REFUSED ile 502 Bad Gateway aynı hata mı?

Hayır. ERR_CONNECTION_REFUSED istemcinin hedef bağlantıyı kuramamasıyla ilişkilidir. 502 Bad Gateway ise genellikle istemcinin proxy veya gateway’e ulaşabildiğini ancak bu sistemin arka uç servisten uygun yanıt alamadığını gösterir. Reverse proxy mimarilerinde bu ayrım sorunun hangi katmanda olduğunu belirlemeyi kolaylaştırır.

ERR_CONNECTION_REFUSED ile 502 Bad Gateway aynı hata mı?

Hayır. ERR_CONNECTION_REFUSED istemcinin hedef bağlantıyı kuramamasıyla ilişkilidir. 502 Bad Gateway ise genellikle istemcinin proxy veya gateway’e ulaşabildiğini ancak bu sistemin arka uç servisten uygun yanıt alamadığını gösterir. Reverse proxy mimarilerinde bu ayrım sorunun hangi katmanda olduğunu belirlemeyi kolaylaştırır.