رفع خطای 500 وردپرس؛ آموزش عیب‌یابی مرحله‌به‌مرحله

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

پیش از شروع: محدوده خطا را مشخص کنید

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

curl -I https://example.com
curl -I https://example.com/wp-admin/

دامنه واقعی را جایگزین کنید. اگر فقط یک مسیر خطای 500 می‌دهد، عیب‌یابی را روی همان قابلیت متمرکز کنید. اگر همه مسیرها خراب‌اند، بررسی لاگ وب‌سرور و PHP در اولویت است. پاسخ 502 یا 504 با 500 یکسان نیست و معمولاً به دسترس‌نبودن یا تأخیر سرویس بالادستی مربوط می‌شود.

مرحله اول: قبل از تغییر نسخه پشتیبان بگیرید

حتی سایت خراب هم باید پیش از دست‌کاری snapshot شود. اگر WP-CLI در مسیر اصلی وردپرس فعال است، پایگاه داده و فایل‌های حساس را با نامی خارج از پوشه عمومی ذخیره کنید:

cd /var/www/example.com/public
wp db export "$HOME/wordpress-before-500-fix.sql"
tar -czf "$HOME/wordpress-files-before-500-fix.tar.gz" \
  wp-config.php wp-content

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

هر عامل را جداگانه آزمایش کنید؛ تغییر هم‌زمان چند بخش تشخیص علت واقعی را دشوار می‌کند.

مرحله دوم: لاگ خطا را بخوانید

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

sudo tail -n 100 /var/log/nginx/error.log
sudo tail -n 100 /var/log/apache2/error.log
systemctl list-units --type=service --all | grep -E 'php.*fpm'
sudo journalctl -u php8.3-fpm --since "30 minutes ago" --no-pager

لازم نیست هر دو لاگ Nginx و Apache روی سرور شما وجود داشته باشد. نام سرویس PHP-FPM را از خروجی فرمان سوم بردارید و به‌جای php8.3-fpm بگذارید. دنبال عبارت‌هایی مانند PHP Fatal error، Allowed memory size exhausted، Permission denied یا مسیر یک افزونه و قالب بگردید. خروجی لاگ ممکن است مسیرها و داده‌های حساس داشته باشد؛ آن را عمومی منتشر نکنید.

مرحله سوم: لاگ امن وردپرس را موقتاً فعال کنید

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

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

اکنون خطا را دوباره ایجاد و فایل wp-content/debug.log را بررسی کنید. خاموش‌کردن نمایش خطا مهم است تا مسیر فایل‌ها یا جزئیات داخلی به بازدیدکننده نشان داده نشود. پس از پایان عیب‌یابی، WP_DEBUG و WP_DEBUG_LOG را به false برگردانید و فایل لاگ را پس از نگهداری نسخه مورد نیاز حذف یا از دسترس عمومی خارج کنید. مستندات رسمی وردپرس نیز استفاده از حالت اشکال‌زدایی روی staging را توصیه می‌کند.

مرحله چهارم: تداخل افزونه‌ها را آزمایش کنید

اگر لاگ نام یک افزونه را نشان می‌دهد، همان افزونه را غیرفعال کنید. وقتی علت مشخص نیست و WP-CLI اجرا می‌شود، فهرست را ثبت و همه افزونه‌های معمولی را موقتاً غیرفعال کنید:

cd /var/www/example.com/public
wp plugin list
wp plugin deactivate --all --skip-plugins --skip-themes

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

wp plugin activate plugin-slug
curl -I https://example.com

در وردپرس چندسایته، افزونه‌های network-active به بررسی جداگانه و گزینه --network نیاز دارند. همچنین must-use pluginها در wp-content/mu-plugins با فرمان عادی غیرفعال نمی‌شوند.

اگر WP-CLI بالا نمی‌آید، روش رسمی جایگزین این است که با File Manager، FTP یا SSH پوشه افزونه‌ها را موقتاً تغییر نام دهید:

cd /var/www/example.com/public
mv wp-content/plugins wp-content/plugins.disabled

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

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

