ss vs netstat: Linux में पोर्ट वाला सही कमांड कौन-सा?

ss इस्तेमाल करें — हर आधुनिक Linux distro पर यही मौजूदा स्टैंडर्ड है, और netstat वहाँ अब legacy है। Ubuntu, Fedora और Debian पर netstat binary अब optional net-tools package में आता है, जबकि ss iproute2 का हिस्सा है और हर जगह पहले से मौजूद रहता है। ss व्यस्त servers पर तेज़ भी है, क्योंकि वह socket statistics सीधे kernel से पढ़ता है, _/proc_ को फ़ाइल दर फ़ाइल नहीं छानता। बस अड़चन syntax की है: -tulpn हर जगह एक ही मतलब नहीं रखता, इसलिए इस गाइड में exact flag mapping, याद रखने लायक़ कमांड, और रात 2 बजे mid-incident समय पर उठने वाले सवालों के जवाब मिलेंगे।

क्या netstat deprecated है?

Linux पर, असरदार तौर पर हाँ। net-tools package — जिसमें netstat, ifconfig और route आते हैं — सालों से आधुनिक kernel features का पीछा नहीं कर रहा, और किसी भी बड़े distribution पर अब डिफ़ॉल्ट रूप से इंस्टॉल नहीं होता। वह अब भी मौजूद है, अब भी चलता है, और उसे अनइंस्टॉल करने जैसी कोई बात नहीं — पर नए features सिर्फ़ iproute2 (ss और ip के पीछे वाला package) में आते हैं।

व्यवहार में तीन नतीजे:

1. नए installs पर ग़ायब। डिफ़ॉल्ट Ubuntu 24.04 या Fedora server में netstat तब तक नहीं होता जब तक आप net-tools हाथ से इंस्टॉल न करें। इसीलिए इतने लोग netstat का equivalent खोजते हैं — binary वहीं से ही ग़ायब है।
2. आधुनिक socket जानकारी नहीं। netstat इन features से पुराना है — TCP fast open, subflow-level socket stats, cgroup socket attribution। ss इन सबको अपने आप से ही दिखाता है।
3. Windows वाला अपवाद। Windows पर netstat पूरी तरह ज़िंदा है — PID को listening port से जोड़ने का स्टैंडर्ड तरीक़ा वहाँ आज भी netstat -ano है। Deprecated सिर्फ़ Linux की कहानी है।

Linux में ss कमांड क्या है?

ss का मतलब है “socket statistics”। यह हर TCP, UDP और Unix socket पर kernel की नज़र उंडेल देता है: state, addresses, ports, processes, timers और queue depths। सबसे ज़्यादा काम आने वाला रूप यह है:

# सब कुछ जो listen कर रहा है, मालिक process के साथ
sudo ss -tulpn

Flag दर flag इसका मतलब: TCP (-t), UDP (-u), सिर्फ़ listening sockets (-l), processes दिखाओ (-p), numeric आउटपुट — DNS lookups नहीं (-n)। -p के लिए sudo ज़रूरी है: बिना root के पोर्ट दिख जाते हैं, पर जो sockets आपके अपने नहीं हैं उनके process नाम नहीं मिलते।

बाक़ी ज़्यादातर काम दो और one-liners निपटा देते हैं:

# पोर्ट 443 के आने-जाने वाले सारे established connections, processes के साथ
sudo ss -tnp 'sport = :443 or dport = :443'

# सारांश तालिका: हर state में कितने sockets
ss -s

यह filter syntax netstat के “grep करो और दुआ करो” वाले तरीके से सचमुच एक क़दम आगे है — यह kernel के भीतर चलता है, इसलिए टेक्स्ट मिलाकर नहीं, exact जवाब मिलता है।

किसी पोर्ट कौन-सा process इस्तेमाल कर रहा है, कैसे पता करें?

दोनों में से किसी भी टूल तक पहुँचने की सबसे आम वजह यही है। ss से:

sudo ss -ltnp 'sport = :8080'

dev server चला रही machine पर नमूना आउटपुट:

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

