400 Bad Request Hatası Nedir ve Nasıl Düzeltilir?

Bir 400 Bad Request, RFC 9110’da tanımlanan HTTP/1.1 istemci hatası durum kodudur ve sunucunun, bozuk biçimli olduğu için işleyemeyeceği veya işlemeyeceği bir istek aldığını bildirir. Sunucu tarafında kaynaklanan 5xx hatalarının aksine, 400 hatası hatayı tamamen istemciye yükler — yani sorun, sunucunun yanıt verme kapasitesinde değil, gönderilen isteğin kendisindedir.

Pratik açıdan bakıldığında, 400 hatası sunucu isteği yerine getirmeye çalışmadan önce tetiklenir. Sunucu gelen HTTP mesajını ayrıştırır, yapısal veya anlamsal olarak geçersiz bir şey tespit eder — bozuk bir başlık, hatalı biçimli bir URI, aşırı büyük bir yük, hatalı bir çerez — ve devam etmek yerine hemen 400 Bad Request döndürür. Bu ayrımı bilmek, doğru teşhise giden en hızlı yoldur.

400 Durum Kodunun Protokol Düzeyinde Gerçekte Ne Anlama Geldiği

HTTP, katı bir istek-yanıt sözleşmesi üzerine çalışır. Her isteğin HTTP spesifikasyonunda tanımlanan dilbilgisine uyması gerekir. Bir istemci bu dilbilgisini ihlal eden bir mesaj gönderdiğinde, sunucunun bunu 400 yanıtıyla reddetmesine hem izin verilir hem de bu beklenir.

Sunucu, 400’ü kendi hatası olarak kaydetmez. Bunu reddedilen bir istemci isteği olarak kaydeder. Bu nedenle bir sunucuyu körü körüne yeniden başlatmak veya CDN önbelleğini temizlemek gerçek bir 400’ü nadiren düzeltir — temel neden neredeyse her zaman isteğin oluşturulmasındadır.

Bu hatanın tarayıcıda görüntülenen yaygın varyantları şunlardır:

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

Bunların tümü aynı temel HTTP durum koduna karşılık gelir. İfade biçimi sunucu yazılımına (Apache, Nginx, IIS, Cloudflare) ve uygulama çerçevesine göre farklılık gösterir.

400 Bad Request Hatasının Temel Nedenleri

Herhangi bir düzeltme denemesinden önce kesin tetikleyiciyi anlamak şarttır. Nedenler iki kategoriye ayrılır: istemci tarafı ve sunucu tarafı yanlış yapılandırma.

İstemci Tarafı Nedenler

Hatalı biçimlendirilmiş veya yanlış kodlanmış URL

Kodlanmamış boşluklar, geçersiz karakterler veya bozuk yüzde kodlama dizileri içeren bir URL hemen reddedilir. HTTP spesifikasyonu, ayrılmamış küme dışındaki tüm karakterlerin (A–Z, a–z, 0–9, -, _, ., ~) iletimden önce yüzde kodlanmasını gerektirir.

Bozuk veya aşırı büyük çerezler

Çerezler Cookie istek başlığında iletilir. Bir çerez değeri hatalı biçimlendirilmişse, tarayıcının çerez başına boyut sınırını (genellikle 4096 bayt) aşıyorsa veya RFC 6265’i ihlal eden karakterler içeriyorsa, sunucu isteğin tamamını reddedebilir. Bu, daha önce sorunsuz ziyaret edilen sitelerde aralıklı 400 hatalarının en sık gözden kaçan nedenlerinden biridir.

Geçersiz veya eksik zorunlu istek başlıkları

Bazı API’ler ve web uygulamaları katı başlık doğrulaması uygular. POST isteğinde eksik Content-Type, hatalı biçimlendirilmiş Authorization başlığı veya desteklenmeyen medya türüne sahip Accept başlığı 400 tetikleyebilir.

Aşırı büyük istek yükü

Web sunucuları ve ters proxy’ler maksimum gövde boyutu sınırları uygular. Nginx client_max_body_size kullanır (varsayılan: 1 MB); Apache LimitRequestBody kullanır. Bu eşiklerin aşılması, yapılandırmaya bağlı olarak 400 veya 413 yanıtı üretir.

Eski veya yanlış DNS önbelleği

