Що таке помилка 400 Bad Request і як її виправити?

Помилка 400 Bad Request — це код статусу HTTP/1.1, що відноситься до помилок клієнта, визначений у RFC 9110. Він сигналізує про те, що сервер отримав запит, який не може або не буде обробляти, оскільки сам запит є некоректним. На відміну від помилок 5xx, які виникають на стороні сервера, помилка 400 повністю покладає провину на клієнта — це означає, що проблема полягає у надісланому запиті, а не у здатності сервера відповідати.

На практиці помилка 400 виникає ще до того, як сервер намагається виконати запит. Сервер аналізує вхідне HTTP-повідомлення, виявляє щось структурно або семантично некоректне — пошкоджений заголовок, некоректний URI, надмірно великий payload, неправильний cookie — і негайно повертає 400 Bad Request, не продовжуючи обробку. Розуміння цього розмежування є найшвидшим шляхом до правильної діагностики.

Що насправді означає код статусу 400 на рівні протоколу

HTTP працює на основі суворого контракту запит-відповідь. Кожен запит повинен відповідати граматиці, визначеній у специфікації HTTP. Коли клієнт надсилає повідомлення, що порушує цю граматику, сервер має право і зобов’язаний відхилити його з відповіддю 400.

Сервер не реєструє 400 як власну помилку. Він реєструє це як відхилений запит клієнта. Саме тому сліпий перезапуск сервера або очищення кешу CDN рідко виправляє справжню помилку 400 — першопричина майже завжди полягає у формуванні запиту.

Поширені варіанти відображення цієї помилки у браузері включають:

• 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.

Усі вони відповідають одному і тому ж базовому коду статусу HTTP. Формулювання відрізняється залежно від серверного програмного забезпечення (Apache, Nginx, IIS, Cloudflare) та фреймворку застосунку.

Першопричини помилки 400 Bad Request

Розуміння точного тригера є необхідним перед будь-якою спробою виправлення. Причини поділяються на дві категорії: на стороні клієнта та неправильна конфігурація на стороні сервера.

Причини на стороні клієнта

Некоректний або неправильно закодований URL

URL, що містить незакодовані пробіли, недозволені символи або пошкоджені послідовності percent-encoding, буде негайно відхилено. Специфікація HTTP вимагає, щоб усі символи поза межами незарезервованого набору (A–Z, a–z, 0–9, -, _, ., ~) були percent-encoded перед передачею.

Пошкоджені або надмірно великі cookies

Cookies передаються у заголовку запиту Cookie. Якщо значення cookie є некоректним, перевищує ліміт розміру одного cookie у браузері (зазвичай 4096 байт) або містить символи, що порушують RFC 6265, сервер може відхилити весь запит. Це одна з найчастіше ігнорованих причин переривчастих помилок 400 на сайтах, які користувач раніше відвідував без проблем.

Недійсні або відсутні обов’язкові заголовки запиту

Деякі API та веб-застосунки застосовують суворі правила перевірки заголовків. Відсутній Content-Type у POST-запиті, некоректний заголовок Authorization або заголовок Accept з непідтримуваним типом медіа — все це може спровокувати помилку 400.

Надмірно великий payload запиту

Веб-сервери та зворотні проксі застосовують обмеження максимального розміру тіла запиту. Nginx використовує client_max_body_size (за замовчуванням: 1 МБ); Apache використовує LimitRequestBody. Перевищення цих порогів призводить до відповіді 400 або 413 залежно від конфігурації.

Застарілий або некоректний кеш DNS

Хоча збої у DNS-розпізнаванні зазвичай призводять до помилок з’єднання, а не до HTTP 400, отруєний або застарілий кеш DNS, який спрямовує запит на неправильний сервер — той, що не розпізнає заголовок Host — може призвести до повернення помилки 400 неправильним сервером-джерелом.

Розширення браузера, що втручаються у заголовки запитів

Деякі блокувальники реклами, інструменти конфіденційності та розширення для розробників змінюють вихідні HTTP-заголовки. Якщо розширення вставляє некоректний або дублюючий заголовок, сервер може відхилити запит.

