خطای ۵۰۳ وردپرس؛ تشخیص تعمیرات، منابع و وب‌سرور

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

هاستلینو۵ دقیقه مطالعه

سرور و پنجره توقف موقت همراه ذره‌بین برای تشخیص خطای ۵۰۳
فهرست مطالب

خطای 503 Service Unavailable یعنی سرور در آن لحظه آماده پاسخ‌گویی به درخواست نیست. در سایت وردپرسی، این پاسخ ممکن است از خود برنامه، وب‌سرور، PHP، لایه پراکسی یا سرویس جلوی سایت بیاید. تعمیرات موقت و فشار منابع از علت‌های رایج‌اند، اما دیدن عدد ۵۰۳ به‌تنهایی ثابت نمی‌کند که هاست ضعیف است یا یک افزونه خاص خراب شده.

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

قدم اول: آیا واقعاً پاسخ HTTP برابر ۵۰۳ است؟

عنوان صفحه خطا ممکن است با وضعیت HTTP فرق کند. در ابزار توسعه مرورگر، بخش Network، درخواست اصلی Document را انتخاب کنید و Status را ببینید. در صورت آشنایی با خط فرمان، دستور زیر یک درخواست GET می‌فرستد و سرآیند پاسخ را نشان می‌دهد؛ این مثال آموزشی است و روی دامنه خودتان اجرا می‌شود.

curl -sS -D - -o /dev/null https://example.com/

زمان، منطقه زمانی، URL، وضعیت HTTP و شناسه درخواست احتمالی را ثبت کنید. سرآیندهایی مثل Server یا Via و ظاهر صفحه می‌توانند سرنخ باشند، ولی اثبات قطعی محل خرابی نیستند. اطلاعات محرمانه مانند کوکی ورود، توکن، رمز و لاگ کامل حاوی داده مشتری را در گزارش عمومی نگذارید.

از نشانه به آزمون؛ جدول تصمیم سریع

نشانهبررسی بعدیاز این نتیجه‌گیری عجولانه پرهیز کنید
بلافاصله پس از آپدیتتمام‌شدن عملیات، وضعیت maintenance و خطاهای همان زمانپاک‌کردن فایل تعمیرات در حالی که آپدیت هنوز فعال است
هم‌زمان با افزایش ترافیکCPU، حافظه، worker و صف اتصال در همان بازهارتقای پلن بدون یافتن نوع محدودیت
فقط یک مسیر یا عملیاتافزونه مرتبط، درخواست خارجی و لاگ آن عملیاتتغییر هم‌زمان همه افزونه‌ها و تنظیمات
صفحه خطای CDN یا پراکسیوضعیت مبدا و ارتباط پراکسی با مبدا توسط مدیر سرویسفرض اینکه وردپرس حتماً پاسخ را ساخته است
خطا متناوب و بدون تغییر اخیرکران، بک‌آپ، اسکن و کارهای دوره‌ایپاک‌کردن کش به‌عنوان تنها راه‌حل

اگر پس از به‌روزرسانی رخ داده است

وردپرس هنگام به‌روزرسانی می‌تواند پیام «Briefly unavailable for scheduled maintenance» نشان دهد. ابتدا مطمئن شوید عملیات هنوز اجرا نمی‌شود. مستندات رسمی وردپرس، باقی‌ماندن فایل .maintenance در ریشه نصب را یکی از علت‌های ماندن پیام تعمیرات معرفی می‌کند. پس از تأیید پایان عملیات و داشتن راه بازگشت، مدیر فنی می‌تواند همان فایل باقی‌مانده را بررسی کند؛ فایل‌های مشابه یا پوشه‌های دیگر را حذف نکنید.

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

اگر منابع یا PHP پاسخ‌گو نیستند

گزارش CPU و حافظه را با لحظه خطا تطبیق دهید. مدیر سرور باید تعداد workerهای PHP، صف درخواست، restart سرویس، اتصال دیتابیس و خطاهای وب‌سرور را هم ببیند. مصرف متوسط روزانه پایین، یک اوج کوتاه یا پرشدن صف را رد نمی‌کند. یک افزونه سنگین، کار زمان‌بندی‌شده یا وابستگی کند بیرونی ممکن است workerها را مدت طولانی مشغول نگه دارد.

در هاست اشتراکی، افزایش عدد حافظه در wp-config.php الزاماً سهمیه واقعی حساب را افزایش نمی‌دهد. ابتدا نوع محدودیت را مشخص کنید. اگر گزارش صریح Resource Limit وجود دارد، راهنمای خطای ۵۰۸ و برای CPU، مسیر تشخیص مصرف بالای CPU را بخوانید. ۵۰۳ و ۵۰۸ را صرفاً به‌خاطر شباهت ظاهری یک خطا ندانید.

افزونه، قالب و درخواست خارجی را چطور بررسی کنیم؟

آخرین تغییر قبل از خطا را پیدا کنید: آپدیت، تنظیم کش، افزونه پرداخت، اتصال API یا تغییر نسخه PHP. در staging، یک تغییر را برگردانید و همان درخواست را دوباره آزمایش کنید. اگر خطا رفع شد، نتیجه را با فعال‌سازی دوباره و لاگ مرتبط تأیید کنید؛ هم‌زمانی به‌تنهایی رابطه علت و معلول را ثابت نمی‌کند.

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

CDN و کش خطا را هم بررسی کنید

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

مدیر سرویس می‌تواند برای تعمیرات موقت، Retry-After متناسب با زمان تخمینی بازیابی تنظیم کند. این سرآیند تضمین نمی‌کند همه کلاینت‌ها دقیقاً همان زمان دوباره تلاش کنند. جایگزین‌کردن صفحه خطا با پاسخ ۲۰۰ نیز دسترس‌پذیری واقعی سرویس را برنمی‌گرداند و پایش را گمراه می‌کند.

برای پشتیبانی چه اطلاعاتی بفرستیم؟

  • URL دقیق و ساعت شروع با منطقه زمانی.
  • دائمی یا متناوب‌بودن، مسیرهای درگیر و مراحل بازتولید.
  • آخرین تغییر و نتیجه هر آزمون، با یک تغییر در هر مرحله.
  • وضعیت HTTP، شناسه درخواست و بخش مرتبط لاگ با حذف داده محرمانه.
  • گزارش منابع همان بازه و نام لایه‌های CDN یا پراکسی در مسیر.

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

پس از رفع، فقط صفحه اصلی را تست نکنید

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

منابع فنی

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

علت خطای ۵۰۳ هنوز مشخص نیست؟

زمان خطا، مسیر درگیر و آخرین تغییر را آماده کن و درخواست بررسی فنی ثبت کن.

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

آیا خطای ۵۰۳ همیشه به کمبود منابع هاست مربوط است؟

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

آیا باید فایل .maintenance را فوراً حذف کنیم؟

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

تفاوت خطای ۵۰۳ و ۵۰۸ چیست؟

۵۰۳ نشان می‌دهد سرویس موقتاً آماده پاسخ‌گویی نیست. پیام ۵۰۸ Resource Limit در برخی محیط‌های میزبانی به محدودیت منابع اشاره دارد؛ تشخیص باید بر اساس پاسخ و لاگ همان سرویس باشد.