Co to jest błąd 400 Bad Request i jak go naprawić?

Błąd 400 Bad Request to kod statusu HTTP/1.1 zdefiniowany w RFC 9110, który sygnalizuje, że serwer otrzymał żądanie, którego nie może lub nie chce przetworzyć, ponieważ jest ono nieprawidłowo sformułowane. W przeciwieństwie do błędów 5xx, które pochodzą po stronie serwera, błąd 400 wskazuje na winę po stronie klienta — oznacza to, że problem leży w wysyłanym żądaniu, a nie w zdolności serwera do odpowiedzi.

W praktyce błąd 400 pojawia się zanim serwer w ogóle podejmie próbę realizacji żądania. Serwer analizuje przychodzącą wiadomość HTTP, wykrywa coś strukturalnie lub semantycznie nieprawidłowego — uszkodzony nagłówek, nieprawidłowy URI, zbyt duży ładunek, błędne ciasteczko — i natychmiast zwraca 400 Bad Request zamiast kontynuować. Znajomość tej różnicy to najszybsza droga do prawidłowej diagnozy.

Co kod statusu 400 faktycznie oznacza na poziomie protokołu

HTTP działa na zasadzie ścisłej umowy żądanie-odpowiedź. Każde żądanie musi być zgodne z gramatyką zdefiniowaną w specyfikacji HTTP. Gdy klient wysyła wiadomość naruszającą tę gramatykę, serwer ma zarówno prawo, jak i obowiązek odrzucić ją odpowiedzią 400.

Serwer nie rejestruje błędu 400 jako własnej awarii. Rejestruje go jako odrzucone żądanie klienta. Dlatego ślepe restartowanie serwera lub czyszczenie pamięci podręcznej CDN rzadko naprawia prawdziwy błąd 400 — przyczyna źródłowa niemal zawsze leży w konstrukcji żądania.

Typowe warianty tego błędu wyświetlane przez przeglądarki to:

• 400 Bad Request
• HTTP Error 400
• Bad Request — Invalid URL
• 400. That's an error. Your client has issued a malformed or illegal request.
• 400 Bad Request. The server cannot or will not process the request due to something that is perceived to be a client error.

Wszystkie te warianty odnoszą się do tego samego bazowego kodu statusu HTTP. Różnice w sformułowaniach wynikają z oprogramowania serwera (Apache, Nginx, IIS, Cloudflare) i frameworka aplikacji.

Przyczyny błędu 400 Bad Request

Zrozumienie dokładnego źródła problemu jest niezbędne przed podjęciem jakichkolwiek działań naprawczych. Przyczyny dzielą się na dwie kategorie: po stronie klienta i błędna konfiguracja po stronie serwera.

Przyczyny po stronie klienta

Nieprawidłowo sformułowany lub błędnie zakodowany URL

URL zawierający niezakodowane spacje, niedozwolone znaki lub uszkodzone sekwencje kodowania procentowego zostanie natychmiast odrzucony. Specyfikacja HTTP wymaga, aby wszystkie znaki spoza zestawu niezarezerwowanego (A–Z, a–z, 0–9, -, _, ., ~) były kodowane procentowo przed transmisją.

Uszkodzone lub zbyt duże ciasteczka

Ciasteczka są przesyłane w nagłówku żądania Cookie. Jeśli wartość ciasteczka jest nieprawidłowa, przekracza limit rozmiaru pojedynczego ciasteczka w przeglądarce (zazwyczaj 4096 bajtów) lub zawiera znaki naruszające RFC 6265, serwer może odrzucić całe żądanie. Jest to jedna z najczęściej pomijanych przyczyn sporadycznych błędów 400 na stronach, które użytkownik wcześniej odwiedzał bez problemów.

Nieprawidłowe lub brakujące wymagane nagłówki żądania

Niektóre API i aplikacje internetowe wymuszają ścisłą walidację nagłówków. Brakujący Content-Type w żądaniu POST, nieprawidłowo sformułowany nagłówek Authorization lub nagłówek Accept z nieobsługiwanym typem mediów mogą wywołać błąd 400.

Zbyt duży ładunek żądania