Причини на стороні сервера

Неправильно налаштовані правила .htaccess (Apache)

Правила перезапису, директиви перенаправлення або записи контролю доступу з синтаксичними помилками можуть змусити Apache генерувати помилку 400 ще до того, як запит досягне рівня застосунку.

Помилки конфігурації Nginx

Недійсні директиви server_name, пошкоджені блоки location або неправильні налаштування proxy_pass можуть змусити Nginx повертати помилку 400 для запитів, які він не може маршрутизувати.

Надмірне блокування WAF або плагіна безпеки

Брандмауери веб-застосунків — чи то на рівні сервера (ModSecurity), рівні CDN (Cloudflare WAF) або рівні застосунку (плагіни безпеки WordPress) — можуть позначати легітимні запити як шкідливі та повертати помилку 400 або 403. Це поширено, коли параметри запиту містять рядки, що відповідають сигнатурам SQL-ін’єкцій або XSS.

Збої валідації на рівні застосунку

Фреймворки на кшталт Laravel, Django або Express.js повертають 400, коли валідація вхідних даних не проходить — наприклад, відсутнє обов’язкове поле JSON, поле дати має неправильний формат або числовий параметр отримує рядкове значення.

Як виправити помилку 400 Bad Request: кроки на стороні клієнта

1. Перевірте та виправте URL

Перевірте URL символ за символом. Зверніть особливу увагу на:

• Незакодовані пробіли: Пробіл повинен бути %20, а не буквальним пробілом або + (поза межами даних форми).
• Подвійні або відсутні слеші: https://example.com//path або https://example.com/path? з висячим знаком питання.
• Пошкоджений percent-encoding: Символ %, за яким не слідують рівно дві шістнадцяткові цифри, є недозволеним.
• Символи поза ASCII: Доменні імена з символами Unicode повинні використовувати Punycode; сегменти шляху з Unicode повинні бути percent-encoded у UTF-8.

Правильно закодований URL виглядає так:

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

А не так:

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

2. Очистіть cookies та кеш браузера

Це вирішує більшість помилок 400, що виникають на сайтах, які користувач раніше відвідував.

Google Chrome:

1. Відкрийте chrome://settings/clearBrowserData
2. Встановіть часовий діапазон на Увесь час
3. Позначте Файли cookie та інші дані сайтів і Кешовані зображення та файли
4. Натисніть Видалити дані

Mozilla Firefox:

1. Відкрийте about:preferences#privacy
2. У розділі Файли cookie та дані сайтів натисніть Видалити дані
3. Виберіть обидва параметри та підтвердіть

Safari (macOS):

1. Перейдіть до Safari > Параметри > Конфіденційність
2. Натисніть Керування даними веб-сайтів, потім Видалити все

Для більш точного підходу — особливо корисного, коли ви не хочете втрачати всі дані сесії — скористайтеся інструментами розробника браузера, щоб видалити лише cookies для конкретного домену:

1. Відкрийте DevTools (F12 або Cmd+Option+I)
2. Перейдіть до Application > Storage > Cookies
3. Виберіть домен і видаліть окремі cookies

3. Очистіть кеш 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

Після очищення перевірте правильність розпізнавання перед повторною спробою:

nslookup example.com

4. Вимкніть розширення браузера

Розширення, що змінюють HTTP-заголовки, є найімовірнішими винуватцями. Замість того щоб вимикати всі розширення одночасно, спочатку скористайтеся режимом анонімного або приватного перегляду браузера — більшість розширень за замовчуванням вимкнені у приватних вікнах. Якщо сторінка коректно завантажується в анонімному режимі, відповідальним є розширення.

Щоб визначити конкретне розширення у Chrome:

1. Перейдіть до chrome://extensions/
2. Вимкніть усі розширення
3. Вмикайте їх по одному, перезавантажуючи сторінку після кожного

5. Перевірте в іншому браузері, на іншому пристрої або мережі

