Що таке помилка 400 Bad Request і як її виправити (Повний посібник)

Помилка 400 Bad Request — це код стану HTTP, який повідомляє, що сервер отримав ваш запит, але відмовився його обробляти — не через збій на стороні сервера, а тому що щось у самому запиті було неправильно сформовано, недійсно або пошкоджено. Незалежно від того, чи ви звичайний користувач, який натрапив на несподіваний бар’єр, чи системний адміністратор, який діагностує неправильно налаштований сервер, розуміння цієї помилки є важливим для швидкого та ефективного усунення неполадок.

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

Що означає помилка 400 Bad Request?

У протоколі HTTP коди стану в діапазоні 4xx вказують на помилки на стороні клієнта. 400 конкретно означає, що сервер зрозумів формат запиту, але виявив його синтаксично неправильним або іншим чином необробним, навіть не намагаючись його виконати.

Поширені варіації повідомлення про помилку 400

Залежно від сервера, фреймворку або CDN, яка використовується, ви можете побачити цю помилку відображеною як:

• 400 Bad Request
• Bad Request – Invalid URL
• HTTP Error 400
• 400. That's an error.
• 400 Bad Request. The server cannot or will not process the request due to a client error.
• Invalid request

Усі вони вказують на одну й ту саму основну причину: клієнт надіслав щось, що сервер не міг прийняти.

Що викликає помилку 400 Bad Request?

Перш ніж переходити до виправлень, важливо розуміти основні причини. Помилка 400 може бути викликана дивовижно широким спектром проблем:

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

1. Перевірте URL на помилки та синтаксичні помилки

Неправильна URL-адреса є найпоширенішою причиною помилки 400, і це перше, що ви повинні перевірити. Навіть один неправильно розміщений символ може зробити запит нечитаним для сервера.

На що звернути увагу:

• Помилки в написанні домену або шляху
• Подвійні скісні риски (//), де вони не повинні з’являтися
• Незакодовані спеціальні символи — пробіли, дужки або амперсанди, які не були URL-закодовані
• Розірвані рядки запиту з відсутніми = знаками або & роздільниками

Практичний приклад:

URL-адреса на кшталт https://example.com/search?q=hello world містить незакодований пробіл, що є недійсним. Правильна, належно закодована версія:

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

Завжди двічі перевіряйте URL у адресному рядку браузера, перш ніж припускати, що проблема глибша.

2. Очистіть кеш браузера та файли cookie

Пошкоджені або застарілі файли cookie та кешовані файли є основною причиною помилок 400, особливо на сайтах, які ви відвідували раніше. Браузер може надсилати кешований, тепер недійсний файл cookie, який сервер відразу відхиляє.

У Google Chrome:

1. Натисніть меню три крапки (⋮) у верхньому правому куті.
2. Перейдіть до Інші інструменти → Видалити дані про перегляд.
3. Установіть прапорці Файли cookie та дані сайтів та Кешовані зображення та файли.
4. Натисніть Видалити дані.

У Mozilla Firefox:

1. Натисніть меню гамбургер (☰) і перейдіть до Параметри.
2. Виберіть Приватність та безпека.
3. У розділі *Файли cookie та дані сайтів* натисніть Видалити дані.
4. Установіть обидва прапорці та натисніть Видалити.

У Safari (macOS):

1. Натисніть Safari у рядку меню та перейдіть до Параметри → Приватність.
2. Натисніть Керувати даними веб-сайту, потім Видалити все.
3. Перезапустіть Safari і повторіть спробу URL-адреси.

Після очищення кешу та файлів cookie перезавантажте сторінку та перевірте, чи зберігається помилка.

3. Очистіть кеш DNS

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

На Windows:

Відкрийте Командний рядок від імені адміністратора і запустіть:

ipconfig /flushdns

Ви повинні побачити підтвердження: *"Кеш DNS Resolver успішно очищено."*

На macOS (Ventura / Monterey / Sonoma):

Відкрийте Термінал і запустіть:

sudo killall -HUP mDNSResponder

На Linux (systemd-resolved):

sudo systemd-resolve --flush-caches

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

4. Перевірте обмеження розміру завантаженого файлу

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

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

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

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

На Apache відредагуйте свій .htaccess або httpd.conf:

LimitRequestBody 104857600

*(Це встановлює обмеження на 100MB.)*

На Nginx відредагуйте свій nginx.conf:

client_max_body_size 100M;

На PHP оновіть php.ini:

upload_max_filesize = 100M
post_max_size = 100M

Перезапустіть веб-сервер після внесення цих змін.

> Якщо ви запускаєте керовану середовище, розгляньте можливість оновлення до плану VPS Hosting, де у вас є повний контроль над параметрами конфігурації сервера.

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

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

У Google Chrome:

1. Введіть chrome://extensions/ у адресний рядок і натисніть Enter.
2. Вимкніть усі розширення.
3. Перезапустіть Chrome і протестуйте URL-адресу.
4. Повторно ввімкніть розширення по одному, щоб виділити проблемне.

У Firefox:

1. Введіть about:addons у адресний рядок.
2. Вимкніть усі розширення.
3. Перезапустіть і протестуйте.

Якщо помилка зникає з вимкненими розширеннями, видаліть або оновіть проблемне розширення.

6. Спробуйте інший браузер або пристрій

Іноді проблема повністю ізольована від конфігурації, профілю або збережених даних вашого поточного браузера. Тестування з альтернативою швидко усуває змінні, специфічні для браузера.

Кроки для виконання:

• Відкрийте ту саму URL-адресу в іншому браузері (наприклад, перейдіть з Chrome на Firefox або Edge).
• Спробуйте отримати доступ до сторінки з іншого пристрою (телефон, планшет або інший комп’ютер).
• Підключіться через іншу мережу (наприклад, перейдіть з Wi-Fi на мобільні дані).

Якщо сторінка завантажується правильно в іншому браузері або на іншому пристрої, проблема локальна для вашої оригінальної установки — повторіть кроки 2 та 5.

7. Перевірте журнали сервера (для власників веб-сайтів та адміністраторів)

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

На що звернути увагу в журналах:

• Конкретна лінія запиту, яка викликала відповідь 400
• Неправильно сформовані або надмірно великі заголовки запиту
• Недійсні дані файлів cookie, які надсилаються
• Запити, заблоковані брандмауером або правилами безпеки

Поширені місця розташування журналів:

Якщо ви використовуєте CMS, як-от WordPress, також перевірте журнал налагодження, ввімкнувши WP_DEBUG_LOG у wp-config.php:

define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);

> Адміністратори, які керують кількома сайтами, отримають користь від VPS з cPanel, який забезпечує централізований, зручний інтерфейс для перегляду журналів помилок на всіх розміщених доменах.

8. Перевірте та виправте неправильні конфігурації сервера

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

Apache — помилки .htaccess:

Синтаксичні помилки в .htaccess можуть змусити Apache відхилити запити. Перевірте свій файл за допомогою:

apachectl configtest

Шукайте рядки з неправильно сформованими RewriteRule директивами, недійсними mod_security правилами або розірваною логікою перенаправлення.

Nginx — помилки конфігурації:

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

nginx -t

Перевірте неправильно налаштовані server_name блоки, недійсні location директиви або надто обмежувальні limit_req правила.

Плагіни безпеки та правила WAF:

Брандмауери веб-додатків (WAF) та плагіни безпеки (такі як Wordfence або Sucuri) можуть агресивно блокувати законні запити, якщо