Kod 502 Bad Gateway

TL;DR — 502 Bad Gateway oznacza, że jeden serwer poprosił inny o Twoją stronę i otrzymał złą odpowiedź. Zwykle „przednim” serwerem jest CDN albo proxy, a „tylnym” — właściwa witryna, czyli origin. Błąd leży w hostingu/infrastrukturze, a nie w Google Search Console; krótkotrwały 502 zwykle niesie ograniczone praktyczne ryzyko SEO, choć Google nie publikuje dokładnego „bezpiecznego” czasu. Problem jest większy, im dłużej trwa.

Czym jest 502 Bad Gateway

Podczas ładowania strony żądanie często nie trafia bezpośrednio do witryny. Przechodzi przez pośrednika — CDN (np. Cloudflare), load balancer albo reverse proxy (np. Nginx). Pośrednik przekazuje żądanie właściwemu serwerowi, czeka na odpowiedź i odsyła ją odwiedzającemu.

502 Bad Gateway pojawia się, gdy pośrednik poprosił serwer o stronę i otrzymał nieprawidłową odpowiedź — albo nie otrzymał jej wcale. Prościej: przedni serwer nie mógł dostać dobrej odpowiedzi od tylnego serwera. Evidence for this claim A 502 response means a gateway or proxy received an invalid response from an upstream server. Scope: RFC 9110 defines the gateway response semantics; it does not identify which infrastructure layer caused a specific failure. Confidence: high · Verified: 2026-07-14 IETF: RFC 9110 §15.6.3 — 502 Bad Gateway

To ważny niuans. 502 nie oznacza automatycznie, że witryna nie działa. Serwer może być zdrowy i poprawnie odpowiadać na bezpośrednie żądanie — ale jeśli proxy przed nim nie może się z nim połączyć (przekroczenie czasu, zła konfiguracja albo awaria samego CDN-u), odwiedzający nadal zobaczy 502.

Czym różni się od podobnych kodów

Zobaczysz kilka podobnych błędów 5xx:

• 500 — własny kod witryny napotkał błąd podczas budowania strony.
• 502 — proxy przed witryną otrzymało od niej złą odpowiedź.
• 503 — witryna jest celowo niedostępna (planowana konserwacja, przeciążenie).
• 504 — proxy czekało na serwer, ale upłynął czas oczekiwania bez odpowiedzi.

Są powiązane, ale wskazują różne miejsca, które trzeba sprawdzić.

Czy 502 szkodzi SEO?

Zwykle niewiele — o ile nie trwa długo. Crawler Google (Googlebot) traktuje 502 tak samo jak inne błędy 5xx: spowalnia crawlowanie proporcjonalnie do liczby URL-i z błędem, a potem zwiększa tempo, gdy witryna znów odpowiada kodami 2xx. Google nie publikuje dokładnego „bezpiecznego” czasu, ale krótki 502 — od kilku minut do kilku godzin — niesie znacznie mniejsze praktyczne ryzyko niż błąd powracający. Evidence for this claim Google handles 502 with its general 5xx behavior: reduced crawling, ignored response content, and eventual removal of persistently failing URLs. Scope: Google explicitly lists 502 among 5xx server errors; it does not guarantee that a particular short outage has no ranking effect. Confidence: high · Verified: 2026-07-14 Google: How HTTP status codes affect Google's crawlers

Rzeczywiste ryzyko pojawia się, gdy 502 stale powraca albo utrzymuje się przez dłuższy czas. Własne sformułowanie Google mówi o URL-ach, które „persistently” zwracają błąd serwera — bez określenia konkretnej liczby dni. (John Mueller z Google wspominał nieformalnie o „multiple days” jako przybliżeniu momentu, gdy strony zaczynają wypadać, oraz że zwykle wracają po odzyskaniu witryny — potraktuj to jednak jako przybliżoną ocenę jednej osoby w konkretnym incydencie, a nie oficjalną regułę.)

Co z tym zrobić

• Nie próbuj „naprawiać” tego w Search Console. Search Console tylko raportuje 502 po fakcie. Naprawa następuje na CDN-ie, proxy albo serwerze.
• Sprawdź, czy problem dotyczy tylko Ciebie, czy wszystkich. Jeśli cały internet działa, ale Twoja witryna nie, problem jest w Twojej konfiguracji. Jeśli awarię ma duży CDN, możesz wcale nie być winny — i po swojej stronie nie masz nic do naprawienia poza czekaniem.
• Sprawdź stronę statusu hosta lub CDN-u oraz logi serwera. Tam znajduje się rzeczywista odpowiedź.

Chcesz poznać diagnozę warstwa po warstwie (CDN kontra proxy kontra origin), dokładne brzmienie dokumentacji Google oraz wypowiedź Johna Muellera podczas awarii Cloudflare w listopadzie 2025 roku? Przejdź do karty Advanced.