Цей крок швидко визначає, чи є проблема специфічною для середовища. Якщо сторінка завантажується на мобільному пристрої через мобільний інтернет, але не завантажується на вашому комп’ютері, проблема, ймовірно, локальна — або конфігурація браузера, мережевий проксі, або корпоративний брандмауер, що змінює заголовки запитів.

Як виправити помилку 400 Bad Request: кроки на стороні сервера

Ці кроки стосуються власників веб-сайтів, розробників та системних адміністраторів, які мають доступ до сервера або панелі керування хостингом.

6. Проаналізуйте журнали доступу та помилок сервера

Журнали сервера є остаточним інструментом діагностики. Запис 400 у журналі доступу покаже необроблений рядок запиту, який був відхилений.

Журнал помилок Nginx (шлях за замовчуванням):

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

Журнал помилок Apache:

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

Журнал доступу Nginx — фільтрація відповідей 400:

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

Шукайте закономірності: чи надходять помилки 400 з певного endpoint, певного user agent або певного параметра? Це значно звужує першопричину.

Якщо ви використовуєте середовище VPS Хостинг, у вас є прямий SSH-доступ до цих журналів. На керованому Спільному веб-хостингу журнали доступу зазвичай доступні через розділ Помилки у cPanel або через завантаження журналу Raw Access.

7. Перевірте файл .htaccess (Apache)

Одна синтаксична помилка у .htaccess може змусити Apache повертати помилки 400 або 500 для кожного запиту. Перевірте синтаксис файлу без перезапуску Apache:

apachectl -t

Поширені проблеми з .htaccess, що призводять до помилок 400:

• Шаблони RewriteRule з неекранованими спеціальними символами

LimitRequestBody встановлено на несподівано низьке значення
Некоректні директиви Header

Приклад проблемної директиви:

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

Виправлена версія:

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

8. Перевірте конфігурацію Nginx

Перевірте всю конфігурацію Nginx перед застосуванням змін:

nginx -t

Зверніть увагу на client_max_body_size, якщо користувачі завантажують файли:

http {
    client_max_body_size 50M;
}

Також перегляньте large_client_header_buffers — якщо заголовки запиту (включно з cookies) перевищують розмір буфера, Nginx повертає помилку 400:

http {
    large_client_header_buffers 4 16k;
}

Після редагування перезавантажте без простою:

nginx -s reload

9. Збільшіть ліміти завантаження файлів

Якщо помилка 400 виникає саме під час завантаження файлів, тіло запиту, ймовірно, перевищує налаштований ліміт сервера.

PHP (php.ini):

upload_max_filesize = 50M
post_max_size = 55M

Apache (httpd.conf або .htaccess):

LimitRequestBody 52428800

Nginx (nginx.conf):

client_max_body_size 50M;

Зверніть увагу, що post_max_size у PHP завжди повинен бути більшим за upload_max_filesize, інакше PHP мовчки відхилить завантаження і застосунок може повернути помилку 400.

10. Перегляньте правила WAF та плагіни безпеки

Якщо ви використовуєте ModSecurity, Cloudflare WAF або плагін безпеки WordPress (Wordfence, iThemes Security), тимчасово вимкніть набір правил WAF і перевірте, чи зникне помилка 400. Якщо так, перегляньте журнал аудиту WAF, щоб визначити, яке правило спрацьовує:

tail -f /var/log/modsec_audit.log

Не вимикайте WAF назавжди. Натомість створіть цільовий виняток для легітимного шаблону запиту, який блокується.

Помилка 400 Bad Request порівняно з пов’язаними кодами помилок HTTP

Розуміння місця помилки 400 у таксономії помилок HTTP запобігає неправильній діагностиці.

Ключова операційна відмінність: 413 (Content Too Large) є більш семантично точним кодом для надмірно великих завантажень, але багато серверів — зокрема старіші конфігурації Apache та Nginx — повертають натомість 400. Якщо ви бачите помилку 400 під час завантаження файлу, завжди спочатку перевіряйте ліміти розміру тіла запиту.

Помилки 400 в контексті API

