ERR_CONNECTION_REFUSED: Co to oznacza i jak to całkowicie naprawić

Błąd ERR_CONNECTION_REFUSED oznacza, że Twoja przeglądarka wysłała żądanie połączenia do serwera WWW, a ten serwer aktywnie je odrzucił — nie zignorował, lecz jawnie odmówił wykonania uzgadniania TCP. Jest to zasadniczo inny rodzaj awarii niż przekroczenie limitu czasu (ERR_CONNECTION_TIMED_OUT) lub błąd DNS (ERR_NAME_NOT_RESOLVED), a ta różnica ma ogromne znaczenie przy diagnozowaniu przyczyny źródłowej.

W praktyce, gdy Chrome wyświetla komunikat „Nie można otworzyć tej witryny. ERR_CONNECTION_REFUSED”, oznacza to jedną z trzech rzeczy: serwer docelowy nie nasłuchuje na żądanym porcie, zapora sieciowa lub warstwa zabezpieczeń odsyła pakiet TCP RST (reset) do klienta, albo lokalny stos sieciowy jest błędnie skonfigurowany i nieprawidłowo kieruje żądanie, zanim dotrze ono do serwera. Ustalenie, która z tych trzech kategorii dotyczy Twojej sytuacji, to najszybsza droga do rozwiązania problemu.

Zrozumienie mechaniki na poziomie TCP

Większość poradników dotyczących rozwiązywania problemów z przeglądarką traktuje ERR_CONNECTION_REFUSED jako ogólny „problem sieciowy”. Tak nie jest. Na poziomie TCP odmowa połączenia oznacza, że serwer (lub pośrednik) odesłał pakiet RST/ACK w odpowiedzi na pakiet SYN przeglądarki. Jest to jawne odrzucenie, a nie ciche porzucenie.

Ta różnica ma praktyczne znaczenie diagnostyczne: gdyby połączenie było po cichu porzucane przez zaporę sieciową, widoczny byłby błąd ERR_CONNECTION_TIMED_OUT. Odmowa połączenia oznacza, że coś aktywnie odpowiada — co oznacza, że host jest osiągalny na poziomie sieci, ale usługa na docelowym porcie jest niedostępna lub zablokowana.

Typowe przyczyny na poziomie portów to:

• Proces serwera WWW (Apache, Nginx, Node.js) uległ awarii lub został zatrzymany
• Serwer nasłuchuje na niestandardowym porcie, a adres URL go nie określa
• Zapora sieciowa na hoście (iptables, ufw, Zapora systemu Windows) odrzuca połączenia na porcie 80 lub 443
• Odwrotny serwer proxy (HAProxy, Nginx, Cloudflare) jest nieprawidłowo skonfigurowany i zwraca pakiety RST do nadrzędnego systemu
• Aplikacja za serwerem proxy uległa awarii, pozostawiając proxy bez backendu do przekazywania żądań

Przyczyny źródłowe: usystematyzowany podział

Przyczyny po stronie klienta

Przyczyny po stronie serwera

Przewodnik diagnostyczny i naprawczy krok po kroku

Krok 1: Ustal, czy problem ma charakter globalny czy lokalny

Przed zmianą jakichkolwiek ustawień lokalnych sprawdź, czy witryna jest niedostępna dla wszystkich, czy tylko dla Ciebie. Użyj następujących narzędzi:

• downforeveryoneorjustme.com — prosta kontrola dostępności
• isitdownrightnow.com — zawiera historię czasu odpowiedzi
• ping.pe — pinguje cel z wielu globalnych lokalizacji jednocześnie

Jeśli witryna jest dostępna z zewnętrznych węzłów, ale nie z Twojego komputera, problem ma charakter lokalny. Jeśli jest niedostępna globalnie, problem leży po stronie serwera i jest poza Twoją kontrolą — skontaktuj się z administratorem witryny lub poczekaj.

Dla administratorów serwerów zarządzających własną infrastrukturą, globalnie niedostępna witryna wymaga natychmiastowego zbadania procesu serwera WWW, reguł zapory sieciowej i sieci nadrzędnej. Jeśli korzystasz ze środowiska Hosting VPS, najpierw sprawdź listę procesów serwera i konfigurację zapory sieciowej.

Krok 2: Sprawdź, czy serwer faktycznie nasłuchuje (dla administratorów serwerów)

Jeśli administrujesz danym serwerem, połącz się przez SSH i uruchom następujące polecenie, aby sprawdzić, co nasłuchuje na których portach:

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

Jeśli wynik jest pusty dla portu 80 lub 443, proces serwera WWW nie działa. Uruchom go ponownie:

# For Nginx
sudo systemctl restart nginx

