قطع شدن ناگهانی دسترسی به VPS یکی از مشکلاتی است که ممکن است برای هر سروری اتفاق بیفتد. گاهی سرور کاملاً خاموش نشده و فقط سرویس SSH پاسخ نمی‌دهد؛ گاهی نیز مصرف بیش از حد CPU، پر شدن دیسک یا مشکل شبکه باعث می‌شود VPS عملاً غیرقابل دسترس شود.

ssh root@IP-SERVER

ssh username@IP-SERVER

ssh -i /path/to/private-key username@IP-SERVER

نکات مهم قبل از اجرای دستورات

• دستورات این مقاله اکثراً نیاز به دسترسی root یا کاربر دارای sudo دارند. اگر با کاربر عادی وارد شده‌اید، قبل از دستورات systemctl، journalctl، ufw و مشابه آن‌ها sudo را فراموش نکنید.

• قبل از هر تغییر مهم در Firewall یا تنظیمات شبکه، حتماً کنسول تحت وب Provider را در دسترس داشته باشید تا در صورت قطع شدن SSH، دسترسی خود را از دست ندهید.

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

• اگر SSH پاسخ نمی‌دهد، از کنسول مدیریتی Provider (VNC/Console) استفاده کنید. این کنسول حتی زمانی که SSH، Firewall یا شبکه مشکل دارند، امکان دسترسی مستقیم به سیستم را فراهم می‌کند.

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

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

یکی از رایج‌ترین دلایل هنگ کردن سرور، تمام شدن حافظه RAM است.

وقتی حافظه و Swap کافی نباشد، لینوکس ممکن است به OOM Killer متوسل شود و بعضی پردازش‌ها را متوقف کند. در شرایط شدید، حتی SSH نیز ممکن است دیگر پاسخ ندهد.

برای بررسی وضعیت RAM:

free -h

برای پیدا کردن پردازش‌هایی که بیشترین حافظه را مصرف می‌کنند:

ps aux --sort=-%mem | head

همچنین می‌توانید لاگ‌های مربوط به OOM را بررسی کنید:

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

راهکار

اگر یک برنامه خاص باعث مصرف شدید RAM شده است، ابتدا همان سرویس را بررسی کنید. در صورت نیاز نیز می‌توان RAM یا Swap بیشتری در نظر گرفت.

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

اجرای یک اسکریپت معیوب، پردازش سنگین، ربات، حمله یا حتی یک برنامه معمولی با مصرف غیرعادی می‌تواند CPU را کاملاً اشغال کند.

برای بررسی:

top

یا:

htop

همچنین می‌توانید پردازش‌های پرمصرف را با این دستور ببینید:

ps aux --sort=-%cpu | head

اگر یک پردازش خاص دائماً CPU را مصرف می‌کند، باید علت اجرای آن را پیدا کنید.

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

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

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

بررسی فضای دیسک:

df -h

برای بررسی inodeها:

df -i

اگر /var حجم زیادی گرفته است:

du -xhd1 /var | sort -h

راهکار

لاگ‌های قدیمی، بکاپ‌های غیرضروری و فایل‌های موقت را بررسی کنید. البته قبل از حذف فایل‌ها، مطمئن شوید که به آن‌ها نیاز ندارید.

۴. مصرف بیش از حد I/O دیسک

گاهی CPU و RAM مشکلی ندارند، اما دیسک به‌شدت مشغول است.

در چنین شرایطی VPS ممکن است بسیار کند شود و حتی SSH با تأخیر زیاد پاسخ دهد. اشباع I/O می‌تواند باعث غیرقابل‌دسترس شدن سرویس‌ها شود.

برای بررسی:

iostat -xz 1

اگر iowait بالا باشد، باید سرویس‌هایی مانند دیتابیس، Docker، بکاپ‌گیری یا برنامه‌های دارای عملیات خواندن و نوشتن زیاد را بررسی کنید.

۵. مشکل Firewall

گاهی خود سرور کاملاً سالم است، اما یک قانون اشتباه در Firewall باعث قطع دسترسی می‌شود.

برای مثال ممکن است پورت SSH مسدود شده باشد.

در Ubuntu می‌توانید وضعیت UFW را بررسی کنید:

sudo ufw status

اگر از nftables استفاده می‌کنید:

sudo nft list ruleset

تغییر اشتباه قوانین Firewall می‌تواند اتصال SSH را بلافاصله قطع کند؛ بنابراین بهتر است قبل از تغییرات مهم، کنسول تحت وب VPS را در دسترس داشته باشید.

۶. از کار افتادن سرویس SSH

ممکن است VPS روشن و سالم باشد، اما سرویس SSH متوقف شده باشد.

وضعیت SSH را بررسی کنید:

sudo systemctl status ssh

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

sudo systemctl status sshd

لاگ‌ها را نیز بررسی کنید:

sudo journalctl -u ssh --since "30 minutes ago"

۷. تغییر اشتباه تنظیمات شبکه

ویرایش اشتباه تنظیمات Netplan یا NetworkManager می‌تواند باعث قطع شبکه VPS شود.

ابتدا وضعیت IP را بررسی کنید:

ip addr

سپس مسیرهای شبکه:

ip route

و برای بررسی اتصال اینترنت:

ping 1.1.1.1

اگر IP روی سرور وجود دارد اما مسیر شبکه درست نیست، مشکل می‌تواند از تنظیمات شبکه باشد.

۸. مشکل DNS

