خطای ⁦401 Unauthorized⁩ چیست و چگونه رفع می‌شود؟

پنلی را باز می‌کنید که دیروز با آن کار کرده‌اید و کروم صفحه خاکستری ساده‌ای نشان می‌دهد: «این صفحه کار نمی‌کند» و در پایین آن ⁦"HTTP ERROR 401"⁩. روی سرور یک شرکت، همین کد به شکل ⁦"401 - Unauthorized: Access is denied due to invalid credentials."⁩ ظاهر می‌شود. در Postman هم یک 401 قرمز کنار فراخوانی API می‌بینید که یک ساعت پیش کار می‌کرد.

هر سه یک کد وضعیت HTTP هستند: سرور می‌خواست بداند شما کیستید و پاسخی نگرفت که بپذیرد. در ادامه می‌خوانید این کد چه معنایی دارد، چه فرقی با 400، 403 و 407 دارد، بازدیدکننده و برنامه‌نویس چگونه آن را رفع می‌کنند و یک آزمایش واقعی با cURL چه نشان می‌دهد.

خطای ⁦401 Unauthorized⁩ یعنی چه؟#

پاسخ 401 یعنی سرور درخواست شما را انجام نداده است، چون بدون اطلاعات ورود معتبر رسیده است. استاندارد HTTP، یعنی ⁦RFC 9110⁩، این کد را در بخش ⁦15.5.2⁩ درخواستی تعریف می‌کند که برای منبع مقصد اطلاعات ورود معتبر ندارد. اطلاعات ورود هر چیزی است که ثابت می‌کند شما کیستید: رمز عبور، کوکی نشست، کلید API یا توکن.

سرور همچنین باید هدر WWW-Authenticate را بفرستد که به کلاینت می‌گوید چگونه وارد شود. اگر درخواست از قبل اطلاعات ورود داشته است، 401 یعنی همان اطلاعات رد شده‌اند.

نام این کد گمراه‌کننده است. احراز هویت (authentication) به پرسش «شما کیستید؟» پاسخ می‌دهد و مجوزدهی (authorization) به پرسش «اجازه چه کاری را دارید؟». 401 به پرسش نخست مربوط است؛ پاسخ منفی به پرسش دوم ⁦403 Forbidden⁩ است.

خطای 401 چه شکلی دارد؟#

بستگی دارد چه کسی آن را نشان می‌دهد: مرورگر، وب‌سرور و API هر کدام آن را با واژه‌های متفاوتی بیان می‌کنند.

صفحه کروم چیزی درباره علت نمی‌گوید؛ در آزمایش ما، کرومیوم (موتوری که کروم بر پایه آن ساخته شده است) این صفحه را برای یک 401 با بدنه خالی نشان داد.

هدر WWW-Authenticate چیست؟#

WWW-Authenticate هدر پاسخی است که سرور در آن روش ورود خود را نام می‌برد؛ به این روش طرح (scheme) می‌گویند. مرجع MDN نحو کامل آن را نشان می‌دهد. Basic نام کاربری و رمز عبور می‌خواهد که با Base64 کدگذاری می‌شوند (رمزنگاری نمی‌شوند، پس فقط روی HTTPS امن‌اند)؛ مرورگرها به آن با پنجره ورود خودشان پاسخ می‌دهند. Bearer یک توکن می‌خواهد، همان قالبی که ⁦OAuth 2.0⁩ به کار می‌برد. Negotiate و NTLM ورود ویندوزی در شبکه‌های شرکتی‌اند.

WWW-Authenticate: Basic realm="Staging server", charset="UTF-8"
WWW-Authenticate: Bearer realm="example", error="invalid_token"

اگر با توکن کار می‌کنید، مقدار error را بخوانید. ⁦RFC 6750⁩، استاندارد توکن‌های Bearer، مقدار invalid_token را برای توکن منقضی، باطل‌شده یا خراب (401)، insufficient_scope را برای توکنی که مجوز لازم را ندارد (403) و invalid_request را برای درخواست بدشکل (400) تعریف می‌کند. درخواستی که اصلاً توکن ندارد یک چالش (challenge) ساده و بدون کد خطا می‌گیرد. بسیاری از APIها با وجود این قاعده هدر را نمی‌فرستند؛ در این صورت فقط بدنه پاسخ دلیل را می‌گوید.

