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

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

خطای 500 چیست و چرا این‌قدر مبهم به نظر می‌رسد؟

خطای HTTP 500 یا Internal Server Error یک کد وضعیت عمومی است که سرور وقتی با موقعیتی روبه‌رو می‌شود که نمی‌تواند به‌درستی پردازش کند، برمی‌گرداند. برخلاف خطای 404 که معنای مشخصی دارد (منبع درخواستی پیدا نشد)، خطای 500 یک ظرف بزرگ است که ده‌ها نوع مشکل متفاوت را در خود جای می‌دهد.

نکته کلیدی اینجاست: پیام Internal Server Error توسط خود وب‌سرور (Apache، Nginx یا LiteSpeed) تولید می‌شود، نه توسط وردپرس. به همین دلیل هیچ جزئیاتی درباره اینکه کدام فایل PHP خطا داده یا کدام کوئری دیتابیس شکست خورده، نمایش داده نمی‌شود. این طراحی عمدی است: نمایش جزئیات فنی خطا به کاربر نهایی، یک ریسک امنیتی جدی محسوب می‌شود.

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

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

چرا خطای 500 در وردپرس رخ می‌دهد؟ هفت دلیل رایج

دلایل بروز خطای 500 در وردپرس را می‌توان در هفت دسته اصلی خلاصه کرد. این دسته‌بندی حاصل سال‌ها دیدن پرونده‌های واقعی است و ترتیب آن تا حد زیادی با احتمال وقوع هم‌خوانی دارد.

۱. خطاهای سینتکس (Syntax Error) در فایل‌های PHP

یک ویرگول یا سمی‌کولن جاافتاده در فایل functions.php یا هر فایل PHP قالب، می‌تواند کل سایت را از کار بیندازد. وردپرس با PHP (Hypertext Preprocessor) کار می‌کند و PHP در برابر خطاهای سینتکسی هیچ رحمی ندارد: یا کد اجرا می‌شود، یا کل فایل کنار گذاشته می‌شود. بدترین حالت وقتی است که این خطا در فایل functions.php قالب فعال اتفاق بیفتد، چون این فایل در همه صفحات بارگذاری می‌شود.

۲. فرسودگی محدودیت حافظه (Memory Limit)

هر اسکریپت PHP سهم مشخصی از حافظه سرور را مصرف می‌کند. اگر یک افزونه سنگین یا فرآیند سنگین (مثل بهینه‌سازی دسته‌جمعی تصاویر یا ایمپورت محتوا) از این سقف عبور کند، سرور با خطای 500 پاسخ می‌دهد. این مسئله به‌خصوص در هاست‌های اشتراکی که سهم حافظه محدودی دارند، شایع است. علت دقیق این خطا را در راهنمای رفع خطای Memory Limit در وردپرس باز کرده‌ام.

۳. تعارض افزونه‌ها یا قالب

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

۴. خرابی فایل .htaccess

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

۵. مجوزهای فایل و مالکیت اشتباه

اگر مجوزهای فایل یا پوشه‌ها به‌درستی تنظیم نشده باشند، سرور نمی‌تواند به فایل‌ها دسترسی پیدا کند و خطای 500 برمی‌گرداند. مجوز پیشنهادی برای فایل‌ها 644 و برای پوشه‌ها 755 است. همین مشکل ممکن است با مالکیت اشتباه فایل‌ها (ownership) هم رخ دهد، مخصوصاً وقتی فایل‌ها از یک سرور به سرور دیگر منتقل می‌شوند.

۶. خرابی دیتابیس

خطاهای دیتابیس هم می‌توانند خودشان را به شکل خطای 500 نشان دهند، مخصوصاً وقتی جدول‌ها خراب شده باشند یا اطلاعات ورود به دیتابیس در wp-config.php اشتباه باشد. اگر شک دارید که مشکل از دیتابیس است، مقاله رفع خطای اتصال به پایگاه داده وردپرس را ببینید. ابزار تعمیر دیتابیس وردپرس در wp-admin/maint/repair.php اولین ایستگاهی است که باید سراغش بروید.

۷. محدودیت‌های سرور و مصرف CPU

اگر سایت شما ترافیک زیادی دارد یا یک افزونه بیش از حد منابع مصرف می‌کند، ممکن است هاست شما به سقف CPU یا تعداد فرآیندهای همزمان برسد. در این حالت معمولاً خطای 500 یا 503 نمایش داده می‌شود. در پنل هاست، بخش Resource Usage یا نمودارهای مصرف را باید در بازه‌های زمانی مختلف چک کنید تا بفهمید الگوی مصرف طبیعی است یا نه.

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

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

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

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

