خطای 500 پاسخ عمومی وب‌سرور به یک شکست داخلی است؛ خودش نمی‌گوید مشکل از وردپرس، PHP-FPM، پیکربندی Apache/Nginx یا منابع سرور است. اگر فقط refresh می‌کنید یا فایل .htaccess را بدون دیدن لاگ تغییر می‌دهید، ممکن است نشانه جابه‌جا شود ولی علت باقی بماند. زمان و URL خطا را ثبت کنید و همان درخواست را در لاگ دنبال کنید.
پاسخ سریع: ابتدا backup بگیرید، status code را تأیید کنید، error log وب‌سرور و PHP را در همان timestamp بخوانید و سپس از تغییرات کم‌ریسک مانند غیرفعال‌سازی مؤلفه تازه‌تغییرکرده شروع کنید. در Nginx فایل .htaccess خوانده نمی‌شود؛ بازسازی آن برای Nginx راه‌حل نیست.
خطا در همه صفحات است یا فقط یک مسیر؟
| الگو | مظنون‌های عملی |
|---|---|
| همه سایت و wp-admin | fatal سراسری PHP، پیکربندی یا منابع |
| فقط یک نوشته یا endpoint | کد همان مسیر، داده نامعتبر یا query |
| فقط بعد از login | افزونه مدیریتی، session، نقش یا AJAX |
| گاه‌به‌گاه زیر بار | worker، memory، timeout یا دیتابیس |
لاگ مناسب را بخوانید
در Nginx، error log نشان می‌دهد upstream چه پاسخی داده یا اتصال چرا قطع شده است. در Apache خطای rewrite، مجوز و PHP دیده می‌شود. مسیر دقیق به توزیع و virtual host بستگی دارد؛ آن را از تنظیمات همان سرور پیدا کنید. برای سرویس systemd می‌توان محدوده زمانی را بدون تغییر سرویس خواند:
journalctl -u php8.3-fpm --since "10 minutes ago"
journalctl -u nginx --since "10 minutes ago"نام unit نسخه PHP در سرور شما ممکن است متفاوت باشد. لاگ را عمومی منتشر نکنید؛ token، مسیر داخلی یا داده کاربر ممکن است داخل آن باشد. برای Apache نیز unit و فایل لاگ را از پیکربندی واقعی پیدا کنید.
راه‌حل‌ها از کم‌ریسک تا پیشرفته
- آخرین تغییر را برگردانید: افزونه یا snippet تازه را موقتاً غیرفعال کنید. اگر deploy انجام شده، rollback همان release از بازگردانی پراکنده فایل‌ها قابل اتکاتر است.
- fatal PHP را پیدا کنید: debug را فقط برای log فعال و نمایش خطا را خاموش نگه دارید. نام فایل و خط اول exception را مبنا قرار دهید.
- Apache و htaccess: نسخه فعلی را نگه دارید، سپس برای آزمون نام
.htaccessرا تغییر دهید. ruleهای امنیتی، redirect و cache باید بعداً دقیق بازگردند. - مجوز و مالکیت: فایل‌ها باید برای کاربر مناسب وب‌سرور قابل خواندن باشند.
chmod 777راه‌حل عمومی نیست؛ ابتدا مدل مالکیت deployment را مشخص کنید. - منابع: فضای دیسک، inode، RAM و محدودیت process را بررسی کنید. پر شدن دیسک می‌تواند session، cache و log را مختل کند.
- PHP-FPM: worker exit، max children و timeout را با بار واقعی تطبیق دهید. افزایش کور worker بدون محاسبه RAM ممکن است OOM ایجاد کند.
تفاوت 500 با 502 و 504
500 معمولاً یعنی برنامه یا وب‌سرور درخواست را با شکست داخلی تمام کرده است. 502 بیشتر به پاسخ نامعتبر یا قطع ارتباط upstream اشاره دارد و 504 یعنی proxy در مهلت تعیین‌شده پاسخی نگرفته است. CDN ممکن است صفحه‌ای مشابه نشان دهد؛ header و لاگ origin تعیین‌کننده‌اند.
مسیر درخواست را لایه‌به‌لایه دنبال کنید
در معماری ساده درخواست از مرورگر به وب‌سرور و سپس PHP-FPM می‌رود. در معماری‌های دیگر CDN، WAF، load balancer یا reverse proxy نیز وجود دارد. زمان پاسخ، headerها و یک شناسه درخواست ـ اگر زیرساخت آن را تولید می‌کند ـ کمک می‌کند خطا را میان لایه‌ها مرتبط کنید. اگر CDN عدد 500 نشان می‌دهد ولی origin برای همان درخواست 200 ثبت کرده، باید مسیر cache یا edge بررسی شود؛ اگر origin نیز 500 دارد، تمرکز را به برنامه و upstream ببرید.
برای آزمون origin، کنترل دسترسی و TLS را دور نزنید و IP خصوصی یا پورت مدیریتی را عمومی نکنید. یک درخواست داخلی کنترل‌شده یا ابزار مانیتورینگ موجود امن‌تر از باز کردن موقت firewall است.
خطاهای پیکربندی را با آزمون syntax جدا کنید
پس از تغییر Nginx، پیش از reload ساختار پیکربندی را آزمایش کنید. موفق بودن syntax به معنی درست بودن منطق route نیست، اما از قطع سرویس به‌دلیل اشتباه نگارشی جلوگیری می‌کند:
nginx -tاجرای reload و محل فایل تنظیمات به نحوه نصب و مدیریت سرویس بستگی دارد. در Apache نیز ابزار آزمون config متناسب با توزیع را به کار ببرید. بدون backup فایل و دانستن virtual host فعال، قطعه تنظیمات ناشناس را جایگزین نکنید.
اگر خطا فقط زیر بار رخ می‌دهد
یک درخواست عادی ممکن است سالم باشد ولی هم‌زمانی بالا صف PHP-FPM، اتصال دیتابیس یا RAM را تمام کند. تعداد درخواست، مدت query، workerهای busy و رخداد OOM را در یک timeline قرار دهید. افزایش pm.max_children بدون محاسبه مصرف هر process می‌تواند فشار حافظه را بیشتر کند. همچنین افزایش timeout یک query معیوب را فقط دیرتر شکست می‌دهد.
بررسی منابع بدون ایجاد اختلال
df -h
df -i
free -h
uptimeاین دستورها فقط وضعیت را می‌خوانند. پر بودن filesystem را با حذف کور log یا فایل دیتابیس حل نکنید. ابتدا مصرف‌کننده را شناسایی، retention را اصلاح و فقط داده‌ای را حذف کنید که سیاست نگهداری و backup آن روشن است.
اشتباه‌هایی که تشخیص را خراب می‌کنند
- تغییر هم‌زمان PHP، افزونه، قالب و وب‌سرور.
- افزایش همه timeoutها بدون یافتن query کند.
- حذف logها پیش از نگهداری نمونه خطا.
- کپی پیکربندی Nginx بدون اجرای
nginx -t. - restart پیاپی که شواهد crash را از بین می‌برد.
چه زمانی مداخله تخصصی لازم است؟
اگر stack trace به یک افزونه می‌رسد، ابتدا روش بازیابی پس از آپدیت افزونه را اجرا کنید؛ برای پیام عمومی وردپرس نیز راهنمای Critical Error مناسب‌تر است.
اگر 500 تصادفی است، فقط زیر بار رخ می‌دهد، چند لایه CDN و proxy دارید یا لاگ به segmentation fault، OOM و دیتابیس می‌رسد، مسئله صرفاً یک تنظیم وردپرس نیست. بررسی فنی وردپرس می‌تواند ارتباط میان request، PHP-FPM، وب‌سرور و MySQL را مشخص کند و تغییرات را با rollback اجرا کند.
پرسش‌های متداول
آیا پاک کردن .htaccess امن است؟
خیر. ruleهای امنیتی و redirect ممکن است در آن باشند. فایل را backup و برای آزمون تغییر نام دهید؛ در Nginx اثری ندارد.
چرا خطا بعد از refresh ناپدید می‌شود؟
ممکن است یکی از workerها خراب یا منبع موقتاً کم باشد. این رفتار دلیل رفع شدن نیست و باید با timestamp در لاگ دنبال شود.
آیا CDN عامل 500 است؟
گاهی CDN خطای origin را نمایش می‌دهد. پاسخ و لاگ origin را جداگانه بررسی کنید تا محل تولید status مشخص شود.