HTTPS 502 – znaczenie błędu Bad Gateway, przyczyny i sposoby naprawy

IT/Komputery/Gry Komputerowe

HTTPS 502 – znaczenie błędu Bad Gateway, przyczyny i sposoby naprawy

HTTPS 502 to komunikat informujący, że serwer pośredniczący w obsłudze żądania nie otrzymał prawidłowej odpowiedzi od serwera znajdującego się dalej w infrastrukturze. Najczęściej użytkownik widzi wtedy stronę z napisem 502 Bad Gateway, „HTTP Error 502”, „502 Proxy Error” albo „The server returned an invalid response”. Problem może wystąpić zarówno w zwykłych witrynach internetowych, jak i w sklepach, aplikacjach SaaS, panelach administracyjnych, interfejsach API oraz systemach korzystających z usług chmurowych.

Obecność skrótu HTTPS nie oznacza, że kod 502 jest osobnym błędem szyfrowania. HTTPS określa sposób bezpiecznego przesyłania danych pomiędzy klientem a serwerem, natomiast liczba 502 jest kodem odpowiedzi HTTP. Błąd może jednak wynikać z problemu dotyczącego certyfikatu, protokołu TLS albo konfiguracji bezpiecznego połączenia między serwerem proxy i serwerem źródłowym.

Współczesna strona internetowa bardzo rzadko jest obsługiwana przez jeden samodzielny serwer. Żądanie użytkownika może przejść przez sieć CDN, zaporę WAF, load balancer, reverse proxy, serwer aplikacji, interpreter PHP, kontener i zewnętrzny interfejs API. Awaria komunikacji na jednym z tych etapów może zakończyć się odpowiedzią HTTPS 502 Bad Gateway.

Dla zwykłego użytkownika błąd zwykle oznacza chwilową niedostępność strony. Dla administratora jest natomiast sygnałem, że należy przeanalizować komunikację między warstwami infrastruktury, logi serwerów, stan aplikacji, konfigurację DNS, reguły zapory oraz ustawienia TLS.

HTTPS 502 co to znaczy

Kod 502 należy do grupy odpowiedzi serwerowych 5xx. Informuje, że serwer działający jako brama lub pośrednik otrzymał nieprawidłową odpowiedź od serwera nadrzędnego, z którym próbował się skomunikować.

W praktyce przepływ może wyglądać następująco:

  1. użytkownik otwiera stronę przez HTTPS,
  2. przeglądarka łączy się z serwerem proxy albo CDN,
  3. serwer pośredniczący przekazuje żądanie do aplikacji,
  4. aplikacja nie odpowiada poprawnie,
  5. proxy zwraca użytkownikowi kod 502.

Błąd nie musi oznaczać, że serwer pośredniczący całkowicie nie działa. Wręcz przeciwnie: skoro wyświetla komunikat 502, prawdopodobnie jest dostępny i potrafi odpowiedzieć przeglądarce. Problem pojawia się za nim, po stronie tak zwanego upstreamu, czyli usługi, od której proxy oczekuje odpowiedzi.

Co oznacza Bad Gateway

Angielskie określenie „Bad Gateway” można przetłumaczyć jako „nieprawidłowa brama” albo „błąd bramy”. W kontekście technicznym nie oznacza ono zwykle awarii routera użytkownika. Brama to serwer pośredniczący między klientem a inną usługą.

Taką rolę może pełnić:

  • NGINX,
  • Apache skonfigurowany jako proxy,
  • load balancer,
  • Cloudflare,
  • inny dostawca CDN,
  • kontroler Ingress w Kubernetes,
  • brama API,
  • serwer obsługujący mikroserwisy.

Brama otrzymuje żądanie i próbuje przekazać je dalej. Jeżeli odpowiedź kolejnego serwera jest niepoprawna, połączenie zostanie zerwane albo usługa będzie niedostępna, użytkownik może zobaczyć kod 502.

HTTP 502 a HTTPS 502

Kod stanu pozostaje ten sam bez względu na to, czy użytkownik odwiedza stronę za pośrednictwem HTTP, czy HTTPS. Różnica dotyczy warstwy zabezpieczającej komunikację.

HTTP przesyła dane bez ochrony zapewnianej przez TLS. HTTPS szyfruje połączenie, uwierzytelnia serwer przy użyciu certyfikatu i pomaga chronić dane przed przechwyceniem.

Określenie HTTPS 502 pojawia się najczęściej wtedy, gdy błąd 502 wystąpił na stronie otwieranej przez bezpieczny adres rozpoczynający się od https://.

Czy błąd 502 oznacza problem z certyfikatem

Nie zawsze. Kod 502 może być wywołany przez wiele innych problemów, takich jak zatrzymana aplikacja, przeciążony serwer, błędny port albo nieprawidłowy socket PHP-FPM.

Certyfikat może jednak pośrednio spowodować błąd, jeżeli proxy łączy się z upstreamem przez HTTPS i nie potrafi ukończyć negocjacji TLS. Przyczyną może być wtedy:

  • nieważny certyfikat upstreamu,
  • niezgodna nazwa hosta,
  • brak pełnego łańcucha certyfikatów,
  • nieobsługiwana wersja TLS,
  • błędna konfiguracja SNI,
  • certyfikat wystawiony przez niezaufane centrum,
  • niezgodne szyfry,
  • certyfikat, który wygasł.

W takim przypadku połączenie użytkownika z pierwszym serwerem może być prawidłowo zabezpieczone, ale kolejne połączenie wewnątrz infrastruktury nie dochodzi do skutku.

Jak powstaje błąd HTTPS 502

Aby zrozumieć źródło problemu, warto spojrzeć na typową architekturę aplikacji.

Uproszczony przepływ wygląda następująco:

Przeglądarka → CDN → load balancer → NGINX → aplikacja → baza danych

Nie każda witryna korzysta ze wszystkich tych elementów, ale każda dodatkowa warstwa zwiększa liczbę możliwych punktów awarii.

Przeglądarka wysyła żądanie

Użytkownik wpisuje adres strony albo klika link. Przeglądarka ustala adres IP domeny, nawiązuje bezpieczne połączenie i wysyła żądanie HTTP.

