ss vs netstat: คำสั่งดูพอร์ตบน Linux ควรใช้ตัวไหน

ใช้ ss — มันคือมาตรฐานปัจจุบันของ distro Linux สมัยใหม่ทุกตัว ส่วน netstat บนนั้นถือเป็นของเก่า บน Ubuntu, Fedora และ Debian ไฟล์ netstat ถูกแพ็กในแพ็กเกจเสริมชื่อ net-tools ขณะที่ ss มากับ iproute2 ที่ติดตั้งอยู่ทุกเครื่อง ss ยังเร็วกว่าบนเซิร์ฟเวอร์ที่งานแน่น เพราะมันอ่านสถิติซ็อกเกตจากเคอร์เนลโดยตรง ไม่ต้องเดินไล่ไฟล์ใน _/proc_ ทีละไฟล์ จุดกีดขวางคือไวยากรณ์: -tulpn ไม่ได้หมายถึงสิ่งเดียวกันทุกที่ บทความนี้จึงมีตารางแปลง flag แบบเป๊ะ คำสั่งที่ควรจำ และคำตอบของคำถามที่โผล่ตอนคุณอยู่กลางเหตุการณ์เวลาตีสอง

netstat เลิกใช้แล้วหรือยัง?

บน Linux ตอบตามปฏิบัติว่าใช่ แพ็กเกจ net-tools — ที่มี netstat, ifconfig และ route — ไม่ได้ตามฟีเจอร์เคอร์เนลสมัยใหม่มาหลายปี และไม่ได้ถูกติดตั้งเป็นค่าเริ่มต้นใน distro ใหญ่อีกต่อไป มันยังมีอยู่ ยังรันได้ ไม่มีอะไรต้องถอน แต่ฟีเจอร์ใหม่จะไปลงที่ iproute2 (แพ็กเกจเบื้องหลัง ss และ ip) เท่านั้น

ผลตามมาสามข้อ:

1. ไม่มีในเครื่องที่ติดตั้งใหม่ เซิร์ฟเวอร์ Ubuntu 24.04 หรือ Fedora แบบค่าเริ่มต้นไม่มี netstat จนกว่าคุณจะติดตั้ง net-tools เอง นี่คือเหตุผลที่หลายคนค้นหาคำสั่งเทียบเท่า netstat — ไฟล์มันแค่ไม่มีแล้ว
2. ไม่มีข้อมูลซ็อกเกตยุคใหม่ netstat เกิดก่อนฟีเจอร์อย่าง TCP fast open สถิติซ็อกเกตระดับ subflow และการระบุ cgroup ของซ็อกเกต ss รายงานสิ่งเหล่านี้ได้ตั้งแต่แกนของมันเอง
3. ข้อยกเว้นของ Windows บน Windows netstat ยังมีชีวิตและแข็งแรง — netstat -ano ยังเป็นวิธีมาตรฐานในการผูก PID เข้ากับพอร์ตที่รอรับการเชื่อมต่อ เรื่องเลิกใช้มีเฉพาะฝั่ง Linux เท่านั้น

คำสั่ง ss บน Linux คืออะไร?

ss ย่อมาจาก “socket statistics” มันเททัศนะของเคอร์เนลออกมาทั้งหมดสำหรับ TCP, UDP และ Unix socket ทุกตัว: สถานะ ที่อยู่ พอร์ต โปรเซส ไทเมอร์ และความลึกของคิว รูปแบบม้างานคือ:

# ทุกอย่างที่รอรับการเชื่อมต่อ พร้อมโปรเซสเจ้าของ
sudo ss -tulpn

แปลงทีละ flag: 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'

ตัวอย่างผลลัพธ์บนเครื่องที่รัน dev server:

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 อื่น (คอนเทนเนอร์) จากเครื่อง host ให้รัน sudo ss -ltnp แล้วหาพอร์ตที่คอลัมน์โปรเซสว่างเปล่า จากนั้นเทียบกับ docker ps หรือใช้ nsenter เข้าไปใน namespace ของคอนเทนเนอร์

