چک هاست: راهنمای کامل بررسی آنلاین بودن هاست و سایت شما

به‌روزرسانی: شهریور ۱۴۰۵

ساعت ۱۱ شب است، مشتری پیام می‌دهد «سایتتون بالا نمیاد». شما آدرس را می‌زنید و سایت کاملاً سالم باز می‌شود. حالا کدامتان درست می‌گویید؟

جواب معمولاً این است: هر دو. «بالا نیامدن سایت» یک اتفاق واحد نیست؛ دست‌کم چهار لایه‌ی مستقل وجود دارد که هرکدام می‌توانند جداگانه خراب شوند — سرور، DNS، گواهی SSL و مسیر شبکه‌ی کاربر. چک هاست یعنی به‌جای حدس زدن، این لایه‌ها را یکی‌یکی و به ترتیب تست کنید تا در چند دقیقه بفهمید ایراد از کجاست.

این موضوع فقط یک دردسر فنی نیست. اگر قرارداد هاست شما آپ‌تایم ۹۹.۹٪ را در بازه‌ی ماهانه تضمین کرده باشد، سقف قطعی مجاز چیزی حدود ۴۳ دقیقه و ۴۸ ثانیه در ماه است — یعنی یک قطعی یک‌ساعته‌ی ساده، همان تضمین را نقض می‌کند (منبع). بدون چک و ثبت دقیق، شما حتی نمی‌دانید که حقی برای پیگیری دارید.

چک هاست دقیقاً یعنی چه و چه چیزی را باید تست کنیم؟

چک هاست یعنی بررسی سیستماتیک اینکه سرور شما به درخواست‌ها پاسخ می‌دهد، دامنه به IP درست اشاره می‌کند، گواهی SSL معتبر است و وب‌سرور کد وضعیت ۲۰۰ برمی‌گرداند. اگر هر چهار مورد سالم باشد، هاست آنلاین است — حتی اگر یک کاربر خاص سایت را نبیند.

تفکیک این چهار لایه مهم‌ترین کار است، چون هر لایه راه‌حل کاملاً متفاوتی دارد:

لایه	علامت خرابی	مسئول رفع
سرور / هاست	تایم‌اوت، خطای ۵۰۰ یا ۵۰۳	شرکت هاستینگ
DNS و نیم‌سرور	«سایت پیدا نشد»، DNS_PROBE_FINISHED	ثبت‌کننده دامنه / پنل DNS
SSL	هشدار «اتصال امن نیست»	هاست یا مدیر سایت
اپلیکیشن (وردپرس، افزونه، دیتابیس)	صفحه سفید، خطای اتصال به دیتابیس	مدیر سایت
شبکه‌ی کاربر	فقط برای بعضی کاربران قطع است	ISP کاربر

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

سریع‌ترین روش‌ها برای فهمیدن اینکه مشکل از هاست است یا از اینترنت خودتان

در ۹۰ ثانیه: سایت را از یک شبکه‌ی دیگر (مثلاً دیتای موبایل) باز کنید، سپس با یک ابزار آنلاین بررسی آپ‌تایم از چند نقطه‌ی جهان تست بگیرید. اگر از شبکه‌ی دوم و از سرورهای خارجی سالم بود، هاست آنلاین است و مشکل محلی است.

ترتیب پیشنهادی، از ساده به فنی:

1. تست شبکه‌ی دوم. وای‌فای را قطع کنید و با دیتای موبایل امتحان کنید. تفاوت نتیجه یعنی مشکل در شبکه یا DNS محلی شماست.
2. مرورگر ناشناس یا مرورگر دیگر. کش و افزونه‌های مرورگر خودشان منبع خطای کاذب‌اند.
3. تست از چند نقطه‌ی جغرافیایی. سرویس‌های آنلاین بررسی وضعیت سایت به شما می‌گویند سایت برای بقیه‌ی دنیا هم قطع است یا نه.
4. پینگ به IP سرور. اگر پینگ جواب می‌دهد ولی سایت باز نمی‌شود، سرور روشن است و مشکل در وب‌سرور یا اپلیکیشن است، نه در ماشین.

دستور مفید و کم‌استفاده در ویندوز، مک و لینوکس:

curl -I https://example.com

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