CDN albo proxy przyjmuje połączenie

Pierwszym serwerem może być dostawca CDN. Sprawdza on, czy posiada gotową kopię treści. Jeżeli jej nie ma, kontaktuje się z serwerem źródłowym.

Reverse proxy przekazuje żądanie

Serwer źródłowy może korzystać z NGINX jako reverse proxy. NGINX przyjmuje żądanie i przesyła je do aplikacji działającej na innym porcie, w kontenerze albo przez socket systemowy.

Upstream odpowiada nieprawidłowo

Aplikacja może nie działać, przerwać połączenie lub zwrócić odpowiedź, której proxy nie potrafi obsłużyć. W rezultacie serwer pośredniczący zwraca kod 502.

Najczęstsze przyczyny błędu HTTPS 502

Nie istnieje jedna przyczyna wspólna dla wszystkich przypadków. Ten sam komunikat może być rezultatem zupełnie różnych problemów.

Niedziałający serwer aplikacji

Jedną z najczęstszych przyczyn jest zatrzymanie aplikacji, do której reverse proxy przekazuje ruch. Może to być proces:

  • Node.js,
  • PHP-FPM,
  • Gunicorn,
  • Uvicorn,
  • Java,
  • .NET,
  • Ruby,
  • aplikacja działająca w kontenerze.

Jeżeli NGINX próbuje połączyć się z portem 3000, ale proces Node.js nie działa, połączenie zostanie odrzucone. Użytkownik może wtedy zobaczyć 502 Bad Gateway.

Jak rozpoznać zatrzymaną aplikację

W logu NGINX może pojawić się komunikat podobny do:

connect() failed (111: Connection refused) while connecting to upstream

Oznacza on, że proxy próbowało połączyć się z upstreamem, lecz pod wskazanym adresem i portem nie działała usługa przyjmująca połączenia.

Należy wtedy sprawdzić stan procesu, kontenera albo usługi systemowej.

Błędny adres IP lub port upstreamu

Aplikacja może działać poprawnie, ale proxy może kierować ruch pod niewłaściwy adres.

Przykładowa błędna konfiguracja:

location / {
    proxy_pass http://127.0.0.1:3001;
}

Jeżeli aplikacja działa na porcie 3000, NGINX nie uzyska odpowiedzi.

Podobny problem może wystąpić po zmianie architektury, migracji serwera, uruchomieniu nowego kontenera albo zmianie nazwy usługi w Docker Compose lub Kubernetes.

Localhost w kontenerach

Częstym błędem jest założenie, że localhost wszędzie wskazuje ten sam system. W kontenerze 127.0.0.1 oznacza najczęściej bieżący kontener, a nie inny kontener ani host.

Jeżeli NGINX i aplikacja działają w osobnych kontenerach, proxy powinno zwykle korzystać z nazwy usługi dostępnej w sieci kontenerowej.

Problem z socketem PHP-FPM

W środowiskach WordPress, WooCommerce i innych aplikacjach PHP kod 502 często wiąże się z PHP-FPM.

NGINX może przekazywać pliki PHP do:

  • portu TCP,
  • socketu uniksowego.

Przykładowa konfiguracja:

fastcgi_pass unix:/run/php/php8.3-fpm.sock;

Jeżeli po aktualizacji systemu aktywny socket ma inną nazwę, NGINX nie połączy się z PHP-FPM.

W logu może pojawić się komunikat:

connect() to unix:/run/php/php8.3-fpm.sock failed

Należy wtedy sprawdzić:

  • czy PHP-FPM działa,
  • jaką wersję PHP uruchomiono,
  • gdzie znajduje się socket,
  • czy NGINX ma odpowiednie uprawnienia,
  • czy konfiguracja wskazuje właściwy plik.

Przeciążenie serwera

Serwer aplikacyjny może działać, ale nie być w stanie obsłużyć nowych żądań. Przyczyną może być:

  • gwałtowny wzrost ruchu,
  • niewystarczająca pamięć RAM,
  • pełne użycie procesora,
  • zbyt mała liczba workerów,
  • wyczerpanie dostępnych połączeń,
  • długie zapytania do bazy,
  • atak DDoS,
  • nieprawidłowa pętla w aplikacji,
  • wyciek pamięci.

Przeciążony proces może zostać zakończony przez system albo samoczynnie przerwać połączenie. Proxy otrzymuje wtedy niepełną lub nieprawidłową odpowiedź.

Brak pamięci

Na serwerze Linux mechanizm OOM Killer może zakończyć proces zużywający zbyt dużo pamięci. Aplikacja nagle znika, a NGINX zaczyna zwracać błędy 502.

Należy sprawdzić logi systemowe, zużycie pamięci, konfigurację limitów i stan procesów.

Restart albo wdrożenie aplikacji

Błąd może pojawiać się przez kilka sekund podczas wdrożenia nowej wersji. Stary proces zostaje zatrzymany, ale nowy nie jest jeszcze gotowy do przyjmowania ruchu.

Problem jest szczególnie widoczny, gdy wdrożenie nie korzysta z mechanizmów:

  • rolling update,
  • health check,
  • readiness probe,
  • blue-green deployment,
  • graceful shutdown.

Load balancer powinien kierować ruch wyłącznie do instancji, które są gotowe. Jeżeli zacznie wysyłać żądania zbyt wcześnie, użytkownicy zobaczą 502.

Nieprawidłowa odpowiedź HTTP

Upstream może przyjąć połączenie, ale przesłać odpowiedź niezgodną z oczekiwanym formatem.

Problem może dotyczyć:

  • nieprawidłowych nagłówków,
  • uszkodzonej linii statusu,
  • zbyt dużego nagłówka,
  • przedwczesnego zakończenia odpowiedzi,
  • pomieszania protokołów,
  • niewłaściwego kodowania.

Serwer proxy nie potrafi wtedy poprawnie zinterpretować odpowiedzi i może zwrócić 502.

Zbyt duże nagłówki odpowiedzi

