راهنمای جامع خطاهای وب؛ از ۴۰۴ و ۵۰۰ تا DNS، CORS و خطاهای زیرساخت

وقتی صفحه‌ای باز نمی‌شود، جملهٔ اول معمولاً این است: «سایت خراب است.» گاهی درست است. خیلی وقت‌ها نیست.

عدد سه‌رقمی بالای پاسخ سرور — کد وضعیت HTTP (HTTP Status Code) — پیام تزئینی مرورگر نیست. قراردادی است بین مرورگر، رابط برنامه‌نویسی کاربردی (API)، شبکه تحویل محتوا (CDN)، خزندهٔ موتور جست‌وجو و تیم فنی.

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

پاسخ کوتاه

خطای وب یعنی درخواست کاربر به نتیجهٔ مورد انتظار نرسیده است. گاهی سرور با یک کد وضعیت جواب می‌دهد. گاهی اتصال قبل از HTTP قطع می‌شود و اصلاً کدی در کار نیست.

کدهای ۴xx معمولاً می‌گویند این درخواست، با این شکل، قابل‌انجام نیست. کدهای ۵xx می‌گویند سرویس یا مسیر پشت آن شکست خورده است. خطاهای DNS، گواهی TLS و CORS ممکن است همان حس «سایت خواب است» را بسازند، بدون این‌که در لاگ برنامه ۵۰۰ دیده شود.

کد وضعیت تشخیص نیست؛ سیگنال است. علت در لاگ، بدنهٔ پاسخ، و لایه‌ای است که آن را صادر کرده.

کد وضعیت HTTP چیست و چگونه کار می‌کند؟

ارتباط وب ساده است: کلاینت درخواست می‌فرستد و سرور پاسخ می‌دهد. هر پاسخ یک کد سه‌رقمی دارد. معنی این کدها در RFC 9110 تعریف شده است.

پاسخ همیشه مستقیم از سرور مبدأ (Origin Server) نمی‌آید. بین کاربر و برنامه معمولاً CDN، متعادل‌کننده بار (Load Balancer) و reverse proxy نشسته‌اند. همان لایه‌ها می‌توانند ۵۰۲، ۵۰۳ یا ۵۰۴ بسازند؛ حتی وقتی کد شما exception نداده باشد.

دسته‌های کد وضعیت

کدها در پنج کلاس قرار می‌گیرند. دانستن کلاس، قبل از دانستن عدد دقیق، مسیر عیب‌یابی را مشخص می‌کند.

خطاهای ۴xx: وقتی درخواست قابل‌انجام نیست

کلاس ۴xx یعنی سرور درخواست را دریافت کرده، اما آن را اجرا نمی‌کند. علت می‌تواند نحو خراب، هویت نامشخص، دسترسی ناکافی، منبع ناموجود یا محدودیت نرخ باشد.

برای کلاینت معنی‌اش این است: همان درخواست را عیناً تکرار نکنید. چیزی باید عوض شود — ورودی، هویت، مجوز، یا زمان.

400 Bad Request

سرور به‌خاطر خطای کلاینت درخواست را پردازش نمی‌کند: JSON ناقص، Content-Type اشتباه، یا framing نامعتبر. تکرار بدون اصلاح معمولاً دوباره ۴۰۰ می‌دهد.

اگر فرم وب است، فیلدها را با قالب خواسته‌شده بفرستید. پاسخ خوب باید بگوید کدام فیلد خراب است، نه فقط Bad Request.

401، 403 و 404 را با هم عوضی نگیرید

نام 401 گمراه‌کننده است. در HTTP این کد یعنی احراز هویت نشده (unauthenticated)، نه «اجازه نداری». پاسخ باید سرنخی از طرح احراز هویت بدهد؛ مشخصات به WWW-Authenticate اشاره می‌کند.

403 یعنی سرور درخواست را فهمیده و معمولاً هویت را می‌شناسد، اما اجازه نمی‌دهد. آوردن credential معتبر این‌جا کمکی نمی‌کند.

404 یعنی representation جاری پیدا نشد، یا سرور نمی‌خواهد وجود منبع را فاش کند. RFC 9110 اجازه می‌دهد برای پنهان‌کردن منبع به‌جای 403 از 404 استفاده شود تا حدس‌زدن شناسه‌ها آسان نشود.

401 یعنی نمی‌دانم تو که هستی. 403 یعنی می‌دانم کی هستی و این کار را نمی‌توانی بکنی. 404 گاهی یعنی اصلاً به تو نمی‌گویم چنین چیزی وجود دارد.

405، 408، 409، 410، 415