برای دیدن اینکه ترافیک شما دقیقاً کجا متوقف می‌شود:

tracert example.com        (ویندوز)
traceroute example.com     (لینوکس / مک)

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

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

کد وضعیت، تشخیص افتراقی سریع شماست: خطاهای ۵xx یعنی سرور مشکل دارد، ۴xx یعنی سرور سالم است ولی درخواست را رد کرده، و نبود هرگونه کد (تایم‌اوت) یعنی حتی به وب‌سرور نرسیده‌اید.

• ۲۰۰ OK — همه‌چیز سالم. اگر همچنان سایت را نمی‌بینید، مشکل سمت مرورگر یا شبکه‌ی شماست.
• ۳۰۱ / ۳۰۲ — ریدایرکت. اگر بی‌نهایت تکرار شود، معمولاً تنظیمات SSL یا .htaccess مقصر است، نه سرور.
• ۴۰۳ Forbidden — سرور بالاست ولی دسترسی بسته است: مجوزهای فایل، فایروال یا قانون امنیتی.
• ۵۰۰ Internal Server Error — خطای اپلیکیشن. در وردپرس معمولاً یک افزونه، قالب یا محدودیت حافظه‌ی PHP.
• ۵۰۲ / ۵۰۴ — سرور واسط جواب گرفته نیست؛ نشانه‌ی فشار منابع یا کند بودن PHP و دیتابیس.
• ۵۰۳ Service Unavailable — سرور عمداً می‌گوید «موقتاً در دسترس نیستم». وردپرس هم هنگام به‌روزرسانی افزونه یا هسته همین را برمی‌گرداند.
• بدون پاسخ / Connection timed out — بدترین حالت: سرور خاموش است، فایروال ترافیک را می‌بلعد یا DNS به IP اشتباهی اشاره می‌کند.

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

هاست بالاست ولی سایت باز نمی‌شود؛ حالا چه؟

در این حالت تقریباً همیشه یکی از این سه مورد است: نیم‌سرورها یا رکورد A به مقصد اشتباه اشاره می‌کنند، گواهی SSL منقضی شده، یا اپلیکیشن بالا نمی‌آید. هر سه از سمت شما قابل بررسی‌اند.

۱. DNS و ماجرای «پروپگیشن». بعد از تغییر نیم‌سرور یا رکورد A، تغییر بلافاصله همه‌جا دیده نمی‌شود. علتش هم انتشار نیست، بلکه کش است: هر ریزالور تا پایان مقدار TTL همان جواب قدیمی را تحویل می‌دهد. در کلودفلر، رکوردهای پروکسی‌شده TTL ثابت ۳۰۰ ثانیه دارند، ولی کش محلی خود کاربر می‌تواند بیشتر طول بکشد (منبع).

نتیجه‌ی عملی: قبل از هر مهاجرت هاست، TTL رکوردها را به ۳۰۰ ثانیه کاهش دهید — نه بعدش. این کار پنجره‌ی سردرگمی را از یک روز به چند دقیقه کوتاه می‌کند و رایگان است.

برای پاک کردن کش DNS دستگاه خودتان:

ipconfig /flushdns              (ویندوز)
sudo dscacheutil -flushcache    (مک)

۲. SSL منقضی‌شده. گواهی‌های رایگان معمولاً سه‌ماهه‌اند و تمدید خودکارشان گاهی بی‌سروصدا شکست می‌خورد. علامتش واضح است: مرورگر صفحه‌ی هشدار امنیتی نشان می‌دهد در حالی که سرور کاملاً سالم است.

۳. اپلیکیشن. صفحه‌ی سفید یا خطای اتصال به دیتابیس یعنی وب‌سرور جواب می‌دهد ولی وردپرس بالا نمی‌آید. اینجا مقصر معمولاً به‌روزرسانی نیمه‌کاره، افزونه‌ی ناسازگار یا پر شدن فضای دیسک است. اگر روی هاست وردپرس با بک‌آپ روزانه باشید، برگرداندن نسخه‌ی دیروز چند دقیقه طول می‌کشد؛ روی هاست بدون بک‌آپ، همان اتفاق می‌تواند یک روز کاری را ببلعد.

چک هاست از نگاه گوگل: چیزی که در مرورگر نمی‌بینید

