چگونه خطای 500 Internal Server Error را رفع کنیم؟

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

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

خطای ۵۰۰ دقیقاً چه معنایی دارد؟

کد وضعیت ۵۰۰ در پروتکل HTTP (Hypertext Transfer Protocol) به معنای خطای داخلی سرور است؛ یعنی سرور درخواست کاربر را دریافت کرده ولی نتوانسته آن را پردازش کند. این خطا با کدهای خانواده‌ی ۴xx تفاوت ماهوی دارد: در خطاهای ۴xx، مسئله معمولاً سمت درخواست است (مثلاً ۴۰۴ برای آدرس ناموجود یا ۴۰۳ برای عدم دسترسی)، ولی در ۵۰۰، درخواست سالم بوده و سرور در تولید پاسخ شکست خورده. توضیح کامل و فنی این کد در ویکی‌پدیا قابل مشاهده است، اما برای مقصود ما، تفاوت کلیدی این است که خطای ۵۰۰ تقریباً همیشه در لایه‌ی سرور یا کد اجراکننده‌ی آن ریشه دارد، نه در رفتار کاربر.

نکته‌ی مهمی که در پروژه‌های واقعی بارها دیده‌ام این است که خطای ۵۰۰ یک تابلوی مقصد نهایی نیست؛ یک چتر عمومی است که کدهای باطنی متعددی زیر آن پنهان شده‌اند. مثلاً وقتی یک اسکریپت PHP به دلیل کمبود حافظه متوقف می‌شود، وب‌سرور همان خطای ۵۰۰ را به کاربر برمی‌گرداند. اگر فایل .htaccess دستور نامعتبری داشته باشد، همان ۵۰۰ را می‌بینید. اگر یک افزونه، استثنای (Exception) مدیریت‌نشده پرتاب کند، باز هم کاربر همان پیام را می‌بیند. بنابراین اولین مهارت در عیب‌یابی این خطا، تشخیص این است که کدام لایه‌ی زیرین درگیر است.

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

شش خانواده‌ی ریشه‌ای خطای ۵۰۰

در تجربه‌ی چندساله روی پروژه‌های وردپرسی و سرورهای لینوکسی، خطای ۵۰۰ را در شش خانواده‌ی اصلی دسته‌بندی می‌کنم. تشخیص خانواده، نیمی از راه‌حل است:

خانواده‌ی اول: کد معیوب یا استثنای مدیریت‌نشده

این خانواده، شایع‌ترین دلیل خطای ۵۰۰ در سایت‌های وردپرسی است. یک خطای نگارشی (Syntax Error) در یک فایل PHP، یا یک استثنای (Exception) پرتاب‌شده که هیچ‌جا گرفته نمی‌شود، کافی است تا کل صفحه از کار بیفتد. مثلاً یک ویرگول جا‌افتاده در فایل functions.php می‌تواند تمام سایت را سفید یا ۵۰۰ کند. مسیر تشخیص این خانواده، دقیقاً به همان چیزی برمی‌گردد که در Parse Error در PHP و راه‌حل آن باز کرده‌ام.

خانواده‌ی دوم: محدودیت منابع سرور

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

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

فایل .htaccess در آپاچی، یا فایل‌های پیکربندی Nginx، اگر دستور نامعتبری داشته باشند، وب‌سرور کل درخواست‌های آن دامنه را با خطای ۵۰۰ رد می‌کند. این حالت معمولاً بعد از یک تغییر پیکربندی یا نصب افزونه‌ای که فایل .htaccess را دست‌کاری می‌کند، بروز می‌دهد.

خانواده‌ی چهارم: مشکل دیتابیس

اگر اتصال بین PHP و دیتابیس (MySQL یا MariaDB) به هر دلیل قطع شود، وردپرس نمی‌تواند محتوا را بخواند و در بسیاری از تنظیمات، به‌جای پیام واضح، یک خطای ۵۰۰ عمومی نمایش می‌دهد. مسیر کامل این تشخیص در رفع خطای اتصال به دیتابیس در وردپرس آمده است.

خانواده‌ی پنجم: مجوزهای فایل و پوشه

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

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

وقتی سرویس PHP-FPM از کار می‌افتد، یا وقتی یک CDN یا پراکسی معکوس (Reverse Proxy) نمی‌تواند به سرور اصلی وصل شود، کاربر به‌جای خطای واضح‌تر، خطای ۵۰۰ می‌بیند. این خانواده در سایت‌هایی که پشت Cloudflare یا پروکسی معکوس دیگری هستند، شایع‌تر است.

واکنش اول در بحران: پنج حرکت سریع

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