TL;DR — 502 to awaria warstwy proxy/bramy: RFC 9110 §15.6.3 definiuje go jako otrzymanie przez bramę lub proxy nieprawidłowej odpowiedzi od serwera wejściowego. Różni się od 500 (błąd aplikacji origin) i 503 (celowa niedostępność origin). Dokumentacja Google traktuje 500, 502 i 503 jako jedną rodzinę 5xx — tempo crawlowania spada proporcjonalnie do liczby URL-i z błędem, treść 5xx jest ignorowana, a utrzymujące się błędy usuwają strony z indeksu. Odzyskiwanie jest stopniowe po powrocie 2xx, choć Google nie publikuje stałego harmonogramu. Czas trwania ma znaczenie, ale nie ma oficjalnego progu: krótkie skoki niosą dużo mniejsze praktyczne ryzyko, a realne zagrożenie stanowią błędy powracające — nieformalne uwagi Muellera z listopada 2025 roku wskazywały na wiele dni, a nie udokumentowany SLA. Diagnozuj warstwami — CDN, reverse proxy lub origin — i koreluj dowody między etapami, zamiast ufać samej markowej stronie błędu.

Co naprawdę sygnalizuje 502

RFC 9110 §15.6.3 definiuje 502 konkretnie: brama lub proxy otrzymuje nieprawidłową odpowiedź od serwera wejściowego, do którego uzyskało dostęp podczas realizacji żądania. Ta granica specyfikacji ma znaczenie — wskazuje miejsce, w którym brama zaobserwowała awarię, a niekoniecznie etap, który ją spowodował. Status 502 jest dowodem awarii na granicy, a nie dowodem, że aplikacja origin jest zepsuta. Ta różnica odróżnia większość konkurencyjnych tekstów „13 sposobów naprawy” i dlatego poniższa diagnoza jest warstwowa, a nie płaska. Evidence for this claim A 502 response means a gateway or proxy received an invalid response from an upstream server. Scope: RFC 9110 defines the gateway response semantics; it does not identify which infrastructure layer caused a specific failure. Confidence: high · Verified: 2026-07-14 IETF: RFC 9110 §15.6.3 — 502 Bad Gateway

Porównaj mylone kody 5xx:

• 500 Internal Server Error — sama aplikacja origin napotkała błąd (błąd kodu, nieobsłużony wyjątek, wyczerpanie zasobów). Origin odpowiedział, a odpowiedź brzmiała „zepsułem się”.
• 502 Bad Gateway — proxy otrzymało od upstreamu zniekształconą lub nieprawidłową odpowiedź (RFC 9110 §15.6.3).
• 503 Service Unavailable — origin jest celowo niedostępny; to zamierzony, akceptowany przez Google kod „wróć później” używany przy planowanej konserwacji, najlepiej z nagłówkiem Retry-After.
• 504 Gateway Timeout — proxy czekało na upstream i nie otrzymało żadnej odpowiedzi przed upływem limitu (RFC 9110 §15.6.5). (502 = zła odpowiedź; 504 = brak odpowiedzi na czas.)

Praktyczny wniosek: 503 to kod, który wybierasz celowo; 502 to kod, który przytrafia się przy awarii infrastruktury.

Jak Googlebot obsługuje 502

Warto oprzeć się tutaj na rzeczywistej dokumentacji Google, a nie na ogólnikowym „to może zaszkodzić rankingom”. Dokument Google o błędach HTTP i sieci wymienia 502 (bad gateway) jako kod 5xx i nadaje wszystkim kodom 5xx takie samo traktowanie:

• Tempo crawlowania spada proporcjonalnie. Google zmniejsza tempo crawlowania witryny, a skala spadku jest proporcjonalna do liczby pojedynczych URL-i zwracających błąd serwera. Kilka 502-ów to niewielki problem; 502 w całej witrynie jest wyraźnym sygnałem „zwolnij”.
• Treść 5xx jest ignorowana. Wszystko, co Google otrzyma z URL-a zwracającego 5xx, jest ignorowane — nie zindeksuje strony błędu 502 jako Twojej treści.
• Ochrona indeksu jest tymczasowa. URL-e już zindeksowane początkowo pozostają w indeksie, ale potok indeksowania Google usuwa URL-e, które utrzymują się jako błąd serwera.
• Odzyskiwanie jest automatyczne i stopniowe. Gdy serwer znów zacznie odpowiadać kodami 2xx, Google stopniowo zwiększa tempo crawlowania. Przy zwykłym odzyskiwaniu nie trzeba ponownie zgłaszać witryny, prosić o ponowne rozpatrzenie ani wykonywać heroicznych działań „validate fix” — ten przycisk tylko prosi Google o szybsze ponowne sprawdzenie.

Najważniejszy wniosek: 502 jest traktowany tak samo jak 500 i 503. Nie jest „mniej poważny” dlatego, że powstaje na warstwie proxy/CDN-u, a nie w originie. Nie ma udokumentowanej pobłażliwości wobec 502. Evidence for this claim Google handles 502 with its general 5xx behavior: reduced crawling, ignored response content, and eventual removal of persistently failing URLs. Scope: Google explicitly lists 502 among 5xx server errors; it does not guarantee that a particular short outage has no ranking effect. Confidence: high · Verified: 2026-07-14 Google: How HTTP status codes affect Google's crawlers

Czas trwania jest całą historią

To, czy 502 rzeczywiście Ci zaszkodzi, zależy od czasu trwania — ale Google nie publikuje stałego bezpiecznego czasu ani stałego progu wypadania z indeksu, więc potraktuj poniższe jako praktyczny kontekst, a nie SLA:

