Błąd http 400 to jeden z tych komunikatów, które wyglądają niegroźnie, ale potrafią zatrzymać formularz, logowanie albo integrację API w najmniej wygodnym momencie. W praktyce najczęściej chodzi o źle zbudowane żądanie, a nie o „zepsuty serwer”, więc warto wiedzieć, gdzie szukać przyczyny i jak ją odróżnić od innych kodów HTTP. Poniżej rozkładam temat na czynniki pierwsze: od znaczenia statusu, przez typowe źródła problemu, aż po sytuacje związane z domeną, hostingiem i reverse proxy.
Najważniejsze informacje o błędzie 400
- 400 oznacza błąd po stronie żądania, czyli problem z tym, co klient wysyła do serwera.
- Najczęstsze przyczyny to niepoprawny JSON, błędne nagłówki, zbyt duże cookies, źle zakodowany adres i konflikty z przekierowaniami.
- Po zmianie domeny 400 często wynika nie z DNS, lecz z konfiguracji hosta, ciasteczek lub warstwy pośredniej.
- Do diagnozy najlepiej użyć karty Network w przeglądarce, logów serwera oraz testu z
curl -v. - Naprawa zależy od tego, czy problem występuje po stronie użytkownika, frontendu, API czy infrastruktury.
Co oznacza kod 400 i kiedy pojawia się naprawdę
Jeśli trzymać się specyfikacji, kod 400 należy do klasy 4xx, czyli błędów klienta. Jak opisuje MDN, serwer odrzuca takie żądanie, gdy widzi w nim problem po stronie klienta; RFC 9110 doprecyzowuje, że chodzi między innymi o wadliwą składnię, niepoprawne formatowanie wiadomości albo błędne routowanie. To ważne rozróżnienie, bo 400 nie mówi jeszcze, że aplikacja padła. Mówi raczej: „to żądanie w tej formie nie nadaje się do obsługi”.
W praktyce po 400 zwykłe odświeżenie strony rzadko pomaga. Trzeba poprawić samo żądanie: treść formularza, nagłówki, adres, parametry URL albo konfigurację pośredników między przeglądarką a backendem. Ja właśnie od tego zaczynam diagnostykę, bo ten kod bardzo szybko zawęża pole poszukiwań do requestu, a nie całej usługi. To prowadzi do pytania, co najczęściej psuje samo żądanie.
Co najczęściej psuje żądanie
Najwięcej problemów widzę wtedy, gdy dane są technicznie wysyłane poprawnie, ale nie pasują do tego, czego oczekuje endpoint. Serwer nie musi wtedy „zgadywać” intencji użytkownika i często po prostu kończy rozmowę kodem 400.
Niepoprawne dane w body
To klasyk w API i formularzach. Wystarczy jeden przecinek w złym miejscu, niedomknięty nawias, nieescapedowany znak nowej linii albo błędny format daty, żeby backend uznał payload za wadliwy. Dotyczy to szczególnie JSON-a, ale także XML-a, danych multipart/form-data i uploadu plików. Jeśli body nie przechodzi walidacji, serwer nie ma czego przetwarzać.
Za ciężkie nagłówki i ciasteczka
Jeśli aplikacja długo działa pod tą samą domeną, nagłówki potrafią urosnąć bardziej, niż się wydaje. Stare sesje, ciasteczka po migracji, tokeny i dodatkowe dane zapisywane przez rozszerzenia przeglądarki zwiększają rozmiar requestu. Czasem jeden za duży nagłówek albo niezgodny Content-Type wystarczy, żeby pośrednik albo serwer zwrócił 400. To szczególnie częste po logowaniu i po długiej pracy na tej samej karcie.
Adres, parametry i kodowanie znaków
Błąd pojawia się także wtedy, gdy URL jest źle zakodowany. Spacje, polskie znaki, podwójne kodowanie znaków specjalnych, niepoprawne znaki w query stringu albo źle złożona ścieżka potrafią zepsuć całe żądanie. W praktyce najbardziej zdradliwe są formularze wysyłające dane do adresu, który wygląda poprawnie wizualnie, ale po stronie protokołu zawiera nieprawidłowe sekwencje.
Warstwa pośrednia między klientem a serwerem
Reverse proxy, CDN i WAF to świetne elementy architektury, ale potrafią też zablokować lub zmodyfikować request jeszcze przed backendem. WAF, czyli web application firewall, filtruje ruch pod kątem reguł bezpieczeństwa. Proxy z kolei może zmieniać nagłówki, limitować ich rozmiar albo odrzucać żądania, które nie pasują do konfiguracji. Jeśli 400 pojawia się tylko z jednej sieci, jednej przeglądarki albo jednego regionu, właśnie tam szukałbym pierwszego tropu.
W tym miejscu już widać, że sam status mówi niewiele bez kontekstu. Najwięcej nieporozumień pojawia się wtedy, gdy do gry wchodzi domena, przekierowania i stara konfiguracja hosta.
Dlaczego błąd 400 często wychodzi po zmianie domeny
Przy zmianie domeny 400 bywa podstępny, bo DNS może działać idealnie, a mimo to backend nadal odrzuca ruch. DNS odpowiada za to, gdzie kieruje nazwa domenowa, ale ostatecznie serwer patrzy też na nagłówek Host, ciasteczka, certyfikat, reguły proxy i trasę przekierowań. Jeżeli któryś z tych elementów się nie zgadza, użytkownik zobaczy właśnie kod 400, nawet jeśli sama domena „otwiera się” poprawnie.
| Sytuacja po stronie domeny | Co się dzieje | Co sprawdzić najpierw |
|---|---|---|
| Przeniesienie serwisu na nowy adres | Stare cookies i sesje nadal są wysyłane, przez co nagłówki rosną albo stają się nieaktualne | Wyczyść cookies dla domeny, sprawdź zakres ciasteczek i działanie logowania |
| Inny host niż ten, którego oczekuje serwer | Reverse proxy albo aplikacja nie rozpoznają nazwy hosta i odrzucają request | Konfigurację server_name, reguły hostingu i mapowanie domeny |
| Przekierowania www, non-www, http i https | Pojawia się pętla albo nieprawidłowy łańcuch przekierowań | Jeden kanoniczny adres, poprawne 301 i spójne ustawienie HTTPS |
| CDN lub WAF przed aplikacją | Warstwa bezpieczeństwa filtruje nietypowy format żądania | Logi edge, reguły bezpieczeństwa i limitowanie nagłówków |
Po migracji domeny błąd często ujawnia się nie na stronie głównej, tylko przy formularzu kontaktowym, koszyku albo panelu logowania. To właśnie tam wychodzą na wierzch stare tokeny CSRF, ciasteczka przypięte do poprzedniego hosta i niezgodność między tym, co wysyła przeglądarka, a tym, czego oczekuje backend. Jeśli 400 pojawia się po zmianie adresu, DNS jest zwykle najmniejszym problemem. Następny krok to dokładna diagnostyka requestu.
Jak zdiagnozować problem krok po kroku
Ja zwykle zaczynam od DevTools, bo odpowiedź serwera jest mniej cenna niż sam request. Najpierw trzeba ustalić, czy 400 dotyczy całej witryny, jednego endpointu, jednego formularza, czy tylko konkretnej przeglądarki. Potem sprawdzam, co naprawdę wyszło z klienta.
- Otwórz kartę Network i znajdź żądanie, które zakończyło się 400.
- Porównaj Request Headers i Request Payload z tym, czego oczekuje endpoint.
- Sprawdź, czy
Content-Typepasuje do formatu danych, które wysyłasz. - Zobacz odpowiedź serwera. Czasem body zwrotne zawiera komunikat, który od razu wskazuje źródło problemu.
- Uruchom ten sam request przez
curl -v, żeby zobaczyć surowe nagłówki i payload bez wpływu przeglądarki. - Przejrzyj logi backendu, reverse proxy i CDN, bo błąd może powstać zanim żądanie dotrze do aplikacji.
Jeśli problem występuje tylko po zalogowaniu, podejrzewam ciasteczka albo token sesyjny. Jeśli tylko na jednym urządzeniu, patrzę na cache, rozszerzenia i lokalne dane przeglądarki. Jeśli tylko po wdrożeniu albo zmianie domeny, sprawdzam przekierowania, hosty i reguły pośredników. Im szybciej odtworzysz warunki błędu, tym szybciej odfiltrujesz przypadkowe tropy. Kiedy wiadomo już, gdzie request się psuje, naprawa zależy od tego, po której stronie leży odpowiedzialność.
Jak naprawić błąd z perspektywy użytkownika i właściciela strony
Tu warto rozdzielić dwie perspektywy, bo użytkownik i właściciel systemu mają zupełnie inne ruchy naprawcze. Dla jednej strony wystarczy wyczyścić lokalny stan przeglądarki, dla drugiej trzeba poprawić walidację, routing albo konfigurację domen.
Gdy problem ma użytkownik
- Odśwież formularz i spróbuj wysłać go ponownie w nowej karcie.
- Wyczyść cookies i cache dla konkretnej domeny, zwłaszcza po migracji lub problemach z logowaniem.
- Przetestuj tryb prywatny, żeby odciąć wpływ starych danych sesyjnych.
- Sprawdź, czy adres nie zawiera spacji, błędnych znaków albo nieprawidłowego kodowania.
- Na chwilę wyłącz rozszerzenia, które modyfikują ruch sieciowy, na przykład blokery treści lub proxy.
Przeczytaj również: Błąd 503 - Domena nie winna! Napraw i chroń SEO
Gdy problem ma właściciel strony lub API
- Waliduj dane wejściowe jak najbliżej źródła i zwracaj precyzyjny komunikat, co jest nie tak.
- Loguj surowe żądanie, identyfikator
request-idi odpowiedź pośredników. - Sprawdź limity nagłówków, rozmiar ciasteczek i ustawienia body w proxy oraz serwerze aplikacyjnym.
- Ujednolić domenę kanoniczną i uprość przekierowania, żeby nie tworzyć zbędnych pętli.
- Dodaj testy dla błędnych danych, nie tylko dla ścieżek „happy path”.
W praktyce największą różnicę robi nie „większy limit”, lecz lepszy kontrakt między klientem a serwerem. Jeśli API jasno mówi, czego oczekuje, 400 staje się kontrolowanym sygnałem walidacji, a nie tajemniczym błędem produkcyjnym. To naturalnie prowadzi do pytania, jak nie pomylić go z innymi kodami, które wyglądają podobnie.
Czym 400 różni się od 401, 403 i 404
Na pierwszy rzut oka te kody łatwo wrzucić do jednego worka, ale każdy z nich oznacza inny rodzaj problemu. W diagnostyce to ważne, bo inna jest odpowiedź, jeśli żądanie jest źle zbudowane, a inna, jeśli użytkownik nie ma dostępu albo zasób po prostu nie istnieje.
| Kod | Co oznacza | Najczęstszy kontekst | Czy wystarczy poprawić żądanie |
|---|---|---|---|
| 400 | Żądanie jest błędne lub nie do przetworzenia | Niepoprawny JSON, nagłówki, URL, cookies, routing | Tak, ale trzeba zmienić sam request |
| 401 | Brak poprawnego uwierzytelnienia | Brak tokenu, wygasła sesja, nieprawidłowe dane logowania | Nie zawsze, zwykle trzeba się uwierzytelnić |
| 403 | Dostęp jest zabroniony | Użytkownik jest rozpoznany, ale nie ma uprawnień | Raczej nie, potrzebne są inne uprawnienia |
| 404 | Zasób nie został znaleziony | Nie istnieje ścieżka, plik albo endpoint | Nie, trzeba poprawić adres lub routing |
W API można jeszcze spotkać 422, czyli sytuację, w której dane są składniowo poprawne, ale semantycznie nie pasują do reguł biznesowych. To już inny poziom błędu niż 400, ale w codziennej pracy te dwa kody bywają mylone, bo oba mówią: „request nie przejdzie w tej postaci”. Gdy kody są już rozróżnione, zostaje najważniejsze: jak zmniejszyć ryzyko, że problem wróci po kolejnym wdrożeniu.
Co zrobić, żeby ten błąd nie wracał po wdrożeniu
Najlepiej działa połączenie trzech rzeczy: walidacji danych, porządku w domenach i sensownych logów. Ja traktuję 400 jako sygnał, że kontrakt między klientem a serwerem jest zbyt słabo opisany albo zbyt łatwo go złamać. Jeśli poprawisz tylko jeden element, problem może wrócić przy następnym release albo po kolejnej zmianie adresu.
- Waliduj payload na poziomie backendu i frontendu, żeby błędy wychwytywać wcześnie.
- Testuj nie tylko poprawne dane, ale też przypadki skrajne: puste pola, zły format, za długie wartości i nietypowe znaki.
- Utrzymuj jedną, spójną domenę kanoniczną i pilnuj przekierowań po migracjach.
- Monitoruj wzrost liczby odpowiedzi 4xx po wdrożeniach, bo to szybki sygnał regresji.
- Dodaj czytelne komunikaty błędów, żeby użytkownik nie musiał zgadywać, co poprawić.
Jeśli miałbym wskazać jeden praktyczny nawyk, zacząłbym od porównania realnego requestu z tym, czego oczekuje endpoint, bo właśnie tam najczęściej kryje się źródło problemu. Przy 400 mniej liczy się sam komunikat, a bardziej to, czy wiesz, który element żądania jest niezgodny z kontraktem aplikacji. Gdy ten kontrakt jest dobrze opisany, błąd staje się łatwy do naprawienia, a nie do zgadywania.
