Gdy strona na domenie przestaje odpowiadać i zamiast treści pojawia się błąd 502 bad gateway, najczęściej problem nie leży w samym adresie, tylko w komunikacji między proxy, CDN, load balancerem i serwerem źródłowym. W tym artykule rozkładam ten scenariusz na czynniki pierwsze: pokazuję, skąd bierze się błąd, jak odróżnić winę DNS od awarii originu i co zrobić krok po kroku, jeśli zarządzasz domeną albo po prostu chcesz szybko przywrócić stronę do działania.
Najważniejsze rzeczy, które trzeba wiedzieć o błędzie na linii domena i serwer
- To zwykle nie jest problem przeglądarki, tylko warstwy pośredniej, która nie dostała poprawnej odpowiedzi od serwera źródłowego.
- Najczęstsze źródła awarii to DNS, CDN, reverse proxy, SSL/TLS, firewall albo przeciążony backend.
- Jeśli jesteś odwiedzającym, sprawdź inną sieć, wyłącz VPN i odśwież stronę po chwili.
- Jeśli zarządzasz domeną, zacznij od rekordów A/AAAA/CNAME, certyfikatu, logów i zdrowia aplikacji.
- Rozróżnienie błędu 502 od 503 i 504 od razu zawęża obszar diagnozy.
- Najlepszą ochroną przed powrotem problemu są monitoring, health checki i sensownie ustawione TTL w DNS.
Co oznacza błąd na styku domeny i serwera
Najprościej mówiąc, ten kod oznacza, że pośrednik w łańcuchu żądań dostał nieprawidłową odpowiedź od serwera nadrzędnego. MDN opisuje ten stan właśnie jako sytuację, w której gateway lub proxy próbuje pobrać odpowiedź, ale otrzymuje coś, czego nie potrafi poprawnie przekazać dalej.
W praktyce nie chodzi więc o samą domenę jako nazwę, tylko o to, co dzieje się za nią: czy DNS prowadzi do właściwego adresu, czy CDN potrafi połączyć się z originem, czy backend odpowiada w przewidywalnym formacie i czasie. Ja zawsze zaczynam od założenia, że domena może działać poprawnie, a problem siedzi niżej, na styku infrastruktury.
To ważne rozróżnienie, bo dopiero ono pozwala ustalić, czy szukasz błędu w konfiguracji DNS, w certyfikacie, w proxy, czy w samej aplikacji. Dzięki temu diagnoza przestaje być zgadywaniem, a staje się sekwencją konkretnych testów.
Żeby dojść do źródła, warto najpierw zobaczyć, przez jakie warstwy przechodzi ruch od domeny do aplikacji.
Gdzie problem powstaje w łańcuchu DNS, CDN i serwera
Po wejściu na adres domeny zapytanie zwykle nie trafia od razu do aplikacji. Najpierw działa DNS, który zamienia nazwę na IP, potem często wchodzi CDN albo reverse proxy, a dopiero na końcu serwer origin, na którym działa strona. Jeśli którakolwiek z tych warstw zwróci niepoprawną odpowiedź, użytkownik zobaczy błąd.
Właśnie dlatego awaria bywa myląca. Dla odwiedzającego wygląda jak problem „z domeną”, ale technicznie może to być:
- zły rekord A, AAAA albo CNAME,
- cache DNS trzymający stary adres po zmianie hostingu,
- reverse proxy, które nie potrafi dogadać się z originem,
- load balancer kierujący ruch do martwego backendu,
- certyfikat SSL/TLS niepasujący do hosta lub host headera.
Cloudflare zwraca uwagę, że przy takich błędach trzeba rozdzielić problem originu od problemu samej warstwy pośredniej. To jest dobra praktyka, bo z zewnątrz oba scenariusze mogą wyglądać bardzo podobnie, a naprawa jest zupełnie inna.
Jeśli umiesz narysować prosty schemat: domena - DNS - proxy - origin, diagnoza staje się dużo szybsza. Taki podział od razu zawęża obszar poszukiwań i chroni przed chaotycznym „grzebaniem” we wszystkim naraz.
Gdy ten łańcuch masz już w głowie, łatwiej przejść do najczęstszych przyczyn i sprawdzić, co faktycznie psuje odpowiedź serwera.
Najczęstsze przyczyny po stronie domen i infrastruktury
W realnych wdrożeniach powtarza się kilka scenariuszy. Niektóre są banalne, ale to właśnie one najczęściej powodują przestój, bo trafiają w newralgiczny punkt konfiguracji.
| Przyczyna | Jak się objawia | Co to zwykle oznacza |
|---|---|---|
| Błędny rekord DNS | Strona działa tylko czasami albo po zmianie hostingu | Domena wskazuje stary adres IP lub zły host docelowy |
| Cache DNS i propagacja | Część użytkowników widzi stronę, część nie | Resolverzy pośredni trzymają jeszcze poprzednią konfigurację |
| SSL/TLS i host name mismatch | Błąd pojawia się po włączeniu CDN lub po odnowieniu certyfikatu | Certyfikat nie obejmuje domeny albo proxy używa złego Host headera |
| Przeciążony backend | Problem nasila się przy większym ruchu albo po deployu | Aplikacja nie wyrabia z żądaniami, timeoutami lub połączeniami |
| Firewall, WAF, allowlist | Błąd dotyczy tylko ruchu przez CDN lub wybranych IP | Origin blokuje połączenia od proxy lub load balancera |
| Nieprawidłowy upstream | Po restarcie usługi problem znika albo pojawia się ponownie | Proxy kieruje ruch do martwego endpointu lub portu |
Jeśli miałbym wskazać jedną rzecz, która często bywa pomijana, to byłby nią TTL rekordów DNS. Przy częstych zmianach 300-900 sekund ma sens, ale dla stabilnych domen lepiej trzymać wyższe wartości, na przykład 3600 sekund lub więcej. Zbyt niski TTL potrafi zwiększyć liczbę zapytań, a zbyt wysoki wydłuża widoczność błędnej konfiguracji po zmianie.
Najgroźniejsze są sytuacje, w których kilka drobnych usterek nakłada się na siebie: stary rekord DNS, nowy certyfikat i restart backendu w trakcie wdrożenia. Wtedy łatwo pomylić symptom z przyczyną, więc lepiej iść warstwa po warstwie niż próbować zgadywać.
Kiedy znasz już typowe źródła problemu, możesz przejść do prostych działań naprawczych z perspektywy zwykłego użytkownika.
Co zrobić od razu, gdy widzisz problem jako odwiedzający
Jeśli nie zarządzasz serwerem ani domeną, Twoim celem nie jest naprawa infrastruktury, tylko szybkie sprawdzenie, czy problem jest lokalny, czy po stronie usługi. Ja w takiej sytuacji robię zawsze kilka krótkich testów, bo one bardzo szybko oddzielają awarię globalną od problemu po Twojej stronie.
- Odśwież stronę po chwili - pojedynczy błąd bywa krótkim zacięciem przy wdrożeniu lub przełączeniu ruchu.
- Sprawdź stronę w trybie prywatnym - to eliminuje wpływ części ciasteczek i lokalnej pamięci podręcznej.
- Wyłącz VPN, proxy lub filtr DNS - niektóre usługi pośrednie potrafią same generować problemy z połączeniem.
- Spróbuj z innej sieci - jeśli na Wi-Fi działa, a na LTE nie, problem może leżeć w routingu albo filtracji po drodze.
- Sprawdź, czy działa tylko jedna domena czy cała usługa - jeśli nie działa też panel, API albo subdomena, awaria jest głębiej niż pojedyncza podstrona.
Jeśli błąd utrzymuje się tylko na jednej stronie i nie ma oznak szerszej awarii, zwykle warto po prostu poczekać kilka minut i wrócić do testu. Przy infrastrukturze z CDN-em, cache i autoskalowaniem krótki przestój bywa skutkiem ubocznym wdrożenia albo przełączenia ruchu.
Dla użytkownika liczy się jedno: czy problem jest lokalny, czy globalny. Jeśli lokalny - zmieniasz sieć lub ustawienia. Jeśli globalny - zgłaszasz go właścicielowi i nie tracisz czasu na czyszczenie rzeczy, które nie mają wpływu na backend.
Jeżeli masz dostęp administracyjny do domeny lub serwera, kolejny krok jest już bardziej techniczny i warto go wykonać w uporządkowanej kolejności.
Jak sprawdzać błąd po stronie właściciela domeny
Najpierw potwierdź, że DNS wskazuje właściwy cel
Sprawdź rekordy A, AAAA i CNAME dla domeny głównej oraz subdomen, na których pojawia się problem. Błąd często wynika z drobiazgu: stary IP po migracji, nieaktualny CNAME albo konflikt między rekordem głównym i subdomeną. Jeżeli rekordy były zmieniane niedawno, uwzględnij także cache i czas propagacji.
Potem przejrzyj proxy, CDN i load balancer
Jeśli domena stoi za CDN-em albo reverse proxy, sprawdź, czy origin odpowiada poprawnie na żądania z tej warstwy. Zwróć uwagę na Host header, SNI, porty, reguły firewall i limity ruchu. W praktyce bardzo często problemem nie jest sama aplikacja, tylko to, że pośrednik nie może się z nią połączyć albo dostaje odpowiedź w złym formacie.
Przeczytaj również: Czy każdy może zarejestrować domenę w pl? Sprawdź wymagania i proces
Na końcu zajrzyj do aplikacji i logów
W logach szukaj komunikatów o timeoutach, connection refused, błędach TLS, restartach procesu lub braku dostępności backendu. Jeśli działa PHP-FPM, Node, kontener albo usługa w Kubernetes, sprawdź, czy procesy nie wpadają w pętlę restartów i czy nie kończą się zasoby. To tutaj zwykle wychodzi, czy problem był chwilowy, czy system naprawdę nie wyrabia pod obciążeniem.
Dobrym nawykiem jest porównanie odpowiedzi z kilku punktów: bezpośrednio z originu, przez proxy i z zewnętrznej sieci. Taki test bardzo szybko pokazuje, na której warstwie ruch się urywa, a bez tego łatwo szukać błędu w złym miejscu.
To prowadzi do kolejnego praktycznego pytania: czy na pewno patrzysz na właściwy kod błędu, czy tylko na podobny komunikat z innego miejsca.
Jak odróżnić ten problem od błędu 503 i 504
Na pierwszy rzut oka te kody wyglądają podobnie, ale znaczą coś innego i to ma realne znaczenie diagnostyczne. Jeśli pomylisz je na starcie, możesz szukać awarii tam, gdzie jej nie ma.
| Kod | Znaczenie | Najczęstszy trop |
|---|---|---|
| 502 | Pośrednik dostał nieprawidłową odpowiedź od upstreamu | Problem z odpowiedzią backendu, proxy, TLS lub formatem komunikacji |
| 503 | Usługa jest chwilowo niedostępna | Przeciążenie, maintenance, wyczerpane zasoby albo planowany downtime |
| 504 | Pośrednik nie dostał odpowiedzi na czas | Timeout między proxy a originem, zbyt wolna aplikacja lub sieć |
Różnica jest subtelna, ale bardzo praktyczna. Przy 502 szukasz głównie niepoprawnej odpowiedzi, przy 504 - zbyt długiego czasu odpowiedzi, a przy 503 - sytuacji, w której usługa świadomie albo nieświadomie nie przyjmuje ruchu. To dlatego rozpoznanie kodu jest często szybsze niż przeglądanie dziesiątek logów.
Jeśli widzisz te trzy kody wymiennie w krótkim czasie, to zwykle znak, że infrastruktura ma niestabilną warstwę pośrednią albo backend nie utrzymuje stałej wydajności. W takim przypadku jednorazowy restart rzadko wystarcza.
Kiedy kod jest już rozpoznany, pozostaje jeszcze jeden ważny temat: co zrobić, żeby podobna awaria nie wracała po każdym wdrożeniu.
Co wdrożyć, żeby awaria nie wracała
Najlepsze zespoły nie liczą na szczęście. Budują system tak, żeby problem dało się zauważyć wcześniej niż użytkownik. Ja w praktyce zaczynam od trzech rzeczy: monitoringu, zdrowych deployów i sensownej konfiguracji DNS.
- Health checki - proxy i load balancer powinny regularnie sprawdzać, czy origin naprawdę odpowiada.
- Monitoring HTTP i logów - sam kod statusu to za mało; potrzebujesz też metryk opóźnień, błędów aplikacji i restartów procesów.
- Rollback po wdrożeniu - jeśli nowa wersja generuje błędy na starcie, szybki powrót do poprzedniej wersji jest lepszy niż długie diagnozowanie na żywo.
- Rozsądne timeouty - zbyt krótkie timeouty produkują fałszywe alarmy, a zbyt długie ukrywają problem i obciążają całą ścieżkę.
- Aktualne rekordy DNS - przy migracjach trzymaj porządek w A, AAAA i CNAME, a zmiany rób etapami, nie hurtem.
- Spójność SSL/TLS - certyfikat, host name, SNI i ustawienia proxy muszą opowiadać tę samą historię.
Ważne jest też, żeby nie przesadzić z automatycznymi retry. Gdy backend już się dławi, agresywne ponawianie żądań tylko pogarsza sytuację. Lepiej zastosować kontrolowane ponawianie z backoffem i jasno ustawionym limitem prób niż powielać ruch bez końca.
Jeśli miałbym zostawić jedną praktyczną radę, byłaby prosta: patrz na błąd 502 jak na sygnał o pęknięciu w łańcuchu, a nie jak na jedną, tajemniczą awarię. Gdy rozbijesz problem na DNS, warstwę pośrednią, origin i aplikację, diagnoza robi się szybka, a naprawa przestaje być zgadywanką.
