# Sunucunuz için veri merkezi lokasyonu nasıl seçilir? > Mesafenin gecikmeye dönüşmesi, ping ve mtr ile kullanıcılarınızın tarafından ölçüm, veri kurallarının lokasyona etkisi ve CDN'in ne zaman gerektiği. Zorluk: Başlangıç\ Denendiği sistemler: Ubuntu 24.04 LTS, Debian 13, Windows 11, macOS Tahoe 26 Bir sunucu için doğru lokasyon genellikle kullanıcılarınızın çoğuna en yakın olandır; ancak mesafe cevabın yalnızca bir parçasıdır. Bu rehber gecikmenin nasıl oluştuğunu, nasıl doğru ölçüleceğini ve veri koruma kurallarının, CDN'lerin ve kesintiye dayanıklılığın karara nasıl dahil olduğunu anlatır. HyperDC sunucuları 24 veri merkezi lokasyonunda çalışır; [veri merkezleri](/data-centers) sayfası bunları her birinde sunulan hizmetlerle birlikte listeler. ## Başlamadan önce - **Kullanıcılarınızın nerede olduğunu bilin.** Analiz araçlarınız, mağaza siparişleriniz veya oyun sunucusu kayıtlarınız trafiğinizin çoğunun hangi ülkelerden ve ağlardan geldiğini gösterir. - **İş yükünüzü bilin.** Bir web sitesi, bir oyun sunucusu ve bir uzak masaüstü için kabul edilebilir gecikme sınırları farklıdır. - `ping` ve `mtr` (Linux ve macOS) veya `pathping` (Windows) çalıştırmak için **bir terminal hazır olsun**. ## Mesafe neden gecikmeye dönüşür? Işık optik fiberde boşluktaki hızının yaklaşık üçte ikisiyle, saniyede kabaca 200.000 kilometre yol alır. ITU'nun fiber için planlama değeri kilometre başına beş mikrosaniyedir; yani her 100 kilometre gidiş-dönüşe yaklaşık bir milisaniye ekler. Gerçek güzergâhlar haritadaki düz çizgiden uzundur ve ölçülen gidiş-dönüş süreleri çoğu zaman bu en düşük değerin birkaç katıdır. Gecikme ayrıca katlanır. Güvenli bir web sayfasını açmak, ilk bayt gelmeden önce birkaç gidiş-dönüş gerektirir: DNS sorgusu, TCP bağlantısı, TLS el sıkışması ve isteğin kendisi. Bu yüzden 100 milisaniye uzaktaki bir sunucu, ilk kez gelen bir ziyaretçiye birkaç yüz milisaniyeye mal olabilir. ## Ne kadar gecikme fazladır? | İş yükü | Ölçüt | Kaynak | |---|---|---| | Web siteleri | İlk bayta kadar 0,8 sn veya daha az | Google web.dev; DNS, bağlantı ve sunucu süresi dahil | | Sesli görüşmeler | Tek yönde 150 ms'nin altı | ITU-T G.114 | | Uzak masaüstü | Gidiş-dönüş 150 ms'nin altı | Microsoft'un Azure Virtual Desktop önerisi | | Çevrim içi oyunlar | Olabildiğince düşük, ideali 50 ms'nin altı | Resmî bir standart yok | | Birbiriyle konuşan servisler | Birkaç milisaniye | Bunları ve veritabanlarını tek lokasyonda tutun | ## 1. adım: Kullanıcılarınızın tarafından ölçün Ofisinizden atılan bir ping ziyaretçileriniz hakkında pek bir şey söylemez. Kullanıcılarınızın bulunduğu bölgelerden, mümkünse birden fazla ağdan ve günün farklı saatlerinde ölçün. Hedef olarak [veri merkezleri](/data-centers) sayfamızdaki lokasyon kartında, mevcutsa gösterilen **test IP'sini** veya **looking glass**'ı kullanın. Örneklerde `203.0.113.10` yerine o adresi yazın. **Linux ve macOS** 20 ping gönderin ve özet satırını okuyun: ```bash ping -c 20 203.0.113.10 ``` Linux'ta `mtr`, ping ile traceroute'u birleştirir ve gecikmenin veya kaybın yolun neresinde ortaya çıktığını gösterir (Ubuntu ve Debian'da `sudo apt install mtr-tiny` ile kurun): ```bash mtr -rwc 50 203.0.113.10 ``` **Windows** ```powershell Test-Connection 203.0.113.10 -Count 20 pathping 203.0.113.10 ``` `pathping` birkaç dakika sürer: önce güzergâhı çıkarır, sonra her atlamadaki kaybı ölçer. **Doğrulama:** en iyi tek sonucu değil, tipik değeri (ortalama veya ortanca) ve ne kadar değiştiğini karşılaştırın. Yolun ortasındaki bir atlamada görülen ve son atlamaya kadar devam etmeyen kayıp, genellikle ping yanıtlarına öncelik vermeyen bir yönlendiricidir; gerçek bir sorun değildir. Daha geniş bir resim için RIPE Atlas gibi halka açık bir ölçüm ağı, aynı anda birçok ağdan test yapar. ## 2. adım: Sipariş formundaki tahmini kullanın Bir HyperDC sunucusu sipariş ettiğinizde sipariş formu, bulunduğunuz yerden her veri merkezine tahmini gecikmeyi gösterir. Adayları kendi konumunuzdan karşılaştırmanın hızlı bir yoludur; kullanıcılarınızın bölgelerinden yapılan ölçümlerle birlikte değerlendirin. ## 3. adım: Verilerinizin nerede durabileceğini kontrol edin Sunucunun bulunduğu yer teknik olduğu kadar hukuki açıdan da önemli olabilir. AB'nin GDPR düzenlemesine göre kişisel veriler Avrupa Ekonomik Alanı'ndan yalnızca yeterlilik kararı bulunan ülkelere ya da standart sözleşme hükümleri gibi güvencelerle çıkabilir. Bazı sektörler ve sözleşmeler de verilerin belirli bir ülkede kalmasını şart koşar. Gerekli bölge içinde bir lokasyon seçmek bu tür kurallara uymanın en kolay yoludur; ancak yedekler, izleme ve destek erişimi de veri aktarımı içerebilir. Yükümlülüklerinizi bir hukuk danışmanıyla kontrol edin. ## 4. adım: Diğer etkenleri tartın - **Bağlantı:** bir lokasyonun kullanıcılarınızın internet sağlayıcılarına nasıl bağlandığı, mesafe kadar önemlidir. - **Koruma:** o lokasyondaki plan için DDoS korumasının dahil olup olmadığını kontrol edin; plan kartı bunu gösterir. - **Donanım ve planlar:** her sunucu modeli her lokasyonda sunulmaz. - **Saat dilimleri:** bakım ve kendi çalışma saatlerinizin kullanıcılarınız için ne zamana denk geldiğini düşünün. - **Fiyat:** aynı donanımın fiyatı lokasyona göre değişebilir. ## 5. adım: CDN veya ikinci lokasyon kararını verin İçerik dağıtım ağı (CDN), görselleri, betikleri ve diğer statik dosyaları ziyaretçilerinize yakın yerde önbelleğe alır; dünya çapında kitlesi olan siteler için faydalıdır. Ödeme, arama veya API çağrısı gibi dinamik istekler yine sunucunuza gider; bu yüzden uygulama ve veritabanı kullanıcılarınızın çoğuna ve birbirine yakın olmalıdır. Bkz. [sitenizin önünde Cloudflare](/guides/cloudflare-proxy-setup). Kesinti pahalıya mal olacaksa ikinci bir lokasyon mantıklıdır. Seçenekler, başka bir bölgede geri yükleyebileceğiniz yedeklerden hızla devreye girebilen sıcak bir yedek sunucuya kadar uzanır. Her basamak daha pahalıdır ve düzenli geçiş testleri gerektirir. ## Sorun giderme **Gecikme gece iyi, akşam yüksek.** Yoğun saatlerde güzergâhta tıkanıklık var. Kullanıcılarınızın aktif olduğu saatlerde ölçün ve lokasyonları o saatlerde karşılaştırın. **En yakın lokasyon en hızlısı değil.** Trafik düz çizgileri değil ağ bağlantılarını izler. Biraz daha uzaktaki bir lokasyon, kullanıcılarınızın sağlayıcılarına daha iyi bağlıysa daha hızlı olabilir. **Bir ülkedeki kullanıcılar yavaşlıktan şikâyetçi.** Onlardan sunucunuza yönelik `mtr` veya `pathping` çıktısı isteyin; gecikme ağımızın içinde görünüyorsa bu çıktıyla bir destek bildirimi açın. ## Sonraki adımlar - Sunucu serilerini karşılaştırın: [VPS, VDS ve dedicated sunucu](/guides/vps-vs-vds-vs-dedicated-server). - Lokasyonlarımızla ilgili sorular: [veri merkezleri SSS](/guides/data-centers-faq). - Mevcut bir siteyi mi taşıyorsunuz? [Web sitesini kesintisiz taşıyın](/guides/move-website-without-downtime). ## Sık sorulan sorular ### Mesafe ne kadar gecikme ekler? Teoride her 100 kilometre fiber için yaklaşık bir milisaniyelik gidiş-dönüş süresi. Gerçek güzergâhlar düz bir çizgiden uzundur ve genellikle daha fazlasını ekler. ### CDN, sunucu lokasyonunu önemsiz hale getirir mi? Hayır. CDN önbelleğe alınmış statik dosyaları ziyaretçilerinize yakın yerden sunar; ancak dinamik sayfalar, girişler, ödeme adımları ve API çağrıları yine sunucunuza gider. ### Kullanıcılarıma en yakın HyperDC lokasyonu hangisi? Sipariş formu, bulunduğunuz yerden her veri merkezine tahmini gecikmeyi gösterir. Başka bölgelerdeki kullanıcılar için, veri merkezleri sayfamızdaki lokasyon kartında gösterilen test IP'si veya looking glass ile o bölgeden ölçüm yapın ya da bize sorun. ### Veritabanım uygulamamla aynı lokasyonda mı olmalı? Çoğu durumda evet. Bir uygulama tek bir sayfayı oluşturmak için genellikle çok sayıda veritabanı sorgusu gönderir ve her sorgu ikisi arasındaki gidiş-dönüş süresini öder. Sık konuşan servisleri bir arada tutun, ikinci bir lokasyonu yedekler veya yedek sunucu için kullanın. ### Sunucumu daha sonra başka bir lokasyona taşıyabilir miyim? Evet; yeni lokasyonda bir sunucu kurup verilerinizi taşıyarak. Her taşıma gibi planlayın: kopyalayın, test edin, ardından DNS'i değiştirin. --- Kaynak: \ Son güncelleme: 2026-10-09