ERR_CONNECTION_REFUSED: serwer odrzucił połączenie, co robić

Czym jest błąd ERR_CONNECTION_REFUSED?

ERR_CONNECTION_REFUSED oznacza, że przeglądarka znalazła adres IP strony, ale maszyna pod tym adresem odrzuciła połączenie. Chrome pokazuje „Ta witryna jest nieosiągalna” z komunikatem „Serwer example.com odrzucił połączenie.” i kodem ERR_CONNECTION_REFUSED, czyli błędem -102 z listy Chromium (net_error_list.h).

Twoje urządzenie wysłało żądanie połączenia TCP na adres IP i port serwera (443 dla HTTPS, 80 dla HTTP) i od razu dostało odmowę: albo reset TCP, albo komunikat zapory „port unreachable” (port nieosiągalny). Żaden program nie przyjmował połączeń na tym porcie albo zapora odrzuciła żądanie. DNS zadziałał, połączenie nie.

Innymi słowy, to odpowiedź, a nie cisza. Jeśli nic nie odpowiada, Chrome czeka i pokazuje ERR_CONNECTION_TIMED_OUT. Jeśli połączenie się otwiera, a potem zostaje przerwane, to ERR_CONNECTION_RESET; jeśli serwer rozłącza się przed wysłaniem strony, to ERR_CONNECTION_CLOSED.

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

Odrzucone połączenie to to samo zdarzenie wszędzie; zmienia się tylko komunikat. Przeglądarki oparte na Chromium (Chrome, Edge, Brave, Opera) pokazują kod ERR_CONNECTION_REFUSED, a aplikacje zgłaszają błąd własny systemu operacyjnego:

Poniższe rozwiązania działają niezależnie od komunikatu: coś pod tym adresem i portem odpowiedziało „nie”.

Najczęstsze przyczyny błędu ERR_CONNECTION_REFUSED

Przyczyny, od strony witryny po Twoją:

• Serwer strony nie działa — serwer WWW (nginx, Apache, Node.js) uległ awarii, restartuje się albo został zatrzymany. Maszyna jest online, ale nic nie odpowiada na porcie 80 ani 443.
• Zapora ustawiona na odrzucanie — zapora na serwerze, w Twojej sieci albo na Twoim urządzeniu, która odrzuca (zamiast po cichu porzucać) połączenia z tym portem.
• Strona blokuje Twoją sieć — niektóre strony odrzucają całe zakresy adresów, na przykład serwery wyjściowe VPN albo cały kraj.
• Oprogramowanie zabezpieczające lub VPN — moduł ochrony WWW w antywirusie albo VPN, który przepuszcza Twój ruch przez siebie i odrzuca połączenie. (Zapora na Twoim urządzeniu, która blokuje Chrome, pokazuje inną stronę, „Masz zablokowany dostęp do internetu”, ERR_NETWORK_ACCESS_DENIED.)
• Zły adres IP — nieaktualna pamięć podręczna DNS albo wpis w pliku hosts kieruje Cię na stary serwer albo na Twój własny komputer (127.0.0.1), gdzie nic nie nasłuchuje.
• Zapamiętane przekierowanie lub reguła HTTPS — Chrome zapamiętał przekierowanie albo regułę HSTS strony i nadal wysyła Cię na port, którego strona już nie obsługuje.
• Nic nie nasłuchuje na localhost — dla programistów: lokalny serwer nie działa, uległ awarii albo działa na innym porcie lub adresie niż ten, który otwierasz w przeglądarce.

Jedna strona, wszystkie strony czy wszystkie przeglądarki?

To, gdzie pojawia się błąd, podpowiada, gdzie szukać, zanim cokolwiek zmienisz:

„We wszystkich przeglądarkach” ma znaczenie: Edge, Firefox i Safari nie dzielą pamięci podręcznej ani rozszerzeń Chrome, więc odmowa we wszystkich wskazuje na coś poniżej przeglądarki: Twoje urządzenie, sieć albo samą stronę.

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

