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

این دستور رو بزن:

ss -tulpn

خیلی خلاصه بهت می‌گه چه پورت‌هایی دارن گوش می‌دن، TCP هستن یا UDP و کدوم Process پشتشونه.

مثلاً اگر کنار پورت 22 اسم sshd دیدی، یعنی SSH اونجاست. پورت‌های 80 و 443 هم معمولاً می‌رسن به Nginx یا Apache.

یه قانون ساده: هر پورت ناشناسی رو فوری نبند 😅 اول ببین مال کدوم سرویسه؛ وگرنه ممکنه خودت سرویس سالمت رو از دسترس خارج کنی.

🔗 کانال وان سرور

#یک_دقیقه_سرور #VPS

امشب یه سؤال پرتکرار رو جمع کنیم: وقتی VPS کُنده، واقعاً خود سرور مقصره یا مسیر اینترنت؟ 😄

اول یه Ping ساده بگیر:

ping -c 10 1.1.1.1

اگر زمان پاسخ بالاست ولی Packet Loss نداری، بیشتر با تأخیر مسیر طرفیم. اگر Loss می‌بینی، یعنی بعضی بسته‌ها اصلاً به مقصد نمی‌رسن و این می‌تونه باعث لگ، قطع‌ووصلی SSH یا کندی محسوس بشه.

برای اینکه ببینی مشکل تقریباً کجای مسیره، اینم خیلی به‌درد می‌خوره:

mtr -rw 1.1.1.1

در MTR مسیر رو Hop به Hop نشون می‌ده. فقط یه نکته: Loss روی یک Hop به‌تنهایی دلیل خرابی همون نقطه نیست؛ بعضی روترها جواب ICMP رو محدود می‌کنن. مهم اینه ببینی Loss یا افزایش تأخیر تا مقصد هم ادامه پیدا می‌کنه یا نه.

پس قبل از اینکه با عصبانیت VPS رو ریبوت کنی 😅 اول Ping و MTR رو ببین؛ شاید سرور بی‌گناهه!

🔗 کانال وان سرور

#یک_دقیقه_سرور #VPS

امشب بریم سراغ اون دوتا خطایی که معمولاً آدم رو می‌فرستن مستقیم سمت ری‌استارت سرور 😅 خطای 502 و 504.

خیلی ساده:

در 502 Bad Gateway یعنی وب‌سرور مثل Nginx از سرویس پشتش جواب درست نگرفته. مثلاً PHP-FPM خوابیده، اپلیکیشن Crash کرده یا آدرس/پورت upstream اشتباهه.

در 504 Gateway Timeout یعنی ارتباط برقرار شده، ولی سرویس پشت وب‌سرور اون‌قدر دیر جواب داده که Timeout خورده.

قبل از ری‌استارت کورکورانه، یه چک سریع بزن:

systemctl status nginx
systemctl status php8.3-fpm
tail -n 50 /var/log/nginx/error.log

اگر Nginx سالمه، برو سراغ upstream؛ یعنی PHP-FPM، Node.js، Gunicorn یا هر سرویسی که سایتت پشتش اجرا می‌شه.

یه میان‌بُر ذهنی هم داشته باش: 502 بیشتر می‌گه «جواب درست نگرفتم»، 504 بیشتر می‌گه «جواب دیر رسید». همین فرق کوچیک، نصف مسیر عیب‌یابی رو برات روشن می‌کنه 👌

🔗 کانال وان سرور

#یک_دقیقه_سرور #VPS

🔐 SSH سرورت واقعاً امنه؟

خیلی از VPSها هنوز با ورود مستقیم root و رمز عبور مدیریت می‌شن؛ درحالی‌که همین تنظیمات می‌تونه یکی از اصلی‌ترین نقاط ورود برای حملات Brute Force باشه.

توی آموزش جدید آکادمی وان‌سرور، امن‌سازی SSH رو مرحله‌به‌مرحله انجام دادیم؛ از ساخت SSH Key و بستن ورود Root گرفته تا UFW، Fail2Ban، محدودسازی کاربران و بررسی لاگ‌های مشکوک.

یه نکته مهم هم بررسی کردیم: تغییر پورت SSH به‌تنهایی امنیت ایجاد نمی‌کنه و فقط بخشی از اسکن‌های رباتی رو کم می‌کنه.

اگر VPS لینوکسی دارید، این چک‌لیست رو حتماً یک‌بار روی سرورتون اجرا کنید. 👇