405 یعنی روش HTTP برای آن منبع مجاز نیست. پاسخ باید فهرست روش‌های مجاز را در Allow داشته باشد. مثال کلاسیک: DELETE روی منبعی که فقط GET و POST می‌پذیرد.

408 یعنی سرور در فرصت معقول، درخواست کامل را نگرفته است. با 504 فرق دارد: این‌جا خود درخواست تمام نشده، نه پاسخ upstream.

409 تعارض با وضعیت فعلی است: موجودی همزمان، نام تکراری، یا شکست ETag. 410 برای حذف دائمی بدون جایگزین است؛ برای SEO قوی‌تر از 404 پیام «برنگرد» می‌دهد.

415 یعنی نوع رسانه پشتیبانی نمی‌شود؛ مثلاً سرور JSON می‌خواهد و کلاینت XML می‌فرستد.

422 Unprocessable Content

سرور نوع محتوا را فهمیده و نحو درست است، اما دستور داخلش قابل‌اجرا نیست. RFC 9110 نام را از Unprocessable Entity به Unprocessable Content عوض کرده است.

تفاوت با 400 این است: آنجا اغلب متن اصلاً خوانده نمی‌شود. اینجا متن خوانده شده و از نظر معنا رد شده؛ مثلاً تاریخ پایان قبل از شروع است.

429 Too Many Requests

کاربر در یک بازه بیش از حد درخواست فرستاده است؛ یعنی محدودسازی نرخ (Rate Limiting). RFC 6585 می‌گوید پاسخ بهتر است توضیح بدهد و می‌تواند Retry-After داشته باشد. این پاسخ نباید cache شود.

نکتهٔ SEO: Google کد 429 را مثل خطای سرور (اضافه‌بار) رفتار می‌کند، نه مثل 404. محدود کردن Googlebot با 429 یا 403 روش کنترل crawl نیست.

خطاهای ۵xx: وقتی سرویس یا مسیر پشت آن می‌شکند

کلاس ۵xx می‌گوید مشکل از سمت سرویس است، نه از شکل درخواست. برای کاربر یعنی الان کار تمام نمی‌شود. برای تیم یعنی باید لایه را پیدا کرد: برنامه، upstream، ظرفیت، یا مهلت زمانی.

500 و 501

500 یعنی سرور با وضعیتی روبه‌رو شده که نمی‌داند چطور مدیریت کند. وجودش یعنی برنامه غافلگیر شده، نه لزوماً این‌که کل زیرساخت سوخته است.

صفحهٔ عمومی باید شناسهٔ حادثه بدهد، نه stack trace. 501 یعنی روش درخواست پیاده نشده؛ برای GET و HEAD معمولاً نباید برگردد.

502، 503 و 504

502 یعنی لایهٔ میانی زنده است، اما از پشت‌سر پاسخ نامعتبر آمده: process کرش کرده، یا origin هنوز listen نمی‌کند.

503 برای نگهداری یا اضافه‌بار است. بهتر است موقت باشد، صفحهٔ انسانی داشته باشد و در صورت امکان Retry-After بگوید. این پاسخ معمولاً نباید روی CDN بماند.

504 یعنی جواب به‌موقع نرسیده، نه این‌که جواب خراب آمده باشد. پرس‌وجوی سنگین پایگاه داده (Database) یا درگاه پرداخت کند، الگوی کلاسیک است.

خطاهای DNS، TLS و اتصال

بخش بزرگی از گزارش «سایت باز نمی‌شود» اصلاً کد وضعیت ندارد. اتصال قبل از HTTP می‌شکند.

خطای DNS یعنی دامنه به نشانی IP ترجمه نشده: رکورد نیست، انتشار ناقص است، یا resolver کاربر خراب است. تیم Backend ممکن است هیچ ۵xxای در لاگ نبیند.

Connection refused یعنی چیزی روی آن پورت گوش نمی‌دهد. Connection timeout یعنی بسته نرسیده یا جواب نیامده؛ اغلب فایروال یا مسیر شبکه.

خطای گواهی TLS — منقضی، نامعتبر، یا ناهماهنگ با دامنه — مرورگر را قبل از اعتماد به محتوا متوقف می‌کند. کاربر عادی نباید این هشدار را دور بزند. نظارت روی تاریخ انقضا باید قبل از پیام مشتریان باشد.

CORS، Timeout و خطاهای مرورگر

اشتراک منابع بین مبدأها (CORS) را مرورگر اعمال می‌کند، نه لزوماً خود سرور. در DevTools پیام blocked by CORS policy می‌آید؛ status ممکن است ۲۰۰ باشد.