• Krótki skok (od kilku minut do kilku godzin) → obniżenie tempa crawlowania Google skaluje się z liczbą URL-i z błędem, więc krótki skok na małą skalę ma ograniczony praktyczny wpływ i zwykle nie warto szukać jego naprawy w Search Console. Dokumentacja Google formalnie nie wyłącza krótkich błędów — chodzi o stopień, a nie twardy próg.
• Błąd powracający albo utrzymujący się → to zakres, którego dotyczy sformułowanie Google o URL-ach „persistently” zwracających błąd serwera, a strony mogą zacząć wypadać z indeksu. Google nie definiuje „persistently” konkretną liczbą dni. Publiczna wypowiedź Muellera (niżej) wskazywała nieformalnie na multiple days, a odzyskiwanie było dość szybkie po przywróceniu zdrowej witryny — ale to ocena praktyka dotycząca konkretnego incydentu, a nie udokumentowana reguła dla każdej witryny lub CDN-u.

W przybliżeniu odpowiada to awarii Cloudflare z listopada 2025 roku, gdy fala witryn zwracała błędy 5xx bez własnej winy. Publiczna odpowiedź Muellera na Bluesky mówiła, że crawlowanie 5xx zwalnia, ale „ramps back up” — dokładne brzmienie i zastrzeżenia źródłowe znajdziesz na karcie Quotes, w tym osobny komentarz o „multiple days” przekazany przez zewnętrzne podsumowanie, a nie zweryfikowany w oryginalnym wątku. Krótka awaria potwierdzona przez dostawcę jest bliska najlepszemu przypadkowi: jest widoczna, zwykle rozwiązuje się sama, a po potwierdzeniu odzyskania przez dostawcę i powrocie własnych odpowiedzi 2xx rozsądne jest zazwyczaj wstrzymanie się ze zmianami infrastruktury zamiast reagowania na siłę.

Diagnozowanie 502 według warstwy

Ponieważ 502 jest awarią komunikacji między serwerami, najszybciej znajdziesz go, schodząc po stosie — CDN, potem reverse proxy, potem origin — zamiast przechodzić przez płaską listę kontrolną. (Karta Decision Trees przedstawia to jako instruktaż.)

Zanim zaczniesz, jedno zastrzeżenie: markowa strona błędu, nazwa dostawcy w nagłówku albo „wygląd” awarii to jeden sygnał dowodowy, a nie dowód tego, który etap zawiódł. Przed stwierdzeniem „to CDN” albo „to mój origin” skoreluj nagłówki odpowiedzi, identyfikatory żądań/śledzenia oraz oznaczone czasem logi po obu stronach danego etapu.

Warstwa CDN/brzegowa

• Przekroczenie czasu upstreamu: węzeł brzegowy nie otrzymał na czas odpowiedzi od originu.
• Brzeg w ogóle nie może dotrzeć do originu — błąd rozwiązywania DNS, błąd uzgadniania SSL/TLS albo firewall/bezpieczeństwo originu blokujące zakresy IP CDN-u.
• Udokumentowane przyczyny różnią się między dostawcami: własna dokumentacja Cloudflare opisuje scenariusze łączności z originem i timeoutów właściwe dla jego sieci brzegowej, a AWS CloudFront ma własny zestaw przyczyn TLS, DNS, portów i funkcji originu — sprawdź dokumentację swojego CDN-u, zamiast zakładać, że lista jednego dostawcy pasuje do innego.
• Własna awaria dostawcy CDN-u (Cloudflare, Fastly, AWS itd.) — masowe zdarzenie 502 w niezwiązanych witrynach, które nie ma nic wspólnego ze zdrowiem Twojego serwera; potwierdź je na stronie statusu dostawcy, a nie tylko po marce widocznej na stronie błędu.

Warstwa reverse proxy/load balancera (Nginx, Apache mod_proxy, HAProxy)

• Timeout backendu albo odmowa połączenia.
• Błędnie skonfigurowane proxy_pass/blok upstreamu wskazujące niewłaściwe miejsce.
• Wyczerpanie puli backendu — każdy worker upstreamu jest zajęty.
• Niezgodność SSL/TLS między proxy a backendem.

Warstwa serwera origin

• Awaria lub restart aplikacji/PHP-FPM albo zabicie procesu OOM (przekroczony limit pamięci).
• Wyczerpanie połączeń z bazą danych.
• Wdrożenie/restart powodujące krótką niedostępność.
• WAF lub wtyczka bezpieczeństwa blokująca prawidłowe IP proxy albo crawlera tak, jakby były atakującymi — to podstępny przypadek, bo zwykłe przeglądarki działają, a proxy (lub Googlebot) dostaje 502s.

Warto podkreślić ostatni wzorzec: jeśli tylko Googlebot albo tylko żądania przez CDN dostają 502s, a zwykłe przeglądarki nie, patrzysz na blokadę związaną z botem albo zmienną odpowiedź, a nie prawdziwą awarię. Przetestuj origin bezpośrednio i przez CDN oraz sprawdź, co rzeczywiście widzi Googlebot, korzystając z testu na żywo URL Inspection w Search Console, zamiast zakładać bieżący wpływ na podstawie raportu Server error (5xx), który może być już nieaktualny.

Naprawianie i zapobieganie 502s

Naprawy zależą od warstwy, a osoba, która powinna je wykonać, zależy od roli:

• Odwiedzający — niczego nie naprawia. Odśwież raz, spróbuj innej sieci, jeśli podejrzewasz lokalny problem, a w przeciwnym razie poczekaj; zmiany po stronie przeglądarki nie naprawią awarii między serwerami.
• Właściciel witryny bez dostępu do infrastruktury — najpierw potwierdź zakres i sprawdź strony statusu/logi (zobacz listę kontrolną niżej), a potem eskaluj do hosta, pomocy CDN-u albo zespołu deweloperskiego, zamiast zgadywać.
• Właściciel hosta/CDN-u/aplikacji — popraw konfigurację proxy/upstreamu, zwiększ timeouty i pojemność backendu, gdy origin jest rzeczywistym wąskim gardłem, oraz rozłóż wdrożenia w czasie, aby restarty nie wyłączały całej puli. Traktuj dodawanie wyjątków WAF-u, zmiany firewalla oraz edycje konfiguracji proxy/upstreamu jako zmiany wymagające akceptacji — wprowadzaj je dopiero, gdy logi i dowody dostawcy rzeczywiście wskazują awarię firewalla lub kontroli dostępu, a nie jako pierwszy strzał; dodanie CDN-u lub crawlera do allowlisty nie jest ogólną naprawą 502.

W zapobieganiu wygrywa nudna podstawa: monitoring dostępności z alertami, monitoring logów błędów serwera i proxy, obserwowanie Host status w statystykach crawlowania Search Console oraz trendu Server error (5xx), a także korelowanie skoków ze stronami statusu dostawców CDN-u i DNS-u, aby w kilka sekund odróżnić „mój problem” od „ich awarii”.

Powiązane kody, które warto rozróżniać, są tuż obok w tym klastrze: origin 500, zamierzony 503 oraz timeout 504.

Podsumowanie AI

Skrócona wersja wariantu Advanced:

• 502 = awaria warstwy proxy/bramy. RFC 9110 §15.6.3 definiuje go jako otrzymanie przez bramę lub proxy nieprawidłowej odpowiedzi od serwera wejściowego — to dowód awarii na granicy, a nie dowód, który etap (CDN, proxy czy origin) ją spowodował. Origin może być zdrowy, choć odwiedzający nadal widzą 502.
• Różne przyczyny, ta sama udokumentowana rodzina. 500 (błąd aplikacji origin), 502 (proxy dostało złą odpowiedź, RFC §15.6.3), 503 (origin celowo niedostępny), 504 (proxy nie dostało odpowiedzi na czas, RFC §15.6.5). Dokumentacja Google grupuje 500, 502 i 503 w jedno traktowanie 5xx — nie opisuje dodatkowej równoważności kodów poza tą regułą rodziny.
• Odpowiedź Googlebota: tempo crawlowania spada proporcjonalnie do liczby URL-i z błędem, treść 5xx jest ignorowana, URL-e z indeksu są krótkoterminowo zachowywane, ale usuwane, jeśli błędy utrzymują się, a crawlowanie stopniowo wraca po powrocie 2xx — Google nie publikuje dokładnego bezpiecznego czasu ani gwarantowanego harmonogramu odzyskiwania.
• Czas trwania ma znaczenie, ale nie ma oficjalnego progu. Krótkie skoki niosą znacznie mniejsze praktyczne ryzyko; realnym zagrożeniem są błędy powracające. Nieformalny komentarz Muellera z listopada 2025 roku wskazywał na „multiple days” jako okolice wypadania z indeksu i dość szybkie odzyskiwanie — potraktuj to jako ocenę praktyka dotyczącą jednego incydentu, a nie udokumentowany SLA.
• Diagnozuj warstwami, nie marką strony błędu. Koreluj nagłówki, identyfikatory żądań/śledzenia, logi i stronę statusu dostawcy: CDN → reverse proxy/load balancer (sprawdź proxy_pass) → origin. Bezpośrednia odpowiedź 2xx originu przy 502 przez CDN zawęża problem do etapu pośredniego.
• Naprawa zależy od roli: odwiedzający czeka; właściciel bez dostępu potwierdza zakres i eskaluje; właściciel infrastruktury poprawia warstwę wskazaną przez dowody. Nie wyłączaj WAF-u ani nie dodawaj botów do allowlisty bez potwierdzenia.
• Dla planowanej przerwy użyj 503, nie 502. 503 z Retry-After sygnalizuje celową tymczasową niedostępność; 502 oznacza niezamierzoną nieprawidłową odpowiedź proxy.
• Szybki przebieg: odtwórz publiczny URL → sprawdź zakres i stronę statusu CDN/DNS → porównaj edge z originem → sprawdź logi proxy i originu → zweryfikuj Googlebota przez URL Inspection → monitoruj stabilne 2xx.

Oficjalna dokumentacja

Dokumentacja źródłowa dotycząca 502 i obsługi błędów 5xx przez wyszukiwarki.

Google

• How HTTP status codes affect Google’s crawlers — dokument kanoniczny; wymienia 502 (bad gateway) obok 500 i 503 oraz opisuje wspólne traktowanie tempa crawlowania i indeksowania.
• Jak radzić sobie z planowaną przerwą w działaniu witryny — dlaczego 503 (a nie 502, 404 ani 200) jest właściwym kodem celowej przerwy, z nagłówkiem Retry-After. Przydatne przy rozróżnieniu 502 i 503.
• robots.txt spec — handling server errors — sposób obsługi 5xx na samym pliku robots.txt przez Google.

Specyfikacja

