خطای 500 یا Internal Server Error یعنی سرور هنگام پردازش درخواست با وضعیتی غیرمنتظره روبه‌رو شده و نتوانسته پاسخ معمول را تولید کند. این پیام به‌تنهایی علت را مشخص نمی‌کند؛ برای رفع آن باید زمان رخداد، تغییرات اخیر و گزارش خطای همان درخواست را کنار هم بررسی کنید.
این راهنما برای عیب‌یابی عمومی سایت و وردپرس است، نه یک دستور ثابت برای همه سرورها. بازبینی فنی: ۲۷ مهر ۱۴۰۵.
اگر بازدیدکننده سایت هستید
ابتدا کمی صبر کنید و صفحه معمولی را دوباره باز کنید. اگر خطا هنگام پرداخت یا ثبت سفارش رخ داده است، پیش از ارسال دوباره، وضعیت سفارش و تراکنش را کنترل کنید؛ تکرار درخواست ممکن است نتیجه ناخواسته داشته باشد. نشانی صفحه، زمان و متن خطا را برای پشتیبانی سایت ارسال کنید، اما رمز، اطلاعات کارت و کدهای خصوصی را نفرستید.
پاک کردن کش مرورگر ممکن است نمایش یک پاسخ ذخیره‌شده را تغییر دهد، ولی درمان قطعی ایراد سمت سرور نیست. اگر چند دستگاه نیز همین خطا را می‌بینند، تغییرات مکرر مرورگر معمولاً مسیر مناسبی برای یافتن علت نیست.
قدم اول مدیر سایت: محدوده خطای 500 را مشخص کنید
بدون تغییر تنظیمات، بررسی کنید آیا همه صفحات خراب‌اند یا فقط ورود، یک فرم، صفحه ویرایش یا عملیات مشخص. وضعیت کاربران واردشده و مهمان را جداگانه ثبت کنید. در گزارش کار، زمان را همراه منطقه زمانی بنویسید؛ این کار تطبیق با لاگ میزبان را آسان‌تر می‌کند.
- آخرین تغییر پیش از شروع مشکل چه بوده است: افزونه، قالب، نسخه PHP، انتقال فایل یا قانون جدید وب‌سرور؟
- کد پاسخ واقعاً 500 است یا صفحه، خطای دیگری از پراکسی یا شبکه را نشان می‌دهد؟
- آیا مشکل مداوم است یا فقط هم‌زمان با یک عملیات سنگین رخ می‌دهد؟
کدهای 502، 503 و 504 را با 500 یکی نگیرید؛ هرکدام معنای متفاوتی دارند. برای سناریوی 503 می‌توانید راهنمای خطای 503 در وردپرس را مطالعه کنید.
لاگ مرتبط با درخواست را بخوانید
گزارش خطای وب‌سرور و PHP را در پنل میزبانی یا از پشتیبانی بگیرید. زمان، مسیر درخواست و در صورت وجود شناسه درخواست را تطبیق دهید. آخرین خط یک فایل لاگ لزوماً مربوط به بازدید شما نیست؛ روی سرور مشترک، برنامه‌های دیگر نیز ممکن است هم‌زمان پیام تولید کنند.
در وردپرس، ابزارهای اشکال‌زدایی می‌توانند خطای برنامه را ثبت کنند. تنظیمات را ابتدا در محیط آزمایشی و با نسخه پشتیبان تغییر دهید. نمایش عمومی خطا را خاموش نگه دارید و محل گزارش را خصوصی انتخاب کنید؛ مسیر فایل‌ها، داده درخواست یا اطلاعات کاربران نباید در صفحه عمومی یا یک فایل لاگ قابل دانلود افشا شوند.
پس از تشخیص و اصلاح، حالت اشکال‌زدایی موقت را به وضعیت عادی برگردانید و دسترسی و نگهداری گزارش‌ها را کنترل کنید. صرف ساختن debug.log بدون محدود کردن دسترسی، یک راهکار امن محسوب نمی‌شود.
تغییر اخیر را کنترل‌شده بررسی کنید
اگر خطا بلافاصله پس از یک تغییر آغاز شده، همان تغییر را در یک کپی آزمایشی بازتولید کنید. نسخه فعلی فایل‌ها و دیتابیس را نگه دارید تا راه بازگشت از دست نرود. چند تغییر هم‌زمان انجام ندهید؛ در غیر این صورت مشخص نمی‌شود کدام اقدام مؤثر بوده است.
برای افزونه یا قالب مشکوک، سازگاری نسخه‌ها و متن خطا را بررسی کنید. غیرفعال‌سازی آزمایشی باید محدود و قابل بازگشت باشد. روی سایت فعال، خاموش کردن همه افزونه‌ها می‌تواند پرداخت، ورود یا حفاظت سایت را مختل کند. همچنین فقط با دیدن نام یک افزونه در لاگ، آن را بدافزار فرض نکنید.
تنظیمات وب‌سرور و دسترسی فایل‌ها
در Apache، دستور نامعتبر یا مجازنبودن یک دستور در .htaccess می‌تواند خطای سرور ایجاد کند. از فایل موجود کپی بگیرید و خط مرتبط را با گزارش وب‌سرور تطبیق دهید. پاک کردن کامل فایل، علاوه بر مسیرها، ممکن است قوانین دسترسی و حفاظت را هم حذف کند.
این توصیه را برای همه وب‌سرورها یکسان به کار نبرید. ساختار تنظیمات به پیکربندی سرویس بستگی دارد؛ اگر پنل آن را مدیریت می‌کند، بدون هماهنگی فایل‌های تولیدشده را جایگزین نکنید. برای جزئیات مربوط به وردپرس، راهنمای اصلاح htaccess را ببینید.
مالکیت و مجوز فایل‌ها نیز باید با مدل اجرای همان میزبان سازگار باشد. دادن مجوز 777 به همه فایل‌ها راه‌حل عمومی نیست و می‌تواند امنیت را کاهش دهد. از پشتیبانی بخواهید ناسازگاری مشخص را اصلاح کند، نه اینکه دسترسی کل سایت را بی‌قید باز کند.
چه زمانی منابع یا نسخه PHP را بررسی کنیم؟
اگر گزارش خطا از کمبود حافظه، محدودیت اجرا یا نبود یک قابلیت خبر می‌دهد، همان مورد را بررسی کنید. افزایش تصادفی همه محدودیت‌ها ممکن است مشکل اصلی را پنهان کند. سقف اندازه آپلود را نیز با حافظه اجرای برنامه اشتباه نگیرید؛ تغییر یکی الزاماً دیگری را اصلاح نمی‌کند.
قبل از تغییر نسخه PHP، سازگاری کد، افزونه‌ها و نیازمندی برنامه را در محیط آزمایشی بررسی کنید. روی هاست مدیریت‌شده، نسخه و تنظیمات مؤثر وب را از پنل و پشتیبانی پیگیری کنید؛ خروجی ابزار خط فرمان همیشه نشان‌دهنده وضعیت درخواست وب نیست.
پس از رفع خطا چه چیزهایی را آزمایش کنیم؟
همان عملیاتی را که مشکل ایجاد می‌کرد دوباره در شرایط کنترل‌شده امتحان کنید. سپس صفحه اصلی، ورود، فرم‌ها و بخش‌های حیاتی را برای مهمان و مدیر بررسی کنید. اگر کش یا CDN دارید، پس از اصلاح علت و با محدوده مناسب آن را پاک کنید؛ پاک کردن کش به‌تنهایی اثبات رفع خطای 500 نیست.
در تیکت پشتیبانی، نشانی صفحه، زمان، تغییرات اخیر و پیام خطای پالایش‌شده را بفرستید. فایل تنظیمات دارای رمز یا آرشیو کامل لاگ کاربران را عمومی منتشر نکنید. نتیجه نهایی و روش بازگشت را نیز ثبت کنید تا رخداد بعدی سریع‌تر پیگیری شود.
منابع: تعریف HTTP 500 در MDN، اشکال‌زدایی وردپرس، مستندات htaccess در Apache و ایمن‌سازی وردپرس.
