Przeczytaj komunikat, zanim cokolwiek zrestartujesz - on mówi, na której warstwie zatrzymało się żądanie. Brak adresu domeny to DNS. Odmowa połączenia to usługa i port. Błąd negocjacji to TLS. Kody 403, 502 i 504 to odpowiedzi HTTP, a Permission denied to uprawnienia w systemie.
Ta strona robi jedną rzecz - prowadzi od widocznego objawu do właściwej procedury naprawy. Jeżeli administrujesz serwerem, przejdź drzewo decyzyjne poniżej. Jeżeli dostępu nie masz, zbierz dane z sekcji dla odwiedzających i przekaż je właścicielowi usługi. Szerszy układ warstw opisuje diagnostyka w architekturze serwera.
Zacznij od komunikatu, nie od listy przyczyn
Najdroższy błąd diagnostyki nie jest techniczny. To godzina spędzona na naprawianiu warstwy, która działa.
Niedziela wieczorem, sklep internetowy przestaje się otwierać. Właściciel restartuje router, czyści pamięć podręczną przeglądarki, prosi znajomego o test z innej sieci. Po godzinie prób ktoś wreszcie czyta komunikat z ekranu: DNS_PROBE_FINISHED_NXDOMAIN. Odpowiedź wisiała tam od początku - nazwa, o którą pyta przeglądarka, nie istnieje w DNS. Router, pamięć podręczna i telefon znajomego nie miały z tym nic wspólnego.
Scenariusz jest wymyślony, mechanizm nie: każdy komunikat pochodzi z konkretnej warstwy i potwierdza dokładnie jeden etap drogi żądania. Zapisz go dosłownie i ustal, skąd przyszedł:
- odpowiedź DNS, taka jak NXDOMAIN, dotyczy pytanej nazwy;
- ERR_CONNECTION_REFUSED to odrzucona próba połączenia, zgłoszona przez stos sieciowy przeglądarki;
- ERR_SSL_PROTOCOL_ERROR to błąd negocjacji TLS, również z przeglądarki;
- 403, 502 i 504 to kody odpowiedzi HTTP - serwer albo proxy zdążyły coś odpowiedzieć;
- Permission denied przychodzi z systemu operacyjnego, nie z sieci.
Nie wyprowadzaj przyczyny z czasu pojawienia się błędu. Strona, która padła natychmiast, nie dowodzi 502, a długie ładowanie nie dowodzi 504 - rozstrzygają kod odpowiedzi i wpis proxy dla tego samego żądania. Pamiętaj też, że odpowiedź z jednej warstwy nie mówi nic o stanie pozostałych: rozwiązana nazwa nie obiecuje działającej aplikacji.
Drzewo diagnostyczne od objawu do warstwy
Odpowiadaj na pytania zgodnie z komunikatem, który masz przed sobą - drzewo poprowadzi cię do jednego z siedmiu zakończeń. Każde z nich nazywa objaw, warstwę i procedurę, w której zaczyna się właściwa naprawa.
Domena nie daje adresu?
DNS_PROBE_FINISHED_NXDOMAIN to komunikat oparty na odpowiedzi DNS o kodzie NXDOMAIN: nazwa domenowa, o którą pyta przeglądarka, nie istnieje (RFC 1035, RFC 8020). Żądanie zatrzymało się na warstwie nazw - do twojego serwera WWW w ogóle nie dotarło, więc jego stan pozostaje niewiadomą.
Sprawdzanie aplikacji, restart usług i czytanie logów HTTP nic tu nie wniesie. Przejdź do procedury gdy DNS zwraca NXDOMAIN i tam ustal, co dzieje się z nazwą. Rekordy DNS i delegację domeny opisujemy w osobnych tekstach - tutaj zostajesz przy wyborze właściwej diagnozy.
Nazwa działa, ale połączenie jest odrzucane?
Rozwiązana nazwa potwierdza tylko warstwę DNS. Następny krok to połączenie z konkretnym adresem i portem - i właśnie ono zostało odrzucone. W systemie ten stan nosi nazwę ECONNREFUSED: próba connect() nie znalazła procesu nasłuchującego pod adresem zdalnym. Chromium pokazuje go jako ERR_CONNECTION_REFUSED.
To nie jest timeout ani odpowiedź HTTP - odmowa przyszła przy samym zestawianiu połączenia, zanim jakikolwiek protokół wyższej warstwy zdążył się odezwać. Które testy wykonać i w jakiej kolejności, znajdziesz w procedurze odrzuconej próby połączenia.
Połączenie pada przy negocjacji TLS?
Przy adresie https przeglądarka najpierw uwierzytelnia serwer i zestawia zabezpieczone połączenie TLS, a dopiero potem wysyła żądanie HTTP (RFC 9110). Komunikat ERR_SSL_PROTOCOL_ERROR znaczy, że negocjacja się nie powiodła i do wymiany HTTP w ogóle nie doszło.
Certyfikatem i konfiguracją zajmiesz się w procedurze błędu protokołu TLS. Tutaj wystarczy ustalenie, że objaw dotyczy warstwy TLS, a nie kodów odpowiedzi HTTP.
Serwer odpowiada, ale kodem błędu
Odpowiedź HTTP to dla diagnozy dobra wiadomość: żądanie przeszło DNS, połączenie i TLS, a serwer albo proxy miały coś do powiedzenia. Teraz liczy się znaczenie samego kodu.
403 - serwer zrozumiał żądanie i odmawia
Kod 403 oznacza, że serwer zrozumiał żądanie, ale odmawia jego realizacji (RFC 9110). Nie myl go z systemowym Permission denied - tamten komunikat nie przychodzi przez sieć i ma inną warstwę oraz inny log. Co sprawdzić po kolei, opisuje procedura odmowy HTTP 403.
502 - proxy dostało nieprawidłową odpowiedź
Kod 502 znaczy, że gateway albo proxy otrzymały nieprawidłową odpowiedź od serwera, do którego zwróciły się podczas realizacji żądania. Szukasz więc problemu w rozmowie proxy z aplikacją, nie w przeglądarce. Kolejne testy prowadzi procedura nieprawidłowej odpowiedzi upstreamu.
504 - proxy nie doczekało się odpowiedzi
Kod 504 znaczy, że gateway albo proxy nie dostały na czas odpowiedzi upstreamu potrzebnej do zakończenia żądania. Granicę między 502 a 504 wyznaczają kod i wpis w logu proxy dla tego samego żądania, nie to, jak długo strona się ładowała. Dalej prowadzi procedura braku terminowej odpowiedzi upstreamu.
Terminal zwraca Permission denied?
Permission denied nie przychodzi z sieci - zgłasza je system operacyjny albo proces, gdy operacji zabrakło uprawnienia. Pod spodem kryje się błąd EACCES z POSIX. Z kodem HTTP 403 łączy go tylko słowo odmowa: warstwa, log i naprawa są inne.
Ustal, jaka operacja i jaki użytkownik dostały odmowę, a kolejne kroki przejdź w procedurze odmowy uprawnienia w systemie.
Nie masz dostępu do serwera?
Możesz zrobić jedno, za to porządnie: zabezpieczyć sygnał dla osoby, która dostęp ma. Zanim napiszesz zgłoszenie:
- Zapisz komunikat dosłownie, bez parafrazy - „strona nie działa" nie mówi nic, DNS_PROBE_FINISHED_NXDOMAIN mówi bardzo dużo.
- Zanotuj pełny adres, który wywołuje błąd, i czynność, którą wykonywałeś.
- Dopisz moment wystąpienia razem ze strefą czasową.
- Sprawdź, czy objaw dotyczy jednej podstrony, czy całej witryny.
Czyszczenie pamięci podręcznej, zmiana DNS i restart routera zmieniają twoje otoczenie, nie serwer - nie przedstawiaj ich sobie ani nikomu jako naprawy błędu po stronie usługi. Komplet zebranych danych przekaż właścicielowi bez zamiany nazw komunikatów na własną diagnozę.
A jeśli zawodzi cudza usługa?
Jeżeli nie administrujesz usługą, nie przechodź procedur własnego serwera tylko dlatego, że objaw wygląda znajomo. Zamiast tego przejdź do sprawdzania statusu zewnętrznego dostawcy: oficjalny komunikat, sygnały innych użytkowników i prosty test lokalny rozstrzygają, czy czekasz na naprawę po tamtej stronie, czy szukasz problemu u siebie.
Osobne instrukcje prowadzą przez Cloudflare i jego komponenty sieciowe, GitHub i operacje developerskie, ChatGPT i oddzielny stan API, Slacka jako kanał firmowej komunikacji, infrastrukturę OVHcloud według produktu i regionu oraz BaseLinkera wraz z integracjami sprzedażowymi.
Pytania o diagnostykę serwera
Od czego zacząć diagnostykę błędu serwera?
Od dokładnego komunikatu, zapisanego bez parafrazy. Ustal, czy dostałeś odpowiedź DNS, czy połączenie zostało odrzucone, czy nie powiodła się negocjacja TLS, czy serwer zwrócił kod HTTP. Komunikat z terminala, taki jak Permission denied, oddziel od błędów sieciowych - należy do uprawnień w systemie, nie do protokołów. Dopiero potem wybierz procedurę.
Czy ERR_CONNECTION_REFUSED jest kodem HTTP?
Nie. To komunikat Chromium o odrzuconej próbie połączenia - w źródłach przeglądarki nosi wewnętrzny kod -102. Powstaje, zanim serwer zdąży wysłać jakąkolwiek odpowiedź HTTP, więc szukanie kodu 403 albo 502 nie ma tu sensu. Zacznij od sprawdzenia, czy pod wskazanym adresem i portem cokolwiek nasłuchuje.
Czy 403 Forbidden i Permission denied oznaczają to samo?
Nie. Kod 403 jest odpowiedzią HTTP: serwer zrozumiał żądanie i odmawia jego realizacji. Permission denied odpowiada systemowemu błędowi EACCES, czyli odmowie uprawnienia do operacji na pliku albo procesie. Pierwszy objaw diagnozujesz w konfiguracji serwera WWW, drugi w uprawnieniach systemu - każdy ma osobną procedurę naprawy.
Jak odróżnić 502 od 504?
Po kodzie odpowiedzi i wpisie w logu proxy dla tego samego żądania. Kod 502 znaczy, że proxy dostało od serwera nadrzędnego nieprawidłową odpowiedź, a 504 - że nie dostało jej w wymaganym czasie. Czas, po którym błąd pojawił się w przeglądarce, nie rozstrzyga niczego i nie zastępuje odczytu kodu.
Czy błąd DNS oznacza awarię serwera WWW?
Nie. NXDOMAIN mówi tylko, że pytana nazwa domenowa nie istnieje w DNS. Serwer WWW może w tym czasie działać bez zarzutu - żądanie po prostu do niego nie dotarło, bo przeglądarka nie dostała adresu. Stan aplikacji oceniaj dopiero na podstawie sygnału z warstwy, która rzeczywiście ją osiągnęła.
Co może zrobić osoba bez dostępu do serwera?
Zapisać dokładny komunikat, pełny adres strony, moment wystąpienia ze strefą czasową i zakres objawu, a potem przekazać komplet właścicielowi usługi. Bez dostępu do logów i konfiguracji naprawy się nie przeprowadzi - restart routera i czyszczenie pamięci podręcznej zmieniają otoczenie czytelnika, nie stan serwera, na którym powstał błąd.
Granica tej strony i źródła
Ta strona wybiera procedurę po objawie i na tym poprzestaje - testy, logi i naprawa czekają w tekście, do którego trafisz. Inne kody HTTP, pętle przekierowań i pozostałe błędy certyfikatów opisujemy w osobnych tekstach; dopóki się nie ukażą, nie prowadzą stąd do nich żadne linki. Konfigurację reverse proxy również omawiamy osobno, a szczegóły konkretnego panelu hostingowego znajdziesz w dokumentacji swojego dostawcy.
Definicje użyte na tej stronie pochodzą z RFC 9110 (sekcje 4.2.2, 15.5.4, 15.6.3 i 15.6.5), RFC 1035 (sekcja 4.1.1), RFC 8020 (sekcja 1), Linux man-pages connect(2), źródeł Chromium net/base/net_error_list.h oraz POSIX errno.h.