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

Błąd ERR_CONNECTION_REFUSED oznacza, że przeglądarka wysłała żądanie połączenia do serwera WWW, a serwer aktywnie je odrzucił — nie zignorował go, ale wyraźnie odmówił uzgodnienia TCP. Jest to fundamentalnie inny tryb awarii niż timeout (ERR_CONNECTION_TIMED_OUT) lub błąd DNS (ERR_NAME_NOT_RESOLVED), a to rozróżnienie ma ogromne znaczenie przy diagnozowaniu przyczyny głównej.

W praktyce, gdy Chrome wyświetla “Nie można uzyskać dostępu do tej witryny. ERR_CONNECTION_REFUSED”, oznacza to jedną z trzech rzeczy: serwer docelowy nie nasłuchuje na żądanym porcie, zapora sieciowa lub warstwa bezpieczeństwa wysyła pakiet TCP RST (reset) z powrotem do klienta, lub lokalny stos sieciowy jest błędnie skonfigurowany i kieruje żądanie nieprawidłowo, zanim w ogóle dotrze do serwera. Określenie, która z tych trzech kategorii dotyczy Twojej sytuacji, to najszybsza droga do rozwiązania.

Zrozumienie mechaniki na poziomie TCP

Większość przewodników rozwiązywania problemów przeglądarki traktuje ERR_CONNECTION_REFUSED jako niejasny “problem sieciowy”. To nie jest. Na warstwie TCP, odrzucona połączenie oznacza, że serwer (lub pośrednik) wysłał z powrotem pakiet RST/ACK w odpowiedzi na pakiet SYN przeglądarki. To jest jawne odrzucenie, a nie cicha utrata.

To rozróżnienie ma praktyczne znaczenie diagnostyczne: gdyby połączenie było cicho odrzucane przez zaporę sieciową, zobaczysz ERR_CONNECTION_TIMED_OUT. Odrzucone połączenie oznacza, że coś aktywnie odpowiada — co oznacza, że host jest osiągalny na poziomie sieci, ale usługa na porcie docelowym jest niedostępna lub zablokowana.

Typowe przyczyny na poziomie portu obejmują:

• Proces serwera WWW (Apache, Nginx, Node.js) uległ awarii lub został zatrzymany
• Serwer nasłuchuje na porcie niestandardowym, a adres URL go nie określa
• Zapora sieciowa oparta na hoście (iptables, ufw, Windows Defender Firewall) odrzuca połączenia na porcie 80 lub 443
• Reverse proxy (HAProxy, Nginx, Cloudflare) jest skonfigurowany nieprawidłowo i zwraca pakiety RST w górę
• Aplikacja za proxy uległa awarii, pozostawiając proxy bez backendu do przekierowania

Przyczyny główne: Strukturalny przegląd

Przyczyny po stronie klienta

Przyczyny po stronie serwera

Przewodnik diagnostyki i naprawy krok po kroku

Krok 1: Określ, czy problem jest globalny czy lokalny

Zanim dotkniesz jakichkolwiek ustawień lokalnych, ustal, czy witryna jest niedostępna dla wszystkich, czy tylko dla Ciebie. Użyj tych narzędzi:

• downforeveryoneorjustme.com — proste sprawdzenie 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 węzłów zewnętrznych, ale nie z Twojego komputera, problem jest lokalny. Jeśli jest niedostępna globalnie, problem jest po stronie serwera i poza Twoją kontrolą — skontaktuj się z administratorem witryny lub czekaj.

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

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

Jeśli administrujesz danym serwerem, zaloguj się przez SSH i uruchom poniższe polecenie, aby potwierdzić, co nasłuchuje na jakich portach:

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

Jeśli wynik jest pusty dla portu 80 lub 443, proces serwera WWW nie jest uruchomiony. 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 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 uruchamiających Dedicated Servers, sprawdź również, czy zapora upstream dostawcy hostingu lub reguły grupy bezpieczeństwa nie blokują portu na obwodzie sieci — jest to oddzielone od zapory 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 tabele NAT, dzierżawy DHCP i wszelkie przejściowe błędy routingu. Odłącz router na 30 sekund, a następnie podłącz ponownie. Jest to szczególnie skuteczne, gdy błąd pojawił się nagle bez żadnych zmian konfiguracji.

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

Stary wpis w pamięci podręcznej DNS wskazujący na stary lub wycofany adres IP jest jedną z najczęstszych przyczyn ERR_CONNECTION_REFUSED po stronie klienta. Serwer pod buforowanym adresem IP może już nie uruchamiać docelowej witryny.

