Ce Este o Eroare 400 Bad Request și Cum o Remediați?

O eroare 400 Bad Request este un cod de stare HTTP/1.1 pentru erori de client, definit în RFC 9110, care semnalează că serverul a primit o cerere pe care nu o poate sau nu dorește să o proceseze, deoarece cererea în sine este malformată. Spre deosebire de erorile 5xx, care provin de pe server, o eroare 400 plasează vina direct pe client — ceea ce înseamnă că problema se află în cererea trimisă, nu în capacitatea serverului de a răspunde.

În termeni practici, o eroare 400 apare înainte ca serverul să încerce să îndeplinească cererea. Serverul analizează mesajul HTTP primit, detectează ceva invalid din punct de vedere structural sau semantic — un antet corupt, un URI malformat, un payload prea mare, un cookie defect — și returnează imediat 400 Bad Request în loc să continue. Cunoașterea acestei distincții este cea mai rapidă cale spre un diagnostic corect.

Ce înseamnă de fapt codul de stare 400 la nivel de protocol

HTTP funcționează pe baza unui contract strict cerere-răspuns. Fiecare cerere trebuie să respecte gramatica definită în specificația HTTP. Când un client trimite un mesaj care încalcă această gramatică, serverul este atât autorizat, cât și obligat să îl respingă cu un răspuns 400.

Serverul nu înregistrează un 400 ca pe o eroare proprie. Îl înregistrează ca pe o cerere de client respinsă. De aceea, repornirea oarbă a unui server sau golirea unui cache CDN rareori rezolvă un 400 autentic — cauza principală se află aproape întotdeauna în construcția cererii.

Variantele comune ale acestei erori afișate de browser includ:

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

Toate acestea corespund aceluiași cod de stare HTTP. Formularea diferă în funcție de software-ul serverului (Apache, Nginx, IIS, Cloudflare) și de framework-ul aplicației.

Cauzele principale ale erorii 400 Bad Request

Înțelegerea declanșatorului precis este esențială înainte de a încerca orice remediere. Cauzele se împart în două categorii: pe partea clientului și configurare greșită pe partea serverului.

Cauze pe partea clientului

URL malformat sau codificat incorect

Un URL care conține spații necodate, caractere ilegale sau secvențe de codificare procentuală defecte va fi respins imediat. Specificația HTTP impune ca toate caracterele din afara setului nerezervat (A–Z, a–z, 0–9, -, _, ., ~) să fie codificate procentual înainte de transmitere.

Cookie-uri corupte sau prea mari

Cookie-urile sunt transmise în antetul de cerere Cookie. Dacă valoarea unui cookie este malformată, depășește limita de dimensiune per cookie a browserului (de obicei 4096 de octeți) sau conține caractere care încalcă RFC 6265, serverul poate respinge întreaga cerere. Aceasta este una dintre cele mai frecvent trecute cu vederea cauze ale erorilor 400 intermitente pe site-uri pe care utilizatorul le-a vizitat anterior fără probleme.

Antete de cerere invalide sau lipsă

Unele API-uri și aplicații web impun o validare strictă a antetelor. Un Content-Type lipsă la o cerere POST, un antet Authorization malformat sau un antet Accept cu un tip de media neacceptat pot declanșa un 400.

Payload de cerere prea mare

Serverele web și proxy-urile inverse impun limite maxime pentru dimensiunea corpului. Nginx folosește client_max_body_size (implicit: 1 MB); Apache folosește LimitRequestBody. Depășirea acestor praguri produce un răspuns 400 sau 413, în funcție de configurație.

Cache DNS expirat sau incorect

Deși eșecurile de rezoluție DNS produc de obicei erori de conexiune mai degrabă decât HTTP 400, un cache DNS otrăvit sau expirat care direcționează o cerere către serverul greșit — unul care nu recunoaște antetul Host — poate duce la returnarea unui 400 de către originea greșită.

Extensii de browser care interferează cu antetele de cerere

Anumite blocante de reclame, instrumente de confidențialitate și extensii pentru dezvoltatori modifică antetele HTTP de ieșire. Dacă o extensie injectează un antet malformat sau duplicat, serverul poate respinge cererea.

Cauze pe partea serverului

Reguli .htaccess configurate greșit (Apache)

Regulile de rescriere, directivele de redirecționare sau intrările de control al accesului cu erori de sintaxă pot face ca Apache să genereze un 400 înainte ca cererea să ajungă la nivelul aplicației.

