Loading...

مبانی · 7 دقیقه مطالعه

کدهای وضعیت HTTP: آن‌ها را به‌شکل «چه‌کسی رد کرد، و کجا» بخوانید

هر مرجعی فهرست می‌کند که کدها چه معنایی دارند. تقریباً هیچ‌کدام نمی‌گویند کدام ماشین آن‌ها را صادر می‌کند — و روی سایتی پشت یک CDN، همین سؤالی است که دیباگ را از یک بعدازظهر به یک دقیقه کوتاه می‌کند. این همان فهرست از زاویهٔ دید proxy است.

به‌روزرسانی

کدهای وضعیت HTTP: آن‌ها را به‌شکل «چه‌کسی رد کرد، و کجا» بخوانید

دسته‌ها، به‌اختصار

2xx — کار کرد. 200 OK پاسخ عادی است. 204 No Content یک درخواست موفق است که چیزی برای برگرداندن ندارد، رایج برای APIها. 206 Partial Content یک range request است، که همان چیزی است که seekکردن ویدیو و دانلودهای قابل‌ازسرگیری را ممکن می‌کند.

3xx — جای دیگری نگاه کنید. 301 دائمی است و سیگنال‌های رتبه را منتقل می‌کند؛ 302 موقت است و این کار را نمی‌کند. 304 Not Modified آرام‌ترین است: کلاینت از قبل یک نسخهٔ معتبر دارد، پس بدنه اصلاً فرستاده نمی‌شود. یک سایت سالم تعداد زیادی 304 سرویس می‌دهد.

4xx — درخواست رد شد. 400 بدشکل است، 401 اعتبارنامه می‌خواهد، 403 یک رد شدنِ عمدی است، 404 پیدا نشده، 410 عمداً رفته، 429 درخواست بیش‌ازحد زیاد است.

5xx — سمت سرور شکست خورد. 500 یک خطای مدیریت‌نشده است، 502 یک گفت‌وگوی خراب با ماشین پشتی است، 503 یک رد شدنِ موقت است، 504 یک timeout در انتظار ماشین پشتی است.

کدام hop آن کد را تولید کرد

یک درخواست پشت یک CDN از میان دست‌کم سه جا عبور می‌کند که می‌توانند به آن پاسخ دهند: edge، وب‌سرور origin شما، و اپلیکیشن شما. هرکدام می‌توانند کدهایی تولید کنند که بقیه نمی‌توانند.

فقط edge می‌تواند تولید کند: یک cache hit که وقتی origin پایین است سرویس داده می‌شود، یک 502 یا 504 دربارهٔ origin شما، یک 403 از یک قانون WAF یا یک مسدودسازی جغرافیایی، و یک 503 که می‌گوید هیچ سرویسی برای هاست‌نیم پیکربندی نشده.

فقط وب‌سرور origin شما تولید می‌کند: 403 از مجوزهای فایل یا یک قانون deny، 404 برای مسیری که روی دیسک وجود ندارد، 413 برای بدنه‌ای بزرگ‌تر از آنچه می‌پذیرد.

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

پس اولین سؤال تشخیصی این نیست که «502 یعنی چه»، بلکه این است که «آیا این درخواست اصلاً به origin من رسیده». اگر در لاگ دسترسی origin ظاهر نمی‌شود، هیچ تغییری که روی origin بدهید رویش اثر نمی‌گذارد.

خواندن هدرها برای پیداکردن hop

پاسخ به شما می‌گوید چه‌کسی آن را مدیریت کرده، اگر به‌جای صفحه به هدرها نگاه کنید.

curl -sI https://example.com/

یک هدر وضعیت cache — در cdn.com.tr، X-Proxy-Cache-MT با HIT یا MISS — یعنی edge درخواست را پردازش کرده. یک HIT یعنی اصلاً با origin مشورت نشده، که وقتی دارید یک تغییر را تست می‌کنید و هنوز رفتار قدیمی را می‌بینید ارزش دانستن دارد.

دو تله اینجا زندگی می‌کنند. اول: curl -I یک درخواست HEAD می‌فرستد، و برخی سرورها و middlewareها برای HEAD متفاوت از GET رفتار می‌کنند، پس هدری که روی -I ظاهر می‌شود ممکن است روی یک GET واقعی غایب باشد و برعکس. وقتی اهمیت دارد، از curl -sD - -o /dev/null با یک GET عادی استفاده کنید. دوم: یک پاسخ خطای cacheشده بعد از رفع علت همچنان سرویس داده می‌شود. اگر کد بعد از یک رفع مشکل تغییر نمی‌کند، پیش از ادامهٔ دیباگ، مسیر را purge کنید.

کدهایی که ارزش پیکربندی‌کردن عمدی دارند

