ارورهای سری ۵xx مربوط به سرور و روش‌های رفع آن‌ها

سایت بالا نمی‌آید و مرورگر به‌جای صفحه، عددی مثل 500، 502 یا 503 نشان می‌دهد. این یعنی درخواست شما سالم به مقصد رسیده، اما سرور نتوانسته پاسخ درستی برگرداند. هر پاسخ HTTP یک کد وضعیت سه‌رقمی دارد و همین عدد، دقیق‌ترین سرنخ برای پیدا کردن محل ایراد است؛ کدهایی که با ۵ شروع می‌شوند انگشت اتهام را به سمت سرور می‌گیرند، نه به سمت مرورگر کاربر.

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

خطاهای سری ۵xx دقیقاً چه چیزی را نشان می‌دهند

کدهای وضعیت HTTP در پنج دسته‌ی اصلی تقسیم می‌شوند و فهرست کوتاه چهار دسته‌ی دیگر را در انواع خطاهای هاست و دلیل آن‌ها آورده‌ایم. دسته‌ی پنجم، یعنی ۵xx، مربوط به خطاهایی است که از سمت سرور ایجاد می‌شوند. وقتی مرورگر پیامی مانند 500 Internal Server Error یا 503 Service Unavailable نشان می‌دهد، یعنی وب‌سرور درخواست را دریافت کرده اما در پردازش یا پاسخ‌دهی به مشکل خورده است.

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

curl -I https://example.com

# فقط عدد کد وضعیت
curl -sS -o /dev/null -w "%{http_code}n" https://example.com

انواع ارورهای سری ۵xx و روش رفع هرکدام

در ادامه خطاهای شناخته‌شده‌ی محدوده‌ی ۵۰۰ تا ۵۱۱ را با معنا و روش رفع هرکدام بررسی می‌کنیم. یک قاعده‌ی کلی را هم همین ابتدا بپذیرید: پیش از هر تغییری در .htaccess، web.config یا کانفیگ وب‌سرور، از فایل فعلی یک نسخه‌ی پشتیبان بگیرید تا بتوانید در چند ثانیه به وضعیت قبل برگردید.

۵۰۰ – Internal Server Error

رایج‌ترین خطای سمت سرور است. این ارور یعنی سرور به خطایی برخورده که نتوانسته آن را در قالب کد دقیق‌تری بیان کند. علت می‌تواند از یک دستور اشتباه در .htaccess تا Fatal Error در PHP، مجوز نادرست فایل‌ها یا تداخل ماژول‌های وب‌سرور باشد.

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

# Ubuntu / Debian با Apache
tail -n 50 /var/log/apache2/error.log

# AlmaLinux / Rocky / CentOS با Apache
tail -n 50 /var/log/httpd/error_log

# سرورهای cPanel با EasyApache 4
tail -n 50 /etc/apache2/logs/error_log

# Nginx
tail -n 50 /var/log/nginx/error.log

# LiteSpeed و OpenLiteSpeed
tail -n 50 /usr/local/lsws/logs/error.log

روی هاست اشتراکی به SSH نیاز ندارید: فایل error_log معمولاً کنار فایل‌های سایت در public_html ساخته می‌شود و در cPanel هم بخش Errors همین اطلاعات را نشان می‌دهد.

فایل htaccess؛ شایع‌ترین عامل خطای ۵۰۰ در هاست لینوکس

یکی از پرتکرارترین دلایل HTTP Error 500 Internal Server Error دستکاری فایل .htaccess است. یک دستور اشتباه، یک ماژول غیرفعال یا حتی یک خط اضافه که از یک آموزش اینترنتی کپی شده کافی است تا آپاچی کل سایت را با خطای ۵۰۰ بالا بیاورد.

برای اینکه مطمئن شوید ایراد از همین فایل است، آن را حذف نکنید؛ فقط نامش را عوض کنید. این‌طور اگر تنظیمات مهمی مثل ریدایرکت‌ها، قوانین امنیتی یا ریدایرکت اجباری HTTPS داخلش بوده، از دست نمی‌رود. مراحل کار در cPanel:

• وارد cPanel شوید و روی File Manager کلیک کنید.
• وارد پوشه‌ی public_html شوید؛ محتوای سایت اصلی همین‌جاست.
• فایل .htaccess مخفی است. در نسخه‌های امروزی cPanel از دکمه‌ی Settings در بالای صفحه گزینه‌ی Show Hidden Files (dotfiles) را تیک بزنید و Save کنید. در نسخه‌های قدیمی، همین گزینه در پنجره‌ی Directory Selection هنگام باز شدن File Manager نمایش داده می‌شد.
• روی .htaccess راست‌کلیک کنید و با Rename نام آن را به چیزی مثل htaccess_old تغییر دهید.
• سایت را دوباره بارگذاری کنید.

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

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

یک نکته‌ی مهم برای فایل‌های .htaccess قدیمی: دستورهای کنترل دسترسی آپاچی ۲٫۲ در آپاچی ۲٫۴ منسوخ شده‌اند و اگر ماژول mod_access_compat فعال نباشد، همان دستورها خودشان باعث خطای ۵۰۰ می‌شوند. اگر فایل شما از سرور قدیمی منتقل شده، این بخش را به شکل امروزی بازنویسی کنید:

# سبک آپاچی 2.2 (منسوخ)
Order allow,deny
Allow from all

# معادل آن در آپاچی 2.4
Require all granted


# مسدود کردن یک IP در آپاچی 2.2 (منسوخ)
Order allow,deny
Allow from all
Deny from 203.0.113.10

# معادل آن در آپاچی 2.4
<RequireAll>
Require all granted
Require not ip 203.0.113.10
</RequireAll>

پیش از اعمال قانون مسدودسازی IP، مطمئن شوید IP خودتان در فهرست نیست؛ یک اشتباه در همین چند خط می‌تواند دسترسی خودتان به سایت را ببندد.

حواستان به وب‌سرور هم باشد: LiteSpeed انترپرایز فایل .htaccess را مثل آپاچی می‌خواند، اما Nginx اصلاً این فایل را نمی‌خواند. اگر روی Nginx هستید و انتظار دارید قوانین .htaccess کار کند، باید معادل آن‌ها را در بلوک server بنویسید و سرویس را ریلود کنید.

مجوز فایل‌ها و مالکیت آن‌ها

مجوز اشتباه هم مستقیم به ۵۰۰ ختم می‌شود؛ مخصوصاً روی سرورهایی که PHP با suPHP یا suEXEC اجرا می‌شود و فایل یا پوشه‌ی با دسترسی ۷۷۷ را اصلاً اجرا نمی‌کنند. مقدار استاندارد، ۷۵۵ برای پوشه‌ها و ۶۴۴ برای فایل‌هاست:

# به‌جای user نام کاربری واقعی اکانت را بگذارید و مسیر را پیش از اجرا دوباره بخوانید
find /home/user/public_html -type d -exec chmod 755 {} ;
find /home/user/public_html -type f -exec chmod 644 {} ;

این دو دستور مجوز همه‌ی فایل‌ها و پوشه‌های زیر آن مسیر را یک‌دست می‌کنند؛ پس اگر اسکریپت CGI یا فایل اجرایی خاصی دارید که به ۷۵۵ نیاز دارد، بعد از اجرا مجوز آن را دستی برگردانید. هرگز این دستورها را روی / یا /home اجرا نکنید. اگر فایلی را با کاربر root آپلود یا استخراج کرده‌اید، مالکیت را هم به کاربر همان اکانت برگردانید، وگرنه وب‌سرور اجازه‌ی خواندن نخواهد داشت.

خطای PHP پشت ارور ۵۰۰

اگر .htaccess و مجوزها سالم بودند، نوبت خود کد است. یک Fatal Error در PHP معمولاً در مرورگر به شکل صفحه‌ی سفید یا خطای ۵۰۰ دیده می‌شود. در وردپرس برای دیدن متن واقعی خطا، این سه خط را در wp-config.php بالای خط /* That's all, stop editing! */ قرار دهید:

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

