Ping testi, bir sunucuya ulaşmanın ne kadar sürdüğünü ve yolda paket kaybolup kaybolmadığını gösteren en hızlı ağ ölçümüdür. Ancak "ping 30 ms çıktı" demek tek başına pek bir şey anlatmaz: kaç paket gönderildi, en yüksek değer neydi, kayıp var mı, sorun sizin bağlantınızda mı yoksa sunucuya giden yolda mı? Bu rehberde ping testini Windows, Linux ve macOS'ta doğru şekilde nasıl yapacağınızı, sonucu nasıl okuyacağınızı, tracert ve MTR ile sorunun hangi noktada başladığını nasıl bulacağınızı ve destek ekibine işe yarar bir rapor nasıl hazırlayacağınızı adım adım anlatıyoruz.
Ping, hedef cihaza ICMP "Echo Request" paketi gönderir ve "Echo Reply" yanıtını bekler. Paketin gidip dönmesi arasında geçen süreye gidiş-dönüş süresi (RTT) denir ve milisaniye (ms) cinsinden gösterilir. Bir ping testi size dört temel bilgi verir:
Ping'in ölçmediği şeyler de var: bant genişliğini (indirme/yükleme hızını), web sitenizin açılma süresini ya da uygulamanızın yanıt süresini ping ile ölçemezsiniz. Ping düşük olduğu hâlde site yavaşsa sorun büyük ihtimalle ağda değil, sunucu kaynaklarında ya da uygulamadadır; bunun için sunucu performans sorunlarını tespit etme rehberimize bakabilirsiniz.
Başlat menüsüne "cmd" yazıp Komut İstemi'ni açın. Varsayılan ping komutu yalnız dört paket gönderir; bu, sunucunun ayakta olduğunu görmek için yeterlidir ama karar vermek için yetersizdir. Daha anlamlı bir ölçüm için paket sayısını artırın:
ping -n 100 203.0.113.10
ping -t 203.0.113.10 (Ctrl+C ile durdurulana kadar sürer)
ping -6 -n 50 sunucu-alan-adiniz.com (IPv6 üzerinden test)
Komut bittiğinde en altta bir özet çıkar: gönderilen, alınan ve kaybolan paket sayısı ile en düşük, en yüksek ve ortalama süre. Asıl bakmanız gereken yer bu özettir.
Ping ICMP kullandığı için ICMP'nin kapalı olduğu sunucularda "İstek zaman aşımına uğradı" görürsünüz. Bu durumda hizmet portunu TCP ile test etmek daha doğrudur. PowerShell'de:
Test-NetConnection 203.0.113.10 -Port 3389
Test-NetConnection 203.0.113.10 -Port 443 -InformationLevel Detailed
Çıktıdaki TcpTestSucceeded : True satırı, port açıksa ve hizmet yanıt veriyorsa görünür. Ping yanıtsız ama TCP testi başarılıysa sunucunuz çalışıyordur; yalnız ICMP engellenmiştir.
Linux ve macOS'ta ping komutu durdurulana kadar çalışır; bu yüzden paket sayısını baştan belirtmek pratiktir:
ping -c 100 203.0.113.10
ping -c 200 -i 0.2 203.0.113.10 (200 paket, 0,2 sn aralıkla)
ping -6 -c 50 sunucu-alan-adiniz.com (bazı sistemlerde: ping6)
Linux özet satırı şu biçimdedir:
100 packets transmitted, 100 received, 0% packet loss, time 99141ms
rtt min/avg/max/mdev = 28.412/29.087/34.906/0.913 ms
Buradaki mdev değeri, sürelerin ortalamadan ne kadar saptığını gösterir ve jitter için iyi bir göstergedir. Sunucu tarafında bir hizmetin portunu test etmek için nc kullanabilirsiniz:
nc -vz 203.0.113.10 22
nc -vz 203.0.113.10 443
Sonucu yorumlarken tek bir sayıya değil, üç değerin birlikte oluşturduğu tabloya bakın.
| Gözlem | Muhtemel anlamı | Ne yapmalı? |
|---|---|---|
| Ortalama düşük, en yüksek ortalamaya yakın, kayıp yok | Sağlıklı ve kararlı bağlantı | Bir şey yapmaya gerek yok |
| Ortalama düşük ama arada çok yüksek değerler var | Yerel ağda yoğunluk, Wi-Fi paraziti ya da anlık tıkanma | Kablolu bağlantıyla tekrar test edin |
| Sürekli yüksek ama kararlı ortalama | Mesafe ya da dolambaçlı yönlendirme | tracert/MTR ile yolu inceleyin, lokasyonu sorgulayın |
| %1 ve üzeri düzenli paket kaybı | Hat sorunu, aşırı yük ya da arızalı bir bağlantı noktası | MTR ile kaybın başladığı durağı bulun |
| Belirli saatlerde artan gecikme | Akşam saatlerinde internet servis sağlayıcısı yoğunluğu | Farklı saatlerde test edip karşılaştırın |
| Hiç yanıt yok | ICMP kapalı, güvenlik duvarı ya da gerçek erişim kaybı | TCP port testi yapın |
Ne kadar ping normaldir? Işık fiberde boşluktakinden yavaş ilerler; kabaca her 100 km mesafe gidiş-dönüşte yaklaşık 1 ms ekler. Üstüne yönlendirici geçişleri ve hatların düz bir çizgi izlememesi eklenir. Bu yüzden aynı şehir içinde birkaç ms, Türkiye içinde onlu değerler, Avrupa'ya onlu ve düşük yüzlü değerler, kıtalar arasında ise yüz ms'nin üzeri normal kabul edilir. Mesafenin gecikmeye etkisini ve neden Türkiye lokasyonunun önemli olduğunu Türkiye lokasyon sunucu ping rehberimizde ayrıntılı ele aldık.
Kullanıcılarınıza yakın, düşük gecikmeli sunucu
İstanbul lokasyonunda, Tier 3 standartlarına uygun veri merkezinde KVM sanallaştırma ve 1 Gbps port ile VDS.
VDS paketlerini inceleyinPing size sonucun kendisini, tracert ise yolu gösterir. Paket sunucunuza giderken geçtiği her yönlendirici bir "durak" (hop) olarak listelenir. Gecikmenin hangi noktada sıçradığını görmek için kullanılır.
Windows: tracert -d 203.0.113.10
Linux: traceroute -n 203.0.113.10
Linux (TCP 443 ile, ICMP engelli yollarda):
sudo traceroute -T -p 443 -n 203.0.113.10
-d ve -n parametreleri ad çözümlemesini kapatır, böylece test çok daha hızlı biter. Bazı duraklarda * * * görmeniz normaldir; o yönlendirici bu tür paketlere yanıt vermiyor demektir, trafiğin orada durduğu anlamına gelmez. Sonraki duraklar yanıt veriyorsa sorun yoktur.
Windows'ta pathping komutu tracert ile ping'i birleştirir: önce yolu çıkarır, sonra her durağa bir süre paket gönderip kayıp oranını hesaplar. Tam sonuç birkaç dakika sürer, ancak MTR kuramadığınız bir Windows bilgisayarda kullanışlıdır:
pathping -n 203.0.113.10
MTR, traceroute ile ping'i aynı anda ve sürekli yapan bir araçtır. Her durak için gönderilen paket sayısını, kayıp yüzdesini ve en düşük/ortalama/en yüksek süreyi tek tabloda gösterir. Sağlayıcılara gönderilen ağ raporlarında standart hâline gelmiştir.
Ubuntu/Debian: sudo apt install mtr-tiny
AlmaLinux/Rocky: sudo dnf install mtr
macOS (Homebrew): brew install mtr
Rapor modu (100 paket, IP ve AS numarası ile):
sudo mtr -rwzbc 100 203.0.113.10
TCP 443 üzerinden:
sudo mtr -rwzbc 100 -T -P 443 203.0.113.10
Windows'ta MTR'ye benzer grafik arayüzlü araçlar bulunur; ancak sağlayıcıya rapor gönderecekseniz Linux'taki MTR çıktısı ya da pathping çıktısı genellikle en kolay okunan biçimdir.
MTR tablosunda ortadaki bir durakta %20, %40 hatta %60 kayıp görünüp hedefte %0 kayıp varsa bu gerçek bir kayıp değildir. İnternet yönlendiricileri trafiği iletmeyi önceliklendirir, kendilerine yöneltilmiş ICMP isteklerine ise sınırlı kaynak ayırır. Bu yüzden ara durakta görünen kayıp çoğu zaman yalnız "bu yönlendirici bana yanıt vermeye üşendi" anlamına gelir.
Gerçek sorunun iki işareti vardır:
Yalnız bir durakta yüksek görünen ama sonraki duraklarda tekrar düşen süre de aynı şekilde ICMP önceliklendirmesinden kaynaklanır ve görmezden gelinebilir.
| MTR tablosu | Yorum |
|---|---|
| Durak 5: %40 kayıp; durak 6-10 ve hedef: %0 | Sorun yok, ara yönlendirici ICMP'yi sınırlıyor |
| Durak 5'ten hedefe kadar her yerde ~%8 kayıp | Gerçek kayıp, durak 4 ile 5 arasındaki bağlantı şüpheli |
| Durak 1 veya 2'de kayıp ve yüksek jitter | Sorun büyük ihtimalle yerel ağınızda ya da modeminizde |
| Durak 7'de +80 ms sıçrama ve sonrası hep yüksek | Trafik uzak bir noktadan dolaşıyor olabilir (yönlendirme) |
Yeni kurulmuş bir Windows Server'a ping atamamanız çok yaygındır; Windows güvenlik duvarı gelen ICMP Echo isteklerini varsayılan olarak yanıtlamaz. İzleme sistemlerinizin ya da sizin test yapabilmeniz için yalnız Echo isteğine izin veren bir kural ekleyebilirsiniz. Yönetici PowerShell'de:
New-NetFirewallRule -DisplayName "ICMPv4 Echo Izin" -Protocol ICMPv4 -IcmpType 8 -Direction Inbound -Action Allow
New-NetFirewallRule -DisplayName "ICMPv6 Echo Izin" -Protocol ICMPv6 -IcmpType 128 -Direction Inbound -Action Allow
Linux tarafında ufw varsayılan kurallarında Echo isteğine zaten izin verir. nftables ya da iptables ile kendi kural setinizi yazdıysanız ICMP'yi tamamen kapatmak yerine hız sınırıyla izin vermek daha sağlıklıdır:
sudo iptables -A INPUT -p icmp --icmp-type echo-request -m limit --limit 5/second -j ACCEPT
sudo iptables -A INPUT -p icmp --icmp-type echo-request -j DROP
IPv6'da ICMP'yi tamamen kapatmayın. IPv6, komşu keşfi ve yol MTU keşfi gibi temel işlevler için ICMPv6'ya ihtiyaç duyar; ICMPv6'yı bütünüyle engellemek bağlantının garip biçimlerde kopmasına yol açar. Yalnız Echo isteğini sınırlamak yeterlidir.
Bir ayarda hata yapıp sunucuya uzaktan erişimi kaybederseniz VDS'lerde Müşteri Arayüzü'ndeki konsoldan, kiralık sunucularda ise tarayıcı üzerinden açılan HTML5 KVM konsolundan girip kuralı düzeltebilirsiniz.
Gecikme ya da kayıp gördüğünüzde sorunu daraltmak için şu sırayı izleyin:
ping -c 100 1.1.1.1 ya da ping -n 100 8.8.8.8 gibi genel bir DNS sunucusuna da test yapın. Her iki hedefte de sorun varsa sorun internet bağlantınızdadır.top ve vnstat, Windows'ta Görev Yöneticisi'nin Performans sekmesi ilk bakılacak yerlerdir.Küçük ping paketleri sorunsuz giderken büyük paketler takılıyorsa yolda MTU uyuşmazlığı olabilir. Parçalanmayı kapatıp paket boyutunu deneyerek bunu anlayabilirsiniz. 1472 bayt veri + 28 bayt başlık = 1500 bayt standart Ethernet MTU'sudur:
Windows: ping -f -l 1472 203.0.113.10
Linux: ping -M do -s 1472 -c 5 203.0.113.10
"Paketin parçalanması gerekiyor" ya da "message too long" yanıtı alırsanız boyutu küçülterek geçen en büyük değeri bulun. Bu bilgi özellikle VPN ve tünel bağlantılarında sorunun kaynağını gösterir.
Ping testi yalnız arıza anında değil, sunucu satın almadan önce de işe yarar. Kullanıcılarınızın büyük çoğunluğu Türkiye'deyse Türkiye lokasyonlu bir sunucu, Avrupa'daki kullanıcılar için ise Almanya ya da Fransa lokasyonu genellikle daha düşük gecikme sağlar. Karar verirken şunlara dikkat edin:
-6 parametresiyle IPv6 üzerinden de tekrarlayın. Türkiye lokasyonlu VDS, kiralık sunucu ve GPU sunucularımızda ücretsiz /64 IPv6 bloğu verilir.Lokasyon seçimini daha kapsamlı ele almak isterseniz veri merkezi lokasyonu seçim rehberimizi okuyabilirsiniz.
Türkiye'deki kullanıcılarınız için fiziksel sunucu
İstanbul veri merkezinde, tarayıcıdan HTML5 KVM konsol erişimli kiralık sunucular ve 7/24 destek.
Türkiye lokasyon kiralık sunucuları inceleyin"İnternet yavaş" diye açılan bir talep çözülene kadar birkaç kez gidip gelir. Aşağıdaki bilgileri ilk mesajda paylaşmanız sorunun çok daha hızlı bulunmasını sağlar:
mtr -rwzbc 100) ya da Windows'ta pathping -n çıktısı.Çıktıları ekran görüntüsü yerine metin olarak eklemeniz, değerlerin kopyalanıp karşılaştırılmasını kolaylaştırır. Destek talepleri 7/24 alınır; talebinizi iletişim sayfamızdan da iletebilirsiniz.
Ping testi kaç paketle yapılmalı?
Tek seferlik dört paket yalnız sunucunun ayakta olup olmadığını gösterir. Gecikme ve paket kaybı hakkında karar vermek için en az 50-100 paket gönderin; aralıklı sorunlarda testi farklı saatlerde birkaç kez tekrarlayın.
Sunucuya ping atamıyorum, sunucu kapalı mı?
Her zaman değil. Windows Server'ın güvenlik duvarı gelen ICMP isteklerini varsayılan olarak yanıtlamaz, bazı Linux sunucularda da ICMP kapatılmış olabilir. Sunucunun açık olup olmadığını anlamak için hizmet portunu TCP ile test edin, örneğin Test-NetConnection ya da nc komutuyla.
MTR çıktısında aradaki bir duraktaki yüzde kayıp sorun mu?
Kayıp yalnız o durakta görünüyor ve sonraki duraklarla hedefte sıfırsa genellikle sorun değildir. Yönlendiriciler kendilerine gelen ICMP isteklerine düşük öncelik verir. Gerçek kayıp, bir duraktan başlayıp hedefe kadar devam eden kayıptır.
İyi bir ping değeri kaç milisaniyedir?
Tek bir doğru sayı yoktur; değer büyük ölçüde mesafeye bağlıdır. Aynı şehir içindeki bağlantılarda birkaç milisaniye, ülke içinde onlu değerler, kıtalar arası bağlantılarda ise yüz milisaniyenin üzeri normaldir. Değerin kararlı olması da ortalaması kadar önemlidir.
Jitter nedir ve neden önemlidir?
Jitter, ardışık paketlerin gecikme süreleri arasındaki dalgalanmadır. Ortalama ping düşük olsa bile jitter yüksekse sesli görüşme, oyun ve uzak masaüstü bağlantılarında takılma ve kopma hissedilir. Ping çıktısındaki en düşük ve en yüksek süre farkı kaba bir fikir verir.
Destek talebi açarken hangi test sonuçlarını eklemeliyim?
Kendi genel IP adresinizi, testin yapıldığı tarih ve saati, en az 100 paketlik ping özetini ve hedefe yönelik MTR ya da tracert çıktısını ekleyin. Mümkünse sunucu tarafından sizin IP adresinize yapılan ters yön testini de paylaşın.