Aplikacja może przesłać nagłówek przekraczający bufor dostępny w proxy. Zdarza się to między innymi przy:

  • bardzo dużych cookies,
  • rozbudowanych nagłówkach bezpieczeństwa,
  • długich tokenach,
  • nieprawidłowo tworzonej sesji,
  • wielokrotnych przekierowaniach,
  • ogromnych nagłówkach Set-Cookie.

W logu NGINX może pojawić się komunikat:

upstream sent too big header while reading response header from upstream

Rozwiązaniem może być usunięcie źródła nadmiernych nagłówków lub ostrożne zwiększenie odpowiednich buforów.

Nie należy automatycznie zwiększać limitów bez analizy aplikacji. Bardzo duży nagłówek może świadczyć o błędzie logicznym albo źle zaprojektowanym mechanizmie sesji.

Nieprawidłowe DNS

Proxy może odwoływać się do upstreamu za pomocą nazwy domenowej. Jeżeli DNS zwraca stary lub niewłaściwy adres IP, ruch trafia do nieprawidłowego serwera.

Problemy mogą wystąpić po:

  • migracji hostingu,
  • zmianie rekordu A lub AAAA,
  • zmianie dostawcy CDN,
  • modyfikacji rekordów wewnętrznych,
  • zmianie adresu kontenera,
  • nieudanej propagacji DNS.

Warto porównać odpowiedzi DNS z różnych resolverów oraz sprawdzić, czy serwer proxy używa aktualnego adresu.

Nieprawidłowy rekord IPv6

Domena może posiadać rekord AAAA kierujący do serwera, który nie obsługuje poprawnie ruchu. Część połączeń może wtedy kończyć się błędem, mimo że rekord IPv4 działa prawidłowo.

Administrator powinien sprawdzić oba typy adresów i przetestować połączenie osobno przez IPv4 oraz IPv6.

Firewall blokujący połączenie

Zapora może pozwalać użytkownikom łączyć się z proxy, ale blokować ruch proxy do serwera źródłowego.

Problem często pojawia się po:

  • zmianie adresów CDN,
  • zaostrzeniu reguł bezpieczeństwa,
  • migracji do innej podsieci,
  • zmianie portu aplikacji,
  • wdrożeniu narzędzia ochronnego,
  • błędnej konfiguracji security group w chmurze.

Jeżeli witryna korzysta z Cloudflare albo innego CDN, serwer źródłowy powinien akceptować ruch z aktualnych zakresów adresów tego dostawcy.

Nieprawidłowa konfiguracja TLS

W architekturze HTTPS szyfrowanie może być zakończone na pierwszym proxy albo kontynuowane aż do serwera aplikacji.

Przykładowe warianty:

  • użytkownik łączy się przez HTTPS, proxy łączy się z aplikacją przez HTTP,
  • użytkownik łączy się przez HTTPS, proxy również używa HTTPS do upstreamu,
  • CDN łączy się przez HTTPS z load balancerem, a ten przez HTTPS z aplikacją.

Im więcej szyfrowanych etapów, tym więcej miejsc wymagających poprawnej konfiguracji certyfikatów.

Błędny protokół w proxy_pass

Jeżeli aplikacja obsługuje HTTP, a konfiguracja wskazuje HTTPS:

proxy_pass https://127.0.0.1:3000;

proxy podejmie próbę negocjacji TLS z usługą, która oczekuje zwykłego HTTP. Połączenie nie powiedzie się.

Odwrotna sytuacja również jest problemem: użycie http:// wobec serwera wymagającego TLS.

Błąd SNI

Gdy na jednym adresie IP działa wiele hostów HTTPS, serwer musi wiedzieć, dla której domeny powinien przedstawić certyfikat. Służy do tego SNI.

Reverse proxy łączące się z upstreamem po nazwie może wymagać włączenia prawidłowej obsługi SNI i przekazania właściwej nazwy serwera.

Bez tego upstream może przedstawić certyfikat dla innej domeny, a połączenie zostanie odrzucone.

Awaria CDN

Kod 502 może zostać wygenerowany zarówno przez serwer źródłowy, jak i przez dostawcę CDN. Jeżeli CDN nie może nawiązać poprawnego kontaktu z originem, użytkownik może zobaczyć jego stronę błędu.

Przyczyny obejmują:

  • niedostępny origin,
  • odrzucanie adresów CDN przez firewall,
  • błąd certyfikatu originu,
  • nieprawidłowy DNS,
  • niezgodny port,
  • przeciążenie,
  • awarię po stronie dostawcy CDN.

W przypadku popularnych usług warto sprawdzić stronę statusu oraz rozróżnić, czy błąd został wygenerowany przez CDN, czy przekazany z serwera źródłowego.

Awaria load balancera

Load balancer rozdziela ruch pomiędzy kilka instancji aplikacji. Jeżeli wszystkie zostaną uznane za niedostępne, może zwrócić 502.

Możliwą przyczyną są źle skonfigurowane health checki. Aplikacja może działać, ale test zdrowia sprawdza niewłaściwy port, ścieżkę albo protokół.

Zdarza się również sytuacja odwrotna: test jest zbyt prosty i uznaje instancję za sprawną, mimo że nie potrafi ona obsługiwać rzeczywistych żądań.

Błąd kontenera

W Dockerze lub Kubernetesie 502 może pojawić się, gdy:

  • kontener aplikacji się restartuje,
  • proces zakończył działanie,
  • port nie został wystawiony,
  • nazwa usługi jest błędna,
  • kontenery nie znajdują się w tej samej sieci,
  • readiness probe nie działa,
  • polityka sieciowa blokuje ruch,
  • Service wskazuje niewłaściwy targetPort.

W Kubernetesie należy sprawdzić Pod, Service, EndpointSlice, Ingress i logi kontrolera.

Problem z WebSocket

Aplikacje czasu rzeczywistego często korzystają z WebSocket. Reverse proxy musi odpowiednio przekazywać nagłówki związane z aktualizacją połączenia.

Błędna konfiguracja może prowadzić do nieudanego handshake’u, zerwania połączenia lub kodu 502.

W NGINX zwykle istotne są między innymi nagłówki:

proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection \"upgrade\";

