400 Bad Request Hatası: Nedir ve Nasıl Çözülür?

400 Bad Request Hatası Nedir?

400 Bad Request (Hatalı İstek), sunucunun isteğinizi aldığı ancak isteğin kendisinde bir şey yanlış göründüğü için onu işlemeyeceği anlamına gelen bir HTTP durum kodudur. HTTP standardı (RFC 9110, bölüm 15.5.1) bunu, sunucunun bir isteği "due to something that is perceived to be a client error" (istemci hatası olarak algılanan bir şey nedeniyle) işleyemediği veya işlemek istemediği durum olarak tanımlar; bozuk söz dizimi, geçersiz mesaj çerçeveleme ya da yanıltıcı istek yönlendirme bunun örnekleridir.

Sunucunun bozulduğunu gösteren 500 hatasının aksine, 400 parmağını isteğe doğrultur: tarayıcınızın veya uygulamanızın gönderdiği URL'ye, başlıklara, çerezlere ya da verilere. Web sitesi genellikle diğer herkes için sorunsuz çalışıyordur.

Bu, ziyaretçiler için iyi haberdir, çünkü çözüm çoğunlukla sizin tarafınızdadır ve bir dakika sürer: 400 hatalarının çoğunun arkasında yanlış yazılmış bir bağlantı ya da bozulmuş bir çerez vardır.

400 Hatası Nasıl Görünür

Mesaj sunucu yazılımına göre değişir ve sayfadaki ek metin çoğu zaman nedenin en iyi ipucudur:

400 Bad Request Hatasına Ne Neden Olur?

• Hatalı biçimlendirilmiş bir URL. Fazladan bir % işareti, bir boşluk, kodlanması gereken bir karakter ya da kesilmiş veya iki kez yapıştırılmış bir bağlantı.

• Bozulmuş veya fazla büyük çerezler. Çok sayıda çerez yerleştiren siteler (oturum açma, A/B testleri, analiz araçları) Cookie başlığını sunucunun limitinin üzerine çıkarabilir. Bir güncelleme sırasında zarar gören bir çerez de reddedilebilir.

• Fazla büyük istek başlıkları. Çerezlerin yanı sıra uzun kimlik doğrulama belirteçleri ya da uzantıların ve proxy'lerin eklediği başlıklar da toplam boyutu büyütür.

• Bir API'ye gönderilen geçersiz veriler. Eksik zorunlu alanlar, bozuk JSON ya da yanlış Content-Type başlığı.

• HTTPS portuna gönderilen HTTP. Yük dengeleyicilerin ve ters proxy'lerin arkasında yaygındır.

• Fazla büyük bir dosya. Birçok sunucu 413 Content Too Large yanıtı verir, ancak bazı uygulamalar ve çatılar bunun yerine 400 döndürür.

Çözüm 1: URL'yi Kontrol Edin

Adres çubuğuna dikkatlice bakın. Dikkat etmeniz gereken sorunlar:

• Ardından iki onaltılık karakter gelmeyen bir % (%20 sorunsuzdur, %2 veya %zz değildir).

• Boşluklar, { }, |, \ ya da diğer olağandışı karakterler; özellikle e-postalardan, PDF'lerden veya sohbet uygulamalarından kopyalanan bağlantılarda.

