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

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

ss -tulpn

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

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

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

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

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

آینده امنیت SSH زودتر از چیزی که فکر می‌کنیم رسیده.

در OpenSSH جدید، تبادل کلید هیبریدی پساکوانتومی وارد مسیر اصلی شده و از نسخه 10.0 الگوریتم mlkem768x25519-sha256 به انتخاب پیش‌فرض تبدیل شده؛ اما پشتیبانی به این معنی نیست که هر اتصال واقعاً از آن استفاده می‌کند.

در راهنمای جدید آکادمی وان‌سرور بررسی کردیم چطور نسخه OpenSSH و الگوریتم‌های KEX را ببینیم، با اتصال verbose الگوریتم مذاکره‌شده واقعی را چک کنیم و بدون ریسک قطع دسترسی، برای امنیت SSH در ۲۰۲۶ آماده شویم.

نکته مهم این است که رمزنگاری پساکوانتومی جای اصول پایه مثل کلید SSH، محدودکردن root، فایروال و به‌روزرسانی امنیتی را نمی‌گیرد.

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

#آکادمی_وان_سرور

امشب یه سؤال پرتکرار رو جمع کنیم: وقتی 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

اگه برای باز کردن یه سرویس روی VPS، اولین راه‌حل‌ت اینه که یه پورت جدید باز کنی، بد نیست یک گزینه تمیزتر رو هم ببینی. Cloudflare Tunnel اجازه می‌ده سرویس داخلی سرور با یک اتصال خروجی امن به Cloudflare وصل بشه؛ یعنی لازم نیست پورت برنامه رو برای کل اینترنت باز بذاری یا IP مبدا رو مستقیم در معرض دید قرار بدی.

توی مقاله جدید، نصب cloudflared، ساخت Tunnel، اتصال دامنه، بستن پورت‌های غیرضروری و نکات امنیتی مهم رو مرحله‌به‌مرحله توضیح دادیم. برای پنل‌های حساس هم حتماً Cloudflare Access و MFA رو جدی بگیر.

#آکادمی_وان_سرور

امشب بریم سراغ اون دوتا خطایی که معمولاً آدم رو می‌فرستن مستقیم سمت ری‌استارت سرور 😅 خطای 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

اگه سایتت پشت NGINX اجرا می‌شه، نسخه 1.30 یه قابلیت جالب داره که می‌تونه بخشی از زمان انتظار مرورگر رو به دانلود زودتر منابع مهم تبدیل کنه. 103 Early Hints قبل از آماده‌شدن پاسخ نهایی، به مرورگر می‌گه فایل‌هایی مثل CSS یا فونت حیاتی رو زودتر شروع کنه.

این قابلیت بیشتر برای سایت‌های پویا مثل WordPress و Laravel ارزش داره؛ مخصوصاً وقتی TTFB بالاست. البته قرار نیست معجزه کنه: باید درست پیکربندی بشه، روی staging تست بشه و نتیجه با LCP و waterfall قبل و بعد مقایسه بشه.

توی مقاله جدید، نحوه کار Early Hints، تنظیم NGINX، نکات تست و اشتباهات رایج رو مرحله‌به‌مرحله توضیح دادیم.

#آکادمی_وان_سرور

وقتی یه سرویس لینوکس بالا نمیاد، اولین کار ری‌استارت پشت ری‌استارت نیست 😄

اول یه نگاه به وضعیت خود سرویس بنداز تا ببینی با چه خطایی متوقف شده:

systemctl status nginx --no-pager -l

بعد برو سراغ لاگ‌های همون سرویس؛ معمولاً سرنخ اصلی همین‌جاست:

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

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

journalctl -u nginx -b -p warning..alert --no-pager

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

journalctl -xeu nginx

فقط اسم nginx رو با سرویس خودت مثل mysql، php-fpm یا هر سرویس دیگه عوض کن.

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

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

اگر روی VPS لینوکسی سرویس وب، کانتینر، کاربر محلی یا هر فرایندی دارید که ممکن است کد غیرقابل‌اعتماد اجرا کند، CVE-2026-43499 را جدی بگیرید. آسیب‌پذیری GhostLock می‌تواند در سناریوهای مشخص به مهاجم اجازه دهد محدودیت‌های دسترسی را دور بزند و سطح دسترسی بالاتری بگیرد.

کار درست این است که قبل از هر چیز نسخه و وضعیت امنیتی سیستم را بررسی کنید، بسته‌های امنیتی را از مخازن رسمی به‌روز نگه دارید و دسترسی کاربران و سرویس‌های غیرضروری را محدود کنید. اگر سرور تولیدی دارید، به‌روزرسانی را با برنامه و بعد از بکاپ انجام دهید؛ امنیت با «بعداً آپدیت می‌کنم» معمولاً دوست خوبی نیست.