خطای 401 گام‌به‌گام چگونه رخ می‌دهد؟#

پاسخ 401 نیمه نخست یک گفت‌وگوی کوتاه میان کلاینت و سرور است:

1. درخواست. مرورگر یا اسکریپت شما صفحه‌ای محافظت‌شده را بدون اطلاعات ورود، یا با اطلاعاتی که دیگر کار نمی‌کنند، درخواست می‌کند.
2. چالش. سرور با 401 پاسخ می‌دهد و طرح را در WWW-Authenticate نام می‌برد.
3. اطلاعات ورود. مرورگر پنجره ورودش را باز می‌کند، برنامه شما را به صفحه ورود خودش می‌فرستد یا کد شما یک توکن درخواست می‌کند.
4. تکرار. درخواست این بار با هدر Authorization فرستاده می‌شود، مثلاً Authorization: Bearer <token>.
5. نتیجه. اطلاعات معتبر صفحه را می‌گیرند (⁦200 OK⁩)، اطلاعات نامعتبر یک 401 دیگر و اطلاعات معتبری که مجوز ندارند یک 403.

بیشتر سایت‌هایی که فرم ورود دارند، بازدیدکننده‌ای را که از حساب خارج شده است به جای 401 به صفحه ورود می‌فرستند. 401 در مرورگر معمولاً از یک بخش مدیریت، اینترانت یک شرکت یا یک برنامه وب می‌آید که فراخوانی‌هایش به API خودش رد می‌شوند.

تفاوت 400، 401، 403 و 407 چیست؟#

این چهار کد در اینکه چه کسی رد می‌کند و چرا با هم فرق دارند: 400 درخواستی است که سرور نمی‌تواند بخواند، 401 ورودی که انجام نشده یا رد شده است، 403 کاربر شناخته‌شده‌ای که اجازه ندارد و 407 پروکسی شما که اطلاعات ورود خودش را می‌خواهد.

پاسخ 401 شما را دعوت می‌کند که با اطلاعات ورود دوباره امتحان کنید؛ 403 می‌گوید همان اطلاعات کمکی نمی‌کند. نوشته خطای ⁦403 Forbidden⁩ چیست و چگونه رفع می‌شود؟ این حالت را توضیح می‌دهد.

پاسخ 400 حتی زودتر می‌آید: سرور نتوانسته است درخواست را بخواند، پس هرگز بررسی نکرده که چه کسی آن را فرستاده است؛ راهنمای ما درباره خطای ⁦400 Bad Request⁩ علت‌های آن را توضیح می‌دهد.

پروکسی‌ای که اطلاعات ورود می‌خواهد با ⁦407 Proxy Authentication Required⁩ و هدر Proxy-Authenticate پاسخ می‌دهد، هرگز با 401. راه‌حل، نام کاربری و رمز پروکسی یا قرار گرفتن آی‌پی شما در لیست سفید آن است، نه ورود شما به سایت. نوشته رفع خطای ⁦HTTP 407 Proxy Authentication Required⁩ نشان می‌دهد اطلاعات ورود پروکسی در هر ابزار کجا نوشته می‌شود.

آیا پروکسی توکن شما را می‌بیند؟ برای آدرس https:// نه: کلاینت با یک درخواست CONNECT تونلی از میان پروکسی باز می‌کند و هدر Authorization درون اتصال رمزنگاری‌شده به سایت می‌رود. پروکسی فقط نام میزبان و پورت را می‌بیند؛ یک پروکسی HTTPS فراخوانی‌های API را همین‌گونه جابه‌جا می‌کند. روی http:// ساده، توکن به شکل متن خوانا از پروکسی می‌گذرد.

چرا خطای 401 می‌گیرم؟#

از سمت بازدیدکننده، 401 تقریباً همیشه یعنی سایت دیگر ورود شما را نمی‌شناسد یا اصلاً آن را دریافت نکرده است:

• نشست شما تمام شده است، پس از مدتی بی‌کاری، تغییر رمز عبور یا خروج از حساب در دستگاهی دیگر، یا کوکی سایت (فایل کوچکی که سایت با آن شما را به یاد می‌آورد) خراب شده است.
• مدیر رمز عبور شما حساب دیگری را پر کرده است، مثلاً حساب شخصی‌تان در سایتی که حساب کاری هم در آن دارید.
• پنجره ورود مرورگر را لغو کرده‌اید یا رمز نادرستی در آن نوشته‌اید.
• پیوند برای کس دیگری بوده است. پنل‌های اشتراکی و سرورهای آزمایشی ممکن است حسابی بخواهند که شما ندارید.
• صفحه‌ای سازمانی حساب کاری شما را انتظار دارد و رایانه شخصی یا مرورگری بیرون از شبکه شرکت را رد می‌کند.