با این تنظیم، خطاها به‌جای نمایش روی صفحه در فایل wp-content/debug.log ثبت می‌شوند. توصیه می‌کنیم روی سایت زنده هرگز display_errors را روشن نکنید؛ خروجی آن مسیر فایل‌ها و ساختار دیتابیس را به بازدیدکننده لو می‌دهد. شکل درست آن روی سرور این است:

log_errors = On
error_log = /home/user/php_errors.log
display_errors = Off

پس از رفع مشکل، حتماً WP_DEBUG را دوباره روی false برگردانید و فایل debug.log را پاک کنید؛ این فایل اگر در مسیر عمومی بماند، از بیرون قابل خواندن است.

سایر کارهایی که در وردپرس جواب می‌دهد:

• اگر ورود به پیشخوان ممکن نیست، از طریق File Manager وارد مسیر wp-content شوید و پوشه‌ی plugins را به نام دیگری (مثلاً plugins_old) تغییر دهید تا همه‌ی افزونه‌ها یک‌جا غیرفعال شوند. سپس سایت را رفرش کنید. اگر مشکل حل شد، نام پوشه را برگردانید و افزونه‌ها را یکی‌یکی فعال کنید تا مقصر پیدا شود.
• قالب فعال را موقتاً به یکی از قالب‌های پیش‌فرض وردپرس تغییر دهید.
• اگر خطا دقیقاً بعد از تغییر نسخه‌ی PHP شروع شده، احتمالاً کد قدیمی با PHP 8 سازگار نیست. توابعی مثل each() و create_function() در PHP 8 حذف شده‌اند، توابع خانواده‌ی mysql_* از PHP 7 حذف شده‌اند و دسترسی به کاراکترهای رشته با آکولاد ($str{0}) هم دیگر پشتیبانی نمی‌شود. تا زمان به‌روزرسانی کد یا افزونه، بازگرداندن سایت به نسخه‌ی قبلی PHP راه‌حل موقت است.

۵۰۱ – Not Implemented

این خطا زمانی ظاهر می‌شود که وب‌سرور متد درخواستی (مثلاً PUT یا DELETE) را پشتیبانی نکند یا نتواند آن را اجرا کند.

روش رفع:

• مطمئن شوید وب‌سرور و ماژول‌های آن از متدهای HTTP مورد استفاده‌ی برنامه پشتیبانی می‌کنند؛ این مورد در APIها و سرویس‌های REST بیشتر دیده می‌شود.
• تنظیمات فایروال، ModSecurity یا پراکسی میانی را بررسی کنید، چون ممکن است برخی متدها را مسدود کرده باشند. اگر قاعده‌ای از ModSecurity را غیرفعال می‌کنید، فقط همان شناسه‌ی قاعده را غیرفعال کنید؛ خاموش کردن کامل ModSecurity روی سایت زنده یک لایه‌ی امنیتی را برمی‌دارد.

۵۰۲ – Bad Gateway

وقتی رخ می‌دهد که یک سرور در مسیر پاسخ‌دهی نقش Gateway یا Proxy دارد اما پاسخ معتبری از سرور پشتی نمی‌گیرد. در معماری Nginx + PHP-FPM، پشت CDN‌هایی مثل Cloudflare و در هاست‌های اشتراکی این خطا رایج است.

روش رفع:

• سلامت سرویس پشتی را بررسی کنید. اغلب اوقات PHP-FPM از کار افتاده و Nginx فقط پیام‌رسان است.
• لاگ PHP-FPM را بخوانید؛ پیام server reached pm.max_children setting یعنی تعداد پردازش‌های مجاز کم است و باید در فایل pool تنظیمات را بالا ببرید. این عدد را پله‌پله و متناسب با RAM آزاد سرور بالا ببرید؛ اگر یک‌باره چند برابرش کنید، سرور به‌جای ۵۰۲ با کمبود حافظه و کشته شدن پردازش‌ها توسط OOM Killer روبه‌رو می‌شود.
• در تنظیمات Nginx مقدار proxy_pass یا fastcgi_pass را بررسی کنید؛ اگر مسیر سوکت PHP-FPM بعد از ارتقای نسخه‌ی PHP عوض شده باشد، همین خطا رخ می‌دهد.
• در Cloudflare حالت پراکسی (ابر نارنجی) را موقتاً خاموش کنید تا مشخص شود منبع خطا سرور خودتان است یا لایه‌ی CDN. توجه کنید که با این کار IP واقعی سرور آشکار می‌شود و سایت از پشت سپر Cloudflare بیرون می‌آید؛ بلافاصله بعد از تست دوباره روشنش کنید.

