وان سرور | هاست، سرور و آموزش
الذهاب إلى القناة على Telegram
🚀 وان سرور | زیرساخت مطمئن برای کسب‌وکار آنلاین 🧠 آموزش Linux، VPS، هاست و WordPress 🚨 هشدارها و نکات فنی مهم 🎁 آفرهای اختصاصی اعضای کانال 🌐 one3erver.com 💬 پشتیبانی: @One3erver_support_bot
إظهار المزيد798
المشتركون
لا توجد بيانات24 ساعات
-27 أيام
-430 أيام
جارٍ تحميل البيانات
القنوات المماثلة
سحابة العلامات
لا توجد بيانات
هل تواجه مشاكل؟ يرجى تحديث الصفحة أو الاتصال بمدير الدعم الخاص بنا.
الإشارات الواردة والصادرة
---
---
---
---
---
---
جذب المشتركين
أكتوبر '26أكتوبر '26
أكتوبر '26
+80
في 0 قنوات
سبتمبر '260
في 1 قنوات
Get PRO
أغسطس '260
في 0 قنوات
Get PRO
يوليو '260
في 0 قنوات
Get PRO
يونيو '260
في 0 قنوات
Get PRO
مايو '260
في 0 قنوات
Get PRO
أبريل '260
في 0 قنوات
Get PRO
مارس '260
في 0 قنوات
Get PRO
فبراير '260
في 0 قنوات
Get PRO
يناير '260
في 0 قنوات
Get PRO
ديسمبر '250
في 0 قنوات
Get PRO
نوفمبر '250
في 0 قنوات
Get PRO
أكتوبر '250
في 0 قنوات
Get PRO
سبتمبر '250
في 0 قنوات
Get PRO
أغسطس '250
في 0 قنوات
Get PRO
يوليو '250
في 2 قنوات
Get PRO
يونيو '250
في 0 قنوات
Get PRO
مايو '250
في 0 قنوات
Get PRO
أبريل '250
في 2 قنوات
Get PRO
مارس '250
في 0 قنوات
Get PRO
فبراير '250
في 2 قنوات
Get PRO
يناير '250
في 0 قنوات
Get PRO
ديسمبر '24
+6
في 0 قنوات
Get PRO
نوفمبر '24
+24
في 2 قنوات
Get PRO
أكتوبر '24
+15
في 4 قنوات
Get PRO
سبتمبر '24
+25
في 3 قنوات
Get PRO
أغسطس '24
+58
في 3 قنوات
Get PRO
يوليو '240
في 1 قنوات
Get PRO
يونيو '240
في 0 قنوات
Get PRO
مايو '24
+6
في 0 قنوات
Get PRO
أبريل '24
+26
في 0 قنوات
Get PRO
مارس '24
+43
في 2 قنوات
Get PRO
فبراير '24
+14
في 0 قنوات
Get PRO
يناير '24
+27
في 0 قنوات
Get PRO
ديسمبر '23
+37
في 0 قنوات
Get PRO
نوفمبر '23
+58
في 1 قنوات
Get PRO
أكتوبر '23
+186
في 7 قنوات
Get PRO
سبتمبر '230
في 0 قنوات
Get PRO
أغسطس '230
في 0 قنوات
Get PRO
يوليو '230
في 0 قنوات
Get PRO
يونيو '230
في 0 قنوات
Get PRO
مايو '230
في 0 قنوات
Get PRO
أبريل '230
في 0 قنوات
Get PRO
مارس '230
في 0 قنوات
Get PRO
فبراير '230
في 0 قنوات
Get PRO
يناير '23
+55
في 0 قنوات
Get PRO
ديسمبر '220
في 0 قنوات
Get PRO
نوفمبر '220
في 0 قنوات
Get PRO
أكتوبر '22
+51
في 0 قنوات
Get PRO
سبتمبر '22
+16
في 0 قنوات
Get PRO
أغسطس '220
في 0 قنوات
Get PRO
يوليو '22
+8
في 0 قنوات
Get PRO
يونيو '22
+5
في 0 قنوات
Get PRO
مايو '22
+11
في 0 قنوات
Get PRO
أبريل '22
+3
في 0 قنوات
Get PRO
مارس '22
+13
في 0 قنوات
Get PRO
فبراير '22
+8
في 0 قنوات
Get PRO
يناير '22
+14
في 0 قنوات
Get PRO
ديسمبر '21
+20
في 0 قنوات
Get PRO
نوفمبر '21
+13
في 0 قنوات
Get PRO
أكتوبر '21
+11
في 0 قنوات
Get PRO
سبتمبر '21
+7
في 0 قنوات
Get PRO
أغسطس '21
+5
في 0 قنوات
Get PRO
يوليو '21
+7
في 0 قنوات
Get PRO
يونيو '21
+3
في 0 قنوات
Get PRO
مايو '21
+13
في 0 قنوات
Get PRO
أبريل '21
+15
في 0 قنوات
Get PRO
مارس '21
+13
في 0 قنوات
Get PRO
فبراير '21
+9
في 0 قنوات
Get PRO
يناير '21
+10
في 0 قنوات
Get PRO
ديسمبر '20
+216
في 0 قنوات
| التاريخ | نمو المشتركين | الإشارات | القنوات | |
| 24 أكتوبر | 0 | |||
| 23 أكتوبر | 0 | |||
| 22 أكتوبر | 0 | |||
| 21 أكتوبر | 0 | |||
| 20 أكتوبر | 0 | |||
| 19 أكتوبر | 0 | |||
| 18 أكتوبر | 0 | |||
| 17 أكتوبر | 0 | |||
| 16 أكتوبر | 0 | |||
| 15 أكتوبر | 0 | |||
| 14 أكتوبر | 0 | |||
| 13 أكتوبر | 0 | |||
| 12 أكتوبر | 0 | |||
| 11 أكتوبر | 0 |
منشورات القناة
🚨 هشدار امنیتی مهم به مشتریان وان سرور | LiteSpeed Cache
🔴 به اطلاع تمامی مشتریانی که از سرورهای مجهز به وب‌سرور LiteSpeed یا لایسنس LiteSpeed وان سرور استفاده می‌کنند می‌رسانیم:
گزارشی درباره یک آسیب‌پذیری امنیتی در افزونه LiteSpeed Cache وردپرس با شناسه
CVE-2026-113500 منتشر شده است.
⚠️ در صورتی که وب‌سایت وردپرسی شما از این افزونه استفاده می‌کند، توصیه می‌کنیم اقدامات زیر را در اولویت قرار دهید:
✅ افزونه LiteSpeed Cache را از طریق مخزن رسمی وردپرس به آخرین نسخه امن منتشرشده به‌روزرسانی کنید.
✅ پس از به‌روزرسانی، از بخش تنظیمات افزونه، گزینه Purge All را اجرا کنید.
✅ کاربران دارای دسترسی مدیریت و فعالیت‌های مشکوک سایت را بررسی کنید.
✅ پیش از به‌روزرسانی، از وب‌سایت خود نسخه پشتیبان تهیه کنید.
📌 نکته مهم: این هشدار مربوط به افزونه LiteSpeed Cache وردپرس است و لزوماً به معنای وجود آسیب‌پذیری در وب‌سرور یا لایسنس LiteSpeed نیست.
🔗 اطلاعات آسیب‌پذیری:
https://www.tenable.com/cve/CVE-2026-113500
🌐 وان سرور | @one3erver| 2 | 🚨 هشدار امنیتی مهم | کشف دو آسیب‌پذیری بحرانی در PHP
دو آسیب‌پذیری بسیار خطرناک با شناسه‌های زیر در PHP شناسایی شده‌اند:
🔴 CVE-2026-109618
🔴 CVE-2026-109619
⚠️ شدت خطر: بحرانی (CVSS 9.2/10)
این آسیب‌پذیری‌ها که با نام PHP2Shell شناخته می‌شوند، می‌توانند به مهاجم اجازه دهند بدون احراز هویت، کد مخرب را روی سرور اجرا کند (RCE).
✅ راهکار رفع آسیب‌پذیری:
🔹 سرورهای لینوکسی: نسخه PHP را به یکی از نسخه‌های اصلاح‌شده 8.2.35، 8.3.36، 8.4.27 یا 8.5.12 (متناسب با شاخه PHP) به‌روزرسانی کنید.
🔹 سرورهای CloudLinux: اصلاحیه‌های امنیتی برای نسخه‌های قدیمی PHP، حتی PHP 5.6، 7.4، 8.0 و 8.1 منتشر شده‌اند. پکیج‌های Alt-PHP و EA-PHP را آپدیت کنید:
dnf update 'alt-php*' 'ea-php*'
در CloudLinux 7 از yum استفاده کنید.
🔹 سرورهای CentOS 7 و سیستم‌عامل‌های قدیمی: به دلیل پایان پشتیبانی رسمی، حتماً از سرویس‌های پشتیبانی امنیتی مانند TuxCare ELS (با پوشش PHP) استفاده کنید یا به سیستم‌عامل پشتیبانی‌شده مهاجرت کنید.
🔹 سرورهای ویندوزی: PHP را از منابع معتبر به نسخه اصلاح‌شده ارتقا دهید.
🛡 نکته مهم: در CloudLinux ممکن است شماره اصلی نسخه PHP تغییر نکند؛ زیرا اصلاحیه‌ها به‌صورت Backport ارائه می‌شوند. نصب اصلاحیه و فعال شدن آن در پردازش‌های PHP را بررسی کنید.
⛔️ استفاده از فایروال و WAF به‌تنهایی جایگزین آپدیت امنیتی نیست.
🔗 منبع: https://blog.cloudlinux.com/php-cve-2026-109618-and-cve-2026-109619
🌐 وان سرور | One Server
#امنیت_سرور #PHP #CloudLinux #CentOS #Vulnerability #OneServer | 123 |
| 3 | ⚠️ اطلاعیه اختلال سرویس از سمت رسپینا
کاربران گرامی وان‌سرور،
طبق اطلاعیه دریافتی از شرکت داده‌پردازی رسپینا، به دلیل انجام عملیات ارتقا و به‌روزرسانی تجهیزات شبکه رسپینا، در روز چهارشنبه ۲۲ مهر ۱۴۰۵ از ساعت ۰۲:۰۰ الی ۰۷:۰۰ بامداد، برخی سرویس‌هایی که از زیرساخت این شرکت استفاده می‌کنند ممکن است با قطعی یا اختلال موقت مواجه شوند.
این اختلال از سمت زیرساخت شرکت رسپینا بوده و ارتباطی با شبکه و تجهیزات وان‌سرور ندارد.
از صبر و همراهی شما سپاسگزاریم. 🌹
وان‌سرور | One Server
🌐 one3erver.com | 207 |
| 4 | گاهی 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 | 293 |
| 5 | گاهی یک مجوز اشتباه روی فایل یا پوشه، بیشتر از چیزی که فکر می‌کنی دردسر می‌سازه؛ مخصوصاً وقتی برای رفع سریع Permission Error از 777 استفاده شده و بعد همون‌طور باقی مونده. برای یک ممیزی ساده، فایل‌ها و پوشه‌های world-writable رو پیدا کن:
find /etc /var/www /opt -xdev -perm -0002 -ls 2>/dev/null
بعد نتیجه‌ها رو کورکورانه chmod نکن؛ اول Owner، Group و نیاز واقعی سرویس رو بررسی کن. برای مسیرهای وب معمولاً مجوز حداقلی و مالکیت درست بهتر از بازکردن دسترسی برای همه است. مجوز موقت اگر جمع نشه، خیلی زود تبدیل به تنظیم دائمی می‌شه.
🔗 کانال وان سرور
#امنیت #Linux | 296 |
| 6 | گاهی تونل WireGuard بین Entry و Exit کاملاً Up است و Handshake هم تازه می‌شود، اما بخشی از ترافیک برگشتی بی‌صدا Drop می‌شود. در معماری چندنودی، یکی از چیزهایی که باید چک کنی rp_filter است؛ چون مسیر نامتقارن می‌تواند Reverse Path Check را حساس کند.
برای بررسی اولیه این مقادیر را ببین:
sysctl net.ipv4.conf.all.rp_filter
sysctl net.ipv4.conf.default.rp_filter
sysctl net.ipv4.conf.wg0.rp_filter
اگر رفت و برگشت از مسیرهای متفاوت انجام می‌شود، قبل از خاموش‌کردن سراسری این کنترل، Route و Policy Routing را بررسی کن و تغییر را فقط روی Interface لازم تست کن. اینجا هدف حذف یک کنترل امنیتی نیست؛ هدف پیدا کردن Drop ناشی از طراحی مسیر است.
🔗 کانال وان سرور
#WireGuard #VPN | 218 |
| 7 | گاهی سرویس روی VPS بالا و CPU هم عادیه، ولی اتصال‌ها مکث می‌کنن یا سرعت نوسانی می‌شه. قبل از دست‌کاری اپلیکیشن، بد نیست TCP Retransmission رو بررسی کنی؛ چون Packet Loss، مسیر بد یا مشکل MTU می‌تونه باعث ارسال مجدد بسته‌ها بشه.
برای یک بررسی سریع این دو دستور مفیدن:
ss -ti
nstat -az | grep -E 'TcpRetransSegs|TcpExtTCPLostRetransmit'
اگر Retransmit در زمان اختلال سریع بالا می‌ره، بعدش مسیر رو با mtr و MTU رو بررسی کن. نکته مهم اینه که Retransmission خودش علت نهایی نیست؛ یک نشونه‌ست که کمک می‌کنه مشکل شبکه رو از CPU، RAM یا خود سرویس جدا کنی.
🔗 کانال وان سرور
#VPS #Linux | 184 |
| 8 | گاهی سایت وردپرسی کند می‌شود ولی CPU و RAM در نگاه اول عادی‌اند؛ اینجا حدس‌زدن درباره افزونه‌ها معمولاً وقت تلف می‌کند. برای پیدا کردن درخواست PHP که واقعاً گیر کرده، PHP-FPM slowlog خیلی کاربردی است.
برای Pool مربوط به سایت، این تنظیم‌ها را فعال کن:
request_slowlog_timeout = 5s
slowlog = /var/log/php-fpm/www-slow.log
بعد PHP-FPM را Reload کن و هنگام کندی Slowlog را بررسی کن. اگر یک Plugin، Theme یا تابع PHP مرتب در Stack Trace تکرار شود، سرنخ واقعی داری؛ بدون اینکه کورکورانه کش را پاک یا افزونه‌ها را یکی‌یکی خاموش کنی.
نکته مهم اینه که مسیر فایل و نام سرویس بین توزیع‌ها و نسخه‌های PHP فرق می‌کند؛ قبل از Reload حتماً کانفیگ را تست کن.
🔗 کانال وان سرور
#WordPress #Hosting | 159 |
| 9 | گاهی 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 | 579 |
| 10 | فرض کن ساعت دو شب مانیتورینگ هشدار می‌ده و یک VPS ناگهان کند شده؛ هنوز نمی‌دونی مشکل از CPU، RAM، دیسک یا شبکه است. اولین دستوری که می‌زنی کدومه؟ 👇
گزینه خودت رو انتخاب کن و بعد با این چک سریع مقایسه کن:
uptime
free -h
vmstat 1 5
df -h
نکته اینجاست که از روی یک عدد نباید حکم بدی؛ Load بالا می‌تونه از CPU باشه، ولی I/O wait یا فشار حافظه هم می‌تونه همون ظاهر رو بسازه. برای Incident واقعی، اول وضعیت کلی رو بگیر و بعد برو سراغ ابزار تخصصی‌تر.
🔗 کانال وان سرور
#Linux #VPS | 199 |
| 11 | گاهی خطرناک‌ترین دسترسی روی سرور نه پورت بازه، نه یک سرویس عجیب؛ یک خط فراموش‌شده در sudoers می‌تونه کاربر عادی رو عملاً به root برسونه. مخصوصاً وقتی برای اسکریپت یا مانیتورینگ، NOPASSWD گذاشتی و بعد یادت رفته جمعش کنی.
برای یک بررسی سریع، دسترسی‌های sudo رو این‌طور ببین:
sudo -l -U USERNAME
grep -R "NOPASSWD" /etc/sudoers /etc/sudoers.d 2>/dev/null
بهتره به‌جای دسترسی کلی، فقط همان command لازم را با مسیر کامل مجاز کنی و بعد از تغییر هم فایل را با visudo -c اعتبارسنجی کنی. دسترسی موقت اگر جمع نشه، خیلی راحت تبدیل به مسیر دائمی Privilege Escalation می‌شه.
🔗 کانال وان سرور
#امنیت #Linux | 184 |
| 12 | گاهی تو معماری چندنودی VPN تونل سالمه و حتی Ping هم رد می‌شه، ولی ترافیک بعضی کاربرها از Exit اشتباه بیرون می‌ره. اینجا معمولاً مشکل خود تونل نیست؛ Policy Routing و markها رو باید چک کرد.
برای شروع ببین Rule و Route واقعاً با mark موردنظر هماهنگ‌اند یا نه:
ip rule show
ip route show table all | grep -E 'default|wg|tun'
nft list ruleset | grep -i mark
نکته مهم اینه که mark کردن Packet به‌تنهایی کافی نیست؛ باید Rule متناظر به جدول درست اشاره کنه و مسیر برگشت هم با معماری Entry/Exit سازگار باشه. وگرنه تونل Up می‌مونه ولی بخشی از Sessionها نامتقارن می‌شن و بی‌دلیل Drop می‌خورند.
🔗 کانال وان سرور
#VPN #Routing | 194 |
| 13 | گاهی 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 | 556 |
| 14 | گاهی کش Cloudflare روشنه، ولی صفحه هنوز هر بار مستقیم از سرور جواب می‌گیره. قبل از اینکه سراغ Purge و تنظیمات عجیب بری، هدر پاسخ رو ببین؛ معمولاً خودش سرنخ رو لو می‌ده.
برای بررسی سریع این دستور کافیه:
curl -I https://example.com
اگر CF-Cache-Status: HIT دیدی، پاسخ از کش لبه آمده. مقدار MISS یعنی این درخواست در کش نبوده و DYNAMIC معمولاً یعنی Cloudflare آن پاسخ را برای کش‌کردن واجد شرایط ندیده.
نکته مهم اینه که قبل از دست‌کاری Cache Rules، کوکی‌ها، Cache-Control و نوع URL رو هم بررسی کنی؛ وگرنه Purge کردن فقط چند دقیقه حس پیروزی می‌ده! 😄
🔗 کانال وان سرور
#Cloudflare #هاستینگ | 179 |
| 15 | گاهی روی نودهای VLESS/REALITY همه‌چیز از نظر کانفیگ درست به‌نظر می‌رسه، ولی بخشی از اتصال‌ها ناپایدار می‌شن. قبل از دست‌کاری Core، مقصدی که برای Reality انتخاب کردی رو از خود سرور بررسی کن؛ چون مسیر، SNI و TLS مقصد باید واقعاً قابل اتکا باشن.
برای یک چک ساده، هندشیک TLS و گواهی مقصد رو از همان نود ببین:
openssl s_client -connect example.com:443 -servername example.com </dev/null
اگر اتصال به مقصد timeout می‌شه، گواهی غیرمنتظره می‌بینی یا مسیر آن از دیتاسنتر ناپایداره، عوض‌کردن UUID و پورت معمولاً درمان مسئله نیست. اول خود مقصد و دسترسی نود به آن را پایدار کن، بعد سراغ تنظیمات Reality برو.
🔗 کانال وان سرور
#VLESS #Reality | 210 |
| 16 | گاهی بعد از ریبوت VPS می‌بینی سرور بالا آمده، ولی یکی از سرویس‌ها با تأخیر آماده می‌شود و کل استک چند ده ثانیه منتظر می‌ماند. به‌جای حدس‌زدن، زنجیره بوت systemd را ببین.
برای پیدا کردن سرویس‌هایی که مسیر بوت را کند کرده‌اند این دو دستور خیلی کاربردی‌اند:
systemd-analyze blame
systemd-analyze critical-chain
نکته اینجاست که blame فقط زمان هر واحد را نشان می‌دهد؛ اما critical-chain وابستگی‌هایی را پیدا می‌کند که واقعاً مسیر بوت را عقب انداخته‌اند. پس صرفاً طولانی‌ترین عدد را مقصر اعلام نکن؛ اول زنجیره وابستگی را ببین، بعد سراغ همان سرویس برو.
🔗 کانال وان سرور
#Linux #VPS | 203 |
| 17 | خیلی وقت‌ها Fail2ban نصب شده و همه خیال‌شون راحته؛ ولی چند ماه بعد می‌بینی سرویس بالا بوده و عملاً هیچ IPای را Ban نمی‌کرده.
برای یک چک سریع اول وضعیت Jail مربوط به SSH رو ببین:
fail2ban-client status sshd
بعد حتماً Backend فایروال رو هم بررسی کن؛ روی سیستم‌های جدید ممکنه انتظار iptables داشته باشی ولی سرور با nftables کار کنه. برای دیدن Ruleهای فعال:
nft list ruleset | grep -i f2b
نکته مهم اینه که «Active بودن سرویس» با «واقعاً Block شدن مهاجم» یکی نیست. بعد از هر تغییر فایروال یا مهاجرت سیستم‌عامل، مسیر Ban رو دوباره تست کن.
🔗 کانال وان سرور
#امنیت #VPS | 180 |
| 18 | گاهی دیسک VPS بی‌سروصدا پر می‌شه و وقتی سراغ فایل‌های معمولی می‌ری چیز عجیبی پیدا نمی‌کنی؛ یکی از جاهایی که ارزش بررسی داره لاگ‌های systemd journal ـه.
اول ببین journal واقعاً چقدر فضا گرفته:
journalctl --disk-usage
اگر حجمش غیرعادی بود، به‌جای پاک‌کردن دستی فایل‌های /var/log/journal می‌تونی خود journal رو کنترل‌شده جمع‌وجور کنی. مثلاً نگه داشتن حداکثر ۷ روز اخیر:
journalctl --vacuum-time=7d
یا محدود کردن حجم آرشیوها به حدود 500 مگابایت:
journalctl --vacuum-size=500M
نکته: قبل از vacuum کردن، اگر سرور مشکل یا سرویس ناپایداری داره اول لاگ موردنیازت رو بررسی یا ذخیره کن؛ چون لاگی که حذف شد برای عیب‌یابی بعدی برنمی‌گرده. 😄
اگر journal دوباره خیلی سریع بزرگ شد، پاکسازی درمان اصلی نیست؛ باید ببینی کدام سرویس مدام خطا می‌نویسه و ریشه همون رو درست کنی.
🔗 کانال وان سرور
#لینوکس #VPS | 182 |
| 19 | گاهی سرور زیر بار شبکه هنوز CPU و RAM بدی نداره، ولی اتصال‌های جدید Timeout می‌شن، بعضی درخواست‌ها رندوم می‌پرن یا NAT رفتار عجیب پیدا می‌کنه. اینجا یکی از چیزهایی که ارزش چک‌کردن داره conntrack ـه.
کرنل لینوکس برای Connection Tracking تعداد اتصال‌های در حال رهگیری رو نگه می‌داره. اول ببین الان چند Entry داری و سقف چقدره:
sysctl net.netfilter.nf_conntrack_count
sysctl net.netfilter.nf_conntrack_max
مثلاً اگر nf_conntrack_count مدام خیلی نزدیک nf_conntrack_max باشه، احتمالاً جدول تحت فشاره. برای دیدن هشدارهای کرنل هم این تست سریع بد نیست:
dmesg | grep -i conntrack
اگر پیامی مثل nf_conntrack: table full, dropping packet دیدی، دیگه سرنخ خیلی جدی داری؛ پکت‌های جدید واقعاً دارن Drop می‌شن.
نکته: سریع nf_conntrack_max رو چند برابر نکن و خیال خودت رو راحت نکن 😄 اول ببین این حجم اتصال طبیعیه یا یک سرویس، NAT شلوغ، اسکن یا ترافیک غیرعادی جدول رو پر کرده. بالا بردن سقف، مصرف RAM رو هم بیشتر می‌کنه و ممکنه فقط اصل مشکل رو عقب بندازه.
🔗 کانال وان سرور
#لینوکس #شبکه | 179 |
| 20 |  هشدار امنیتی جدید برای کاربران MikroTik جدی است. زنجیره MikroTrick در RouterOS می‌تواند روی دستگاه‌هایی که SSH آن‌ها از اینترنت در دسترس است، در شرایط مشخص به تصرف کامل روتر منجر شود.
نسخه‌های اصلاح‌شده شامل 7.24.2، 7.23.4، 7.25 beta 3 و 6.49.21 هستند.
اقدام فوری این است که RouterOS را به نسخه اصلاح‌شده ارتقا بدهید و دسترسی SSH را فقط به IPهای مورد اعتماد، شبکه مدیریت یا VPN محدود کنید. بعد از آپدیت هم کاربران، Scriptها، Scheduler، Firewall و Logها را برای نشانه‌های مشکوک بررسی کنید.
🔗 کانال وان سرور
#هشدار_وان_سرور | 187 |