رفع خطای 401 به‌عنوان بازدیدکننده#

این گام‌ها را به ترتیب پیش بروید؛ گام‌های نخست فقط چند ثانیه طول می‌کشند.

1. آدرس را بررسی کنید. یک غلط تایپی یا نشانک (bookmark) قدیمی می‌تواند شما را به بخشی محافظت‌شده ببرد؛ صفحه را از صفحه اصلی سایت باز کنید.
2. از حساب خارج شوید و دوباره وارد شوید تا نشست تازه‌ای بگیرید.
3. حساب را بررسی کنید. ببینید مدیر رمز عبور کدام نام کاربری را پر کرده است و اطلاعات ورود را یک بار با دست تایپ کنید.
4. کوکی‌های همان سایت را پاک کنید. در کروم: بیشتر > تنظیمات > حریم خصوصی و امنیت > کوکی‌های طرف سوم > دیدن همه داده‌ها و اجازه‌های سایت، نام سایت را جست‌وجو کنید و حذف را انتخاب کنید. این کار شما را فقط از همان سایت خارج می‌کند.
5. یک پنجره ناشناس را امتحان کنید. گزینه بیشتر > پنجره ناشناس جدید (⁦Ctrl+Shift+N⁩) در کروم پنجره‌ای بدون کوکی‌های سایت باز می‌کند و افزونه‌هایی که اجازه کار در آن را نداده‌اید آنجا اجرا نمی‌شوند. اگر صفحه آنجا کار کرد، یک کوکی یا یک افزونه باعث 401 بوده است.
6. در پنجره ورود، اطلاعاتی را بنویسید که به شما داده‌اند. اگر پنجره مدام برمی‌گردد، اطلاعات نادرست است؛ از کسی که به شما دسترسی داده است بپرسید.
7. با سایت یا تیم فناوری اطلاعات (IT) خود تماس بگیرید و آدرس، زمان و حسابی را که به کار بردید بگویید.

خطای 401 فقط یک راه‌حل صادقانه دارد: اطلاعات ورودی که برای خود شما صادر شده است. امتحان کردن رمزهای دیگر یا حساب شخص دیگر دسترسی غیرمجاز است و تلاش‌های ناموفق پیاپی می‌تواند حساب را قفل کند.

رفع خطای 401 به‌عنوان برنامه‌نویس#

در کد، 401 یعنی سرور آنچه را در هدر Authorization رسیده است نپذیرفته است، پس پیش از حساب، درخواست را بررسی کنید. نخست مقدار WWW-Authenticate و بدنه پاسخ را بخوانید.

