Static IPv4 Datacenter Proxy

Bir proxy seçerken çoğu ekip önce hız ve fiyatı konuşur. Oysa static IPv4 datacenter proxy alırken asıl satın alınan şey öngörülebilirliktir: bugün 09.00’da hangi adresten çıktıysanız, yarın 09.00’da da aynı adresten çıkarsınız. Bu kararlılık, hedef sistemin sizi adresinizle tanıdığı her işte doğrudan değer üretir. Bir bayi paneli, bir ödeme sağlayıcısının test ortamı, bir müşterinin güvenlik duvarı arkasındaki raporlama ekranı ya da kendi şirketinizin yönetim arayüzü, bağlantıyı kabul edip etmeyeceğine çoğu zaman kaynak IP’ye bakarak karar verir.

Dönen bir havuzda her yeni bağlantı başka bir adresten gelebilir. Bu, geniş çaplı veri toplamada avantajdır ama kimliğin sabit kalması gereken işlerde sürekli yeniden doğrulama, beklenmedik çıkış ve şüpheli oturum uyarısı demektir. Sabit IP ise hedefin gözünde tek, tutarlı bir istemci gibi davranır. Bu yüzden static IPv4, hacimden çok süreklilik isteyen iş yüklerinin ürünüdür.

IPv4 tarafının ayrıca pratik bir avantajı vardır: neredeyse her hedef sistem IPv4 konuşur. Eski kurumsal yazılımlar, bazı bankacılık ve muhasebe entegrasyonları, IPv6’yı hâlâ etkinleştirmemiş barındırma firmaları ve yalnız IPv4 adresi kabul eden izin listesi formları bu gruba girer. Hedefin IPv6 desteğini araştırmak, adres ailesi uyumsuzluğunu ayıklamak gibi ek adımlar olmadan doğrudan çalışmaya başlarsınız. Ürün HTTP, HTTPS ve SOCKS5 protokolleriyle kullanılır; yani tarayıcıdan komut satırı araçlarına, Python betiklerinden kurumsal entegrasyon sunucularına kadar yaygın istemcilerin hepsi doğrudan bağlanabilir.

Sayfanın üst kısmında ürünün kimler için uygun olduğu, teknik notları ve paketleri zaten listeleniyor. Bu bölüm o listeleri tekrar etmek yerine sabit IP’nin günlük işletmede nasıl yönetileceğini, maliyetin nasıl hesaplanacağını, sık görülen hataların nasıl çözüleceğini ve devreye almadan önce neyin kontrol edileceğini anlatır.

Static IPv4 paketleri IP başına dönemsel modelle faturalanır ve doğrulanmış katalogdaki her paketin dönemi 30 gündür. Bu süreyi bir sözleşme takvimi gibi düşünmek, operasyonu planlamayı kolaylaştırır. Dönem başladığında adresler size tahsis edilir, dönem boyunca aynı kalır ve dönem sonunda yenileme kararı verilir. Bu döngünün her aşamasında yapılması gereken işler farklıdır.

1. Tahsis günü: Panelden adres listesini indirin ve kendi envanterinize kaydedin. Her IP için hangi müşteri, proje veya iş yükü tarafından kullanılacağını yazın. Bu eşleme, ileride bir adres sorun çıkardığında etkisini hızla anlamanızı sağlar.
2. İlk 24 saat: Her adresi ayrı ayrı test edin. Bağlantı kuruluyor mu, çıkış IP’si listedeki adresle aynı mı, hedef sistemler bu adresi kabul ediyor mu? Sorunlu adresi erken fark etmek, dönemin kalanını rahat geçirmenin en ucuz yoludur.
3. Dönem ortası: İzin listelerine eklenen adreslerin hâlâ geçerli olduğunu, iş yüklerinin planlandığı gibi dağıldığını ve hiçbir adresin beklenmedik biçimde aşırı yüklenmediğini gözden geçirin.
4. Dönem bitimine bir hafta kala: Gerçek kullanım oranına bakın. Paketin tamamı kullanılıyor mu, yoksa bir alt pakete inmek mümkün mü? Tersine, yeni projeler bir üst paketi gerektiriyor mu?
5. Yenileme: Yenilemede aynı adreslerin korunup korunmadığını panelde ve sipariş adımında kontrol edin. İzin listelerine bağlı işleriniz varsa bu bilgi, yenileme tarihinden önce netleşmelidir.