Erori de configurare Nginx

Directive server_name invalide, blocuri location defecte sau setări proxy_pass incorecte pot face ca Nginx să returneze un 400 pentru cererile pe care nu le poate direcționa.

Blocare excesivă de WAF sau plugin de securitate

Firewall-urile pentru aplicații web — fie la nivel de server (ModSecurity), la nivel CDN (Cloudflare WAF) sau la nivel de aplicație (plugin-uri de securitate WordPress) — pot marca cereri legitime ca malițioase și pot returna un 400 sau 403. Acest lucru este frecvent când parametrii cererii conțin șiruri care corespund semnăturilor de injecție SQL sau XSS.

Eșecuri de validare la nivel de aplicație

Framework-uri precum Laravel, Django sau Express.js returnează 400 când validarea datelor de intrare eșuează — de exemplu, un câmp JSON obligatoriu lipsește, un câmp de dată este în format greșit sau un parametru numeric primește o valoare de tip șir.

Cum să remediați o eroare 400 Bad Request: pași pe partea clientului

1. Validați și corectați URL-ul

Inspectați URL-ul caracter cu caracter. Acordați atenție deosebită:

• Spații necodate: Un spațiu trebuie să fie %20, nu un spațiu literal sau + (în afara datelor de formular).
• Bare oblice duble sau lipsă: https://example.com//path sau https://example.com/path? cu un semn de întrebare suspendat.
• Codificare procentuală defectă: Un % neurmat de exact două cifre hexazecimale este ilegal.
• Caractere non-ASCII: Numele de domenii cu caractere Unicode trebuie să folosească Punycode; segmentele de cale cu Unicode trebuie codificate procentual în UTF-8.

Un URL corect codificat arată astfel:

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

Nu astfel:

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

2. Ștergeți cookie-urile și cache-ul browserului

Aceasta rezolvă majoritatea erorilor 400 întâlnite pe site-uri pe care utilizatorul le-a vizitat anterior.

Google Chrome:

1. Deschideți chrome://settings/clearBrowserData
2. Setați intervalul de timp la Tot timpul
3. Bifați Cookie-uri și alte date de site și Imagini și fișiere în cache
4. Faceți clic pe Șterge datele

Mozilla Firefox:

1. Deschideți about:preferences#privacy
2. Sub Cookie-uri și date de site, faceți clic pe Șterge datele
3. Selectați ambele opțiuni și confirmați

Safari (macOS):

1. Mergeți la Safari > Setări > Confidențialitate
2. Faceți clic pe Gestionați datele site-ului, apoi pe Eliminați tot

Pentru o abordare mai țintită — utilă în special când nu doriți să pierdeți toate datele de sesiune — utilizați instrumentele pentru dezvoltatori ale browserului pentru a șterge doar cookie-urile pentru domeniul specific:

1. Deschideți DevTools (F12 sau Cmd+Option+I)
2. Navigați la Application > Storage > Cookies
3. Selectați domeniul și ștergeți cookie-urile individuale

3. Goliți cache-ul 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

După golire, verificați că rezoluția este corectă înainte de a reîncerca:

nslookup example.com

4. Dezactivați extensiile browserului

Extensiile care modifică antetele HTTP sunt cele mai probabile vinovate. În loc să dezactivați toate extensiile simultan, utilizați mai întâi modul incognito sau privat al browserului — majoritatea extensiilor sunt dezactivate implicit în ferestrele private. Dacă pagina se încarcă corect în incognito, o extensie este responsabilă.

Pentru a identifica extensia specifică în Chrome:

1. Navigați la chrome://extensions/
2. Dezactivați toate extensiile
3. Reactivați-le una câte una, reîncărcând pagina după fiecare

5. Testați pe un alt browser, dispozitiv sau rețea

Acest pas determină rapid dacă problema este specifică mediului. Dacă pagina se încarcă pe un dispozitiv mobil folosind date celulare, dar eșuează pe desktop, problema este probabil locală — fie configurația browserului, un proxy la nivel de rețea sau un firewall corporativ care modifică antetele de cerere.

Cum să remediați o eroare 400 Bad Request: pași pe partea serverului

Acești pași se aplică proprietarilor de site-uri, dezvoltatorilor și administratorilor de sistem cu acces la server sau la panoul de control al găzduirii.

