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

Bir e-postadaki bağlantıyı ya da her gün girdiğiniz bir siteyi açıyorsunuz ve sayfa yerine beyaz bir ekranda kalın harflerle "400 Bad Request" yazısını görüyorsunuz. Bazen altında biraz daha bilgi veren ikinci bir satır (örneğin "Request Header Or Cookie Too Large"), en altta da "nginx" yazar. Chrome da bunun yerine kendi gri sayfasını gösterebilir: "Bu sayfa çalışmıyor" ve HTTP ERROR 400. Geliştiriciler aynı kodu bir API'den, çoğu zaman kısa bir JSON mesajıyla birlikte alır.

Bunların hepsinin anlamı aynıdır: sunucu bir istek almış ama onu kabul etmemiştir. Bu yazıda kodun ne anlama geldiğini, sayfayı kimin gönderdiğini, ziyaretçi tarafındaki nedenleri ve çözümleri, 400'ün 401, 403, 404 ve 413'ten farkını ve geliştiricilerin nelere bakması gerektiğini, kendi bilgisayarımızda yeniden ürettiğimiz bir örnekle anlatıyoruz.

400 Bad Request ne demek?#

400 Bad Request, sunucunun bir isteği hatalı bulduğu için işlemeyi reddettiği anlamına gelir. HTTP standardı RFC 9110 buna üç örnek verir: hatalı istek söz dizimi, geçersiz mesaj çerçevesi (mesajın nerede başlayıp bittiğinin yanlış bildirilmesi) ve aldatıcı istek yönlendirmesi. Sade bir dille söylersek adres, istek başlıkları ya da gönderilen veri, sunucunun uyguladığı kurallara uymamıştır.

400'lü kodlar sorunun istek tarafında olduğunu söyler; ama "istemci hatası" her zaman sizin bir hata yaptığınız anlamına gelmez: sitenin kendi koyduğu bir çerez, tarayıcınızın isteklerini fazla büyütebilir. Tanımdan bir kural da çıkar. MDN'nin başvuru sayfasının belirttiği gibi, değiştirilmeden tekrarlanan bir istek aynı hatayı alır; bu yüzden sayfayı yenilemek işe yaramaz, isteği değiştirmek ise işe yarar.

400 sayfasını kim gönderdi?#

Sayfadaki ikinci satır ve en alttaki ad, isteği hangi programın reddettiğini, çoğu zaman da nedenini söyler.

Chrome satırını kendi bilgisayarımızda, boş gövdeyle 400 döndüren küçük bir test sunucusu kurup Chromium 145'te açarak denedik: Türkçe arayüzde tam olarak bu satırlar ve bir Yeniden Yükle düğmesi çıktı. Bu metni Chrome kendisi yazar; bu yüzden nedene dair bir şey söylemez.

400 hatası adım adım nasıl oluşur?#

Bir isteğin üç bölümü vardır ve sunucu bunları sırayla denetler:

1. İstek satırı. Yöntem ve adres, örneğin GET /search?q=shoes. Adresteki özel karakterler, yüzde kodlaması denen yöntemle bir % işareti ve iki onaltılık (hexadecimal) rakam olarak taşınır; arkasında bu iki rakam olmayan bir % çözülemez.
2. Başlıklar. İsteğe eklenen Host ve User-Agent gibi bilgi satırları ve tarayıcının o site için tuttuğu bütün çerezleri taşıyan Cookie satırı. Sunucular her başlık satırına bir boyut sınırı koyar: nginx'te varsayılan 8 KB, Apache'de 8.190 bayt.
3. Gövde. Form ya da API verisi, çoğu zaman JSON; uygulama biçimini ve zorunlu alanları denetler.
4. Karar. Başarısız olan ilk denetim isteği 400 ile bitirir, çoğu zaman kısa bir gerekçeyle.
5. Tekrar. Hiçbir şey değişmediği için sonraki deneme aynı adresi, çerezleri ve veriyi gönderir ve aynı 400'ü alır.

