Błąd 400 Bad Request: co oznacza i jak naprawić

Czym jest błąd 400 Bad Request?

400 Bad Request to kod statusu HTTP, który oznacza, że serwer otrzymał Twoje żądanie, ale nie przetworzy go, bo coś w samym żądaniu wygląda na nieprawidłowe. Standard HTTP (RFC 9110, sekcja 15.5.1) definiuje go jako sytuację, w której serwer nie może lub nie chce przetworzyć żądania „z powodu czegoś, co jest postrzegane jako błąd klienta”, na przykład błędnej składni, nieprawidłowej struktury wiadomości lub zwodniczego kierowania żądania.

W przeciwieństwie do błędu 500, który oznacza awarię serwera, kod 400 wskazuje na żądanie: adres URL, nagłówki, pliki cookie lub dane wysłane przez przeglądarkę albo aplikację. Dla wszystkich pozostałych strona zwykle działa normalnie.

To dobra wiadomość dla odwiedzających, bo rozwiązanie zwykle leży po Twojej stronie i zajmuje minutę: za większością błędów 400 stoi źle wpisany link albo uszkodzony plik cookie.

Jak wygląda błąd 400

Treść komunikatu zależy od oprogramowania serwera, a dodatkowy tekst jest często najlepszą wskazówką co do przyczyny:

Co powoduje błąd 400 Bad Request?

• Nieprawidłowy adres URL. Przypadkowy znak %, spacja, znak, który powinien zostać zakodowany, albo link ucięty lub wklejony dwa razy.

• Uszkodzone lub zbyt duże pliki cookie. Strony, które ustawiają wiele plików cookie (logowanie, testy A/B, analityka), mogą wypchnąć nagłówek Cookie ponad limit serwera. Plik cookie uszkodzony podczas aktualizacji również może zostać odrzucony.

• Zbyt duże nagłówki żądania. Poza plikami cookie sumują się też długie tokeny uwierzytelniające oraz nagłówki dodawane przez rozszerzenia i proxy.

• Nieprawidłowe dane wysłane do API. Brak wymaganych pól, błędny JSON albo niewłaściwy nagłówek Content-Type.

• Zwykłe HTTP wysłane na port HTTPS. Częste za load balancerami i reverse proxy.

• Zbyt duży plik. Wiele serwerów odpowiada wtedy kodem 413 Content Too Large, ale niektóre aplikacje i frameworki zwracają zamiast tego 400.

Rozwiązanie 1: Sprawdź adres URL

Przyjrzyj się dokładnie paskowi adresu. Na co zwrócić uwagę:

• Znak %, po którym nie następują dwa znaki szesnastkowe (%20 jest w porządku, %2 lub %zz już nie).

• Spacje, { }, |, \ lub inne nietypowe znaki, zwłaszcza w linkach skopiowanych z e-maili, plików PDF lub komunikatorów.