# For Apache
sudo systemctl restart apache2

# Check status
sudo systemctl status nginx

Sprawdź również, czy zapora sieciowa nie blokuje połączeń przychodzących:

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

# If using ufw
sudo ufw status verbose

Jeśli port 443 jest zablokowany, zezwól na niego:

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

Dla administratorów korzystających z Serwerów Dedykowanych sprawdź również, czy zapora sieciowa lub reguły grupy zabezpieczeń dostawcy hostingu nie blokują portu na obwodzie sieci — jest to odrębne od zapory sieciowej na poziomie systemu operacyjnego.

Krok 3: Uruchom ponownie router i wyczyść lokalny stan sieci

W przypadku problemów po stronie klienta ponowne uruchomienie routera czyści tablice NAT, dzierżawy DHCP oraz wszelkie przejściowe awarie routingu. Odłącz router na 30 sekund, a następnie podłącz go ponownie. Jest to szczególnie skuteczne, gdy błąd pojawił się nagle bez żadnych zmian konfiguracji.

Krok 4: Wyczyść pamięć podręczną DNS

Nieaktualna pozycja w pamięci podręcznej DNS wskazująca na stary lub wycofany adres IP jest jedną z najczęstszych przyczyn ERR_CONNECTION_REFUSED po stronie klienta. Serwer pod zapisanym adresem IP może już nie obsługiwać docelowej witryny.

W systemie Windows:

ipconfig /flushdns

W systemie macOS (Ventura, Sonoma i większość nowoczesnych wersji):

sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

W systemie Linux (systemd-resolved):

sudo systemd-resolve --flush-caches

Po wyczyszczeniu pamięci podręcznej sprawdź, na jaki adres IP domena jest teraz rozwiązywana:

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

Porównaj to ze znanym adresem IP witryny. Jeśli się różnią, propagacja DNS może być jeszcze w toku.

Krok 5: Wyczyść pamięć podręczną i pliki cookie przeglądarki

W Google Chrome przejdź do chrome://settings/clearBrowserData lub użyj skrótu klawiaturowego:

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

Ustaw zakres czasu na Cały czas, zaznacz Obrazy i pliki w pamięci podręcznej oraz Pliki cookie i inne dane witryn, a następnie kliknij Wyczyść dane. Uruchom Chrome całkowicie od nowa (nie tylko kartę) przed ponownym testem.

Aby szybko przetestować bez czyszczenia danych, otwórz okno incognito (Ctrl + Shift + N). Jeśli witryna ładuje się w trybie incognito, ale nie w zwykłym oknie, winowajcą jest zasób z pamięci podręcznej lub rozszerzenie przeglądarki.

Krok 6: Sprawdź i wyłącz ustawienia proxy

Błędnie skonfigurowany lub niedziałający serwer proxy jest częstą przyczyną ERR_CONNECTION_REFUSED na wszystkich witrynach jednocześnie. Chrome domyślnie używa systemowych ustawień proxy.

W systemie Windows:

Przejdź do Ustawienia > System > Serwer proxy i wyłącz opcję „Użyj serwera proxy”, jeśli jest włączona bez Twojej wiedzy. Alternatywnie uruchom to z wiersza polecenia z podwyższonymi uprawnieniami:

netsh winhttp reset proxy

W systemie macOS:

Przejdź do Ustawienia systemowe > Sieć, wybierz aktywny interfejs, kliknij Szczegóły, a następnie kartę Serwery proxy i odznacz wszystkie aktywne protokoły proxy.

Po wyłączeniu proxy przetestuj witrynę. Jeśli się ładuje, przyczyną była konfiguracja proxy. Skonfiguruj ją poprawnie lub usuń całkowicie.

Krok 7: Zmień resolver DNS

Domyślny resolver DNS Twojego dostawcy usług internetowych może zwracać nieprawidłowe wyniki, być niedostępny lub aktywnie blokować określone domeny. Przełączenie na publiczny resolver eliminuje tę zmienną.

Zalecane publiczne resolvery DNS:

W systemie Windows (przez PowerShell):

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

W systemie macOS:

Przejdź do Ustawienia systemowe > Sieć > [Twój interfejs] > Szczegóły > DNS, usuń istniejące wpisy i dodaj 1.1.1.1 oraz 1.0.0.1.

W systemie Linux (systemd-resolved):

Edytuj /etc/systemd/resolved.conf:

[Resolve]
DNS=1.1.1.1 1.0.0.1
FallbackDNS=8.8.8.8 8.8.4.4

Następnie uruchom ponownie resolver:

sudo systemctl restart systemd-resolved

Krok 8: Tymczasowo wyłącz zaporę sieciową i program antywirusowy

