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

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

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

اول بار سرور را ببینید، نه سایت را

وقتی سایت کند است یا تایم‌اوت می‌دهد، اولین عددی که باید ببینید load average است:

uptime
# 14:32:07 up 41 days,  3:12,  2 users,  load average: 12.40, 9.85, 4.20

سه عدد آخر میانگین بار در یک، پنج و پانزده دقیقهٔ گذشته است. قاعدهٔ سرانگشتی: اگر این عدد از تعداد هسته‌های CPU بیشتر شد، صف تشکیل شده. با nproc تعداد هسته را ببینید. load ۱۲ روی سرور ۴ هسته‌ای یعنی سه برابر ظرفیت؛ load ۱۲ روی سرور ۱۶ هسته‌ای یعنی هنوز جا دارید.

نکتهٔ مهم: load بالا همیشه یعنی CPU پر است؟ نه. اگر load بالا باشد ولی top نشان دهد CPU بیکار است، مشکل I/O دیسک است. این‌جا اشتباه می‌کنند: مدیر سایت می‌بیند load بالا رفته، سرور را ارتقا می‌دهد، و مشکل که کندی دیسک شبکه‌ای بوده سر جایش می‌ماند.

top -o %CPU
free -h
df -h
df -i

free -h را با دقت بخوانید. ستون available مهم است، نه free. لینوکس حافظهٔ آزاد را برای cache خرج می‌کند و این طبیعی است؛ اگر available نزدیک صفر شد و swap پر بود، آن‌وقت مشکل حافظه دارید. df -h فضای دیسک را نشان می‌دهد و df -i تعداد inode. خطای «No space left on device» در حالی که df -h می‌گوید ۴۰٪ آزاد است، تقریباً همیشه یعنی inode تمام شده — معمولاً به‌خاطر میلیون‌ها فایل session یا cache کوچک.

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

برای دیدن پرمصرف‌ترین پروسه‌ها به ترتیب حافظه و CPU:

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

و برای فهمیدن این‌که کدام پروسه واقعاً I/O دیسک تولید می‌کند، iotop را نصب کنید (بستهٔ iotop در مخازن استاندارد هست). اگر iotop در دسترس نبود، vmstat 1 هم کافی است: ستون‌های si و so اگر عدد بزرگ نشان بدهند، سیستم دارد swap می‌کند و این بدترین حالت برای یک سرور وب است.

یک trade-off که باید صریح بگویم: کشتن پروسه با kill -9 سریع‌ترین راه است و من هم در شرایط اضطراری همین را می‌زنم، ولی اگر پروسه یک دیتابیس باشد، ممکن است جدول‌ها را خراب کند و بعد از ری‌استارت با خطای recovery روبه‌رو شوید. اول kill -15 بزنید، ده ثانیه صبر کنید، بعد اگر جواب نداد -9.

سرویس وب و پورت‌ها

اگر سایت کلاً جواب نمی‌دهد، قبل از هر چیز ببینید سرویس وب زنده است یا نه:

systemctl status nginx
systemctl status apache2
systemctl status php8.2-fpm

و بعد پورت‌ها:

ss -tulpn | grep -E ':80|:443|:3306'

اگر پورت ۸۰ گوش نمی‌دهد، مشکل در لایهٔ سرویس است نه در کد سایت. اگر گوش می‌دهد ولی از بیرون جواب نمی‌گیرید، احتمالاً فایروال یا کلادفلر وسط است. ss جانشین netstat است؛ روی توزیع‌های جدید netstat ممکن است اصلاً نصب نباشد.

برای تست پاسخ HTTP از خود سرور، بدون واسطهٔ DNS:

curl -I -H "Host: example.com" http://127.0.0.1
curl -o /dev/null -s -w "%{time_total}\n" https://example.com

عدد دوم زمان کل درخواست به ثانیه است. اگر این عدد زیر ۰.۵ بود و کاربران هنوز شکایت دارند، مشکل از سرور شما نیست؛ از مسیر شبکه یا DNS است. تفکیک کدهای وضعیت مثل 502 و 504 در راهنمای کد وضعیت HTTP آمده و برای این مرحله دقیقاً همان چیزی است که لازم دارید.

لاگ‌ها: جایی که جواب واقعی هست

هیچ دستوری جای خواندن لاگ را نمی‌گیرد. مسیرها بسته به توزیع فرق می‌کند:

tail -f /var/log/nginx/error.log
tail -n 200 /var/log/nginx/access.log
journalctl -u php8.2-fpm --since "30 min ago"
journalctl -xe

در access log دنبال کدهای ۵۰۰ بگردید و ببینید کدام مسیر بیشترین تکرار را دارد:

awk '{print $9}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head

اگر یک IP خاص دارد سرور را می‌کوبد، همان‌جا پیدایش می‌کنید. اگر خطای ۵۰۰ روی یک اسکریپت خاص متمرکز است، مشکل افزونه یا کد است نه سرور. برای سایت‌های وردپرسی، ممیزی افزونه‌ها معمولاً سریع‌تر از هر tuning سروری به نتیجه می‌رسد.

یک هشدار عملی: tail -f روی لاگی که هر ثانیه هزاران خط تولید می‌کند، خودش می‌تواند ترمینال شما را قفل کند. برای حجم بالا از grep با فیلتر استفاده کنید، نه از تماشای خام.