#آکادمی_وان_سرور

آدرس IP روی VPS فقط یه عدد برای وصل‌شدن به سرور نیست؛ انتخاب بین IPv4 و IPv6 روی دسترسی، سازگاری و حتی بعضی سناریوهای شبکه اثر می‌ذاره.

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

در مقابل، IPv6 فضای آدرس خیلی بزرگ‌تری می‌ده و برای سرویس‌هایی که کلاینت و شبکه مقصد ازش پشتیبانی می‌کنن می‌تونه اتصال مستقیم‌تر و آینده‌نگرانه‌تری داشته باشه؛ ولی جای IPv4 رو در همه سناریوها نگرفته.

برای اینکه ببینی VPS تو چه آدرس‌هایی داره، این دوتا دستور سریع به کارت میاد:

ip -4 addr
ip -6 addr

اگر سرویس عمومی مهم داری، معمولاً Dual Stack یعنی داشتن هم‌زمان IPv4 و IPv6 انتخاب مطمئن‌تریه؛ اینطوری کاربرانی که فقط یکی از این دو مسیر رو دارن هم به سرویس دسترسی پیدا می‌کنن.

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

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

هشدار امنیتی مهم برای مدیرهای cPanel و WHM ⚠️

آسیب‌پذیری CVE-2026-65643 در قابلیت‌های Domain Parking و Addon Domain می‌تواند به یک کاربر احراز هویت‌شده که اجازه افزودن دامنه دارد امکان ایجاد فایل دلخواه روی سرور بدهد؛ طبق هشدار رسمی cPanel، بهره‌برداری موفق حتی می‌تواند به اجرای کد با دسترسی root برسد.

اگر سرور cPanel دارید، فقط بستن موقت Parked/Addon Domain کافی نیست. نسخه فعلی را بررسی کنید، cPanel/WHM را فوراً به بیلد اصلاح‌شده یا نسخه جدیدتر ارتقا دهید و بعد از آپدیت، لاگ‌ها و تغییرات مشکوک فایل‌ها را هم مرور کنید.

در مقاله امروز، نسخه‌های Patch شده و مراحل بررسی و ارتقای امن را کامل توضیح دادیم.

#آکادمی_وان_سرور

🔐 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

🛡 هدرهای امنیتی HTTP واقعاً چه کمکی به امنیت سایت می‌کنن؟

هدرهایی مثل CSP، HSTS، X-Content-Type-Options، Referrer-Policy و Permissions-Policy می‌تونن بخش مهمی از حملات سمت مرورگر مثل XSS، MIME Sniffing و Clickjacking رو محدود کنن؛ اما اگر اشتباه تنظیم بشن، حتی ممکنه بخشی از سایت رو از کار بندازن.

تو آموزش جدید آکادمی وان‌سرور، تنظیم امن این هدرها روی NGINX و Apache رو مرحله‌به‌مرحله با نمونه کانفیگ، روش تست و خطاهای رایج بررسی کردیم.

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

#آکادمی_وان_سرور #امنیت_وب #NGINX #Apache #HTTP

امشب بریم سراغ یه ابزار خیلی به‌دردبخور برای جابه‌جایی و بکاپ فایل بین سرورها: 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

هشدار امنیتی برای مدیران سرورهای cPanel ⚠️

آسیب‌پذیری CVE-2026-67402 در سرویس MESSENGER مربوط به CSF می‌تواند در شرایطی به مهاجمِ بدون احراز هویت اجازه اجرای کد با سطح دسترسی کاربر Apache را بدهد. نسخه‌های CSF تا 16.30 در معرض خطرند، به‌خصوص وقتی Messenger v3 فعال باشد.

راهکار اصلی، به‌روزرسانی CSF به نسخه 16.31 یا جدیدتر است. اگر فعلاً امکان آپدیت ندارید، موقتاً گزینه MESSENGERV3 را در فایل تنظیمات CSF روی 0 بگذارید و سرویس‌های csf و lfd را restart کنید. جزئیات بررسی شرایط آسیب‌پذیری و دستورات لازم را در آموزش کامل بخوانید.

#امنیت_سرور

گاهی سرور ظاهراً اینترنت داره، پینگ هم جواب می‌ده، ولی یک سایت نصفه باز می‌شه، دانلود وسط کار می‌ایسته یا اتصال از داخل 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