Bu döngünün pratik sonucu şudur: static IPv4 bir kez kurulup unutulan bir ürün değil, düzenli bakım isteyen küçük bir altyapı bileşenidir. Bakım yükü azdır ama sıfır değildir. Envanteri düzenli tutan ekipler dönem değişimlerini fark etmeden atlatır; tutmayanlar ise yenileme gününde hangi adresin nerede kullanıldığını aramak zorunda kalır.

Sabit IP’nin en yaygın kullanım nedeni, bir hedef sistemin izin listesine girmektir. Bir müşterinin API’si, bir tedarikçinin sipariş portalı veya kendi şirketinizin yönetim paneli yalnız tanımlı adreslerden gelen istekleri kabul ediyor olabilir. Bu senaryoda proxy adresi, karşı tarafın güvenlik kuralının parçası hâline gelir. O yüzden entegrasyonu dikkatli ve belgelenmiş biçimde yapmak gerekir.

1. İzin listesine eklenecek adresleri seçin. Tek bir adres yerine en az iki adres tanımlamak, birinde sorun çıktığında işi durdurmadan diğerine geçmenizi sağlar.
2. Karşı tarafa adresleri tek tek, CIDR gösterimiyle ya da sistemin istediği biçimde iletin. Tek adres için bu genellikle 203.0.113.10/32 gibi bir yazımdır. Aralık tanımlamaktan kaçının; yalnız size tahsis edilen adresleri bildirin.
3. İstemcinizi yalnız bu adreslerden çıkacak şekilde yapılandırın. Aynı uygulama birden fazla proxy kullanıyorsa izin listesine bağlı istekler için ayrı bir bağlantı profili tanımlayın.
4. Test isteğini proxy üzerinden gönderin ve karşı tarafın günlüklerinde gerçekten bu adresin göründüğünü teyit edin. Yalnız “çalışıyor” demek yetmez; isteğin hangi adresten geldiğini görmek gerekir.
5. Envanterde bu adresleri “izin listesine bağlı” diye işaretleyin. Bu etiket, ileride adres değişikliği veya paket küçültme kararlarında sizi uyarır.
6. Değişiklik prosedürünü yazılı hâle getirin: adres değişirse kime haber verilecek, karşı tarafın güncelleme süresi ne kadar, bu sürede iş nasıl yürüyecek?

Burada iki kavramı karıştırmamak önemlidir. Birincisi, hedef sistemin sizin proxy IP’nizi izin listesine eklemesidir; bu rehberin konusu budur. İkincisi, proxy hizmetine bağlanırken kimlik doğrulamanın nasıl yapılacağıdır; kullanıcı adı ve şifre ya da kendi sunucu adresinizi yetkilendirme gibi yöntemlerden hangisinin hesabınızda tanımlı olduğunu panelde kontrol edin. İki ayar birbirinden bağımsızdır ve sorun giderirken ayrı ayrı test edilmelidir.

İzin listesi talebinde adreslerin bir datacenter sağlayıcısına ait olduğunu, hangi amaçla kullanılacağını ve teknik irtibat kişisini kısa bir notla belirtin. Kurumsal güvenlik ekipleri belirsiz taleplere temkinli yaklaşır; açık bir not onay sürecini hızlandırır ve sonradan yaşanacak soruları azaltır.

Pek çok web uygulaması oturumu yalnız çerezle değil, çerezle birlikte görülen IP adresiyle de ilişkilendirir. Oturum açtığınız adres ile sonraki isteklerin geldiği adres farklıysa uygulama bunu çalınmış oturum belirtisi sayabilir, sizi yeniden giriş ekranına gönderebilir veya ek doğrulama isteyebilir. Static IPv4 bu sorunu kökünden çözer, çünkü oturum boyunca adres değişmez.

