Filtruj błędy nginx po kodzie statusu lub wpisie z logu i poznaj prawdopodobną przyczynę oraz zmianę konfiguracji, która ją naprawia. Obejmuje 502, 504, 403, 404 i 413.
Nginx zwraca 502 Bad Gateway, gdy działa jako proxy, a aplikacja za nim nie daje poprawnej odpowiedzi: aplikacja nie działa, nasłuchuje na innym porcie lub sockecie albo padła w trakcie odpowiedzi. Uruchom aplikację, ustaw proxy_pass na adres, na którym naprawdę nasłuchuje, a potem sprawdź w logu błędów nginx dokładny powód.
Na co wskazuje który błąd nginx
Wybierz kod statusu, który widzisz, albo wpisz słowo z logu błędów, a wyszukiwarka zawęzi listę do pasujących przyczyn. Każda karta podaje przyczynę, sposób jej potwierdzenia i fragment konfiguracji do dostosowania. Dopóki nie filtrujesz, widoczne są wszystkie karty.
Jako odwiedzający niczym go nie powodujesz. Proxy sięgnęło do aplikacji za sobą i nie dostało poprawnej odpowiedzi. Jako właściciel strony odpowiadasz za aplikację lub ustawienia proxy, więc zacznij od sprawdzenia, czy proces upstream działa.
502 oznacza, że upstream odpowiedział nieprawidłowo lub odrzucił połączenie. 504 oznacza, że nginx czekał i nic nie dotarło na czas. Pierwszy wskazuje na zatrzymaną lub padającą aplikację, drugi na powolne przetwarzanie lub zbyt niski timeout.
Ustaw client_max_body_size w bloku http, server lub location, na przykład client_max_body_size 20m;. Domyślna wartość to 1m. Wartość 0 wyłącza sprawdzanie rozmiaru, czego na publicznej stronie rzadko chcesz.
Gdy URL kończy się ukośnikiem, nginx szuka pliku index, takiego jak index.html. Jeśli go nie ma, a autoindex jest wyłączony, co jest ustawieniem domyślnym, nie ma niczego, co mógłby serwować. Dodaj plik index albo przekieruj żądanie za pomocą try_files.
Jego lokalizację ustawia dyrektywa error_log w Twojej konfiguracji. Przeszukaj nginx.conf i dołączone pliki pod kątem error_log, bo pakiety i kontenery umieszczają go w różnych miejscach.
Punkt wyjścia dla aplikacji na porcie 3000. Przekazuje oryginalny host i schemat, ustawia jawne timeouty i zostawia miejsce na większe nagłówki.
Przetestuj poleceniem nginx -t, potem przeładuj. Dostosuj port i limity do swojej aplikacji.
Aplikacja za nginx nie działa, więc połączenie jest odrzucane.
Wywołaj curl na adres z proxy_pass z maszyny z nginx. Odrzucone połączenie to potwierdza.
Uruchom aplikację pod menedżerem procesów, który restartuje ją po awarii.
proxy_pass wskazuje port lub socket, na którym aplikacja nie nasłuchuje.
Porównaj adres w proxy_pass z tym, który aplikacja wypisuje przy starcie.
Ustaw oba dokładnie tak samo, łącznie z częścią hosta.
Aplikacja wysyła nagłówki odpowiedzi większe niż bufor, do którego nginx je wczytuje, na przykład z powodu wielu ciasteczek.
Poszukaj w logu linii mówiącej, że nagłówek jest za duży.
Podnieś proxy_buffer_size dla tej lokalizacji. Domyślnie to jedna strona pamięci, 4k lub 8k.
Aplikacja potrzebowała między dwoma odczytami więcej czasu niż proxy_read_timeout, domyślnie 60 sekund.
Zmierz czas tego samego żądania wysłanego bezpośrednio do aplikacji przez curl.
Przyspiesz endpoint lub przenieś pracę do zadania w tle. Timeout podnieś tylko dla tej lokalizacji.
Nginx nie zdołał nawet otworzyć połączenia w czasie proxy_connect_timeout, domyślnie 60 sekund.
Sprawdź, czy nie blokuje firewall albo czy host jest osiągalny z proxy.
Napraw ścieżkę sieciową. Dokumentacja nginx zaznacza, że ten timeout zwykle nie może przekroczyć 75 sekund, więc jego podnoszenie nie pomaga.
URL kończący się ukośnikiem nie ma pliku index, a autoindex jest wyłączony.
Wylistuj folder, na który wskazuje root, i poszukaj index.html.
Dodaj plik index albo przekaż żądanie do aplikacji za pomocą try_files.
Użytkownik workera nginx nie może odczytać pliku ani wejść do któregoś z folderów nad nim.
Poszukaj w logu błędów linii permission denied z nazwą ścieżki.
Daj użytkownikowi workera prawo odczytu plików i prawo wykonania dla każdego folderu nadrzędnego.
Do odwiedzającego pasowała reguła allow lub deny. Reguły są sprawdzane po kolei i wygrywa pierwsze dopasowanie.
Przeczytaj od góry do dołu każdą linię allow i deny, która dotyczy tej lokalizacji.
Zmień kolejność reguł tak, aby konkretne allow było przed ogólnym deny all.
Użyto root tam, gdzie miał być alias, więc nginx dodaje prefiks lokalizacji do ścieżki dwa razy.
Ustal ścieżkę pliku: root dokleja cały URI, alias zastępuje dopasowany prefiks.
Użyj alias, z ukośnikiem na końcu po obu stronach, gdy nazwa folderu różni się od URL.
Trasa aplikacji single page, na przykład /dashboard, nie ma pliku na dysku.
Strona główna się ładuje, ale odświeżenie dowolnej wewnętrznej trasy kończy się błędem.
Ustaw fallback na index.html przez try_files, aby ścieżką zajął się router aplikacji.
Treść żądania jest większa niż client_max_body_size, domyślnie 1m.
Przesyłanie plików poniżej megabajta działa, a większych kończy się błędem.
Podnieś limit tylko dla lokalizacji obsługującej przesyłanie.
Kod statusu
Wszystkie kody
Słowa z Twojego logu błędów
na przykład: refused, timed out, denied
Sprawdź
Rozwiązanie
Pasujące przyczyny: {n}
Żadna przyczyna nie pasuje. Wyczyść wyszukiwanie lub wybierz inny kod.
Zacznij za darmo · Bez karty kredytowej