Serwery internetowe i odwrotne serwery proxy wymuszają maksymalne limity rozmiaru treści. Nginx używa client_max_body_size (domyślnie: 1 MB); Apache używa LimitRequestBody. Przekroczenie tych progów powoduje odpowiedź 400 lub 413 w zależności od konfiguracji.

Nieaktualna lub nieprawidłowa pamięć podręczna DNS

Chociaż błędy rozwiązywania DNS zazwyczaj powodują błędy połączenia, a nie HTTP 400, zatruta lub nieaktualna pamięć podręczna DNS, która kieruje żądanie do niewłaściwego serwera — takiego, który nie rozpoznaje nagłówka Host — może skutkować zwróceniem błędu 400 przez niewłaściwe źródło.

Rozszerzenia przeglądarki ingerujące w nagłówki żądań

Niektóre blokery reklam, narzędzia ochrony prywatności i rozszerzenia deweloperskie modyfikują wychodzące nagłówki HTTP. Jeśli rozszerzenie wstrzykuje nieprawidłowy lub zduplikowany nagłówek, serwer może odrzucić żądanie.

Przyczyny po stronie serwera

Błędnie skonfigurowane reguły .htaccess (Apache)

Reguły przepisywania, dyrektywy przekierowań lub wpisy kontroli dostępu z błędami składni mogą powodować, że Apache generuje błąd 400 zanim żądanie dotrze do warstwy aplikacji.

Błędy konfiguracji Nginx

Nieprawidłowe dyrektywy server_name, uszkodzone bloki location lub niepoprawne ustawienia proxy_pass mogą powodować, że Nginx zwraca błąd 400 dla żądań, których nie może obsłużyć.

Nadmierne blokowanie przez WAF lub wtyczki bezpieczeństwa

Zapory aplikacji internetowych (WAF) — czy to na poziomie serwera (ModSecurity), CDN (Cloudflare WAF), czy aplikacji (wtyczki bezpieczeństwa WordPress) — mogą oznaczać prawidłowe żądania jako złośliwe i zwracać błąd 400 lub 403. Jest to częste, gdy parametry żądania zawierają ciągi pasujące do sygnatur SQL injection lub XSS.

Błędy walidacji na poziomie aplikacji

Frameworki takie jak Laravel, Django lub Express.js zwracają błąd 400, gdy walidacja danych wejściowych nie powiedzie się — na przykład brakuje wymaganego pola JSON, pole daty ma nieprawidłowy format lub parametr numeryczny otrzymuje wartość tekstową.

Jak naprawić błąd 400 Bad Request: kroki po stronie klienta

1. Sprawdź i popraw URL

Sprawdź URL znak po znaku. Zwróć szczególną uwagę na:

• Niezakodowane spacje: Spacja musi być zakodowana jako %20, a nie jako dosłowna spacja lub + (poza danymi formularza).
• Podwójne ukośniki lub brakujące ukośniki: https://example.com//path lub https://example.com/path? z wiszącym znakiem zapytania.
• Uszkodzone kodowanie procentowe: Znak % niepo poprzedzony dokładnie dwoma cyframi szesnastkowymi jest niedozwolony.
• Znaki spoza ASCII: Nazwy domen z znakami Unicode muszą używać Punycode; segmenty ścieżki z Unicode muszą być kodowane procentowo w UTF-8.

Prawidłowo zakodowany URL wygląda tak:

https://example.com/search?q=hello%20world&lang=en

A nie tak:

https://example.com/search?q=hello world&lang=en

2. Wyczyść ciasteczka i pamięć podręczną przeglądarki

To rozwiązuje większość błędów 400 napotykanych na stronach, które użytkownik wcześniej odwiedzał.

Google Chrome:

1. Otwórz chrome://settings/clearBrowserData
2. Ustaw zakres czasu na Cały czas
3. Zaznacz Pliki cookie i inne dane witryn oraz Obrazy i pliki w pamięci podręcznej
4. Kliknij Wyczyść dane

Mozilla Firefox:

1. Otwórz about:preferences#privacy
2. W sekcji Ciasteczka i dane witryn kliknij Wyczyść dane
3. Zaznacz obie opcje i potwierdź

Safari (macOS):

1. Przejdź do Safari > Ustawienia > Prywatność
2. Kliknij Zarządzaj danymi witryn, a następnie Usuń wszystkie