موفقیت همان درخواست در Postman فقط یعنی endpoint زنده است. مجوز مرورگر را ثابت نمی‌کند.

محتوای ترکیبی (Mixed Content) وقتی است که صفحه HTTPS است ولی اسکریپت یا API روی HTTP لود می‌شود. مرورگر اسکریپت mixed را معمولاً مسدود می‌کند؛ HTML ممکن است با ۲۰۰ آمده باشد و «دکمه کار نکند».

سیاست امنیت محتوا (CSP) اگر دامنهٔ درگاه یا اسکریپت را نبسته باشد، صفحه لود می‌شود اما پرداخت یا analytics می‌خوابد. Access log باز هم ممکن است سبز باشد.

خطاهای CDN و زیرساخت

CDN می‌تواند خطای origin را به لبه نزدیک کاربر بیاورد، یا برعکس صفحهٔ سالم را از cache نشان بدهد در حالی که checkout خراب است. هر دو گمراه‌کننده‌اند.

صفحهٔ تعمیرات اگر با ۲۰۰ cache شود، هم کاربر را فریب می‌دهد هم خزنده را. 503 واقعی با کنترل cache، برای نگهداری کوتاه مناسب‌تر است.

تفاوت Frontend، Backend، Database و Infrastructure

طبقه‌بندی ۴xx و ۵xx نقطهٔ شروع است، حکم نهایی نیست. یک ۴۰۰ ممکن است باگ Frontend باشد که JSON ناقص می‌فرستد. یک ۵۰۲ ممکن است اتصال پایگاه داده پشت Load Balancer timeout داده باشد.

Frontend: نشانی غلط، روش غلط، توکن منقضی، CORS، بدنهٔ نامعتبر.

Backend: اعتبارسنجی، مجوز، منطق کسب‌وکار، exception مدیریت‌نشده.

Database: قید یکتا، deadlock، تمام شدن pool، ناسازگاری schema بعد از deploy.

Infrastructure: process کرش، گواهی TLS، ظرفیت، CDN، مهلت بین سرویس‌ها.

قید یکتای پایگاه داده را خام به ۵۰۰ تبدیل نکنید. ۴۰۹ معمولاً دقیق‌تر است. exception دیتابیس را در پاسخ عمومی نگذارید.

اثر خطاها روی تجربه کاربر و SEO

کاربر status را نمی‌خواند؛ متن و احساس بن‌بست را می‌خواند. صفحهٔ ۴۰۴ با مسیر بازگشت هنوز فروشگاه است. صفحهٔ سفید با Internal Server Error اعلام ازکارافتادگی است.

ادعاهای این بخش بر اساس مستند Google Search Central با عنوان How HTTP status codes affect Google's crawlers است. به‌روزرسانی منبع در زمان پژوهش: ۴ فوریه ۲۰۲۶.

۲xx محتوا را برای پردازش می‌فرستد؛ تضمین ایندکس نیست. بدنهٔ خالی یا شبیه خطا ممکن است soft 404 شود.

۳xx: Google به‌طور پیش‌فرض تا ۱۰ hop را دنبال می‌کند. ۳۰۱ و ۳۰۸ سیگنال قوی‌اند؛ ۳۰۲ و ۳۰۷ ضعیف‌تر.

۴xx به‌جز ۴۲۹: محتوا استفاده نمی‌شود و URL به‌تدریج از ایندکس خارج می‌شود. ۴۰۱ و ۴۰۳ ابزار کاهش crawl نیستند.

۴۲۹ مثل خطای سرور دیده می‌شود و crawl را کند می‌کند.

۵xx: crawl موقتاً کند می‌شود. URL ایندکس‌شده می‌ماند، اما اگر خطا ماندگار باشد حذف می‌شود.

یک ۴۰۴ واقعی روی صفحهٔ حذف‌شده طبیعی است. خطرناک‌تر، soft 404 است — صفحهٔ «پیدا نشد» با وضعیت ۲۰۰ — و ۵۰۰ ماندگار روی URLهای پول‌ساز.

خطاهای امنیتی

بعضی «خطا»ها در واقع تصمیم امنیتی‌اند. 401 و 403 باید به اندازهٔ کافی بگویند، اما نقشهٔ منابع را لو ندهند.

پنهان‌کردن وجود رکورد با 404، وقتی شناسه قابل حدس است، اغلب امن‌تر از 403 است. stack trace روی صفحهٔ عمومی برای مهاجم مستند است.

محدودسازی نرخ روی ورود و OTP از سوءاستفاده کم می‌کند؛ اما اگر Googlebot را هم 429 کنید، هزینهٔ آن را در crawl می‌پردازید.

