ERR_CONNECTION_REFUSED: co oznacza i jak naprawić

Co oznacza ERR_CONNECTION_REFUSED

Połączenie TCP zaczyna się od handshake'u: klient wysyła pakiet SYN, a serwer odpowiada SYN-ACK, jeśli jakiś proces jest przypięty do tego portu. Gdy żaden proces nie nasłuchuje, stos sieciowy systemu operacyjnego odsyła zamiast tego pakiet RST, natychmiast kończąc próbę. To właśnie ten RST produkuje ERR_CONNECTION_REFUSED w Chrome i jego odpowiedniki w innych przeglądarkach. Połączenie dotarło do maszyny docelowej i dostało wyraźne "nie", co odróżnia ten błąd od timeoutu, gdzie nic w ogóle nie odpowiada.

Odpowiedź RST pochodzi ze stosu TCP jądra, nie z kodu żadnej aplikacji, dlatego przychodzi w ciągu kilku milisekund zamiast po kilku sekundach oczekiwania. Oznacza to też, że sama maszyna działa i odpowiada na ruch sieciowy; po prostu nic nie jest przypięte do konkretnego portu, do którego celowało żądanie. To rozróżnienie ma znaczenie przy decyzji, od czego zacząć: odrzucone połączenie wskazuje na port i proces za nim, nie na zasilanie serwera ani jego łącze sieciowe.

Jak pojawia się błąd

Chrome pokazuje prostą stronę "This site can't be reached ... ERR_CONNECTION_REFUSED" bez dalszych szczegółów. Firefox zgłasza "Unable to connect" i podaje host i port, których próbował. Linia poleceń daje dokładniejszy obraz:

curl -v https://example.com:8443/
* Trying 203.0.113.10:8443...
* connect to 203.0.113.10 port 8443 failed: Connection refused
* Failed to connect to example.com port 8443 after 2 ms: Connection refused

Komunikat podaje dokładny port, którego próbował curl, i zgłasza odmowę w ciągu paru milisekund, na tyle szybko, żeby wykluczyć timeout. telnet host port albo nc -zv host port zwracają tę samą linię "Connection refused".

Co powoduje ERR_CONNECTION_REFUSED

• Nic nie nasłuchuje na tym porcie. Serwer WWW, aplikacja albo proxy, które powinno być przypięte do portu, nie działa.
• Usługa się zatrzymała albo zawiesiła. Proces, który się zakończył, został zabity za zużywanie zbyt dużo pamięci, albo został zatrzymany na czas konserwacji, zostawia port odpięty.
• Reguła zapory wprost odrzuca połączenie. Reguła REJECT odsyła ten sam RST co zamknięty port, więc z zewnątrz wygląda identycznie jak brak czegokolwiek tam.
• W URL jest zły port. Literówka, stara zakładka sprzed zmiany portu albo usługa, która przeniosła się na inny port, wszystkie produkują ten błąd wobec starego portu.
• Lokalny serwer deweloperski nie działa. Odrzucone localhost:3000 niemal zawsze oznacza, że serwer deweloperski został zatrzymany albo nigdy nie uruchomiony w tej sesji terminala.
• Proxy albo VPN są źle skonfigurowane. Proxy wskazujące na wyłączony backend, albo klient VPN przepisujący żądania na port, którego nic nie obsługuje, odrzuca połączenie we własnym imieniu.
• Mapowanie portu kontenera nie zgadza się z aplikacją wewnątrz niego. Usługa Docker albo Kubernetes, której opublikowany port różni się od portu, którego faktycznie używa aplikacja, produkuje ten błąd nawet wtedy, gdy sam proces działa i jest zdrowy.

Jak rozpoznać, kto zawinił

Jeśli witryna ładuje się teraz innym osobom, albo ładowała się Tobie minutę temu, problem jest bardziej prawdopodobnie lokalny: VPN, ustawienie proxy albo reguła zapory na Twojej własnej maszynie albo w sieci. Jeśli zawodzi tak samo z telefonu na danych mobilnych, strona serwera odrzuca połączenia dla wszystkich. Uruchomienie kontroli HTTP albo portu z kilku lokalizacji naraz rozstrzyga to w jednym żądaniu; jeśli punkty kontrolne w wielu krajach zgłaszają odrzucone połączenie, przyczyną jest serwer albo jego zapora, nie Twoja sieć.

Jak naprawić ERR_CONNECTION_REFUSED

Jeśli jesteś odwiedzającym

1. Potwierdź URL i port. Sprawdź, czy nie ma literówki, starej zakładki albo linku wciąż wskazującego na wycofany port.
2. Wyłącz VPN albo proxy i przeładuj. Jeśli witryna potem się ładuje, przyczyną jest konfiguracja VPN albo proxy; sprawdź jej ustawienia albo skontaktuj się z tym, kto nią zarządza.
3. Wypróbuj inną sieć, na przykład dane mobilne zamiast Wi-Fi, żeby wykluczyć lokalną zaporę albo regułę routera.
4. Poczekaj i spróbuj ponownie. Jeśli właściciel witryny jest w trakcie wdrożenia albo restartuje usługę, port może być odpięty tylko przez kilka sekund.