#آکادمی_وان_سرور #SSH #VPS #امنیت_سرور #لینوکس

امشب یه درد آشنای ادمین‌ها رو حل کنیم: SSH قطع می‌شه و همون لحظه پروسه‌ای که نیم ساعت منتظرش بودی هم می‌پره 😅

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

یه مثال سریع:

tmux new -s deploy

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

Ctrl+B  سپس  D

بعداً که دوباره وصل شدی:

tmux attach -t deploy

برای دیدن سشن‌های فعال هم:

tmux ls

این ترفند برای deploy، بکاپ، کامپایل، انتقال فایل یا هر کاری که نمی‌خوای با یک قطع SSH نابود بشه خیلی نجات‌دهنده‌ست. فقط یادت باشه tmux جای سرویس‌مدیری مثل systemd نیست؛ برای پردازش‌های دائمی هنوز باید سرویس درست داشته باشی.

🔗 کانال وان سرور

#یک_دقیقه_سرور #VPS

امشب بریم سراغ یه ابزار خیلی به‌دردبخور برای جابه‌جایی و بکاپ فایل بین سرورها: rsync؛ هم سریع‌تر از کپی کورکورانه‌ست، هم فقط تغییرات رو منتقل می‌کنه. 😄

ولی قبل از اینکه یه مسیر اشتباه بزنی و بعد با نگاه خیره به ترمینال بگی «من چی کار کردم؟»، اول --dry-run رو اجرا کن:

rsync -avh --dry-run /var/www/ user@SERVER:/backup/www/

این دستور فقط نشون می‌ده چه فایل‌هایی قرار است منتقل شوند و چیزی را واقعاً کپی نمی‌کند. اگر خروجی درست بود، --dry-run را بردار:

rsync -avh /var/www/ user@SERVER:/backup/www/

یه نکته ریز ولی مهم: اسلش آخر مسیر فرق دارد. /var/www/ یعنی محتویات پوشه را منتقل کن؛ ولی /var/www می‌تواند خود پوشه www را هم داخل مقصد بسازد.

برای بکاپ‌های واقعی، مخصوصاً وقتی پای --delete وسطه، اول dry-run، بعد اجرا؛ این یکی از اون عادت‌هاییه که یه روز واقعاً نجاتت می‌ده. 😉

🔗 کانال وان سرور

#یک_دقیقه_سرور #VPS

گاهی سایت از بیرون کاملاً سالمه، ولی داخل VPS هر چی می‌زنی اسم دامنه resolve نمی‌شه. قبل از اینکه DNS دامنه رو زیر و رو کنی، اول مشخص کن مشکل از خود دامنه‌ست یا resolver سرور. 😄

اول پاسخ DNS رو مستقیم از یک resolver مشخص بگیر:

dig @1.1.1.1 example.com

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

dig example.com

اگر دستور اول جواب درست می‌ده ولی دومی timeout یا خطای عجیب می‌ده، احتمال زیاد رکوردهای دامنه سالم‌اند و باید resolver خود VPS رو بررسی کنی. روی سیستم‌هایی که systemd-resolved دارند این دستور خیلی سریع وضعیت رو نشون می‌ده:

resolvectl status

به DNS Server فعال، اینترفیس شبکه و DefaultRoute دقت کن. برای یک تست تکمیلی هم می‌تونی بزنی:

resolvectl query example.com

اما اگر حتی dig @1.1.1.1 هم رکورد مورد انتظار رو برنمی‌گردونه، دیگه فقط گردن VPS ننداز 😅؛ رکورد DNS، nameserverها یا انتشار تغییرات دامنه رو بررسی کن.

خلاصه مسیر عیب‌یابی: اول resolver عمومی، بعد resolver خود VPS. همین مقایسه ساده خیلی وقت‌ها چند دقیقه حدس‌زدن رو حذف می‌کنه.

🔗 کانال وان سرور

#یک_دقیقه_سرور #VPS

گاهی سایت باز نمی‌شه و اولین مظنون هم طبق معمول Nginx یا اپلیکیشنه؛ ولی قبل از اینکه نصف سرویس‌ها رو restart کنی، با دو دستور ساده می‌تونی بفهمی داستان از کجاست. 😄

اول فقط هدرهای پاسخ رو ببین:

curl -I https://example.com

