خطای ۵۰۰ Internal Server Error چیست و چطور فروشگاهت را زمین نمیگذارد

TL;DR — خطای ۵۰۰ یعنی سرور وسط جواب دادن به درخواست سقوط کرده و عمداً نمی‌گوید چرا؛ جواب واقعی تقریباً همیشه در error log سرور است، نه روی صفحه.

چرا ۵۰۰ به اندازهی یک هک جدی است

یک شنبه صبح بیدار می‌شوی، سایتت را باز می‌کنی و بهجای صفحهی اصلی فقط یک خط متن می‌بینی: 500 Internal Server Error. نه توضیح، نه stack trace، هیچی. مشتریها فکر می‌کنند فروشگاه بسته شده، گوگل دارد صفحاتی که خطا می‌دهند را از ایندکس کم می‌کند، و بدتر از همه — پنل مدیریت هم معمولاً همین وضع را دارد، یعنی ابزاری که برای درست کردنش لازم داری خودش از کار افتاده.

نکتهی مهمی که پست تازهای در بلاگ Sucuri (۱۴ اکتبر ۲۰۲۶) روش تأکید می‌کند: خطای ۵۰۰ «عمداً مبهم» است. سرور می‌گوید «چیزی شکست و نمیگویم چی» — جزئیات واقعی در error log است، نه روی صفحهی بازدیدکننده. و یک بخش که راهنماهای معمولی حذفش می‌کنند: گاهی ۵۰۰ اصلاً باگ نیست، نشانهی یک سایت هکشده است.

۵۰۰ با ۵۰۲ و ۵۰۳ چه فرقی دارد

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

| کد | یعنی چه | سرنخ | | --- | --- | --- | | 500 | سرور خودش وسط پردازش سقوط کرد | عمداً مبهم — لاگ را بخوان | | 502 | یک سرور جواب بدی از سرور بالادستی گرفت | مشکل بین لایههاست | | 503 | سرویس در دسترس نیست یا شلوغ است | overload یا تعمیر برنامهریزیشده | | 504 | سرور بالادستی timeout شد | یک بخش جواب نمی‌دهد |

در وردپرس گاهی بهجای ۵۰۰ خام پیام «There has been a critical error on this website» می‌بینی — همان فاجع PHP است، فقط بستهبندیش فرق کرده. صفحهی کاملاً سفید هم معمولاً ۵۰۰ است: کد برگشته ولی بدنه ندارد.

مقصرهای همیشگی

طبق تجربهی گفتهشده در منبع، تقریباً هر ۵۰۰ به یکی از این چندتا برمیگردد:

۱. پلاگین یا قالب خراب — آپدیت تازهای با نسخهی PHP شما سازگار نیست، یا دو پلاگین یک تابع هماسم تعریف کردهاند. ۲. فایل .htaccess خراب یا متضاد — یک دایرکتیو غلط کافی است تا همهی URLهای زیر آن پوشه زمین بخورند. ۳. تمام شدن حافظهی PHP یا نسخهی ناسازگار — اسکریپت وسط درخواست میمیرد. ۴. مشکل دسترسی فایلها و مالکیت — روی هاست اشتراکی معمولاً فایل ۶۴۴ و پوشه ۷۵۵ باید باشد. ۵. هک — فایلی بدون دیپلوی یا آپدیتی از سمت تو عوض شده باشد، یعنی یک نفر دیگر دستکاریش کرده.

ترتیب درست رفع مشکل — چکلیست

این ترتیب عمدی است: اول کاری که «علت واقعی» را می‌گوید، بعد سراغ مقصرهای پرتکرار برو.