Zanim cokolwiek zmienisz na swoim urządzeniu, ustal, czy strona odrzuca wszystkich. Jeśli tak, żadna poprawka po Twojej stronie nie pomoże.

Najszybszy test to inna ścieżka sieciowa: otwórz stronę na telefonie przez dane komórkowe (Wi-Fi wyłączone). Potem sprawdź serwer z zewnątrz tymi narzędziami DNS Robot:

• Sprawdzanie, czy strona działa — otwiera stronę z 11 miejsc i z Twojej własnej przeglądarki. Nie działa nigdzie: to strona. Działa wszędzie poza Tobą: problem jest po Twojej stronie.
• Port checker — wpisz stronę z portem 443 (albo example.com:443). Zamknięty oznacza, że serwer odrzucił także nasze połączenie; otwarty, że przyjmuje połączenia, a odmowa dotyczy tylko Ciebie.
• Test Ping — łączy się ze stroną na porcie 443 z 11 miast, plus klasyczny ping z jednego. Odmowa z każdego miasta oznacza, że maszyna działa, ale nic nie nasłuchuje na tym porcie; brak odpowiedzi na klasyczny ping niczego nie dowodzi, bo wiele serwerów go ignoruje.

Rozwiązanie 2: zrestartuj router i urządzenie

Pierwsza podpowiedź Chrome, „Sprawdź połączenie”, mówi, by uruchomić ponownie „wszelkie używane routery, modemy i inne urządzenia sieciowe”. Czyści to stan, który zgromadził router, w tym jego pamięć podręczną DNS.

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ść zapamiętane w Chrome przekierowania i reguły HTTPS

Chrome zapamiętuje stałe przekierowania oraz regułę HSTS każdej strony („zawsze używaj HTTPS”). Jeśli strona się przeniosła albo przestała obsługiwać HTTPS na porcie 443, Chrome nadal wysyła Cię pod adres lub na port, gdzie nic nie nasłuchuje.

• Otwórz Chrome → menu z trzema kropkami → Usuń dane przeglądania
• Zakres czasu → Od początku, zaznacz Obrazy i pliki zapisane w pamięci podręcznej (pliki cookie mogą zostać)
• Kliknij Usuń dane (albo Usuń z tego urządzenia, jeśli nie jesteś zalogowany w Chrome), a potem otwórz stronę ponownie
• Nadal odrzuca? Otwórz chrome://net-internals/#hsts, wpisz domenę w polu Delete domain security policies i kliknij Delete. Działa to tylko dla reguł ustawionych przez samą stronę, nie dla domen wbudowanych w listę wstępnego ładowania HSTS Chrome.

Jedna zmiana z 2026 roku: Chrome 154 (październik 2026) domyślnie włącza „Zawsze używaj bezpiecznych połączeń”, więc przed pierwszą wizytą na publicznej stronie bez HTTPS Chrome pyta o Twoją zgodę, zamiast po cichu próbować (Google Security Blog).

Rozwiązanie 4: sprawdź ustawienia proxy

Strona błędu Chrome wymienia serwer proxy, więc go sprawdź, ale wiedz, czego się spodziewać. Gdy Chrome nie może połączyć się z serwerem proxy, pokazuje stronę z nagłówkiem „Brak internetu” i kodem ERR_PROXY_CONNECTION_FAILED („Serwer proxy działa nieprawidłowo albo adres jest błędny.”), a nie ERR_CONNECTION_REFUSED. Jeśli widzisz właśnie tę stronę, to jest Twoje rozwiązanie.

Windows: Ustawienia → Sieć i Internet → Serwer proxy. W sekcji „Ręczna konfiguracja serwera proxy” kliknij Edytuj (albo Konfiguruj) obok „Użyj serwera proxy”, wyłącz tę opcję i kliknij Zapisz. Wyłącz też „Użyj skryptu konfiguracji”, jeśli nie rozpoznajesz adresu. Zostaw włączone „Automatycznie wykryj ustawienia”, chyba że wiesz, że Twoja sieć z tego nie korzysta.