Ancak sabit IP tek başına yeterli değildir. Oturumun tutarlı görünmesi için istemcinin de tutarlı davranması gerekir. Aynı hesaba farklı tarayıcı profillerinden, farklı dil ve saat dilimi ayarlarıyla girmek, IP sabit olsa bile şüphe uyandırabilir. Burada amaç kimlik gizlemek değil, meşru bir kullanıcının doğal olarak yaptığı gibi tutarlı bir çalışma ortamı sunmaktır.

• Bir hesap, bir IP: Her hesabı veya oturumu tek bir sabit adrese eşleyin ve bu eşlemeyi envanterde tutun. Aynı hesabın gün içinde farklı adreslerden görünmesi en sık yaşanan oturum kopması nedenidir.
• Çerez deposunu kalıcı tutun: Otomasyon betikleri her çalıştırmada sıfırdan oturum açmak yerine oturum çerezini güvenli biçimde saklayıp yeniden kullanmalıdır. Bu, hem hedef sisteme binen yükü hem de giriş denemesi sayısını azaltır.
• Saat dilimi ve dil uyumu: Seçtiğiniz ülke ile istemci ayarları arasında bariz bir çelişki olmamasına dikkat edin. Bu, özellikle yerel içerik gösteren panellerde raporların doğru dilde ve doğru bölge ayarlarıyla gelmesini de sağlar.
• Bağlantı havuzu: Uygulama içinde HTTP bağlantılarını yeniden kullanmak hem gecikmeyi düşürür hem de hedefe daha doğal bir trafik deseni sunar. Her istek için yeni TLS el sıkışması yapmak gereksiz yüktür.

Teknik ekipler için ölçülebilir bir hedef koymak faydalıdır: belirli bir süre içinde kaç oturumun beklenmedik biçimde sonlandığını kendi günlüklerinizden sayın. Sabit IP’ye geçtikten sonra bu sayı düşmüyorsa sorun büyük olasılıkla adreste değil, istemci yapılandırmasındadır. Bu ayrımı yapmak, gereksiz paket büyütmenin önüne geçer.

SEO izlemede veri kalitesi tekrarlanabilirliğe bağlıdır. Bir anahtar kelimenin sırasını, bir sayfanın yanıt süresini veya bir rakibin fiyat sayfasını ölçerken her seferinde farklı bir ağdan bakarsanız sonuçlardaki değişimin ne kadarının gerçek, ne kadarının ölçüm koşulundan kaynaklandığını ayırt etmek zorlaşır. Sabit IP, ölçüm koşullarından birini sabitleyerek karşılaştırmayı anlamlı kılar.

Doğrulanmış katalogda static IPv4 için beş ülke listelenir: Amerika Birleşik Devletleri, Birleşik Krallık, Hollanda, Almanya ve Kanada. Bu ülkeler, İngilizce ve Avrupa pazarlarına yönelik raporlama için doğal bir başlangıç noktasıdır. Türkiye veya listede olmayan başka bir pazar için yerel sonuç gerekiyorsa sabit IPv4 yerine kataloğun diğer ürünlerindeki ülke seçeneklerini incelemek gerekir.

• Ölçüm takvimini sabitleyin: Aynı sorguyu her gün aynı saatte, aynı adresten çalıştırın. Değişken sayısı azaldıkça rapordaki dalgalanma daha kolay yorumlanır.
• Adresleri pazarlara bölün: Örneğin Almanya adreslerini yalnız Almanca sorgulara, Birleşik Krallık adreslerini yalnız İngilizce sorgulara ayırın. Karışık kullanım, sonuçların hangi bölge bağlamında üretildiğini belirsizleştirir.
• İstek hızını makul tutun: Arama motorları ve hedef siteler kısa sürede yoğun sorgu gelen adresleri kısıtlayabilir. İşi daha fazla adrese yaymak ve istekler arasına bekleme koymak, hem kurallara saygılı hem de daha istikrarlı bir yöntemdir.
• Ham yanıtı saklayın: Sıra verisinin yanında yanıt kodunu ve sayfanın kısa bir özetini de kaydedin. Bir gün sonuçlar tuhaf görünürse, sorunun hedefte mi yoksa ölçüm hattında mı olduğunu bu kayıt söyler.