301 در برابر 302. وقتی جابه‌جایی دائمی است از 301 استفاده کنید — رتبهٔ آدرس قدیمی را در آدرس جدید تثبیت می‌کند. یک 302 آدرس قدیمی را به‌عنوان canonical نگه می‌دارد، که همان چیزی است که برای یک ریدایرکت موقت کمپین می‌خواهید و نه چیزی که بعد از بازسازی یک سایت می‌خواهید. ریدایرکت‌ها در edge cache می‌شوند، پس یک ریدایرکت اشتباه از خودِ استقراری که آن را معرفی کرده بیشتر عمر می‌کند.

404 در برابر 410. هر دو می‌گویند «اینجا نیست». یک 410 می‌گوید «و برنمی‌گردد»، که باعث می‌شود آدرس سریع‌تر از ایندکس کنار گذاشته شود. برای صفحات محصول بازنشسته‌شده، 410 کد صادقانه است.

503 همراه با Retry-After. در طول نگهداری، این همان جفتی است که خزنده‌ها را صبور نگه می‌دارد. یک صفحهٔ نگهداری که با 200 سرویس داده شود به آن‌ها می‌گوید اعلان نگهداری شما همان محتوای شماست.

429 برای rate limitها. وقتی رد شدن دربارهٔ سرعت درخواست این کلاینت است، از 503 صادقانه‌تر است. هر استکی آن را به‌صورت پیش‌فرض نمی‌فرستد — rate limiting در nginx مگر پیکربندی شود جور دیگری، 503 برمی‌گرداند.

کدهای وضعیتی که واقعاً برایشان وقت می‌گذارید

در عمل سه کد بیشتر زمان دیباگ روی سایتی پشت یک proxy را به خود اختصاص می‌دهند، و هرکدام راهنمای خودشان را دارند:

**502 Bad Gateway** — edge نتوانسته پاسخ قابل‌استفاده‌ای از origin شما بگیرد. چهار علت: کانکشن ردشده، بسته‌شدن زودهنگام، شکست handshake TLS، پاسخ بدشکل.

**403 Forbidden** — چیزی عمداً رد کرده. پنج تصمیم‌گیرندهٔ ممکن: origin شما، یک قانون WAF، مسدودسازی کشوری یا شبکه‌ای، محافظت هات‌لینک، یک لیست IP. یک reference ID روی صفحهٔ خطا همان چیزی است که حدس‌زدن را به جست‌وجوکردن تبدیل می‌کند.

**503 Service Unavailable** — یک رد شدنِ موقت: overload، نگهداری، یک rate limit، یا یک edge بدون originی پیکربندی‌شده برای آن هاست‌نیم.

چهارمی، 504، دوقلوی timeout برای 502 است و در راهنمای 502 پوشش داده شده، چون تشخیص آن‌ها از هم بیشتر کار است.

پرسش‌های پرتکرار

کدام کدهای وضعیت واقعاً روی SEO اثر می‌گذارند؟

آن‌هایی که چیزی را که ایندکس می‌شود تغییر می‌دهند: 301 یک آدرس را در مقصدش تثبیت می‌کند، 302 این کار را نمی‌کند، 404 و 410 یک آدرس را حذف می‌کنند و 410 سریع‌تر است، و یک 5xx طولانی‌مدت در نهایت صفحه را کنار می‌گذارد. یک 200 که روی یک صفحهٔ خطا سرویس داده شود همان آسیب‌رسان بی‌سروصداست، چون متن خطا به‌عنوان محتوا ایندکس می‌شود.

چرا از curl کد متفاوتی از مرورگرم می‌گیرم؟

درخواست‌ها متفاوت‌اند. مرورگر شما کوکی، یک user agent متفاوت و یک هدر Accept می‌فرستد؛ curl معمولاً هیچ‌کدام از این‌ها را نمی‌فرستد. روی سایتی با یک WAF یا یک login cookie bypass، این تفاوت‌ها تصمیم را تغییر می‌دهند. پیش از هر نتیجه‌گیری‌ای، مشابه را با مشابه مقایسه کنید.

آیا 304 یک خطاست؟

نه، بهترین نتیجه بعد از یک cache hit است: کلاینت از قبل یک نسخهٔ معتبر دارد و سرور اصلاً بدنه‌ای نمی‌فرستد. تعداد زیاد 304 در لاگ‌های شما یعنی conditional requestها دارند کار می‌کنند.

یک وضعیت 000 یا خالی در مانیتورینگ من یعنی چه؟

یعنی هیچ پاسخ HTTPای برای خواندن نبوده: DNS resolve نشده، کانکشن TCP شکست خورده، یا TLS مذاکره نکرده. یک مشکل اتصال‌پذیری است نه یک مشکل اپلیکیشن، و ارزش دارد در هر سیستم هشداردهی‌ای که دارید آن را از یک 5xx متمایز کنید.