DNS çözümleme hataları genellikle HTTP 400 yerine bağlantı hataları üretse de, bir isteği yanlış sunucuya yönlendiren — Host başlığını tanımayan — zehirlenmiş veya eski bir DNS önbelleği, yanlış kaynaktan 400 döndürülmesine yol açabilir.

İstek başlıklarına müdahale eden tarayıcı uzantıları

Belirli reklam engelleyiciler, gizlilik araçları ve geliştirici uzantıları giden HTTP başlıklarını değiştirir. Bir uzantı hatalı biçimlendirilmiş veya yinelenen bir başlık eklerse, sunucu isteği reddedebilir.

Sunucu Tarafı Nedenler

Yanlış yapılandırılmış .htaccess kuralları (Apache)

Sözdizimi hataları içeren yeniden yazma kuralları, yönlendirme direktifleri veya erişim denetimi girişleri, Apache’nin istek uygulama katmanına ulaşmadan önce 400 üretmesine neden olabilir.

Nginx yapılandırma hataları

Geçersiz server_name direktifleri, bozuk location blokları veya yanlış proxy_pass ayarları, Nginx’in yönlendiremediği istekler için 400 döndürmesine neden olabilir.

WAF veya güvenlik eklentisinin aşırı engelleme yapması

Web Uygulama Güvenlik Duvarları — sunucu düzeyinde (ModSecurity), CDN düzeyinde (Cloudflare WAF) veya uygulama düzeyinde (WordPress güvenlik eklentileri) olsun — meşru istekleri kötü amaçlı olarak işaretleyip 400 veya 403 döndürebilir. Bu durum, istek parametrelerinin SQL enjeksiyonu veya XSS imzalarıyla eşleşen dizeler içermesi durumunda yaygındır.

Uygulama düzeyinde doğrulama hataları

Laravel, Django veya Express.js gibi çerçeveler, giriş doğrulaması başarısız olduğunda 400 döndürür — örneğin zorunlu bir JSON alanı eksikse, tarih alanı yanlış biçimdeyse veya sayısal bir parametre dize değeri alıyorsa.

400 Bad Request Hatası Nasıl Düzeltilir: İstemci Tarafı Adımlar

1. URL’yi Doğrulayın ve Düzeltin

URL’yi karakter karakter inceleyin. Özellikle şunlara dikkat edin:

• Kodlanmamış boşluklar: Boşluk %20 olmalıdır, gerçek boşluk veya + (form verisi dışında) olmamalıdır.
• Çift eğik çizgi veya eksik eğik çizgi: https://example.com//path veya sondaki soru işaretiyle https://example.com/path?.
• Bozuk yüzde kodlama: Tam olarak iki onaltılık rakamla takip edilmeyen % geçersizdir.
• ASCII dışı karakterler: Unicode karakterler içeren alan adları Punycode kullanmalıdır; Unicode içeren yol segmentleri UTF-8 ile yüzde kodlanmalıdır.

Doğru kodlanmış bir URL şöyle görünür:

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

Şöyle değil:

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

2. Tarayıcı Çerezlerini ve Önbelleğini Temizleyin

Bu işlem, kullanıcının daha önce ziyaret ettiği sitelerde karşılaşılan 400 hatalarının büyük çoğunluğunu çözer.

Google Chrome:

chrome://settings/clearBrowserData açın
Zaman aralığını Tüm zamanlar olarak ayarlayın
Çerezler ve diğer site verileri ile Önbelleğe alınmış resimler ve dosyalar seçeneklerini işaretleyin
Verileri temizle düğmesine tıklayın

Mozilla Firefox:

about:preferences#privacy açın
Çerezler ve Site Verileri altında Verileri Temizle seçeneğine tıklayın
Her iki seçeneği de işaretleyin ve onaylayın

Safari (macOS):

Safari > Ayarlar > Gizlilik bölümüne gidin
Web Sitesi Verilerini Yönet seçeneğine, ardından Tümünü Kaldır seçeneğine tıklayın

Tüm oturum verilerini kaybetmek istemediğinizde daha hedefli bir yaklaşım için tarayıcının geliştirici araçlarını kullanarak yalnızca belirli alan adına ait çerezleri silin:

DevTools’u açın (F12 veya Cmd+Option+I)
Uygulama > Depolama > Çerezler bölümüne gidin
Alan adını seçin ve tek tek çerezleri silin

3. DNS Önbelleğini Temizleyin
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
Temizledikten sonra yeniden denemeden önce çözümlemenin doğru olduğunu doğrulayın:
nslookup example.com
4. Tarayıcı Uzantılarını Devre Dışı Bırakın
HTTP başlıklarını değiştiren uzantılar en olası suçlulardır. Tüm uzantıları aynı anda devre dışı bırakmak yerine önce tarayıcının gizli veya özel modunu kullanın — çoğu uzantı özel pencerelerde varsayılan olarak devre dışıdır. Sayfa gizli modda doğru yükleniyorsa, bir uzantı sorumludur.
Chrome’da belirli uzantıyı tespit etmek için:

chrome://extensions/ adresine gidin
Tüm uzantıları devre dışı bırakın
Her birinin ardından sayfayı yeniden yükleyerek tek tek yeniden etkinleştirin

5. Farklı Bir Tarayıcı, Cihaz veya Ağda Test Edin
Bu adım, sorunun ortama özgü olup olmadığını hızla belirler. Sayfa hücresel veri kullanan bir mobil cihazda yükleniyorsa ancak masaüstünüzde yüklenmiyorsa, sorun muhtemelen yereldir — tarayıcı yapılandırması, ağ düzeyinde proxy veya istek başlıklarını değiştiren kurumsal güvenlik duvarı olabilir.
400 Bad Request Hatası Nasıl Düzeltilir: Sunucu Tarafı Adımlar
Bu adımlar, sunucuya veya barındırma kontrol paneline erişimi olan web sitesi sahipleri, geliştiriciler ve sistem yöneticileri için geçerlidir.
6. Sunucu Erişim ve Hata Günlüklerini Analiz Edin
Sunucu günlükleri kesin tanı aracıdır. Erişim günlüğündeki bir 400 girişi, reddedilen ham istek satırını gösterecektir.
Nginx hata günlüğü (varsayılan yol):
tail -n 100 /var/log/nginx/error.log | grep " 400 "
Apache hata günlüğü:
tail -n 100 /var/log/apache2/error.log
Nginx erişim günlüğü — 400 yanıtlarını filtrele:
awk '$9 == 400' /var/log/nginx/access.log | tail -20
Kalıpları arayın: 400’ler belirli bir uç noktadan, belirli bir kullanıcı aracısından veya belirli bir parametreden mi geliyor? Bu, temel nedeni önemli ölçüde daraltır.
Bir VPS Hosting ortamı çalıştırıyorsanız, bu günlüklere doğrudan SSH erişiminiz vardır. Yönetilen Shared Web Hosting hizmetlerinde erişim günlüklerine genellikle cPanel’in Hatalar bölümünden veya Ham Erişim günlüğü indirmesi aracılığıyla ulaşılabilir.
7. .htaccess Dosyasını Denetleyin (Apache)
.htaccess dosyasındaki tek bir sözdizimi hatası, Apache’nin her istek için 400 veya 500 hatası döndürmesine neden olabilir. Apache’yi yeniden başlatmadan dosya sözdizimini doğrulayın:
apachectl -t
400 hatası üreten yaygın .htaccess sorunları:

Kaçış karakteri kullanılmamış özel karakterler içeren RewriteRule kalıpları
Beklenmedik düşük değere ayarlanmış LimitRequestBody

1. Hatalı biçimlendirilmiş Header direktifleri

Sorunlu direktif örneği:

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

Düzeltilmiş sürüm:

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

8. Nginx Yapılandırmasını Kontrol Edin

Değişiklikleri uygulamadan önce tüm Nginx yapılandırmasını doğrulayın:

nginx -t

Kullanıcılar dosya yüklüyorsa client_max_body_size ayarına dikkat edin:

http {
    client_max_body_size 50M;
}

Ayrıca large_client_header_buffers ayarını da gözden geçirin — istek başlıkları (çerezler dahil) arabellek boyutunu aşarsa Nginx 400 döndürür:

http {
    large_client_header_buffers 4 16k;
}

Düzenledikten sonra kesinti olmadan yeniden yükleyin:

nginx -s reload