اینجا سریع status code و redirectها رو می‌بینی. مثلاً 200 یعنی پاسخ رسیده، 301/302 مسیر redirect رو نشون می‌ده و 502 معمولاً سرنخ خوبی برای بررسی upstream یا اپلیکیشن پشت وب‌سروره.

اگر هنوز معلوم نیست مشکل کجاست، حالت verbose رو اجرا کن:

curl -v https://example.com

این خروجی جزئیات اتصال، DNS resolve، برقراری TCP، مذاکره TLS و هدرهای درخواست و پاسخ رو نشون می‌ده. پس می‌تونی تشخیص بدی درخواست اصلاً به سرور می‌رسه، روی SSL گیر می‌کنه یا وب‌سرور جواب نامناسب می‌ده.

یه تست کاربردی دیگه وقتی پشت Nginx یا Reverse Proxy هستی اینه که upstream محلی رو مستقیم صدا بزنی:

curl -I http://127.0.0.1:8000

اگر این یکی 200 می‌ده ولی دامنه 502 برمی‌گردونه، مسیر عیب‌یابی خیلی کوتاه‌تر می‌شه؛ تنظیمات proxy و اتصال وب‌سرور به upstream رو بررسی کن، نه اینکه بی‌هدف همه‌چی رو خاموش روشن کنی. 😅

🔗 کانال وان سرور

#یک_دقیقه_سرور #VPS

گاهی یک فایل لاگ چند گیگی رو پاک می‌کنی، ls هم دیگه نشونش نمی‌ده، ولی df -h می‌گه فضای دیسک هنوز پره. اینجا معمولاً فایل واقعاً از دید فایل‌سیستم حذف شده، اما یک پردازش هنوز file descriptor اون رو باز نگه داشته. 😄

برای پیدا کردنش اول این دستور رو بزن:

sudo lsof +L1

یا اگر دنبال موارد حذف‌شده می‌گردی:

sudo lsof | grep '(deleted)'

به ستون‌های COMMAND، PID و SIZE/OFF دقت کن. مثلاً اگر یک لاگ حذف‌شده چند گیگی هنوز دست nginx یا یک سرویس اپلیکیشن باز مونده، تا وقتی اون پردازش descriptor رو نبنده فضا آزاد نمی‌شه.

نکته مهم: صرفاً چون PID رو پیدا کردی، مستقیم kill -9 نزن. اول مشخص کن پردازش مربوط به کدوم سرویسه و اگر امکانش هست با روش امن خودش reload یا restart کن؛ مخصوصاً روی سرور Production که یک kill عجولانه می‌تونه دردسر بزرگ‌تری از کمبود فضا بسازه.

بعد از بستن descriptor دوباره df -h رو چک کن. خیلی وقت‌ها همون چند گیگ گمشده همون لحظه برمی‌گرده.

🔗 کانال وان سرور

#یک_دقیقه_سرور #VPS

گاهی سرور ظاهراً اینترنت داره، پینگ هم جواب می‌ده، ولی یک سایت نصفه باز می‌شه، دانلود وسط کار می‌ایسته یا اتصال از داخل VPN/Tunnel رفتار عجیب پیدا می‌کنه. یکی از متهم‌های همیشگی این سناریو MTU و Fragmentation ـه. 😄

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

ping -M do -s 1472 1.1.1.1

روی Ethernet با MTU استاندارد 1500، عدد 1472 به‌اضافه 28 بایت هدر IP و ICMP می‌شه 1500. اگر پیام‌هایی مثل message too long یا Frag needed دیدی، اندازه رو کم‌کم پایین بیار تا بزرگ‌ترین مقداری که سالم رد می‌شه پیدا کنی.

مثلاً اگر 1472 رد نشد ولی 1400 بدون مشکل جواب داد، احتمالاً جایی در مسیر MTU کوچک‌تری داری؛ چیزی که روی GRE، VPN و بعضی مسیرهای تونلی خیلی بیشتر خودش رو نشان می‌ده.

نکته: پایین آوردن کورکورانه MTU راه‌حل عیب‌یابی نیست. اول مسیر و مقدار واقعی رو پیدا کن؛ بعد سراغ تنظیم MTU یا در سناریوهای TCP، MSS Clamping برو.

🔗 کانال وان سرور

#شبکه #VPS

گاهی پورت بازه، فایروال هم چیزی رو نبسته، ولی سرویس جواب درست نمی‌ده؛ اینجا بهتره به‌جای ری‌استارت‌های شانسی، از بیرون به داخل جلو بری.