1. هدر فرستاده نمی‌شود. اگر در خروجی curl -v خطی به شکل > Authorization: نیست، چیزی فرستاده نشده است. علت‌های معمول: یک متغیر محیطی خالی یا یک تغییر مسیر (redirect). cURL وقتی تغییر مسیر به میزبان، پورت یا پروتکل (http یا https) دیگری برود، هدر Authorization را کنار می‌گذارد، مگر اینکه --location-trusted را اضافه کنید؛ در آزمایش ما، تغییر مسیری از localhost به 127.0.0.1 یک پاسخ 200 را به 401 تبدیل کرد.
2. طرح نادرست است. توکن به شکل Authorization: Bearer <token> فرستاده می‌شود و نام کاربری و رمز با Basic. توکنی که با Basic فرستاده شود، نوشتن Token جایی که API انتظار Bearer دارد، یا کلید API در هدری که API آن را نمی‌خواند، همه به 401 می‌رسند. پس از نام طرح یک فاصله بگذارید و از گیومه استفاده نکنید.
3. توکن منقضی یا باطل شده است. وجود error="invalid_token" در چالش همین را می‌گوید. یک توکن تازه بگیرید (اگر توکن تازه‌سازی یا refresh token دارید، با همان) و درخواست را یک بار تکرار کنید.
4. ساعت‌ها با هم نمی‌خوانند. یک JWT (یعنی JSON Web Token) زمان انقضا (exp) و زمان شروع اعتبار (nbf) خودش را همراه دارد که با ساعت سرور سنجیده می‌شوند. ساعتی که چند دقیقه جلو یا عقب باشد، توکن تازه را منقضی یا هنوز نامعتبر نشان می‌دهد؛ استاندارد JWT حداکثر چند دقیقه رواداری (leeway) را در نظر می‌گیرد، پس ساعت هر دو دستگاه را با NTP هماهنگ کنید.
5. توکن متعلق به جای دیگری است: توکن محیط آزمایشی (staging) که به محیط اصلی (production) فرستاده شده، یا توکنی که برای API دیگری صادر شده است. JWT گیرنده مورد نظرش را در فیلد aud (audience) نام می‌برد و سروری که نام خودش را آنجا نمی‌یابد باید توکن را رد کند.
6. درخواست پیش‌بررسی مرورگر رد می‌شود. مرورگر پیش از یک درخواست میان‌سایتی که هدر Authorization دارد، یک درخواست OPTIONS می‌فرستد، یعنی پیش‌بررسی CORS (preflight)، که هرگز اطلاعات ورود ندارد. اگر سرور آنجا هم توکن بخواهد، با 401 پاسخ می‌دهد و درخواست اصلی هرگز فرستاده نمی‌شود. به OPTIONS بدون احراز هویت پاسخ دهید.
7. پیکربندی خود سرور. در IIS، عدد پس از نقطه دلیل را نام می‌برد: 401.1 ورود ناموفق، 401.2 تنظیمات احراز هویت سرور و 401.3 مجوزهای فایل؛ بقیه در فهرست کدهای وضعیت IIS مایکروسافت آمده است. در IIS Manager، قابلیت Authentication (احراز هویت) سایت نشان می‌دهد کدام روش‌ها فعال‌اند.

اگر خزنده (crawler) شما به 401 برخورد، صفحه پشت ورود قرار دارد: فقط صفحه‌های عمومی را جمع‌آوری کنید یا از API رسمی سایت با کلیدی که برای شما صادر شده است استفاده کنید. هرگز 401 را در یک حلقه تکرار نکنید؛ بدون اطلاعات ورود تازه، موفق نمی‌شود.

چگونه یک 401 را با cURL آزمایش کنید؟#

curl -i سطر وضعیت و هدرهای پاسخ را بالای بدنه چاپ می‌کند و همین برای دیدن یک 401 و چالش آن کافی است. روی رایانه خودمان یک API آزمایشی کوچک با Node.js نوشتیم که نقطه اتصال /api/profile آن با 401 پاسخ می‌دهد، مگر اینکه درخواست demo-token-123 را همراه داشته باشد، که توکنی ساختگی است. آن را با ⁦cURL 8.22⁩ که درون ویندوز 11 هست فراخوانی کردیم:

curl -i http://localhost:8401/api/profile

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

سپس با توکن:

curl -i -H "Authorization: Bearer demo-token-123" http://localhost:8401/api/profile

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

با یک توکن تاریخ‌گذشته، سرور با 401 و error="invalid_token" پاسخ داد. در ⁦Windows PowerShell 5.1⁩، curl میان‌بری برای Invoke-WebRequest است، پس آنجا curl.exe را تایپ کنید.

تفاوت کلید API و توکن OAuth چیست؟#

کلید API رازی بلندمدت است که برنامه یا حساب شما را معرفی می‌کند؛ توکن دسترسی OAuth مجوز عبوری کوتاه‌مدت است که پس از ورود یک نفر صادر می‌شود.

توکنی که دامنه دسترسی (scope) درست، یعنی فهرست کارهایی که اجازه انجامشان را دارد، نداشته باشد، به جای 401 پاسخ 403 می‌گیرد. کلیدها و توکن‌ها را در متغیرهای محیطی یا یک مدیر رازها (secrets manager) نگه دارید، هرگز در مخزن کد.

کجا ممکن است با 401 روبه‌رو شوید#

• پنل‌های مدیریت و سرورهای آزمایشی که با پنجره ورود مرورگر محافظت می‌شوند.
• صفحه‌های اینترانت شرکت‌ها که از ورود ویندوزی استفاده می‌کنند.
• APIها و وب‌هوک‌ها پس از تعویض کلید یا انقضای توکن.
• مجموعه‌های (collection) Postman یا Bruno با توکنی که به‌روز نیست.
• خزنده‌ها و اسکریپت‌های پایش که به صفحه‌های پشت ورود می‌رسند.