REST та GraphQL API широко використовують 400 як стандартну відповідь на збої валідації вхідних даних. Якщо ви розробляєте або використовуєте API, тіло відповіді 400 зазвичай міститиме структурований payload з описом помилки:

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

При налагодженні помилок 400 в API:

• Перевірте, чи заголовок Content-Type відповідає формату тіла (application/json для JSON-payload, multipart/form-data для завантаження файлів)
• Переконайтеся, що всі обов’язкові поля присутні та мають правильний тип
• Перевірте, що рядкові значення не перевищують обмеження максимальної довжини
• Перевірте формати дати та часу відповідно до специфікації API (стандартом є ISO 8601: 2024-01-15T10:30:00Z)
• Перевірте формат заголовка Authorization — Bearer-токени повинні мати префікс Bearer , а не передаватися у сирому вигляді

Для команд, що запускають API-сервіси на Виділених серверах, увімкнення детального журналювання запитів на рівні застосунку (а не лише на рівні веб-сервера) є критично важливим для діагностики шаблонів помилок 400 у масштабі.

Діагностика помилок 400 за допомогою інструментів розробника браузера

Панель Network у браузері є найточнішим клієнтським інструментом діагностики.

1. Відкрийте DevTools (F12)
2. Перейдіть на вкладку Network
3. Відтворіть запит, що спричиняє помилку 400
4. Натисніть на невдалий запит у waterfall
5. Перевірте вкладку Headers — перегляньте як Request Headers, так і Response Headers
6. Перевірте вкладку Response на наявність деталей помилки, повернутих сервером

Панель Request Headers покаже саме те, що надіслав браузер. Порівняйте це з тим, що очікує сервер. Зверніть особливу увагу на:

• Значення заголовка Host
• Розмір та вміст заголовка Cookie
• Content-Type та Content-Length для POST/PUT-запитів
• Будь-які власні заголовки, вставлені розширеннями

Запобігання помилкам 400 у веб-застосунках

Для розробників та адміністраторів серверів превентивні заходи значно знижують частоту виникнення помилок 400.

Санітизація та валідація вхідних даних на рівні застосунку — Перевіряйте всі дані, введені користувачем, перш ніж вони досягнуть рівня маршрутизації сервера. Повертайте описові відповіді 400 з повідомленнями про помилки на рівні полів, а не загальні збої.

Реалізуйте правильне URL-кодування у клієнтському коді — Використовуйте вбудовані функції кодування замість ручних маніпуляцій з рядками:

// 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}"

Встановіть явні та розумні ліміти розміру тіла запиту — Не залишайте client_max_body_size на значенні за замовчуванням 1 МБ, якщо ваш застосунок приймає завантаження файлів. Водночас не встановлюйте необмежений розмір — це створює вектор атаки типу «відмова в обслуговуванні».

Відстежуйте частоту помилок 400 у продакшені — Раптовий стрибок кількості помилок 400 часто є першим індикатором того, що бот сканує вразливості, клієнтська форма зламана або розгортання внесло несумісну зміну API. Налаштуйте сповіщення про частоту помилок 4xx у вашому стеку моніторингу (Grafana, Datadog, CloudWatch).

Використовуйте HTTPS з дійсним SSL-сертифікатом — Деякі помилки 400 виникають, коли клієнти надсилають HTTPS-запити на сервер, який не налаштований належним чином для TLS, або коли невідповідність сертифіката спричиняє збій TLS-рукостискання ще до досягнення рівня HTTP. Забезпечення того, що ваші SSL-сертифікати є дійсними, правильно встановленими та охоплюють усі необхідні піддомени, повністю усуває цей клас помилок.

Правильно налаштовуйте середовища панелі керування — Якщо ви керуєте кількома сайтами через панель керування, неправильно налаштовані визначення віртуальних хостів є поширеним джерелом помилок 400. Середовища, що використовують VPS з cPanel, повинні перевіряти, що кореневий каталог документів кожного домену, прив’язка SSL та правила перезапису правильно обмежені, щоб уникнути міждоменного забруднення запитів.

