ss مقابل netstat: أي أمر منافذ تستخدم في لينكس

استخدم ss — إنه المعيار الحالي على كل توزيعات لينكس الحديثة، وnetstat هناك من بقايا الماضي. على Ubuntu وFedora وDebian، يُشحن ثنائي netstat اليوم داخل حزمة اختيارية اسمها net-tools، بينما ss مدمج في iproute2 والمثبت في كل مكان. كما أن ss أسرع على الخوادم المشغولة لأنه يقرأ إحصاءات المقابس من النواة مباشرة بدل تفقّد ملفات _/proc_ واحدًا واحدًا. العيب هو الصياغة: -tulpn لا تعني الشيء نفسه في كل مكان، لذا يمنحك هذا الدليل جدول مطابقة الخيارات الدقيق، والأوامر المستحقة للحفظ، وإجابات الأسئلة التي تطفو وأنت في قلب حادثة الساعة الثانية فجرًا.

هل netstat مهجورة؟

على لينكس، نعم عمليًا. حزمة net-tools — التي تحوي netstat وifconfig وroute — لم تلاحق ميزات النواة الحديثة منذ سنوات، ولم تعد مثبتة افتراضيًا في أي توزيعة كبرى. لا تزال موجودة، ولا تزال تعمل، ولا شيء يستحق إزالتها، لكن الميزات الجديدة لا تهبط إلا في iproute2 (الحزمة خلف ss وip).

ثلاث نتائج عملية:

1. غائبة على التثبيتات الجديدة. خادم Ubuntu 24.04 أو Fedora الافتراضي بلا netstat إلا إذا ثبّت net-tools بيدك. ولهذا يبحث كثيرون عن مكافئ netstat — الثنائي ببساطة لم يعد موجودًا.
2. لا معلومات مقابس حديثة. netstat سبقت ميزات مثل TCP fast open وإحصاءات المقابس على مستوى subflow وإسناد المقابس إلى cgroup. وss يعرضها أصلًا.
3. استثناء Windows. على ويندوز، netstat حية وبصحة جيدة — netstat -ano ما تزال الطريقة القياسية لربط PID بمنفذ مستمع هناك. قصة الإهمال خاصة بلينكس وحده.

ما هو أمر ss في لينكس؟

ss اختصار “socket statistics”. يفرغ نظرة النواة لكل مقبس TCP وUDP وUnix: الحالة، العناوين، المنافذ، العمليات، المؤقتات، وعمق الطوابير. الصيغة الحصان العاملة:

# كل ما يستمع، مع العملية المالكة
sudo ss -tulpn

خيارًا خيارًا، تُقرأ هكذا: TCP (-t)، UDP (-u)، مقابس المستمع فقط (-l)، أظهر العمليات (-p)، ناتج رقمي بلا استعلامات DNS (-n). وsudo مهمة لسبب -p: بلا صلاحيات root ترى المنافذ لكن بلا أسماء عمليات للمقابس التي لا تملكها.

وسطران إضافيان يغطيان معظم العمل:

# كل الاتصالات المؤسسة من/إلى المنفذ 443، مع العمليات
sudo ss -tnp 'sport = :443 or dport = :443'

# جدول ملخص: كم مقبسًا في كل حالة
ss -s

صيغة الفلترة تلك ترقية حقيقية على منهج netstat المتمثل في “grep وتصلي”: تعمل داخل النواة فتكون تامة المطابقة لا تقريبية بالنص.

كيف تعرف أي عملية تستخدم منفذًا؟

هذا هو السبب الأشهر للمدّ يدك نحو أي من الأداتين. مع ss:

sudo ss -ltnp 'sport = :8080'

ناتج نموذجي على جهاز يشغّل خادم تطوير:

State   Recv-Q  Send-Q  Local Address:Port  Peer Address:Port  Process
LISTEN  0       511     *:8080              *:*               users:(("node",pid=214113,fd=18))

