Scraper Sunucusu Nerede Çalışmalı? İstemci, Proxy ve Hedef Bacaklarında Gecikme
Scraper sunucusu nerede çalışmalı sorusunun cevabı, proxy çıkışı hedef ülkede olsa bile sunucunun konumunun gecikmeyi değiştirmesidir; çünkü her istek sunucu ile proxy giriş noktası arasındaki bacağı en az bir kez, bağlantı kurulumunda ise üç dört kez öder. Bu rehber iş yükünü ofisten bir sanal sunucuya ya da buluta taşıyacak ekip için üç bacağı ayırır, dört yerleşim düzenini karşılaştırır, ürün başına ülke listesini katalogdan verir ve iki sunucu bölgesi ile iki proxy ülkesini bir tabloda ölçen bir karar yöntemi anlatır.
Yayın: 2026-11-12 · Güncelleme: 2026-11-12

Üç bacak: sunucu → proxy girişi, proxy → hedef, dönüş
Proxy üzerinden giden bir isteğin yolu üç bacaktan oluşur. Birinci bacak scraper’ın çalıştığı sunucudan proxy giriş noktasına gider; ikinci bacak proxy’nin çıkış adresinden hedef sunucuya; üçüncü bacak yanıtın aynı yoldan geri dönüşüdür. Hedefin gördüğü adres ikinci bacağın başındaki çıkış adresidir; sunucunuzun kendi adresi hedefe ulaşmaz. Buna karşılık sizin ölçtüğünüz süre üç bacağın toplamıdır ve birinci bacak, sunucu ile proxy girişi arasındaki mesafeye göre sıfıra yakın da olabilir, yüz milisaniyenin üstüne de çıkabilir.
Bacakların kaç kez ödendiği istek türüne göre değişir. Yeni bir bağlantıda sunucu ile proxy girişi arasında TCP el sıkışması, ardından HTTPS hedef için CONNECT isteği ve tünel içinde TLS el sıkışması olur; bunların her biri birinci bacağı bir gidiş dönüş olarak öder. Kurulum tamamlandıktan sonra veri isteği ve yanıtı bir gidiş dönüş daha ekler. Yani bağlantı başına birinci bacak üç dört kez, ikinci bacak ise CONNECT ile birlikte bir iki kez ödenir. Sunucu proxy girişinden uzaksa bu çarpan doğrudan sayfa başına süreye yansır; bileşenlerin curl ile nasıl ayrı ayrı ölçüleceği gecikme ölçümü rehberinde anlatılır.
Hedef pazar ve çıkış ülkesi seçimi ayrı bir sorudur ve lokasyon seçimi rehberinde ele alınır; aşağıdaki karşılaştırmalarda çıkış ülkesi seçilmiş sayılır ve yalnız sunucunun yeri değişir.
Çıkış hedef ülkede ama sunucu uzaktaysa: keep-alive ne kadarını kurtarır?
Keep-alive, kurulan tüneli bir sonraki istek için açık tutar ve birinci bacağın el sıkışma payını siler. İstemci kütüphanesi bağlantıyı yeniden kullandığında sayfa başına yalnız bir gidiş dönüş kalır; kurulum maliyeti ilk istekte ödenir ve ardından gelen yüzlerce isteğe bölünür. Bu yüzden sunucu proxy girişinden uzak olsa bile, static adet ürünlerinde uzun ömürlü tünellerle çalışan bir scraper kurulum farkını büyük ölçüde gizler.
Rotating GB ürünlerinde durum farklıdır. İstek başına rotasyon isteyen bir iş, tasarımı gereği her istekte yeni bir çıkış adresi alır ve çoğu kurulumda bu yeni bir tünel demektir; keep-alive devreye giremez ve birinci bacak her sayfada üç dört kez ödenir. Tünel ömrünün ürün türüne göre nasıl değiştiği ve ısınma etkisi yüksek hacimli scraping rehberinde ayrıntılı anlatılır; burada sonuç şudur: rotating ağırlıklı bir iş yükünde sunucu konumu, static ağırlıklı bir iş yüküne göre daha çok önem taşır.
Uzak sunucunun ikinci etkisi zaman aşımı ayarlarındadır. Bağlantı zaman aşımı yalnız sunucu ile proxy girişi arasındaki TCP kurulumunu kapsar; sunucuyu başka kıtaya taşıdığınızda bu değer sabit kalırsa ilk belirtiler yavaş sayfa yerine bağlantı hataları olur. Taşınma sonrası zaman aşımı değerleri yeni bölgeden yapılan ölçümle yeniden türetilir; yöntem zaman aşımı rehberindedir.
Dört yerleşim düzeni: ofis, hedefe yakın, proxy girişine yakın, çok bölgeli
Birinci düzen ofis bilgisayarı ya da ofis ağındaki bir makinedir. Kurulumu sıfır, bakım sıfır; ama hat ev ya da ofis tipi bir bağlantıdır, elektrik ve yeniden başlatma kesintileri işi durdurur ve birinci bacak çoğu proxy girişi için kıtalar arası olur. Günde birkaç bin sayfa için yeterlidir; sürekli çalışan bir iş için değildir.
İkinci düzen hedefe yakın sanal sunucudur. Mantığı şudur: çıkış adresi zaten hedef ülkede, sunucu da aynı bölgede olsun. Bu düzen ikinci bacağı kısaltmaz, çünkü ikinci bacak proxy çıkışıyla hedef arasındadır ve sunucunun yerinden bağımsızdır. Kısalttığı şey, proxy girişi de aynı bölgedeyse birinci bacaktır. Yani bu düzenin değeri, proxy girişinin nerede olduğuna bağlıdır; hedefe yakın olmak tek başına bir kazanç getirmez.
Üçüncü düzen proxy giriş noktasına yakın sunucudur. Birinci bacak en küçüğe iner, kurulum çarpanı neredeyse yok olur ve rotating işlerde en çok kazanç burada çıkar. Giriş noktasının adresi panelde yazar; bölgesini o adrese yapılan bağlantı ölçümünden ya da destekten öğrenir, sunucu bölgesini ona göre seçersiniz. Bu düzende kendi sunucunuzun bulut sağlayıcısında ikinci bacak değişmez; değişen tek şey, her sayfada üç dört kez ödediğiniz ilk bacağın küçülmesidir.
Dördüncü düzen çok bölgeli worker’lardır: her hedef pazar için o bölgeye yakın bir worker, ortada tek bir kuyruk. Kurulum ve işletme maliyeti en yüksek olanıdır ve yalnız üç dört farklı kıtadaki pazarları aynı anda, sürekli ve yüksek hacimle çeken ekip için anlamlıdır. Tek pazara ya da ara sıra çalışan bir işe çok bölge kurmak, kazandırdığı birkaç on milisaniyeyi işletme yüküyle geri alır.
Hedef ülke ile ürün ülkesi: static IPv4 beş ülke, rotating 180’den fazla
Çıkış ülkesi ürüne göre sınırlıdır ve sunucu bölgesi kararı bu listeyle birlikte verilir. Kataloğa göre static IPv4 datacenter adresleri beş ülkede sunulur: Amerika Birleşik Devletleri, Birleşik Krallık, Hollanda, Almanya ve Kanada; paketler 30 günlük 100, 250, 500 ve 1.000 adet için 15, 25, 45 ve 80 USD’dir. Türkiye static IPv4 listesinde yoktur. Rotating IPv4 datacenter 180’den fazla ülkeyi kapsar; paketler 2, 10, 20, 50 ve 100 GB için 1, 6, 12, 30 ve 60 USD’dir ve Türkiye bu listededir. Static IPv6 datacenter on dokuz ülkede sunulur ve Türkiye ile Almanya ve ABD bu listede yer alır.
Bu listenin sunucu kararına etkisi şudur: hedef pazarınız Almanya ise hem static IPv4 hem rotating seçeneği vardır ve sunucu Avrupa’da bir bölgede durabilir. Hedef Türkiye ise static IPv4 yoktur; rotating IPv4 ya da static IPv6 kullanırsınız ve ikisinde de birinci bacak için proxy girişinin bölgesine bakarsınız. Hedef Japonya ya da Brezilya gibi static IPv4 listesinde olmayan bir ülkeyse çıkış rotating’den gelir ve sunucuyu hedef kıtaya taşımak ikinci bacağı değiştirmez.
Bütün bunlar yalnız gecikme içindir. Hedefin ülkeye göre farklı içerik göstermesi ya da ülke kısıtı uygulaması çıkış adresine bağlıdır; sunucunuz Frankfurt’ta, çıkışınız Amsterdam’da ise hedef Hollanda’dan gelen bir ziyaretçi görür.
Ölçerek karar: iki sunucu bölgesi × iki proxy ülkesi, ilk bayt tablosu
Karar bir tabloyla verilir ve tablo bir saatte dolar. Satırlar sunucu bölgesidir: mevcut yer (ofis ya da bugünkü bulut bölgesi) ve aday bölge. Sütunlar çıkış ülkesidir: iki aday ülke, örneğin Almanya ve ABD. Her hücre için aynı hedefe, aynı üründen, on tekrarlı curl ölçümü yapılır ve dört sayı kaydedilir: bağlantı süresi (birinci bacak TCP), CONNECT dahil tünel kurulumu, ilk bayt süresi ve toplam süre. Dört sayının nasıl alınacağı gecikme ölçümü rehberindeki curl kalıbıyla aynıdır.
Bağlantı süresi satırlar arasında büyük, sütunlar arasında küçük fark gösteriyorsa sunucu bölgesi önemlidir ve aday bölgeye taşınırsınız. Fark sütunlar arasında büyükse çıkış ülkesi belirleyicidir ve sunucu yerinde kalır. İlk bayt süresi iki eksende de yakınsa hedefin kendi yanıt süresi baskındır ve ne taşınma ne de ülke değişimi fark yaratır; o durumda eşzamanlılık ve kuyruk yönetimiyle uğraşırsınız.
Varsayım: mevcut bölge İstanbul ofisi, aday bölge Frankfurt; çıkış ülkeleri Almanya ve ABD; hedef Almanya’daki bir pazar yeri. Beklenen örüntü, Frankfurt satırında bağlantı süresinin belirgin düşmesi ve Almanya sütununda ilk bayt süresinin ABD sütununa göre kısa olmasıdır; gerçek sayılar sizin ölçümünüzden gelir, buraya örnek değer yazılmaz. Ölçümü iş saatinde ve gece bir kez daha tekrarlayın; iki ölçüm farklı kazanan gösteriyorsa yol kalitesi saate bağlıdır ve kararı iş yükünün çalıştığı saate göre verirsiniz.
Ölçüm bir kez yapılıp bırakılmaz. Sunucu taşındıktan sonra aynı tabloyu bir hafta boyunca günde bir kez doldurun; taşınma öncesi ortalama ile sonrası ortalama arasındaki fark, kararın gerçek getirisidir. Fark yoksa taşınma gereksizdi ve bir sonraki pazar kararında bu ölçüm başlangıç noktası olur.
Kontrol listesi: veri transfer kotası, saat dilimi, kayıt ve depolama
Bulut sağlayıcının giden veri kotası. Scraper’ın proxy’ye gönderdiği her istek ve aldığı her yanıt, sağlayıcının ağ faturasında giden ve gelen trafik olarak sayılır; proxy’nin GB kotası ile sağlayıcının trafik kotası iki ayrı faturadır. Taşınmadan önce aylık beklenen GB’yi iki kez sayın.
Saat dilimi. Sunucu bölgesini değiştirince sistem saati de değişir; zamanlanmış görevler, günlük tarih damgaları ve hedefin yerel saatine göre kurulan tarama takvimi kayar. Sunucuyu UTC’de tutup hedefin saatini kodda çevirmek, bölge değiştirdikçe takvimi yeniden yazmaktan ucuzdur.
Kayıt ve depolama yeri. Çekilen veri hangi ülkede saklanıyor ve kayıtlar hangi ülkede tutuluyor? Veri koruma gereklilikleri kişisel veri içeren işlerde depolama yerine bağlı olabilir; bu konu bu rehberin kapsamı dışındadır, ancak taşınma kararında hukuk ekibine sorulacak tek soru budur.
Çıkış adresi izin listesi. Proxy hesabı IP izin listesiyle çalışıyorsa yeni sunucunun adresi panele eklenmeden ilk istek 407 ile döner. Taşınma günü bunu ilk sıraya yazın; en sık karşılaşılan taşınma sonrası arıza budur.
Zaman aşımı ve eşzamanlılık değerleri. Yeni bölgeden ölçülen bağlantı süresine göre zaman aşımları yeniden türetilir; eşzamanlılık değeri bir hafta boyunca eski değerde tutulur ve ölçüm tablosu kararlı çıktıktan sonra artırılır.
İlgili ürünler
İç bağlantılar
- Proxy Gecikme Ölçümü: Latency Testi Nasıl Yapılır?
- Gecikme İçin Proxy Lokasyonu Seçimi: Katalogdan Karar
- Çok Lokasyonlu Site Hızı Testi: CDN’i Proxy ile Doğrulama
- Yüksek Hacimli Scraping’de Gecikme: Datacenter Proxy Planı
- Kendi Proxy Sunucunu Kurmak mı, Datacenter Proxy mi?
- Proxy Timeout Ayarları: Bağlantı ve Okuma Zaman Aşımı
- Web Scraping
- Pazar Araştırması
SSS
Sunucu ile proxy aynı ülkede olmalı mı?
Aynı ülke gerekmez; aynı bölge yeter. Önemli olan sunucu ile proxy giriş noktası arasındaki birinci bacağın kısa olmasıdır. Giriş noktası Avrupa’daysa Frankfurt, Amsterdam ya da Paris bölgeleri arasındaki fark küçüktür; kıta değişimi ise bağlantı süresini birkaç kat artırır.
Proxy kullanınca sunucunun IP adresi hedefe görünür mü?
Hayır. Hedef yalnız proxy çıkış adresini görür; sunucunuzun adresi ikinci bacakta yoktur. Kimlik bilgisi ya da DNS sızıntısı gibi konular ayrı bir sorudur ve proxy ayarının doğru katmanda yapılmasıyla ilgilidir; sunucu konumu bu konuyu değiştirmez.
Türkiye’deki ofisten çalıştırmak yeterli mi?
Günde birkaç bin sayfa ve sürekli çalışma gerektirmeyen işler için evet. Birinci bacak Avrupa’daki proxy girişine kıtalar arası sayılmaz ama ofis hattı, elektrik kesintisi ve makinenin başka işlerde kullanılması işi durdurur. Sürekli ve yüksek hacimli işler, proxy girişine yakın bir sanal sunucuya taşınır.
Çok bölgeli kurulum ne zaman gerekir?
Üç dört farklı kıtadaki pazarları aynı anda, sürekli ve yüksek hacimle çekiyorsanız. Tek pazar ya da ara sıra çalışan iş için tek bölge yeter; ölçüm tablosunda bölge satırları arasındaki bağlantı süresi farkı küçükse ikinci bölge kurmaya gerek yoktur.
Sunucuyu hedefe yakın koymak ikinci bacağı kısaltır mı?
Hayır. İkinci bacak proxy çıkış adresi ile hedef arasındadır ve sunucunun yerinden bağımsızdır. Hedefe yakınlık, yalnız proxy girişi de aynı bölgedeyse birinci bacağı kısaltır. Sunucu bölgesi seçerken giriş noktasının bölgesine bakılır.
