Static IPv6 Datacenter Proxy

IPv4 dünyasında adres kıt bir kaynaktır ve fiyatı bu kıtlığı yansıtır. IPv6’da durum terstir: adres alanı o kadar geniştir ki sağlayıcılar büyük bloklarla çalışabilir ve adres başına maliyet belirgin biçimde düşer. Static IPv6 datacenter proxy satın aldığınızda, bu geniş alandan size ayrılmış ve ay boyunca değişmeyen bir adres kümesi alırsınız. Ürünün asıl vaadi tek bir adresin kalitesi değil, çok sayıda sabit adresi yönetilebilir bir bütçeyle kullanabilmektir.

Bu fark rakamlara da yansır. Doğrulanmış katalogda 1000 adetlik static IPv6 paketi aylık 20 USD’dir; aynı adette static IPv4 paketi 30 günlük dönem için 80 USD’dir. Yani benzer adet için IPv6 tarafında yaklaşık dörtte bir maliyetle çalışırsınız. Ancak bu karşılaştırma yalnız hedef sistem IPv6 kabul ediyorsa anlamlıdır. IPv6 konuşmayan bir hedef için ucuz adres, hiç adres olmamasıyla aynı sonucu verir.

Bu yüzden bu rehber, alışılmış “ürün nedir” sırası yerine bir mühendislik sırası izler: önce hedefinizin IPv6 konuşup konuşmadığını test eder, sonra adres yapısını ve paket ekonomisini inceler, ardından binlerce adresin nasıl yönetileceğini, IPv6 yolunun kapalı olduğu durumda nasıl geri düşüleceğini ve sık görülen hataların nasıl çözüleceğini anlatır. Protokol tarafında ürün HTTP, HTTPS ve SOCKS5 ile kullanılır; bu da mevcut istemcilerinizin büyük ölçüde değişmeden çalışacağı anlamına gelir.

Bir hedefin IPv6 üzerinden erişilebilir olması için iki koşul gerekir: alan adının IPv6 adresini gösteren bir AAAA kaydı olmalı ve o adreste gerçekten çalışan bir servis bulunmalıdır. Bazı siteler AAAA kaydı yayınlar ama IPv6 tarafında eksik yapılandırılmıştır; bazıları ana sayfayı IPv6’dan sunar ama API veya giriş alt alan adları yalnız IPv4’tür. Bu yüzden test tek bir alan adıyla değil, kullanacağınız her uç noktayla yapılmalıdır.

1. Hedef listenizi çıkarın: Ana alan adı yetmez; giriş, API, statik dosya ve yönlendirme yapılan alt alan adlarını da yazın. Bir tarayıcı oturumunda geliştirici araçlarının ağ sekmesi, sayfanın gerçekte hangi alan adlarına istek attığını gösterir.
2. AAAA kaydını sorgulayın: Her alan adı için IPv6 adresi yayınlanıp yayınlanmadığına bakın. Kayıt yoksa o alan adı IPv6 çıkışından doğrudan erişilemez.
3. IPv6 üzerinden gerçek bir istek gönderin: Kayıt olması servisin çalıştığını kanıtlamaz. IPv6 bağlantısı olan bir makineden yalnız IPv6 kullanarak istek atın ve yanıt kodunu kaydedin. Kendi ağınızda IPv6 yoksa sitedeki IPv6 Destek Kontrolü aracı ön fikir verir.
4. Sonuçları sınıflandırın: Her uç noktayı “tam IPv6”, “kısmi” veya “yalnız IPv4” diye etiketleyin. Bu tablo hem paket büyüklüğünü hem de geri düşme planınızı belirler.
5. Küçük bir pilotla doğrulayın: Türkiye, Almanya ve ABD için 100 IP’lik paket aylık 2 USD’dir. Bu ülkelerden biri işinize uygunsa, büyük pakete geçmeden önce gerçek iş yükünüzü bu küçük paketle denemek ucuz bir sigortadır.

# 1) AAAA kaydı var mı?
dig AAAA hedef.example +short
nslookup -type=AAAA hedef.example

# 2) Yalnız IPv6 kullanarak doğrudan istek (makinenizde IPv6 varsa)
curl -6 -sS -o /dev/null -w "%{http_code} %{remote_ip}\n" https://hedef.example

