Sunucu Trafiğim Nereye Gidiyor? vnstat, iftop ve nethogs ile Bulma

Ayın 12'si ve sağlayıcıdan bir uyarı e-postası geldi: aylık trafik kotanızın %85'i dolmuş. Panele giriyorsunuz, grafiğe bakıyorsunuz — geçen ay 900 GB kullanmışsınız, bu ay 12 günde 3,4 TB. Grafikte belirgin bir sıçrama var ama grafik size yalnızca "ne kadar" der, asla "kim" demez. Site trafiğiniz iki katına çıkmadı, yeni bir müşteri de eklemediniz.

Bu noktada yapılan en yaygın hata, doğrudan iftop kurup ekrana bakmaktır. iftop size şu anda ne olduğunu gösterir; oysa trafiği yiyen iş gece 03:00'te çalışan bir yedekleme görevi veya haftada bir gelen bir tarayıcı botu olabilir. Ekranda hiçbir şey görünmez, siz de "sorun yok galiba" dersiniz ve kota dolmaya devam eder.

Bu rehber üç aracı — vnstat, iftop, nethogs — birbirinin alternatifi olarak değil, üç ayrı soruya cevap veren üç ayrı alet olarak ele alır. Ardından gerçek bir kota aşımı senaryosunu baştan sona takip eder: önce dönemi daraltır, sonra karşı tarafı bulur, en sonunda hangi sürecin ve hangi dosyanın sorumlu olduğunu ortaya çıkarır. Sonunda yedek işi mi, bot mu, hotlink mi olduğunu ayırt edebiliyor olacaksınız.

Hangi Araç Hangi Soruya Cevap Veriyor?#

Bir trafik sorununu çözmek üç ayrı bilgi gerektirir: ne zaman, kiminle, hangi program. Tek araç üçünü birden vermez.

Doğru sıra da bu tablodaki sıradır. Önce vnstat ile olayın saatini bulursunuz; sonra o saate denk gelen bir zaman diliminde iftop ve nethogs ile canlı yakalarsınız. Olayın saatini bilmeden canlı araçlara bakmak, kaza saatini bilmeden yola çıkıp trafiği izlemeye benzer.

Kotanın nasıl hesaplandığı, "sınırsız trafik" ifadesinin gerçekte ne anlama geldiği ve gelen/giden ayrımı konusunda temel eksikse önce bant genişliği nedir yazısını okumanızı öneririm; buradaki ölçümleri yorumlarken işinize yarayacak.

vnstat ile Geçmişe Dönük Trafik Raporu#

vnstat bir arka plan servisi olarak çalışır, çekirdeğin arayüz sayaçlarını düzenli aralıklarla okur ve kendi veritabanına yazar. Paket içeriğine bakmaz, bu yüzden neredeyse hiç kaynak tüketmez ve sürekli açık bırakılabilir. Karşılığında size sağlayıcının panelindekiyle karşılaştırabileceğiniz saatlik, günlük ve aylık bir tablo verir.

Kurulum ve İlk Yapılandırma#

# Debian / Ubuntu
apt update && apt install -y vnstat

# AlmaLinux / Rocky / RHEL (EPEL gerekir)
dnf install -y epel-release && dnf install -y vnstat

# Servisi başlat ve açılışta etkinleştir
systemctl enable --now vnstat
systemctl status vnstat --no-pager

# Hangi arayüzler izleniyor?
vnstat --iflist

Kurulumdan sonra en az bir saat beklemeniz gerekir; vnstat yalnızca kendi çalıştığı süredeki veriyi bilir, geçmişi geriye dönük üretemez. Bu yüzden vnstat'ı sorun çıktığında değil, sunucuyu kurduğunuz gün kurun. Yeni bir sunucunun ilk yapılacaklar listesinde, güvenlik duvarı ve SSH sıkılaştırmasıyla aynı satırda yer almalıdır.

Raporları Okumak#

# Aylık özet - kota takibinin ana ekranı
vnstat -m

# Günlük döküm - hangi günler sıçramış?
vnstat -d

# Saatlik döküm - sıçrayan günün hangi saati?
vnstat -h

# En yoğun günler sıralı liste
vnstat -t

# Canlı akış (Ctrl+C ile çıkılır)
vnstat -l -i eth0

# Başka bir araca aktarmak için
vnstat --json m

