چرا VPS هر چند ساعت یک‌بار قطع می‌شود؟ راهنمای کامل عیب‌یابی و رفع مشکل

یکی از مشکلات آزاردهنده در مدیریت VPS این است که سرور هر چند ساعت یک‌بار از دسترس خارج می‌شود، اما بعد از انجام Reboot دوباره به حالت عادی برمی‌گردد. در این شرایط ممکن است VPS در پنل ارائه‌دهنده همچنان روشن و فعال نمایش داده شود، اما سایت، API، SSH یا سایر سرویس‌ها پاسخ ندهند. گاهی نیز سرور به‌طور کامل فریز می‌شود و تنها راه برگشتن آن به وضعیت عادی، ریبوت کردن VPS است.

در این مقاله، مهم‌ترین دلایل قطع شدن دوره‌ای VPS و روش پیدا کردن عامل اصلی مشکل را بررسی می‌کنیم.

این مشکل معمولاً چه شکلی دارد؟

مشکل قطع شدن دوره‌ای VPS می‌تواند به شکل‌های مختلف ظاهر شود:

• اتصال SSH قطع می‌شود.
• سایت باز نمی‌شود.
• Ping پاسخ نمی‌دهد.
• پنل VPS سرور را روشن نشان می‌دهد.
• CPU ناگهان به 100 درصد می‌رسد.
• RAM کاملاً مصرف می‌شود.
• دیسک پر می‌شود.
• سرویس‌هایی مانند Apache، Nginx یا MySQL از کار می‌افتند.
• سرور کاملاً فریز می‌شود.
• بعد از Reboot همه‌چیز برای چند ساعت یا چند روز عادی می‌شود.

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

مهم‌ترین دلایل قطع شدن دوره‌ای VPS

۱. مصرف بیش از حد RAM

یکی از رایج‌ترین دلایل فریز شدن VPS، تمام شدن حافظه RAM است. فرض کنید VPS شما 2GB RAM دارد و هم‌زمان سرویس‌های زیر روی آن اجرا می‌شوند: Apache یا Nginx، MySQL/MariaDB، PHP، Docker، Redis و چند برنامه دیگر. اگر مصرف حافظه به سقف برسد، سیستم‌عامل ممکن است برای آزاد کردن RAM، بعضی Processها را متوقف کند. در لینوکس این وضعیت می‌تواند باعث فعال شدن OOM Killer شود.

برای مشاهده وضعیت RAM:

free -h

اگر RAM دائماً نزدیک به سقف مصرف می‌شود، باید Processهای پرمصرف را پیدا کنید:

top
# یا
htop

اگر htop نصب نیست: apt install htop

۲. بررسی OOM Killer

اگر احتمال می‌دهید RAM تمام شده، لاگ‌های سیستم را بررسی کنید:

dmesg -T | grep -i "out of memory"
dmesg -T | grep -i "killed process"
journalctl -k | grep -Ei "out of memory|oom|killed process"

اگر مواردی مانند Out of memory، Killed process یا oom-killer مشاهده کردید، احتمال دارد سیستم به دلیل کمبود حافظه Processهایی را متوقف کرده باشد.

۳. پر شدن فضای دیسک

یکی دیگر از دلایل بسیار مهم، پر شدن دیسک است. اگر پارتیشن اصلی VPS کاملاً پر شود، سرویس‌های مختلف ممکن است دچار مشکل شوند. برای بررسی:

df -h

استفاده ۹۹ درصدی از دیسک یک هشدار جدی است. برای پیدا کردن پوشه‌های حجیم:

du -sh /*
du -sh /var/*
du -sh /var/log/*

گاهی فایل‌های Log به دلیل خطای یک سرویس، در مدت کوتاهی چندین گیگابایت حجم پیدا می‌کنند.

۴. پر شدن Inodeها

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

df -i

اگر مقدار IUse% نزدیک ۱۰۰ درصد باشد، مشکل می‌تواند مربوط به Inodeها باشد. این مشکل معمولاً در سرورهایی که تعداد بسیار زیادی فایل کوچک تولید می‌کنند بیشتر دیده می‌شود.

۵. مصرف ۱۰۰ درصدی CPU

CPU بالا نیز می‌تواند باعث کندی شدید یا حتی از دسترس خارج شدن سرویس‌ها شود. برای مشاهده مصرف CPU:

top

اگر یک Process برای مدت طولانی CPU زیادی مصرف کند، باید علت آن را پیدا کنید. ممکن است دلیل یکی از موارد زیر باشد:

• اجرای Query سنگین MySQL
• اسکریپت PHP معیوب
• Cron Job
• پردازش Docker
• حمله یا ترافیک غیرعادی
• برنامه‌ای که وارد Loop شده است
• استخراج غیرمجاز منابع سیستم

۶. اجرای Cron Job در فواصل مشخص

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

crontab -l

Cronهای سیستم نیز ممکن است در این مسیرها قرار داشته باشند:

/etc/crontab
/etc/cron.hourly/
/etc/cron.daily/
/etc/cron.weekly/
/etc/cron.monthly/

اگر مثلاً یک Backup سنگین، اسکریپت پردازش فایل یا Query بزرگ در ساعت مشخصی اجرا شود، ممکن است منابع VPS را مصرف کند.

۷. مشکل در MySQL یا MariaDB

در VPSهایی که سایت PHP و دیتابیس روی یک سرور قرار دارند، MySQL می‌تواند یکی از عوامل مصرف بالای منابع باشد. برای مشاهده وضعیت:

systemctl status mysql
journalctl -u mysql
tail -f /var/log/mysql/error.log

اگر تعداد Connectionها زیاد باشد یا Queryهای سنگین اجرا شوند، مصرف CPU و RAM افزایش پیدا می‌کند. در چنین شرایطی باید Queryهای سنگین، Connectionها و تنظیمات MySQL بررسی شوند.

۸. مشکل Apache یا Nginx

گاهی خود VPS خاموش نشده است، اما وب‌سرور از کار افتاده است. ابتدا وضعیت Apache را بررسی کنید:

systemctl status apache2
systemctl status nginx
journalctl -u apache2
journalctl -u nginx

اگر فقط سایت قطع شده اما SSH همچنان کار می‌کند، احتمال دارد مشکل مربوط به وب‌سرور یا Application باشد و نه خود VPS.

۹. مشکل سرویس SSH

ممکن است VPS کاملاً سالم باشد اما سرویس SSH پاسخ ندهد. بررسی:

systemctl status ssh
systemctl status sshd
journalctl -u ssh

اگر SSH از کار افتاده ولی سایت همچنان باز می‌شود، نباید بلافاصله نتیجه بگیرید که VPS قطع شده است.

۱۰. مشکل شبکه

گاهی CPU، RAM و Disk کاملاً عادی هستند اما VPS از طریق شبکه قابل دسترسی نیست. از سیستم خودتان می‌توانید وضعیت Ping را بررسی کنید:

ping SERVER_IP
# در ویندوز:
Test-NetConnection SERVER_IP -Port 22

اگر Ping فعال است ولی SSH باز نمی‌شود، ممکن است مشکل مربوط به پورت SSH، Firewall، سرویس SSH، Fail2Ban، محدودیت اتصال یا تنظیمات شبکه باشد.

۱۱. Firewall یا Fail2Ban

تنظیمات اشتباه Firewall می‌تواند باعث قطع دسترسی شود. اگر از UFW استفاده می‌کنید:

ufw status
ufw status numbered
systemctl status fail2ban
fail2ban-client status

گاهی یک IP به دلیل تلاش‌های متعدد برای ورود، Ban می‌شود.

۱۲. مصرف شدید Disk I/O

گاهی فضای دیسک کافی است و CPU نیز مشکل خاصی ندارد، اما Disk I/O بسیار زیاد است. این اتفاق می‌تواند باعث شود سیستم به‌شدت کند شود و سرویس‌ها پاسخ ندهند. برای بررسی:

iostat
iostat -xz 1
iotop

اگر %util دیسک دائماً بسیار بالا باشد، باید Processهای ایجادکننده I/O را پیدا کنید.

۱۳. مشکل Kernel یا سیستم‌عامل

گاهی مشکل از Application نیست و Kernel یا یکی از اجزای سیستم‌عامل دچار خطا می‌شود. لاگ Kernel را بررسی کنید:

journalctl -k
journalctl -p err -b
journalctl -b -1 -p err

دستور آخر بسیار مهم است. اگر VPS بعد از Reboot بالا آمده، می‌توانید لاگ Boot قبلی را بررسی کنید و ببینید قبل از ریبوت چه اتفاقی افتاده است.

۱۴. پیدا کردن زمان دقیق قطع شدن VPS

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

journalctl --since "2026-09-19 16:00:00" --until "2026-09-19 16:20:00"

این روش بسیار بهتر از بررسی تصادفی Logها است.

۱۵. بررسی اینکه VPS واقعاً Reboot شده یا فقط سرویس‌ها از کار افتاده‌اند

یکی از مهم‌ترین نکات این است که مشخص کنید سرور واقعاً خاموش یا Reboot شده است یا فقط سرویس خاصی از کار افتاده است. برای مشاهده زمان آخرین Boot:

uptime
who -b
last reboot

اگر در زمان مشکل Boot جدیدی ثبت نشده باشد، احتمالاً VPS واقعاً Reboot نشده و فقط یکی از سرویس‌ها، شبکه یا سیستم دچار مشکل شده است.

۱۶. بررسی لاگ‌های Boot قبلی

این قسمت برای عیب‌یابی بسیار مهم است. ابتدا Bootها را مشاهده کنید:

journalctl --list-boots
journalctl -b -1
journalctl -b -1 -p err

اگر قبل از Reboot مشکل فریز شدن، OOM، Kernel Error یا Crash رخ داده باشد، ممکن است آثار آن در همین Logها باقی مانده باشد.

۱۷. بررسی مصرف منابع در طول زمان

یکی از مشکلات ابزارهایی مانند top این است که وضعیت همین لحظه را نشان می‌دهند. اگر VPS هر ۸ ساعت یک‌بار مشکل پیدا می‌کند، ممکن است زمانی که شما top را اجرا می‌کنید، همه‌چیز کاملاً عادی باشد. برای چنین شرایطی بهتر است از ابزارهای مانیتورینگ استفاده کنید. یکی از ابزارهای رایج sysstat است:

apt install sysstat
sar -u   # CPU
sar -r   # RAM
sar -q   # Load
sar -d   # I/O

این اطلاعات کمک می‌کنند بفهمید چند ساعت قبل مصرف منابع چه وضعیتی داشته است.

۱۸. Load Average را بررسی کنید

گاهی CPU صددرصد نیست، اما Load Average بسیار بالا است. دستور:

uptime
nproc

مقدار مناسب Load به تعداد هسته‌های CPU نیز بستگی دارد. برای مثال در یک VPS تک‌هسته‌ای، Load بسیار بالا می‌تواند نشانه فشار شدید باشد؛ اما در VPS چند هسته‌ای باید Load را در مقایسه با تعداد CPUها بررسی کرد.

۱۹. بررسی Processهای مشکوک

اگر VPS ناگهان کند می‌شود، Processهای فعال را بررسی کنید:

ps aux --sort=-%cpu | head
ps aux --sort=-%mem | head

اگر Process ناشناخته‌ای مشاهده کردید، قبل از Kill کردن آن باید ابتدا مشخص کنید متعلق به چه نرم‌افزاری است.

۲۰. بررسی حملات و Loginهای ناموفق

اگر VPS عمومی و دارای IP اینترنتی است، ممکن است دائماً تلاش‌هایی برای ورود به SSH انجام شود. برای مشاهده Loginهای ناموفق:

grep "Failed password" /var/log/auth.log
journalctl -u ssh | grep -i "failed"

تعداد زیادی تلاش ناموفق لزوماً به معنی هک شدن سرور نیست، اما می‌تواند باعث ایجاد فشار روی سرویس SSH شود و باید مدیریت شود.

اگر فقط با Reboot مشکل حل می‌شود، چه چیزی را بررسی کنیم؟

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

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

systemctl --failed

اگر خروجی شامل سرویس‌هایی مانند apache2.service، mysql.service یا docker.service باشد، باید همان سرویس‌ها را جداگانه بررسی کنید.

چرا Reboot موقتاً مشکل را حل می‌کند؟

Reboot بسیاری از وضعیت‌های موقت سیستم را پاک می‌کند. برای مثال:

• RAM آزاد می‌شود.
• Processهای خراب بسته می‌شوند.
• Connectionهای قدیمی از بین می‌روند.
• سرویس‌ها دوباره Start می‌شوند.
• Cacheها و وضعیت‌های موقت پاک می‌شوند.
• بعضی مشکلات Network دوباره Initialize می‌شوند.
• Processهای مصرف‌کننده CPU متوقف می‌شوند.

به همین دلیل ممکن است بعد از Reboot VPS برای چند ساعت کاملاً سالم باشد. اما اگر علت اصلی همچنان وجود داشته باشد، مشکل دوباره تکرار می‌شود.

چطور بفهمیم مشکل از RAM است یا CPU؟

این جدول تشخیص قطعی نیست؛ بلکه نقطه شروع عیب‌یابی است.

آیا ممکن است مشکل از خود VPS یا Host باشد؟

بله. اگر موارد زیر را بررسی کردید و هیچ مشکل واضحی در داخل سیستم‌عامل پیدا نشد:

• RAM
• CPU
• Disk
• Network
• Firewall
• SSH
• Kernel
• Application
• MySQL
• Apache/Nginx

اما VPS همچنان به‌صورت دوره‌ای فریز می‌شود، باید موضوع را با ارائه‌دهنده VPS مطرح کنید. به‌خصوص اگر چند VPS یا سرویس دیگر روی همان زیرساخت مشکلی ندارند اما این VPS مرتباً از دسترس خارج می‌شود، ارائه‌دهنده می‌تواند وضعیت Host Node، منابع اختصاص‌یافته، Virtualization و رویدادهای زیرساختی را بررسی کند.

در این حالت بهتر است هنگام ارسال تیکت، اطلاعات دقیق‌تری ارائه کنید:

این اطلاعات روند بررسی را بسیار سریع‌تر می‌کند.

برای جلوگیری از تکرار مشکل چه کار کنیم؟

۱. Monitoring نصب کنید

برای VPSهای مهم بهتر است فقط به بررسی دستی اکتفا نکنید. مصرف CPU، RAM، Swap، Disk، Disk I/O، Network، Load Average و وضعیت سرویس‌ها را مانیتور کنید.

۲. برای RAM کافی برنامه‌ریزی کنید

اگر دائماً RAM به سقف نزدیک می‌شود، افزایش RAM یا بهینه‌سازی سرویس‌ها می‌تواند ضروری باشد. همچنین در VPSهای کوچک وجود Swap می‌تواند در بعضی شرایط از Crashهای ناشی از فشار حافظه جلوگیری کند؛ البته Swap جای RAM واقعی را نمی‌گیرد.

۳. Logها را مدیریت کنید

لاگ‌های بدون Rotation می‌توانند فضای دیسک را به‌سرعت پر کنند. مطمئن شوید logrotate به‌درستی کار می‌کند.

۴. Cron Jobهای سنگین را بررسی کنید

اگر مشکل همیشه در یک ساعت مشخص اتفاق می‌افتد، Cron Jobها را بررسی کنید. به‌خصوص: Backup، Database Dump، اسکن فایل‌ها، پردازش ویدئو، فشرده‌سازی، اسکریپت‌های PHP و عملیات Docker.

۵. سرویس‌های غیرضروری را حذف کنید

هر سرویس اضافی می‌تواند RAM و CPU مصرف کند. لیست سرویس‌ها را بررسی کنید:

systemctl list-units --type=service

یک چک‌لیست سریع برای VPSهایی که هر چند ساعت قطع می‌شوند

اگر VPS شما مرتباً از دسترس خارج می‌شود، این دستورات را اجرا کنید:

uptime
free -h
df -h
df -i
nproc
systemctl --failed
journalctl -p err
journalctl -b -1 -p err
ps aux --sort=-%cpu | head
ps aux --sort=-%mem | head

این مجموعه بررسی اولیه خوبی برای پیدا کردن علت مشکل است.

جمع‌بندی

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

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

• مصرف بیش از حد RAM
• فعال شدن OOM Killer
• مصرف ۱۰۰ درصد CPU
• پر شدن Disk
• تمام شدن Inode
• مصرف شدید Disk I/O
• مشکل MySQL یا MariaDB
• Crash شدن Apache یا Nginx
• مشکل SSH
• Firewall یا Fail2Ban
• Cron Jobهای سنگین
• خطاهای Kernel
• مشکلات شبکه
• Processهای غیرعادی
• مشکلات احتمالی زیرساخت VPS

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

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

برای VPSهای مهم نیز بهتر است از Monitoring استفاده کنید تا قبل از رسیدن RAM، CPU، Disk یا سایر منابع به وضعیت بحرانی، هشدار دریافت کنید.