Dün kullandığınız bir paneli açıyorsunuz ve Chrome düz, gri bir sayfa gösteriyor: "Bu sayfa çalışmıyor", en altta da HTTP ERROR 401. Bir şirket sunucusunda aynı kod "401 - Unauthorized: Access is denied due to invalid credentials." diye görünür. Postman'de ise bir saat önce çalışan bir API çağrısının yanında kırmızı bir 401 belirir.
Üçü de aynı HTTP durum kodudur: sunucu kim olduğunuzu bilmek istemiş ve kabul edeceği bir cevap alamamıştır. Bu yazıda kodun ne anlama geldiğini, 400, 403 ve 407'den farkını, ziyaretçi ve geliştirici için çözümleri ve cURL ile yaptığımız gerçek bir testi anlatıyoruz.
401 Unauthorized ne demek?
401, sunucunun isteğinizi geçerli kimlik bilgisi taşımadığı için yerine getirmediği anlamına gelir. HTTP standardı RFC 9110, 15.5.2 numaralı bölümde bu kodu, hedef kaynak için geçerli kimlik doğrulama bilgisi taşımayan bir isteğe verilen cevap olarak tanımlar. Kimlik bilgisi, kim olduğunuzu kanıtlayan her şeydir: şifre, oturum çerezi, API anahtarı ya da token (belirteç), yani sunucunun size verdiği dijital bir erişim anahtarı.
Sunucu ayrıca istemciye (tarayıcıya ya da programa) nasıl giriş yapacağını söyleyen bir WWW-Authenticate başlığı göndermek zorundadır. İstek zaten kimlik bilgisi taşıyorsa 401, bu bilgilerin reddedildiği anlamına gelir.
Kodun adı (Unauthorized, "yetkisiz") yanıltıcıdır. Kimlik doğrulama (authentication) "kimsiniz?" sorusunu, yetkilendirme (authorization) "neye izniniz var?" sorusunu cevaplar. 401 birinci soruyla ilgilidir; ikinci sorudaki ret ise 403 Forbidden'dır.
401 hatası nasıl görünür?
Bu, hatayı kimin gösterdiğine bağlıdır: tarayıcı, web sunucusu ve API aynı kodu farklı sözlerle bildirir.
| Ne görürsünüz? | Kim gösterir? | Ne anlama gelir? |
|---|---|---|
| "Bu sayfa çalışmıyor", "HTTP ERROR 401" | Chrome | Site, kendi sayfası olmayan bir 401 gönderdi |
| Kullanıcı adı ve şifre isteyen küçük bir kutu | Tarayıcınız | Site, HTTP üzerinden giriş (Basic) kullanıyor |
| "401 - Unauthorized: Access is denied due to invalid credentials." yazan sayfa | Microsoft'un web sunucusu IIS | IIS girişi kabul etmedi |
401 ve kısa bir JSON mesajı | Postman'de ya da kodunuzda bir API | Anahtar ya da token eksik, yanlış veya süresi dolmuş |
Chrome'un sayfası neden hakkında hiçbir şey söylemez; testimizde Chromium (Chrome'un temelindeki motor) bu sayfayı gövdesi boş bir 401 için gösterdi.
WWW-Authenticate başlığı nedir?
WWW-Authenticate, sunucunun giriş yöntemini, yani şemayı (scheme) bildirdiği cevap başlığıdır. Tam söz dizimi MDN'nin başvuru sayfasında yer alır.
Basic kullanıcı adı ve şifre ister; istemci bunları Base64 ile kodlayıp gönderir. Base64 bir şifreleme değil, herkesin geri çevirebileceği bir kodlama olduğu için Basic yalnız HTTPS üzerinden güvenlidir; tarayıcılar Basic'e kendi giriş kutularıyla cevap verir. Bearer, OAuth 2.0'ın kullandığı biçimde bir token ister; Negotiate ve NTLM ise şirket ağlarındaki Windows girişidir.
WWW-Authenticate: Basic realm="Staging server", charset="UTF-8"
WWW-Authenticate: Bearer realm="example", error="invalid_token"Token kullanıyorsanız error değerine bakın. Bearer token standardı RFC 6750 üç değer tanımlar: süresi dolmuş, iptal edilmiş ya da bozuk token için invalid_token (401), gereken izni taşımayan token için insufficient_scope (403) ve hatalı biçimlendirilmiş istek için invalid_request (400). Hiç token taşımayan istek ise hata kodu içermeyen yalın bir giriş çağrısı (challenge), yani yalnız şemayı bildiren bir WWW-Authenticate başlığı alır. Birçok API, kurala rağmen bu başlığı hiç göndermez; o zaman nedeni yalnız cevabın gövdesinden öğrenirsiniz.
401 hatası adım adım nasıl oluşur?
401, istemci ile sunucu arasındaki kısa bir konuşmanın ilk yarısıdır:
- İstek. Tarayıcınız ya da betiğiniz korunan bir sayfayı kimlik bilgisi olmadan veya artık geçerli olmayan bilgilerle ister.
- Giriş çağrısı (challenge). Sunucu 401 döndürür ve şemanın adını
WWW-Authenticatebaşlığına yazar. - Kimlik bilgileri. Tarayıcı giriş kutusunu açar, uygulama sizi kendi giriş sayfasına gönderir ya da kodunuz bir token alır.
- Tekrar. İstek bu kez
Authorization: Bearer <token>gibi birAuthorizationbaşlığıyla yeniden gönderilir. - Karar. Geçerli bilgiler sayfayı getirir (200 OK), geçersiz bilgiler yeni bir 401 alır; bilgiler geçerli ama hesabın izni yoksa cevap 403 olur.
Giriş formu olan sitelerin çoğu, oturumu kapalı bir ziyaretçiye 401 göndermez, onu giriş sayfasına yönlendirir. Bu yüzden tarayıcıda görülen 401 çoğunlukla bir yönetim panelinden, şirket içi bir siteden (intranet) ya da kendi API'sine yaptığı çağrılar reddedilen bir web uygulamasından gelir.
400, 401, 403 ve 407 arasındaki fark nedir?
Dört kod, kimin ve neden reddettiğiyle ayrılır: 400 sunucunun okuyamadığı bir isteği, 401 eksik ya da reddedilmiş bir girişi, 403 tanınan ama izni olmayan bir kullanıcıyı, 407 ise kendi kimlik bilgilerini isteyen proxy'nizi gösterir.
| Kod | Kim reddeder? | Ne anlama gelir? | Ne çözer? |
|---|---|---|---|
400 | Site ya da API | İstek hatalı biçimlendirilmiş | İsteği düzeltmek |
401 | Site ya da API | Geçerli kimlik bilgisi yok | Giriş yapmak ya da geçerli token göndermek |
403 | Site ya da API | Tanınıyor, ama izin yok | Başka bir hesap ya da sitenin izni |
407 | Proxy'niz | Proxy kimlik bilgisi istiyor | Proxy'nin kullanıcı adı ve şifresi ya da IP listesi |
401, kimlik bilgileriyle yeniden denemeye çağırır; 403 ise aynı bilgilerin işe yaramayacağını söyler. Bu ikinci durumu 403 Forbidden Hatası Nedir, Nasıl Çözülür? yazısında anlattık.
400 daha da önce gelir: sunucu isteği okuyamamıştır, bu yüzden kimin gönderdiğine hiç bakmamıştır; nedenlerini 400 Bad Request hatası rehberimizde topladık.
Kimlik bilgisi isteyen bir proxy, 401 ile değil, Proxy-Authenticate başlığı taşıyan 407 Proxy Authentication Required ile cevap verir. Bu durumda çözüm sitedeki girişiniz değil, proxy'nin kullanıcı adı ve şifresi ya da IP adresinizin onun whitelist'inde (izin listesinde) bulunmasıdır. Proxy kimlik bilgilerinin her araçta nereye yazıldığını HTTP 407 Proxy Authentication Required Hatası Nasıl Çözülür? yazısında gösterdik.
Proxy, siteye gönderdiğiniz token'ı görür mü? https:// ile başlayan bir adreste görmez: istemci proxy üzerinden CONNECT isteğiyle bir tünel açar ve Authorization başlığı siteye giden şifreli bağlantının içinde yol alır. Proxy yalnız alan adını ve portu görür; API çağrıları HTTPS Proxy üzerinden bu şekilde taşınır. Düz http:// adreslerde ise token proxy'den okunabilir metin olarak geçer.
Neden 401 hatası alıyorum?
Ziyaretçi açısından 401 neredeyse her zaman, sitenin girişinizi artık tanımadığı ya da hiç almadığı anlamına gelir:
- Oturumunuz sona ermiştir. Uzun süre işlem yapmamış, şifrenizi değiştirmiş ya da başka bir cihazda çıkış yapmış olabilirsiniz. Sitenin sizi hatırlamak için tuttuğu küçük dosya, yani çerez de bozulmuş olabilir.
- Şifre yöneticiniz başka bir hesabı doldurmuştur, örneğin iş hesabınız da olan bir sitede kişisel hesabınızı.
- Tarayıcının giriş kutusunu kapatmışsınızdır ya da kutuya yanlış şifre yazmışsınızdır.
- Bağlantı başkası için paylaşılmıştır. Paylaşılan paneller ve test sunucuları, sizde olmayan bir hesap isteyebilir.
- Şirket sayfası iş hesabınızı bekliyordur ve kişisel bir bilgisayarı ya da şirket ağı dışındaki bir tarayıcıyı reddediyordur.
Ziyaretçi olarak 401 hatası nasıl çözülür?
Adımları sırayla deneyin; ilkleri birkaç saniye sürer.
- Adresi kontrol edin. Bir yazım hatası ya da eski bir yer imi sizi korunan bir alana götürebilir; sayfayı sitenin ana sayfasından açın.
- Çıkış yapıp yeniden giriş yapın. Böylece yeni bir oturum açılır.
- Hesabı kontrol edin. Şifre yöneticinizin hangi kullanıcı adını doldurduğuna bakın ve bilgileri bir kez elle yazın.
- O sitenin çerezlerini silin. Chrome'da Diğer > Ayarlar > Gizlilik ve güvenlik > Üçüncü taraf çerezleri > Tüm site verilerini ve izinlerini göster yolunu izleyin, siteyi aratın ve Sil'i seçin. Bu işlem yalnız o sitedeki oturumunuzu kapatır.
- 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 çerezlerini taşımadan açılır; orada çalışmasına izin vermediğiniz uzantılar da kapalı kalır. Sayfa gizli pencerede açılıyorsa 401'e bir çerez ya da bir uzantı yol açıyordur.
- Giriş kutusuna size verilen bilgileri yazın. Kutu tekrar tekrar açılıyorsa bilgiler yanlıştır; erişimi size kim verdiyse ona sorun.
- Siteye ya da BT ekibinize yazın. Adresi, saati ve kullandığınız hesabı bildirin.
401'in tek dürüst çözümü, size verilmiş kimlik bilgileridir. Başka şifreler denemek ya da başkasının hesabını kullanmak yetkisiz erişimdir; art arda başarısız denemeler hesabı kilitleyebilir de.
Geliştirici olarak 401 hatası nasıl çözülür?
Kodda 401, sunucunun Authorization başlığında gelen bilgiyi kabul etmediği anlamına gelir; bu yüzden önce hesabı değil, isteği kontrol edin. İlk iş olarak WWW-Authenticate değerini ve cevabın gövdesini okuyun.
- Başlık gönderilmiyordur.
curl -vçıktısında> Authorization:satırı yoksa başlık hiç gitmemiştir. Bunun en sık nedeni boş kalmış bir ortam değişkeni ya da bir yönlendirmedir. cURL, yönlendirme başka bir alan adına, porta ya da şemaya (http/https) gidiyorsa--location-trustedeklenmedikçeAuthorizationbaşlığını taşımaz; testimizdelocalhostadresinden127.0.0.1adresine yapılan bir yönlendirme, 200 cevabını 401'e çevirdi. - Şema yanlıştır. Token
Authorization: Bearer <token>biçiminde, kullanıcı adı ve şifreBasicile gönderilir. Basic olarak gönderilen bir token, APIBearerbeklerken yazılanTokenya da API'nin okumadığı bir başlığa konan API anahtarı, hep 401 ile sonuçlanır. Şemadan sonra tek boşluk bırakın, tırnak kullanmayın. - Token'ın süresi dolmuş ya da token iptal edilmiştir. Giriş çağrısındaki
error="invalid_token"bunu söyler. Yeni bir token alın (varsa yenileme token'ıyla, yani refresh token ile) ve isteği bir kez tekrarlayın. - Saatler uyuşmuyordur. JWT (JSON Web Token), kendi bitiş zamanını (
exp) ve geçerlilik başlangıcını (nbf) taşır; sunucu bunları kendi saatiyle karşılaştırır. Birkaç dakika kaymış bir saat, yeni bir token'ı süresi dolmuş ya da henüz geçerli değilmiş gibi gösterir. JWT standardı en fazla birkaç dakikalık bir tolerans öngördüğü için iki makinenin saatini de NTP ile, yani internet üzerinden otomatik saat ayarıyla eşitleyin. - Token başka bir yere aittir. Canlı ortama (production) gönderilen bir test (staging) token'ı ya da başka bir API için verilmiş bir token bu gruba girer. JWT, hedeflendiği alıcıyı
aud(audience) alanında yazar; kendini orada bulamayan sunucu token'ı reddetmek zorundadır. - Tarayıcının ön kontrol isteği reddediliyordur. Tarayıcı,
Authorizationbaşlığı taşıyan siteler arası bir istekten önceOPTIONSyöntemiyle bir ön kontrol isteği (CORS preflight) gönderir ve bu istek hiçbir zaman kimlik bilgisi taşımaz. Sunucu burada da token isterse 401 döndürür ve asıl istek hiç gönderilmez.OPTIONSisteklerine kimlik doğrulama istemeden cevap verin. - Sunucunun kendi ayarları. IIS'te noktadan sonraki sayı nedeni söyler: 401.1 başarısız oturum açma, 401.2 sunucunun kimlik doğrulama ayarları, 401.3 dosya izinleri; listenin tamamı Microsoft'un IIS durum kodu listesinde yer alır. IIS Yöneticisi'nde sitenin Authentication (Kimlik Doğrulama) özelliği hangi yöntemlerin açık olduğunu gösterir.
Crawler'ınız (otomatik tarama programınız) 401 alıyorsa sayfa bir girişin arkasındadır: yalnız herkese açık sayfaları toplayın ya da sitenin resmî API'sini size verilmiş bir anahtarla kullanın. 401 alan isteği asla döngü içinde tekrarlamayın; yeni kimlik bilgisi olmadan başarılı olamaz.
401 hatası cURL ile nasıl test edilir?
curl -i, cevabın gövdesinin üstüne durum satırını ve başlıkları da yazar; bir 401'i ve giriş çağrısını görmek için bu kadarı yeterlidir. Kendi bilgisayarımızda Node.js ile küçük bir test API'si yazdık: /api/profile uç noktası, istek uydurma bir token olan demo-token-123 değerini taşımadıkça 401 döndürüyor. API'yi Windows 11 ile birlikte gelen cURL 8.22 ile çağırdık:
curl -i http://localhost:8401/api/profileHTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer realm="example"
Content-Type: application/json
Content-Length: 21
Date: Thu, 12 Nov 2026 01:20:35 GMT
Connection: keep-alive
Keep-Alive: timeout=5
{"error":"no token"}Ardından token'la:
curl -i -H "Authorization: Bearer demo-token-123" http://localhost:8401/api/profileHTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 16
Date: Thu, 12 Nov 2026 01:20:35 GMT
Connection: keep-alive
Keep-Alive: timeout=5
{"user":"demo"}Süresi geçmiş bir token gönderdiğimizde sunucu yine 401 döndürdü, bu kez giriş çağrısında error="invalid_token" vardı. Windows PowerShell 5.1'de curl, Invoke-WebRequest komutunun kısayoludur; orada curl.exe yazın.
API anahtarı ile OAuth token'ı arasındaki fark nedir?
API anahtarı, uygulamanızı ya da hesabınızı tanıtan uzun ömürlü bir gizli değerdir; OAuth erişim token'ı ise biri giriş yaptıktan sonra verilen, kısa ömürlü bir geçiş kartıdır.
| Soru | API anahtarı | OAuth erişim token'ı |
|---|---|---|
| Kim verir? | Hizmetin yönetim paneli | Yetkilendirme sunucusu, girişten sonra |
| Ne kadar yaşar? | Silinene ya da yenilenene kadar | Dakikalar ya da saatler; refresh token yeniler |
| Nasıl gönderilir? | API'nin belirttiği başlık ya da parametre | Authorization: Bearer <token> |
| Tipik 401 nedeni | Yanlış yazılmış, silinmiş ya da yanlış yere konmuş | Süresi dolmuş ya da başka bir API için verilmiş |
Gereken kapsamı (scope), yani yapabileceği işlerin listesini taşımayan bir token 401 değil, 403 alır. Anahtarları ve token'ları ortam değişkenlerinde ya da bir gizli bilgi yöneticisinde (secrets manager) saklayın, asla kod deposunda tutmayın.
401 hatasıyla nerelerde karşılaşırsınız?
- Tarayıcının giriş kutusuyla korunan yönetim panellerinde ve test sunucularında.
- Windows girişi kullanan şirket içi sitelerde.
- Anahtar yenilendikten ya da token'ın süresi dolduktan sonra API'lerde ve webhook'larda.
- Kayıtlı token'ı eskimiş Postman ya da Bruno koleksiyonlarında.
- Giriş gerektiren sayfalara ulaşan crawler'larda ve izleme betiklerinde.
Sık yapılan hatalar
- 401'i 403 gibi ele almak. Token hiç gitmiyorsa daha fazla yetki istemek işe yaramaz.
- Döngü içinde yeniden denemek. Bu, hesabı kilitleyebilir ya da bir hız sınırına takılmanıza yol açabilir.
- Gerçek token'ları destek kayıtlarına, ekran görüntülerine ya da paylaşılan
curl -vçıktısına yapıştırmak. - Sunucuda
OPTIONSisteği için token istemek. WWW-Authenticateolmadan 401 göndermek. Standart bu başlığı zorunlu tutar.
Karar rehberi
| Durumunuz | Ne yapmalısınız? |
|---|---|
| Chrome "HTTP ERROR 401" gösteriyor | Yeniden giriş yapın, sonra o sitenin çerezlerini silin |
| Tarayıcı sürekli şifre soruyor | Bilgileri, erişimi size veren kişiye sorun |
| "Access is denied due to invalid credentials" sayfası | İş hesabınızı kullanın; yöneticiler 401.x koduna bakar |
curl -v çıktısında > Authorization: satırı yok | Başlığı düşüren değişkeni ya da yönlendirmeyi düzeltin |
error="invalid_token" | Yeni token alın, bir kez yeniden deneyin |
| 401 yerine 407 | Sitedeki girişi değil, proxy kimlik bilgilerini düzeltin |
Sıkça sorulan sorular
Postman'de neden 401 Unauthorized hatası alıyorum?
Çoğu zaman istek, gönderdiğini sandığınız token'ı göndermiyordur. İsteğin Authorization sekmesindeki Auth type listesi, isteğin kendi ayarını mı, yoksa bağlı olduğu koleksiyonun ya da klasörün ayarını mı (Inherited bölümü) kullandığını gösterir. Token bir değişkenden geliyorsa doğru ortamı (environment) seçin ve token'ın süresinin dolmadığını kontrol edin.
"Access is denied due to invalid credentials" ne demek?
Bu, Microsoft'un web sunucusu IIS'in standart 401 sayfasıdır: sunucu, tarayıcınızın gönderdiği kimlik bilgilerini kabul etmemiş ya da ayarlandığı giriş yöntemiyle oturumunuzu açamamıştır. Ziyaretçiyseniz doğru iş hesabıyla giriş yapın ya da BT ekibinize sorun; yöneticiyseniz noktadan sonraki 401.x numarasına bakın.
401 hatası benden mi kaynaklanıyor, siteden mi?
Çoğu zaman sizin çözebileceğiniz bir giriş sorunudur: süresi dolmuş bir oturum, eskimiş bir çerez ya da şifre yöneticisinin doldurduğu yanlış hesap. Çerezleri sildikten sonra doğru bilgilerle de giriş yapamıyorsanız sitenin giriş sistemi bozuktur.
401 cevabının gövdesi neden boş?
Standart gövde istemez; WWW-Authenticate başlığını ister, bu yüzden başlıkları okuyun. Gövdesi boş bir 401 alan tarayıcı kendi sayfasını gösterir; testimizde Chromium "Bu sayfa çalışmıyor" sayfasını açtı.
VPN ya da proxy 401 hatasına yol açar mı?
Doğrudan pek yol açmaz: kimlik bilgisi isteyen bir proxy 407 döndürür. Ama ikisi de IP adresinizi değiştirir ve bazı API'ler bir anahtarı yalnız listedeki adreslerden kabul eder, diğerlerini 401 ya da 403 ile reddeder. Böyle bir API için ISP Proxy aynı çıkış IP'sini korur.
Kodum 401 alınca otomatik olarak yeniden denemeli mi?
Bir kez ve yalnız yeni kimlik bilgisi, örneğin yenilenmiş bir token aldıktan sonra. Aynı giriş çağrısı yine gelirse durun ve hatayı bildirin.
Özet
401 Unauthorized, sunucunun kabul ettiği kimlik bilgilerini almadığını gösterir; hangi türü istediğini de WWW-Authenticate başlığı söyler. Ziyaretçiyseniz adresi kontrol edin, yeniden giriş yapın ve sitenin çerezlerini silin. Geliştiriciyseniz Authorization başlığının doğru şemayla ve süresi geçmemiş bir token'la gittiğini doğrulayın. Sabit çıkış IP'si ya da HTTPS tüneli gerektiren API işleri için seçenekleri proxy sayfamızda karşılaştırabilirsiniz.