6. Analizați jurnalele de acces și erori ale serverului

Jurnalele serverului sunt instrumentul de diagnostic definitiv. O intrare 400 în jurnalul de acces va afișa linia de cerere brută care a fost respinsă.

Jurnal de erori Nginx (cale implicită):

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

Jurnal de erori Apache:

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

Jurnal de acces Nginx — filtrați pentru răspunsuri 400:

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

Căutați tipare: erorile 400 provin dintr-un endpoint specific, un user agent specific sau un parametru specific? Aceasta restrânge dramatic cauza principală.

Dacă rulați un mediu de VPS Hosting, aveți acces direct SSH la aceste jurnale. Pe Găzduire Web Partajată gestionată, jurnalele de acces sunt de obicei disponibile prin secțiunea Erori din cPanel sau prin descărcarea jurnalului Raw Access.

7. Auditați fișierul .htaccess (Apache)

O singură eroare de sintaxă în .htaccess poate face ca Apache să returneze erori 400 sau 500 pentru fiecare cerere. Validați sintaxa fișierului fără a reporni Apache:

apachectl -t

Probleme comune în .htaccess care produc erori 400:

• Tipare RewriteRule cu caractere speciale neescapate

LimitRequestBody setat la o valoare neașteptat de mică
Directive Header malformate

Exemplu de directivă problematică:
# This will cause a 400 if the header value is malformed
RequestHeader set X-Custom-Header "value with "quotes""
Versiunea corectată:
RequestHeader set X-Custom-Header "value with escaped quotes"
8. Verificați configurația Nginx
Validați întreaga configurație Nginx înainte de a aplica modificări:
nginx -t
Acordați atenție client_max_body_size dacă utilizatorii încarcă fișiere:
http {
    client_max_body_size 50M;
}
Revizuiți și large_client_header_buffers — dacă antetele de cerere (inclusiv cookie-urile) depășesc dimensiunea bufferului, Nginx returnează un 400:
http {
    large_client_header_buffers 4 16k;
}
După editare, reîncărcați fără întreruperi:
nginx -s reload
9. Măriți limitele de încărcare a fișierelor
Dacă eroarea 400 apare specific în timpul încărcării fișierelor, corpul cererii depășește probabil limita configurată a serverului.
PHP (php.ini):
upload_max_filesize = 50M
post_max_size = 55M
Apache (httpd.conf sau .htaccess):
LimitRequestBody 52428800
Nginx (nginx.conf):
client_max_body_size 50M;
Rețineți că post_max_size în PHP trebuie să fie întotdeauna mai mare decât upload_max_filesize, altfel PHP va ignora silențios încărcarea și aplicația poate returna un 400.
10. Revizuiți regulile WAF și plugin-urile de securitate
Dacă rulați ModSecurity, Cloudflare WAF sau un plugin de securitate WordPress (Wordfence, iThemes Security), dezactivați temporar setul de reguli WAF și testați dacă eroarea 400 dispare. Dacă da, revizuiți jurnalul de audit WAF pentru a identifica ce regulă se declanșează:
tail -f /var/log/modsec_audit.log
Nu dezactivați pur și simplu WAF-ul permanent. În schimb, creați o excepție țintită pentru tiparul de cerere legitimă care este blocat.
400 Bad Request față de codurile de eroare HTTP înrudite
Înțelegerea locului în care se situează 400 în taxonomia erorilor HTTP previne diagnosticarea greșită.



Cod de stare
Denumire
Localizarea erorii
Cauză tipică








—
—
—
—








400
Bad Request
Client
Sintaxă de cerere malformată, antete invalide, codificare defectă








401
Unauthorized
Client
Credențiale de autentificare lipsă sau invalide








403
Forbidden
Politică server
Cerere validă, dar accesul este refuzat de regulile serverului








404
Not Found
Server
Resursa nu există la URI-ul solicitat








413
Content Too Large
Client
Corpul cererii depășește limita de dimensiune configurată a serverului








414
URI Too Long
Client
URI-ul cererii depășește lungimea maximă a URI acceptată de server








422
Unprocessable Content
Client
Valid sintactic, dar incorect semantic (frecvent în REST API-uri)








431
Request Header Fields Too Large
Client
Dimensiunea individuală sau totală a antetelor depășește limitele serverului








500
Internal Server Error
Server
Excepție netreatată sau configurare greșită pe server