• RFC 9110 §15.6.3 — 502 (Bad Gateway) — definicja na poziomie specyfikacji: brama lub proxy otrzymuje nieprawidłową odpowiedź od serwera wejściowego, do którego uzyskało dostęp podczas realizacji żądania. Wskazuje granicę, na której zaobserwowano awarię, a nie etap, który ją spowodował.

Bing / Microsoft

• Bing Webmaster Tools — Help Center — Bing pokazuje serwerowe problemy crawlowania klasy 5xx, w tym awarie łączności, w raportach błędów crawlowania.

Cytaty ze źródła

Wypowiedzi Google dostępne w oryginale. Każdy odnośnik prowadzi bezpośrednio do cytowanego fragmentu.

Google — jak obsługiwane są błędy 5xx (w tym 502)

• “5xx and 429 server errors prompt Google’s crawlers to temporarily slow down with crawling. For Google Search, already indexed URLs are preserved in the index, but eventually dropped.” (tłumaczenie) „Błędy serwera skłaniają crawlery Google do tymczasowego spowolnienia crawlowania. W wyszukiwarce Google adresy URL już zindeksowane pozostają w indeksie, ale z czasem są usuwane.” — Google Search Central, How HTTP status codes affect Google’s crawlers. Przejdź do cytatu
• “Google decreases the crawl rate for the site. The decrease in crawl rate is proportionate to the number of individual URLs that are returning a server error. For Google Search, Google’s indexing pipeline removes from the index URLs that persistently return a server error.” (tłumaczenie) „Google zmniejsza tempo crawlowania witryny. Spadek jest proporcjonalny do liczby pojedynczych URL-i zwracających błąd serwera. W wyszukiwarce Google potok indeksowania usuwa z indeksu URL-e, które stale zwracają błąd serwera.” — ten sam dokument, wiersz tabeli obejmujący 500, 502 i 503. Przejdź do cytatu
• “Once the server starts responding with a 2xx status code, Google gradually increases the crawl rate for the site.” (tłumaczenie) „Gdy serwer zacznie odpowiadać kodem z klasy powodzenia, Google stopniowo zwiększa tempo crawlowania witryny.” — ten sam dokument. Przejdź do cytatu

John Mueller, Google (Bluesky, 18 listopada 2025 r. — odpowiedź w wątku o skoku liczby błędów 5xx podczas awarii Cloudflare)

• “Yeah. 5xx = Google crawling slows down, but it’ll ramp back up.” (tłumaczenie) „Tak. Google zwalnia crawlowanie, ale potem tempo znów wzrośnie.” Wyświetl wpis
• “If it stays at 5xx for multiple days, then things may start to drop out, but even then, those will pop back in fairly quickly.” (tłumaczenie) „Jeśli błąd utrzyma się przez kilka dni, strony mogą zacząć wypadać z indeksu, lecz nawet wtedy dość szybko do niego wrócą.” Przekazane za pośrednictwem artykułu Matta G. Southerna w Search Engine Journal o tej samej wymianie; przed potraktowaniem tego jako ostatecznej informacji potwierdź treść w oryginalnym wątku. Przeczytaj omówienie

Lista kontrolna odpowiedzi 502 Bad Gateway

Gdy pojawi się 502 — w przeglądarce, monitoringu albo w raporcie błędów serwera (5xx) w Search Console — wykonaj poniższą listę. Etykiety ról: [Dowolna osoba] oznacza, że dostęp do infrastruktury nie jest potrzebny; [Właściciel hosta/CDN/aplikacji] oznacza, że jest wymagany.

• [Dowolna osoba] Potwierdź, że błąd jest rzeczywisty i aktualny — odtwórz teraz adres URL; raport błędów serwera (5xx) może być opóźniony względem krótkiego problemu, który już się rozwiązał.
• [Dowolna osoba] Sprawdź zakres — czy dotyczy jednego adresu URL, sekcji czy całej witryny? (Wpływ na crawlowanie rośnie wraz z liczbą adresów URL zwracających błąd.)
• [Dowolna osoba] Sprawdź stronę statusu dostawcy CDN/DNS pod kątem awarii obejmującej całego dostawcę, zanim zmienisz własną konfigurację.
• [Właściciel hosta/CDN/aplikacji] Przetestuj bezpośrednio do originu vs. przez CDN — jeśli origin odpowiada kodem 2xx bezpośrednio, ale CDN zwraca 502, problem występuje na brzegu sieci albo pomiędzy tymi punktami.
• [Właściciel hosta/CDN/aplikacji] Sprawdź, czy tylko boty/adresy IP CDN otrzymują 502, podczas gdy przeglądarki działają poprawnie — może to wskazywać na możliwą blokadę WAF/firewalla, a nie awarię. Potwierdź to w logach firewalla/WAF przed dodaniem czegokolwiek do listy dozwolonych; allowlisting nie jest uniwersalną poprawką i powinien wynikać z dowodów, a nie je wyprzedzać.
• [Właściciel hosta/CDN/aplikacji] Odczytaj logi błędów proxy (Nginx/Apache/HAProxy) pod kątem przekroczeń czasu oczekiwania upstreamu albo wpisów o odmowie połączenia.
• [Właściciel hosta/CDN/aplikacji] Odczytaj logi originu pod kątem awarii aplikacji, zabójstw OOM albo wyczerpania połączeń z bazą danych w okolicy wskazanych znaczników czasu.
• [Dowolna osoba] Zweryfikuj w teście na żywo w GSC, co widzi Googlebot, korzystając z funkcji Inspekcja adresu URL.
• [Właściciel hosta/CDN/aplikacji] Zastosuj poprawkę właściwą dla danej warstwy dopiero wtedy, gdy wskazują na nią logi i dowody od dostawcy — zmiany WAF, firewalla, limitu czasu i konfiguracji proxy to zmiany infrastruktury, a nie zgadywane działania w pierwszej odpowiedzi.
• [Dowolna osoba] Po naprawie pozwól, aby przywracanie przebiegło samo — odpowiedzi 2xx stopniowo zwiększają tempo crawlowania; Google nie publikuje dokładnego harmonogramu powrotu. Użyj opcji „Validate Fix” wyłącznie po to, by poprosić o szybsze ponowne sprawdzenie, a nie jako o „naprawę”.
• [Właściciel hosta/CDN/aplikacji] Potwierdź, że w razie planowanej niedostępności w przyszłości używasz 503 (a nie 502).