# 3) Proxy üzerinden istek; DNS çözümlemesi proxy tarafında yapılır
curl -sS -o /dev/null -w "%{http_code}\n" \
  -x "socks5h://KULLANICI:SIFRE@PROXY_ADRESI:PORT" https://hedef.example

Üçüncü test özellikle önemlidir, çünkü gerçek kullanım koşulunu taklit eder. HTTP proxy ve socks5h kullanımında alan adı sizin makinenizde değil, proxy tarafında çözülür. Proxy’nin IPv6 çıkışı, hedefin AAAA kaydını kullanarak bağlantı kurar. Hedefte AAAA kaydı yoksa ne olacağını, yani hizmetin bu durumda nasıl davrandığını kendi testlerinizle görün ve gerekirse panelde veya destek ekibiyle teyit edin.

IPv6 adresi 128 bittir ve iki nokta üst üste ile ayrılmış sekiz gruptan oluşur. Pratikte adresin ilk yarısı ağı, ikinci yarısı ağ içindeki arabirimi tanımlar. Yaygın uygulamada bir yerel ağ segmentine /64 önek verilir; bir kuruma veya müşteriye ise /48 ya da /56 gibi daha büyük bir blok ayrılır. 2001:db8:1234:5678::/64 yazımı, ilk dört grubu sabit olan ve geri kalan 64 bitte sayısız adres barındıran bir segmenti ifade eder.

Bu yapı, proxy kullanıcıları için önemli bir sonuç doğurur. IPv4’te tek bir adres genellikle tek bir istemciyi temsil eder. IPv6’da ise tek bir kullanıcı ya da cihaz aynı /64 içinde çok sayıda adres kullanabildiği için, birçok hedef sistem hız sınırlarını ve itibar kararlarını tek adres yerine /64 düzeyinde uygular. Yani aynı /64 içindeki bin farklı adres, hedefin gözünde tek bir istemci gibi görünebilir. Bu, paketinizdeki adres sayısının hedef tarafında her zaman aynı sayıda bağımsız kimliğe dönüşmediği anlamına gelir.

Teslim edilen adres listenizin önek dağılımını kendiniz çıkarabilirsiniz. Aşağıdaki betik, adresleri /64 ve /48 öneklerine göre gruplar. Çıktı, iş yüklerini nasıl dağıtacağınıza karar vermenin temelidir: bağımsız görünmesi gereken iş akışlarını farklı öneklere, aynı mantıksal istemciye ait işleri ise aynı öneke yerleştirmek tutarlı bir yaklaşımdır.

import ipaddress
from collections import Counter

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

by64 = Counter(ipaddress.IPv6Network((int(a) >> 64 << 64, 64)) for a in addrs)
by48 = Counter(ipaddress.IPv6Network((int(a) >> 80 << 80, 48)) for a in addrs)

print("Adres:", len(addrs), "| farklı /64:", len(by64), "| farklı /48:", len(by48))
for net, n in by64.most_common(5):
    print(net, n)

Doğrulanmış katalogda static IPv6 için 19 ülke listelenir ve her paket kaydı bir ülke koduna bağlıdır. Ülkeler paket seçenekleri bakımından iki gruba ayrılır. Türkiye, Almanya ve Amerika Birleşik Devletleri için 100 IP’den 10.000 IP’ye kadar altı paket bulunur. Diğer 16 ülkede ise yalnız 1000, 5000 ve 10.000 IP’lik paketler vardır.

Bu yapının pratik sonucu açıktır. Türkiye, Almanya veya ABD’de çalışıyorsanız küçük başlayıp ihtiyaç büyüdükçe paket büyütebilirsiniz. Japonya, Brezilya veya Güney Afrika gibi bir pazar için ise en küçük giriş noktası 1000 IP ve aylık 20 USD’dir. Bu, tek bir pazarda birkaç düzine adrese ihtiyaç duyan ekipler için atıl adres demektir; ama bu fiyat seviyesinde atıl adresin maliyeti de sınırlıdır.