• İki kez yapıştırılmış (https://example.com/https://example.com/...) ya da yarıda kesilmiş bir bağlantı.

• İzleme parametreleri içeren çok uzun bir URL. ? işaretinden sonraki her şeyi silip yeniden deneyin.

Başka bir siteden gelen bir bağlantıyı izlediyseniz, bunun yerine sitenin ana sayfasına gidin ve sayfaya oradan ulaşın.

Çözüm 2: Yalnızca O Sitenin Çerezlerini Temizleyin

Bu adım, daha önce kullandığınız sitelerdeki 400 hatalarının çoğunu çözer; özellikle de mesaj, "too large" (çok büyük) veya "too long" (çok uzun) olan çerezlerden ya da başlıklardan bahsediyorsa. Tüm sitelerin çerezlerini silmenize gerek yok, yalnızca bu sitenin çerezlerini silin:

• Chrome / Edge: adres çubuğunun solundaki simgeye tıklayın → Çerezler ve site verileri (veya Site ayarları) → sitenin verilerini silin, ardından sayfayı yenileyin.

• Firefox: asma kilit simgesine tıklayın → Çerezleri ve site verilerini temizle…

• Safari (Mac): Safari → Ayarlar → Gizlilik → Web Sitesi Verilerini Yönet… → siteyi arayın → Sil.

• iPhone: Ayarlar → Uygulamalar → Safari → İleri Düzey → Web Sitesi Verileri → silmek için sitenin üzerinde sola kaydırın.

Çözüm 3: Gizli Pencereyi Deneyin, Ardından Önbelleği Temizleyin

Sayfayı bir Gizli/Özel pencerede açın (Chrome ve Edge'de Ctrl + Shift + N, Firefox'ta Ctrl + Shift + P, Safari'de Cmd + Shift + N). Gizli pencereler çerezsiz ve uzantısız başlar; sayfa orada çalışıyorsa Çözüm 2 veya Çözüm 4 sorunu kalıcı olarak giderir.

Gizli pencerede de hata alıyorsanız tarayıcı önbelleğini temizleyin (Ctrl + Shift + Delete → Önbelleğe alınan resimler ve dosyalar), son adım olarak da DNS önbelleğinizi temizleyin. DNS nadiren 400 hatasının nedenidir, ancak bir site sunucu değiştirdikten sonra eskimiş bir adres sizi isteğinizi reddeden bir sunucuya götürebilir.

Çözüm 4: Uzantıları Devre Dışı Bırakın ve Dosya Boyutlarını Kontrol Edin

Gizlilik araçları, başlık düzenleyiciler, kupon bulucular ve bazı reklam engelleyiciler gibi istekleri değiştiren uzantılar, başlıkları sunucunun reddedeceği şekilde ekleyebilir veya değiştirebilir. Hepsini devre dışı bırakın, sayfayı yenileyin, ardından suçluyu bulmak için onları teker teker yeniden açın.

Hata dosya yüklerken çıkıyorsa daha küçük bir dosya deneyin. Görselleri sıkıştırın veya büyük dosyaları bölün. Böylece sunucu bunu 413 yerine 400 olarak bildirse bile boyutu reddedip reddetmediğini anlarsınız.

Web Sitesi Sahipleri İçin: 400 Hatalarının Nedenini Bulmak

Kullanıcılar sitenizde 400 hatası bildiriyorsa işe gördükleri mesajın tam metniyle ve sunucu günlüklerinizle başlayın. nginx ve Apache nedeni info düzeyinde kaydeder; göremiyorsanız hata günlüğü düzeyini geçici olarak yükseltin. Erişim günlüğü ise hangi URL'lerin 400 döndürdüğünü gösterir. DNS Robot'un HTTP Başlık Kontrolü aracı bir sayfanın durum kodunu, sunucu yazılımını ve gönderdiği her Set-Cookie başlığını gösterir; bu da sürekli büyüyen çerezleri fark etmenize yardımcı olur.

# Hangi istekler 400 alıyor? (nginx combined günlük biçimi)
sudo awk '$9 == 400 {print $7}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head

# nginx'in kaydettiği nedenler (error_log ... info; gerektirir)
sudo grep -i "client sent\|too large\|bad request" /var/log/nginx/error.log | tail -20

"Request Header Or Cookie Too Large" Hatası

nginx, istek başlıklarını large_client_header_buffers ile ayarlanan arabelleklere okur; varsayılan değer 8 KB'lık 4 arabellektir. Tek bir arabelleğe sığmayan tek bir başlık satırı (genellikle Cookie başlığı) bu 400 hatasını tetikler. Apache'deki karşılığı LimitRequestFieldSize limitidir ve varsayılan değeri 8.190 bayttır.

Doğru çözüm daha az veri göndermektir: artık ihtiyacınız olmayan çerezleri kaldırın, oturum çerezlerini küçük tutun ve çerezleri yalnızca onları kullanan yollar ve alt alan adlarıyla sınırlayın. Gerçekten daha büyük başlıklara ihtiyacınız varsa (örneğin büyük çoklu oturum açma belirteçleri için) limiti yükseltin:

# nginx (http veya server bloğu)
large_client_header_buffers 4 16k;

# Apache karşılığı (httpd.conf / vhost)
# LimitRequestFieldSize 16380

"The plain HTTP request was sent to HTTPS port" Hatası

nginx, bir şey TLS beklediği bir porta (genellikle 443) düz HTTP gönderdiğinde bu 400 hatasını döndürür. Tipik nedenler: http:// trafiğini 443 portuna ileten bir yük dengeleyici veya proxy, http://example.com:443 içeren bir bağlantı ya da bir portun gerekmediği hâlde TLS beklemesine yol açan eski bir ssl on; ayarı.

Her listen satırının o porta gelen trafikle eşleştiğinden emin olun: HTTPS için listen 443 ssl;, düz HTTP için listen 80; ve 80'den 443'e bir yönlendirme. Önündeki proxy'nin de 443 portuyla HTTPS (ya da 80 portuyla HTTP) konuştuğundan emin olun.

API'lerden Gelen 400 Hataları

API'ler doğrulamadan geçemeyen istekler için 400 kullanır. Bir API çağırıyorsanız yanıt gövdesini okuyun, çünkü çoğu API hangi alanın yanlış olduğunu açıklar. Ardından geçerli JSON gönderdiğinizi, doğru Content-Type: application/json başlığını eklediğinizi ve tüm zorunlu parametreleri gönderdiğinizi kontrol edin.

Bir API geliştiriyorsanız sorunu adıyla belirten bir gövde döndürün (örneğin {"error": "email is required"}). Biçimi doğru ama anlamsal olarak geçersiz istekler için 422 Unprocessable Content kodunu kullanmayı düşünün, 400'ü ise hiç ayrıştırılamayan isteklere bırakın.

400 ile 401, 403, 404, 413, 429 ve 431 Arasındaki Fark

Komşu hatalar için rehberlerimiz: 403 Forbidden, 401 Unauthorized ve 429 Too Many Requests. Başarısız olmak yerine döngüye giren yönlendirmeler için ERR_TOO_MANY_REDIRECTS rehberine bakın; Yönlendirme Kontrolü aracı da her yönlendirme adımını gösterir.