• [ ] قبل از هر تغییری، بکاپ کامل فایلها و دیتابیس بگیر.
• [ ] error log سرور را بخوان — ارزشمندترین قدم؛ معمولاً فایل و شمارهی خط مقصر را می‌گوید (در پنل هاست، بخش Logs).
• [ ] اگر لاگ کمک نکرد، لاگ سطح اپلیکیشن را روشن کن (در وردپرس: WP_DEBUG و WP_DEBUG_LOG در wp-config.php) — ولی هرگز روی سایت لایو خطاها را روی صفحه نمایش نده.
• [ ] .htaccess را موقتاً به .htaccess_old تغییر نام بده؛ اگر سایت بالا آمد، مشکل همان فایل بود. در وردپرس بعدش تنظیمات پیوندهای یکتا را ذخیره کن تا فایل تمیز ساخته شود.
• [ ] اگر به پنل مدیریت رسیدی: همهی پلاگینها را خاموش کن، سایت را چک کن، بعد یکییکی روشن کن. اگر قفل شدهای، از SFTP پوشهی plugins را تغییر نام بده.
• [ ] اگر لاگ گفت حافظه تمام شد (allowed memory size)، memory_limit را موقتاً بالا ببر — این تشخیص است نه درمان؛ پلاگینی که اینقدر حافظه می‌خواهد خودش مسئله است.
• [ ] نسخهی PHP را چک کن — اگر خطا بلافاصله بعد از آپگرید سمت هاست شروع شد، موقتاً برگردان و کد ناسازگار را درست کن.
• [ ] دسترسیها و مالکیت فایلها را ببین: فایل ۶۴۴، پوشه ۷۵۵، مالک حساب هاست خودت. فایل با دسترسی ۷۷۷ هم کارکردی است هم امنیتی.
• [ ] زمان آخرین تغییر (mtime) فایلهای core، قالب و پلاگین را چک کن — خطای ۵۰۰ بدون هیچ تغییر از سمت تو یعنی کس دیگری فایلها را دستکاری کرده.
• [ ] همهی کشها را خالی کن — صفحه، آبجکت، CDN، reverse proxy — چون کش ممکن است جواب ۵۰۰ را نگه داشته و بعد از رفع مشکل هم همان را سرو کند.
• [ ] اگر لاگ به چیزی خارج از کنترل تو اشاره کرد، با تایم دقیق و خط لاگ به هاست تیکت بزن.

کی بدانی هک است، نه باگ؟

سه علامت روشن:

• خطا شروع شده ولی هیچ دیپلوی، آپدیت یا تغییر تنظیمات از سمت تو نبوده.
• در لاگ، فایلهایی که خودت ننوشتهی در حال اجرا هستند، یا فایلهای PHP عجیب در پوشههای uploads.
• بعد از رفع موقت، مشکل برمیگردد — مخصوصاً در بدافزارهای «خودترمیم» که Sucuri جداگانه دربارهشان نوشته.

اینجا دیگر با رفع خطای معمولی نرو جلو؛ اول اسکن امنیتی و بررسی دسترسیها، بعد ترمیم.

و بعدش؟ رتبهی گوگل را نجات بده

مدت زمان down بودن مهم است، ولی گوگل هم سایتها را مدام چک می‌کند. کارهای فوری:

• اگر خطای سراسری بود و خیلی طول کشید، در Search Console چند صفحهی کلیدی را با «URL Inspection» دوباره تست و درخواست ایندکس کن.
• خطای ۵۰۰ گاهی موقتی رندر می‌شود — گوگل معمولاً چند بار retry می‌کند، پس وحشت نکن، ولی دیر هم نمان.
• یک مانیتور uptime ساده (حتی رایگان) بگذار که پیام بدهد، تا مشتریها زودتر از تو خبردار نشوند.

Q: چرا فقط بعضی صفحاتم ۵۰۰ می‌دهند و بقیه سالم‌اند؟

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

Q: هاستم می‌گوید مشکل از کد من است، من میگویم از هاست — کی راست می‌گوید؟

لاگ تصمیم می‌گیرد، نه حدس. اگر خط لاگ به محدودیت منابع (memory، max_execution_time) یا ماژول سرور اشاره کرد، سمت هاست است؛ اگر به فایل و خط کد خودت اشاره کرد، سمت تو. تایم دقیق + خط لاگ را در تیکت بگذار تا رفت و برگشت نکنی.

Q: بعد از رفع، دوباره ۵۰۰ می‌آید. چیکار کنم؟

یعنی علت ریشهی رفع نشده. مرتبترین دلیل: پلاگینی که هر بار با cron یا ورود مشتری اجرا می‌شود و سقوط می‌کند. لاگ را در لحظهی تکرار خطا بگیر (نه بعداً)، و یادت باشد اگر الگوی برگشت «خودترمیمشونده» است، احتمال هک جدی است.

منابع

• ۵۰۰ Internal Server Error: What It Means and How to Fix It — Sucuri Blog
• Anatomy of a WooCommerce Skimmer — Scott Helme
• SC WordPress Malware: Self-Healing Loaders and Backdoors — Sucuri Blog