خطای 503 Service Unavailable یعنی سرویس در آن لحظه قادر به پاسخ‌گویی نیست. این پاسخ ممکن است از وب‌سرور، پراکسی، محدودیت منابع یا خود برنامه تولید شود؛ بنابراین دیدن 503 به‌تنهایی ثابت نمی‌کند که افزونه خراب است. ابتدا زمان وقوع و دامنه اختلال را مشخص کنید، سپس علت را با شواهد برطرف کنید.
۱. مشخص کنید کدام بخش پاسخ 503 می‌دهد
صفحه اصلی، یک نوشته، صفحه ورود و پیشخوان را جدا بررسی کنید. ببینید مشکل برای همه کاربران رخ می‌دهد یا فقط یک مسیر، هنگام پشتیبان‌گیری یا پس از به‌روزرسانی. زمان دقیق و منطقه زمانی، URL، متن خطا و آخرین تغییر را ثبت کنید. اگر سایت پشت CDN است، شناسه درخواست و لاگ مبدأ را نیز کنار هم بگذارید؛ صفحه خطای CDN لزوماً خطای خود وردپرس نیست.
۲. لاگ و مصرف منابع را قبل از تغییر تنظیمات بخوانید
در کنترل‌پنل هاست، گزارش خطای وب‌سرور، PHP و نمودار CPU، RAM، I/O و پردازش‌های هم‌زمان را در همان بازه ببینید. روی سرور مدیریت‌شده، وضعیت PHP-FPM و صف پردازش اهمیت دارد. پیام‌هایی مانند تمام‌شدن workerها یا محدودیت پردازش، مسیر بررسی را از یک خطای کدنویسی متفاوت می‌کنند. نبود خطا در debug.log وردپرس، سالم‌بودن وب‌سرور را اثبات نمی‌کند.
لاگ را عمومی منتشر نکنید؛ مسیر فایل، کوکی، نشانی کاربران یا کلیدها ممکن است داخل آن باشد. برای دیباگ موقت، نمایش خطا به بازدیدکننده را خاموش و ثبت لاگ را در مسیر حفاظت‌شده تنظیم کنید. پس از پایان عیب‌یابی، حالت دیباگ را به وضعیت قبلی برگردانید.
۳. تغییر اخیر را کنترل‌شده برگردانید
اگر اختلال بلافاصله پس از به‌روزرسانی افزونه یا قالب شروع شده، ابتدا پشتیبان و راه بازگشت تهیه کنید. در staging، همان مؤلفه را موقتاً غیرفعال یا نسخه سالم آن را بازیابی کنید و دوباره تست بگیرید. بدون دسترسی پیشخوان می‌توان فقط پوشه افزونه مظنون را از File Manager تغییر نام داد؛ حذف فایل‌ها لازم نیست. غیرفعال‌کردن سراسری روی فروشگاه می‌تواند پرداخت و فرم‌ها را از کار بیندازد، پس این کار باید در پنجره نگهداری و با ثبت وضعیت قبلی انجام شود.
برای تست قالب، ابتدا وجود یک قالب پیش‌فرض سالم و سازگار را بررسی کنید. تغییر نام کورکورانه قالب فعال، بدون جایگزین، روش مطمئن بازیابی نیست.
۴. ازدحام، cron و حالت نگهداری را تفکیک کنید
پشتیبان‌گیری سنگین، اسکن امنیتی، صف ایمیل، درخواست ربات‌ها یا اجرای هم‌زمان cron می‌تواند منابع را اشغال کند. زمان‌بندی کارهای سنگین را از هم جدا کنید و درخواست‌های پرهزینه را از لاگ بیابید. کش صفحه عمومی ممکن است بار را کم کند، اما پاسخ صفحات ورود، سبد خرید و نشست کاربران نباید با کش عمومی مخلوط شود. حفاظت امنیتی را برای رفع موقت خطا به‌طور سراسری خاموش نکنید.
اگر به‌روزرسانی قطع شده و پیام نگهداری باقی مانده، اول مطمئن شوید پردازش به‌روزرسانی واقعاً پایان یافته است؛ حذف فایل .maintenance حین اجرای به‌روزرسانی می‌تواند وضعیت نیمه‌کاره ایجاد کند.
۵. نتیجه را با معیار روشن تأیید کنید
رفع خطا یعنی همان مسیر مشکل‌دار، برای کاربر واردشده و مهمان، چند بار پاسخ طبیعی بدهد و خطای متناظر در لاگ تکرار نشود. فرم، ورود، سفارش و cron مرتبط را نیز بررسی کنید. افزایش حافظه یا ارتقای سرویس فقط زمانی انتخاب درستی است که اندازه‌گیری، کمبود واقعی منابع را نشان دهد؛ افزایش عددها، حلقه بی‌نهایت یا کوئری کند را درمان نمی‌کند.
اگر مشکل ادامه دارد، برای پشتیبانی هاست زمان وقوع، URL، کد پاسخ، شناسه درخواست و پیام پالایش‌شده لاگ را ارسال کنید. این اطلاعات از عبارت کلی «سایت باز نمی‌شود» بسیار کاربردی‌تر است.
منابع و دامنه راهنما
این راهنما بر پایه مستندات رسمی زیر بازبینی شده است. نام گزینه‌ها و امکانات ممکن است با نسخه نرم‌افزار یا سطح دسترسی سرویس شما تفاوت داشته باشد.