شبکه، DNS و اتصال به دیتابیس

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

dig +short example.com A
dig +trace example.com
ping -c 4 8.8.8.8
mtr -rw example.com

dig +trace مسیر کامل resolve را نشان می‌دهد و اگر جایی قطع شود، همان‌جا مشخص می‌شود. خطای NXDOMAIN یعنی رکورد وجود ندارد یا zone درست load نشده؛ جزئیات تشخیصش در خطای DNS_PROBE_FINISHED_NXDOMAIN آمده است.

برای دیتابیس، دو چیز را جدا تست کنید: اتصال شبکه و اتصال احراز هویت.

mysql -h 127.0.0.1 -u appuser -p -e "SELECT 1;"
mysqladmin -u root -p status

اگر mysqladmin status عدد Threads_connected نزدیک سقف max_connections نشان داد، مشکل این‌جاست: درخواست‌های وب پشت صف اتصال می‌مانند و سایت کند می‌شود، بدون این‌که CPU یا دیسک مشکلی داشته باشد. این یکی از آن مواردی است که همه به سرور وب نگاه می‌کنند و مقصر دیتابیس است.

چند دستور که وقت کم می‌آورند

• du -sh /var/log/* | sort -h — پیدا کردن لاگ‌های چاق که دیسک را پر کرده‌اند.
• lsof -i :80 — چه پروسه‌ای پورت را گرفته.
• find /var/www -name "*.php" -mtime -1 — چه فایل‌هایی در ۲۴ ساعت گذشته تغییر کرده‌اند؛ برای ردیابی تغییر مشکوک.
• crontab -l و ls /etc/cron.d/ — بکاپ یا اسکریپتی که ساعت ۳ بامداد سرور را می‌خواباند.
• last -n 20 — آخرین ورودها؛ اگر IP ناشناس دیدید، اول رمزها را عوض کنید بعد عیب‌یابی.

روی وردپرس، اگر دسترسی SSH دارید، WP-CLI چند برابر سریع‌تر از پنل است: wp plugin list --status=active و wp cron event list در چند ثانیه نشان می‌دهند چه چیزی در پس‌زمینه اجرا می‌شود. اگر cron وردپرس گیر کرده باشد، سایت روی هر بازدید کند می‌شود؛ الگوی تشخیصش در مشکل wp-cron توضیح داده شده.

چه زمانی این کارها کافی نیست

اگر بعد از همهٔ این‌ها load پایین است، دیسک سالم است، لاگ خطایی ندارد، ولی سایت هنوز کند است، احتمالاً مشکل در لایهٔ پلتفرم است: شبکهٔ ذخیره‌سازی، سهمیهٔ CPU کانتینر، یا همسایهٔ پرمصرف روی یک میزبان مجازی. این‌جا دیگر دستور لینوکس جواب نمی‌دهد و باید با ارائه‌دهنده تماس بگیرید. اگر روی هاست اشتراکی یا هاست وردپرس هستید، همین نقطه‌ای است که تیکت دادن منطقی‌تر از دست‌وپا زدن در ترمینال است.

برای کارهای روزمره، یک اسکریپت کوچک که هر پنج دقیقه uptime، free -h و df -h را در یک فایل می‌نویسد، بیشتر از هر ابزار گرانی به کارتان می‌آید. وقتی سایت خوابید، داشتن تاریخچهٔ این سه عدد در دو ساعت گذشته، تفاوت بین حدس و تشخیص است. ابزارهای آمادهٔ بیشتری هم در ابزارهای رایگان و راهنماهای گام‌به‌گام در مستندات در دسترس است.

پرسش‌های پرتکرار

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

اگر load average بالا باشد ولی top نشان دهد بخش زیادی از CPU بیکار (id) است، گلوگاه دیسک است. با vmstat 1 ستون wa را ببینید؛ عدد بالای ۲۰ درصد یعنی پروسه‌ها منتظر I/O هستند. در این حالت ارتقای CPU هیچ کمکی نمی‌کند.

تفاوت kill -15 و kill -9 چیست و کدام را بزنم؟

kill -15 درخواست خاتمهٔ تمیز می‌فرستد و پروسه فرصت دارد فایل‌ها و اتصال‌ها را ببندد. kill -9 بلافاصله و بدون فرصت می‌کشد و برای دیتابیس می‌تواند باعث recovery طولانی شود. همیشه اول ۱۵، و اگر بعد از ده ثانیه پروسه هنوز بود، ۹.

چرا df می‌گوید فضا هست ولی خطای No space left on device می‌گیرم؟

چون inode تمام شده، نه فضا. با df -i چک کنید. علت رایج، انبوه فایل‌های کوچک است: sessionهای PHP، فایل‌های cache، یا صف ایمیل. پیدا کردنشان با find /path -type f | wc -l روی پوشه‌های مشکوک شروع می‌شود.

سایت از داخل سرور باز می‌شود ولی از بیرون نه؛ از کجا شروع کنم؟

اول DNS را با dig +short example.com A چک کنید و ببینید IP برگشتی همان IP سرور است. بعد فایروال و پورت‌های باز را با ss -tulpn ببینید. اگر هر دو درست بود، احتمالاً پروکسی یا CDN وسط است و باید تنظیمات آن لایه را بررسی کنید.