ss vs netstat: Dùng lệnh nào để xem port trên Linux

Hãy dùng ss — đây là chuẩn hiện hành trên mọi distro Linux hiện đại, còn netstat ở đó là legacy. Trên Ubuntu, Fedora và Debian, binary netstat giờ nằm trong gói tùy chọn net-tools, trong khi ss được đóng gói sẵn trong iproute2 và có mặt ở khắp nơi. ss cũng nhanh hơn trên server đông nối kết vì nó đọc socket statistics trực tiếp từ kernel thay vì đi dọc _/proc_ từng file một. Cái giá phải trả là cú pháp: -tulpn không mang cùng ý nghĩa ở mọi nơi, nên bài này đưa cho bạn bảng ánh xạ flag chính xác, những lệnh đáng nhớ, và lời giải cho các câu hỏi hay nổi lên giữa sự cố lúc 2 giờ sáng.

netstat có bị deprecated không?

Trên Linux, thực tế là có. Gói net-tools — nơi chứa netstat, ifconfig và route — đã nhiều năm không theo kịp tính năng kernel hiện đại và không còn được cài mặc định trên bất kỳ distro lớn nào. Nó vẫn tồn tại, vẫn chạy, và không có gì phải gỡ đi, nhưng tính năng mới chỉ đổ về iproute2 (gói đứng sau ss và ip).

Ba hệ quả thực tế:

1. Mất tích trên bản cài mới. Một server Ubuntu 24.04 hay Fedora nguyên bản không có netstat cho tới khi bạn tự tay cài net-tools. Vì vậy mới có nhiều người tìm “lệnh tương đương netstat” — binary nó đơn giản là không còn đó.
2. Không có thông tin socket hiện đại. netstat ra đời trước các tính năng như TCP fast open, thống kê socket cấp subflow, hay phân loại socket theo cgroup. ss báo cáo chúng nguyên bản.
3. Ngoại lệ Windows. Trên Windows, netstat vẫn sống khỏe — netstat -ano vẫn là cách chuẩn để ánh xạ một PID sang port đang lắng nghe ở đó. Chỉ có chuyện phía Linux mới là deprecated.

Lệnh ss trong Linux là gì?

ss là viết tắt của “socket statistics”. Nó in ra góc nhìn của kernel về mọi socket TCP, UDP và Unix: trạng thái, địa chỉ, port, process, timer và độ sâu hàng đợi. Dạng chúng ta dùng nhiều nhất:

# Mọi thứ đang lắng nghe, kèm process sở hữu
sudo ss -tulpn

Đọc từng flag một: TCP (-t), UDP (-u), chỉ socket đang lắng nghe (-l), hiện process (-p), đầu ra thuần số — không tra cứu DNS (-n). sudo là vì -p: không có root, bạn vẫn thấy port nhưng không có tên process cho những socket không thuộc về mình.

Hai lệnh một dòng nữa phủ gần hết công việc:

# Mọi kết nối established đến/đi từ port 443, kèm process
sudo ss -tnp 'sport = :443 or dport = :443'

# Bảng tổng hợp: bao nhiêu socket ở mỗi trạng thái
ss -s

Cú pháp filter đó là một nâng cấp thật sự so với kiểu grep-rồi-cầu may của netstat — nó chạy ngay trong kernel, nên chính xác tuyệt đối chứ không phải khớp văn bản.

Làm sao kiểm tra process nào đang chiếm một port?

Đây là lý do số một khiến người ta với tới một trong hai công cụ. Với ss:

sudo ss -ltnp 'sport = :8080'

Ví dụ đầu ra trên một máy đang chạy dev server:

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

Trường users:(...) đưa thẳng tên process và PID — không cần lệnh thứ hai. Nếu port đang bận mà không thấy process nào, thường bạn đang nhìn vào một socket được giữ trong network namespace khác (một container). Từ host, chạy sudo ss -ltnp và tìm port có cột process trống trơn, rồi đối chiếu bằng docker ps hoặc nsenter vào namespace của container.

Thích một công cụ chuyên trách? sudo lsof -i :8080 -sTCP:LISTEN làm đúng việc đó và hoạt động như nhau trên macOS lẫn phần lớn BSD — vì vậy nó vẫn sống sót trong các runbook. Nhưng trên Linux thì ss đã có sẵn ở đó.

ss và netstat khác nhau ở điểm nào?

Cùng một việc, đường ống khác nhau: netstat bới _proc/net/tcp_ trong userspace, còn ss dùng netlink để hỏi thẳng kernel — vì vậy ss trả kết quả tính bằng mili-giây trên server đang mở 50k socket, còn netstat thì không. Còn xét hằng ngày, sự khác biệt nằm ở các flag. Đây là bảng ánh xạ đáng dán lên màn hình:

Bạn muốn	netstat	ss
Các port TCP đang lắng nghe + process	netstat -tlpn	ss -tlpn
Mọi kết nối TCP + UDP	netstat -tulpna	ss -tulpna
Bảng định tuyến	netstat -r	ip route
Thống kê interface	netstat -i	ip -s link
Tổng hợp socket từ kernel	—	ss -s
Lọc theo port ngay trong kernel	—	ss -tnp 'sport = :22'

Để ý hai hàng đầu tiên giống hệt nhau: do may mắn, các flag ngắn của ss trùng với của netstat ở những trường hợp thông dụng, nên phần lớn nhớ cơ bắp sống sót qua cuộc chuyển dịch. Các hàng cuối mới là chỗ netstat bó tay — việc định tuyến và interface đã chuyển sang lệnh ip, còn hai hàng tổng hợp và lọc chỉ tồn tại ở ss.

Khi nào vẫn nên dùng netstat?

Hai trường hợp, nói thật. Thứ nhất là tính di động: trên một đội máy trộn lẫn Linux, AIX hay các BSD già, netstat là cú pháp duy nhất hiện diện ở mọi nơi. Thứ hai là giữ nguyên nhớ cơ bắp trong các runbook cũ — nếu runbook ghi netstat -tlpn và máy đó có cài net-tools, lệnh vẫn chạy ngon lành.

Còn lại, mặc định dùng ss và cập nhật lại runbook. Một người bạn đồng hành hữu ích khi bạn viết lại những runbook đó trên server là cheat sheet journalctl, vốn ghép rất tự nhiên với việc kiểm tra port khi bạn đang chẩn đoán một service không chịu khởi động: /en/blog/2026-09-02/journalctl-cheat-sheet.

Vì sao lệnh ss không tìm thấy?

Vì hoặc bạn đang ở trên một distro rất già (thời tiền-2007, trước khi iproute2 thành tiêu chuẩn), hoặc — khả năng cao hơn xa — bạn không hề ở trên Linux. ss không phải lệnh của macOS; macOS có lsof và netstat nhưng không có ss. Các BSD phần lớn cũng vậy. Trên Windows, hãy dùng netstat -ano hoặc Get-NetTCPConnection của PowerShell.

Nếu bạn thực sự đang trên Linux mà ss vắng mặt, cài iproute2:

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

Câu trả lời trong 30 giây

ss hơn netstat trên Linux, mọi lần: nó cài sẵn, nhanh hơn, và filter được ngay trong kernel. netstat -tlpn đổi thành ss -tlpn, săn process đổi thành sudo ss -ltnp 'sport = :PORT', còn bảng định tuyến giờ thuộc về ip route. Giữ netstat cho script đa nền tảng và nhớ cơ bắp cũ; giữ trang này cho bảng ánh xạ flag.