Bir datacenter IP’si internete çıktığında hedef sistem onu tek başına değil, ait olduğu bağlamla birlikte değerlendirir. Bu bağlamın üç katmanı vardır. En üstte otonom sistem numarası, yani ASN bulunur; adresin hangi ağ işletmecisine ait olduğunu gösterir. Ortada alt ağ, yani adresin içinde bulunduğu blok yer alır. En altta da adresin kendi geçmişi, yani itibarı vardır. Bir hedef, isteklerinizi bu üç katmanın her birinde farklı ağırlıklarla değerlendirebilir.

ASN düzeyinde datacenter adresleri genellikle barındırma ve bulut işletmecilerine ait görünür. Bazı hedefler bu tür ağlardan gelen trafiğe varsayılan olarak daha temkinli yaklaşır; bu, ürünün doğasından gelen bir sınırdır ve sabit IP bunu değiştirmez. Ürün sayfasında belirtildiği gibi, residential kimlik bekleyen sıkı hedefler bu ürünün doğru kullanım alanı değildir. Ancak izin listesine dayalı entegrasyonlarda ve kurumsal paneller gibi sizi zaten tanıyan sistemlerde ASN türü sorun olmaz, çünkü karşı taraf adresi bilerek kabul etmiştir.

Alt ağ çeşitliliği, aynı paketteki adreslerin kaç farklı bloğa yayıldığıyla ilgilidir. Hedef sistemler bazen tek tek adresleri değil, bütün bir bloğu sınırlar. Bütün adresleriniz aynı bloktaysa tek bir blok kararı tüm işinizi etkileyebilir; adresler farklı bloklara dağılmışsa etki sınırlı kalır. Paketinizdeki adreslerin blok dağılımını teslimden sonra kendiniz çıkarabilirsiniz: adresleri ilk üç oktete göre gruplamak, kabaca kaç farklı /24 bloğu kullandığınızı gösterir.

from collections import Counter

# ips.txt: panelden indirilen, her satırda bir IPv4 adresi olan liste
with open("ips.txt", encoding="utf-8") as f:
    ips = [line.strip() for line in f if line.strip()]

blocks = Counter(".".join(ip.split(".")[:3]) + ".0/24" for ip in ips)

print("Toplam adres:", len(ips))
print("Farklı /24 bloğu:", len(blocks))
for block, count in blocks.most_common(10):
    print(block, count)

Bu çıktıyı iş yükü dağılımında kullanın. Kritik bir izin listesine iki adres ekleyecekseniz, mümkünse farklı bloklardan seçin. SEO ölçümünü pazarlara bölerken her pazara birden fazla bloktan adres verin. Böylece tek bir blokta yaşanan sorun bir pazarın tamamını kör bırakmaz.

İtibar konusunda en etkili araç sizin kendi davranışınızdır. Bir adresin itibarı, ondan çıkan trafiğin niteliğiyle şekillenir. Aşırı hızlı, hatalı veya hedefin kurallarına aykırı istekler o adresin ve dolaylı olarak bloğunun itibarını aşındırır. Sabit IP’de bu etki birikimlidir: dönen havuzda kötü bir dakika dağılır, sabit adreste ise aynı adresin sicilinde kalır. Bu yüzden static IPv4 kullanan ekiplerin istek hızını, hata oranını ve yanıt kodlarını adres bazında izlemesi önerilir.

Doğrulanmış katalogda static IPv4 için dört paket bulunur. Hepsi USD cinsinden ve 30 günlük dönem için fiyatlandırılmıştır. Paketler büyüdükçe IP başına maliyet düşer; ancak doğru paket, en ucuz birim fiyatı veren değil, gerçek ihtiyacınızı en az atıl adresle karşılayandır.

Tablodaki günlük değerler dönem fiyatının 30’a bölünmesiyle hesaplanmıştır ve yalnız karşılaştırma amaçlıdır; faturalama gün bazında değil, dönem bazında yapılır. Dikkat çeken nokta, birim fiyattaki düşüşün en çok ilk adımda yaşanmasıdır: 100 IP’den 250 IP’ye geçince IP başına maliyet 0,15 USD’den 0,10 USD’ye iner. Sonraki adımlarda düşüş daha sınırlıdır.