Niektóre programy antywirusowe i zapory sieciowe na hoście przechwytują ruch HTTPS przez lokalny serwer proxy i mogą wysyłać pakiety RST, gdy ich silnik inspekcji zawiedzie lub gdy domena docelowa znajduje się na liście blokowanych. Tymczasowe wyłączenie ich (wyłącznie w celach diagnostycznych) potwierdza, czy są przyczyną problemu.

Jeśli wyłączenie oprogramowania zabezpieczającego rozwiązuje błąd, dodaj konkretny wyjątek dla docelowej domeny zamiast pozostawiać oprogramowanie wyłączone. Włącz je ponownie natychmiast po testowaniu.

Krok 9: Przetestuj w innej przeglądarce i sieci

Przetestuj adres URL w Firefox, Edge lub Safari. Jeśli ładuje się w innej przeglądarce, problem dotyczy Chrome — prawdopodobnie uszkodzonego profilu, nieprawidłowo działającego rozszerzenia lub ustawienia proxy specyficznego dla Chrome. Spróbuj utworzyć nowy profil Chrome, aby odizolować problem.

Jeśli witryna nie działa we wszystkich przeglądarkach, przełącz się na mobilny hotspot. Jeśli ładuje się przez dane mobilne, źródłem problemu jest Twój dostawca usług internetowych lub router domowy.

Krok 10: Sprawdź problemy z konfiguracją SSL/TLS (administratorzy serwerów)

Błędnie skonfigurowany certyfikat SSL może spowodować awarię serwera lub odmowę połączeń TLS, co Chrome w niektórych przypadkach brzegowych zgłasza jako ERR_CONNECTION_REFUSED zamiast błędu certyfikatu. Użyj następującego polecenia do testowania z wiersza poleceń:

curl -vI https://yourdomain.com

Zwróć uwagę na etap uzgadniania TLS w szczegółowym wyniku. Błąd na tym etapie wskazuje na problem z certyfikatem lub zestawem szyfrów. Możesz również przetestować za pomocą:

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

Jeśli certyfikat SSL wygasł lub jest błędnie skonfigurowany, jego odnowienie lub wymiana rozwiązuje problem. Upewnij się, że Twoje Certyfikaty SSL są ważne, prawidłowo połączone w łańcuch i zainstalowane na właściwym interfejsie serwera.

ERR_CONNECTION_REFUSED a podobne błędy przeglądarki

Zrozumienie, czym ten błąd różni się od pokrewnych błędów, zapobiega błędnej diagnozie:

Zaawansowane przypadki brzegowe i pułapki

Konflikty rozwiązywania adresów IPv6 i IPv4: Jeśli domena rozwiązuje się do adresu IPv6, ale Twoja sieć nie obsługuje prawidłowo IPv6, Chrome może próbować nawiązać połączenie IPv6, które zostanie odrzucone, a następnie nie zdążyć przełączyć się na IPv4. Tymczasowe wyłączenie IPv6 na karcie sieciowej może to potwierdzić. W systemie Linux możesz wymusić IPv4 za pomocą curl -4 https://example.com.

Błędy nieaktualnego źródła w pamięci podręcznej Cloudflare lub CDN: Jeśli witryna korzysta z Cloudflare i serwer źródłowy przestaje działać, Cloudflare może przez pewien czas serwować wersję z pamięci podręcznej, a następnie zacząć zwracać błędy 521 (origin refused connection) lub 522, które Chrome może wyświetlać jako ERR_CONNECTION_REFUSED w zależności od sposobu przekazywania błędu przez proxy.

Lokalne środowiska deweloperskie: Deweloperzy często napotykają ERR_CONNECTION_REFUSED podczas uzyskiwania dostępu do localhost:3000 lub podobnych adresów. Przyczyną jest niemal zawsze to, że proces serwera deweloperskiego nie działa, uległ awarii lub jest powiązany z 127.0.0.1 na innym porcie niż oczekiwany. Uruchom ss -tlnp | grep node (lub odpowiedni proces), aby sprawdzić, co faktycznie nasłuchuje.

Konflikty portów serwera poczty e-mail: Jeśli korzystasz z Hostingu Poczty E-mail na tym samym serwerze co aplikacja WWW, upewnij się, że konflikty portów między SMTP (25, 587), IMAP (993) a HTTP/HTTPS (80, 443) nie powodują błędów powiązania serwera WWW.

Ograniczenia hostingu współdzielonego: W środowiskach Hostingu Współdzielonego odmowa połączenia może oznaczać, że serwer dostawcy hostingu jest przeciążony, konto zostało zawieszone lub DNS domeny nie wskazuje jeszcze na właściwy współdzielony adres IP. Sprawdź panel sterowania hostingu pod kątem statusu konta i konfiguracji DNS.