Матриця рішень: діагностика помилки 400 за симптомом

Технічний контрольний список: вирішення помилки 400 Bad Request

Для кінцевих користувачів:

• Вручну перевірте та введіть URL заново, виправивши будь-які проблеми з кодуванням
• Очистіть cookies та кеш саме для ураженого домену
• Перевірте у приватному/анонімному вікні, щоб виключити розширення
• Очистіть локальний кеш DNS
• Перевірте в іншому браузері, на іншому пристрої та через інше мережеве з’єднання

Для розробників та споживачів API:

• Перевірте, чи Content-Type відповідає формату тіла запиту
• Переконайтеся, що всі обов’язкові поля та заголовки присутні та мають правильний тип
• Перевірте, що рядкові значення, дати та числові типи відповідають контракту API
• Використовуйте curl з детальним виводом для перевірки необробленого HTTP-обміну:

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

Для адміністраторів серверів:

• Отримайте та відфільтруйте журнали помилок сервера на наявність записів 400
• Перевірте синтаксис конфігурації веб-сервера (nginx -t / apachectl -t)
• Перевірте client_max_body_size (Nginx) та LimitRequestBody (Apache)
• Перегляньте large_client_header_buffers у Nginx, якщо запити з великою кількістю cookies завершуються помилкою
• Перевірте правила WAF та журнал аудиту ModSecurity
• Перевірте дійсність та охоплення SSL/TLS-сертифіката
• Переконайтеся, що правила перезапису .htaccess є синтаксично правильними

—

FAQ

У чому різниця між помилками 400 та 404?

Помилка 400 означає, що сервер не зміг зрозуміти запит, оскільки він був некоректним — провина полягає у тому, як був сформований запит. Помилка 404 означає, що запит був дійсним і зрозумілим, але запитуваний ресурс просто не існує на сервері. Вони вимагають абсолютно різних підходів до виправлення.

Чи може помилка 400 Bad Request бути спричинена сервером, а не клієнтом?

Так, опосередковано. Неправильна конфігурація сервера — наприклад, надмірно обмежувальне правило WAF, неправильне налаштування large_client_header_buffers у Nginx або пошкоджена директива .htaccess — може змусити сервер відхиляти технічно дійсні запити. У таких випадках специфікація HTTP все одно дотримується (сервер відхиляє те, що він сприймає як поганий запит), але справжня провина полягає у конфігурації сервера, а не у запиті клієнта.

Чому очищення cookies виправляє помилку 400?

Cookies надсилаються у заголовку запиту Cookie з кожним запитом до відповідного домену. Якщо cookie, збережений у браузері, є некоректним, прострочений у спосіб, який сервер не приймає, або став надто великим (перевищуючи ліміти large_client_header_buffers у Nginx), сервер відхиляє весь запит з помилкою 400 ще до його обробки. Видалення пошкодженого cookie усуває погані дані із заголовка.

Як виправити помилку 400 під час завантаження файлів на мій веб-сайт?

Завантаження перевищує або ліміт розміру тіла запиту веб-сервера, або ліміт розміру завантаження PHP. У Nginx збільшіть client_max_body_size у nginx.conf. У Apache налаштуйте LimitRequestBody у .htaccess або httpd.conf. Для PHP-застосунків оновіть upload_max_filesize та post_max_size у php.ini, переконавшись, що post_max_size більший за upload_max_filesize. Перезапустіть відповідні служби після внесення змін.

Як визначити, чи надходить помилка 400 від CDN або WAF, а не від мого сервера-джерела?

Перевірте заголовки відповіді. Cloudflare додає заголовки cf-ray та server: cloudflare. AWS CloudFront додає x-amz-cf-id. Якщо ці заголовки присутні у відповіді 400, відхилення відбулося на edge-вузлі, а не на вашому сервері-джерелі. Перегляньте журнали WAF CDN або панель подій брандмауера, щоб визначити, яке правило спричинило блокування, а потім створіть цільовий виняток для легітимного шаблону трафіку.