Paketleri bölmenin tek gerekçesi maliyet değildir. Farklı müşterilere ait işleri ayrı paketlerde tutmak, faturalamayı ve dönem yönetimini müşteri bazında ayırmanızı sağlar. Bir müşteriyle çalışma bittiğinde ilgili paketi yenilememek, büyük bir paketi küçültmekten daha temizdir. Ayrıca farklı ülkelere ihtiyaç duyuyorsanız ülke seçiminin paket düzeyinde mi yapıldığını sipariş adımında kontrol edin; bu durum paket bölme kararını doğrudan etkiler.

Gerçekçi bir senaryo üzerinden gidelim. Bir ajans 12 müşteri için SEO izleme yapıyor ve her müşteriye ortalama 15 adres ayırmak istiyor; ayrıca iki kurumsal müşterinin paneline erişim için toplam 6 adres izin listesine eklenecek. Toplam ihtiyaç 12 × 15 + 6 = 186 adrestir. 100 IP’lik paket yetmez; 250 IP’lik paket 25 USD’ye ihtiyacı karşılar ve 64 adres yedek kalır. Bu yedek, ölçümde sorun çıkaran adresleri değiştirmek ve yeni müşteri eklemek için tampon görevi görür. Adres başına fiili maliyet 25 / 186 ile yaklaşık 0,13 USD olur; müşteri başına aylık proxy maliyeti ise 15 adres için yaklaşık 2 USD’dir. Ajans altı ay içinde müşteri sayısını ikiye katlamayı planlıyorsa 500 IP’lik pakete geçiş, ihtiyaç 250’yi aştığı dönemde değerlendirilmelidir.

Ürün HTTP, HTTPS ve SOCKS5 ile kullanılabildiği için istemci seçimi geniştir. Aşağıdaki örneklerde kimlik bilgileri ve uç nokta yer tutucu olarak yazılmıştır. Gerçek adres, port ve kimlik doğrulama bilgilerini panelinizden alın. Örneklerdeki çıkış IP’si doğrulaması için kendi kontrol ettiğiniz bir IP yansıtma uç noktasını veya hedef sistemin günlüklerini kullanın.

# HTTP proxy üzerinden
curl -x "http://KULLANICI:SIFRE@PROXY_IP:PORT" https://IP_KONTROL_ADRESI

# SOCKS5 üzerinden; DNS çözümlemesini proxy tarafına bırakmak için socks5h
curl -x "socks5h://KULLANICI:SIFRE@PROXY_IP:PORT" https://IP_KONTROL_ADRESI

# Yalnız bağlantı süresini ölçmek için
curl -o /dev/null -s -w "baglanti=%{time_connect} tls=%{time_appconnect} toplam=%{time_total}\n" \
  -x "http://KULLANICI:SIFRE@PROXY_IP:PORT" https://hedef.example

import requests

PROXY = "http://KULLANICI:SIFRE@PROXY_IP:PORT"

session = requests.Session()
session.proxies = {"http": PROXY, "https": PROXY}
session.headers.update({"Accept-Language": "en-GB,en;q=0.9"})

# Aynı Session nesnesi çerezleri ve bağlantıları yeniden kullanır
r = session.get("https://hedef.example/panel", timeout=20)
print(r.status_code)

# SOCKS5 için: pip install "requests[socks]" ve
# PROXY = "socks5h://KULLANICI:SIFRE@PROXY_IP:PORT"

Tarayıcı tabanlı işlerde her sabit adres için ayrı bir tarayıcı profili açmak en temiz yöntemdir. Profil, kendi çerezlerini, eklentilerini ve proxy ayarını taşır; böylece bir hesabın oturumu yanlışlıkla başka bir adresle açılmaz. İşletim sistemi düzeyinde proxy tanımlamak ise o makinedeki bütün trafiği aynı adrese yönlendirir. Bu, tek amaçlı bir sanal makine için uygundur ama karışık kullanılan bir iş istasyonunda hatalı yönlendirme riskini artırır.