Czy mój 502 jest problemem CDN, proxy czy originu?

502 oznacza niepowodzenie pomiędzy serwerami, dlatego diagnozuj go, przechodząc w dół stosu, zamiast zgadywać. Zacznij od brzegu i kieruj się do środka.

P1. Czy Twój dostawca CDN lub DNS zgłasza teraz awarię?

• Tak → najprawdopodobniej jest to awaria obejmująca całego dostawcę (zdarzenie Cloudflare z listopada 2025 r. jest podręcznikowym przykładem). Zwykle nie masz nic do naprawienia po swojej stronie. Potwierdź, że Twój origin działa poprawnie, a następnie poczekaj na przywrócenie usługi — tempo crawlowania Google stopniowo wraca po wznowieniu odpowiedzi 2xx, choć nie opublikowano dokładnego harmonogramu. Zakończ tutaj.
• Nie → przejdź dalej.

P2. Czy origin odpowiada kodem 2xx przy bezpośrednim żądaniu (z pominięciem CDN/proxy)?

• Nie — origin również zawodzi → problem występuje na warstwie originu. Sprawdź w logach awarie aplikacji / PHP-FPM, zabójstwa OOM, wyczerpanie połączeń z bazą danych albo wadliwe wdrożenie. Zależnie od tego, jak proxy je odczytuje, może się to również wyświetlać jako 500 lub 504. Zakończ tutaj.
• Tak — origin działa bezpośrednio, ale CDN/proxy zwraca 502 → przejdź dalej. Origin działa poprawnie; coś przed nim nie może uzyskać prawidłowej odpowiedzi.

P3. Czy zwykłe przeglądarki działają, podczas gdy tylko Googlebot / adresy IP CDN otrzymują 502?

• Tak → podejrzewaj blokadę WAF lub firewalla, który traktuje proxy albo zakresy adresów IP crawlera jak atakujących. Najpierw potwierdź to w logach firewalla/WAF, a następnie dodaj do listy dozwolonych prawidłowe zakresy IP CDN i zweryfikowanego crawlera — nie rób tego bez potwierdzenia. Zakończ tutaj.
• Nie — wszyscy korzystający z proxy otrzymują 502 → przejdź dalej.

P4. Co logi reverse proxy pokazują dla upstreamu?

• Przekroczenie czasu oczekiwania / odmowa połączenia → proxy może dotrzeć do backendu, ale nie otrzymuje na czas prawidłowej odpowiedzi → problem z wydajnością backendu albo limitem czasu (wyczerpana pula, zbyt krótkie limity czasu). Zwiększ wydajność lub limity czasu albo napraw wolny backend.
• Błędny host / DNS / nieudane uzgadnianie SSL z upstreamem → błędna konfiguracja proxy → napraw blok proxy_pass / upstream albo konfigurację TLS na odcinku proxy↔backend.

Niezależnie od warstwy: porządki SEO są takie same i w większości nie wymagają działania. Gdy adresy URL zaczną zwracać 2xx, Google automatycznie wznowi crawlowanie — nie trzeba niczego ponownie zgłaszać.

Mity o 502 i błędy, których należy unikać