گاهی اینترنت سرور برقرار است، اما DNS کار نمی‌کند.

برای آزمایش:

ping 1.1.1.1

سپس:

ping google.com

اگر اولی جواب می‌دهد اما دومی نه، باید تنظیمات DNS را بررسی کنید.

۹. حمله یا ترافیک غیرعادی

افزایش ناگهانی ترافیک می‌تواند منابع VPS را مصرف کند.

برای مثال:

• حمله DDoS
• Brute Force روی SSH
• درخواست‌های زیاد به وب‌سایت
• ربات‌های مخرب
• حمله به API

می‌توانند CPU، RAM، شبکه یا کانکشن‌های سرور را تحت فشار قرار دهند.

بررسی اتصال‌ها:

ss -tunap

و بررسی لاگ سرویس‌های وب مانند Nginx یا Apache می‌تواند اطلاعات بیشتری ارائه دهد.

۱۰. اجرای یک برنامه یا اسکریپت معیوب

گاهی مشکل از خود سیستم‌عامل نیست.

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

برای بررسی پردازش‌ها:

ps aux

و برای مشاهده مصرف منابع:

top

اگر مشکل دقیقاً بعد از اجرای یک برنامه شروع شده، تغییرات اخیر را بررسی کنید.

۱۱. مشکل Docker یا Containerها

اگر روی VPS از Docker استفاده می‌کنید، یک Container می‌تواند مقدار زیادی CPU، RAM یا I/O مصرف کند.

لیست Containerها:

docker ps

مصرف منابع:

docker stats

اگر یک Container به‌صورت غیرعادی منابع مصرف می‌کند، لاگ و تنظیمات همان سرویس را بررسی کنید.

۱۲. مشکل دیتابیس MySQL یا PostgreSQL

دیتابیس‌ها می‌توانند منابع زیادی مصرف کنند؛ مخصوصاً زمانی که Queryهای سنگین یا تعداد زیادی اتصال هم‌زمان وجود داشته باشد.

اگر MySQL دارید:

sudo systemctl status mysql

برای مشاهده پردازش‌ها:

mysqladmin processlist

همچنین لاگ‌های دیتابیس را بررسی کنید.

۱۳. پر شدن لاگ‌ها

سرویس‌هایی مانند systemd-journald می‌توانند حجم زیادی لاگ تولید کنند.

برای مشاهده حجم Journal:

journalctl --disk-usage

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

۱۴. مشکل در سمت دیتاسنتر یا Provider

همیشه مشکل از داخل VPS نیست.

گاهی ممکن است مشکل مربوط به:

• شبکه دیتاسنتر
• Host Node
• Storage
• Maintenance
• اختلال شبکه
• منابع بیش از حد Host
• مشکل Virtualization

باشد.

اگر از طریق کنسول مدیریتی Provider هم VPS پاسخ نمی‌دهد، وضعیت سرور و اطلاعیه‌های Provider را بررسی کنید.

۱۵. ری‌استارت یا Crash شدن VPS

ممکن است سرور واقعاً Restart شده باشد.

برای بررسی زمان آخرین بوت:

uptime

یا:

who -b

برای بررسی Bootهای قبلی:

last reboot

همچنین لاگ‌های Kernel را بررسی کنید:

journalctl -k

این لاگ‌ها می‌توانند سرنخ‌هایی درباره Memory Pressure، خطاهای دیسک و مشکلات شبکه ارائه کنند.

روش عیب‌یابی VPS در چند دقیقه

اگر VPS از دسترس خارج شد، به‌جای اینکه بلافاصله آن را Reboot کنید، این مراحل را انجام دهید.

مرحله اول: بررسی وضعیت VPS

در پنل Provider ببینید VPS روشن است یا خاموش.

اگر گزینه Console دارید، وارد آن شوید. کنسول تحت وب می‌تواند حتی زمانی که SSH یا Firewall مشکل دارد، امکان دسترسی مستقیم به سیستم را فراهم کند.

مرحله دوم: بررسی منابع

free -h

df -h

top

مرحله سوم: بررسی سرویس‌ها

systemctl --failed

سپس سرویس مهمی که مشکل دارد را بررسی کنید:

systemctl status nginx

یا:

systemctl status apache2

مرحله چهارم: بررسی لاگ‌ها

journalctl -p err -b

برای بررسی خطاهای Kernel:

journalctl -k -p err

مرحله پنجم: بررسی شبکه

ip addr

ip route

ping 1.1.1.1

و در نهایت:

ss -tulpn

این روش کمک می‌کند مشخص کنید مشکل از خود سیستم، منابع، سرویس، شبکه یا Provider است.

قبل از Reboot این کارها را انجام دهید

یکی از اشتباهات رایج این است که کاربر به محض قطع شدن VPS، آن را Restart می‌کند.

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

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

free -h
df -h
uptime
systemctl --failed
journalctl -p err -b

اگر VPS کاملاً قفل شده و هیچ راهی برای دسترسی وجود ندارد، آن‌وقت استفاده از Console، Rescue Mode یا Restart می‌تواند گزینه بعدی باشد.

جمع‌بندی

از دسترس خارج شدن VPS لزوماً به معنی خراب شدن سرور نیست. در بسیاری از موارد، مشکل به مصرف بیش از حد RAM یا CPU، پر شدن دیسک، I/O بالا، Firewall، SSH، تنظیمات شبکه یا یک سرویس معیوب مربوط می‌شود.

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