ERR_CONNECTION_REFUSED: Co to znaczy i jak to naprawić

Czym jest błąd ERR_CONNECTION_REFUSED?

ERR_CONNECTION_REFUSED to błąd Chrome, który pojawia się, gdy przeglądarka dociera do serwera strony, ale serwer aktywnie odmawia połączenia. Na poziomie sieci Twój komputer wysłał żądanie nawiązania połączenia TCP (SYN) na adres IP i port serwera, a serwer — lub stojąca przed nim zapora — zamiast je przyjąć, odpowiedział pakietem resetującym (RST), który mówi: „nic tutaj nie będzie z tobą rozmawiać”.

To zasadniczo odróżnia ERR_CONNECTION_REFUSED od błędów DNS, takich jak DNS_PROBE_FINISHED_NXDOMAIN. Przy błędzie DNS nazwa domeny w ogóle nie została przetłumaczona na adres IP. Przy ERR_CONNECTION_REFUSED DNS zadziałał bez zarzutu — przeglądarka dokładnie wie, gdzie jest serwer — ale maszyna pod tym adresem odmówiła otwarcia drzwi.

Odmowa zwykle oznacza jedną z trzech rzeczy: na tym porcie nie nasłuchuje żadna usługa (serwer WWW nie działa lub uległ awarii), zapora odrzuca ruch na ten port, albo Twoje urządzenie łączy się z zupełnie niewłaściwym adresem IP — na przykład przez nieaktualną pamięć podręczną DNS lub zepsute proxy.

Jak ten błąd wygląda w innych przeglądarkach

Każda przeglądarka inaczej zgłasza odrzucone połączenie, ale stojące za tym odrzucenie TCP jest identyczne.

Przeglądarki oparte na Chromium (Chrome, Edge, Brave, Opera) pokazują surowy kod ERR_CONNECTION_REFUSED. Firefox i Safari opisują problem prostym językiem, ale przyczyna i rozwiązania są dokładnie takie same.

Najczęstsze przyczyny błędu ERR_CONNECTION_REFUSED

Mniej więcej w połowie przypadków problem leży po stronie serwera, a w połowie coś przeszkadza na Twoim urządzeniu lub w Twojej sieci. Oto najczęstsze przyczyny, od najbardziej do najmniej powszechnych.

• Serwer strony nie działa — Usługa WWW (nginx, Apache, Node.js) uległa awarii, restartuje się lub została zatrzymana. Maszyna jest online, ale nic nie odpowiada na porcie 80/443.

• Zapora blokuje port — Zapora na serwerze, w Twojej sieci lub na Twoim urządzeniu odrzuca połączenia na ten port.

• Błędne ustawienia proxy — System kieruje ruch przez serwer proxy, który jest wyłączony lub nieosiągalny. To jedna z najczęstszych przyczyn po stronie klienta.

• Nieaktualna pamięć podręczna DNS — Strona przeniosła się na nowy serwer, ale wpis DNS w Twojej pamięci podręcznej nadal wskazuje stary adres IP, na którym nic już nie nasłuchuje.

• Ingerencja VPN lub antywirusa — Oprogramowanie zabezpieczające przechwytuje połączenie i je odrzuca, albo serwer wyjściowy VPN nie może dotrzeć do strony.

• Ingerencja rozszerzeń przeglądarki — Blokery reklam, rozszerzenia dbające o prywatność lub rozszerzenia zainfekowane złośliwym oprogramowaniem mogą blokować połączenia z konkretnymi hostami.

• Nadpisanie w pliku hosts — Domena jest w pliku hosts przypisana do złego adresu IP (często 127.0.0.1), więc przeglądarka łączy się z Twoim własnym komputerem, który odmawia.

• Nic nie nasłuchuje na localhost — Dla programistów: lokalny serwer deweloperski nie działa, uległ awarii albo jest powiązany z innym portem niż ten, który otwierasz.

• Problem z routerem — Zawieszony router lub modem psuje połączenia, dopóki nie zostanie zrestartowany.

Rozwiązanie 1: Sprawdź, czy strona nie leży dla wszystkich

Zanim cokolwiek zmienisz na swoim urządzeniu, ustal, czy problem leży po stronie serwera — jeśli strona nie działa u nikogo, żadna lokalna poprawka nie pomoże.