1. تعیین دامنه‌ی خطا: ببینید آیا تمام سایت خطا می‌دهد یا فقط یک صفحه‌ی خاص. اگر کل سایت است، سریع‌تر به لایه‌ی سرور یا پیکربندی بروید. اگر یک صفحه‌ی خاص است، به سراغ کد یا افزونه‌ی مرتبط بروید.
2. بکاپ لحظه‌ی جرم: قبل از هر تغییری، یک نسخه‌ی فوری از فایل‌ها و دیتابیس بگیرید. حتی اگر همه‌چیز خراب است، همین بکاپ می‌تواند در تحلیل ریشه کمک کند. روش کامل در رفع خطای آپلود فایل در وردپرس نیست، ولی اصل کار در همان پروتکل آشنای بکاپ است.
3. فعال‌سازی حالت تعمیرات: اگر سایت فروشگاهی است، صفحه‌ی تعمیرات را فعال کنید تا کاربران به‌جای خطای ۵۰۰، پیام آگاهانه ببینند. این کار هم تجربه‌ی کاربری را حفظ می‌کند و هم فرصت عیب‌یابی می‌دهد.
4. بررسی لاگ سرور: ابتدا لاگ وب‌سرور و سپس لاگ PHP را بررسی کنید. در بیشتر موارد، ریشه در همان دو دقیقه‌ی اول پیدا می‌شود. روش دقیق خواندن لاگ در بررسی خطاهای سرور در لاگ‌ها آمده است.
5. غیرفعال‌سازی افزونه‌های مشکوک: اگر آخرین تغییر سایت نصب یا آپدیت یک افزونه بود، همان افزونه را از مسیر File Manager یا SSH غیرفعال کنید. این حرکت معمولاً سایت را در چند ثانیه برمی‌گرداند.

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

خواندن درست لاگ‌ها

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

مهم‌ترین نکته‌ای که در تجربه‌ام بارها دیده‌ام این است که بسیاری از خطاهای ۵۰۰ در لاگ وب‌سرور به‌عنوان 500 ثبت می‌شوند، ولی در لاگ PHP به‌عنوان Fatal error: Allowed memory size exhausted یا Fatal error: Maximum execution time exceeded یا PHP Parse error ظاهر می‌شوند. اگر فقط لاگ وب‌سرور را نگاه کنید، هیچ‌وقت به ریشه نمی‌رسید.

پیدا کردن لاگ PHP در پنل‌های مختلف

در cPanel، لاگ PHP معمولاً در مسیر /home/username/logs/ یا از طریق بخش Errors قابل دسترسی است. در هاست‌های مدیریت‌شده وردپرس، فایل لاگ غالباً در مسیر wp-content/debug.log قرار می‌گیرد، به شرط آن‌که WP_DEBUG_LOG در فایل wp-config.php فعال شده باشد. جزئیات دقیق این تنظیمات در رفع خطای Memory Limit در وردپرس آمده است.

نکات مهم در خواندن لاگ

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

htaccess، مجوزها و بازنویسی URL

یکی از شایع‌ترین دلیل‌های خطای ۵۰۰ در سایت‌های وردپرسی، دستور نامعتبر در فایل .htaccess است. این فایل، پیکربندی وب‌سرور آپاچی را در سطح دایرکتوری تنظیم می‌کند و یک دستور نادرست در آن می‌تواند کل سایت را از کار بیندازد.

روش تشخیص htaccess معیوب

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

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

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

مجوزهای فایل و پوشه

مجوزهای استاندارد در وردپرس: پوشه‌ها ۷۵۵، فایل‌ها ۶۴۴ و فایل wp-config.php روی ۶۰۰ یا ۶۴۰. اگر مجوزها از این استاندارد منحرف شوند، وب‌سرور نمی‌تواند فایل‌ها را بخواند یا اجرا کند. برای بازنشانی مجوزها از طریق SSH:

find /path/to/wordpress -type d -exec chmod 755 {} \;
find /path/to/wordpress -type f -exec chmod 644 {} \;
chmod 600 /path/to/wordpress/wp-config.php

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

php.ini و محدودیت‌های منابع

لایه‌ی PHP، مسئول اجرای کد سایت شما است. اگر منابع این لایه محدود باشند، اجرای کد نیمه‌کاره متوقف می‌شود و همان خطای ۵۰۰ ظاهر می‌شود. سه مقدار بحرانی در php.ini:

memory_limit