Aby zastosować bardziej ukierunkowane podejście — szczególnie przydatne, gdy nie chcesz utracić wszystkich danych sesji — użyj narzędzi deweloperskich przeglądarki, aby usunąć tylko ciasteczka dla konkretnej domeny:

1. Otwórz DevTools (F12 lub Cmd+Option+I)
2. Przejdź do Aplikacja > Magazyn > Ciasteczka
3. Wybierz domenę i usuń poszczególne ciasteczka

3. Wyczyść pamięć podręczną DNS

Windows:

ipconfig /flushdns

macOS (Ventura, Sonoma, Sequoia):

sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

Linux (systemd-resolved):

sudo systemd-resolve --flush-caches

Linux (nscd):

sudo service nscd restart

Po wyczyszczeniu pamięci podręcznej sprawdź poprawność rozwiązywania nazw przed ponowną próbą:

nslookup example.com

4. Wyłącz rozszerzenia przeglądarki

Rozszerzenia modyfikujące nagłówki HTTP są najbardziej prawdopodobnymi winowajcami. Zamiast wyłączać wszystkie rozszerzenia jednocześnie, najpierw użyj trybu incognito lub prywatnego przeglądarki — większość rozszerzeń jest domyślnie wyłączona w oknach prywatnych. Jeśli strona ładuje się poprawnie w trybie incognito, winne jest jakieś rozszerzenie.

Aby zidentyfikować konkretne rozszerzenie w Chrome:

1. Przejdź do chrome://extensions/
2. Wyłącz wszystkie rozszerzenia
3. Włączaj je po jednym, przeładowując stronę po każdym

5. Przetestuj w innej przeglądarce, na innym urządzeniu lub w innej sieci

Ten krok szybko pozwala ustalić, czy problem jest specyficzny dla środowiska. Jeśli strona ładuje się na urządzeniu mobilnym korzystającym z danych komórkowych, ale nie działa na komputerze stacjonarnym, problem jest prawdopodobnie lokalny — może to być konfiguracja przeglądarki, proxy na poziomie sieci lub firmowa zapora sieciowa modyfikująca nagłówki żądań.

Jak naprawić błąd 400 Bad Request: kroki po stronie serwera

Te kroki dotyczą właścicieli stron internetowych, deweloperów i administratorów systemów mających dostęp do serwera lub panelu sterowania hostingiem.

6. Analizuj logi dostępu i błędów serwera

Logi serwera są ostatecznym narzędziem diagnostycznym. Wpis 400 w logu dostępu pokaże surową linię żądania, które zostało odrzucone.

Log błędów Nginx (domyślna ścieżka):

tail -n 100 /var/log/nginx/error.log | grep " 400 "

Log błędów Apache:

tail -n 100 /var/log/apache2/error.log

Log dostępu Nginx — filtrowanie odpowiedzi 400:

awk '$9 == 400' /var/log/nginx/access.log | tail -20

Szukaj wzorców: czy błędy 400 pochodzą z konkretnego punktu końcowego, konkretnego agenta użytkownika lub konkretnego parametru? To znacznie zawęża przyczynę źródłową.

Jeśli korzystasz ze środowiska VPS Hosting, masz bezpośredni dostęp SSH do tych logów. Na zarządzanym Hostingu Współdzielonym logi dostępu są zazwyczaj dostępne przez sekcję Błędy w cPanel lub poprzez pobieranie logów Raw Access.

7. Sprawdź plik .htaccess (Apache)

Pojedynczy błąd składni w .htaccess może spowodować, że Apache zwraca błędy 400 lub 500 dla każdego żądania. Sprawdź składnię pliku bez restartowania Apache:

apachectl -t

Typowe problemy z .htaccess powodujące błędy 400:

• Wzorce RewriteRule z niezaescapowanymi znakami specjalnymi

LimitRequestBody ustawiony na nieoczekiwanie niską wartość
Nieprawidłowo sformułowane dyrektywy Header

Przykład problematycznej dyrektywy:

# This will cause a 400 if the header value is malformed
RequestHeader set X-Custom-Header "value with "quotes""

Poprawiona wersja:

RequestHeader set X-Custom-Header "value with escaped quotes"