9. Dosya Yükleme Sınırlarını Artırın

400 hatası özellikle dosya yüklemeleri sırasında oluşuyorsa, istek gövdesi muhtemelen sunucunun yapılandırılmış sınırını aşıyordur.

PHP (php.ini):

upload_max_filesize = 50M
post_max_size = 55M

Apache (httpd.conf veya .htaccess):

LimitRequestBody 52428800

Nginx (nginx.conf):

client_max_body_size 50M;

PHP’de post_max_size değerinin her zaman upload_max_filesize değerinden büyük olması gerektiğini unutmayın; aksi takdirde PHP yüklemeyi sessizce atar ve uygulama 400 döndürebilir.

10. WAF Kurallarını ve Güvenlik Eklentilerini Gözden Geçirin

ModSecurity, Cloudflare WAF veya bir WordPress güvenlik eklentisi (Wordfence, iThemes Security) çalıştırıyorsanız, WAF kural setini geçici olarak devre dışı bırakın ve 400’ün kaybolup kaybolmadığını test edin. Kayboluyorsa, hangi kuralın tetiklendiğini belirlemek için WAF denetim günlüğünü inceleyin:

tail -f /var/log/modsec_audit.log

WAF’ı kalıcı olarak devre dışı bırakmayın. Bunun yerine, engellenen meşru istek kalıbı için hedefli bir istisna oluşturun.

400 Bad Request ile İlgili HTTP Hata Kodları Karşılaştırması

400’ün HTTP hata sınıflandırmasındaki yerini anlamak yanlış teşhisi önler.

Durum Kodu	Ad	Hata Konumu	Tipik Neden
—	—	—	—
400	Bad Request	İstemci	Hatalı istek sözdizimi, geçersiz başlıklar, hatalı kodlama
401	Unauthorized	İstemci	Eksik veya geçersiz kimlik doğrulama bilgileri
403	Forbidden	Sunucu politikası	Geçerli istek, ancak sunucu kuralları erişimi reddediyor
404	Not Found	Sunucu	İstenen URI’de kaynak mevcut değil
413	Content Too Large	İstemci	İstek gövdesi sunucunun yapılandırılmış boyut sınırını aşıyor
414	URI Too Long	İstemci	İstek URI’si sunucunun maksimum URI uzunluğunu aşıyor
422	Unprocessable Content	İstemci	Sözdizimsel olarak geçerli ancak anlamsal olarak hatalı (REST API’lerinde yaygın)
431	Request Header Fields Too Large	İstemci	Tek tek veya toplam başlık boyutu sunucu sınırlarını aşıyor
500	Internal Server Error	Sunucu	Sunucuda işlenmeyen istisna veya yanlış yapılandırma
502	Bad Gateway	Sunucu/Proxy	Yukarı akış sunucusu geçersiz yanıt döndürdü

Önemli bir operasyonel ayrım: 413 (Content Too Large), aşırı büyük yüklemeler için anlamsal olarak daha kesin koddur; ancak birçok sunucu — özellikle eski Apache ve Nginx yapılandırmaları — bunun yerine 400 döndürür. Dosya yüklemesinde 400 görürseniz, önce gövde boyutu sınırlarını kontrol edin.

API Bağlamlarında 400 Hataları

REST ve GraphQL API’leri, giriş doğrulama hataları için standart yanıt olarak 400’ü yaygın biçimde kullanır. Bir API oluşturuyor veya tüketiyorsanız, 400 yanıt gövdesi genellikle yapılandırılmış bir hata yükü içerir:

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

API 400 hatalarını ayıklarken:

Content-Type başlığının gövde biçimiyle eşleştiğini doğrulayın (JSON yükleri için application/json, dosya yüklemeleri için multipart/form-data)
Zorunlu alanların mevcut olduğunu ve doğru türde olduğunu onaylayın
Dize değerlerinin maksimum uzunluk kısıtlamalarını aşmadığını kontrol edin
Tarih ve saat biçimlerini API spesifikasyonuna göre doğrulayın (ISO 8601 standarttır: 2024-01-15T10:30:00Z)
Authorization başlık biçimini inceleyin — Bearer token’ların ham olarak değil, Bearer  önekiyle gönderilmesi gerekir