ชอบเครื่องมือเฉพาะทางกว่า? sudo lsof -i :8080 -sTCP:LISTEN ทำงานเดียวกัน และให้ผลเหมือนกันบน macOS กับ BSD ส่วนใหญ่ จึงยังอยู่ในรันบุ๊ก แต่บน Linux ss มีอยู่แล้ว

ss กับ netstat ต่างกันตรงไหน?

งานเดียวกัน ท่อประปาต่างกัน: netstat ขูดข้อมูลจาก _proc/net/tcp_ ใน userspace ขณะที่ ss ใช้ netlink ถามเคอร์เนลตรง ๆ — เพราะงั้น ss ตอบในไม่กี่มิลลิวินาทีบนเซิร์ฟเวอร์ที่มีซ็อกเกตเปิด 50,000 ตัว แต่ netstat ทำไม่ได้ ในการใช้งานจริง ความต่างคือเรื่อง flag นี่คือตารางที่ควรแปะไว้ที่จอ:

ต้องการ	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'

สังเกตว่าสองแถวแรกเหมือนกันเป๊ะ: โดยโชคช่วย flag ตัวสั้นของ ss ตรงกับ netstat ในกรณีทั่วไป ความจำกล้ามเนื้อจึงอยู่รอดในการย้ายถิ่นส่วนใหญ่ ส่วนแถวล่างคือจุดที่ netstat ไม่มีคำตอบ — งานเราติ้งกับอินเทอร์เฟซย้ายไปอยู่กับคำสั่ง ip และแถวสรุปกับกรองมีอยู่ใน ss เท่านั้น

กรณีไหนที่ยังควรใช้ netstat?

สองกรณีอย่างซื่อสัตย์ หนึ่ง คือ ความสามารถพกพา: ในฟาร์มเครื่องที่ผสม Linux, AIX หรือ BSD รุ่นเก่า netstat เป็นไวยากรณ์เดียวที่มีอยู่ทุกเครื่อง สอง คือ ความต่อเนื่องของความจำกล้ามเนื้อ ในรันบุ๊กรุ่นเก่า — ถ้ารันบุ๊กเขียนว่า netstat -tlpn และเครื่องมี net-tools อยู่ มันก็ยังทำงานได้ดี

นอกจากนั้น ให้เริ่มจาก ss แล้วอัปเดตรันบุ๊กตาม เพื่อนคู่ใจช่วงที่คุณกำลังเขียนรันบุ๊กใหม่บนเซิร์ฟเวอร์คือ สรุปคำสั่ง journalctl ที่จับคู่กับการเช็กพอร์ตได้อย่างเป็นธรรมชาติ เวลาคุณกำลังวินิจฉัย service ที่ไม่ยอมสตาร์ต: /en/blog/2026-09-02/journalctl-cheat-sheet

ทำไมถึงบอกว่าไม่พบคำสั่ง ss?

เพราะคุณอยู่บน distro เก่าแก่มาก (ยุคก่อน 2007 ก่อนที่ iproute2 จะเป็นมาตรฐาน) หรือ — ที่เป็นไปได้มากกว่า — คุณไม่ได้อยู่บน Linux เลย ss ไม่ใช่คำสั่งของ macOS: macOS มาพร้อม lsof กับ netstat แต่ไม่มี ss ฝั่ง BSD ก็ส่วนใหญ่เช่นกัน บน Windows ให้ใช้ netstat -ano หรือ Get-NetTCPConnection ของ PowerShell

ถ้าคุณอยู่บน Linux จริง ๆ และ ss หายไป ติดตั้ง iproute2:

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

คำตอบฉบับ 30 วินาที

ss เหนือกว่า netstat บน Linux ทุกครั้ง: มันติดตั้งมาก่อน เร็วกว่า และกรองได้ในเคอร์เนล netstat -tlpn กลายเป็น ss -tlpn การล่าโปรเซสกลายเป็น sudo ss -ltnp 'sport = :PORT' และตารางเราติ้งเป็นของ ip route ไปแล้ว เก็บ netstat ไว้สำหรับสคริปต์ข้ามแพลตฟอร์มและความจำกล้ามเนื้อเก่า ๆ เก็บหน้านี้ไว้สำหรับตารางแปลง flag