• Mit: „502 to problem Google/SEO, który naprawię w Search Console”. Nie. 502 to awaria hostingu/infrastruktury; Search Console tylko raportuje ją po fakcie. Poprawki trzeba wprowadzić w CDN, proxy albo originie. „Validate Fix” jedynie prosi Google o ponowne sprawdzenie — niczego nie naprawia.
• Mit: “A 502 always means my server is down.” (tłumaczenie) „502 zawsze oznacza, że mój serwer nie działa.” Nie. Origin może zwrócić 2xx przy bezpośrednim żądaniu, podczas gdy odwiedzający zobaczą 502 przez CDN — z powodu przekroczenia czasu oczekiwania, błędnej konfiguracji upstreamu albo własnej awarii CDN. Przetestuj połączenie bezpośrednio z originem, zanim założysz, że serwer się zawiesił.
• Mit: „502 jest mniej poważny dla SEO niż 500”. Nie. Dokumentacja Google przypisuje kodom 500, 502 i 503 takie samo ograniczenie tempa crawlowania oraz takie samo ostateczne usunięcie z indeksu w przypadku utrzymujących się błędów. Nie ma udokumentowanej pobłażliwości wobec 502.
• Mit: „Jednorazowy 502 wyindeksuje moją stronę”. Nie. Crawlowanie zwalnia, a potem stopniowo przyspiesza. Spadki w indeksie wymagają, by błąd utrzymywał się — dokumentacja Google używa tego słowa bez określenia dokładnej liczby dni. Nieformalny komentarz Muellera z listopada 2025 r. wskazywał około kilku dni i dodawał, że usunięte strony „dość szybko wracają” — traktuj to jako praktyczną interpretację jednego incydentu, a nie oficjalny próg.
• Mit: „502 i 503 oznaczają to samo”. Nie. 503 to kod celowego „serwisu niedostępnego”, którego należy używać przy planowanej konserwacji (z nagłówkiem Retry-After); 502 to niezamierzona awaria proxy. Mylenie ich w monitoringu ukrywa rzeczywiste incydenty za oczekiwanymi oknami konserwacji.
• Mit: „Wyczyszczenie pamięci podręcznej przeglądarki naprawia 502 w całej witrynie”. To rada dla odwiedzającego rozwiązującego problem własnego widoku. Jeśli CDN/proxy/origin faktycznie zawodzi, działanie po stronie przeglądarki niczego nie zmieni dla innych osób.
• Antywzorzec: odruchowe klikanie „Validate Fix” i odświeżanie GSC. Podczas przejściowego skoku (albo awarii CDN) najszybszym i właściwym działaniem często jest nie robić nic, tylko potwierdzić powrót usługi. Google automatycznie obsługuje ponowne stopniowe zwiększanie tempa.

Playbook incydentu: witryna zwraca 502

1. Potwierdź zakres. Sprawdź jeden dotknięty problemem adres URL za pomocą narzędzia Website Down Checker, a następnie przetestuj wiele adresów URL za pomocą Bulk HTTP Status Code Checker. Jeśli zawodzi tylko Twoja przeglądarka, usuń lokalny problem z siecią lub DNS, zanim eskalujesz incydent obejmujący całą witrynę. Jeśli wiele publicznych adresów URL zwraca 502, przejdź dalej.
2. Zapisz nieudaną odpowiedź. Zachowaj czas, adres URL, status, nagłówki odpowiedzi i dowolny identyfikator żądania CDN. Jeśli błąd występuje sporadycznie, powtórz żądanie, zamiast uznawać pojedynczą udaną próbę za powrót usługi.
3. Zidentyfikuj bramę — traktuj branding jako jeden z sygnałów, a nie dowód. Odczytaj nagłówki i oznaczoną stronę błędu, szukając charakterystycznych cech CDN, reverse proxy albo load balancera, ale przed wyciągnięciem wniosku o uszkodzonym odcinku potwierdź to na stronie statusu dostawcy i w swoich logach; oznaczone strony i nagłówki zależą od dostawcy i nie dowodzą uniwersalnie przyczyny. Jeśli dostawca zgłasza awarię, postępuj zgodnie z jego ścieżką obsługi incydentu; w przeciwnym razie kieruj się dalej w stronę originu.
4. Porównaj brzeg i origin. Wyślij żądanie do publicznej nazwy hosta w zwykły sposób, a następnie wyślij tę samą nazwę hosta bezpośrednio do znanego adresu IP originu za pomocą curl --resolve. Dzięki temu publiczna nazwa hosta pozostaje w nagłówku HTTP Host i nazwie TLS, a połączenie odbywa się z tym adresem IP. Jeśli origin działa, ale brzeg zwraca 502, sprawdź łączność CDN z originem, TLS i konfigurację proxy. Jeśli oba żądania zawodzą, przejdź do logów aplikacji i originu.
5. Skoreluj logi według znacznika czasu. Odmowa połączenia albo błąd TLS wskazują na granicę gateway/origin; zniekształcona lub nagle zamknięta odpowiedź upstreamu wskazuje na usługę originu. Napraw warstwę, która zawodzi, a nie Search Console.
6. Zweryfikuj powrót usługi. Ponownie wykonaj kontrole publiczne i bezpośrednio do originu dla reprezentatywnych adresów URL. Jeśli odpowiedzi 2xx są stabilne, monitoruj logi i Search Console, gdy Googlebot automatycznie wznowi crawlowanie. Jeśli 502 powrócą, wróć do kroku 4 z nowymi znacznikami czasu, zamiast bezmyślnie zwiększać liczbę prób.

Prompt: klasyfikowanie partii błędów 502 według warstwy

Wklej plik CSV zawierający adres URL, znacznik czasu, status, nagłówki odpowiedzi, wynik na publicznym brzegu, wynik bezpośrednio na originie i pasujący fragment logu. Najpierw usuń sekrety, pliki cookie, nagłówki autoryzacji i prywatne adresy originu.

You are triaging HTTP 502 Bad Gateway failures. A 502 means a gateway or proxy
received an invalid response from an upstream server. Classify each row as one of:
CDN/edge, reverse proxy or load balancer, origin application/server, local-only,
provider-wide outage, or insufficient evidence.

For every row:
1. Cite the exact supplied evidence that supports the classification.
2. State the next check that would distinguish the leading cause from the runner-up.
3. Do not infer a cause from the 502 code alone.
4. Flag cases where the public edge fails but a same-host direct-origin test succeeds.
5. Group failures that share a timestamp, header fingerprint, or upstream log error.

Return a table with URL, likely layer, confidence (high/medium/low), evidence, next
check, and incident group. End with the three highest-value checks for the batch.