چه زمانی Retry مناسب است؟

تکرار کور همهٔ خطاها را بدتر می‌کند. قاعدهٔ عملی این است:

۴xx به‌جز ۴۰۸ و ۴۲۹ را بدون تغییر تکرار نکنید.

۴۲۹ را فقط بعد از Retry-After یا backoff نمایی تکرار کنید.

۵۰۳ و بعضی ۵۰۲/۵۰۴های موقتی را می‌توان با فاصله تکرار کرد.

پرداخت، ثبت سفارش و هر عمل غیرتکرارپذیر (non-idempotent) را کورکورانه تکرار نکنید؛ اول وضعیت را بپرسید.

محصول خوب بعد از ۵۰۴ پرداخت، دکمه را از «دوباره بفرست» به «وضعیت را ببین» عوض می‌کند.

چرا نباید کاربر را با خطای خام تنها گذاشت؟

کد وضعیت برای ماشین است. انسان به سه چیز نیاز دارد: صداقت، اقدام بعدی، و مسیر پشتیبانی.

صادق باشد: «مشکلی پیش آمد» بهتر از «موفق» دروغین است. متن SQL هم محصول نیست.

قابل‌عمل باشد: وارد شوید، فایل کوچک‌تر، چند دقیقه بعد.

ایمن باشد: یک شناسهٔ حادثه برای پشتیبانی کافی است؛ مسیر فایل و نسخهٔ فریمورک نه.

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

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

• همه چیز را ۵۰۰ برگرداندن.
• 401 و 403 را عوضی گرفتن.
• 400 و 422 را یکی فرض کردن.
• صفحهٔ ۴۰۴ با وضعیت ۲۰۰.
• stack trace روی صفحهٔ عمومی.
• Retry تهاجمی روی پرداخت.
• محدود کردن Googlebot با 429 یا 403 به‌عنوان «کنترل SEO».
• نادیده گرفتن خطاهای بدون HTTP: CORS، TLS، DNS.
• Cache کردن 503 روی CDN بدون کنترل.

جمع‌بندی

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

برای مدیر: از تیم نخواهید «۵۰۰ نباشد». بخواهید خطاهای پول‌ساز دیده شوند، صفحهٔ خطا کاربر را تنها نگذارد، و خزنده نسخهٔ جعلی ۲۰۰ از صفحهٔ خراب نگیرد.

برای تیم فنی: status را بخشی از قرارداد محصول بدانید. 401 را از 403 جدا کنید، 400 را از 422، 500 را از 502 و 504.

اگر برای معماری مشاهده‌پذیری یا صفحهٔ خطای محصول مطمئن نیستید، اول مشخص کنید کدام عمل‌ها پول‌سازند و همان‌ها را اندازه بگیرید.

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

آیا ۴۰۴ برای SEO فاجعه است؟

نه به‌خودی‌خود. Google URLهای ۴۰۴ را ایندکس نمی‌کند و به‌تدریج حذف می‌کند؛ برای صفحهٔ واقعاً حذف‌شده رفتار درست است. فاجعه وقتی است که URL مهم ۴۰۴ شود و ۳۰۱ نداشته باشد، یا صفحهٔ خطا با ۲۰۰ سرو شود.

تفاوت 401 و 403 در یک جمله؟

401: هویت معتبر ارائه نشده. 403: هویت معلوم است و اجازه وجود ندارد.

چرا Postman ۲۰۰ می‌گیرد ولی مرورگر CORS می‌دهد؟

چون CORS را مرورگر اعمال می‌کند. Postman مبدأ مرورگر ندارد.

بعد از ۵۰۰ دکمه را دوباره بزنم؟

خواندن معمولاً امن است. پرداخت و ثبت سفارش را بدون دیدن وضعیت تکرار نکنید.

منابع و مراجع

RFC 9110 — HTTP Semantics: https://www.rfc-editor.org/rfc/rfc9110

RFC 6585 — Additional HTTP Status Codes: https://www.rfc-editor.org/rfc/rfc6585

MDN — HTTP response status codes: https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status

IANA HTTP Status Code Registry: https://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml

Google Search Central — How HTTP status codes affect Google's crawlers (به‌روزرسانی ۴ فوریه ۲۰۲۶): https://developers.google.com/search/docs/crawling-indexing/http-network-errors

Google Search Central — Soft 404 errors: https://developers.google.com/search/docs/crawling-indexing/soft-404-errors

Fetch Standard — CORS: https://fetch.spec.whatwg.org/#http-cors-protocol

MDN — Mixed content: https://developer.mozilla.org/en-US/docs/Web/Security/Mixed_content