خطای 503 در وردپرس یعنی سرور در همان لحظه آماده پاسخ‌گویی به درخواست نیست. اگر بازدیدکننده به‌جای سایت عبارت Service Unavailable می‌بیند، ابتدا زمان شروع، صفحات درگیر و آخرین تغییرات را ثبت کنید؛ سپس منابع هاست، وضعیت PHP و افزونه‌ها را بررسی کنید. تغییر هم‌زمان چند تنظیم، پیدا کردن علت را سخت‌تر می‌کند.
این راهنما برای مدیر سایتی نوشته شده که می‌خواهد بفهمد مشکل از وردپرس است، از ظرفیت میزبانی می‌آید یا در لایه‌ای مانند CDN رخ داده است. هدف، بازگرداندن سایت با یک اقدام قابل پیگیری و جلوگیری از تکرار اختلال است.
خطای 503 چیست و چه تفاوتی با خطاهای دیگر دارد؟
کد HTTP 503 نشان‌دهنده در دسترس نبودن موقت سرویس است. سرور ممکن است در حال نگهداری باشد یا ظرفیت کافی برای پردازش درخواست تازه نداشته باشد. دیدن این کد به‌تنهایی ثابت نمی‌کند که هاست ضعیف است یا افزونه‌ای خراب شده؛ برای نتیجه‌گیری باید زمان خطا را با گزارش‌های همان بازه مقایسه کرد. تعریف فنی این وضعیت در مستندات HTTP در MDN آمده است.
خطای 500 معمولاً یک خطای عمومی سمت سرور است. در 502، دروازه یا پراکسی پاسخ نامعتبر از سرویس پشت خود دریافت می‌کند؛ در 504 نیز منتظر ماندن برای پاسخ آن سرویس به پایان می‌رسد. این تفاوت‌ها برای انتخاب مسیر بررسی مفیدند، اما معماری و تنظیمات میزبان می‌تواند شکل خطای نهایی را تغییر دهد. برای آشنایی با پایه موضوع، راهنمای درخواست، پاسخ و کدهای وضعیت HTTP را بخوانید.
پیش از هر تغییر، محدوده اختلال را مشخص کنید
صفحه اصلی، یک نوشته، صفحه ورود و یک فایل تصویری موجود را جداگانه باز کنید. نتیجه را در یک مرورگر خصوصی و در صورت امکان یک اتصال اینترنت دیگر هم بسنجید. اگر تصاویر باز می‌شوند ولی صفحات پویا خطا دارند، مسیر اجرای PHP و برنامه ارزش بررسی بیشتری دارد؛ البته کش یا CDN می‌تواند نتیجه این مقایسه را تحت تأثیر قرار دهد.
زمان دقیق همراه منطقه زمانی، نشانی صفحه، متن خطا و اینکه ورود به پیشخوان ممکن است یا نه را یادداشت کنید. مشخص کنید مشکل دائمی است یا هنگام جست‌وجو، خرید، بکاپ‌گیری یا افزایش بازدید ظاهر می‌شود. پیش از تغییر فایل‌ها و افزونه‌ها، نسخه پشتیبان قابل بازیابی و راه دسترسی به مدیریت فایل هاست داشته باشید. در فروشگاه فعال، سفارش‌های تازه را هنگام تصمیم برای بازیابی بکاپ در نظر بگیرید.
راهنمای سریع تشخیص خطای 503 در وردپرس
| نشانه مشاهده‌شده | بررسی بعدی | اقدام متناسب |
|---|---|---|
| شروع خطا بلافاصله پس از به‌روزرسانی | لاگ PHP و نام مؤلفه تغییرکرده | آزمون همان افزونه یا قالب در محیط آزمایشی |
| اختلال در ساعت‌های پرترافیک | مصرف منابع و محدودیت درخواست‌های هم‌زمان | کاهش عملیات سنگین و بررسی ظرفیت واقعی |
| نمایش خطا فقط پشت CDN | گزارش پراکسی و پاسخ مبدأ با کمک میزبان | اصلاح ارتباط یا تنظیم کش در لایه مربوط |
| خطای هم‌زمان در چند سایت روی یک سرویس | وضعیت وب‌سرور و سرویس PHP | ارجاع شواهد به پشتیبانی میزبانی |
| تکرار هنگام اجرای بکاپ یا درون‌ریزی | زمان‌بندی کارها و فشار پردازش و دیسک | جدا کردن زمان اجرای وظایف سنگین |
۱. منابع هاست را در زمان وقوع خطا بررسی کنید
در کنترل‌پنل میزبان، بخش آمار مصرف یا Resource Usage را پیدا کنید؛ نام و دسترسی این بخش به نوع سرویس بستگی دارد. مصرف CPU، حافظه، ورودی و خروجی دیسک و تعداد پردازش‌ها یا درخواست‌های هم‌زمان را برای همان دقیقه‌های اختلال ببینید. عدد مصرف فعلی، پس از پایان خطا، لزوماً توضیح‌دهنده اتفاق گذشته نیست. اگر نمودار یا سابقه محدودیت‌ها در پنل ندارید، این اطلاعات را از پشتیبانی بخواهید.
برای مثال، اگر فروشگاه هر شب هم‌زمان با بکاپ کامل و به‌روزرسانی موجودی خطا می‌دهد، ابتدا زمان این دو کار را جدا کنید و نتیجه را در نوبت بعدی بسنجید. افزایش حافظه PHP جایگزین بررسی ظرفیت حساب میزبانی نیست؛ اگر مجموع پردازش‌ها از سهم منابع عبور کند، بالاتر بردن یک مقدار ممکن است کمکی نکند. ارتقای سرویس زمانی تصمیم دقیق‌تری است که علت فشار و میزان نیاز مشخص شده باشد.
۲. افزونه‌ای را که شواهد به آن اشاره دارد آزمایش کنید
اگر خطا پس از نصب یا به‌روزرسانی افزونه شروع شده، همان افزونه نقطه شروع مناسبی است. در صورت دسترسی به پیشخوان، ابتدا در محیط آزمایشی وردپرس آن را غیرفعال و عملیات مشکل‌دار را تکرار کنید. باز شدن صفحه اصلی کافی نیست؛ اگر مشکل هنگام ثبت سفارش بوده، همان مسیر باید دوباره بررسی شود.
اگر پیشخوان باز نمی‌شود، مدیر فنی می‌تواند پس از تهیه بکاپ، پوشه همان افزونه را در مسیر wp-content/plugins موقتاً تغییر نام دهد. نام اولیه را ثبت کنید و فایل‌ها را حذف نکنید. این روش برای همه اجزای سایت کافی نیست؛ افزونه‌های اجباری و بعضی فایل‌های کش جداگانه بارگذاری می‌شوند. غیرفعال‌سازی جمعی افزونه‌ها روی فروشگاه زنده نیز می‌تواند پرداخت و امکانات ضروری را متوقف کند، بنابراین آزمون گسترده را در نسخه آزمایشی انجام دهید.
۳. وضعیت قالب و اجرای PHP را جداگانه بررسی کنید
قالب یا کد سفارشی ناسازگار می‌تواند پردازش‌های طولانی یا خطاهای اجرایی ایجاد کند. اگر تغییر اخیر مربوط به قالب بوده، در محیط آزمایشی با یک قالب استاندارد سازگار مقایسه کنید. تعویض قالب سایت اصلی ممکن است چیدمان، ابزارک‌ها یا بخش‌هایی از فروشگاه را تغییر دهد؛ برای آزمون، مسیر برگشت روشن داشته باشید.
در سمت سرور، پر شدن ظرفیت پردازش‌های PHP، توقف سرویس یا اختلال ارتباط وب‌سرور با PHP نیز باید بررسی شود. در هاست اشتراکی معمولاً مدیریت این بخش با میزبان است. از پشتیبانی بخواهید گزارش سرویس را در زمان دقیق خطا بررسی کند. راه‌اندازی مجدد سرویس شاید دسترسی را موقتاً برگرداند، اما بدون یافتن علت، اختلال می‌تواند تکرار شود. اگر مسئله بیشتر به کندی بخش مدیریت محدود است، مقاله رفع کندی پیشخوان وردپرس مسیر مرتبط‌تری ارائه می‌کند.
۴. لاگ‌ها را بخوانید و از نتیجه عجولانه پرهیز کنید
گزارش خطای وب‌سرور و PHP را با ساعت درخواست ناموفق تطبیق دهید. نام یک افزونه در لاگ، سرنخ است؛ هر هشدار قدیمی علت 503 نیست. به تکرار رخداد، مسیر فایل، نوع خطا و هم‌زمانی آن با اختلال توجه کنید. اگر گزارش خطای اتصال دیتابیس دیده می‌شود، از راهنمای تشخیص خطای اتصال وردپرس به پایگاه داده کمک بگیرید.
برای بررسی کد وردپرس در محیط آزمایشی می‌توان از ابزارهای ثبت خطا استفاده کرد. طبق راهنمای رسمی دیباگ وردپرس، این ابزارها برای توسعه و عیب‌یابی هستند و نمایش خطا به بازدیدکننده مناسب سایت اصلی نیست. فایل لاگ ممکن است اطلاعات حساس داشته باشد؛ دسترسی عمومی به آن را ببندید و هنگام ارسال برای پشتیبانی، رمزها، اطلاعات مشتری و داده‌های محرمانه را حذف کنید. پس از پایان بررسی، ثبت خطای موقت را متوقف کنید.
۵. CDN، کش و ترافیک غیرعادی را بررسی کنید
اگر سایت پشت پراکسی یا CDN است، صفحه 503 ممکن است از همان لایه تولید شده باشد. متن صفحه و هدرهای پاسخ برای تشخیص مفیدند، ولی همیشه علت را قطعی نشان نمی‌دهند. وضعیت ارتباط با سرور مبدأ را با کمک پشتیبانی و بدون تغییر عمومی DNS بررسی کنید. خاموش کردن کامل فایروال برای آزمایش، دامنه بررسی را بیش از نیاز گسترش می‌دهد؛ بهتر است قانون یا رخداد مشخص بررسی شود.
کش صفحات عمومی می‌تواند تعداد درخواست‌هایی را که به PHP می‌رسند کاهش دهد. با این حال، صفحه حساب کاربری، سبد خرید و پرداخت به تنظیمات درست استثناها نیاز دارند. پاک‌سازی مکرر کل کش هم بار بازسازی صفحات را بالا می‌برد. اگر پاسخ خطا در کش باقی مانده، پس از رفع علت، کش همان لایه و همان نشانی را کنترل کنید. در بررسی ترافیک غیرعادی نیز به تعداد درخواست، نشانی‌های هدف و الگوی تکرار توجه کنید؛ افزایش بازدید به‌تنهایی به معنی حمله نیست.
خطای 503 چه اثری بر سئو دارد؟
طبق مستندات گوگل درباره کدهای HTTP، خطاهای سمت سرور می‌توانند باعث کاهش موقت سرعت خزش شوند و تداوم آن‌ها ممکن است به حذف نشانی‌ها از ایندکس منجر شود. برای اختلال برنامه‌ریزی‌شده، پاسخ واقعی 503 با زمان تخمینی معتبر در هدر Retry-After می‌تواند وضعیت موقت را توضیح دهد. نمایش یک صفحه خطا با پاسخ 200، گزارش درستی از وضعیت سرویس نیست.
پس از رفع مشکل، پاسخ صفحات اصلی را بررسی و گزارش‌های Search Console را دنبال کنید. یک قطعی کوتاه لزوماً به معنی افت دائمی رتبه نیست و زمان ثابتی برای اثرگذاری همه اختلال‌ها وجود ندارد. اولویت عملی، کوتاه کردن مدت قطعی و جلوگیری از تکرار آن است.
برای پشتیبانی هاست چه اطلاعاتی بفرستیم؟
یک درخواست دقیق شامل دامنه، نشانی نمونه، ساعت خطا با منطقه زمانی، تصویر پیام، آخرین تغییر و نتیجه آزمون‌های انجام‌شده است. برای نمونه بنویسید: «امروز ساعت ۱۴:۲۰ به وقت تهران، صفحه پرداخت 503 داد؛ تصویر محصول باز می‌شد؛ خطا هنگام اجرای بکاپ تکرار شد؛ لطفاً محدودیت منابع و لاگ PHP همان بازه بررسی شود.» این توضیح از عبارت کلی «سایت باز نمی‌شود» کاربردی‌تر است.
برای بررسی اولیه دامنه، HTTPS و برخی شاخص‌های زیرساخت می‌توانید از ابزار بررسی سلامت سایت آفاق هاست استفاده کنید؛ تشخیص علت داخلی PHP همچنان به لاگ میزبان نیاز دارد. اگر اختلال مرتب تکرار می‌شود، از بخش تماس و مشاوره آفاق هاست برای بررسی نیاز میزبانی و مسیر بهبود کمک بگیرید.
پرسش‌های رایج درباره رفع خطای 503 در وردپرس
آیا پاک کردن کش مرورگر مشکل را حل می‌کند؟
اگر پاسخ قدیمی ذخیره شده باشد، آزمون در پنجره خصوصی کمک می‌کند. اما کمبود ظرفیت یا توقف سرویس سمت سرور با پاک کردن کش مرورگر برطرف نمی‌شود؛ باید پاسخ تازه و وضعیت میزبان بررسی شود.
آیا برای رفع 503 باید فوراً هاست را ارتقا دهیم؟
ابتدا علت را مشخص کنید. کار زمان‌بندی‌شده سنگین، افزونه ناسازگار یا تنظیم نامناسب کش ممکن است با اصلاح همان عامل برطرف شود. ارتقا برای فشار واقعی و پایدار منابع، پس از اندازه‌گیری، قابل ارزیابی است.
اگر پیشخوان هم باز نشود، از کجا شروع کنیم؟
از کنترل‌پنل هاست، گزارش خطا و وضعیت منابع شروع کنید. در صورت وجود شواهد درباره یک افزونه، بررسی محدود و قابل بازگشت آن با بکاپ انجام شود. برای توقف سرویس PHP یا مشکل وب‌سرور، پشتیبانی میزبان باید وارد بررسی شود.
پس از بازگشت سایت، علت را ثبت کنید
رفع خطای 503 در وردپرس زمانی کامل است که صفحه مشکل‌دار و عملیات اصلی سایت دوباره آزموده شده باشند. زمان اختلال، عامل شناسایی‌شده، تغییر انجام‌شده و نتیجه آزمون را ثبت کنید. سپس زمان‌بندی بکاپ‌ها، به‌روزرسانی در محیط آزمایشی و پایش منابع را متناسب با همان علت اصلاح کنید تا دفعه بعد مسیر تشخیص کوتاه‌تر شود.
سرویس‌های مرتبط با این مطلب
برای بررسی راهکار مناسب، مشخصات و شرایط این خدمات را ببینید.
پرسش‌ها و دیدگاه‌های شما
سؤال یا تجربه مرتبط با این مطلب دارید؟ با ما و خوانندگان مجله آفاق هاست در میان بگذارید.