DATA:
[PASTE SANITIZED CSV HERE]

Oczekuj kolejki do triage’u, a nie ostatecznego raportu o przyczynie źródłowej. Zweryfikuj każdą sugerowaną kontrolę na podstawie aktualnych nagłówków i logów.

Odtwórz publiczny błąd 502

Uruchom to w powłoce macOS/Linux. Polecenie wyświetla nagłówki odpowiedzi bez pobierania treści i nie podąża za przekierowaniami, więc zobaczysz pierwszą odpowiedź.

curl -sS -D - -o /dev/null https://www.example.com/affected-path

Odpowiednik w PowerShellu:

Invoke-WebRequest -Uri 'https://www.example.com/affected-path' -Method Head -SkipHttpErrorCheck

Jeśli aplikacja obsługuje HEAD inaczej, użyj zwykłego GET i odrzuć treść odpowiedzi:

Invoke-WebRequest -Uri 'https://www.example.com/affected-path' -SkipHttpErrorCheck | Select-Object StatusCode, Headers

Porównaj trasę CDN ze znanym originem

Zastąp 203.0.113.10 adresem IP originu, nad którym masz kontrolę. --resolve zachowuje publiczną nazwę hosta dla nagłówka HTTP Host i nazwy TLS, jednocześnie łącząc się z tym adresem IP.

curl -sS -D - -o /dev/null \
  --resolve www.example.com:443:203.0.113.10 \
  https://www.example.com/affected-path

Nie ujawniaj chronionego originu ani nie osłabiaj jego firewalla tylko po to, by wykonać ten test. Uruchom go z sieci, która ma już autoryzowany dostęp. Publiczny 502 przy jednoczesnym sukcesie połączenia bezpośrednio z originem zawęża awarię do ścieżki CDN/proxy; niepowodzenie na obu ścieżkach kieruje uwagę na origin lub aplikację.

Narzędzia pomocne w zawężaniu problemu 502

• Website Down Checker — potwierdź, czy adres URL jest osiągalny z zewnętrznego punktu obserwacyjnego Cloudflare, i zbierz dane o czasie, przekierowaniach oraz ograniczonym zakresie DNS. Odpowiada na pytanie „czy problem występuje tylko u mnie?” zanim zaczniesz zmieniać infrastrukturę.
• Bulk HTTP Status Code Checker — przetestuj reprezentatywny zestaw adresów URL, zobacz pełne ścieżki przekierowań i opóźnienia oraz wyeksportuj wyniki. Użyj go, aby odróżnić awarię jednej trasy od szerszego incydentu 502.
• Panel Twojego CDN lub load balancera — dopasuj identyfikatory żądań i znaczniki czasu z nieudanej odpowiedzi do logów brzegu i statusu dostawcy.
• Logi aplikacji originu i serwera — potwierdź, czy upstream przyjął żądanie oraz czy zwrócił, zresetował albo zniekształcił odpowiedź. To właśnie zamienia hipotezę o warstwie w przyczynę źródłową.

Żadne narzędzie nie wskaże wadliwej warstwy na podstawie samego 502. Porównaj dowody z publicznego brzegu z autoryzowanym żądaniem bezpośrednio do originu oraz logami opatrzonymi znacznikami czasu.

Sprawdź się: 502 Bad Gateway

Pięć krótkich pytań o tym, czym jest 502 i jak wpływa na SEO. Wybierz odpowiedź na każde pytanie, a następnie sprawdź wynik.

Wartościowe materiały

Moje powiązane teksty

• Kompleksowy przewodnik po kodach statusu HTTP dla SEO — gdzie 502 i pozostałe kody z rodziny 5xx pasują do całości oraz co każdy z nich sygnalizuje wyszukiwarkom.
• Przewodnik po technicznym SEO dla początkujących — jak kondycja serwera i crawlowanie łączą się z szerszym obrazem.
• Robots.txt i SEO: wszystko, co musisz wiedzieć — istotne, ponieważ plik robots.txt zwracający błąd 5xx jest obsługiwany w szczególny sposób.

Z całej branży

• Jak kody statusu HTTP wpływają na crawlery Google (Google Search Central) — podstawowe źródło: 502 (bad gateway) jest grupowany z 500/503, wraz z dokładnym opisem wpływu na tempo crawlowania i indeksowanie.
• Jak postępować podczas planowanej niedostępności witryny (Google Search Central) — różnica między 503 a 502 oraz wyjaśnienie, dlaczego 503 jest kodem dla celowej niedostępności.
• Awaria Cloudflare wywołuje skok liczby błędów 5xx: co to oznacza dla SEO (Matt G. Southern, Search Engine Journal) — awaria z listopada 2025 r. jako studium przypadku z komentarzami Muellera.
• 502 Bad Gateway: dokumentacja MDN (MDN Web Docs) — neutralna definicja kodu statusu na poziomie specyfikacji.
• RFC 9110 §15.6.3 — 502 (Bad Gateway) (IETF) — podstawowa specyfikacja semantyki HTTP.
• Jak naprawić błąd 502 Bad Gateway (Kinsta) — szczegółowy przewodnik rozwiązywania problemów z perspektywy hosta, obejmujący poprawki po stronie przeglądarki i witryny.
• 502 bad gateway: co oznacza i jak web developerzy mogą naprawić te błędy (Webflow) — omówienie przyczyn i poprawek skierowane do developerów.

Dziennik zmian