Jeśli prowadzisz witrynę

1. Potwierdź, że proces działa i jest przypięty do oczekiwanego portu:

   ss -ltnp | grep :443
   netstat -tlnp | grep :443

   Pusty wynik oznacza, że nic nie nasłuchuje; uruchom usługę albo popraw jej skonfigurowany port.
2. Sprawdź status usługi i logi:

   systemctl status nginx
   journalctl -u nginx -n 50

   Zawieszony albo nieudany unit pokazuje się tutaj, często z powodem, dla którego się zakończył.
3. Sprawdź zaporę pod kątem reguły REJECT na tym porcie:

   iptables -L -n | grep REJECT
   ufw status verbose

   Reguła REJECT wygląda z zewnątrz identycznie jak zamknięty port, więc ten krok łatwo pominąć.
4. Potwierdź, że usługa nasłuchuje na właściwym interfejsie. Serwer przypięty do 127.0.0.1 zamiast do 0.0.0.0 odrzuca każde połączenie przychodzące spoza maszyny, mimo że działa dobrze z lokalnej powłoki.
5. Zrestartuj usługę po naprawieniu konfiguracji i potwierdź, że port jest znów przypięty tym samym poleceniem ss, zanim uznasz problem za rozwiązany.

Jak zapobiec ERR_CONNECTION_REFUSED

Zawieszona usługa albo przypadkowa reguła zapory zwykle objawia się najpierw jako odrzucone połączenia, a nie jako alert z samego serwera, bo proces, który nie działa, nie może zgłosić własnej awarii. Regularne monitorowanie portu wyłapuje to w ciągu minut, łącząc się spoza sieci tak samo, jak zrobiłby to odwiedzający, i wysyła alert e-mailem, SMS-em, połączeniem głosowym, przez Slack, Telegram i inne kanały, gdy tylko kontrola zawiedzie.

Powiązane błędy

• ERR_CONNECTION_TIMED_OUT zdarza się, gdy nic w ogóle nie odpowiada na próbę połączenia, zamiast aktywnie ją odrzucać.
• ERR_CONNECTION_RESET zdarza się, gdy połączenie zostało zaakceptowane, a potem zerwane w połowie.
• This site can't be reached obejmuje cały zestaw błędów połączenia, które Chrome grupuje pod jednym nagłówkiem.

Najczęściej zadawane pytania

Czy ERR_CONNECTION_REFUSED to to samo co blokada przez zaporę?

Może tak być. Reguła REJECT zapory produkuje tę samą odpowiedź RST co zamknięty port, więc z przeglądarki oba wyglądają identycznie. Reguła DROP zachowuje się inaczej i produkuje zamiast tego timeout.

Dlaczego zdarza się to tylko na localhost?

Niemal zawsze dlatego, że lokalny serwer deweloperski nie działa w tym terminalu, został zatrzymany albo zawiesił się przy starcie z powodu błędu w kodzie albo konfiguracji. Sprawdź terminal, w którym zwykle go uruchamiasz, pod kątem komunikatu błędu.

Czy VPN może spowodować ERR_CONNECTION_REFUSED?

Tak. VPN trasujące ruch przez proxy albo bramę może odrzucić połączenie w imieniu bramy, jeśli jej własny backend jest niedostępny, mimo że sam docelowy serwer działa poprawnie.

Czy ERR_CONNECTION_REFUSED oznacza, że witryna nie działa dla wszystkich?

Niekoniecznie. Przetestuj z drugiej sieci albo uruchom kontrolę z wielu lokalizacji, zanim to stwierdzisz. Pojedyncza źle skonfigurowana reguła zapory albo lokalny VPN mogą wyprodukować ten sam błąd, podczas gdy witryna działa dobrze dla wszystkich innych.

Jaka jest różnica między odrzuceniem a resetem?

Odrzucenie oznacza, że próba połączenia nigdy się nie zakończyła; cel natychmiast ją odrzucił. Reset oznacza, że połączenie zostało nawiązane i działało, a potem zerwane w połowie, zwykle przez coś dalej na trasie.

Jak dowiedzieć się, jaki proces powinien nasłuchiwać?

Sprawdź własne logi startu aplikacji i jej konfigurację pod kątem portu, którego oczekuje. Jeśli proces działa, ale jest przypięty do innego portu niż ten, którego używa URL, zaktualizuj URL albo konfigurację, żeby były zgodne, a potem potwierdź poleceniem ss -ltnp, że port jest teraz przypięty zgodnie z oczekiwaniem.