Ülke seçerken iki ölçüt öne çıkar. Birincisi içerik bağlamıdır: hedef sistem konuma göre farklı içerik, fiyat veya dil sunuyorsa, ölçmek istediğiniz pazarın ülkesini seçmeniz gerekir. İkincisi ağ yakınlığıdır: konuma duyarlı olmayan işlerde hedef sunucuya coğrafi olarak yakın bir çıkış seçmek, gidiş dönüş süresini kısaltma eğilimindedir. Bu ikinci ölçütü kendi ölçümlerinizle doğrulayın; ağ yolları her zaman haritadaki mesafeyi izlemez.

Static IPv6 paketlerinde IP başına maliyet ilk dört kademede sabittir ve büyük paketlerde düşer. Aşağıdaki tablo, doğrulanmış paket fiyatlarından türetilmiş birim maliyetleri gösterir. Faturalama aylıktır.

Birim maliyet 1000 IP’ye kadar değişmediği için küçük paketler arasında seçim yaparken tek ölçüt ihtiyaç duyduğunuz adettir; büyük paket almanın bu aralıkta birim fiyat avantajı yoktur. Eşik noktaları 1000 IP’nin üzerinde ortaya çıkar ve bu noktaları bilmek gereksiz harcamayı önler.

Buradan basit eşik kuralları çıkar. Türkiye, Almanya ve ABD’de küçük paketler ince ayar yapmaya izin verdiği için 2500 IP’ye kadar küçük paket birleşimi en fazla 5000 IP’lik paketle aynı fiyata gelir; 2500 IP’yi aşan ihtiyaçta 5000 IP’lik paket ucuzdur. 7000 IP’de 10.000 IP’lik paket aynı fiyata 3000 adres fazla verir, daha yukarısında ise daha ucuzdur. Yalnız 1000’lik kademeden başlayan 16 ülkede eşikler daha erkendir: 2000 IP’yi aşan her ihtiyaç üç adet 1000’lik paket gerektirdiği için 5000 IP’lik paket ucuza gelir, 6000 IP’yi aşan ihtiyaçta da 10.000 IP’lik paket aynı fiyata ya da daha ucuza çıkar. Bu kurallar yalnız aynı ülke için geçerlidir; farklı ülkelerdeki ihtiyaçlar ayrı paketlerle karşılanır.

Çok ülkeli bir senaryoya bakalım. Bir fiyat izleme ekibi, IPv6 desteğini doğruladığı bir pazar yeri ağında Japonya, Brezilya, Hindistan ve Almanya için ayrı ölçüm hatları kurmak istiyor. Her pazarda birkaç yüz adres yeterli; ancak Japonya, Brezilya ve Hindistan’da en küçük paket 1000 IP olduğu için bu üç ülke 3 × 20 = 60 USD tutar. Almanya’da 500 IP’lik paket yeterlidir ve 10 USD’dir. Toplam aylık maliyet 70 USD olur ve ekibin elinde 3500 sabit adres bulunur; adres başına ortalama maliyet 70 / 3500 ile 0,02 USD’dir. Aynı ekip her pazarda yalnız 300 adres kullanıyorsa fiilen kullanılan 1200 adres için adres başına maliyet yaklaşık 0,058 USD’ye çıkar. Bu hâliyle bile, kullanılmayan adresler daha fazla iş akışını ayrı öneklere dağıtmak için yedek kapasite işlevi görür.

Yüz adresi bir elektronik tabloda takip etmek mümkündür; on bin adresi aynı yöntemle yönetmek değildir. Static IPv6’nın ölçek avantajından yararlanmak için adresleri bir envanter sistemiyle, programatik olarak yönetmek gerekir. Bu bölüm küçük ekiplerin bile uygulayabileceği hafif bir düzen önerir.

Doğrudan bağlantılarda modern işletim sistemleri ve tarayıcılar, IPv6 yolu çalışmadığında otomatik olarak IPv4’e geçen bir mekanizma kullanır. Proxy üzerinden çalışırken bu otomatik geçiş sizin istemcinizde değil, proxy tarafında gerçekleşir ve yalnız IPv6 çıkış veren bir hizmette IPv4’e geçiş beklenmemelidir. Bu durumda geri düşme kararını uygulamanızın kendisi vermelidir.