با این تنظیمات، خطاها در فایل wp-content/debug.log ذخیره می‌شوند اما به کاربر نمایش داده نمی‌شوند. این دقیقاً همان چیزی است که در محیط production می‌خواهید. اگر WP_DEBUG_DISPLAY را روی true بگذارید، خطاها روی صفحه نمایش داده می‌شوند که در محیط توسعه مفید است ولی در سایت زنده می‌تواند اطلاعات حساس را لو بدهد.

اگر به فایل wp-config.php یا کد PHP دسترسی ندارید، می‌توانید از لاگ خطاهای سرور استفاده کنید. در cPanel معمولاً در بخش Error Log یا از مسیر /home/username/logs/ قابل دسترسی است. اگر با پنل cPanel آشنایی ندارید، راهنمای کار با cPanel نقطه شروع خوبی است.

در لاگ سرور معمولاً چیزی شبیه این می‌بینید:

[Wed Sep 17 10:23:45 2026] [error] [client 192.0.2.1] PHP Fatal error:  Allowed memory size of 134217728 bytes exhausted (tried to allocate 20480 bytes)

همین یک خط به شما می‌گوید که مشکل از کمبود حافظه است. سطرهای بعدی لاگ یا سطرهای قبلی معمولاً نام فایل و شماره خط را هم نشان می‌دهند که مسیر عیب‌یابی را کوتاه می‌کند.

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

عیب‌یابی گام‌به‌گام خطای 500

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

گام اول: بکاپ کامل بگیرید

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

گام دوم: فایل .htaccess را موقتاً غیرفعال کنید

فایل .htaccess را از طریق File Manager یا FTP به .htaccess.bak تغییر نام دهید. اگر سایت بالا آمد، مشکل از این فایل بوده. باید آن را باز کنید و خطوط اضافی یا اشتباه را حذف یا اصلاح کنید. خطوط استاندارد وردپرس را از مستندات رسمی می‌توانید بردارید. اگر سایت شما روی Nginx اجرا می‌شود، معادل این فایل در تنظیمات سرور است و باید با پشتیبانی هاست هماهنگ کنید.

گام سوم: افزونه‌ها را غیرفعال کنید

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

گام چهارم: قالب را به پیش‌فرض تغییر دهید

اگر با غیرفعال‌سازی افزونه‌ها مشکل حل نشد، احتمالاً قالب مقصر است. با تغییر نام پوشه قالب فعال، وردپرس به‌صورت خودکار از یک قالب پیش‌فرض (مثل Twenty Twenty-Four) استفاده می‌کند. اگر سایت بالا آمد، باید قالب را از نظر خطاهای سینتکسی، ناسازگاری با نسخه PHP یا تداخل با افزونه‌ها بررسی کنید. برای مقایسه با یک قالب سالم و رفع این نوع خطا، مقاله رفع خطای قالب وردپرس را ببینید.

گام پنجم: حافظه PHP را افزایش دهید

اگر مراحل قبلی نتیجه نداد، احتمالاً مشکل از محدودیت حافظه است. مقدار WP_MEMORY_LIMIT را در wp-config.php افزایش دهید:

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

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

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

با یک کلاینت FTP مثل FileZilla، مجوز پوشه‌ها و فایل‌های اصلی را چک کنید. پوشه‌ها باید 755 و فایل‌ها 644 باشند. فایل wp-config.php معمولاً باید 600 یا 644 باشد. اگر عددی غیر از این دیدید، اصلاحش کنید. همچنین مطمئن شوید مالکیت فایل‌ها (owner) روی کاربر صحیح هاست تنظیم شده است.

گام هفتم: دیتابیس را تعمیر کنید

به آدرس wp-admin/maint/repair.php بروید و دستور repair را اجرا کنید. این ابزار جدول‌های خراب را تعمیر می‌کند. اگر به پیشخوان دسترسی ندارید، از طریق phpMyAdmin یا خط فرمان mysqlcheck -r هم می‌توانید این کار را انجام دهید. برای خطاهای مربوط به دیتابیس، مراجعه به مقاله رفع خطای سفید صفحه در وردپرس هم مفید است، چون این دو خطا اغلب هم‌زمان ظاهر می‌شوند.

گام هشتم: خطاهای مرتبط را جدا کنید