اول ببین واقعاً چه پردازشی روی پورت گوش می‌ده:

sudo ss -lntp | grep ':443'

اگر Listener وجود داشت، خود سرویس رو از همان سرور تست کن:

curl -v http://127.0.0.1:8080/

اگر curl محلی جواب داد ولی از بیرون نه، احتمال مشکل بیشتر سمت Firewall، NAT، Reverse Proxy یا مسیر شبکه است. اگر همان تست محلی هم خطا داد، برو سراغ لاگ سرویس:

sudo journalctl -u nginx -n 50 --no-pager

مسیر سریع عیب‌یابی:
در ss می‌گه «کسی روی پورت گوش می‌ده؟»
در curl می‌گه «سرویس واقعاً جواب می‌ده؟»
در journalctl می‌گه «اگر جواب نمی‌ده، خودش چه خطایی ثبت کرده؟»

این سه مرحله معمولاً خیلی سریع‌تر از یک systemctl restart بی‌هدف، متهم اصلی رو پیدا می‌کنه.

🔗 کانال وان سرور

#لینوکس #VPS

گاهی دیسک VPS بی‌سروصدا پر می‌شه و وقتی سراغ فایل‌های معمولی می‌ری چیز عجیبی پیدا نمی‌کنی؛ یکی از جاهایی که ارزش بررسی داره لاگ‌های systemd journal ـه.

اول ببین journal واقعاً چقدر فضا گرفته:

journalctl --disk-usage

اگر حجمش غیرعادی بود، به‌جای پاک‌کردن دستی فایل‌های /var/log/journal می‌تونی خود journal رو کنترل‌شده جمع‌وجور کنی. مثلاً نگه داشتن حداکثر ۷ روز اخیر:

journalctl --vacuum-time=7d

یا محدود کردن حجم آرشیوها به حدود 500 مگابایت:

journalctl --vacuum-size=500M

نکته: قبل از vacuum کردن، اگر سرور مشکل یا سرویس ناپایداری داره اول لاگ موردنیازت رو بررسی یا ذخیره کن؛ چون لاگی که حذف شد برای عیب‌یابی بعدی برنمی‌گرده. 😄

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

🔗 کانال وان سرور

#لینوکس #VPS

خیلی وقت‌ها Fail2ban نصب شده و همه خیال‌شون راحته؛ ولی چند ماه بعد می‌بینی سرویس بالا بوده و عملاً هیچ IPای را Ban نمی‌کرده.

برای یک چک سریع اول وضعیت Jail مربوط به SSH رو ببین:

fail2ban-client status sshd

بعد حتماً Backend فایروال رو هم بررسی کن؛ روی سیستم‌های جدید ممکنه انتظار iptables داشته باشی ولی سرور با nftables کار کنه. برای دیدن Ruleهای فعال:

nft list ruleset | grep -i f2b

نکته مهم اینه که «Active بودن سرویس» با «واقعاً Block شدن مهاجم» یکی نیست. بعد از هر تغییر فایروال یا مهاجرت سیستم‌عامل، مسیر Ban رو دوباره تست کن.

🔗 کانال وان سرور

#امنیت #VPS

گاهی بعد از ریبوت VPS می‌بینی سرور بالا آمده، ولی یکی از سرویس‌ها با تأخیر آماده می‌شود و کل استک چند ده ثانیه منتظر می‌ماند. به‌جای حدس‌زدن، زنجیره بوت systemd را ببین.

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

systemd-analyze blame
systemd-analyze critical-chain

نکته اینجاست که blame فقط زمان هر واحد را نشان می‌دهد؛ اما critical-chain وابستگی‌هایی را پیدا می‌کند که واقعاً مسیر بوت را عقب انداخته‌اند. پس صرفاً طولانی‌ترین عدد را مقصر اعلام نکن؛ اول زنجیره وابستگی را ببین، بعد سراغ همان سرویس برو.

🔗 کانال وان سرور

#Linux #VPS

گاهی VPS ظاهراً بدون دلیل یک سرویس رو می‌کُشه؛ نه CPU پره، نه دیسک مشکل داره، ولی پروسه ناگهان ناپدید می‌شه. یکی از مظنون‌های اصلی OOM Killer لینوکسه؛ وقتی RAM و Swap جواب نمی‌دن، کرنل برای زنده نگه داشتن سیستم یک پروسه رو قربانی می‌کنه. 😅

