ss vs netstat: Hangi Port Komutunu Kullanmalı?

ss kullanın — her modern Linux dağıtımında güncel standart odur ve netstat orada eski teknolojidir. Ubuntu, Fedora ve Debian’da netstat ikili dosyası artık isteğe bağlı bir net-tools paketiyle gelirken, ss iproute2 içinde her dağıtımda hazır gelir. ss, soket istatistiklerini çekirdekten doğrudan okuduğu için yoğun sunucularda ayrıca daha hızlıdır; netstat ise _/proc_ altını dosya dosya gezer. Asıl püf noktası sözdizimidir: -tulpn her yerde aynı şeyi ifade etmez. Bu rehberde tam flag eşleştirmesi, ezberlenmeye değer komutlar ve gece 2’de olayın ortasındayken aklınıza gelen soruların cevapları var.

netstat kullanımdan kalktı mı?

Linux’ta fiilen evet. net-tools paketi — netstat, ifconfig ve route dahil — yıllardır modern çekirdek özelliklerini takip etmiyor ve hiçbir büyük dağıtımda varsayılan olarak kurulmuyor. Hâlâ vardır, hâlâ çalışır, kaldırılacak bir şey de yoktur; ama yeni özellikler yalnızca iproute2‘ye düşer (ss ve ip‘nin arkasındaki paket).

Üç somut sonuç:

1. Taze kurulumlarda yok. Standart bir Ubuntu 24.04 ya da Fedora sunucusunda, net-tools‘u elle kurana dek netstat yoktur. İnsanların netstat muadilini aramasının sebebi budur — ikili dosya basitçe yok olmuştur.
2. Modern soket bilgisi yok. netstat, TCP fast open, alt akış düzeyi soket istatistikleri ve cgroup soket atıfları gibi özelliklerden önce gelir. ss bunları yerli olarak raporlar.
3. Windows istisnası. Windows’ta netstat sağ salimdir — orada bir PID’i dinlenen porta eşlemek için hâlâ standart yöntem netstat -ano‘dur. Kullanımdan kalkma yalnızca Linux hikâyesidir.

Linux’taki ss komutu nedir?

ss “socket statistics” demektir. Çekirdeğin her TCP, UDP ve Unix soketine bakışını döker: durum, adresler, portlar, süreçler, zamanlayıcılar ve kuyruk derinlikleri. İş atının biçimi:

# Dinlenen her şey, sahibi süreçle birlikte
sudo ss -tulpn

Flag flag okunuşu: TCP (-t), UDP (-u), yalnızca dinleyen soketler (-l), süreçleri göster (-p), sayısal çıktı — DNS sorgusu yok (-n). -p için sudo önemlidir: root olmadan portları görürsünüz ama sahibi olmadığınız soketlerin süreç adlarını alamazsınız.

İşin çoğunu karşılayan iki tek satırlık daha:

# Port 443'e/443'ten tüm kurulmuş bağlantılar, süreçlerle
sudo ss -tnp 'sport = :443 or dport = :443'

# Özet tablo: her durumda kaç soket var
ss -s

Bu filtre söz dizimi, netstat’ın “grep’leyip dua et” yaklaşımına karşı gerçek bir yükseltme — çekirdeğin içinde çalıştığı için tam eşleşme yapar, metin karşılaştırmasıyla değil.

Bir portu hangi süreç kullanıyor, nasıl bulursun?

İki araca da başvurulmasının en yaygın sebebi budur. ss ile:

sudo ss -ltnp 'sport = :8080'

Bir makinede dev server çalışırken örnek çıktı:

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

users:(...) alanı size süreç adını ve PID’i doğrudan verir — ikinci bir komut gerekmez. Port meşgulse ama hiçbir süreç görünmüyorsa, genellikle başka bir ağ ad alanının (konteyner) tuttuğu bir sokete bakıyorsunuzdur. Host’tan sudo ss -ltnp çalıştırıp süreç sütunu boş olan portu bulun; ardından docker ps ile eşleştirin ya da konteynerin ad alanına nsenter ile girin.

Adanmış bir araç mı tercih edersiniz? sudo lsof -i :8080 -sTCP:LISTEN aynı işi görür ve macOS’ta da çoğu BSD’de de aynı çalışır — runbook’larda hayatta kalmasının sebebi bu. Yine de Linux’ta ss çoktan oradadır.

ss ile netstat arasındaki farklar neler?

Aynı iş, farklı tesisat: netstat, _proc/net/tcp_ dosyasını kullanıcı uzayında tarar; ss ise netlink ile doğrudan çekirdeğe sorar — 50 bin açık soketli bir sunucuda ss‘in milisaniyeler içinde dönmesinin, netstat’ın dönmemesinin sebebi budur. Günlük hayattaki fark flag’lerdedir. Monitörünüze bantlanacak eşleştirme şurada:

İstediğiniz	netstat	ss
Dinleyen TCP portları + süreç	netstat -tlpn	ss -tlpn
Tüm TCP + UDP bağlantıları	netstat -tulpna	ss -tulpna
Yönlendirme tablosu	netstat -r	ip route
Arayüz istatistikleri	netstat -i	ip -s link
Çekirdek soket özeti	—	ss -s
Çekirdek içinde porta göre filtre	—	ss -tnp 'sport = :22'

Dikkat: ilk iki satır aynıdır. Şans eseri ss’nin kısa flag’leri sıradan durumlarda netstat’ınkilerle örtüşür; kas hafızası geçişten büyük ölçüde sağ çıkar. Alt satırlar, netstat’ın cevabı olmadığı yerlerdir — yönlendirme ve arayüz işleri ip komutuna taşındı; özet ve filtre satırları ise yalnızca ss‘te var.

netstat’a hâlâ ne zaman ihtiyaç duyarsın?

İki dürüst durum. Birincisi taşınabilirlik: Linux, AIX veya eski BSD makinelerinden oluşan karışık bir filoda netstat, her yerde bulunan tek söz dizimidir. İkincisi eski runbook’lardaki kas hafızası sürekliliği — runbook netstat -tlpn diyorsa ve makinede net-tools kuruluysa, gayet iyi çalışmaya devam eder.

Aksi hâlde varsayılanınız ss olsun ve runbook’u güncelleyin. Runbook’ları sunucuda yeniden yazarken yanınıza alınacak faydalı eş, başlamayan bir servisi teşhis ederken port kontrolüyle doğal olarak el ele giden journalctl cheat sheet’idir: /en/blog/2026-09-02/journalctl-cheat-sheet.

ss komutu bulunamadı hatası neden çıkar?

Çünkü ya çok eski bir dağıtımdasınız (2007 öncesi, iproute2 standart olmadan önce) ya da — çok daha muhtemel — hiç Linux’ta değilsinizdir. ss bir macOS komutu değildir; macOS lsof ve netstat ile gelir ama ss yoktur. BSD’ler için de çoğunlukla aynı şey geçerli. Windows’ta netstat -ano ya da PowerShell’in Get-NetTCPConnection‘ını kullanın.

Gerçekten Linux’tasınız ve ss eksikse, iproute2 kurun:

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

30 saniyelik cevap

Linux’ta her seferinde netstat yerine ss: hazır kuruludur, daha hızlıdır ve çekirdeğin içinde filtreleyebilir. netstat -tlpn artık ss -tlpn‘dir; süreç avı sudo ss -ltnp 'sport = :PORT' olur, yönlendirme tabloları da artık ip route‘a aittir. netstat’ı platformlar arası betikler ve eski kas hafızası için saklayın; flag eşleştirmesi için de bu sayfayı.