رفع خطای 500 وردپرس؛ چک‌لیست عیب‌یابی از سمت هاست و سرور

خطای 500 Internal Server Error به این معنی است که وب‌سرور هنگام پردازش درخواست با مشکلی روبه‌رو شده، اما نتوانسته جزئیات دقیق آن را به مرورگر اعلام کند. در وردپرس، این خطا ممکن است از یک افزونه یا قالب ناسازگار، خطای PHP، تنظیم نادرست فایل .htaccess، کمبود منابع یا پیکربندی وب‌سرور ایجاد شود.

اشتباه رایج این است که بدون دیدن لاگ، چند تنظیم را هم‌زمان تغییر دهیم. روش مطمئن‌تر این است که ابتدا زمان و محدوده خرابی را مشخص کنیم، سپس با کمترین تغییر ممکن علت را جدا کنیم.

قبل از شروع: از وضعیت فعلی نسخه پشتیبان بگیرید

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

• از wp-config.php و .htaccess یک کپی جداگانه تهیه کنید.
• نسخه PHP، آخرین تغییر انجام‌شده و زمان شروع خطا را یادداشت کنید.
• اگر بکاپ خودکار دارید، سالم‌بودن آخرین نسخه و امکان Restore را بررسی کنید.

مرحله اول: محدوده خطا را مشخص کنید

اول پاسخ این سؤال‌ها را پیدا کنید:

• خطا در کل سایت دیده می‌شود یا فقط یک URL؟
• پیشخوان وردپرس باز می‌شود؟
• خطا پس از نصب یا به‌روزرسانی افزونه، قالب یا PHP ایجاد شده است؟
• فقط درخواست‌های سنگین، آپلود یا Cron دچار خطا هستند؟
• کد پاسخ واقعاً 500 است یا 502، 503 و 504؟

برای بررسی هدر پاسخ می‌توانید از دستور زیر استفاده کنید:

curl -I https://example.com/problem-page/

تفکیک کدهای 5xx مهم است؛ برای مثال 502 معمولاً به ارتباط وب‌سرور با PHP-FPM یا Upstream مربوط است، در حالی که 504 بیشتر به Timeout اشاره می‌کند.

مرحله دوم: لاگ را قبل از حدس‌زدن بخوانید

مهم‌ترین مدرک، خطایی است که در همان زمان درخواست ثبت شده است. بسته به محیط، این مسیرها را بررسی کنید:

• لاگ خطای دامنه در cPanel، DirectAdmin یا Plesk
• لاگ Apache یا Nginx
• لاگ PHP-FPM
• فایل wp-content/debug.log

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

define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);

نمایش خطا روی سایت عمومی را خاموش نگه دارید؛ پیام خطا ممکن است مسیر فایل‌ها یا اطلاعات حساس را افشا کند. بعد از عیب‌یابی نیز Debug را غیرفعال کنید. راهنمای رسمی Debugging in WordPress جزئیات بیشتری دارد.

مرحله سوم: افزونه‌ها را به روش قابل بازگشت بررسی کنید

اگر پیشخوان باز می‌شود، افزونه‌ای را که دقیقاً قبل از خرابی نصب یا به‌روزرسانی شده غیرفعال کنید. اگر پیشخوان در دسترس نیست، از File Manager یا SSH نام پوشه افزونه مشکوک را در wp-content/plugins موقتاً تغییر دهید.

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

مرحله چهارم: قالب فعال را جدا کنید

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

مرحله پنجم: فایل htaccess و Rewrite را بررسی کنید

در Apache و LiteSpeed، اشتباه نحوی یا دستور پشتیبانی‌نشده در .htaccess می‌تواند بلافاصله خطای 500 بسازد. فایل را تغییر نام دهید، سپس از بخش «تنظیمات ← پیوندهای یکتا» قوانین استاندارد وردپرس را دوباره ذخیره کنید.

اگر با حذف موقت فایل مشکل حل شد، دستورها را مرحله‌به‌مرحله برگردانید. قوانین امنیتی، Redirectها، تنظیمات PHP و دستورهایی مانند Options یا SetEnv باید با پیکربندی هاست سازگار باشند.

مرحله ششم: نسخه PHP، افزونه‌های PHP و محدودیت‌ها

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

• فعال‌بودن افزونه‌های ضروری مانند mysqli، mbstring، curl، json و zip
• مقادیر memory_limit، max_execution_time و max_input_vars
• لاگ Pool مربوط به PHP-FPM
• وضعیت OPcache پس از Deploy یا تغییر نسخه

افزایش Memory Limit بدون دیدن لاگ ممکن است فقط نشانه را پنهان کند. اگر خطا Allowed memory size exhausted است، علاوه بر افزایش منطقی محدودیت، افزونه یا Query پرمصرف را پیدا کنید.

مرحله هفتم: مالکیت و سطح دسترسی فایل‌ها

Permission نامناسب یا Owner اشتباه، مخصوصاً پس از انتقال سایت، می‌تواند اجرای PHP یا خواندن فایل‌ها را مختل کند. مقادیر رایج 755 برای پوشه و 644 برای فایل است، اما تنظیم نهایی باید با مدل اجرای PHP و سیاست هاست هماهنگ باشد. از 777 به‌عنوان راه‌حل دائمی استفاده نکنید.

مرحله هشتم: منابع و سلامت سرویس‌ها

اگر خطا مقطعی است، فقط وردپرس را بررسی نکنید. CPU، RAM، I/O، تعداد Processها، محدودیت Entry Process و اتصال دیتابیس را هم ببینید:

uptime
free -h
df -h
ps aux --sort=-%cpu | head
systemctl status php-fpm
systemctl status mariadb

در هاست اشتراکی، نمودار Resource Usage می‌تواند نشان دهد خطا هم‌زمان با رسیدن به Limit رخ داده است. در سرور اختصاصی، لاگ Kernel و OOM Killer نیز مهم است.

ترتیب پیشنهادی عیب‌یابی

1. ثبت زمان، URL و کد پاسخ
2. بررسی Error Log همان درخواست
3. بازگردانی آخرین تغییر
4. تست افزونه و قالب به‌صورت کنترل‌شده
5. بررسی htaccess و Rewrite
6. بررسی PHP، Permission و منابع
7. تست نهایی و خاموش‌کردن Debug

چطور مطمئن شویم مشکل واقعاً حل شده است؟

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

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