• Link wklejony dwa razy (https://example.com/https://example.com/...) albo ucięty w połowie.

• Bardzo długi adres URL z parametrami śledzącymi. Usuń wszystko od znaku ? do końca i spróbuj ponownie.

Jeśli trafiłeś tu z linku na innej stronie, wejdź na stronę główną witryny i przejdź do tej podstrony stamtąd.

Rozwiązanie 2: Wyczyść pliki cookie tej jednej strony

To rozwiązuje większość błędów 400 na stronach, z których już wcześniej korzystałeś, zwłaszcza gdy komunikat wspomina o plikach cookie lub nagłówkach, które są „zbyt duże” (too large) lub „zbyt długie” (too long). Nie musisz czyścić plików cookie wszystkich stron, wystarczy ta jedna:

• Chrome / Edge: kliknij ikonę po lewej stronie paska adresu → Pliki cookie i dane witryn (lub Ustawienia witryny) → usuń dane tej strony, a potem odśwież.

• Firefox: kliknij kłódkę → Wyczyść ciasteczka i dane witryny… (Clear cookies and site data…)

• Safari (Mac): Safari → Ustawienia → Prywatność → Zarządzaj danymi witryn… → wyszukaj stronę → Usuń.

• iPhone: Ustawienia → Aplikacje → Safari → Zaawansowane → Dane witryn → przesuń palcem w lewo na stronie, aby ją usunąć.

Rozwiązanie 3: Spróbuj trybu incognito, a potem wyczyść pamięć podręczną

Otwórz stronę w oknie incognito/prywatnym (Ctrl + Shift + N w Chrome i Edge, Ctrl + Shift + P w Firefoksie, Cmd + Shift + N w Safari). Okna prywatne startują bez plików cookie i bez rozszerzeń, więc jeśli strona w nich działa, Rozwiązanie 2 lub Rozwiązanie 4 naprawi problem na stałe.

Jeśli tryb incognito też nie pomaga, wyczyść pamięć podręczną przeglądarki (Ctrl + Shift + Delete → Obrazy i pliki zapisane w pamięci podręcznej), a na koniec wyczyść pamięć podręczną DNS. DNS rzadko jest przyczyną błędu 400, ale po przeniesieniu strony na inny serwer nieaktualny adres może skierować Cię na serwer, który odrzuca Twoje żądanie.

Rozwiązanie 4: Wyłącz rozszerzenia i sprawdź rozmiar plików

Rozszerzenia, które modyfikują żądania, takie jak narzędzia do ochrony prywatności, edytory nagłówków, wyszukiwarki kuponów i niektóre blokery reklam, mogą dodawać lub zmieniać nagłówki w sposób, który serwer odrzuca. Wyłącz je wszystkie, odśwież stronę, a potem włączaj je po kolei, aby znaleźć winowajcę.

Jeśli błąd pojawia się przy przesyłaniu pliku, spróbuj mniejszego pliku. Skompresuj obrazy albo podziel duże pliki. W ten sposób sprawdzisz, czy serwer odrzuca rozmiar, nawet jeśli zgłasza to jako 400 zamiast 413.

Dla właścicieli stron: jak znaleźć przyczynę błędów 400

Jeśli użytkownicy zgłaszają błędy 400 na Twojej stronie, zacznij od dokładnej treści komunikatu, który widzą, i od logów serwera. nginx i Apache zapisują przyczynę na poziomie info, więc jeśli jej nie widzisz, tymczasowo podnieś poziom logowania błędów, a log dostępu pokaże, które adresy URL zwracają 400. Narzędzie HTTP Headers od DNS Robot pokazuje kod statusu, oprogramowanie serwera i każdy nagłówek Set-Cookie wysyłany przez stronę, co pomaga wychwycić pliki cookie, które ciągle rosną.

# Które żądania dostają 400? (format logu nginx combined)
sudo awk '$9 == 400 {print $7}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head

# Przyczyny zapisane przez nginx (wymaga error_log ... info;)
sudo grep -i "client sent\|too large\|bad request" /var/log/nginx/error.log | tail -20

Błąd „Request Header Or Cookie Too Large”

nginx wczytuje nagłówki żądania do buforów ustawianych dyrektywą large_client_header_buffers, domyślnie 4 bufory po 8 KB. Pojedyncza linia nagłówka, zwykle nagłówek Cookie, która nie mieści się w jednym buforze, wywołuje ten błąd 400. Odpowiednikiem w Apache jest limit LimitRequestFieldSize, domyślnie 8190 bajtów.

Właściwe rozwiązanie to wysyłać mniej: usuń niepotrzebne już pliki cookie, utrzymuj małe ciasteczka sesyjne i ograniczaj zasięg plików cookie do ścieżek i subdomen, które z nich korzystają. Jeśli naprawdę potrzebujesz większych nagłówków, na przykład dla dużych tokenów single sign-on, podnieś limit:

# nginx (blok http lub server)
large_client_header_buffers 4 16k;

# Odpowiednik w Apache (httpd.conf / vhost)
# LimitRequestFieldSize 16380

Błąd „The plain HTTP request was sent to HTTPS port”

nginx zwraca ten błąd 400, gdy coś wysyła zwykłe HTTP na port, na którym nginx oczekuje TLS, zwykle 443. Typowe przyczyny to load balancer lub proxy przekazujące ruch http:// na port 443, link w postaci http://example.com:443 albo stare ustawienie ssl on;, przez które port oczekuje TLS, choć nie powinien.

Upewnij się, że każda linia listen pasuje do tego, co na nią trafia: listen 443 ssl; dla HTTPS i listen 80; dla zwykłego HTTP, z przekierowaniem z portu 80 na 443. Sprawdź też, czy proxy przed serwerem łączy się po HTTPS z portem 443 (albo po HTTP z portem 80).

Błędy 400 zwracane przez API

API zwracają 400 dla żądań, które nie przeszły walidacji. Jeśli wywołujesz API, przeczytaj treść odpowiedzi, bo większość API wyjaśnia, które pole jest błędne. Następnie sprawdź, czy wysyłasz poprawny JSON, właściwy nagłówek Content-Type: application/json i wszystkie wymagane parametry.

Jeśli budujesz API, zwracaj treść odpowiedzi, która nazywa problem (na przykład {"error": "email is required"}), i rozważ kod 422 Unprocessable Content dla żądań poprawnie zbudowanych, ale błędnych merytorycznie, zostawiając 400 dla żądań, których w ogóle nie da się sparsować.

400 a 401, 403, 404, 413, 429 i 431

Nasze poradniki o pokrewnych błędach: 403 Forbidden, 401 Unauthorized i 429 Too Many Requests. Przy przekierowaniach, które się zapętlają, zamiast kończyć błędem, zobacz ERR_TOO_MANY_REDIRECTS, a Redirect Checker pokaże każdy przeskok.