Okurken üç şeye dikkat edin. Birincisi, rx gelen (indirilen), tx giden (yüklenen) trafiktir; çoğu sağlayıcı kotayı giden trafik üzerinden ya da ikisinin toplamı üzerinden sayar, sözleşmenizde hangisi yazıyorsa ona bakın. İkincisi, vnstat arayüz üzerindeki ham trafiği ölçer; sağlayıcı paneliyle %5-10 fark normaldir çünkü ölçüm noktaları farklıdır. Üçüncüsü, birden fazla arayüz varsa (eth0, ens3, docker0, lo) yalnızca gerçek dış arayüzü hesaba katın — docker0 üzerindeki trafik sunucudan dışarı çıkmaz.

vnstat -d çıktısında tek bir günde diğerlerinin beş katı trafik görüyorsanız işiniz kolaylaştı: vnstat -h ile o günün saatini bulun. Sıçrama her gece aynı saatte tekrar ediyorsa şüpheli neredeyse kesin olarak zamanlanmış bir görevdir. Trafik gün içine yayılmış ve iş saatlerinde yoğunlaşıyorsa, kaynak büyük ihtimalle web sunucunuzdur.

iftop ile Şu Anda Hangi IP ile Konuşuyorsunuz?#

iftop, arayüzden geçen paketleri dinleyip trafiği karşı taraf IP'sine göre sıralar. Size "en çok kiminle konuşuyorum" sorusunun cevabını verir. Süreç bilgisi vermez; onun için bir sonraki bölüme geçeceksiniz.

apt install -y iftop      # veya: dnf install -y iftop

# İsim çözümlemesi kapalı, port numaraları görünür halde
iftop -i eth0 -nNP

# Sadece HTTPS trafiğini izle
iftop -i eth0 -nNP -f "port 443"

# Belirli bir IP ile olan trafiği izle
iftop -i eth0 -nNP -f "host 203.0.113.45"

# Ekran başında beklemeden 10 saniyelik metin raporu al
iftop -i eth0 -nNP -t -s 10 -L 20

Son satır özellikle kullanışlıdır: -t metin modudur, -s 10 on saniye ölçüp çıkar, -L 20 en üstteki 20 satırı yazdırır. Bu komutu cron ile yoğun saatlerde çalıştırıp çıktıyı bir dosyaya yazdırarak "gece 03:00'te kiminle konuşuluyor" sorusunu, uykunuzu bölmeden cevaplayabilirsiniz.

Ekranı okurken: ortadaki sütunlar sırasıyla son 2, 10 ve 40 saniyelik ortalamalardır; sağdaki TX/RX/TOTAL satırları ise ölçüm başladığından beri toplamdır. -n ve -N bayraklarını kullanmak önemlidir — ters DNS çözümlemesi hem ekranı yavaşlatır hem de yoğun trafikte kendi başına gecikme yaratır.

Gördüğünüz IP'nin kime ait olduğunu anlamak için whois yeterlidir; bir bulut sağlayıcısına veya arama motoruna aitse bot, kendi yedekleme sunucunuza aitse yedek işi, tek bir ev abonesine aitse büyük ihtimalle bir indirme veya hotlink söz konusudur:

whois 203.0.113.45 | grep -iE 'orgname|netname|country|descr'

Karşı tarafa giden yolun sağlıklı olup olmadığını da merak ediyorsanız ping, traceroute ve mtr ile ağ tanılama yazısındaki yöntemler bu noktada devreye girer.

nethogs ile Hangi Süreç Trafiği Yiyor?#

iftop size karşı tarafı gösterir, nethogs ise kendi tarafınızı: hangi PID ve hangi program bant genişliğini tüketiyor. top komutunun CPU için yaptığını ağ için yapar.

apt install -y nethogs    # veya: dnf install -y nethogs

# Temel kullanım (root gerekir)
nethogs eth0

# Toplamı MB cinsinden göster
nethogs -v 3 eth0

# Yenileme aralığını 2 saniye yap
nethogs -d 2 eth0

Ekrandayken m tuşuyla birim (KB/s, KB, MB) değiştirir, r ile alınan, s ile gönderilen trafiğe göre sıralar, q ile çıkarsınız. Çıktıda program yolunu ve kullanıcıyı birlikte görürsünüz: /usr/sbin/nginx, /usr/bin/rsync, /usr/bin/php-fpm8.2 gibi. Bu satır çoğu zaman soruşturmayı bitirir.