حقل users:(...) يمنحك اسم العملية ورقم PID مباشرة — لا أمر ثانٍ. وإذا كان المنفذ مشغولًا بلا عملية ظاهرة، فأنت غالبًا تنظر إلى مقبس محتجز داخل network namespace آخر (حاوية). من المضيف، شغّل sudo ss -ltnp وابحث عن المنفذ ذي عمود العملية الفارغ، ثم طابقه بـ docker ps أو ادخل الـ namespace بـ nsenter.

تفضل أداة مخصصة؟ sudo lsof -i :8080 -sTCP:LISTEN يقوم بالعمل نفسه ويعمل بشكل مطابق على macOS ومعظم BSD — ولهذا ينجو في كتيبات التشغيل. لكن على لينكس ss موجود أصلًا.

ما الفروق بين ss وnetstat؟

العمل نفسه، سباكة مختلفة: netstat يكتش _proc/net/tcp_ في فضاء المستخدم، بينما ss يستخدم netlink ليسأل النواة مباشرة — ولهذا يعيد ss النتيجة في ميلي ثوانٍ على خادم فيه 50 ألف مقبس مفتوح ولا يفعل netstat. وفي العمل اليومي، الفرق هو الخيارات. هذا الجدول الذي يستحق أن يُلصق على الشاشة:

تريد	netstat	ss
منافذ TCP مستمعة + العملية	netstat -tlpn	ss -tlpn
كل اتصالات TCP + UDP	netstat -tulpna	ss -tulpna
جدول التوجيه	netstat -r	ip route
إحصاءات الواجهات	netstat -i	ip -s link
ملخص مقابس النواة	—	ss -s
فلترة بالمنفذ داخل النواة	—	ss -tnp 'sport = :22'

لاحظ أن الصفين الأولين متطابقان: بحظ سعيد، تلتقي الخيارات القصيرة لـ ss مع netstat في الحالات الشائعة، فتنجو الذاكرة العضلية في الانتقال. والصفوف الأخيرة حيث لا جواب عند netstat — عملتا التوجيه والواجهات انتقلتا إلى أمر ip، وصفا الملخص والفلترة لا يوجدان إلا في ss.

متى ما زلت تحتاج netstat؟

حالتان صادقتان. الأولى قابلية النقل: في أسطول مختلط من أجهزة لينكس أو AIX أو BSD قديمة، صياغة netstat هي الوحيدة الموجودة في كل مكان. والثانية استمرارية الذاكرة العضلية في كتيبات تشغيل قديمة — إذا قال الكتيب netstat -tlpn وكانت net-tools مثبتة على الجهاز، فسيبقى الأمر يعمل جيدًا.

غير ذلك، عُد إلى ss وحدّث الكتيب. ومرافق مفيد عندما تعيد كتابة تلك الكتيبات على خادم هي ورقة أوامر journalctl التي تتآزر طبيعيًا مع فحص المنافذ عندما تشخّص خدمة ترفض الإقلاع: /en/blog/2026-09-02/journalctl-cheat-sheet.

لماذا يظهر أن الأمر ss غير موجود؟

لأنك إما على توزيعة عتيقة جدًا (ما قبل 2007، قبل أن يصبح iproute2 معيارًا) أو — وهذا الأرجح بكثير — أنك لست على لينكس أصلًا. ss ليس أمر macOS؛ macOS يشحن lsof وnetstat بلا ss. والشيء نفسه في BSD غالبًا. وعلى ويندوز استخدم netstat -ano أو Get-NetTCPConnection من PowerShell.

وإن كنت فعلًا على لينكس وss غائب، فثبّت iproute2:

sudo apt install iproute2    # Debian/Ubuntu
sudo dnf install iproute2    # Fedora/RHEL

الجواب في 30 ثانية

ss على netstat في لينكس، كل مرة: مثبت مسبقًا، أسرع، ويرشّح داخل النواة. netstat -tlpn تصبح ss -tlpn، وصيد العمليات يصبح sudo ss -ltnp 'sport = :PORT'، وجداول التوجيه أصبحت ملك ip route. أبقِ netstat للسكربتات العابرة للمنصات وللذاكرة العضلية القديمة؛ وأبقِ هذه الصفحة لجدول المطابقة.