systemctl status nginx
systemctl status php8.2-fpm
journalctl -u php8.2-fpm -n 50

ریست سرویس‌ها برای رفع وضعیت‌های موقتی (هر ریست چند ثانیه قطعی دارد، پس روی سایت پرترافیک زمانش را انتخاب کنید):

systemctl restart nginx

# PHP-FPM؛ نام سرویس بسته به توزیع و نسخه فرق می‌کند
systemctl restart php-fpm          # AlmaLinux / Rocky / CentOS
systemctl restart php8.2-fpm       # Ubuntu / Debian
systemctl restart ea-php82-php-fpm # سرورهای cPanel با EasyApache 4

# LiteSpeed
systemctl restart lsws
# یا
/usr/local/lsws/bin/lswsctrl restart

اگر نام دقیق سرویس را نمی‌دانید، با systemctl list-units --type=service | grep -i fpm آن را پیدا کنید. اگر هنوز روی نسخه‌های قدیمی PHP مثل php7.4-fpm هستید، بدانید که پشتیبانی امنیتی آن‌ها تمام شده و ماندن روی آن‌ها خودش ریسک است؛ ارتقا به شاخه‌ی ۸ را در برنامه بگذارید.

۵۰۳ – Service Unavailable

یعنی سرویس موقتاً در دسترس نیست. معمولاً وقتی رخ می‌دهد که منابع سرور (CPU، RAM یا I/O) بیش از حد مصرف شده باشند یا سرویس وب در حال ریست یا به‌روزرسانی باشد.

روش رفع:

• مصرف منابع را ببینید. دقت کنید که دستورهای لینوکس به بزرگی و کوچکی حروف حساس‌اند و باید top با حروف کوچک نوشته شود.

top
# یا نمای خواناتر
htop

• اگر پیام «Briefly unavailable for scheduled maintenance» می‌بینید، وردپرس وسط یک به‌روزرسانی ناتمام گیر کرده است. کافی است فایل مخفی .maintenance را از ریشه‌ی سایت پاک کنید تا سایت برگردد.
• محدودیت‌های PHP مانند max_execution_time و memory_limit را بالا ببرید. روش تغییر این مقادیر در راهنمای upload_max_filesize آمده است.
• در آپاچی، سقف تعداد درخواست‌های هم‌زمان را بررسی کنید. توجه داشته باشید که دستور MaxClients مربوط به آپاچی ۲٫۲ است و در آپاچی ۲٫۴ نام آن به MaxRequestWorkers تغییر کرده است.
• سرویس وب‌سرور را در صورت هنگ کردن پردازش‌ها ریست کنید.

# Apache روی AlmaLinux / Rocky / CentOS و سرورهای cPanel
systemctl restart httpd

# Apache روی Ubuntu / Debian
systemctl restart apache2

# LiteSpeed
systemctl restart lsws

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

دستور قدیمی service apache2 restart هنوز روی بیشتر توزیع‌ها کار می‌کند، اما فقط یک لایه‌ی سازگاری روی systemd است؛ شکل درست امروزی همان systemctl است. همین حکم برای /etc/init.d/httpd restart هم صادق است. در سرورهای WHM یا cPanel که از LiteSpeed استفاده می‌کنند، علاوه بر دکمه‌ی Restart LiteSpeed در WHM، می‌توان از طریق SSH این دستور را هم اجرا کرد:

/usr/local/lsws/bin/lswsctrl restart

۵۰۴ – Gateway Timeout

این خطا زمانی رخ می‌دهد که سرور میانی (مثلاً Nginx یا یک پراکسی) منتظر پاسخ سرور پشتی می‌ماند اما در زمان تعیین‌شده جوابی نمی‌گیرد. برخلاف ۵۰۲ که یعنی «پاسخ خراب بود»، اینجا اصلاً پاسخی نرسیده است.