برای چک سریع، این لاگ‌ها رو ببین:

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

بعد مصرف حافظه رو با این دو دستور بررسی کن:

free -h
ps aux --sort=-%mem | head

نکته مهم اینه که صرفاً RAM رو بیشتر نکنی؛ اول ببین کدوم سرویس نشت حافظه داره، Swap اصلاً فعاله یا نه و محدودیت Memory سرویس/کانتینر درست تنظیم شده یا نه.

🔗 کانال وان سرور

#VPS #Linux

فرض کن ساعت دو شب مانیتورینگ هشدار می‌ده و یک VPS ناگهان کند شده؛ هنوز نمی‌دونی مشکل از CPU، RAM، دیسک یا شبکه است. اولین دستوری که می‌زنی کدومه؟ 👇

گزینه خودت رو انتخاب کن و بعد با این چک سریع مقایسه کن:

uptime
free -h
vmstat 1 5
df -h

نکته اینجاست که از روی یک عدد نباید حکم بدی؛ Load بالا می‌تونه از CPU باشه، ولی I/O wait یا فشار حافظه هم می‌تونه همون ظاهر رو بسازه. برای Incident واقعی، اول وضعیت کلی رو بگیر و بعد برو سراغ ابزار تخصصی‌تر.

🔗 کانال وان سرور

#Linux #VPS

گاهی VPS کُند می‌شه ولی CPU در ظاهر بیکار است؛ اینجا قبل از متهم کردن پردازنده، I/O Wait رو چک کن. وقتی دیسک دیر جواب می‌ده، پردازش‌ها منتظر I/O می‌مونن و سرور حس سنگینی می‌ده، حتی اگر مصرف CPU پایین باشه.

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

vmstat 1 5
iostat -xz 1 5

توی vmstat ستون wa رو ببین؛ اگر بالا می‌مونه، سراغ دیسک برو. بعد در iostat به await و %util نگاه کن تا مشخص بشه تأخیر واقعاً از Storage میاد یا نه.

نکته مهم اینه که یک عدد لحظه‌ای ملاک نیست؛ چند نمونه پشت‌سرهم بگیر و هم‌زمان ببین کدوم پروسه بیشترین I/O رو ایجاد می‌کنه.

🔗 کانال وان سرور

#VPS #Linux

گاهی سرویس روی VPS بالا و CPU هم عادیه، ولی اتصال‌ها مکث می‌کنن یا سرعت نوسانی می‌شه. قبل از دست‌کاری اپلیکیشن، بد نیست TCP Retransmission رو بررسی کنی؛ چون Packet Loss، مسیر بد یا مشکل MTU می‌تونه باعث ارسال مجدد بسته‌ها بشه.

برای یک بررسی سریع این دو دستور مفیدن:

ss -ti
nstat -az | grep -E 'TcpRetransSegs|TcpExtTCPLostRetransmit'

اگر Retransmit در زمان اختلال سریع بالا می‌ره، بعدش مسیر رو با mtr و MTU رو بررسی کن. نکته مهم اینه که Retransmission خودش علت نهایی نیست؛ یک نشونه‌ست که کمک می‌کنه مشکل شبکه رو از CPU، RAM یا خود سرویس جدا کنی.

🔗 کانال وان سرور

#VPS #Linux

گاهی Load Average بالاست ولی از روی CPU، RAM یا دیسک به‌تنهایی نمی‌فهمی سیستم دقیقاً کجا گیر کرده؛ اینجا Linux PSI می‌تونه سرنخ خیلی خوبی بده. PSI میزان زمانی رو نشان می‌دهد که پردازش‌ها به‌خاطر کمبود CPU، Memory یا I/O منتظر مانده‌اند.

برای یک بررسی سریع این سه فایل رو ببین:

cat /proc/pressure/cpu
cat /proc/pressure/memory
cat /proc/pressure/io

اگر مقدار avg10 در یکی از بخش‌ها بالا می‌رود، یعنی در ۱۰ ثانیه اخیر فشار واقعی همان منبع بیشتر شده. نکته مهم اینه که PSI جای بررسی top یا iostat رو نمی‌گیره؛ کمک می‌کنه قبل از عیب‌یابی عمیق بفهمی باید دنبال CPU، حافظه یا دیسک بگردی.

🔗 کانال وان سرور

#VPS #Linux