Najczystszym testem jest sprawdzenie z innej ścieżki sieciowej. Otwórz stronę na telefonie przez dane mobilne (z wyłączonym Wi-Fi). Jeśli tam też nie działa, to sam serwer odrzuca połączenia i pozostaje czekać, aż właściciel strony to naprawi.

Możesz też przetestować serwer bezpośrednio narzędziami DNS Robot:

• [Port Checker](/port-checker) — Wpisz domenę strony i przetestuj port 443 (HTTPS) oraz port 80 (HTTP). Jeśli oba są zamknięte, serwer WWW nie działa lub jest odcięty zaporą dla wszystkich, nie tylko dla Ciebie.

• [Test Ping](/ping) — Sprawdza, czy maszyna serwera w ogóle odpowiada. Jeśli ping działa, ale porty są zamknięte, maszyna żyje, ale usługa WWW jest martwa.

• [HTTP Headers Checker](/http-headers) — Wysyła prawdziwe żądanie HTTP z serwerów DNS Robot. Jeśli dostaje odpowiedź, a Twoja przeglądarka nie, problem leży lokalnie — na Twoim urządzeniu lub w Twojej sieci.

Rozwiązanie 2: Zrestartuj router i urządzenie

Klasyczny pierwszy ruch nie bez powodu: restart czyści tablicę połączeń routera, pamięć podręczną DNS i zawieszony stan NAT, który może powodować odrzucanie połączeń.

Odłącz router (i modem, jeśli to osobne urządzenie) od zasilania, odczekaj 30 sekund, podłącz z powrotem i daj mu 2–3 minuty na pełne połączenie. Zrestartuj też komputer lub telefon, aby zresetować jego stos sieciowy, a następnie otwórz stronę ponownie.

Rozwiązanie 3: Wyczyść pamięć podręczną i pliki cookie przeglądarki

Chrome mógł zapamiętać zepsute przekierowanie, stary wpis HSTS lub pliki cookie, które kierują Cię na martwy serwer. Ich wyczyszczenie wymusza całkowicie świeże połączenie.

• Otwórz Chrome → kliknij menu z trzema kropkami → Usuń dane przeglądania

• Zakres czasu → wybierz Od początku

• Zaznacz „Pliki cookie i inne dane witryn” oraz „Obrazy i pliki zapisane w pamięci podręcznej”

• Kliknij Usuń dane, zrestartuj Chrome i otwórz stronę ponownie

Rozwiązanie 4: Wyłącz ustawienia proxy

Błędnie skonfigurowane lub martwe proxy to jedna z najczęstszych przyczyn ERR_CONNECTION_REFUSED na wszystkich stronach naraz. Gdy system jest ustawiony tak, by kierować ruch przez proxy, które już nie istnieje — często pozostałość po starym VPN, konfiguracji szkolnej/firmowej lub złośliwym oprogramowaniu — każde połączenie jest odrzucane.

Windows: Otwórz Ustawienia → Sieć i internet → Serwer proxy. Wyłącz „Użyj serwera proxy” w sekcji ręcznej konfiguracji proxy i wyłącz „Automatycznie wykryj ustawienia”, jeśli nie korzystasz z firmowego proxy.

macOS: Otwórz Ustawienia systemowe → Sieć → Wi-Fi → Szczegóły → Serwery proxy. Odznacz wszystkie protokoły na liście (Web Proxy HTTP, Secure Web Proxy HTTPS, SOCKS Proxy), chyba że wymaga ich Twoja organizacja, i kliknij OK.

Chrome korzysta z ustawień proxy systemu operacyjnego, więc po ich zmianie zrestartuj przeglądarkę i przetestuj ponownie.

Rozwiązanie 5: Wyczyść pamięć podręczną DNS

Jeśli strona niedawno przeniosła się na nowy serwer, wpis w Twojej pamięci podręcznej DNS może nadal wskazywać stary adres IP — na którym nic już nie nasłuchuje, więc połączenie jest odrzucane. Wyczyszczenie pamięci podręcznej zmusza urządzenie do ponownego ustalenia aktualnego adresu.

# Windows (Command Prompt as Administrator)
ipconfig /flushdns

# macOS
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

# Linux (systemd-resolved)
sudo resolvectl flush-caches

# Also clear Chrome's internal DNS cache:
# chrome://net-internals/#dns → Clear host cache