502
Bad Gateway
Server/Proxy
Serverul upstream a returnat un răspuns invalid





O distincție operațională cheie: 413 (Content Too Large) este codul mai precis semantic pentru încărcări prea mari, dar multe servere — în special configurații mai vechi Apache și Nginx — returnează 400 în schimb. Dacă vedeți un 400 la încărcarea fișierelor, verificați întotdeauna mai întâi limitele de dimensiune ale corpului.
Erori 400 în contexte API
API-urile REST și GraphQL folosesc 400 pe scară largă ca răspuns standard pentru eșecurile de validare a datelor de intrare. Dacă construiți sau consumați un API, un corp de răspuns 400 va conține de obicei un payload de eroare structurat:
{
  "error": "Bad Request",
  "message": "The 'email' field must be a valid email address.",
  "field": "email",
  "code": 400
}
Când depanați erori 400 de API:

Verificați că antetul Content-Type corespunde formatului corpului (application/json pentru payload-uri JSON, multipart/form-data pentru încărcări de fișiere)
Confirmați că câmpurile și antetele obligatorii sunt prezente și corect tipizate
Verificați că valorile șirurilor nu depășesc constrângerile de lungime maximă
Validați formatele de dată și oră față de specificația API (ISO 8601 este standard: 2024-01-15T10:30:00Z)
Inspectați formatul antetului Authorization — token-urile Bearer trebuie prefixate cu Bearer , nu transmise brut

Pentru echipele care rulează servicii API pe Servere Dedicate, activarea jurnalizării detaliate a cererilor la nivelul aplicației (nu doar la nivelul serverului web) este esențială pentru diagnosticarea tiparelor 400 la scară.
Diagnosticarea erorilor 400 cu instrumentele pentru dezvoltatori ale browserului
Panoul Network al browserului este cel mai precis instrument de diagnostic disponibil pe partea clientului.

Deschideți DevTools (F12)
Navigați la fila Network
Reproduceți cererea care declanșează eroarea 400
Faceți clic pe cererea eșuată în cascadă
Inspectați fila Headers — revizuiți atât Request Headers, cât și Response Headers
Verificați fila Response pentru orice detaliu de eroare returnat de server

Panoul Request Headers va afișa exact ce a trimis browserul. Comparați aceasta cu ce se așteaptă serverul. Uitați-vă în special la:

Valoarea antetului Host

Prevenirea erorilor 400 în aplicațiile web

Pentru dezvoltatori și administratori de server, măsurile proactive reduc semnificativ incidența erorilor 400.

Sanitizarea și validarea datelor de intrare la nivelul aplicației — Validați toate datele de intrare furnizate de utilizator înainte ca acestea să ajungă la nivelul de rutare al serverului. Returnați răspunsuri 400 descriptive cu mesaje de eroare la nivel de câmp, mai degrabă decât eșecuri generice.

Implementați codificarea corectă a URL-urilor în codul client — Folosiți funcții de codificare integrate mai degrabă decât manipulare manuală a șirurilor:

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

Setați limite explicite și rezonabile pentru dimensiunea corpului — Nu lăsați client_max_body_size la valoarea implicită de 1 MB dacă aplicația dvs. acceptă încărcări de fișiere. De asemenea, nu îl setați la nelimitat — aceasta creează un vector de denial-of-service.

Monitorizați ratele de erori 400 în producție — O creștere bruscă a erorilor 400 este adesea primul indicator al unui bot care scanează pentru vulnerabilități, al unui formular defect pe partea clientului sau al unui deployment care a introdus o modificare incompatibilă a API-ului. Configurați alerte pentru rata de erori 4xx în stiva dvs. de monitorizare (Grafana, Datadog, CloudWatch).

Folosiți HTTPS cu un certificat SSL valid — Unele erori 400 apar când clienții trimit cereri HTTPS către un server care nu este configurat corect pentru TLS, sau când o nepotrivire de certificat face ca handshake-ul TLS să eșueze înainte ca nivelul HTTP să fie atins. Asigurarea că Certificatele SSL sunt valide, corect instalate și acoperă toate subdomeniile necesare elimină complet această clasă de erori.