400, 401, 403, 404 ve 413'ten nasıl ayrılır?#

400 genel koddur; durumu daha iyi anlatan bir kod varsa sunucular onu gönderir. 401, sunucunun isteği okuyabildiğini ama kimin gönderdiğini bilmek istediğini gösterir; bu durumu 401 Unauthorized Hatası Nedir, Nasıl Çözülür? yazısında anlattık. Sınırı aşan bir yükleme normalde 413 alır (nginx varsayılan olarak 1 MB istek gövdesi kabul eder), ama bazı uygulamalar bu durumda 400 döndürür.

Neden 400 Bad Request hatası alıyorum?#

Ziyaretçi açısından başlıca nedenler şunlardır:

• Yanlış yazılmış ya da bozulmuş bir adres. E-postalardan ve mesajlaşma uygulamalarından kopyalanan bağlantılar kesilebilir ya da araya fazladan karakterler girebilir; 50%off örneğindeki gibi arkasında iki onaltılık rakam olmayan bir % çözülemez.
• O site için fazla sayıda ya da fazla büyük çerez. "Request Header Or Cookie Too Large" mesajının arkasındaki neden budur.
• Bozuk ya da eskimiş bir çerez. Bir site giriş sistemini değiştirdikten sonra eski bir çerez, yeni kodun okuyamadığı bir değer taşıyabilir.
• İsteği değiştiren bir tarayıcı uzantısı, örneğin başlıkları ya da çerezleri düzenleyen bir uzantı.
• Arada çalışan bir program, nadiren de olsa: web trafiğini inceleyen bir güvenlik yazılımı ya da yanlış şemayla (adresin başındaki http:// ile https:// karıştırılarak) ya da yanlış portla kurulmuş bir proxy.

"Request Header Or Cookie Too Large" ne demek?#

Tarayıcınızın o site için tuttuğu çerezlerin, diğer başlıklarla birlikte sunucunun boyut sınırına artık sığmadığı anlamına gelir; bu yüzden nginx isteği 400 ile reddeder. Tarayıcınız her istekte bir sitenin bütün çerezlerini tek bir Cookie başlığında gönderir. nginx ise large_client_header_buffers belgesinde anlatıldığı gibi, bir tampondan (buffer) büyük her başlık satırını reddeder; varsayılan tampon boyutu 8 KB'tır.

İki tarafın sınırları birbirini tutmaz. Çerez standardı RFC 6265, tarayıcılardan çerez başına en az 4.096 bayt ve alan adı başına en az 50 çerez saklamalarını ister; bu, toplamda 8 KB'ın çok üstündedir. Çok sayıda analiz ve oturum çerezi kullanan bir site, birkaç haftalık olağan kullanımdan sonra bu sınırı aşabilir. Hata o zaman yalnız o sitede çıkar, çünkü bir siteye giden isteklerde yalnız o sitenin çerezleri taşınır.

IIS aynı durumu "HTTP 400 - Bad Request (Request header too long)" diye bildirir; bazı sunucular ise daha belirgin olan 431 kodunu gönderir. Sizin tarafınızdaki çözüm aynıdır: o sitenin çerezlerini silin.

Ziyaretçi olarak 400 hatası nasıl çözülür?#

Adımları sırayla deneyin; ilk üçü bir dakikanızı alır.

1. Adresi kontrol edin. Elle yeniden yazın ya da sitenin ana sayfasını açıp oradan ilerleyin. E-postadan gelen uzun bir bağlantıyı, ? işaretinden sonraki kısmı silerek deneyin.
2. Yalnız o sitenin çerezlerini silin. Bu işlem yalnız o sitedeki oturumunuzu kapatır, diğer sitelere dokunmaz.
   • Chrome: Diğer > Ayarlar > Gizlilik ve güvenlik > Üçüncü taraf çerezleri > Tüm site verilerini ve izinlerini göster yolunu izleyin, siteyi aratın, Sil'i seçin ve onaylayın (Google'ın adımları).
   • Edge: Ayarlar ve daha fazlası > Ayarlar > Gizlilik, arama ve hizmetler > Tanımlama Bilgileri > Tüm tanımlama bilgilerini ve site verilerini gör yolunu izleyin, siteyi aratın, yanındaki aşağı oka tıklayın ve Sil'i seçin.
   • Firefox: sitedeyken adres çubuğunun solundaki kalkan simgesine tıklayın, açılan panelde Çerezleri ve site verilerini temizle… seçeneğine tıklayın.
   • Mac'te Safari: Safari > Ayarlar > Gizlilik > Web Sitesi Verilerini Yönet yolunu izleyin, siteyi seçin ve Sil'e tıklayın.