• W systemie Windows:

ipconfig /flushdns

• Na 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, sprawdź, na jaki adres IP domena się teraz rozwiązuje:

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

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

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

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 i Pliki cookie i inne dane witryn, a następnie kliknij Wyczyść dane. Całkowicie uruchom ponownie Chrome (nie tylko kartę) przed ponownym testowaniem.

Aby szybciej przetestować bez czyszczenia danych, otwórz okno Incognito (Ctrl + Shift + N). Jeśli witryna ładuje się w Incognito, ale nie w normalnym oknie, buforowany zasób lub rozszerzenie przeglądarki jest winne.

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

Źle skonfigurowany lub martwy 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 > Proxy i wyłącz „Użyj serwera proxy”, jeśli jest włączony bez Twojej wiedzy. Alternatywnie uruchom to z wiersza polecenia z podwyższonymi uprawnieniami:

netsh winhttp reset proxy

• Na macOS

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

Po wyłączeniu proxy przetestuj witrynę. Jeśli się ładuje, konfiguracja proxy była przyczyną. Albo skonfiguruj ją prawidłowo, albo usuń ją całkowicie.

Krok 7: Zmień resolver DNS

Domyślny resolver DNS Twojego dostawcy internetu może zwracać nieprawidłowe wyniki, doświadczać awarii lub aktywnie blokować określone domeny. Przełączenie na publiczny resolver eliminuje tę zmienną.

Rekomendowani publiczni resolvery DNS:

• W systemie Windows (za pośrednictwem PowerShell):

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

• Na macOS:

Przejdź do Ustawienia systemowe > Sieć > [Twój interfejs] > Szczegóły > DNS, usuń istniejące wpisy i dodaj 1.1.1.1 i 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ę i oprogramowanie antywirusowe

Niektóre produkty antywirusowe i zapory oparte na hoście przechwytują ruch HTTPS za pośrednictwem lokalnego proxy i mogą wysyłać pakiety RST, gdy ich silnik inspekcji zawiedzie lub gdy domena docelowa znajduje się na liście blokowania. Tymczasowe wyłączenie ich (wyłącznie w celach diagnostycznych) potwierdza, czy są przyczyną.

Jeśli wyłączenie oprogramowania bezpieczeństwa rozwiąże błąd, dodaj konkretny wyjątek dla domeny docelowej zamiast pozostawiać oprogramowanie wyłączone. Natychmiast włącz je ponownie po testowaniu.

Krok 9: Przetestuj za pomocą innej przeglądarki i sieci

Przetestuj adres URL w Firefox, Edge lub Safari. Jeśli ładuje się w innej przeglądarce, problem jest specyficzny dla Chrome — prawdopodobnie uszkodzony profil, wadliwe rozszerzenie lub ustawienie proxy specyficzne dla Chrome. Spróbuj utworzyć nowy profil Chrome, aby wyizolować problem.

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

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

Źle skonfigurowany certyfikat SSL może spowodować, że serwer ulegnie awarii lub odmówi połączeń TLS, które Chrome raportuje jako ERR_CONNECTION_REFUSED zamiast błędu certyfikatu w niektórych przypadkach brzegowych. Użyj poniższego do testowania z wiersza polecenia:

curl -vI https://yourdomain.com

Poszukaj etapu uzgadniania TLS w szczegółowym wyjściu. Awaria tutaj 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 Twój certyfikat SSL wygasł lub jest źle skonfigurowany, odnowienie lub zastąpienie go rozwiąże problem. Upewnij się, że Twoje SSL Certificates są ważne, prawidłowo połączone i zainstalowane na prawidłowym interfejsie serwera.

ERR_CONNECTION_REFUSED vs. Podobne błędy przeglądarki

Zrozumienie różnic między tym błędem a błędami pokrewnymi zapobiega błędnej diagnozie:

Zaawansowane przypadki brzegowe i pułapki

1) Konflikty rozdzielczości IPv6 vs. IPv4:

Jeśli domena rozwiązuje się na adres IPv6, ale Twoja sieć nie obsługuje prawidłowo IPv6, Chrome może spróbować połączenia IPv6, które zostanie odrzucone, a następnie nie powróci szybko do IPv4. Tymczasowe wyłączenie IPv6 na karcie sieciowej może to potwierdzić. Na Linux możesz wymusić IPv4 za pomocą curl -4 https://example.com.

