چگونه خطای 500 داخلی سرور را در وردپرس حل کنیم؟

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

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

خطای 500 دقیقاً چیست؟

خطای 500 یا Internal Server Error، کد وضعیت HTTP است که نشان می‌دهد سرور، نتوانسته درخواست را به‌درستی پردازش کند — ولی دقیقاً نمی‌گوید چرا. برخلاف خطای 404 که «صفحه پیدا نشد» است، یا 403 که «دسترسی ندارید» است، 500 هیچ اطلاعاتی درباره‌ی دلیل نمی‌دهد. به همین دلیل هم ترسناک به نظر می‌رسد.

در وردپرس، خطای 500 می‌تواند از چند خانواده‌ی مختلف بیاید:

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

خطای 500 مثل یک آژیر آتش‌نشانی است: به شما می‌گوید جایی آتش گرفته، ولی نمی‌گوید کدام طبقه. کارِ شما، پیدا کردن آن طبقه است — نه خاموش‌کردن آژیر.

قاعده‌ی اول: قبل از هر چیزی بکاپ

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

روش‌های بکاپ را در چگونه از وردپرس بکاپ بگیریم؟ راهنمای مبتدیان و چگونه از cPanel بکاپ بگیریم آورده‌ام. اگر هاست‌تان بکاپ خودکار دارد، حتماً یک نسخه‌ی دستی هم بگیرید — چون بکاپ خودکار، گاهی بعد از حادثه گرفته می‌شود و دیگر آن وضعیت سالم را ندارد.

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

گام اول: فعال‌سازی لاگ خطا

خطای 500، پیام دقیق را در مرورگر نشان نمی‌دهد — چون نمایش خطاهای PHP روی سایت زنده، امنیتی است. ولی راهی وجود دارد که خطاها را به‌جای صفحه، در یک فایل ذخیره کنیم. کافی است این چهار خط را در فایل wp-config.php، بالای خط /* That's all, stop editing! */ اضافه کنید:

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

سه نکته‌ی مهم در این تنظیمات:

1. WP_DEBUG روی true: حالت دیباگ را فعال می‌کند.
2. WP_DEBUG_LOG روی true: خطاها در فایل wp-content/debug.log ذخیره می‌شوند.
3. WP_DEBUG_DISPLAY روی false: خطاها روی صفحه نمایش داده نشوند. این خط، برای سایت زنده حیاتی است — چون اگر خطا روی صفحه نمایش داده شود، ممکن است اطلاعات حساس سرور به کاربر لو برود.

بعد از فعال‌سازی، سایت را یک‌بار باز کنید. حالا فایل wp-content/debug.log را از طریق FTP یا File Manager باز کنید. این فایل، پر از پیام‌هایی است که نشان می‌دهند سایت کجا شکسته. مسیر کامل خواندن این فایل در خطای قالب وردپرس: چگونه آن را پیدا و رفع کنیم و چگونه خطای قالب را در وردپرس دیباگ کنیم آمده است.

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

گام دوم: خواندن لاگ و پیدا کردن ریشه

حالا که لاگ را دارید، باید آن را درست بخوانید. فایل debug.log، معمولاً پنج نوع پیام دارد:

سه الگویی که در پروژه‌ها بیشترین کمک را می‌کنند:

• مسیر فایل: خطا از کجا آمده؟ اگر مسیر شامل /wp-content/themes/ است، قالب مقصر است. اگر شامل /wp-content/plugins/ است، افزونه مقصر است.
• شماره خط: دقیقاً کدام خط از فایل مقصر است. حتی اگر با کد آشنا نیستید، می‌توانید به پشتیبانی سازنده بگویید «در فایل فلان، خط فلان، خطای فلان داده می‌شود».
• زمان‌بندی: خطا در چه زمانی رخ داده؟ اگر هم‌زمان با یک آپدیت یا نصب افزونه بوده، مقصر پیدا شده است.

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

گام سوم: عیب‌یابی افزونه‌ها

در تجربه‌ی من، نزدیک به نیمی از خطاهای 500، از یک افزونه می‌آیند — معمولاً بعد از آپدیت خودکارِ شبانه یا نصب افزونه‌ی جدید. اگر لاگ خطا مسیر /wp-content/plugins/ را نشان می‌دهد، این گام را جدی بگیرید.

پروتکل عیب‌یابی افزونه‌ها:

1. از طریق FTP به سایت وصل شوید.
2. پوشه‌ی wp-content/plugins را تغییر نام دهید — مثلاً به plugins-disabled. این کار، همه‌ی افزونه‌ها را به‌طور یک‌جا غیرفعال می‌کند.
3. سایت را باز کنید. اگر درست شد، مقصر یک افزونه است.
4. پوشه را به نام اصلی برگردانید و از پیشخوان، افزونه‌ها را یکی‌یکی فعال کنید تا مقصر مشخص شود.