8. Sprawdź konfigurację Nginx

Sprawdź poprawność całej konfiguracji Nginx przed wprowadzeniem zmian:

nginx -t

Zwróć uwagę na client_max_body_size, jeśli użytkownicy przesyłają pliki:

http {
    client_max_body_size 50M;
}

Sprawdź również large_client_header_buffers — jeśli nagłówki żądań (w tym ciasteczka) przekraczają rozmiar bufora, Nginx zwraca błąd 400:

http {
    large_client_header_buffers 4 16k;
}

Po edycji przeładuj bez przestoju:

nginx -s reload

9. Zwiększ limity przesyłania plików

Jeśli błąd 400 pojawia się konkretnie podczas przesyłania plików, treść żądania prawdopodobnie przekracza skonfigurowany limit serwera.

PHP (php.ini):

upload_max_filesize = 50M
post_max_size = 55M

Apache (httpd.conf lub .htaccess):

LimitRequestBody 52428800

Nginx (nginx.conf):

client_max_body_size 50M;

Pamiętaj, że post_max_size w PHP musi być zawsze większy niż upload_max_filesize, w przeciwnym razie PHP po cichu odrzuci przesyłanie, a aplikacja może zwrócić błąd 400.

10. Przejrzyj reguły WAF i wtyczki bezpieczeństwa

Jeśli korzystasz z ModSecurity, Cloudflare WAF lub wtyczki bezpieczeństwa WordPress (Wordfence, iThemes Security), tymczasowo wyłącz zestaw reguł WAF i sprawdź, czy błąd 400 znika. Jeśli tak, przejrzyj log audytu WAF, aby zidentyfikować, która reguła jest wyzwalana:

tail -f /var/log/modsec_audit.log

Nie wyłączaj WAF na stałe. Zamiast tego utwórz ukierunkowany wyjątek dla prawidłowego wzorca żądania, który jest blokowany.

400 Bad Request a powiązane kody błędów HTTP

Zrozumienie miejsca błędu 400 w taksonomii błędów HTTP zapobiega błędnej diagnozie.

Kluczowa różnica operacyjna: 413 (Content Too Large) jest bardziej semantycznie precyzyjnym kodem dla zbyt dużych przesyłanych plików, jednak wiele serwerów — szczególnie starsze konfiguracje Apache i Nginx — zwraca zamiast niego 400. Jeśli widzisz błąd 400 podczas przesyłania pliku, zawsze najpierw sprawdź limity rozmiaru treści.

Błędy 400 w kontekście API

REST i GraphQL API szeroko używają kodu 400 jako standardowej odpowiedzi na błędy walidacji danych wejściowych. Jeśli tworzysz lub konsumujesz API, treść odpowiedzi 400 zazwyczaj zawiera ustrukturyzowany ładunek błędu:

{
  "error": "Bad Request",
  "message": "The 'email' field must be a valid email address.",
  "field": "email",
  "code": 400
}

Podczas debugowania błędów 400 w API:

• Sprawdź, czy nagłówek Content-Type odpowiada formatowi treści (application/json dla ładunków JSON, multipart/form-data dla przesyłania plików)
• Potwierdź, że wymagane pola są obecne i mają poprawny typ
• Sprawdź, czy wartości tekstowe nie przekraczają maksymalnych ograniczeń długości
• Sprawdź poprawność formatów daty i czasu względem specyfikacji API (ISO 8601 jest standardem: 2024-01-15T10:30:00Z)
• Sprawdź format nagłówka Authorization — tokeny Bearer muszą być poprzedzone prefiksem Bearer , a nie przekazywane bez niego

Dla zespołów uruchamiających usługi API na Serwerach Dedykowanych, włączenie szczegółowego logowania żądań na poziomie aplikacji (nie tylko na poziomie serwera internetowego) jest kluczowe dla diagnozowania wzorców błędów 400 na dużą skalę.

Diagnozowanie błędów 400 za pomocą narzędzi deweloperskich przeglądarki

Panel Sieć w narzędziach deweloperskich przeglądarki to najdokładniejsze dostępne narzędzie diagnostyczne po stronie klienta.