Komut satırı araçlarının çoğu HTTP_PROXY ve HTTPS_PROXY ortam değişkenlerini tanır. Bu değişkenleri yalnız ilgili betiğin çalıştığı kabukta tanımlamak, sistem genelinde kalıcı ayar yapmaktan daha güvenlidir. NO_PROXY değişkeniyle iç ağ adreslerinizi proxy dışında tutmayı da unutmayın; aksi hâlde şirket içi servislere giden istekler de dışarı çıkmaya çalışır ve beklenmedik hatalar üretir.

Sabit IP ile çalışan sistemlerde sorunların büyük bölümü dört başlıkta toplanır: proxy’ye bağlanamama, proxy’ye bağlanıp hedefe ulaşamama, hedefin adresi reddetmesi ve oturumun beklenmedik biçimde kopması. Aşağıdaki tablo, her belirti için ilk bakılması gereken yeri gösterir.

Sorun giderirken her zaman en dış katmandan başlayın. Önce proxy’ye bağlanabildiğinizi, sonra çıkış IP’sinin beklenen adres olduğunu, en son da hedefin yanıtını kontrol edin. Bu sıralama, hedef tarafındaki bir engeli proxy arızası sanmak gibi yaygın bir yanılgıyı önler. Her testte zamanı, kullanılan adresi ve yanıt kodunu not etmek, destek ekibiyle iletişimi de hızlandırır.

Static IPv4 her işin cevabı değildir. Aşağıdaki tablo, iş yükünün baskın gereksinimine göre katalogdaki hangi ürün ailesinin daha uygun olduğunu özetler. Fiyat modelleri farklı olduğu için karşılaştırmayı birim fiyattan değil, iş yükünün doğasından başlatmak gerekir.

Pek çok ekip sonunda karma bir yapı kurar: izin listesine bağlı entegrasyonlar ve oturumlu paneller için küçük bir static IPv4 paketi, geniş veri toplama için dönen bir ürün. Bu ayrım hem maliyeti hem de risk dağılımını iyileştirir, çünkü kritik sabit adresler yüksek hacimli işlerin yarattığı itibar riskinden korunur.

Aşağıdaki liste, yeni bir static IPv4 paketini üretim işlerine bağlamadan önce gözden geçirilmesi gereken noktaları toplar. Listeyi ekibinizin iç dokümantasyonuna kopyalayıp her yeni dönemde yeniden kullanabilirsiniz.

• Paket büyüklüğü bugünkü ihtiyaç artı makul tamponla eşleşiyor mu?
• Ülke seçimi, izlenecek pazarlarla uyumlu mu ve sipariş adımında doğru seçildi mi?
• Adres listesi indirildi, envantere işlendi ve her adres bir iş yüküne eşlendi mi?
• Her adres için bağlantı ve çıkış IP’si testi yapıldı mı?
• Adreslerin /24 blok dağılımı çıkarıldı ve kritik işler farklı bloklara yayıldı mı?
• İzin listesine eklenen adresler karşı tarafın günlüklerinde doğrulandı mı?
• Proxy kimlik doğrulama yöntemi panelde kontrol edildi ve kimlik bilgileri güvenli bir yerde saklanıyor mu?
• İstemcilerde NO_PROXY ile iç ağ adresleri dışarıda bırakıldı mı?
• Adres bazında hata oranı ve yanıt kodu izleme kuruldu mu?
• İstek hızları hedef sistemlerin kurallarına uygun mu?
• Yenileme tarihi takvimde, sorumlusu belli ve hatırlatma kurulu mu?
• Adres değişikliği gerekirse kime haber verileceği yazılı mı?

Bu listenin her maddesi küçük görünür, ama birlikte bakıldığında static IPv4’ün asıl değerini korurlar: adresin sabit olması, ancak etrafındaki süreç de sabit ve belgelenmiş olduğunda işe yarar. Envanteri tutulan, izlenen ve zamanında yenilenen bir sabit IP paketi, izin listesine bağlı entegrasyonlarda ve tekrarlanabilir ölçümlerde ekibinize uzun süre sorunsuz hizmet eder.