3. Gizli pencerede deneyin. Chrome'da Diğer > Yeni Gizli pencere yolunu izleyin ya da Ctrl+Shift+N tuşlarına basın. Gizli pencere sitenin çerezleri olmadan açılır; uzantılar da siz izin vermedikçe orada çalışmaz. Sayfa açılıyorsa neden bir çerez ya da bir uzantıdır.
4. Uzantıları tek tek kapatın. Chrome'da Diğer > Uzantılar > Uzantıları yönet bölümüne gidin; içerik engelleyen ya da istekleri düzenleyen uzantılardan başlayın.
5. Hata dosya gönderirken çıkıyorsa dosyayı küçültün.
6. VPN'i ya da proxy'yi kapatarak veya mobil veriyle deneyin. Sayfa böyle açılıyorsa ilk bağlantınızdaki bir şey isteklerinizi değiştiriyordur.
7. Siteye bildirin. Adresi, saati ve neye tıkladığınızı yazın. Hata, çerezleri sildikten günler sonra geri geliyorsa site, kendi sunucusunun kabul ettiğinden fazla çerez koyuyordur.

DNS önbelleğini temizlemek ya da modemi yeniden başlatmak nadiren işe yarar: sunucu 400 ile cevap verdiğinde bilgisayarınız onu çoktan bulmuştur.

Kodunuz 400 alırsa nelere bakmalısınız?#

Kodda 400, sunucunun programınızın oluşturduğu isteği reddettiği anlamına gelir; cevabın gövdesi de çoğu zaman sorunlu alanı ya da kuralı adıyla söyler. Herhangi bir şeyi değiştirmeden önce gövdeyi kaydedin. Başlıca nedenler:

• Geçersiz JSON: sonda fazladan bir virgül, tek tırnak, elle birleştirilmiş bir metin. Dilinizin kodlayıcısını kullanın, örneğin JSON.stringify ya da json.dumps.
• Gövdeyle uyuşmayan bir Content-Type, örneğin form türüyle gönderilen JSON.
• Eksik ya da yanlış parametreler: atlanmış zorunlu bir alan, metin olarak gönderilmiş bir sayı, yanlış biçimde yazılmış bir tarih.
• Elle kurulan sorgu dizeleri. Adreste ? işaretinden sonra gelen bu kısımda, değerlerin içindeki boşluk, & ve % kodlanmalıdır; URLSearchParams ya da urllib.parse.urlencode bunu sizin yerinize yapar.
• Sunucunun kabul etmediği başlıklar. Büyük bir çerez ya da uzun bir token, başlık başına sınırı aşabilir: nginx'te 8 KB, Apache'de LimitRequestFieldSize, IIS'te MaxFieldLength. HTTP/1.1, Host başlığı eksik ya da iki kez gönderilmiş isteklere 400 verilmesini de şart koşar.
• HTTP/2'de HTTP/1.1 alışkanlıkları. HTTP/2 küçük harfli başlık adları ister ve Connection, Keep-Alive gibi bağlantıya özgü başlıkları yasaklar; sunucu böyle bir isteği sıfırlar ya da 400 ile cevaplar. Kod ya da bir proxy, HTTP/1.1 başlıklarını HTTP/2 isteğine taşıdığında bu sorun çıkar.