Dedicated Servers üzerinde API hizmetleri çalıştıran ekipler için, yalnızca web sunucusu katmanında değil uygulama katmanında da ayrıntılı istek günlüğü kaydını etkinleştirmek, 400 kalıplarını ölçekte teşhis etmek açısından kritik öneme sahiptir.
Tarayıcı Geliştirici Araçlarıyla 400 Hatalarını Teşhis Etme
Tarayıcının Ağ paneli, mevcut en kesin istemci tarafı tanı aracıdır.

DevTools’u açın (F12)
Ağ sekmesine gidin
400’ü tetikleyen isteği yeniden oluşturun
Şelale görünümünde başarısız olan isteğe tıklayın
Başlıklar sekmesini inceleyin — hem İstek Başlıkları hem de Yanıt Başlıkları‘nı gözden geçirin
Sunucu tarafından döndürülen hata ayrıntıları için Yanıt sekmesini kontrol edin

İstek Başlıkları paneli, tarayıcının tam olarak ne gönderdiğini gösterir. Bunu sunucunun beklentileriyle karşılaştırın. Özellikle şunlara bakın:

Host başlık değeri
Cookie başlık boyutu ve içeriği
POST/PUT istekleri için Content-Type ve Content-Length

Web Uygulamalarında 400 Hatalarını Önleme

Geliştiriciler ve sunucu yöneticileri için proaktif önlemler, 400 hatalarının görülme sıklığını önemli ölçüde azaltır.

Uygulama katmanında girdi temizleme ve doğrulama — Kullanıcı tarafından sağlanan tüm girdileri sunucunun yönlendirme katmanına ulaşmadan önce doğrulayın. Genel hatalar yerine alan düzeyinde hata mesajları içeren açıklayıcı 400 yanıtları döndürün.

İstemci kodunda uygun URL kodlamasını uygulayın — Manuel dize işleme yerine yerleşik kodlama işlevlerini kullanın:

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

Açık ve makul gövde boyutu sınırları belirleyin — Uygulamanız dosya yüklemelerini kabul ediyorsa client_max_body_size değerini varsayılan 1 MB’ta bırakmayın. Aynı şekilde sınırsız olarak da ayarlamayın — bu, hizmet reddi saldırısı vektörü oluşturur.

Üretimde 400 oranlarını izleyin — 400 hatalarında ani bir artış, genellikle güvenlik açıklarını tarayan bir bot, bozuk bir istemci tarafı form veya kırıcı bir API değişikliği getiren bir dağıtımın ilk göstergesidir. İzleme yığınınızda (Grafana, Datadog, CloudWatch) 4xx hata oranı için uyarı kurun.

Geçerli SSL sertifikasıyla HTTPS kullanın — Bazı 400 hataları, istemcilerin TLS için düzgün yapılandırılmamış bir sunucuya HTTPS isteği göndermesinden veya HTTP katmanına ulaşılmadan önce TLS el sıkışmasının başarısız olmasına neden olan sertifika uyumsuzluğundan kaynaklanır. SSL Sertifikaları‘nızın geçerli, doğru kurulmuş ve gerekli tüm alt alan adlarını kapsadığından emin olmak bu hata sınıfını tamamen ortadan kaldırır.

Kontrol paneli ortamlarını doğru yapılandırın — Birden fazla siteyi kontrol paneli aracılığıyla yönetiyorsanız, yanlış yapılandırılmış sanal ana bilgisayar tanımları 400 hatalarının yaygın bir kaynağıdır. VPS with cPanel kullanan ortamlar, etki alanları arası istek kirliliğini önlemek için her alan adının belge kökünün, SSL bağlamasının ve yeniden yazma kurallarının doğru kapsamda olduğunu doğrulamalıdır.

Karar Matrisi: Belirtiye Göre 400 Hatasını Teşhis Etme

Teknik Kontrol Listesi: 400 Bad Request Çözümü

Son kullanıcılar için:

• URL’yi karakter karakter inceleyin ve yeniden yazın, kodlama sorunlarını düzeltin
• Etkilenen alan adına özgü çerezleri ve önbelleği temizleyin
• Uzantıları elemek için özel/gizli pencerede test edin
• Yerel DNS önbelleğini temizleyin
• Farklı bir tarayıcı, cihaz ve ağ bağlantısında test edin