macOS: Ustawienia systemowe → Sieć → Wi-Fi → Szczegóły → Proxy. Wyłącz wszystkie serwery proxy, których nie skonfigurowała Twoja organizacja, a potem kliknij OK.

Chrome korzysta z systemowych ustawień proxy, a Firefox domyślnie też („Używaj systemowych ustawień serwerów proxy”), więc jeden nieaktualny serwer proxy psuje wszystkie przeglądarki naraz. Na urządzeniu szkolnym lub służbowym proxy ustawia administrator i nie możesz go zmienić.

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

Jeśli strona przeniosła się na nowy serwer, zapisana w pamięci podręcznej odpowiedź DNS może nadal wskazywać stary adres IP, gdzie nic już nie nasłuchuje. Wyczyszczenie sprawia, że urządzenie sprawdzi aktualny adres.

# 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 chrome://net-internals/#dns i zrzuć pule gniazd pod chrome://net-internals/#sockets. Chrome trzyma obie osobno od systemu operacyjnego. Pełny opis znajdziesz w naszym poradniku jak wyczyścić DNS w każdym systemie.

Aby zobaczyć adres, którego komputer faktycznie używa (z plikiem hosts i pamięcią podręczną), uruchom ping example.com albo Resolve-DnsName example.com w PowerShellu i porównaj z wynikiem „Sprawdź rekordy DNS”. Nie używaj do tego nslookup: pyta on serwer DNS bezpośrednio i pomija jedno i drugie.

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

Jeśli resolver Twojego dostawcy internetu po wyczyszczeniu nadal podaje stary adres, przełącz się na publiczny resolver, żeby dostać świeżą odpowiedź.

Windows: Ustawienia → Sieć i Internet → Wi-Fi → „Zarządzaj znanymi sieciami” → Twoja sieć (Ethernet → Twoja sieć) → Edytuj obok „Przypisanie serwera DNS” → Ręcznie → włącz IPv4 → Preferowany serwer DNS 1.1.1.1, Alternatywny serwer DNS 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 Test szybkości DNS od DNS Robot: w kilka sekund porówna Cloudflare, Google, Quad9 i innych 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 stoją między Twoją przeglądarką a internetem i każde z nich może odrzucić połączenie. Moduły, które skanują HTTPS, przepuszczają Twój ruch przez lokalną usługę; jeśli ta usługa przestanie działać, strony HTTPS mogą przestać działać we wszystkich przeglądarkach naraz. A niektóre strony po prostu odrzucają adresy VPN.

Testuj po kolei: odłącz VPN i odśwież stronę. Potem wstrzymaj na minutę ochronę WWW w antywirusie i odśwież. Na końcu wstrzymaj każdą zaporę innej firmy, często będącą częścią pakietu antywirusowego. (Zapora macOS filtruje tylko połączenia przychodzące, a Zapora Windows Defender przepuszcza ruch wychodzący, chyba że ktoś dodał regułę. Jeśli Chrome pokazuje „Masz zablokowany dostęp do internetu”, przyczyną jest zapora na Twoim urządzeniu.)

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 wybierz inny serwer VPN, zamiast zostawiać ochronę wyłączoną.

Rozwiązanie 8: przetestuj rozszerzenia w trybie incognito

Rozszerzenia rzadko powodują ten kod: rozszerzenie, które blokuje stronę, pokazuje ERR_BLOCKED_BY_CLIENT. Ale okno incognito (Ctrl+Shift+N, a na Macu Cmd+Shift+N) to dziesięciosekundowy test, który wyklucza naraz rozszerzenia i dane z pamięci podręcznej, bo rozszerzenia są tam wyłączone, o ile nie zostały tam włączone.

Jeśli strona ładuje się w trybie incognito, wejdź na chrome://extensions, wyłącz wszystkie, a potem włączaj je pojedynczo, aż błąd wróci. Jeśli nadal nie działa w trybie incognito, przyczyna jest poza Chrome.