1. Otwórz DevTools (F12)
2. Przejdź do zakładki Sieć
3. Odtwórz żądanie wywołujące błąd 400
4. Kliknij na nieudane żądanie na osi czasu
5. Sprawdź zakładkę Nagłówki — przejrzyj zarówno Nagłówki żądania, jak i Nagłówki odpowiedzi
6. Sprawdź zakładkę Odpowiedź pod kątem szczegółów błędu zwróconych przez serwer

Panel Nagłówki żądania pokaże dokładnie to, co przeglądarka wysłała. Porównaj to z tym, czego oczekuje serwer. Zwróć szczególną uwagę na:

• Wartość nagłówka Host
• Rozmiar i zawartość nagłówka Cookie
• Content-Type i Content-Length dla żądań POST/PUT
• Wszelkie niestandardowe nagłówki wstrzyknięte przez rozszerzenia

Zapobieganie błędom 400 w aplikacjach internetowych

Dla deweloperów i administratorów serwerów proaktywne działania znacznie zmniejszają częstotliwość występowania błędów 400.

Sanityzacja i walidacja danych wejściowych na poziomie aplikacji — Sprawdzaj wszystkie dane dostarczone przez użytkownika zanim dotrą do warstwy routingu serwera. Zwracaj opisowe odpowiedzi 400 z komunikatami błędów na poziomie pól, a nie ogólnymi komunikatami o błędach.

Implementuj prawidłowe kodowanie URL w kodzie klienta — Używaj wbudowanych funkcji kodowania zamiast ręcznej manipulacji ciągami znaków:

// JavaScript — correct approach
const query = encodeURIComponent("hello world & more");
const url = `https://example.com/search?q=${query}`;

# Python — correct approach
from urllib.parse import urlencode
params = urlencode({"q": "hello world & more"})
url = f"https://example.com/search?{params}"

Ustaw jawne i rozsądne limity rozmiaru treści — Nie pozostawiaj client_max_body_size przy domyślnym 1 MB, jeśli aplikacja przyjmuje przesyłane pliki. Jednocześnie nie ustawiaj go na nieograniczony — stwarza to wektor ataku typu odmowa usługi.

Monitoruj wskaźniki błędów 400 w środowisku produkcyjnym — Nagły wzrost liczby błędów 400 jest często pierwszym sygnałem, że bot skanuje w poszukiwaniu podatności, formularz po stronie klienta jest uszkodzony lub wdrożenie wprowadził przełomową zmianę w API. Skonfiguruj alerty dotyczące wskaźnika błędów 4xx w swoim stosie monitorowania (Grafana, Datadog, CloudWatch).

Używaj HTTPS z ważnym certyfikatem SSL — Niektóre błędy 400 pojawiają się, gdy klienci wysyłają żądania HTTPS do serwera, który nie jest prawidłowo skonfigurowany dla TLS, lub gdy niezgodność certyfikatu powoduje niepowodzenie uzgadniania TLS zanim w ogóle zostanie osiągnięta warstwa HTTP. Zapewnienie, że Certyfikaty SSL są ważne, prawidłowo zainstalowane i obejmują wszystkie wymagane subdomeny, całkowicie eliminuje tę klasę błędów.

Prawidłowo konfiguruj środowiska panelu sterowania — Jeśli zarządzasz wieloma stronami przez panel sterowania, błędnie skonfigurowane definicje wirtualnych hostów są częstym źródłem błędów 400. Środowiska korzystające z VPS z cPanel powinny weryfikować, czy katalog główny dokumentów każdej domeny, powiązanie SSL i reguły przepisywania są prawidłowo ograniczone, aby uniknąć zanieczyszczenia żądań między domenami.

Macierz decyzyjna: diagnozowanie błędu 400 według objawu

Lista kontrolna techniczna: rozwiązywanie błędu 400 Bad Request

Dla użytkowników końcowych:

• Ręcznie sprawdź i przepisz URL, korygując wszelkie problemy z kodowaniem
• Wyczyść ciasteczka i pamięć podręczną konkretnie dla dotkniętej domeny
• Przetestuj w oknie prywatnym/incognito, aby wykluczyć rozszerzenia
• Wyczyść lokalną pamięć podręczną DNS
• Przetestuj w innej przeglądarce, na innym urządzeniu i z innym połączeniem sieciowym