nethogs'un iki sınırı vardır ve ikisini de bilmek gerekir. Birincisi, çok kısa ömürlü süreçleri (birkaç saniyede açılıp kapanan bir curl) kaçırabilir. İkincisi, konteyner içindeki süreçleri host'tan bakınca beklediğiniz isimle göstermeyebilir. Bu durumlarda ss ile açık bağlantılara doğrudan bakmak daha güvenilirdir:

# Kurulu TCP bağlantıları, süreç adıyla birlikte
ss -tnp state established

# Hangi uzak IP'den kaç bağlantı var? (saldırı/bot tespitinde çok işe yarar)
ss -tn state established | awk '{print $4}' | cut -d: -f1 | sort | uniq -c | sort -rn | head -15

# Soket özeti
ss -s

Süreçleri kaynak tüketimine göre yorumlama konusunda daha rahat olmak isterseniz ps, top ve htop ile süreç izleme yazısı bu araçları tamamlar.

Kota Aşan Sunucuyu Adım Adım Teşhis Etmek#

Şimdi baştaki senaryoya dönelim: 12 günde 3,4 TB. Sıra şu şekilde işler.

1. Dönemi daraltın. vnstat -d ile hangi günlerin anormal olduğunu, vnstat -h ile o günün hangi saatinde sıçradığını bulun. Diyelim ki her gece 03:00-04:00 arasında yaklaşık 90 GB giden trafik var.

2. O saatte ne çalışıyor bakın. Canlı yakalamayı beklemeden zamanlanmış görevlere bakmak çoğu zaman yeterlidir:

# Sistem ve kullanıcı cron görevleri
crontab -l
ls -l /etc/cron.d/ /etc/cron.daily/
grep -rE '^[^#]' /etc/cron.d/ 2>/dev/null

# systemd zamanlayıcıları ve bir sonraki çalışma zamanları
systemctl list-timers --all --no-pager

3. Sonraki gece canlı ölçüm alın. Şüpheli saatte otomatik çalışacak kısa bir kayıt bırakın:

# 03:00'te başlayıp 5 dakika ölçen bir cron satırı
0 3 * * * /usr/sbin/iftop -i eth0 -nNP -t -s 300 -L 25 > /var/log/iftop-gece.log 2>&1

4. Süreci doğrulayın. Ölçüm sırasında nethogs -v 3 eth0 çıktısını da bir dosyaya alın veya o saatte SSH ile bağlanıp bakın.

5. Kaynağı web sunucusuna kadar takip edin. Sorumlu nginx veya apache çıktıysa cevap erişim günlüklerinde yatıyordur. Aşağıdaki üç komut, standart "combined" log biçiminde çalışır ve trafiği kimin/neyin yediğini doğrudan MB cinsinden verir:

# En çok bayt indiren IP'ler
awk '{b[$1]+=$10} END {for (i in b) printf "%10.1f MB  %s\n", b[i]/1048576, i}' \
  /var/log/nginx/access.log | sort -rn | head -20

# En çok bayt üreten URL'ler
awk '{b[$7]+=$10} END {for (u in b) printf "%10.1f MB  %s\n", b[u]/1048576, u}' \
  /var/log/nginx/access.log | sort -rn | head -20

# En çok bayt indiren tarayıcı/bot kimlikleri
awk -F'"' '{split($3,a," "); ua[$6]+=a[2]} END {for (u in ua) printf "%10.1f MB  %s\n", ua[u]/1048576, u}' \
  /var/log/nginx/access.log | sort -rn | head -15

Bu üç çıktı yan yana konduğunda tablo neredeyse her zaman netleşir. Günlükler döndürülmüşse zcat access.log.*.gz | awk ... biçiminde eski dosyaları da kapsayın.

Şüpheli 1: Kendi Yedekleme İşiniz#

Sunucu yöneticilerinin en sık gözden kaçırdığı kalem budur, çünkü "trafik" denince akla dışarıdan gelen ziyaretçi gelir. Oysa her gece dışarıya tam yedek gönderen bir görev, 60 GB'lık bir sunucuda tek başına aylık 1,8 TB giden trafik üretir.

Belirtileri nettir: sıçrama her gün aynı saatte olur, iftop çıktısında karşı taraf tek bir IP'dir ve whois sonucu bir depolama sağlayıcısı ya da kendi ikinci sunucunuzdur, nethogs satırında rsync, restic, borg, tar veya mysqldump görünür.

Çözüm yedeklemeyi durdurmak değil, artımlı (incremental) hale getirmek ve hızını sınırlamaktır:

# rsync ile hız sınırı (KB/s cinsinden; 5000 ≈ 5 MB/s)
rsync -az --bwlimit=5000 --delete /var/www/ [email protected]:/yedek/www/

# Yalnızca değişenleri gönder, sıkıştırarak aktar
rsync -az --partial --info=progress2 /var/www/ [email protected]:/yedek/www/

Her gece tam yedek yerine haftada bir tam, diğer günler artımlı yedek almak trafiği tipik olarak %90'ın üzerinde azaltır. Yöntem ve seçenekler için rsync ile yedekleme yazısı doğrudan uygulanabilir bir başlangıç sunar.

Şüpheli 2: Bot ve Tarayıcı Trafiği#

Belirtisi, trafiğin gün içine yayılmış olması ve nethogs çıktısında web sunucusunun tepede durmasıdır. Kesin teşhis, yukarıdaki user-agent sorgusundadır: listenin başında AhrefsBot, SemrushBot, MJ12bot, Bytespider gibi isimler ya da hiç user-agent göndermeyen - satırı varsa suçlu bulundu demektir.

robots.txt dosyasına yazacağınız Crawl-delay ve Disallow satırları iyi niyetli tarayıcıları yavaşlatır ama bağlayıcı değildir; kuralı görmezden gelen botlar için sunucu tarafında bir kural gerekir:

# /etc/nginx/conf.d/bot.conf - kimliğe göre engelleme
map $http_user_agent $kotu_bot {
    default            0;
    ~*MJ12bot          1;
    ~*Bytespider       1;
    ~*SemrushBot       1;
}

server {
    if ($kotu_bot) { return 429; }

    # İstek oranını sınırla
    limit_req_zone $binary_remote_addr zone=genel:10m rate=20r/s;
}

İstek seli kimlikten bağımsız, çok sayıda IP'den ve düzensiz aralıklarla geliyorsa artık bot değil saldırı ihtimalini değerlendirin: bir botun amacı içeriği okumaktır, saldırının amacı sunucuyu meşgul etmektir ve ikisi log'da farklı desen bırakır.

Şüpheli 3: Hotlink ve Büyük Dosya İndirmeleri#

Üçüncü ve en sinsi kalem budur. URL bazlı raporda tek bir dosya — bir PDF katalog, bir video, yüksek çözünürlüklü bir görsel — diğerlerinin toplamından fazla bayt üretiyorsa iki ihtimal vardır: ya dosya çok popülerdir ya da başka bir site onu doğrudan sizin sunucunuzdan gösteriyordur. İkincisine hotlink denir ve faturayı siz ödersiniz.

Ayrım referer sütunundadır:

# Hangi siteler sizin dosyalarınızı çağırıyor, kaç MB tüketiyorlar?
awk -F'"' '{split($3,a," "); r[$4]+=a[2]} END {for (i in r) printf "%10.1f MB  %s\n", r[i]/1048576, i}' \
  /var/log/nginx/access.log | sort -rn | head -20

Listede kendi alan adınız dışında bir site yüksek sıradaysa hotlink kesinleşmiştir. Nginx tarafında çözüm kısadır:

location ~* \.(jpg|jpeg|png|gif|webp|mp4|pdf|zip)$ {
    valid_referers none blocked server_names *.siteniz.com;
    if ($invalid_referer) { return 403; }

    # Büyük dosyalarda ilk 10 MB'tan sonra hızı 512 KB/s'ye düşür
    limit_rate_after 10m;
    limit_rate 512k;
}

cPanel kullanıyorsanız aynı korumayı arayüzden birkaç tıkla açabilirsiniz; adımları cPanel hotlink koruma yazısında bulabilirsiniz. Büyük statik dosyaların kalıcı çözümü ise onları sunucudan çıkarmaktır: bir CDN veya nesne depolama, hem trafiği hem de disk okuma yükünü sizden alır.

Bir Daha Yaşamamak İçin: Ölçüm, Alarm ve Sınır#

Teşhis bir kez yapılır, önlem kalıcıdır. Şu dört maddeyi kurduğunuzda aynı e-postayı bir daha okumazsınız:

1. vnstat her sunucuda kurulu ve etkin olsun. Maliyeti sıfıra yakın, geriye dönük veri üretmesi imkânsız. Kurulum günü kurulmalı.
2. Ayın ortasında bir kontrol alışkanlığı edinin. vnstat -m çıktısına haftada bir bakmak, kotayı ayın 12'sinde değil ayın 20'sinde öğrenmenizi engeller. Grafiksel bir panel istiyorsanız netdata ile sunucu izleme kurulumu ağ grafiklerini de kapsar.
3. Yedekleme trafiğine hız sınırı ve artımlı politika koyun. Bu tek başına çoğu kota sorununu bitirir.
4. Statik ağır içeriği CDN'e veya nesne depolamaya taşıyın. 200 MB'lık bir kurulum dosyası, ayda 2.000 indirme ile tek başına 400 GB eder.