Rozwiązanie 9: sprawdź plik hosts

Plik hosts nadpisuje DNS dla nazw, które zawiera. Jeśli strona jest w nim przypisana do 127.0.0.1 albo do adresu IP starego serwera, przeglądarka łączy się właśnie tam i dostaje odmowę. Typowi podejrzani to pozostawione wpisy deweloperskie i listy hosts blokujące reklamy, a plik wpływa na każdą przeglądarkę.

# 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.

Rozwiązanie 10: na Androidzie lub iPhonie

Telefony odrzucają połączenia z tych samych powodów, tylko przełączniki są inne:

• Zmień sieć: załaduj stronę przez dane komórkowe, potem przez Wi-Fi. Jeśli odmawia tylko jedna z nich, problemem jest ta sieć, nie telefon.
• Wyłącz aplikacje VPN, także blokery reklam i zapory działające jako VPN (pokazują klucz albo ikonę VPN na pasku stanu).
• Usuń proxy sieci Wi-Fi: na Androidzie otwórz ustawienia sieci Wi-Fi → ikona ołówka (Zmień) → Opcje zaawansowane → Serwer proxy → Brak (nazwy różnią się zależnie od producenta telefonu). Na iPhonie: Ustawienia → Wi-Fi → ⓘ obok sieci → Konfiguruj proxy → „Off” (wyłączone).
• Wyczyść dane Chrome: Chrome → Ustawienia → Prywatność i bezpieczeństwo → Usuń dane przeglądania → Obrazy i pliki zapisane w pamięci podręcznej.
• Testujesz własny serwer? Na telefonie localhost to sam telefon. Użyj zamiast tego lokalnego adresu IP swojego komputera (zobacz następną sekcję).

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

Komunikat localhost odrzucił połączenie albo ERR_CONNECTION_REFUSED na 127.0.0.1 oznacza, że nic na Twojej maszynie nie przyjmuje połączeń na adresie i porcie, które otwierasz. Zwykłe powody:

• Serwer deweloperski nie działa — nie został uruchomiony albo uległ awarii. 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 (na przykład 3001, bo 3000 był zajęty). Skopiuj adres z jego komunikatu startowego.
• Brak portu w adresie — http://localhost prowadzi na port 80, a serwery deweloperskie używają własnych (3000, 5173, 8000, 8080).
• 127.0.0.1 a [::1] — przeglądarki próbują obu adresów dla localhost, ale serwer może nasłuchiwać tylko na jednym z nich. Otwarcie drugiego adresu wprost (http://127.0.0.1:3000 lub http://[::1]:3000) albo połączenie z narzędzia, które próbuje tylko jednego, kończy się odmową.
• W Dockerze — aplikacja musi nasłuchiwać na 0.0.0.0 wewnątrz kontenera, a port musi być opublikowany (-p 3000:3000). Aplikacja związana z 127.0.0.1 w kontenerze jest nieosiągalna z Twojej maszyny (zamiast tego możesz zobaczyć ERR_EMPTY_RESPONSE).
• Z telefonu lub emulatora — tam localhost to samo urządzenie. Użyj adresu IP LAN swojego komputera i uruchom serwer deweloperski na wszystkich interfejsach (Vite: --host), albo 10.0.2.2 z emulatora Androida, jego aliasu dla localhost komputera.

# What is listening on port 3000?
# macOS / Linux:
lsof -nP -iTCP:3000 -sTCP:LISTEN

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

# No output = nothing is listening = connection refused.
# 127.0.0.1:3000 in the output = IPv4 only; [::1]:3000 = IPv6 only.

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 tak, jak widzą je Twoi odwiedzający.

„Odrzucił połączenie” wewnątrz osadzonej strony

Jeśli „Serwer example.com odrzucił połączenie.” pojawia się w ramce na innej stronie (osadzony formularz, raport, mapa albo logowanie), zwykle nie jest to problem sieci. Chrome pokazuje to samo zdanie, gdy osadzana strona zabrania wyświetlania w stronach innych witryn przez nagłówek X-Frame-Options lub Content-Security-Policy: frame-ancestors. Wewnętrznie to ERR_BLOCKED_BY_RESPONSE, błąd -27 (net_error_list.h).

Jako odwiedzający otwórz osadzony link w osobnej karcie; tam się załaduje. Jako właściciel strony zezwól stronie, która Cię osadza, przez Content-Security-Policy: frame-ancestors 'self' https://parent.example. X-Frame-Options może tylko powiedzieć DENY albo SAMEORIGIN, a obecne przeglądarki stosują frame-ancestors, gdy strona wysyła oba. Sprawdź, co wysyła Twoja strona, w Checkerze nagłówków HTTP, a dokładne nagłówki podaje nasz poradnik o X-Frame-Options.

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

Jeśli odwiedzający zgłaszają ERR_CONNECTION_REFUSED na Twojej stronie, ich pakiety docierają do maszyny pod Twoim adresem IP, ale nic tam nie przyjmuje połączenia. Przejdź przez tę listę kontrolną:

• Czy serwer WWW działa? Połącz się przez SSH i sprawdź systemctl status nginx (albo apache2, caddy). Serwer, który nie wystartował po restarcie przez błędną konfigurację albo został zabity, gdy maszynie zabrakło pamięci, nie zostawia nic nasłuchującego. Uruchom go ponownie przez sudo systemctl restart nginx.
• Czy nasłuchuje na właściwych portach i adresach? Uruchom ss -tlnp | grep -E ':(80|443) '. Serwer nasłuchujący tylko na 127.0.0.1 odrzuca wszystkich z zewnątrz; brak czegokolwiek na 443 oznacza, że żaden blok serwera tam nie nasłuchuje (HTTPS nigdy nie skonfigurowano albo plik strony nie jest włączony). nginx -T wypisuje konfigurację, która jest faktycznie załadowana.
• Czy zapora odrzuca? Reguła ustawiona na odrzucanie (iptables REJECT, ufw reject) wysyła odmowy. Domyślne deny w ufw i zapory chmurowe, takie jak grupy zabezpieczeń AWS, porzucają pakiety po cichu, co odwiedzający widzą jako ERR_CONNECTION_TIMED_OUT.
• Czy fail2ban kogoś zbanował? Jego domyślny ban odrzuca zbanowany adres, więc ten odwiedzający (albo Ty, po kilku nieudanych logowaniach SSH) dostaje ERR_CONNECTION_REFUSED, a wszyscy inni wchodzą. Sprawdź sudo fail2ban-client status.
• Czy zmienił się adres IP serwera? Porównaj rekord A z prawdziwym adresem IP serwera w „Sprawdź rekordy DNS”. Po migracji stary rekord A kieruje odwiedzających na poprzednią maszynę.
• Za Cloudflare? Przy rekordach z włączonym proxy (pomarańczowa chmurka) odwiedzający łączą się z Cloudflare, nie z Tobą, więc nie zobaczą tego kodu. Gdy Twój serwer źródłowy odrzuca połączenia Cloudflare, Cloudflare pokazuje własny Error 521: Web server is down.
• Testuj z zewnątrz: Port checker na portach 80 i 443 oraz Checker nagłówków HTTP dla prawdziwego żą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 -w 5 example.com 443
# "succeeded" = port open, "refused" = still rejected

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

# Then confirm the address your computer actually uses:
ping -c 1 example.com          # Mac/Linux
Resolve-DnsName example.com    # Windows PowerShell

Albo pomiń terminal: wpisz domenę i port w Port checkerze od DNS Robot, aby dostać odpowiedź otwarty/zamknięty spoza Twojej sieci. Jeśli port jest otwarty z zewnątrz, a Twoja przeglądarka nadal pokazuje ERR_CONNECTION_REFUSED, blokada jest na Twoim urządzeniu lub w sieci: wróć do rozwiązań dotyczących VPN, oprogramowania zabezpieczającego i pliku hosts.