Dla deweloperów i konsumentów API:

• Sprawdź, czy Content-Type odpowiada formatowi treści żądania
• Potwierdź, że wszystkie wymagane pola i nagłówki są obecne i mają poprawny typ
• Sprawdź, czy wartości tekstowe, daty i typy numeryczne są zgodne z kontraktem API
• Użyj curl z pełnym wyjściem, aby sprawdzić surową wymianę HTTP:

curl -v -X POST https://api.example.com/endpoint 
  -H "Content-Type: application/json" 
  -H "Authorization: Bearer YOUR_TOKEN" 
  -d '{"key": "value"}'

Dla administratorów serwerów:

• Pobierz i przeszukaj logi błędów serwera pod kątem wpisów 400
• Sprawdź poprawność składni konfiguracji serwera internetowego (nginx -t / apachectl -t)
• Sprawdź client_max_body_size (Nginx) i LimitRequestBody (Apache)
• Przejrzyj large_client_header_buffers w Nginx, jeśli żądania z dużą ilością ciasteczek kończą się niepowodzeniem
• Sprawdź reguły WAF i log audytu ModSecurity
• Sprawdź ważność i zakres certyfikatu SSL/TLS
• Potwierdź, że reguły przepisywania .htaccess są składniowo poprawne

—

FAQ

Jaka jest różnica między błędem 400 a błędem 404?

Błąd 400 oznacza, że serwer nie mógł zrozumieć żądania, ponieważ było nieprawidłowo sformułowane — wina leży w sposobie skonstruowania żądania. Błąd 404 oznacza, że żądanie było prawidłowe i zrozumiałe, ale żądany zasób po prostu nie istnieje na serwerze. Wymagają one zupełnie innych rozwiązań.

Czy błąd 400 Bad Request może być spowodowany przez serwer, a nie przez klienta?

Tak, pośrednio. Błędna konfiguracja serwera — taka jak zbyt restrykcyjna reguła WAF, nieprawidłowe ustawienie large_client_header_buffers w Nginx lub uszkodzona dyrektywa .htaccess — może spowodować, że serwer odrzuca technicznie prawidłowe żądania. W takich przypadkach specyfikacja HTTP jest nadal przestrzegana (serwer odrzuca to, co postrzega jako złe żądanie), ale rzeczywista wina leży w konfiguracji serwera, a nie w żądaniu klienta.

Dlaczego wyczyszczenie ciasteczek naprawia błąd 400?

Ciasteczka są wysyłane w nagłówku żądania Cookie przy każdym żądaniu do odpowiedniej domeny. Jeśli ciasteczko przechowywane w przeglądarce jest nieprawidłowe, wygasło w sposób nieakceptowany przez serwer lub stało się zbyt duże (przekraczając limity large_client_header_buffers w Nginx), serwer odrzuca całe żądanie z błędem 400 przed jego przetworzeniem. Usunięcie uszkodzonego ciasteczka eliminuje błędne dane z nagłówka.

Jak naprawić błąd 400 podczas przesyłania plików na moją stronę?

Przesyłanie przekracza limit rozmiaru treści serwera internetowego lub limit rozmiaru przesyłania PHP. W Nginx zwiększ client_max_body_size w nginx.conf. W Apache dostosuj LimitRequestBody w .htaccess lub httpd.conf. W aplikacjach PHP zaktualizuj upload_max_filesize i post_max_size w php.ini, upewniając się, że post_max_size jest większy niż upload_max_filesize. Uruchom ponownie odpowiednie usługi po wprowadzeniu zmian.

Jak sprawdzić, czy błąd 400 pochodzi z CDN lub WAF, a nie z mojego serwera źródłowego?

Sprawdź nagłówki odpowiedzi. Cloudflare dodaje nagłówki cf-ray i server: cloudflare. AWS CloudFront dodaje x-amz-cf-id. Jeśli te nagłówki są obecne w odpowiedzi 400, odrzucenie nastąpiło na brzegu sieci, a nie na serwerze źródłowym. Przejrzyj logi WAF CDN lub panel zdarzeń zapory sieciowej, aby zidentyfikować, która reguła wywołała blokadę, a następnie utwórz ukierunkowany wyjątek dla prawidłowego wzorca ruchu.