Praktyczna macierz decyzyjna: którą poprawkę zastosować jako pierwszą

Użyj tej listy kontrolnej, aby sprawnie ustalić priorytety:

• Błąd pojawia się na wszystkich witrynach jednocześnie — najpierw sprawdź ustawienia proxy i konfigurację VPN/zapory sieciowej
• Błąd pojawia się tylko na jednej konkretnej domenie — sprawdź, czy witryna jest globalnie niedostępna; następnie wyczyść pamięć podręczną DNS
• Błąd pojawia się tylko w Chrome, nie w innych przeglądarkach — wyczyść pamięć podręczną Chrome, wyłącz rozszerzenia lub utwórz nowy profil Chrome
• Błąd pojawia się tylko w Twojej sieci, nie przez dane mobilne — uruchom ponownie router; sprawdź DNS lub zaporę sieciową na poziomie dostawcy usług internetowych
• Błąd pojawia się po zmianie konfiguracji serwera — sprawdź status procesu serwera WWW, powiązania portów i reguły zapory sieciowej na serwerze
• Błąd pojawia się sporadycznie przy dużym obciążeniu — zbadaj wyczerpanie zasobów (deskryptory plików, pamięć, limity połączeń) na serwerze
• Błąd pojawia się tylko na HTTPS, nie na HTTP — zbadaj ważność certyfikatu SSL i konfigurację TLS
• Błąd pojawił się po zmianie ustawień DNS — cofnij zmiany DNS i wyczyść pamięć podręczną; sprawdź, czy nowy resolver jest osiągalny

FAQ

Jaka jest różnica między ERR_CONNECTION_REFUSED a ERR_CONNECTION_TIMED_OUT?

ERR_CONNECTION_REFUSED oznacza, że serwer (lub zapora sieciowa) aktywnie wysłał pakiet TCP reset, natychmiast odrzucając połączenie. ERR_CONNECTION_TIMED_OUT oznacza, że w czasie limitu oczekiwania nie otrzymano żadnej odpowiedzi — pakiety zostały po cichu porzucone. Odmowa połączenia pojawia się szybciej i wskazuje na aktywne odrzucenie, podczas gdy przekroczenie limitu czasu sugeruje regułę DROP routingu lub zapory sieciowej.

Czy ERR_CONNECTION_REFUSED może być spowodowany wygasłym certyfikatem SSL?

Pośrednio tak. W niektórych konfiguracjach serwerów wygasły lub błędnie skonfigurowany certyfikat SSL powoduje, że proces serwera WWW nie uruchamia się lub ulega awarii podczas obsługi połączeń TLS, co skutkuje brakiem nasłuchiwania na porcie 443. Chrome zgłasza wtedy ERR_CONNECTION_REFUSED, ponieważ nic nie nasłuchuje, mimo że podstawową przyczyną jest problem z certyfikatem.

Dlaczego ERR_CONNECTION_REFUSED pojawia się tylko na jednej konkretnej witrynie?

Jeśli błąd dotyczy tylko jednej domeny, najbardziej prawdopodobnymi przyczynami są: awaria usługi WWW na serwerze docelowym, blokowanie Twojego zakresu adresów IP przez zaporę sieciową serwera, rekordy DNS domeny wskazują na stary adres IP, gdzie żadna usługa nie działa, lub witryna została wyłączona. Użyj curl -v https://thatdomain.com z innej sieci lub serwera, aby odizolować przyczynę.

Jak naprawić ERR_CONNECTION_REFUSED na localhost?

Serwer aplikacji nie działa lub jest powiązany z innym portem niż ten, do którego się odwołujesz. Sprawdź, co nasłuchuje, za pomocą ss -tlnp w systemie Linux/macOS lub netstat -ano | findstr :PORT w systemie Windows. Uruchom proces serwera aplikacji i upewnij się, że jest powiązany z 0.0.0.0 lub 127.0.0.1 na oczekiwanym porcie.

Czy wyczyszczenie DNS zawsze naprawia ERR_CONNECTION_REFUSED?

Tylko wtedy, gdy przyczyną źródłową jest nieaktualna pozycja w pamięci podręcznej DNS wskazująca na adres IP, gdzie usługa już nie działa. Jeśli serwer jest wyłączony, zapora sieciowa blokuje połączenie lub proxy jest błędnie skonfigurowane, wyczyszczenie DNS nie przyniesie efektu. Użyj dig lub nslookup, aby zweryfikować rozwiązywanie DNS przed i po wyczyszczeniu, aby potwierdzić, czy DNS był faktycznie przyczyną problemu.