Configurați corect mediile panoului de control — Dacă gestionați mai multe site-uri printr-un panou de control, definițiile de virtual host configurate greșit sunt o sursă frecventă de erori 400. Mediile care folosesc VPS cu cPanel ar trebui să verifice că rădăcina documentului, legarea SSL și regulile de rescriere ale fiecărui domeniu sunt corect delimitate pentru a evita contaminarea cererilor între domenii.

Matrice de decizie: diagnosticarea unei erori 400 după simptom

Listă de verificare tehnică: rezolvarea unei erori 400 Bad Request

Pentru utilizatorii finali:

• Inspectați și retastați manual URL-ul, corectând orice probleme de codificare
• Ștergeți cookie-urile și cache-ul specific pentru domeniul afectat
• Testați într-o fereastră privată/incognito pentru a exclude extensiile
• Goliți cache-ul DNS local
• Testați pe un alt browser, dispozitiv și conexiune de rețea

Pentru dezvoltatori și consumatori de API:

• Validați că Content-Type corespunde formatului corpului cererii
• Confirmați că toate câmpurile și antetele obligatorii sunt prezente și corect tipizate
• Verificați că valorile șirurilor, datele și tipurile numerice respectă contractul API
• Folosiți curl cu ieșire verbosă pentru a inspecta schimbul HTTP brut:

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

Pentru administratorii de server:

• Extrageți și filtrați jurnalele de erori ale serverului pentru intrările 400
• Validați sintaxa configurației serverului web (nginx -t / apachectl -t)
• Verificați client_max_body_size (Nginx) și LimitRequestBody (Apache)
• Revizuiți large_client_header_buffers în Nginx dacă cererile cu multe cookie-uri eșuează
• Auditați regulile WAF și verificați jurnalul de audit ModSecurity
• Verificați validitatea și acoperirea certificatului SSL/TLS
• Confirmați că regulile de rescriere .htaccess sunt corecte sintactic

—

Întrebări frecvente

Care este diferența dintre o eroare 400 și o eroare 404?

O eroare 400 înseamnă că serverul nu a putut înțelege cererea deoarece era malformată — vina este în modul în care a fost construită cererea. O eroare 404 înseamnă că cererea a fost validă și înțeleasă, dar resursa solicitată pur și simplu nu există pe server. Acestea necesită remedieri complet diferite.

Poate o eroare 400 Bad Request să fie cauzată de server, nu de client?

Da, indirect. O configurare greșită a serverului — cum ar fi o regulă WAF prea restrictivă, o setare Nginx large_client_header_buffers incorectă sau o directivă .htaccess defectă — poate face ca serverul să respingă cereri care sunt tehnic valide. În aceste cazuri, specificația HTTP este în continuare respectată (serverul respinge ceea ce percepe ca o cerere defectă), dar vina reală este în configurația serverului, nu în cererea clientului.

De ce ștergerea cookie-urilor rezolvă o eroare 400?

Cookie-urile sunt trimise în antetul de cerere Cookie la fiecare cerere către domeniul relevant. Dacă un cookie stocat în browser este malformat, expirat într-un mod pe care serverul nu îl acceptă sau a crescut prea mult (depășind limitele large_client_header_buffers în Nginx), serverul respinge întreaga cerere cu un 400 înainte de a o procesa. Ștergerea cookie-ului corupt elimină datele defecte din antet.

Cum remediez o eroare 400 la încărcarea fișierelor pe site-ul meu?

Încărcarea depășește fie limita de dimensiune a corpului serverului web, fie limita de dimensiune a încărcării PHP. Pe Nginx, măriți client_max_body_size în nginx.conf. Pe Apache, ajustați LimitRequestBody în .htaccess sau httpd.conf. Pentru aplicațiile PHP, actualizați upload_max_filesize și post_max_size în php.ini, asigurând că post_max_size este mai mare decât upload_max_filesize. Reporniți serviciile relevante după efectuarea modificărilor.

Cum pot determina dacă o eroare 400 provine de la un CDN sau WAF mai degrabă decât de la serverul meu de origine?

Verificați antetele de răspuns. Cloudflare adaugă antetele cf-ray și server: cloudflare. AWS CloudFront adaugă x-amz-cf-id. Dacă aceste antete sunt prezente în răspunsul 400, respingerea a avut loc la margine, nu la originea dvs. Revizuiți jurnalele WAF ale CDN-ului sau tabloul de bord al evenimentelor firewall pentru a identifica ce regulă a declanșat blocarea, apoi creați o excepție țintită pentru tiparul de trafic legitim.