اشتباه‌های رایج#

• برخورد با 401 مانند 403. وقتی توکن فرستاده نمی‌شود، مجوزهای بیشتر کمکی نمی‌کنند.
• تکرار درخواست در یک حلقه، که می‌تواند حساب را قفل کند یا محدودیت نرخ را فعال کند.
• چسباندن توکن‌های واقعی در تیکت‌ها، تصویرهای صفحه یا خروجی اشتراکی curl -v.
• خواستن توکن برای OPTIONS در سرور.
• فرستادن 401 بدون WWW-Authenticate، هدری که استاندارد آن را الزامی می‌داند.

راهنمای انتخاب#

پرسش‌های متداول#

چرا در Postman خطای ⁦401 Unauthorized⁩ می‌گیرم؟#

معمولاً درخواست توکنی را که فکر می‌کنید نمی‌فرستد. در زبانه Authorization درخواست، فهرست Auth type نشان می‌دهد که درخواست از تنظیم خودش استفاده می‌کند یا از تنظیم مجموعه (collection) یا پوشه‌اش (زیر Inherited). اگر توکن از یک متغیر می‌آید، محیط (environment) درست را انتخاب کنید و بررسی کنید که توکن منقضی نشده باشد.

پیام ⁦"Access is denied due to invalid credentials"⁩ یعنی چه؟#

این صفحه استاندارد 401 در IIS، وب‌سرور مایکروسافت، است: سرور اطلاعات ورودی را که مرورگر شما فرستاده نپذیرفته یا نتوانسته است با روشی که برایش تنظیم شده شما را وارد کند. بازدیدکننده باید با حساب کاری درست وارد شود یا از تیم IT بپرسد؛ مدیران باید عدد ⁦401.x⁩ را بخوانند.

آیا خطای 401 تقصیر من است یا سایت؟#

معمولاً یک مشکل ورود است که خودتان می‌توانید رفعش کنید: نشست منقضی، کوکی کهنه یا حساب ذخیره‌شده نادرست. اگر اطلاعات ورود درست با کوکی‌های تازه هم کار نکند، سیستم ورود سایت خراب است.

چرا پاسخ 401 بدنه ندارد؟#

استاندارد بدنه را الزامی نمی‌داند؛ هدر WWW-Authenticate را الزامی می‌داند، پس هدرها را بخوانید. مرورگری که یک 401 خالی می‌گیرد صفحه خودش را نشان می‌دهد؛ در آزمایش ما کرومیوم صفحه «این صفحه کار نمی‌کند» را نمایش داد.

آیا VPN یا پروکسی می‌تواند باعث خطای 401 شود؟#

به‌ندرت به‌طور مستقیم: پروکسی‌ای که اطلاعات ورود می‌خواهد با 407 پاسخ می‌دهد. اما هر دو آدرس آی‌پی شما را تغییر می‌دهند و برخی APIها یک کلید را فقط از آدرس‌های ثبت‌شده می‌پذیرند و بقیه را با 401 یا 403 رد می‌کنند. برای چنین APIهایی، یک پروکسی ISP همان آی‌پی خروجی را ثابت نگه می‌دارد.

آیا کد من باید 401 را خودکار دوباره امتحان کند؟#

یک بار، و فقط پس از گرفتن اطلاعات ورود تازه، مثلاً یک توکن تازه‌شده. اگر همان چالش دوباره برگشت، متوقف شوید و خطا را گزارش کنید.

خلاصه#

⁦401 Unauthorized⁩ یعنی سرور اطلاعات ورودی را که بپذیرد دریافت نکرده است و WWW-Authenticate می‌گوید چه نوعی را می‌خواهد. بازدیدکننده آدرس را بررسی می‌کند، دوباره وارد می‌شود و کوکی‌های سایت را پاک می‌کند. برنامه‌نویس بررسی می‌کند که هدر Authorization با طرح درست و توکنی معتبر فرستاده شود. برای کار با APIهایی که به آی‌پی خروجی ثابت یا تونل HTTPS نیاز دارند، گزینه‌ها را در صفحه پروکسی ما مقایسه کنید.