روش رفع:

• مقدار proxy_read_timeout و fastcgi_read_timeout را در تنظیمات Nginx افزایش دهید. این کار زمان می‌خرد اما ریشه‌ی مشکل را حل نمی‌کند. بعد از ویرایش، اول با nginx -t کانفیگ را تست و بعد با systemctl reload nginx اعمال کنید؛ reload برخلاف restart قطعی ایجاد نمی‌کند.
• مقدار max_execution_time در PHP را با این تایم‌اوت‌ها هماهنگ کنید؛ اگر PHP زودتر قطع شود، پیام خطا فرق می‌کند.
• ارتباط بین سرور پراکسی و سرور پشتی را با Ping و Traceroute بررسی کنید.
• ریشه را پیدا کنید: کوئری‌های سنگین دیتابیس، کرون‌جاب‌های طولانی، فراخوانی API خارجی که جواب نمی‌دهد و ایمپورت‌های حجیم رایج‌ترین دلایل هستند. فعال کردن Slow Query Log در MySQL یا MariaDB سریع‌ترین راه پیدا کردن کوئری کند است.

۵۰۵ – HTTP Version Not Supported

سرور از نسخه‌ی درخواستی پروتکل HTTP پشتیبانی نمی‌کند.

روش رفع:

• از سازگاری وب‌سرور با HTTP/1.1 و HTTP/2 مطمئن شوید.
• تنظیمات Reverse Proxy را بررسی کنید؛ ناهماهنگی نسخه‌ی پروتکل بین لایه‌ی جلویی و سرور پشتی عامل رایج این خطاست.

۵۰۶ – Variant Also Negotiates

در این حالت سرور در فرآیند «مذاکره‌ی محتوا» (Content Negotiation) دچار چرخه‌ی بی‌پایان می‌شود؛ یعنی به‌جای ارائه‌ی نسخه‌ی مناسب محتوا، خودش را به‌عنوان یکی از گزینه‌ها معرفی می‌کند.

روش رفع:

• تنظیمات mod_negotiation در آپاچی را اصلاح کنید.
• اگر MultiViews در .htaccess یا کانفیگ سایت فعال است، آن را غیرفعال کنید: Options -MultiViews

۵۰۷ – Insufficient Storage

یعنی سرور فضای کافی برای ذخیره یا پردازش درخواست ندارد. در سرورهای مجازی با دیسک محدود بیشتر دیده می‌شود.

روش رفع:

# فضای دیسک
df -h

# تعداد inodeها؛ گاهی دیسک خالی است اما inode تمام شده
df -i