این روش، سریع‌تر از غیرفعال‌کردن افزونه‌ها از پیشخوان است — چون در خطای 500، معمولاً دسترسی به پیشخوان هم ممکن نیست. مسیر کامل در چگونه افزونه مشکل‌ساز وردپرس را پیدا کنیم و رفع خطای Fatal error بعد از فعال‌سازی افزونه آمده است.

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

گام چهارم: عیب‌یابی قالب

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

1. خطای Parse Error در functions.php: این خطا، نتیجه‌ی یک اشتباه سینتکس است — مثلاً یک ; فراموش‌شده یا یک } جاافتاده. مسیر دقیق در رفع خطای Parse error در فایل functions.php آمده است.
2. قالب با نسخه‌ی جدید وردپرس یا PHP ناسازگار: اگر بعد از آپدیت وردپرس یا تغییر نسخه‌ی PHP این خطا آمد، احتمالاً قالب از توابع یا ساختارهای قدیمی استفاده می‌کند. مسیر در رفع خطای ناسازگاری قالب با نسخه وردپرس آمده است.

پروتکل عیب‌یابی قالب:

1. از طریق FTP به سایت وصل شوید.
2. پوشه‌ی قالب فعال را تغییر نام دهید — مثلاً به my-theme-disabled. این کار، وردپرس را مجبور می‌کند به قالب پیش‌فرض برگردد.
3. اگر سایت بالا آمد، قالب مقصر است. حالا باید فایل خطا‌ساز را پیدا کنید — معمولاً functions.php یا یک فایل خاص.

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

گام پنجم: بازبینی htaccess و مجوز فایل‌ها

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

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

1. فایل .htaccess را از طریق FTP دانلود کنید.
2. آن را موقتاً تغییر نام دهید (مثلاً .htaccess.backup).
3. سایت را باز کنید. اگر بالا آمد، مشکل از این فایل بوده. حالا باید بفهمید کدام خط مشکل‌ساز است.
4. اگر می‌خواهید فایل را از صفر بسازید، از طریق «تنظیمات ← پیوندهای یکتا» یک بار ذخیره کنید تا وردپرس فایل پیش‌فرض را بسازد.

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

مجوزها را می‌توانید از File Manager پنل هاست تغییر دهید. مسیر کامل در خطای دسترسی به فایل‌ها در وردپرس و خطای Permission در فایل‌های وردپرس آمده است.

گام ششم: محدودیت‌های PHP و منابع سرور

خطای 500 می‌تواند از محدودیت‌های PHP بیاید — بدون این‌که کد شما خطا داشته باشد. سه محدودیت کلیدی:

1. Memory Limit: اگر اسکریپتی بیش از حافظه‌ی مجاز مصرف کند، سرور آن را می‌بندد و خطای 500 می‌دهد. مسیر افزایش این محدودیت در خطای Memory limit در PHP و راه حل آن و خطای Memory Limit در وردپرس آمده است.
2. Max Execution Time: اگر اسکریپتی بیش از حد طول بکشد، سرور آن را قطع می‌کند. مسیر در رفع خطای Maximum execution time در PHP آمده است.
3. Post Max Size و Upload Max Filesize: اگر آپلود فایل بزرگ باعث 500 شود، این دو محدودیت مقصرند. مسیر در چگونه خطای آپلود فایل در وردپرس را برطرف کنیم آمده است.

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

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

گام هفتم: بازبینی دیتابیس

اگر خطای 500 با پیام «خطا در اتصال به دیتابیس» همراه است، مسئله در لایه‌ی دیتابیس است. سه سناریو:

1. اطلاعات اتصال اشتباه: نام کاربری یا رمز دیتابیس در wp-config.php اشتباه است. اگر اخیراً رمز دیتابیس را عوض کرده‌اید، باید همان را در این فایل هم بگذارید.
2. دیتابیس خراب یا خالی: بعضی وقت‌ها یک جدول خراب می‌شود و کوئری‌ها با خطا مواجه می‌شوند. مسیر تشخیص در خطای اتصال به پایگاه داده وردپرس و رفع خطای اتصال به دیتابیس در وردپرس آمده است.
3. سقف اتصال‌های همزمان: اگر تعداد اتصال‌ها بیش از حد مجاز باشد، دیتابیس اتصال جدید را قبول نمی‌کند. مسیر در رفع خطای Too many connections در MySQL آمده است.

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

گام هشتم: سرور و کارهای سرور

اگر همه‌ی گام‌های قبلی را انجام دادید و مشکل باقی ماند، مسئله احتمالاً در لایه‌ی سرور است. سه سناریوی رایج:

1. CPU یا RAM تمام شده: در ساعات اوج، اگر منابع هاست تمام شود، سرور درخواست‌های اضافه را با خطای 500 رد می‌کند. مسیر در خطای افزایش مصرف CPU در وردپرس آمده است.
2. هارد دیسک پر شده: اگر فضای هاست پر باشد، وردپرس نمی‌تواند کوکی یا فایل موقت بنویسد و خطا می‌دهد. مسیر در خطای هارد دیسک پر شده در سرور و چگونه فضای cPanel را آزاد کنیم آمده است.
3. مشکل موقت سرور: بعضی وقت‌ها سرور، برای نگهداری یا آپدیت، موقتاً در دسترس نیست. این سناریو، سریع خودش حل می‌شود و نیازی به اقدام ندارد.

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