سرچ کنسول، لاگ مستقل شما از قطعی‌هاست. گزارش Crawl Stats نشان می‌دهد خزنده‌ی گوگل در چه روزهایی خطای سرور گرفته — حتی قطعی‌هایی که شما اصلاً متوجهشان نشدید.

دو گزارش را ببینید:

• Settings ← Crawl stats: جهش ناگهانی در پاسخ‌های ناموفق، یعنی سرور در آن بازه پاسخگو نبوده.
• Indexing ← Pages: فیلتر روی خطای سرور، فهرست دقیق آدرس‌هایی را می‌دهد که گوگل نتوانسته بخواند.

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

آپ‌تایم ۹۹.۹٪ در قرارداد هاست دقیقاً چقدر قطعی است؟

۹۹.۹٪ در بازه‌ی ماهانه یعنی حداکثر حدود ۴۳ دقیقه قطعی در ماه؛ همان عدد در بازه‌ی سالانه یعنی سرور می‌تواند یک روز کاری کامل قطع باشد و باز هم قرارداد نقض نشده باشد.

این تفاوت بازه، مهم‌ترین جزئیاتی است که در تبلیغات هاست گفته نمی‌شود. اگر تضمین آپ‌تایم روی میانگین سالانه محاسبه شود، ارائه‌دهنده فضای مانور بسیار بیشتری برای یک قطعی طولانی دارد؛ محاسبه‌ی ماهانه دست او را می‌بندد (منبع).

سه سؤالی که قبل از خرید باید بپرسید:

• تضمین آپ‌تایم ماهانه است یا سالانه؟
• پنجره‌ی «تعمیرات برنامه‌ریزی‌شده» از محاسبه خارج می‌شود؟ چند ساعت در ماه؟
• جبران خسارت چیست و چطور باید مطالبه شود؟

به‌جای چک دستی، مانیتورینگ دائمی راه بیندازید

چک دستی فقط لحظه‌ی حال را نشان می‌دهد. یک مانیتور آپ‌تایم که هر ۱ تا ۵ دقیقه سایت را تست می‌کند، هم قطعی را قبل از مشتری به شما خبر می‌دهد و هم مدرک مستند برای پیگیری با هاست می‌سازد.

حداقل تنظیماتی که ارزش وقت گذاشتن دارد:

• فاصله‌ی چک ۱ تا ۵ دقیقه. فاصله‌های ۳۰ دقیقه‌ای قطعی‌های کوتاه را کامل از دست می‌دهند.
• چک محتوا، نه فقط کد ۲۰۰. مانیتور را طوری تنظیم کنید که وجود یک عبارت مشخص در صفحه را بررسی کند؛ وگرنه یک صفحه‌ی خالی که کد ۲۰۰ برمی‌گرداند «سالم» شمرده می‌شود.
• مانیتور جدا برای SSL و انقضای دامنه. این دو خرابی برنامه‌پذیرند و کاملاً قابل پیشگیری.
• هشدار از مسیری غیر از ایمیل همان دامنه. اگر ایمیل شما روی همان سرور باشد، هشدار قطعی هرگز به دستتان نمی‌رسد.

اگر مجبورید سایت را موقتاً پایین بیاورید

کد درست برای قطعی موقت، ۵۰۳ به همراه هدر Retry-After است — نه ۲۰۰ و نه ۴۰۴. گوگل ۵۰۳ را «موقت» می‌فهمد و بعداً برمی‌گردد، ولی این مهلت نامحدود نیست.

مستندات رسمی گوگل صریح است: اگر ناچارید سایت را فوری و برای یک تا دو روز از دسترس خارج کنید، صفحه‌ای اطلاع‌رسانی با کد ۵۰۳ برگردانید؛ و برای بازه‌های طولانی‌تر، به‌جای ۵۰۳ یک صفحه‌ی اصلی قابل ایندکس با کد ۲۰۰ نگه دارید (منبع). گوگل صفحات ۵۰۳ را حدود یک هفته دوباره امتحان می‌کند و بعد از آن فرض را بر حذف دائمی می‌گذارد (منبع).

دو خطای پرهزینه که باید از آن‌ها دور بمانید:

• فایل robots.txt را با کد ۵۰۳ سرو نکنید. نتیجه‌اش توقف کامل خزش کل سایت است، نه فقط مکث موقت.
• صفحه‌ی «در دست تعمیر» را با کد ۲۰۰ منتشر نکنید. گوگل ممکن است همان را به‌عنوان محتوای واقعی صفحه ثبت کند.

خبر خوب اینکه وردپرس هنگام به‌روزرسانی افزونه و هسته به‌صورت پیش‌فرض همین ۵۰۳ را برمی‌گرداند؛ مشکل معمولاً وقتی پیش می‌آید که افزونه‌های «حالت تعمیر» شخص ثالث، کد ۲۰۰ برگردانند.

چک‌لیست ۵ دقیقه‌ای چک هاست

هر بار که گزارش «سایت بالا نمیاد» گرفتید، به همین ترتیب پیش بروید:

1. از شبکه‌ی دوم و مرورگر ناشناس تست کنید.
2. curl -I بزنید و کد وضعیت واقعی را ببینید.
3. اگر تایم‌اوت بود: پینگ به IP و بعد traceroute.
4. رکورد A و نیم‌سرورها را با پنل دامنه مقایسه کنید.
5. تاریخ انقضای SSL را چک کنید.
6. اگر همه سالم بود ولی سایت خطا می‌دهد: لاگ خطای هاست را باز کنید، نه پنل ارتقای پلن را.
7. زمان دقیق شروع و پایان قطعی را ثبت کنید — این همان چیزی است که در پیگیری SLA به کار می‌آید.

سؤالات پرتکرار

چطور بفهمم سایت فقط برای من قطع است یا برای همه؟ سایت را از دیتای موبایل و از یک ابزار تست چندمنطقه‌ای امتحان کنید. اگر از سرورهای خارجی کد ۲۰۰ برمی‌گردد ولی شما نمی‌بینید، مشکل در مسیر شبکه یا کش DNS خود شماست.

بعد از تغییر نیم‌سرور چقدر باید صبر کنم؟ به TTL رکوردها بستگی دارد، نه به یک عدد ثابت. با TTL پنج‌دقیقه‌ای معمولاً چند دقیقه کافی است؛ با TTL بلند ممکن است تا یک شبانه‌روز طول بکشد. اگر تغییر را از قبل برنامه‌ریزی کرده‌اید، TTL را ۲۴ ساعت قبل کم کنید.

خطای ۵۰۰ یعنی هاستم ضعیف است؟ نه لزوماً. ۵۰۰ خطای سمت اپلیکیشن است — افزونه، قالب یا محدودیت PHP. قبل از ارتقای پلن، افزونه‌ی اخیراً نصب‌شده را غیرفعال کنید و لاگ خطا را بخوانید.

قطعی کوتاه به سئوی من ضربه می‌زند؟ قطعی چنددقیقه‌ای عملاً بی‌اثر است؛ احتمال اینکه خزنده دقیقاً همان لحظه سر بزند پایین است. خطر واقعی از قطعی‌های چندروزه شروع می‌شود که گوگل آن‌ها را دائمی تلقی می‌کند.

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

سرور بالاست ولی سایت خیلی کند است؛ این هم قطعی حساب می‌شود؟ از نظر فنی نه، ولی از نظر کاربر و خزنده تقریباً بله. اگر پاسخ سرور مرتب به مرز تایم‌اوت نزدیک شود، همان اثر قطعی را می‌گذارد. کندی پایدار را جدی بگیرید.

جمع‌بندی

چک هاست یک مهارت است، نه یک دکمه. کسی که ترتیب درست را بلد باشد — شبکه، DNS، SSL، اپلیکیشن — در پنج دقیقه به جواب می‌رسد؛ کسی که نداند، یک شب کامل بین پشتیبانی هاست و توسعه‌دهنده تلفن می‌زند و آخرش هم پلنش را بی‌دلیل ارتقا می‌دهد.

اگر تست‌ها را گرفتید و هنوز مطمئن نیستید که ریشه‌ی مشکل منابع سرور است، تنظیمات DNS یا خود سایت، لازم نیست حدس بزنید: در مشاوره رایگان سئونامی می‌توانیم خروجی همین تست‌ها را با هم مرور کنیم و بگوییم واقعاً کجا باید هزینه کنید — و کجا لازم نیست.