دستور ss در لینوکس آمار سوکت‌ها را نشان می‌دهد؛ شباهت به netstat دارد ولی معمولاً سریع‌تر است و جزئیات TCP بیشتری می‌دهد. با همین ابزار می‌فهمید کدام پورت در حالت LISTEN است و کدام اتصال برقرار مانده. مرجع این آموزش صفحهٔ رسمی ss(8) در man7 است.
آموزش دستور ss در لینوکس؛ دیدن پورت‌های باز و اتصال‌ها
پیش‌نیازهایی که جا می‌ماند: یک شل روی لینوکس (دسکتاپ یا سرور)، بستهٔ iproute2 که معمولاً ss را می‌آورد، و ترجیحاً دسترسی کافی وقتی می‌خواهید نام فرایند را با -p ببینید. نقش‌ها را جدا کنید: ss فقط گزارش می‌دهد؛ سرویس/اپ سوکت را باز کرده؛ فایروال ممکن است پورت را از بیرون ببندد حتی اگر LISTEN محلی باشد.
- ترمینال را باز کنید و با ss -h یا man ss خلاصهٔ گزینه‌ها را ببینید تا نسخهٔ سیستم‌تان شناخته شود.
- بدون گزینه، طبق man، ss سوکت‌های غیرشنوندهٔ برقرار را نشان می‌دهد (مثلاً اتصال‌های TCP برقرار). برای دیدن همه‌چیز از ss -a استفاده کنید.
- فقط پورت‌های در حال شنیدن: ss -l یا صریح‌تر ss -ltn برای TCP عددی. فلگ -l / --listening همان listening است؛ -n / --numeric نام سرویس را resolve نمی‌کند و عدد پورت را می‌دهد.
- برای UDP شنونده: ss -lun. ترکیب رایج عیب‌یابی وب: ss -tulpn یعنی TCP+UDP، listening، عددی، با فرایند (-p / --processes).
- اگر خروجی شلوغ است، فیلتر کنید؛ مثلاً پورت ۸۰/۴۴۳ یا وضعیت خاص. man اجازهٔ FILTER می‌دهد؛ برای شروع، ss -ltn 'sport = :80' یا معادل نسخهٔ سیستم‌تان را امتحان کنید.
- جزئیات بیشتر TCP با -i (info) یا تایمر با -o؛ برای حافظهٔ سوکت -m. این‌ها وقتی اتصال «گیر» کرده یا بافر پر است به درد می‌خورند، نه برای اولین نگاه.
- نام فرایند را با -p ببینید؛ روی بعضی سیستم‌ها برای سوکت‌های دیگران به دسترسی بالا نیاز دارید. اگر فقط عدد inode می‌بینید، اول با کاربر درست یا sudo تکرار کنید.
- نتیجه را با انتظار سرویس بسنجید: اگر nginx باید روی ۸۰ گوش بدهد و در ss -ltn نیست، مشکل از خود سرویس است نه لزوماً فایروال. اگر LISTEN هست ولی از بیرون نمی‌آید، سراغ firewall و bind آدرس بروید.
یادآوری man: بدون گزینه، listeningها عمداً حذف می‌شوند؛ خیلی‌ها همین را با «ss هیچ پورتی نشان نمی‌دهد» اشتباه می‌گیرند. همیشه برای پورت باز از -l یا -a استفاده کنید. -p فرایند را نشان می‌دهد و -T تردها را هم می‌آورد و ضمناً -p را implied می‌کند.
اگر خروجی ss -tulpn خالی‌تر از انتظار است یا permission برای -p می‌گیرید، در نظرات توزیع لینوکس و همان دو خط خطا (بدون آی‌پی داخلی حساس) را بگذارید.
خطاهای رایج و نکات امنیتی
- هیچ LISTEN نمی‌بینید → فلگ -l یا -a را فراموش کرده‌اید.
- نام سرویس گیج‌کننده است → با -n عدد پورت را ببینید.
- ستون Process خالی است → دسترسی یا نبود -p.
- پورت محلی باز است ولی از اینترنت نمی‌آید → bind روی 127.0.0.1 یا فایروال؛ ss به‌تنهایی NAT را باز نمی‌کند.
- روی سرور تولید، خروجی کامل ss را در تیکت عمومی نگذارید؛ آدرس و سرویس‌های داخلی را خلاصه کنید.
شما ss را بیشتر برای پیدا کردن پورت اشغال‌شده می‌خواهید یا برای ردیابی اتصال‌های برقرار؟ ترکیب فلگ همیشگی‌تان چیست؟
در عیب‌یابی سرویس، ترتیب درست معمولاً این است: وضعیت سرویس، بعد ss برای LISTEN، بعد تست محلی، بعد فایروال. اگر ss پورت را نشان ندهد، باز کردن پورت در firewall چیزی را درست نمی‌کند.
آدرس bind را بخوانید: گوش دادن روی 127.0.0.1 فقط محلی است؛ 0.0.0.0 یا :: یعنی همهٔ اینترفیس‌ها. خیلی از «از بیرون نمی‌آید»ها همین‌جا حل می‌شوند نه با ss بیشتر.
برای اتصال‌های برقرار، ss بدون -l مفید است؛ برای TIME-WAIT و مشابه، خروجی را با صبر بخوانید تا نتیجه نگیرید سرویس «خراب» است. گزینه‌های -o و -i وقتی اتصال گیر کرده به کار می‌آیند.
مرجع گزینه‌ها و رفتار پیش‌فرض همان ss(8) روی man7 است؛ به‌جای حفظ کردن همهٔ فلگ‌ها، -tulpn را پایه و بقیه را موردی اضافه کنید.