Hatalı JSON'a gelen 400'ü yeniden ürettik#

Kendi bilgisayarımızda, bir siparişin gövdesi geçerli JSON değilse 400 döndüren küçük bir Node.js sunucusu çalıştırdık. Sonra curl -i ile (-i, durum satırını ve başlıkları da yazdırır), gövdesinin sonunda fazladan virgül olan tek bir istek gönderdik:

curl -i http://127.0.0.1:18400/api/orders -H "Content-Type: application/json" -d '{"product": "sku-123", "qty": 2,}'

Çıktı (Windows 11'de curl 8.22, Node.js 24):

HTTP/1.1 400 Bad Request
Content-Type: application/json
Date: Thu, 12 Nov 2026 01:21:06 GMT
Connection: keep-alive
Keep-Alive: timeout=5
Transfer-Encoding: chunked

{"error":"invalid JSON","detail":"Expected double-quoted property name in JSON at position 32 (line 1 column 33)"}

Mesajdaki position 32, virgülün hemen ardından gelen } karakteridir: JSON, kapanan süslü parantezden önce virgüle izin vermez. Virgülü silerseniz gövde geçerli olur. Gerçek bir API mesajını başka sözcüklerle yazar, ama mantık aynıdır: durum satırı isteğin hatalı olduğunu, gövde ise nerede hatalı olduğunu söyler.

Arada proxy olunca ne değişir?#

Proxy doğru kurulmuşsa istekte hiçbir şey değişmez. https:// ile başlayan bir adres için istemci, proxy'den CONNECT isteğiyle bir tünel açmasını ister; proxy de baytları okumadan iki yönde aktarır. Bu yüzden geri gelen 400, sitenin isteğiniz hakkındaki kararıdır. Sık görülen bir kurulum hatası, şemanın portla uyuşmamasıdır: HTTPS bekleyen bir porta gelen düz http:// isteği, nginx'in "The plain HTTP request was sent to HTTPS port" cevabını alır. HTTPS Proxy kullanırken sunucu adını, portu ve şemayı Endpoint Oluşturucu'nun gösterdiği gibi aynen kopyalayın.

Scraper 400'ü nasıl ele almalı?#

Scraper (sitelerden otomatik veri toplayan program), 400'ü bir engel olarak değil, kendi isteğindeki bir hata olarak görmelidir. Değiştirilmeden tekrarlanan istek aynı 400'ü alır; bir Residential Proxy havuzu da sitenin gördüğü adresi değiştirir, kodunuzun gönderdiği isteği değil. Durun, isteği ve gövdeyi kaydedin, gövdenin işaret ettiği şeyi düzeltin.

Bazı kodlarda ise yeniden denemek doğrudur; örneğin 503 alındığında bir süre beklenip istek tekrarlanır. Hangi kodda yeniden deneneceğini, hangisinde durulacağını Scraping'de HTTP Hata Kodları yazısında topladık.

400 hatasıyla nerelerde karşılaşırsınız?#

• Her gün girdiğiniz bir sitede birden çıkan "Request Header Or Cookie Too Large" sayfasında.
• E-postalardan, mesajlaşma uygulamalarından ve bültenlerden gelen, yolda kesilmiş uzun bağlantılarda.
• Boyut sınırını sayfada belirtmeyen dosya yükleme formlarında.
• Kurulumu hatalı uygulamalardaki Google hesabıyla giriş düğmelerinde, "Error 400" koduyla.
• Bir alanın adı ya da türü değiştikten sonra betiklerden, Postman'den ve kodsuz araçlardan yapılan API çağrılarında.

Sık yapılan hatalar#