Sağlam bir geri düşme düzeni üç parçadan oluşur. Önce hangi hedeflerin IPv6’dan erişilebilir olduğunu bilen bir yönlendirme tablosu kurulur; bu tablo ikinci bölümdeki testlerden beslenir. Sonra IPv6 çıkışından gelen hatalar sınıflandırılır: bağlantı kurulamaması veya proxy’nin hedefe ulaşamadığını bildiren yanıtlar geri düşmeyi tetikler, hedefin kendi verdiği 403 veya 429 gibi yanıtlar ise tetiklemez, çünkü bunlar adres ailesiyle değil, isteğin kendisiyle ilgilidir. Son olarak geri düşülen istekler kaydedilir ve yönlendirme tablosu periyodik olarak güncellenir.

import requests

IPV6_PROXY = "http://KULLANICI:SIFRE@PROXY_ADRESI_V6:PORT"
IPV4_PROXY = "http://KULLANICI:SIFRE@PROXY_ADRESI_V4:PORT"

# Testlerle yalnız IPv4 olduğu bilinen hedefler doğrudan IPv4 hattına gider
IPV4_ONLY = {"eski-sistem.example"}

def fetch(url, host):
    order = [IPV4_PROXY] if host in IPV4_ONLY else [IPV6_PROXY, IPV4_PROXY]
    last_error = None
    for proxy in order:
        try:
            r = requests.get(url, proxies={"http": proxy, "https": proxy}, timeout=15)
            # 502/503/504: proxy hedefe ulaşamadı, bir sonraki hatta geç
            if r.status_code in (502, 503, 504) and proxy is not order[-1]:
                continue
            return r
        except (requests.ConnectionError, requests.Timeout) as e:
            last_error = e
    raise last_error

Bu örnekte IPv4 hattı olarak kendi tercih ettiğiniz bir IPv4 çıkışı kullanılır; katalogdaki static IPv4 veya rotating IPv4 ürünleri bu rolü üstlenebilir. Geri düşmenin maliyetini de hesaba katın: IPv4 hattına giden her istek daha pahalı bir kaynaktan tüketir. Geri düşme oranı yüksekse sorun büyük olasılıkla hedef listenizdedir ve bu hedeflerin baştan IPv4 hattına yönlendirilmesi daha verimli olur.

Proxy uç noktası bir alan adı veya IPv4 adresi olarak verilmişse istemci yapılandırması IPv4 ürünlerinden farksızdır. Uç nokta bir IPv6 adresi olarak verilmişse adresin köşeli parantez içine alınması gerekir; aksi hâlde istemci adresin içindeki iki nokta üst üsteyi port ayracı sanar. Proxy uç noktasının hangi biçimde verildiğini ve hangi kimlik doğrulama yönteminin tanımlı olduğunu panelinizden kontrol edin.

# Uç nokta IPv6 adresi ise köşeli parantez zorunludur (2001:db8:: belge aralığıdır)
curl -x "http://KULLANICI:SIFRE@[2001:db8::10]:PORT" https://hedef.example

# Kabuk oturumu için ortam değişkenleri
export HTTPS_PROXY="http://KULLANICI:SIFRE@PROXY_ADRESI:PORT"
export HTTP_PROXY="$HTTPS_PROXY"
export NO_PROXY="localhost,127.0.0.1,::1,.ic-ag.example"

DNS çözümlemesinin nerede yapıldığı IPv6 senaryolarında belirleyicidir. SOCKS5 kullanırken socks5 yerine socks5h şemasını seçmek, alan adının proxy tarafında çözülmesini sağlar. Çözümleme sizin makinenizde yapılırsa ve makinenizde IPv6 bağlantısı yoksa, yerel çözümleyici yalnız IPv4 adresini tercih edebilir ve istek IPv6 çıkışının amacına aykırı biçimde IPv4 hedef adresine yönlenir. HTTP proxy kullanımında istemciler alan adını genellikle doğrudan proxy’ye iletir, bu yüzden bu sorun daha az görülür.