نگاه سطح بالا: خطای 500 به‌مثابه نشانه‌ی سراسری

برای کسی که سال‌ها روی زیرساخت سیستم‌های وب کار کرده، «خطای 500» در نگاه اول یک خطای تکی است. اما اگر عمیق‌تر نگاه کنید، این خطا یک نشانه‌ی سراسری است که از یک لایه‌ی خاص می‌آید — ولی معلوم نیست کدام لایه. در چارچوب‌های جدی مهندسی، این نوع خطاها را با مفهوم «Fault Domain» می‌شناسند: دامنه‌ی خطا که به شما می‌گوید مسئله کجاست. و خطای 500، به‌طور معمول از یکی از این چهار دامنه می‌آید:

• دامنه‌ی کد اپلیکیشن: کد PHP شما یا افزونه‌ها یا قالب، خطای غیرمنتظره‌ای داده که سرور نمی‌تواند ادامه دهد.
• دامنه‌ی پیکربندی: تنظیمات htaccess، php.ini، یا مجوزهای فایل اشتباه است.
• دامنه‌ی منابع: حافظه، CPU، دیسک یا اتصال دیتابیس به سقف رسیده.
• دامنه‌ی شبکه: مسئله‌ای در مسیر بین کاربر و سرور (فایروال، DNS، لوکیشن).

در چارچوب‌های جدی SRE، این چهار دامنه را با مفهوم «Fault Isolation» مدیریت می‌کنند: یعنی نه حدس، بلکه جداسازی سیستماتیک هر دامنه تا پیدا کردن ریشه. تفاوت بین کسی که «سایتم 500 می‌دهد، نمی‌دانم چرا» می‌گوید و کسی که «سایتم 500 می‌دهد، در دامنه‌ی منابع، توی فایل فلان، خط فلان» می‌گوید، در همین جداسازی است. و این مهارت — نه حفظ کد، نه شناخت ابزار — تفاوت بین یک کاربر وردپرس و یک مهندس وردپرس را می‌سازد. اگر می‌خواهید این نگاه را در پروژه‌های وردپرسی پیاده کنید، راهنمای امنیت وردپرس برای مبتدیان، چگونه یک پروژه توسعه وردپرس را ساختاربندی کنیم و سرور چیست و چگونه کار می‌کند را در کنار این بحث بخوانید.

یک نکته‌ی مهم دیگر که در پروژه‌های بلندمدت یاد گرفته‌ام: خطای 500، همیشه از سایت شما نمی‌آید. گاهی از هاست شما می‌آید، گاهی از شبکه، و گاهی از ISP کاربر. یعنی قبل از هر اقدامی، یک سؤال ساده بپرسید: «آیا این خطا برای همه کاربران است یا فقط برای من؟». اگر با VPN یا از شبکه‌ی دیگر سایت باز شد، مسئله در ISP یا لوکیشن شماست، نه در سایت. این تفکیک ساده، بارها در پروژه‌ها ساعاتی از عیب‌یابی بی‌دلیل را حذف کرده است. و اگر فروشگاه ووکامرس دارید، حتماً پس از هر تغییر در پیکربندی، مسیر پرداخت را تست کنید — چون در فروشگاه، خطای 500 در لحظه‌ی پرداخت، معادل سفارش از دست رفته است. مسیر تخصصی در امنیت فروشگاه ووکامرس و خطای ووکامرس: چگونه آن را رفع کنیم آمده است.

آنچه از این راهنما باید با خود ببرید

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

قدم عملی امشب‌تان: در سایت خودتان، حالت WP_DEBUG را روی محیط لوکال یا استجینگ فعال کنید و فایل wp-content/debug.log را برای پنج دقیقه‌ی گشت‌وگذار باز کنید. حتی اگر خطای 500 نداشته باشید، این کار شما را با ابزار لاگ‌گیری آشنا می‌کند — و روزی که به آن نیاز دارید، آماده خواهید بود. مسیر پیشگیری از این خطا در پروژه‌های آینده در چگونه یک سایت وردپرسی راه‌اندازی کنیم و بهترین روش تست قالب وردپرس قبل از انتشار آمده است.

اگر تجربه‌ای از خطای 500 دارید — چه با موفقیت حل شده، چه با شکست — برای من جذاب است بدانم کدام دامنه (کد، پیکربندی، منابع، شبکه) در پروژه‌ی شما مقصر بود و چطور پیدایش کردید. تجربه‌تان را در دیدگاه‌ها بنویسید؛ مخصوصاً اگر سناریویی هست که در این راهنما نبوده ولی در پروژه‌ی شما کلیدی بوده، آن هم داده‌ای است که برای نفر بعدی، ساعت‌ها وقت ذخیره می‌کند. 🛠️