یک خطای PHP در قالب یا child theme هم می‌تواند پاسخ 500 بسازد. ابتدا قالب‌های نصب‌شده را ببینید و فقط اگر یک قالب پیش‌فرض سالم از قبل نصب است، موقتاً آن را فعال کنید:

wp theme list --skip-plugins
wp theme activate twentytwentysix --skip-plugins --skip-themes

twentytwentysix در این مثال باید با slug قالب پیش‌فرض نصب‌شده روی سایت شما جایگزین شود. اگر با قالب پیش‌فرض مشکل رفع شد، لاگ PHP و آخرین تغییرات functions.php، templateها و وابستگی‌های قالب اصلی را بررسی کنید. روی سایت پرترافیک این آزمون را در staging یا بازه نگهداری انجام دهید، چون ظاهر عمومی سایت تغییر می‌کند.

مرحله ششم: فایل htaccess را فقط در Apache آزمایش کنید

فایل خراب .htaccess می‌تواند روی Apache خطای داخلی ایجاد کند، اما Nginx این فایل را نمی‌خواند. اگر وب‌سرور Apache است، ابتدا کپی پشتیبان بسازید و فایل را موقتاً کنار بگذارید:

cd /var/www/example.com/public
cp .htaccess "$HOME/htaccess-before-500-fix"
mv .htaccess .htaccess.disabled

اگر سایت باز شد، پس از ورود به مدیریت وردپرس صفحه «تنظیمات ← پیوندهای یکتا» را بدون تغییر ذخیره کنید تا قواعد استاندارد دوباره ساخته شوند. کاربران WP-CLI نیز می‌توانند پس از رفع علت، wp rewrite flush را اجرا کنند. قواعد امنیتی یا redirect اختصاصی نسخه پشتیبان را بعداً با دقت و یکی‌یکی برگردانید.

مرحله هفتم: کمبود حافظه PHP را فقط با شواهد اصلاح کنید

افزایش حافظه یک درمان عمومی برای هر خطای 500 نیست. فقط وقتی لاگ پیام Allowed memory size exhausted دارد، مصرف افزونه یا عملیات سنگین را بررسی کنید. مقدار WP_MEMORY_LIMIT می‌تواند در wp-config.php تعیین شود:

define( 'WP_MEMORY_LIMIT', '256M' );

عدد مناسب به منابع هاست و محدودیت memory_limit در PHP بستگی دارد؛ وردپرس نمی‌تواند سقفی را که میزبان پایین‌تر تعیین کرده دور بزند. افزایش زیاد بدون یافتن افزونه یا فرایند پرمصرف ممکن است فقط خطا را عقب بیندازد و فشار روی سرور را بیشتر کند. در هاست اشتراکی برای تغییر سقف PHP با پشتیبانی تماس بگیرید.

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

WP-CLI می‌تواند فایل‌های هسته را با checksum رسمی WordPress.org مقایسه کند و برای این بررسی WordPress را کامل بارگذاری نمی‌کند:

cd /var/www/example.com/public
wp core verify-checksums --include-root

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

برای خطای Permission denied مالک فایل و کاربری را که PHP-FPM با آن اجرا می‌شود بررسی کنید. استفاده از chmod -R 777 راه‌حل امنی نیست؛ مجوز و مالکیت باید متناسب با معماری هاست اصلاح شود. اگر ساختار سرور را نمی‌شناسید، از مدیر سرور کمک بگیرید.

بعد از رفع خطا چه کار کنیم؟

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

جمع‌بندی

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

اگر ریشه مشکل کمبود منابع یا تنظیم نادرست زیرساخت است، راهنمای انتخاب هاست وردپرس و مقاله امن‌سازی VPS اوبونتو را نیز ببینید. برای ارتباط امن مدیریت سایت، آموزش نصب SSL رایگان روی Nginx در دسترس است.

منابع رسمی: خطاهای رایج وردپرس، راهنمای اشکال‌زدایی وردپرس، دستور غیرفعال‌سازی افزونه در WP-CLI، بررسی checksum هسته و مرجع رسمی محدودیت حافظه PHP.