Tarayıcı tabanlı işlerde, proxy ayarının yanında WebRTC ve benzeri özelliklerin yerel ağ bilgisini sızdırmadığından emin olun. Bu, gizlenme amacıyla değil, ölçümün gerçekten seçtiğiniz çıkış adresinden yapıldığını garanti etmek için gereklidir; aksi hâlde ölçüm verisi iki farklı ağ bağlamının karışımı olur. Uzun süre çalışan otomasyonlarda bağlantıları yeniden kullanmak, IPv6’da da TLS el sıkışma maliyetini azaltır.

IPv6’ya özgü hataların çoğu adres ailesi uyumsuzluğundan kaynaklanır. Aşağıdaki tablo, en sık karşılaşılan belirtileri ve ilk bakılması gereken yeri özetler. Her teşhiste önce proxy’ye bağlanıp bağlanamadığınızı, sonra çıkış adresinin gerçekten IPv6 olup olmadığını, en son hedefin yanıtını kontrol edin.

Teşhis sırasında topladığınız bilgiler, destek ekibine iletildiğinde çözüm süresini kısaltır: kullanılan adres, önek, ülke, hedef alan adı, zaman damgası, yanıt kodu ve mümkünse curl çıktısı. Tek bir başarısız istek yerine bir örneklem sunmak, sorunun adres, önek veya hedef düzeyinde olup olmadığını netleştirir.

Çok sayıda sabit adrese sahip olmak, hedef sistemlere daha fazla yük bindirme kapasitesi de demektir. Bu kapasiteyi sorumlu kullanmak hem etik bir yükümlülük hem de uzun vadede işin sürdürülebilirliği için gereklidir. Hedef sistemin kullanım şartlarını okuyun; resmi bir API varsa önce onu değerlendirin; robots yönergelerine ve hız sınırlarına uyun; kişisel verileri yalnız yasal dayanağınız olduğu ölçüde işleyin.

Teknik açıdan da sorumlu kullanım kendini öder. Önek başına makul istek hızları, istekler arasında bekleme süreleri ve hatalarda üstel geri çekilme, adreslerinizin itibarını korur. Hedefin açıkça engellediği bir trafiği adres değiştirerek sürdürmeye çalışmak ise hem kurallara aykırıdır hem de bütün önek bloklarının toptan sınırlanmasına yol açabilir. Static IPv6’nın sunduğu ölçek, engel aşmak için değil, meşru işleri daha düzenli ve daha ince bölünmüş biçimde yürütmek için kullanılmalıdır.

Aşağıdaki liste, static IPv6 paketini üretim iş yüklerine bağlamadan önce tamamlanması gereken adımları toplar. Her yeni ülke veya paket eklediğinizde aynı listeyi yeniden çalıştırın.

• Kullanılacak her alan adı ve alt alan adı için AAAA kaydı ve yalnız IPv6 ile erişim testi yapıldı mı?
• Hedefler tam IPv6, kısmi ve yalnız IPv4 olarak sınıflandırıldı mı?
• Yalnız IPv4 ve kısmi hedefler için ayrı bir IPv4 çıkış hattı planlandı mı?
• Ülke seçimi içerik bağlamına ve ağ yakınlığına göre yapıldı mı?
• Paket büyüklüğü, ülkenin paket kademesine göre değişen 5000 ve 10.000 IP eşik noktaları dikkate alınarak seçildi mi?
• Adres listesi indirildi, standart biçime çevrildi ve /64 ile /48 öneklerine göre gruplandı mı?
• İş akışları farklı önek gruplarına atandı ve atama envanterden okunuyor mu?
• Önek ve adres başına istek hızı üst sınırları tanımlandı mı?
• SOCKS5 kullanılıyorsa socks5h şeması seçildi mi; IPv6 uç noktaları köşeli parantezle yazıldı mı?
• Geri düşme mantığı test edildi ve geri düşen istekler kaydediliyor mu?
• Önek bazlı sağlık kontrolü ve hata oranı izleme kuruldu mu?
• Aylık yenileme tarihi takvimde ve sorumlusu belli mi?

Bu adımlar tamamlandığında static IPv6, düşük birim maliyetiyle geniş ölçekli ve sabit çıkış gerektiren işler için güçlü bir temel oluşturur. Başarının anahtarı, adres sayısının büyüklüğünde değil, o adreslerin hedef uyumu doğrulanmış, öneklere göre düzenlenmiş ve ölçülü biçimde kullanılmasındadır.