• Bütün tarama verilerini temizlemek. Bu, her siteden çıkış yapmanıza yol açar; önemli olan yalnız hata veren sitenin çerezleridir.
• Sayfayı tekrar tekrar yenilemek. İstek değişmediği için cevap da değişmez.
• Suçu bağlantıya atmak. 400, isteğin sunucuya ulaştığını gösterir.
• Geliştiriciler: 400 alan isteği döngüde yeniden denemek ya da 400 alınca IP adresi değiştirmek; durum kodunu cevabın gövdesi olmadan kaydetmek.
• Site sahipleri: çerezleri azaltmak yerine başlık sınırlarını yükseltmek. Çerez standardı da sunuculara çerezleri az ve küçük tutmalarını önerir.

Karar rehberi#

Sıkça sorulan sorular#

400 hatası benden mi kaynaklanıyor, siteden mi?#

İkisi de olabilir; kod yalnız isteğin hatalı olduğunu söyler. Yazım hatası ya da bir uzantı sizin tarafınızdadır, fazla büyümüş bir çerezi ise sitenin kendisi koymuştur. Bir API'den gelen 400 de onu çağıran koddaki bir hatadır.

Neden yalnız bir sitede 400 Bad Request alıyorum?#

Çünkü neden çoğu zaman o sitenin çerezlerinde ya da sınırlarındadır: her site yalnız kendi çerezlerini alır ve kendi boyut sınırını koyar. O sitenin çerezlerini silin; gizli pencerede de aynı hata çıkıyorsa sorunu site düzeltmelidir.

VPN ya da proxy 400 hatasına yol açar mı?#

Nadiren. VPN de, HTTPS trafiğini tünelle taşıyan bir proxy de isteğinizi değiştirmeden iletir; 400'ü gönderen sitedir. Hata yalnız proxy açıkken çıkıyorsa önce şemayı ve portu kontrol edin; trafiği inceleyen güvenlik yazılımları da başlıkları değiştirebilir.

iPhone'da ya da Android'de 400 Bad Request hatası nasıl düzeltilir?#

Android'de siteyi Chrome'da açın, adres çubuğunun solundaki Sayfa bilgileri simgesine dokunun, Çerezler ve site verileri'ni açın ve kayıtlı verilerin yanındaki Sil'e dokunun. iPhone'da önce sayfayı gizli bir sekmede deneyin; orada açılıyorsa Ayarlar > Uygulamalar > Safari > Gelişmiş > Web Sitesi Verileri > Tüm Web Sitesi Verilerini Sil sorunu giderir, ama bütün sitelerdeki oturumlarınızı kapatır.

Postman'de neden 400 Bad Request alıyorum?#

Çoğu zaman sorun gövdede ya da gövdenin türündedir. Gövde raw moduna ve JSON türüne ayarlıysa Postman uygun Content-Type başlığını kendisi ekler, ama sizin elle girdiğiniz bir Content-Type onun yerine geçer. JSON'u ve zorunlu parametreleri kontrol edin, sonra cevabın gövdesini okuyun.

"Error 400: redirect_uri_mismatch" ne demek?#

Bir uygulama sizi Google hesabıyla girişe yönlendirdiğinde çıkar: uygulamanın Google'a verdiği dönüş adresi (redirect URI), o uygulama için kayıtlı adreslerin hiçbiriyle eşleşmiyordur. Bunu yalnız uygulamanın geliştiricisi, uygulamanın Google Cloud ayarlarından düzeltebilir.

Özet#

400 Bad Request, sunucunun isteğinizi aldığını ama olduğu hâliyle kabul etmediğini gösterir. Ziyaretçiyseniz adresi kontrol edin, yalnız o sitenin çerezlerini silin, gizli pencerede deneyin ve uzantıları kapatın. Geliştiriciyseniz cevabın gövdesini okuyun, JSON'u, başlıkları ya da parametreleri düzeltin ve 400 alan bir isteği değiştirmeden yeniden denemeyin. İzleme ve veri toplama işleriniz için proxy türlerini proxy sayfamızda karşılaştırabilirsiniz.