Konkretna konfiguracja powinna jednak odpowiadać używanej aplikacji i wersji protokołu.

Problem z zewnętrznym API

Aplikacja może działać poprawnie, ale podczas obsługi żądania kontaktować się z zewnętrzną usługą. Jeżeli zewnętrzne API nie odpowiada, kod aplikacji może zakończyć się błędem albo zerwać odpowiedź przekazywaną do proxy.

Należy wtedy rozróżnić:

  • 502 zwracany bezpośrednio przez zewnętrzne API,
  • 502 generowany przez własne proxy,
  • 502 wynikający z awarii aplikacji czekającej na API.

Dobra architektura powinna stosować limity czasu, ponawianie z kontrolą, circuit breaker i odpowiednie komunikaty błędów.

Różne komunikaty błędu HTTPS 502

Kod może być przedstawiany w wielu formach:

  • 502 Bad Gateway,
  • HTTP 502,
  • HTTPS 502,
  • 502 Proxy Error,
  • Error 502,
  • HTTP Error 502 – Bad Gateway,
  • NGINX 502 Bad Gateway,
  • Cloudflare 502 Bad Gateway,
  • upstream connect error,
  • server returned an invalid response.

Wygląd strony zależy od serwera, proxy i konfiguracji witryny.

Niektóre platformy ukrywają szczegóły techniczne i pokazują jedynie ogólny komunikat o niedostępności usługi.

HTTPS 502 a inne błędy serwera

Kody 5xx bywają mylone, ale opisują odmienne sytuacje.

500 Internal Server Error

Kod 500 oznacza ogólny wewnętrzny błąd serwera. Może wystąpić bez udziału proxy.

502 wskazuje natomiast na problem z odpowiedzią serwera nadrzędnego podczas pracy bramy lub pośrednika.

Przykład:

  • aplikacja wykrywa nieobsłużony wyjątek i sama zwraca 500,
  • NGINX nie może uzyskać prawidłowej odpowiedzi od aplikacji i zwraca 502.

503 Service Unavailable

503 oznacza, że usługa jest chwilowo niedostępna. Może wynikać z przeciążenia, konserwacji albo świadomego wyłączenia.

Aplikacja lub load balancer może zwrócić 503, gdy wie, że nie jest gotowy do obsługi żądania.

504 Gateway Timeout

504 oznacza, że serwer działający jako brama nie otrzymał odpowiedzi na czas.

W dużym uproszczeniu:

  • 502 – proxy nie otrzymało prawidłowej odpowiedzi,
  • 504 – proxy nie doczekało się odpowiedzi w wymaganym czasie.

Granica w praktyce może zależeć od implementacji i momentu wystąpienia awarii.

521 i inne błędy CDN

Niektórzy dostawcy CDN stosują własne kody opisujące komunikację z originem. Nie są one identyczne z kodami standardowymi.

Jeżeli błąd jest wyświetlany przez CDN, należy korzystać z dokumentacji konkretnego dostawcy i zwrócić uwagę na identyfikator żądania.

Co może zrobić użytkownik strony

Użytkownik zwykle nie ma dostępu do serwera, dlatego jego możliwości są ograniczone. Błąd 502 najczęściej musi zostać naprawiony przez właściciela strony albo dostawcę infrastruktury.

Można jednak wykonać kilka prostych czynności.

Odśwież stronę

Błąd może być chwilowy i zniknąć po ponownym załadowaniu. Nie należy jednak wielokrotnie odświeżać strony co sekundę, zwłaszcza jeśli serwer jest przeciążony.

Otwórz stronę w trybie prywatnym

Tryb prywatny pomaga wykluczyć część problemów związanych z zapisanymi danymi sesji oraz rozszerzeniami.

Sprawdź inną przeglądarkę

Jeżeli błąd pojawia się wyłącznie w jednej przeglądarce, problem może dotyczyć jej konfiguracji, proxy, rozszerzenia lub pamięci podręcznej.

Sprawdź inne urządzenie i połączenie

Można otworzyć stronę na telefonie przez sieć komórkową. Jeżeli działa, problem może dotyczyć lokalnej sieci, operatora albo używanego DNS.

Wyczyść dane konkretnej strony

Uszkodzone cookies rzadko są główną przyczyną prawdziwego kodu 502, ale mogą powodować nietypowe zachowanie aplikacji lub kierowanie do błędnego backendu.

Lepiej najpierw usunąć dane konkretnej witryny niż całą historię i wszystkie cookies.

Sprawdź, czy awaria dotyczy innych

Warto sprawdzić oficjalne kanały firmy, stronę statusu lub komunikaty administratora.

Nie wysyłaj ponownie płatności bez sprawdzenia

Jeżeli 502 pojawił się podczas płatności lub składania zamówienia, nie należy od razu ponawiać operacji. Żądanie mogło zostać przetworzone, mimo że odpowiedź nie dotarła do przeglądarki.

Najpierw należy sprawdzić:

  • historię zamówień,
  • pocztę,
  • rachunek bankowy,
  • potwierdzenie płatności.

To ważne, ponieważ ponowienie może doprowadzić do podwójnego obciążenia.

Jak naprawić HTTPS 502 jako administrator

Diagnostyka powinna przebiegać warstwowo. Chaotyczne zmienianie timeoutów, DNS i certyfikatów może utrudnić odnalezienie prawdziwej przyczyny.

Ustal, która warstwa generuje 502

Najpierw należy określić, kto zwraca odpowiedź:

  • CDN,
  • load balancer,
  • NGINX,
  • Apache,
  • brama API,
  • aplikacja.

Pomocne są:

  • nagłówki odpowiedzi,
  • wygląd strony błędu,
  • identyfikator żądania,
  • logi,
  • test originu bez CDN.

Przykładowe polecenie:

curl -I https://example.com

Bardziej szczegółowy test:

curl -v https://example.com

Opcja -v pokazuje przebieg połączenia, negocjację TLS, nagłówki i odpowiedź serwera.

Sprawdź logi reverse proxy

W przypadku NGINX najważniejsze są zwykle:

  • access log,
  • error log.

Przykładowe lokalizacje:

/var/log/nginx/access.log
/var/log/nginx/error.log

Polecenie:

sudo tail -f /var/log/nginx/error.log

W logach można znaleźć komunikaty wskazujące na:

  • connection refused,
  • no such file or directory,
  • upstream prematurely closed connection,
  • too big header,
  • SSL handshake failure,
  • timeout,
  • brak uprawnień.

Treść komunikatu jest znacznie bardziej użyteczna niż sam kod widoczny w przeglądarce.

Sprawdź stan aplikacji

Dla usługi systemd można użyć:

sudo systemctl status nazwa-uslugi

Przykład dla PHP-FPM:

sudo systemctl status php8.3-fpm

Logi usługi:

sudo journalctl -u php8.3-fpm

Dla aplikacji działającej w kontenerze:

docker ps
docker logs nazwa-kontenera

W Kubernetesie:

kubectl get pods
kubectl describe pod nazwa-poda
kubectl logs nazwa-poda

Należy sprawdzić nie tylko, czy proces istnieje, ale również czy jest gotowy i słucha na oczekiwanym porcie.

Sprawdź port

Na serwerze Linux można sprawdzić aktywne porty:

sudo ss -lntp

Jeżeli aplikacja powinna działać na porcie 3000, można przetestować ją lokalnie:

curl -v http://127.0.0.1:3000/

Jeżeli lokalne żądanie nie działa, problem prawdopodobnie znajduje się w aplikacji albo jej konfiguracji, a nie w publicznym HTTPS.

Przetestuj upstream bez proxy

Bezpośrednie wywołanie backendu pomaga rozdzielić problem proxy od problemu aplikacji.

Przykład dla HTTP:

curl -v http://127.0.0.1:8080/health

Przykład dla HTTPS:

curl -vk https://backend.example.internal/health

Opcja -k pomija weryfikację certyfikatu i powinna służyć wyłącznie diagnostyce. Nie jest rozwiązaniem produkcyjnym.

Jeżeli test z -k działa, a bez niego nie, należy poprawić certyfikat albo zaufanie, zamiast wyłączać weryfikację.

Sprawdź konfigurację NGINX

Przed przeładowaniem konfiguracji należy wykonać test:

sudo nginx -t

Jeżeli wynik jest poprawny:

sudo systemctl reload nginx

Warto zweryfikować:

  • proxy_pass,
  • fastcgi_pass,
  • adres hosta,
  • port,
  • nazwę socketu,
  • protokół HTTP lub HTTPS,
  • nagłówki Host,
  • ustawienia SNI,
  • timeouty,
  • bufory,
  • resolver DNS.

Przykład prostego reverse proxy