users:(...) field process का नाम और PID सीधे दे देता है — दूसरी कमांड की ज़रूरत नहीं। अगर पोर्ट व्यस्त है पर कोई process नहीं दिखता, तो आमतौर पर आप किसी दूसरे network namespace (एक container) के कब्ज़े वाले socket को देख रहे होते हैं। Host से sudo ss -ltnp चलाएँ, ख़ाली process column वाला पोर्ट ढूँढें, फिर उसे docker ps से मिलाएँ या nsenter से container के namespace में उतर जाएँ।

समर्पित टूल पसंद है? sudo lsof -i :8080 -sTCP:LISTEN यही काम करता है और macOS तथा ज़्यादातर BSDs पर वैसा ही चलता है — इसीलिए वह runbooks में टिका हुआ है। पर Linux पर, तो ss पहले से मौजूद है।

ss और netstat में फ़र्क़ क्या है?

काम एक है, नालियाँ अलग: netstat userspace में _proc/net/tcp_ खंगालता है, जबकि ss netlink से सीधे kernel से पूछ लेता है — इसीलिए 50k खुले sockets वाले server पर ss मिलीसेकंड में जवाब देता है और netstat नहीं देता। रोज़मर्रा में फ़र्क़ flags का है। यह mapping मॉनिटर पर टेप करने लायक़ है:

आपको चाहिए	netstat	ss
Listen कर रहे TCP पोर्ट + process	netstat -tlpn	ss -tlpn
सारे TCP + UDP connections	netstat -tulpna	ss -tulpna
Routing table	netstat -r	ip route
Interface आँकड़े	netstat -i	ip -s link
Kernel socket सारांश	—	ss -s
पोर्ट से kernel के भीतर फ़िल्टर	—	ss -tnp 'sport = :22'

ध्यान दें, पहली दो पंक्तियाँ एक जैसी हैं: क़िस्मत से ss के short flags आम मामलों में netstat के साथ मिल जाते हैं, इसलिए muscle memory दाँव पर ज़्यादातर बच जाती है। नीचे की पंक्तियाँ वहाँ हैं जहाँ netstat का कोई जवाब नहीं — routing और interface का काम ip कमांड के पास चला गया है, और summary/filter वाली पंक्तियाँ सिर्फ़ ss में मौजूद हैं।

netstat का इस्तेमाल अब भी कब करना चाहिए?

ईमानदारी से दो ही मामले। पहला, portability: Linux, AIX या पुराने BSD machines के मिश्रित fleet में netstat ही वह एक syntax है जो हर जगह मौजूद है। दूसरा, पुराने runbooks में muscle memory की निरंतरता — अगर runbook कहता है netstat -tlpn और machine पर net-tools लगे हैं, तो वह आज भी ठीक चलता है।

बाक़ी हालत में ss को डिफ़ॉल्ट बनाएँ और runbook अपडेट कर दें। Server पर वे runbooks दोबारा लिखते समय journalctl चीट शीट साथ में काम आती है — service जो स्टार्ट ही नहीं हो रही, उसकी जाँच के साथ पोर्ट चेक स्वाभाविक रूप से जुड़ते हैं: /en/blog/2026-09-02/journalctl-cheat-sheet।

ss कमांड not found क्यों आता है?

क्योंकि या तो आप बहुत पुराने distro पर हैं (2007 से पहले के दौर का, iproute2 के स्टैंडर्ड बनने से पहले का), या — कहीं ज़्यादा संभावना यह है — आप Linux पर हैं ही नहीं। ss macOS की कमांड नहीं है; macOS lsof और netstat देता है, ss नहीं। ज़्यादातर BSDs की भी यही हालत। Windows पर netstat -ano या PowerShell का Get-NetTCPConnection इस्तेमाल करें।

अगर आप सचमुच Linux पर हैं और ss ग़ायब है, तो iproute2 इंस्टॉल करें:

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

30 सेकंड का जवाब

Linux पर हर बार netstat से ऊपर ss: वह पहले से इंस्टॉल है, तेज़ है, और kernel के भीतर फ़िल्टर कर सकता है। netstat -tlpn बन जाता है ss -tlpn, process की खोज बन जाती है sudo ss -ltnp 'sport = :PORT', और routing table अब ip route का इलाक़ा है। netstat को cross-platform scripts और पुरानी muscle memory के लिए रखें; flag mapping के लिए यह पन्ना रखें।