2) Cloudflare lub buforowanie CDN starych błędów pochodzenia:

Jeśli witryna używa Cloudflare i serwer pochodzenia ulegnie awarii, Cloudflare może przez pewien czas serwować wersję buforowaną, a następnie zacząć zwracać błędy 521 (origin refused connection) lub 522, które Chrome może wyświetlić jako ERR_CONNECTION_REFUSED w zależności od sposobu, w jaki błąd jest pośredniczony.

3) Lokalne środowiska programistyczne:

Programiści często widzą ERR_CONNECTION_REFUSED podczas uzyskiwania dostępu do localhost:3000 lub podobnych. Przyczyna jest prawie zawsze taka, że proces serwera programistycznego nie jest uruchomiony, 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 potwierdzić, co faktycznie nasłuchuje.

4) Konflikty portów serwera poczty:

Jeśli uruchamiasz Email Hosting na tym samym serwerze co aplikacja internetowa, upewnij się, że konflikty portów między SMTP (25, 587), IMAP (993) i HTTP/HTTPS (80, 443) nie powodują, że serwer internetowy nie może się powiązać.

5) Ograniczenia hostingu współdzielonego:

W środowiskach Shared Web Hosting odmowa połączenia może wskazywać, że serwer dostawcy hostingu jest przeciążony, konto zostało zawieszone lub DNS domeny nie wskazuje jeszcze na prawidłowy współdzielony IP. Sprawdź panel sterowania hostingu, aby uzyskać stan konta i konfigurację DNS.

Praktyczna Macierz Decyzji: Które Naprawienie Zastosować Pierwsze

Użyj tej listy kontrolnej do efektywnej triage:

• Błąd pojawia się na wszystkich stronach internetowych jednocześnie — Najpierw sprawdź ustawienia proxy i konfigurację VPN/firewall
• Błąd pojawia się tylko na jednej konkretnej domenie — Sprawdź, czy strona 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 na danych mobilnych — Uruchom ponownie router; sprawdź DNS na poziomie ISP lub firewall
• Błąd pojawia się po zmianie konfiguracji serwera — Sprawdź status procesu serwera WWW, powiązania portów i reguły firewall na serwerze
• Błąd pojawia się sporadycznie pod obciążeniem — 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 — Przywróć zmiany DNS i wyczyść pamięć podręczną; sprawdź, czy nowy resolver jest osiągalny

FAQ

1) 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, odrzucając połączenie natychmiast. ERR_CONNECTION_TIMED_OUT oznacza, że w okresie timeout nie otrzymano żadnej odpowiedzi — pakiety zostały dyskretnie porzucone. Odrzucone połączenie pojawia się szybciej i wskazuje na aktywne odrzucenie, podczas gdy timeout sugeruje regułę routingu lub zapory DROP.

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

Pośrednio, tak. W niektórych konfiguracjach serwera 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łuchiwacza na porcie 443. Chrome następnie raportuje ERR_CONNECTION_REFUSED, ponieważ nic nie nasłuchuje, chociaż podstawową przyczyną jest problem z certyfikatem.

3) Dlaczego ERR_CONNECTION_REFUSED pojawia się tylko na jednej konkretnej stronie?

Jeśli błąd dotyczy tylko jednej domeny, najprawdopodobniejszymi przyczynami są: usługa WWW na serwerze docelowym uległa awarii, zapora sieciowa serwera blokuje Twój zakres IP, 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 wyizolować przyczynę.

4) Jak naprawić ERR_CONNECTION_REFUSED na localhost?

Serwer aplikacji nie jest uruchomiony lub jest powiązany z innym portem niż ten, który żądasz. Potwierdź, co nasłuchuje za pomocą ss -tlnp na Linux/macOS lub netstat -ano | findstr :PORT na 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.

5) Czy czyszczenie DNS zawsze naprawia ERR_CONNECTION_REFUSED?

Tylko wtedy, gdy główną przyczyną jest przestarzały wpis w pamięci podręcznej DNS wskazujący na adres IP, gdzie usługa już nie działa. Jeśli serwer jest wyłączony, zapora blokuje połączenie lub proxy jest błędnie skonfigurowany, czyszczenie DNS nie będzie miało żadnego efektu. Użyj dig lub nslookup, aby zweryfikować rozdzielczość DNS przed i po czyszczeniu, aby potwierdzić, czy DNS był rzeczywiście problemem.