Po wyczyszczeniu wyczyść też własną pamięć podręczną DNS Chrome pod adresem chrome://net-internals/#dns i opróżnij pule gniazd pod chrome://net-internals/#sockets — Chrome przechowuje jedno i drugie niezależnie od systemu operacyjnego. Pełną instrukcję znajdziesz w naszym poradniku jak wyczyścić DNS w każdym systemie.

Na jaki adres IP domena aktualnie się rozwiązuje, sprawdzisz narzędziem DNS Lookup od DNS Robot — jeśli nslookup w Twoim terminalu pokazuje inny adres IP niż wynik globalny, problemem była Twoja pamięć podręczna.

Rozwiązanie 6: Przełącz się na publiczny serwer DNS

Jeśli serwer DNS Twojego dostawcy internetu zwraca nieaktualne rekordy, czyszczenie pamięci podręcznej nie pomoże — po prostu pobierzesz ten sam przestarzały adres IP. Przejście na szybki publiczny resolver daje aktualne rekordy i często ogólnie przyspiesza przeglądanie.

Windows: Ustawienia → Sieć i internet → Twoje połączenie → Edytuj obok Przypisanie serwera DNS → Ręczne → włącz IPv4 → wpisz 1.1.1.1 i 1.0.0.1 → Zapisz.

macOS: Ustawienia systemowe → Sieć → Wi-Fi → Szczegóły → DNS → dodaj 1.1.1.1 i 1.0.0.1, usuń stare wpisy → OK.

Nie wiesz, który resolver jest najszybszy w Twojej lokalizacji? Uruchom DNS Speed Test od DNS Robot — w kilka sekund porówna Cloudflare, Google, Quad9 i inne z Twojego własnego łącza.

Rozwiązanie 7: Tymczasowo wyłącz VPN, antywirus i zaporę

VPN-y, moduły ochrony WWW w antywirusach i zapory sieciowe stoją między Twoją przeglądarką a internetem i każde z nich może odrzucać połączenia. Częstym winowajcą są funkcje skanowania HTTPS w antywirusach: przepuszczają one Twój szyfrowany ruch przez lokalną usługę, a gdy ta się zepsuje, każda strona HTTPS jest odrzucana.

Testuj w tej kolejności: odłącz VPN i odśwież stronę. Następnie wyłącz na minutę moduł ochrony WWW w antywirusie i odśwież. Na końcu na chwilę wyłącz zaporę (Zapora Windows Defender lub zapora macOS) i odśwież.

Jeśli strona ładuje się po wyłączeniu któregoś z nich, włącz go z powrotem i dodaj wyjątek dla tej strony — albo zmień lokalizację serwera VPN — zamiast zostawiać ochronę wyłączoną.

Rozwiązanie 8: Przetestuj rozszerzenia w trybie incognito

Blokery reklam, narzędzia dbające o prywatność i rozszerzenia VPN potrafią po cichu blokować połączenia z konkretnymi hostami. Szybki test: otwórz stronę w oknie incognito (Ctrl+Shift+N / Cmd+Shift+N), w którym większość rozszerzeń jest domyślnie wyłączona.

Jeśli strona działa w incognito, przyczyną jest rozszerzenie. Wejdź na chrome://extensions, wyłącz wszystkie, a potem włączaj je pojedynczo, aż błąd wróci — to będzie winowajca. Usuń go albo wyklucz stronę z jego filtrów.

Rozwiązanie 9: Sprawdź plik hosts

Plik hosts nadpisuje DNS dla konkretnych domen. Jeśli strona jest w nim przypisana do 127.0.0.1, 0.0.0.0 lub starego adresu IP serwera, przeglądarka łączy się właśnie z tym adresem — i dostaje odmowę. Typowi podejrzani to pozostawione wpisy deweloperskie i listy hosts blokujące reklamy.

# Windows — open as Administrator:
notepad C:\Windows\System32\drivers\etc\hosts

# macOS / Linux:
sudo nano /etc/hosts

# Look for lines containing the domain, e.g.:
# 127.0.0.1   example.com   ← forces the connection to your own PC
# 203.0.113.7 example.com   ← forces an old server IP

# Delete the offending line, save, then flush DNS.

Localhost odmówił połączenia (dla programistów)

Widok localhost refused to connect lub ERR_CONNECTION_REFUSED na 127.0.0.1 to rytuał przejścia każdego programisty. Oznacza, że nic na Twojej maszynie nie przyjmuje połączeń na porcie, o który prosisz. Typowe powody:

• Serwer deweloperski nie działa — Nigdy go nie uruchomiłeś albo się wysypał. Sprawdź terminal, w którym powinno działać npm run dev, rails s lub python manage.py runserver.

• Zły port — Serwer wystartował na innym porcie (np. 3001, bo 3000 był zajęty), a Ty otwierasz stary. Przeczytaj linię logu startowego, która mówi, na którym porcie nasłuchuje.

• Powiązanie z innym interfejsem — Serwer nasłuchuje na 0.0.0.0 lub na wewnętrznym IP kontenera, a Ty wchodzisz na localhost — albo odwrotnie. Mapowania portów Dockera (-p 3000:3000) muszą odpowiadać portowi, na którym aplikacja nasłuchuje wewnątrz kontenera.

• Zapora lub oprogramowanie zabezpieczające — Lokalne zapory potrafią blokować nawet porty loopback; to częste na komputerach firmowych.

• HTTPS vs HTTP — Otwierasz https://localhost:3000, a serwer deweloperski mówi tylko zwykłym HTTP. Spróbuj jawnie wpisać http://.

# Which process is listening on port 3000?
# macOS / Linux:
lsof -i :3000

# Windows (PowerShell):
netstat -ano | findstr :3000

# No output = nothing is listening = connection refused.
# Start your dev server, or kill the stale process and restart it.

Jeśli chcesz sprawdzić, czy port na Twoim publicznym serwerze jest osiągalny z internetu (a nie tylko z samej maszyny), użyj Port Checkera od DNS Robot — testuje połączenie spoza Twojej sieci, czyli dokładnie to, czego doświadczają Twoi odwiedzający.

Dla właścicieli stron: Twoja witryna odrzuca połączenia

Jeśli odwiedzający zgłaszają ERR_CONNECTION_REFUSED na Twojej własnej stronie, serwer działa (DNS się rozwiązuje, maszyna zapewne odpowiada na ping), ale usługa WWW nie przyjmuje połączeń. Przejdź przez tę listę kontrolną:

• Czy proces serwera WWW działa? Zaloguj się przez SSH i sprawdź: systemctl status nginx (albo apache2, caddy). Proces, który padł po nieudanym przeładowaniu lub został zabity przez brak pamięci, to przyczyna nr 1. Zrestartuj go: sudo systemctl restart nginx.

• Czy nasłuchuje na właściwych portach? Uruchom ss -tlnp | grep -E ':80|:443'. Jeśli nic nie nasłuchuje na 443, konfiguracja TLS się nie wczytała — sprawdź błędy konfiguracji przez nginx -t.

• Czy zapora jest otwarta? Sprawdź ufw status lub grupę zabezpieczeń u swojego dostawcy chmury. Porty 80 i 443 muszą przyjmować przychodzący ruch TCP z 0.0.0.0/0.

• Czy zmienił się adres IP serwera? Porównaj rekord A w DNS z faktycznym adresem IP serwera przy pomocy DNS Lookup. Po migracji stary rekord A wysyła odwiedzających na poprzednią maszynę.

• Przetestuj z zewnątrz — Użyj Port Checkera na portach 80 i 443 oraz HTTP Headers Checkera, aby potwierdzić, że serwer odpowiada na prawdziwe żądania z publicznego internetu.

Jak sprawdzić, czy naprawa zadziałała

Po każdej poprawce potwierdź połączenie na poziomie sieci, zamiast tylko odświeżać stronę — dowiesz się, czy port faktycznie się otworzył.

# Test the TCP connection directly (Mac/Linux):
nc -zv example.com 443
# "succeeded" = port open, "refused" = still rejected

# Windows (PowerShell):
Test-NetConnection example.com -Port 443
# TcpTestSucceeded : True = fixed

# Then confirm what IP you're actually connecting to:
nslookup example.com

Możesz też pominąć terminal: wpisz domenę i port w Port Checkerze od DNS Robot, aby błyskawicznie uzyskać odpowiedź otwarty/zamknięty z zewnętrznej sieci. Jeśli port jest otwarty z zewnątrz, a Twoja przeglądarka nadal pokazuje ERR_CONNECTION_REFUSED, blokada tkwi na Twoim urządzeniu — wróć do poprawek dotyczących proxy, VPN, antywirusa i pliku hosts powyżej.