Geliştiriciler ve API tüketicileri için:

• Content-Type değerinin istek gövdesi biçimiyle eşleştiğini doğrulayın
• Tüm zorunlu alanların ve başlıkların mevcut ve doğru türde olduğunu onaylayın
• Dize değerlerinin, tarihlerin ve sayısal türlerin API sözleşmesine uyduğunu kontrol edin
• Ham HTTP alışverişini incelemek için ayrıntılı çıktıyla curl kullanın:

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

Sunucu yöneticileri için:

• Sunucu hata günlüklerini çekip 400 girişleri için grep ile filtreleyin
• Web sunucusu yapılandırma sözdizimini doğrulayın (nginx -t / apachectl -t)
• client_max_body_size (Nginx) ve LimitRequestBody (Apache) değerlerini kontrol edin
• Çerez yoğun istekler başarısız oluyorsa Nginx’te large_client_header_buffers ayarını gözden geçirin
• WAF kurallarını denetleyin ve ModSecurity denetim günlüğünü kontrol edin
• SSL/TLS sertifika geçerliliğini ve kapsamını doğrulayın
• .htaccess yeniden yazma kurallarının sözdizimsel olarak doğru olduğunu onaylayın

—

SSS

400 ile 404 hatası arasındaki fark nedir?

400 hatası, sunucunun isteği anlayamadığı anlamına gelir çünkü istek hatalı biçimlendirilmiştir — hata, isteğin nasıl oluşturulduğundadır. 404 hatası ise isteğin geçerli ve anlaşılır olduğu, ancak istenen kaynağın sunucuda mevcut olmadığı anlamına gelir. Her ikisi de tamamen farklı düzeltmeler gerektirir.

400 Bad Request hatası sunucudan kaynaklanabilir mi, istemciden değil?

Evet, dolaylı olarak. Aşırı kısıtlayıcı bir WAF kuralı, yanlış Nginx large_client_header_buffers ayarı veya bozuk .htaccess direktifi gibi bir sunucu yanlış yapılandırması, sunucunun teknik olarak geçerli istekleri reddetmesine neden olabilir. Bu durumlarda HTTP spesifikasyonu hâlâ takip edilmektedir (sunucu, hatalı olarak algıladığı şeyi reddediyor), ancak gerçek hata istemcinin isteğinde değil sunucunun yapılandırmasındadır.

Çerezleri temizlemek neden 400 hatasını düzeltir?

Çerezler, ilgili alan adına yapılan her istekte Cookie istek başlığında gönderilir. Tarayıcıda depolanan bir çerez hatalı biçimlendirilmişse, sunucunun kabul etmediği şekilde süresi dolmuşsa veya çok büyük hale gelmişse (Nginx’teki large_client_header_buffers sınırlarını aşıyorsa), sunucu isteği işlemeden önce 400 ile reddeder. Bozuk çerezi silmek, başlıktaki hatalı veriyi kaldırır.

Web siteme dosya yüklerken oluşan 400 hatasını nasıl düzeltirim?

Yükleme, web sunucusunun gövde boyutu sınırını veya PHP’nin yükleme boyutu sınırını aşıyordur. Nginx’te nginx.conf dosyasındaki client_max_body_size değerini artırın. Apache’de .htaccess veya httpd.conf dosyasındaki LimitRequestBody değerini ayarlayın. PHP uygulamaları için php.ini dosyasındaki upload_max_filesize ve post_max_size değerlerini güncelleyin; post_max_size değerinin upload_max_filesize değerinden büyük olduğundan emin olun. Değişiklikleri yaptıktan sonra ilgili servisleri yeniden başlatın.

400 hatasının kaynak sunucumdan değil CDN veya WAF’tan geldiğini nasıl anlayabilirim?

Yanıt başlıklarını kontrol edin. Cloudflare cf-ray ve server: cloudflare başlıkları ekler. AWS CloudFront x-amz-cf-id ekler. Bu başlıklar 400 yanıtında mevcutsa, red işlemi kaynakta değil uçta gerçekleşmiştir. Hangi kuralın bloğu tetiklediğini belirlemek için CDN’nin WAF günlüklerini veya güvenlik duvarı olay panosunu inceleyin, ardından meşru trafik kalıbı için hedefli bir istisna oluşturun.