server {
    listen 443 ssl;
    server_name example.com;

    ssl_certificate /etc/ssl/example/fullchain.pem;
    ssl_certificate_key /etc/ssl/example/privkey.pem;

    location / {
        proxy_pass http://127.0.0.1:3000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

Przykład jest ogólny. Produkcyjna konfiguracja powinna zostać dostosowana do aplikacji, zabezpieczeń oraz sposobu wdrożenia.

Sprawdź certyfikat upstreamu

Dla serwera HTTPS można użyć OpenSSL:

openssl s_client -connect backend.example.com:443 -servername backend.example.com

Polecenie pozwala zobaczyć certyfikat, łańcuch, nazwę serwera i rezultat negocjacji TLS.

Należy sprawdzić:

  • datę ważności,
  • nazwę domeny,
  • centrum certyfikacji,
  • pełny łańcuch,
  • obsługiwane protokoły.

Sprawdź DNS

Przydatne polecenia:

dig example.com
dig A example.com
dig AAAA example.com

Można porównać odpowiedzi różnych resolverów:

dig @1.1.1.1 example.com
dig @8.8.8.8 example.com

W środowisku wewnętrznym należy sprawdzić, jak nazwę rozwiązuje sam serwer proxy, a nie tylko komputer administratora.

Sprawdź firewall

Należy zweryfikować:

  • lokalne reguły systemowe,
  • security groups,
  • ACL,
  • zaporę dostawcy hostingu,
  • reguły WAF,
  • zakresy adresów CDN,
  • polityki sieciowe Kubernetes.

Test połączenia:

nc -vz backend.example.com 443

Albo:

curl -v https://backend.example.com

Brak połączenia nie zawsze oznacza firewall. Może również wskazywać na niedziałającą usługę lub zły adres.

Sprawdź obciążenie serwera

Przydatne polecenia:

top
htop
free -m
df -h
uptime

Należy sprawdzić:

  • użycie CPU,
  • RAM,
  • swap,
  • wolne miejsce na dysku,
  • load average,
  • liczbę procesów,
  • liczbę otwartych połączeń.

Pełny dysk może uniemożliwić zapisywanie logów, sesji, cache albo plików tymczasowych, co pośrednio doprowadzi do błędów aplikacji.

Sprawdź bazę danych

Aplikacja może zerwać odpowiedź, jeżeli nie potrafi połączyć się z bazą. Należy przeanalizować:

  • liczbę połączeń,
  • wolne zapytania,
  • blokady,
  • stan replikacji,
  • dostępność hosta,
  • poświadczenia,
  • certyfikaty,
  • wykorzystanie zasobów.

Sam błąd bazy nie musi zostać pokazany użytkownikowi bezpośrednio. Zewnętrzna warstwa może zobaczyć jedynie 502.

HTTPS 502 w WordPressie

W WordPressie częste przyczyny obejmują:

  • awarię PHP-FPM,
  • wadliwą wtyczkę,
  • przeciążenie,
  • zbyt niski limit pamięci,
  • błędny cache,
  • problem z bazą danych,
  • konflikt CDN,
  • nieudane wywołanie zewnętrznego API.

Wyłączanie wtyczek

Jeżeli panel nie działa, można tymczasowo zmienić nazwę katalogu wtyczki przez FTP lub SSH. Nie należy jednak wyłączać wszystkich elementów bez kopii i planu diagnostycznego.

Logi WordPressa

Można uruchomić logowanie błędów w środowisku testowym albo na krótki czas produkcyjnie, dbając o to, aby szczegóły nie były wyświetlane użytkownikom.

Najważniejsze jest połączenie informacji z logów WordPressa, PHP-FPM i serwera WWW.

HTTPS 502 w WooCommerce

W sklepie internetowym błąd może pojawiać się podczas:

  • dodawania produktu do koszyka,
  • obliczania dostawy,
  • płatności,
  • generowania zamówienia,
  • synchronizacji magazynu,
  • komunikacji z bramką płatniczą.

Takie operacje są szczególnie wrażliwe, ponieważ mogą zostać wykonane częściowo. System powinien stosować idempotency, poprawną obsługę transakcji i bezpieczne ponawianie żądań.

Po awarii należy sprawdzić, czy zamówienie lub płatność nie zostały utworzone mimo błędu widocznego dla klienta.

HTTPS 502 w Node.js

W aplikacjach Node.js typowe przyczyny to:

  • proces nie działa,
  • nieobsłużony wyjątek,
  • niewłaściwy port,
  • aplikacja nasłuchuje wyłącznie na niewłaściwym interfejsie,
  • przekroczenie pamięci,
  • zerwane połączenie,
  • błędna konfiguracja proxy,
  • niepoprawna obsługa WebSocket.

Aplikacja uruchomiona w kontenerze powinna często nasłuchiwać na 0.0.0.0, a nie tylko na 127.0.0.1, jeżeli ma być dostępna z innych kontenerów.

HTTPS 502 w PHP-FPM

W środowisku PHP warto sprawdzić:

  • stan usługi,
  • konfigurację poola,
  • limit workerów,
  • log błędów,
  • socket,
  • uprawnienia,
  • pm.max_children,
  • pamięć,
  • czas wykonywania skryptów.

Jeżeli wszystkie workery są zajęte, żądania mogą czekać lub zostać odrzucone.

Zwiększenie limitu procesów bez zwiększenia pamięci może pogorszyć sytuację. Konfigurację należy dobierać na podstawie zużycia zasobów pojedynczego procesu.

HTTPS 502 w Pythonie

W aplikacjach opartych na Django, Flask lub FastAPI kod 502 może wynikać z problemu z Gunicornem, Uvicornem albo innym serwerem aplikacyjnym.

Należy sprawdzić:

  • liczbę workerów,
  • timeout,
  • logi wyjątków,
  • zgodność socketu,
  • działanie modułu aplikacji,
  • zależności,
  • zmienne środowiskowe,
  • połączenia z bazą.

Jeżeli worker jest regularnie zabijany z powodu timeoutu, samo zwiększenie limitu może ukryć wolne zapytanie albo blokującą operację.

HTTPS 502 w Kubernetesie

W klastrze Kubernetes żądanie może przejść przez wiele zasobów:

Load Balancer → Ingress → Service → Pod

Błąd może powstać, gdy:

  • Service nie ma endpointów,
  • selector nie pasuje do Podów,
  • targetPort jest nieprawidłowy,
  • Pod nie jest Ready,
  • kontener nie słucha,
  • NetworkPolicy blokuje ruch,
  • Ingress używa złego protokołu,
  • certyfikat upstreamu jest niepoprawny.

Przydatne polecenia:

kubectl get ingress
kubectl get service
kubectl get pods
kubectl get endpoints
kubectl describe ingress nazwa
kubectl logs nazwa-poda

Warto też przeanalizować logi kontrolera Ingress.

HTTPS 502 w Cloudflare

Jeżeli strona korzysta z Cloudflare, należy ustalić, czy problem znajduje się na krawędzi sieci, czy przy połączeniu z originem.

Należy sprawdzić:

  • stronę statusu Cloudflare,
  • dostępność originu bez proxy,
  • certyfikat originu,
  • reguły firewalla,
  • rekordy DNS,
  • poprawność portów,
  • zasoby serwera,
  • logi originu,
  • identyfikator Ray ID.

Origin można testować ostrożnie, kierując żądanie bezpośrednio na jego adres IP i ustawiając odpowiedni nagłówek Host. Nie należy publicznie ujawniać adresu originu, jeżeli został ukryty ze względów bezpieczeństwa.

Czy zmiana timeoutu naprawia HTTPS 502

Zwiększenie timeoutu bywa często sugerowane, ale nie jest uniwersalnym rozwiązaniem.

Jeżeli aplikacja odpowiada zbyt wolno, dłuższy limit może zmniejszyć liczbę błędów. Może jednak także:

  • zwiększyć liczbę zajętych połączeń,
  • pogłębić przeciążenie,
  • opóźnić informację o awarii,
  • ukryć wolne zapytania,
  • pogorszyć doświadczenie użytkownika.

Timeout należy dobierać do charakteru operacji. Długie zadania warto przenieść do kolejki i wykonywać asynchronicznie, zamiast utrzymywać żądanie HTTP przez wiele minut.

Czy restart serwera naprawia błąd 502

Restart może przywrócić działanie, jeżeli proces się zawiesił albo zabrakło zasobów. Nie zawsze usuwa jednak źródło problemu.

Jeżeli aplikacja ma wyciek pamięci, błąd powróci. Jeżeli port jest źle skonfigurowany, restart niczego nie zmieni.

Po przywróceniu dostępności należy wykonać analizę przyczyny źródłowej.

Wpływ HTTPS 502 na SEO

Długotrwałe lub regularne błędy 502 mogą negatywnie wpływać na widoczność strony. Robot wyszukiwarki otrzymuje kod serwerowy i nie może pobrać treści.

Pojedyncza krótka awaria zwykle nie powoduje trwałych konsekwencji. Problemem jest:

  • wielogodzinna niedostępność,
  • regularne błędy,
  • 502 na ważnych podstronach,
  • błędy podczas dużej części crawl budgetu,
  • niestabilność po wdrożeniach.

Nie zamieniaj 502 na 200

Niektórzy administratorzy tworzą stronę błędu, która wizualnie informuje o awarii, ale zwraca kod 200. Jest to zła praktyka.

Kod 200 sugeruje, że treść została poprawnie dostarczona. Wyszukiwarka może zindeksować stronę awarii zamiast właściwej zawartości.

502 czy 503 podczas prac serwisowych

Planowana przerwa techniczna powinna być zwykle komunikowana kodem 503 Service Unavailable, a nie przypadkowym 502.

Można również zastosować nagłówek Retry-After, jeżeli wiadomo, kiedy usługa może wrócić.

Jak zapobiegać błędom HTTPS 502

Najlepszym podejściem jest ograniczenie prawdopodobieństwa awarii oraz skrócenie czasu jej wykrywania.

Monitoring dostępności

Zewnętrzny monitoring powinien regularnie sprawdzać kluczowe adresy i informować zespół o błędach.

Nie wystarczy test strony głównej. Należy monitorować także:

  • logowanie,
  • API,
  • koszyk,
  • płatność testową,
  • panel,
  • health endpointy,
  • krytyczne integracje.

Health check i readiness check

Health check powinien określać, czy proces działa. Readiness check powinien informować, czy jest gotowy do obsługi ruchu.

Aplikacja może działać jako proces, ale nadal ładować konfigurację, wykonywać migrację albo czekać na bazę. W takim stanie nie powinna otrzymywać ruchu.

Automatyczny restart

Narzędzia takie jak systemd, Docker, Kubernetes i menedżery procesów mogą automatycznie ponownie uruchamiać aplikację.

Restart nie zastępuje monitoringu, ale może skrócić awarię po pojedynczym zakończeniu procesu.

Wiele instancji aplikacji

Jedna instancja stanowi pojedynczy punkt awarii. Load balancer może rozdzielać ruch pomiędzy kilka działających kopii.

Wdrożenie wysokiej dostępności wymaga jednak:

  • poprawnych health checków,
  • wspólnego lub odpowiednio rozdzielonego stanu,
  • skalowalnej bazy,
  • spójnych wdrożeń,
  • monitorowania.

Graceful shutdown

Podczas wyłączania aplikacja powinna przestać przyjmować nowe żądania, ale dokończyć już rozpoczęte.

Nagłe zabicie procesu może zerwać aktywne odpowiedzi i doprowadzić do 502.

Ograniczanie ruchu

Rate limiting i ochrona przed przeciążeniem pomagają zabezpieczyć upstream przed nadmierną liczbą żądań.

Lepsze jest kontrolowane odrzucenie części ruchu niż całkowite załamanie aplikacji.

Cache

Cache może zmniejszyć liczbę żądań trafiających do backendu. Dotyczy to:

  • statycznych plików,
  • stron,
  • odpowiedzi API,
  • wyników zapytań,
  • danych sesyjnych.

Nie każda treść może być bezpiecznie buforowana. Szczególną ostrożność należy zachować przy danych osobowych, koszykach i panelach użytkownika.

Kolejki zadań

Operacje wymagające dużo czasu, takie jak generowanie raportów, przetwarzanie filmów czy wysyłanie tysięcy wiadomości, warto wykonywać poza cyklem zwykłego żądania.

Użytkownik może otrzymać potwierdzenie przyjęcia zadania, a wynik pobrać później.

Observability

Skuteczne diagnozowanie wymaga połączenia:

  • logów,
  • metryk,
  • śledzenia rozproszonego,
  • alertów,
  • identyfikatorów korelacyjnych.

Jeżeli każde żądanie ma unikalny identyfikator przekazywany przez proxy i mikroserwisy, łatwiej odtworzyć jego przebieg.

Alerty

Alert powinien reagować na:

  • wzrost liczby 502,
  • brak zdrowych upstreamów,
  • restarty aplikacji,
  • wysokie użycie zasobów,
  • błędy TLS,
  • odrzucane połączenia,
  • opóźnienia.

Zbyt wiele nieistotnych alertów prowadzi do ich ignorowania. Reguły powinny wskazywać problemy wymagające działania.

Plan reakcji na incydent

Zespół powinien wiedzieć:

  • kto otrzymuje alert,
  • gdzie znajdują się logi,
  • jak wyłączyć wadliwe wdrożenie,
  • jak przełączyć ruch,
  • jak poinformować klientów,
  • jak wykonać rollback,
  • jak dokumentować incydent.

Brak procedury wydłuża awarię i zwiększa ryzyko chaotycznych zmian.

Własna strona błędu 502

Administrator może przygotować czytelną stronę błędu. Powinna ona:

  • jasno informować o chwilowym problemie,
  • nie ujawniać danych technicznych,
  • zawierać kontakt lub link do statusu,
  • zachować właściwy kod 502,
  • być lekka i niezależna od niedziałającej aplikacji.

Nie należy wyświetlać użytkownikom stack trace, ścieżek systemowych, adresów wewnętrznych ani sekretów.

Bezpieczeństwo a HTTPS 502

Sam kod 502 nie oznacza włamania, ale może pojawić się podczas ataku lub błędnej konfiguracji zabezpieczeń.

Możliwe scenariusze obejmują:

  • DDoS przeciążający backend,
  • WAF blokujący legalny ruch,
  • skanowanie powodujące awarię wadliwego endpointu,
  • błędną rotację certyfikatu,
  • uszkodzenie usługi po nieautoryzowanej zmianie.

Nagły wzrost liczby 502 powinien zostać przeanalizowany również pod kątem bezpieczeństwa.

Czy HTTPS 502 jest niebezpieczny dla użytkownika

Sam komunikat nie infekuje komputera i nie oznacza automatycznie, że dane zostały skradzione. Informuje przede wszystkim o problemie serwerowym.

Ostrożność jest jednak potrzebna, gdy po błędzie użytkownik otrzymuje wiadomość nakłaniającą do:

  • ponownego podania hasła,
  • pobrania programu naprawczego,
  • instalacji certyfikatu,
  • kontaktu z fałszywym wsparciem,
  • dokonania dodatkowej płatności.

Prawdziwy błąd 502 nie wymaga instalowania żadnego programu w przeglądarce.

Diagnostyka krok po kroku

Uporządkowany proces może wyglądać następująco:

  1. odtwórz błąd,
  2. zapisz dokładny czas i adres,
  3. sprawdź nagłówki oraz stronę błędu,
  4. ustal warstwę generującą 502,
  5. przeanalizuj logi proxy,
  6. przetestuj upstream bezpośrednio,
  7. sprawdź proces, port i socket,
  8. zweryfikuj DNS oraz firewall,
  9. sprawdź TLS,
  10. przeanalizuj zasoby,
  11. sprawdź ostatnie wdrożenia,
  12. przywróć usługę,
  13. wykonaj analizę przyczyny źródłowej,
  14. wprowadź zabezpieczenie przed powtórką.

Taki proces jest skuteczniejszy niż losowe zwiększanie limitów albo wielokrotne restartowanie wszystkich usług.

Checklista HTTPS 502 dla administratora

Podczas awarii warto szybko zweryfikować:

  • czy problem dotyczy wszystkich użytkowników,
  • czy CDN działa,
  • czy origin odpowiada,
  • czy aplikacja działa,
  • czy właściwy port jest otwarty,
  • czy socket istnieje,
  • czy ostatnie wdrożenie się powiodło,
  • czy certyfikat jest ważny,
  • czy DNS wskazuje właściwy adres,
  • czy firewall nie blokuje połączeń,
  • czy serwer ma wolną pamięć i miejsce,
  • czy baza danych odpowiada,
  • czy zewnętrzne API działa,
  • czy logi wskazują konkretny błąd.

Lista nie zastępuje analizy, ale pomaga nie pominąć podstawowych obszarów.

HTTPS 502 w architekturze mikroserwisowej

W systemie mikroserwisowym jedno żądanie może przejść przez kilka usług. Każda z nich może posiadać własne proxy, timeouty i zależności.

Przykład:

Gateway → usługa zamówień → usługa płatności → zewnętrzny operator

Jeżeli usługa płatności zwróci nieprawidłową odpowiedź, gateway może ostatecznie zwrócić 502 użytkownikowi.

Potrzebne są wtedy:

  • identyfikatory śledzenia,
  • distributed tracing,
  • jednoznaczna obsługa błędów,
  • limity czasu,
  • circuit breaker,
  • kontrolowane ponawianie,
  • idempotencja.

Bez tych mechanizmów ustalenie źródła awarii może być bardzo trudne.

HTTPS 502 w API

W API kod 502 powinien być traktowany jako błąd infrastrukturalny albo błąd zależności upstream.

Klient API może zastosować ponowienie żądania, ale tylko pod określonymi warunkami.

Bezpieczniejsze do ponawiania są zwykle operacje odczytu. Ponowienie operacji tworzącej płatność lub zamówienie wymaga mechanizmu idempotency key.

Ślepe ponawianie może wywołać:

  • duplikaty,
  • przeciążenie,
  • efekt lawiny,
  • wielokrotne płatności.

Analiza przyczyny źródłowej

Po naprawieniu awarii należy odpowiedzieć nie tylko na pytanie „co przestało działać”, ale również „dlaczego system nie poradził sobie z tym problemem”.

Przykład:

  • bezpośrednia przyczyna: proces aplikacji został zakończony,
  • głębsza przyczyna: aplikacja przekroczyła pamięć,
  • przyczyna organizacyjna: brak monitoringu wycieku pamięci,
  • przyczyna wpływu: działała tylko jedna instancja,
  • przyczyna długiej awarii: brak automatycznego restartu.

Dobra analiza prowadzi do konkretnych działań, a nie do szukania winnej osoby.

Najczęstsze błędy podczas naprawy 502

Zwiększanie wszystkich timeoutów

Może jedynie przesunąć problem i zwiększyć obciążenie.

Wyłączanie weryfikacji TLS

Pozwala czasem ominąć problem certyfikatu, ale obniża bezpieczeństwo i nie rozwiązuje źródła błędu.

Restart bez analizy logów

Restart może usunąć dowody potrzebne do ustalenia przyczyny.

Zmiana wielu elementów jednocześnie

Jeżeli administrator jednocześnie zmieni DNS, firewall, timeout i certyfikat, trudno ustalić, co rzeczywiście zadziałało.

Testowanie wyłącznie strony głównej

Strona główna może być przechowywana w cache, podczas gdy API i proces zakupowy nadal nie działają.

Ignorowanie operacji częściowo wykonanych

Błąd odpowiedzi nie oznacza, że backend nie wykonał operacji. Dotyczy to szczególnie płatności i zamówień.

HTTPS 502 jako sygnał problemu między serwerami

Najważniejszą informacją wynikającą z kodu HTTPS 502 jest to, że błąd najczęściej występuje w komunikacji pomiędzy warstwami systemu. Przeglądarka zdołała skontaktować się z serwerem pośredniczącym, ale ten nie otrzymał poprawnej odpowiedzi od kolejnej usługi.

Dla użytkownika najlepszym rozwiązaniem jest zwykle ponowienie próby po krótkim czasie, sprawdzenie oficjalnego statusu oraz ostrożność przy płatnościach. Lokalne czyszczenie przeglądarki może pomóc jedynie w ograniczonej liczbie przypadków.

Dla administratora kod 502 oznacza konieczność sprawdzenia całej ścieżki żądania: od CDN i load balancera, przez reverse proxy, aż po aplikację, bazę danych i zewnętrzne usługi. Szczególną uwagę należy poświęcić logom, stanowi procesów, portom, socketom, DNS, firewallom oraz konfiguracji TLS.

Błąd 502 można szybko usunąć przez restart usługi, ale trwałe rozwiązanie wymaga poznania przyczyny. Monitoring, poprawne health checki, wiele instancji aplikacji, bezpieczne wdrożenia i dobrze zaprojektowana obserwowalność znacząco ograniczają ryzyko ponownego wystąpienia problemu.

HTTPS 502 Bad Gateway nie jest więc pojedynczą awarią o jednej przyczynie, lecz technicznym sygnałem, że jeden serwer nie potrafił prawidłowo porozumieć się z drugim. Zrozumienie architektury i systematyczna diagnostyka pozwalają ustalić miejsce błędu, sprawnie przywrócić usługę oraz poprawić odporność całego systemu.

Powiązane artykuły

Opublikuj komentarz