Son bir uyarı: kota aşımının faturası genelde sessizce gelir. Bazı sağlayıcılar aşımı ücretlendirir, bazıları hızı düşürür, bazıları hizmeti askıya alır. Sözleşmenizde hangisinin geçerli olduğunu sorun çıkmadan okumak, gece yarısı sürpriz yaşamamanın en ucuz yoludur.

Sıkça Sorulan Sorular#

vnstat kurduğum halde geçmiş aylara ait veri görünmüyor, neden?#

vnstat yalnızca kendi servisi çalışırken toplanan veriyi bilir; kurulumdan önceki dönem için hiçbir kaydı yoktur ve bu veriyi geriye dönük üretemez. Arayüz sayaçları da her yeniden başlatmada sıfırlandığı için kaynak yoktur. Bu yüzden vnstat sorun çıktığında değil, sunucu kurulduğu gün kurulup açılışta etkinleştirilmelidir. Kurulumdan sonra ilk anlamlı aylık rapor için bir tam ay beklemeniz gerekir.

iftop ve nethogs sürekli açık kalabilir mi?#

Kalmamalı. İkisi de arayüzü dinleyip her paketi işlediği için yoğun trafik altında gözle görülür CPU tüketirler ve uzun süreli çalıştırıldıklarında ekranda tuttukları veri de büyür. Bu araçlar teşhis içindir: sorunlu saatte birkaç dakika çalıştırıp kapatın. Sürekli izleme için ölçüm maliyeti çok düşük olan vnstat ya da bir izleme paneli kullanın.

vnstat'ın gösterdiği rakam sağlayıcı panelindekiyle uyuşmuyor, hangisi doğru?#

İkisi de kendi ölçüm noktasında doğrudur. vnstat sunucunun ağ arayüzündeki trafiği sayar; sağlayıcı ise sanallaştırma katmanında veya anahtar üzerinde ölçer ve genellikle protokol başlıklarını da hesaba katar. %5-10 arası fark normaldir. Faturalandırmada sağlayıcının ölçümü geçerlidir; vnstat'ı mutlak rakam için değil, sıçramanın hangi gün ve saatte olduğunu bulmak için kullanın.

Trafik giden yönde çok yüksek ama sitem çok ziyaret almıyor, sebebi ne olabilir?#

Bu tabloda ilk üç şüpheli sırasıyla şudur: dışarıya gönderilen bir yedekleme işi, sizin dosyalarınızı kendi sayfasında gösteren bir site (hotlink) ve büyük statik dosyaların doğrudan indirilmesi. Erişim günlüğünde en çok bayt üreten URL'leri ve referer alanını incelemek üçünü de birbirinden kolayca ayırır. Ziyaretçi sayısı ile trafik arasında doğrudan bir orantı beklemeyin; tek bir 200 MB'lık dosya, binlerce sayfa görüntülemeden fazla bant genişliği harcar.

Bant genişliği kotamı aşarsam ne olur?#

Sağlayıcıya göre değişir ve üç yaygın uygulama vardır: aşan kısım için ek ücret faturalanır, hız belirgin biçimde düşürülür (genellikle 10 Mbps gibi bir seviyeye) veya hizmet dönem sonuna kadar askıya alınır. Hangisinin geçerli olduğu hizmet sözleşmesinde yazar ve satın almadan önce okunması gereken maddelerden biridir. Kotanın %80'inde uyarı almak için sağlayıcı panelinde bildirim ayarı varsa mutlaka açın.

Docker kullanıyorum, hangi konteynerin trafiği tükettiğini nasıl bulurum?#

Host üzerinde nethogs konteyner içindeki süreçleri beklediğiniz isimle göstermeyebilir. En pratik yol, arayüz bazlı bakmaktır: her konteynerin veth arayüzü vardır ve vnstat -i vethXXXX ile ayrı ayrı izlenebilir. Alternatif olarak docker stats komutu NET I/O sütununda konteyner başına toplam gelen/giden trafiği doğrudan verir; sıçrayan konteyneri bulmak için genellikle bu sütun yeterlidir.