حداکثر حافظه‌ای که یک اسکریپت PHP می‌تواند استفاده کند. مقدار پایین این تنظیم، باعث خطای Allowed memory size exhausted می‌شود. برای سایت‌های وردپرسی، مقدار حداقل ۲۵۶ مگابایت و برای فروشگاه‌ها ۵۱۲ مگابایت توصیه می‌شود. نکات تکمیلی درباره‌ی این خطا در راه‌حل خطای Memory Limit در PHP آمده است.

max_execution_time

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

max_input_vars

حداکثر تعداد متغیرهای ورودی در یک درخواست POST. اگر فرم‌های سایت شما (مثلاً فرم تسویه‌حساب یا فرم‌های مدیریتی) بیش از این مقدار فیلد داشته باشند، بخشی از داده‌ها ارسال نمی‌شود و خطاهای پیش‌بینی‌نشده ظاهر می‌شود. مقدار توصیه‌شده حداقل ۳۰۰۰ است.

برای تغییر این مقادیر، می‌توانید از فایل php.ini، از فایل .user.ini در ریشه‌ی سایت، یا از پنل مدیریت هاست استفاده کنید. در بعضی هاست‌ها، تغییر این مقادیر به‌صورت مستقیم از پنل ممکن نیست و باید با پشتیبانی درخواست دهید.

افزونه‌ها، قالب و کد سفارشی

در سایت‌های وردپرسی، افزونه‌ها و قالب مسئول بیش از نیمی از خطاهای ۵۰۰ هستند. سه سناریوی رایج:

افزونه‌ی ناسازگار

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

کد سفارشی در functions.php

یک خطای نگارشی در فایل functions.php قالب، کافی است که کل سایت با خطای ۵۰۰ سفید شود. نشانه‌ی این وضعیت: سایت بعد از یک ویرایش کد در پنل ظاهر، از کار افتاده. راه‌حل در رفع صفحه‌ی سفید مرگ در وردپرس آمده است.

تداخل افزونه‌ها با یکدیگر

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

دیتابیس و اتصال‌های قطع‌شده

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

نشانه‌های مشکل دیتابیس

• کندی شدید پیش از خطای ۵۰۰.
• خطای ۵۰۰ در صفحه‌های خاص و پرفرکانس دیتابیس، مثل آرشیو یا جستجو.
• پیام‌های Error establishing a database connection در لاگ PHP.
• افت عملکرد سراسری بعد از افزایش ترافیک یا واردات داده.

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

کوئری مفید برای بررسی کندی دیتابیس

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

SELECT table_name, table_rows, data_length, index_length
FROM information_schema.tables
WHERE table_schema = 'your_database_name'
ORDER BY data_length DESC
LIMIT 20;

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

لایه‌ی سرور: وب‌سرور، PHP-FPM و پراکسی

وقتی لایه‌ی اپلیکیشن سالم است، ریشه در زیرساخت است. سه جزء اصلی که باید بررسی شوند:

وضعیت وب‌سرور

اگر آپاچی یا Nginx در حال اجرا نیست، تمام سایت خطای ۵۰۰ می‌دهد. با دستور زیر می‌توانید وضعیت را بررسی کنید:

sudo systemctl status apache2
sudo systemctl status nginx

اگر سرویس متوقف شده باشد، با دستور sudo systemctl start apache2 می‌توانید آن را دوباره راه‌اندازی کنید. اما باید علت توقف را هم بررسی کنید؛ ممکن است یک فایل پیکربندی معیوب باعث آن شده باشد.

وضعیت PHP-FPM

در سرورهایی که از PHP-FPM استفاده می‌کنند، اگر این سرویس از کار بیفتد، سایت با خطای ۵۰۲ یا ۵۰۰ (بسته به پیکربندی) رو‌به‌رو می‌شود. وضعیت را با sudo systemctl status php-fpm بررسی کنید.

پراکسی معکوس و CDN

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

فضای دیسک و منابع

اگر فضای دیسک سرور پر شده باشد، PHP نمی‌تواند لاگ بنویسد یا فایل‌های کش را ذخیره کند و خطای ۵۰۰ رخ می‌دهد. برای بررسی:

df -h
du -sh /var/log/* | sort -h

راه‌حل کامل این سناریو در رفع خطای پر شدن هارد سرور آمده است.

بازگردانی سرویس و اولویت‌بندی

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

1. برگرداندن سرویس در کمترین زمان: اگر عیب‌یابی طولانی می‌شود، از یک راه‌حل موقت مثل بستن مسیرهای مشکل‌دار یا غیرفعال‌سازی افزونه‌ی معیوب استفاده کنید تا سایت بالا بیاید.
2. رفع ریشه‌ای: بعد از بازگردانی سرویس، تحلیل ریشه را تا پایان ادامه دهید. رفع موقت، دردی را درمان نمی‌کند و خطا بعداً برمی‌گردد.
3. مستندسازی: ریشه‌ی خطا، روش تشخیص و راه‌حل نهایی را در یک یادداشت ثبت کنید. این یادداشت در بحران بعدی، ساعت‌ها زمان صرفه‌جویی می‌کند.
4. پایش پس از بازگشت: یک هفته بعد از رفع، سایت را از نظر عملکرد و لاگ پایش کنید تا از برنگشتن خطا مطمئن شوید.

پیشگیری و پایش مستمر

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

سطح اول: پایش منابع سرور

ابزارهایی مثل htop، glances یا New Relic می‌توانند مصرف CPU، RAM و دیسک را به‌صورت زنده نشان دهند. این پایش به شما اجازه می‌دهد قبل از رسیدن به سقف منابع، اقدام کنید.

سطح دوم: پایش لاگ و هشدار

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

سطح سوم: پایش خارجی آپ‌تایم

سرویس‌هایی مثل Uptime Robot یا Pingdom هر چند دقیقه یک درخواست به سایت شما می‌فرستند و در صورت خطای ۵۰۰، هشدار می‌دهند. این سطح پایش از دید کاربر واقعی، بهترین شاخص سلامت سایت است.

پرسش‌های پرتکرار درباره خطای ۵۰۰ سرور

آیا خطای ۵۰۰ همیشه ناشی از سرور است؟

خیر. گرچه خطای ۵۰۰ در پروتکل HTTP به معنای خطای داخلی سرور است، ولی در عمل، ریشه می‌تواند در کد اپلیکیشن (مثل یک افزونه‌ی معیوب)، پیکربندی نادرست، یا حتی دیتابیس باشد. تفاوت کلیدی این است که مسئولیت رفع، همیشه با صاحب سایت است، نه با کاربر.

چگونه بفهمم خطای ۵۰۰ از کدام افزونه است؟

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

چرا خطای ۵۰۰ فقط در بعضی صفحات رخ می‌دهد؟

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

آیا تغییر قالب می‌تواند خطای ۵۰۰ را رفع کند؟

اگر ریشه در کد قالب باشد، بله. برای تست سریع، قالب را موقتاً به Twenty Twenty-Four تغییر دهید. اگر سایت بالا آمد، مقصر قالب فعلی است. این تست، در کنار غیرفعال‌سازی افزونه‌ها، سریع‌ترین روش عیب‌یابی است.

چگونه بدون دسترسی به پنل هاست، خطای ۵۰۰ را رفع کنیم؟

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

آیا خطای ۵۰۰ روی سئو تأثیر می‌گذارد؟

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

چگونه مطمئن شوم که خطای ۵۰۰ کاملاً برطرف شده است؟

سه کار انجام دهید: اول، در لاگ‌ها هیچ خطای جدیدی ثبت نشود. دوم، تمام صفحات کلیدی سایت (خانه، محصول، تسویه‌حساب، تماس) را با مرورگر تست کنید. سوم، ۴۸ ساعت اول را با پایش دقیق بگذرانید و اگر خطا برنگشت، می‌توانید مطمئن شوید که ریشه برطرف شده است.

آیا خطای ۵۰۰ می‌تواند ناشی از حمله باشد؟

بله. بعضی حملات مثل DDoS یا Brute Force می‌توانند منابع سرور را مصرف کنند و باعث خطای ۵۰۰ شوند. نشانه‌ی این سناریو: افزایش ناگهانی ترافیک از یک محدوده‌ی IP مشخص یا خطاهای ۵۰۰ در ساعات خاص. راه‌حل: بستن آی‌پی‌های مهاجم و استفاده از فایروال ابری.

چگونه خطای ۵۰۰ را در وردپرس چندسایتی (Multisite) عیب‌یابی کنیم؟

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

آیا می‌توانم از ابزارهای آنلاین برای تشخیص خطای ۵۰۰ استفاده کنم؟

ابزارهای آنلاین مثل GTmetrix یا Pingdom می‌توانند نشان دهند خطا در کدام مرحله رخ داده، ولی جزئیات ریشه‌ای را نمی‌دهند. برای تشخیص دقیق، همیشه باید به لاگ سرور و لاگ PHP دسترسی داشته باشید.

چرا خطای ۵۰۰ بعد از مهاجرت سرور ظاهر می‌شود؟

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

سخن آخر: درسی که این خطا در پروژه‌ها به من آموخته

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

سه اصل که تجربه به من ثابت کرده و در هر پروژه‌ای رعایت می‌کنم:

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

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