# پیدا کردن سنگین‌ترین پوشه‌ها
du -sh /var/* | sort -h

• لاگ‌های قدیمی و فایل‌های موقت را پاک کنید و logrotate را تنظیم کنید تا این وضعیت تکرار نشود. برای لاگی که یک سرویس در حال حاضر باز نگه داشته، به‌جای rm از truncate -s 0 /path/to/file.log استفاده کنید؛ پاک کردن چنین فایلی فضا را آزاد نمی‌کند.
• پیش از حذف هر چیزی مطمئن شوید آن فایل واقعاً لاگ یا موقت است؛ حذف نادرست در /var می‌تواند سرویسی را از کار بیندازد.
• بکاپ‌های محلی و فایل‌های .tar.gz باقی‌مانده از انتقال سایت، رایج‌ترین دلیل پر شدن ناگهانی دیسک هستند.
• در صورت نیاز، پلن هاست یا دیسک سرور را ارتقا دهید.

۵۰۸ – Loop Detected

سیستم در حین پردازش درخواست دچار حلقه‌ی بی‌نهایت شده است. این خطا بیشتر در محیط‌هایی که از WebDAV یا سیستم‌های مدیریت محتوا استفاده می‌کنند دیده می‌شود.

روش رفع:

• ریدایرکت‌های متوالی و لینک‌های داخلی را بررسی کنید. (دقت کنید حلقه‌ی ریدایرکت معمولاً با پیام ERR_TOO_MANY_REDIRECTS در مرورگر ظاهر می‌شود نه با کد ۵۰۸، اما محل عیب‌یابی هر دو یکی است: قوانین ریدایرکت در .htaccess و تنظیمات SSL.)
• در وردپرس، افزونه‌های کش یا Redirect را غیرفعال کنید و .htaccess را به حالت پیش‌فرض برگردانید.
• روی هاست‌های اشتراکی مبتنی بر CloudLinux، همین کد با پیام Resource Limit Is Reached نمایش داده می‌شود و معنایش کاملاً متفاوت است: اکانت شما به سقف منابع (CPU، RAM یا Entry Process) رسیده. در این حالت باید مصرف را در بخش Resource Usage در cPanel ببینید و سایت را بهینه یا پلن را ارتقا دهید.

۵۰۹ – Bandwidth Limit Exceeded

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

۵۱۰ – Not Extended

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

روش رفع:

• افزونه‌ها یا ماژول‌هایی را که درخواست‌های سفارشی HTTP می‌فرستند بررسی کنید.
• وب‌سرور یا فریم‌ورک را به‌روزرسانی کنید تا از Extensionهای مورد نیاز پشتیبانی کند.

۵۱۱ – Network Authentication Required

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

روش رفع:

• تنظیمات پراکسی و احراز هویت شبکه را بررسی کنید.
• اگر Gateway در اختیار خودتان است، محدودیت احراز هویت را در همان سطح بازبینی کنید.

دلایل عمومی بروز ارورهای ۵xx

هرچند هر خطا مفهوم خاص خود را دارد، اما این علت‌ها در بیشتر آن‌ها مشترک‌اند:

• فشار بیش از حد بر منابع سرور (CPU، RAM یا دیسک).
• تنظیمات اشتباه در فایل‌های پیکربندی وب‌سرور یا PHP.
• تداخل افزونه‌ها و ماژول‌ها در CMSهایی مانند وردپرس یا جوملا.
• محدودیت‌های اعمال‌شده در سطح هاست اشتراکی؛ راه‌حل پایدار آن معمولاً انتخاب پلن هاست با منابع بیشتر است.
• خرابی در ارتباط با دیتابیس یا Timeout در اجرای کوئری‌ها.
• سخت‌گیری بیش از حد فایروال یا ModSecurity که باعث مسدود شدن درخواست‌های معتبر می‌شود.

عیب‌یابی بر اساس نوع هاست و سرور

هاست لینوکس (cPanel / LiteSpeed / Apache)

• فایل‌های خطا را از بخش Errors در cPanel ببینید.
• فایل error_log در مسیر public_html را بررسی کنید.
• منابع PHP را از مسیر Select PHP Version > Options افزایش دهید.
• در LiteSpeed، از گزینه‌ی Restart LiteSpeed در WHM برای ریست سرویس استفاده کنید.

هاست و سرور ویندوز (Plesk / IIS)

• جزئیات خطا را از مسیر Logs > HTTP Error Logs در Plesk ببینید.
• از فعال بودن FastCGI برای PHP مطمئن شوید.
• IIS را با دستور iisreset در PowerShell با دسترسی Administrator ریست کنید. توجه کنید iisreset همه‌ی سایت‌های آن سرور را برای چند ثانیه پایین می‌آورد؛ اگر فقط یک سایت مشکل دارد، به‌جای آن Application Pool همان سایت را Recycle کنید.
• Application Pool مربوط به سایت و مقدار Memory Limit آن را بررسی کنید؛ اگر Application Pool متوقف شده باشد، همه‌ی درخواست‌ها با خطای ۵۰۳ برمی‌گردند.

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

<configuration>
  <system.webServer>
    <httpErrors errorMode="Detailed" />
  </system.webServer>
</configuration>

روی بسیاری از هاست‌های اشتراکی ویندوز، بخش httpErrors در سطح سرور قفل است و افزودن این چند خط به‌جای نمایش خطا، پیام 500.19 – Internal Server Error می‌دهد. در آن حالت این تنظیم را بردارید و جزئیات خطا را از پشتیبانی یا از بخش Logs در Plesk بخواهید. خروجی Detailed مسیر فایل‌ها را نشان می‌دهد، پس آن را روی سایت زنده رها نکنید.

خطای ASP 0177 و دسترسی به FileSystemObject در اسکریپت‌های ASP

اگر سایتتان با ASP کلاسیک نوشته شده و جایی از کد با FileSystemObject فایل می‌خواند یا می‌نویسد، ممکن است به‌جای صفحه‌ی سایت این پیام را ببینید (در سطح HTTP همان پاسخ ۵۰۰ برگردانده می‌شود):

Server object error 'ASP 0177 : 800401f3'

Server.CreateObject Failed

/aspfilename.asp, line n

800401f3

کد 800401f3 در ویندوز یعنی Invalid class string؛ به بیان ساده، IIS نتوانسته کلاسی را که خواسته‌اید پیدا کند. سه علت رایج دارد:

• غلط املایی در نام کلاس. شکل درست دقیقاً به این صورت است:

Set fso = Server.CreateObject("Scripting.FileSystemObject")

• ثبت‌نشده یا غیرفعال بودن کامپوننت scrrun.dll روی سرور.
• محدود بودن دسترسی FSO روی هاست اشتراکی. چون FileSystemObject امکان کار با فایل‌سیستم را می‌دهد، روی بسیاری از هاست‌های اشتراکی ویندوز به‌صورت پیش‌فرض برای همه‌ی اکانت‌ها باز نیست.

اگر سرور مجازی یا اختصاصی ویندوز در اختیار خودتان است: مطمئن شوید نقش ASP در Role Services مربوط به IIS نصب شده، هویت Application Pool روی پوشه‌ی مورد نظر دسترسی Modify دارد و در صورت نیاز کامپوننت را دوباره ثبت کنید. دستور را در Command Prompt یا PowerShell با دسترسی Administrator اجرا کنید:

regsvr32 %windir%system32scrrun.dll

# روی ویندوز 64 بیتی، اگر Application Pool در حالت 32 بیتی اجرا می‌شود
regsvr32 %windir%SysWOW64scrrun.dll

و اگر روی هاست اشتراکی ویندوز آنلاین سرور هستید، نام سایت و آدرس فایل ASP خود را با یک درخواست پشتیبانی (تیکت) برای ما بفرستید تا دسترسی لازم برای استفاده از FSO روی همان مسیر برایتان فعال شود.

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

سرور مجازی و اختصاصی

روی سرور خودتان، دسترسی کامل به لاگ سیستم دارید؛ از همان‌جا شروع کنید:

journalctl -xe

# لاگ یک سرویس مشخص
journalctl -u nginx -n 50

# Ubuntu / Debian
tail -f /var/log/syslog

# AlmaLinux / Rocky / CentOS
tail -f /var/log/messages

• وضعیت سرویس‌ها را بررسی کنید: systemctl status nginx، systemctl status httpd یا systemctl status apache2 بسته به توزیع و وب‌سرورتان.
• منابع را با ابزارهایی مانند htop، glances یا PRTG مانیتور کنید.
• در صورت نیاز، منابع را از کنترل‌پنل مجازی‌ساز افزایش دهید یا Swap تنظیم کنید تا کشته شدن پردازش‌ها توسط OOM Killer متوقف شود.

نکات پیشگیرانه برای جلوگیری از بروز خطاهای ۵xx

• استفاده از ابزارهای مانیتورینگ منابع مانند Zabbix و تنظیم هشدار برای مصرف CPU، RAM و فضای دیسک.
• راه‌اندازی یک مانیتورینگ ساده‌ی در دسترس بودن سایت تا قبل از کاربران، خودتان از قطعی باخبر شوید.
• به‌روزرسانی مداوم CMS، افزونه‌ها و نسخه‌ی PHP؛ اما تغییر نسخه‌ی PHP را اول روی یک نسخه‌ی آزمایشی از سایت امتحان کنید.
• بررسی دوره‌ای لاگ‌ها، تنظیم logrotate و پاک‌سازی فایل‌های غیرضروری.
• گرفتن بکاپ قبل از هر تغییر در .htaccess، web.config یا کانفیگ وب‌سرور.
• استفاده از CDN و کش برای کاهش فشار مستقیم روی سرور.

جمع‌بندی

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

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