گاهی خطای 500 با خطاهای دیگر مثل 404 یا 503 اشتباه گرفته می‌شود. اگر خطای شما در واقع 404 است، رفع خطای 404 در وردپرس را ببینید. اگر صفحه کاملاً سفید است و هیچ پیامی ندارد، احتمالاً با White Screen of Death روبرو هستید. این دو خطا ریشه مشترکی دارند اما درمان‌شان از یک نقطه شروع نمی‌شود.

خطای 500 فقط در پیشخوان وردپرس

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

یک نکته دیگر: اگر خطای 500 در صفحه لاگین رخ می‌دهد، ممکن است مربوط به فایل wp-login.php باشد. در این حالت، فایل را از یک نسخه سالم وردپرس جایگزین کنید. اگر مشکل بعد از نصب یک افزونه امنیتی شروع شده، احتمالاً همان افزونه یک ریدایرکت اشتباه یا یک قانون در .htaccess اضافه کرده که باید بازبینی شود.

خطای 500 در فروشگاه ووکامرس

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

  • افزونه‌های پرداخت که با نسخه جدید ووکامرس سازگار نیستند
  • افزونه‌های محاسبه هزینه ارسال که کوئری سنگین می‌زنند
  • افزونه‌های تخفیف و کوپن که روی جدول‌های بزرگ کار می‌کنند
  • حافظه کم سرور در ساعات اوج ترافیک

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

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

خطامعنای رایجمقاله مرتبط
500خطای داخلی سرور، معمولاً PHP یا منابعهمین مقاله
503سرویس در دسترس نیست، معمولاً overloadبررسی منابع هاست
404منبع پیدا نشد، معمولاً permalinkرفع خطای 404
White Screenخطای PHP بدون پیام نمایشصفحه سفید مرگ

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

پیشگیری از تکرار خطای 500

بعد از اینکه مشکل حل شد، چند کار برای جلوگیری از تکرار انجام دهید. این کارها در تجربه من بیشترین اثر پیشگیرانه را داشته‌اند:

  • بکاپ خودکار روزانه روی فضای ذخیره‌سازی خارج از هاست راه بیندازید
  • فقط از افزونه‌های به‌روز و سازگار با نسخه PHP هاست استفاده کنید
  • قبل از نصب افزونه جدید، آن را روی محیط staging تست کنید
  • افزونه‌های بلااستفاده را کامل حذف کنید، نه اینکه فقط غیرفعال بگذارید
  • لاگ خطاها را هفتگی چک کنید و به هشدارها واکنش دهید
  • نسخه PHP را از تنظیمات هاست به‌روز نگه دارید
  • فایل wp-config.php و .htaccess را در جایی امن نگه دارید

پیشنهاد می‌کنم همیشه این موارد را دم دست داشته باشید: یک بکاپ تازه، دسترسی SSH یا FTP، یک نسخه از فایل‌های پیکربندی، و یک قالب پیش‌فرض وردپرس برای تست سریع. در تجربه من، بزرگ‌ترین اشتباه در مواجهه با خطای 500، تغییرات هم‌زمان و بی‌نظم است.

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

پیشگیری از خطای 500 ارزان‌تر از رفع آن است، به‌خصوص اگر سایت درآمدزا باشد و مشتری منتظر سفارش دادن.

پرسش‌های پرتکرار درباره خطای 500

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

آیا خطای 500 خودش برطرف می‌شود؟

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

آیا خطای 500 به دیتابیس آسیب می‌زند؟

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

آیا می‌توان بدون دسترسی FTP خطای 500 را رفع کرد؟

اگر پیشخوان در دسترس است، می‌توانید از بخش افزونه‌ها یا ویرایشگر قالب استفاده کنید. اما در حالت‌های شدید، بدون FTP یا File Manager راه‌حلی نیست. بنابراین داشتن دسترسی FTP برای هر مدیر سایتی یک ضرورت است، نه یک تجمل.

آیا خطای 500 همیشه مربوط به وردپرس است؟

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

آیا افزونه امنیتی می‌تواند خودش باعث خطای 500 شود؟

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

چگونه بفهمم خطای 500 از هاست است یا از وردپرس؟

یک فایل ساده مثل test.html را در ریشه سایت آپلود کنید. اگر این فایل باز شد ولی سایت وردپرسی خطا داد، مشکل از وردپرس است. اگر فایل ساده هم خطا داد، مشکل از سرور یا تنظیمات هاست است و باید با پشتیبانی تماس بگیرید.

آخرین توصیه‌های میدانی برای مدیران سایت

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

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

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