Rotating IPv6 Datacenter Proxy

Bu üründe faturanın birimi porttur ve ödeme aylık yapılır. Katalogdaki kısa açıklama ürünü sınırsız bant genişliği modelinde konumlar; yani maliyeti aktardığınız veri miktarı değil, kullandığınız port sayısı belirler. Bu, GB bazlı ürünlerle çalışan ekiplerin alışık olduğu hesabı tersine çevirir. GB modelinde her fazladan bayt bütçeden düşer; port modelinde ise sabit bir aylık tutar ödersiniz ve asıl soru, o portları ay boyunca ne kadar verimli kullandığınız olur. Bant genişliğine ilişkin adil kullanım ya da benzeri bir koşul olup olmadığını sipariş adımında okuyun.

Tablonun beklenmedik sonucu, port başına maliyetin paket büyüdükçe sürekli düşmemesidir. 5 port paketinde port başına 16 USD ödenirken 10 port paketinde bu tutar 17,50 USD’ye çıkar. Katalog fiyatlarıyla iki adet 5 port paketi toplam 160 USD, tek bir 10 port paketi 175 USD tutar. Aynı hesapta birden fazla paket alınıp alınamadığını, portların tek panelden nasıl yönetildiğini ve iki paket arasında teknik bir fark bulunup bulunmadığını sipariş adımında kontrol ettikten sonra karar verin; yalnızca tablo üzerinden kesin hüküm vermeyin.

IPv6 proxy’nin işe yaraması için iki koşul aynı anda sağlanmalıdır: hedef alan adının bir AAAA kaydı yani IPv6 adresi olmalı ve hedef sunucu bu adres üzerinden gerçekten hizmet vermelidir. Birçok büyük platform IPv6’yı tam destekler; buna karşılık bazı küçük siteler, eski e-ticaret altyapıları ve kurumsal paneller yalnız IPv4 üzerinden yayın yapar. Katalog da bu ürünün yalnız IPv4 zorunlu hedeflere uygun olmadığını açıkça belirtir. Aylık port ödemesi yapmadan önce hedef listenizi bu açıdan taramak, ilk ayın boşa gitmesini önleyen en ucuz adımdır.

1. Hedef listenizdeki her alan adını çıkarın; aynı sitenin farklı alt alan adlarını, örneğin www, api ve görsel sunucusunu ayrı satırlar olarak yazın, çünkü IPv6 desteği alt alan adına göre değişebilir.
2. Her alan adı için AAAA kaydı olup olmadığını DNS sorgusuyla kontrol edin. AAAA kaydı yoksa o hedef IPv6 proxy ile çalışmaz.
3. AAAA kaydı olan hedeflerde IPv6 Destek Kontrolü aracını ya da kendi IPv6 bağlantılı bir sunucunuzu kullanarak gerçek bir HTTP isteği gönderin ve yanıtın IPv4 ile aynı içeriği döndürdüğünü doğrulayın.
4. Veri ürettiğiniz uç noktaları, örneğin arama, fiyat ya da API yollarını ayrıca test edin. Ana sayfanın IPv6 üzerinden açılması, tüm uç noktaların öyle olduğu anlamına gelmez.
5. Sonuçları üç gruba ayırın: tam IPv6 destekli, kısmen destekli ve yalnız IPv4. Tam destekli hedeflerin toplam iş hacmindeki payını hesaplayın.
6. Bu pay düşükse ya da kritik hedefler yalnız IPv4 ise, port paketine geçmeden önce o hedefler için IPv4 tabanlı bir ürünle çalışmayı planlayın.

# AAAA kaydı var mı?
dig +short AAAA www.example.com

# Doğrudan IPv6 üzerinden istek (yerel makinede IPv6 bağlantısı gerekir)
curl -6 -s -o /dev/null -w "IPv6 durum: %{http_code}\n" https://www.example.com/

# Aynı isteği IPv4 ile karşılaştırma
curl -4 -s -o /dev/null -w "IPv4 durum: %{http_code}\n" https://www.example.com/

# Proxy üzerinden çıkış adresini görmek; sonuç 2001:db8::1 gibi bir IPv6 olmalı
curl -s -x http://KULLANICI:ŞİFRE@GATEWAY:PORT https://api64.ipify.org

Son komutta proxy üzerinden dönen adres bir IPv6 adresi değil de 203.0.113.10 gibi bir IPv4 adresiyse, ya kontrol servisi IPv4 üzerinden yanıt vermiştir ya da istemciniz trafiği IPv6 çıkışından geçirmiyordur. Bu ayrımı bir sonraki bölümde ayrıntılı ele alıyoruz.

IPv6 ile çalışan ekiplerin en sık karşılaştığı ve en geç fark ettiği sorun, trafiğin bir kısmının fark edilmeden IPv4 üzerinden gitmesidir. İşler çalışır, veri gelir, hata yoktur; ama toplanan verinin bir bölümü beklenen yoldan gelmemiştir. Bu durumun üç yaygın kaynağı vardır ve her biri farklı bir önlem gerektirir.

IPv6’nın adres alanı o kadar geniştir ki tek bir kullanıcıya bile milyarlarca adres düşebilir. Bu yüzden IPv6 trafiğini değerlendiren pek çok hedef sistem, tekil adres yerine adres bloğuna bakar. Yaygın uygulama, aynı /64 ya da daha geniş bir prefix içinden gelen istekleri tek bir kaynak gibi saymaktır. Bunun pratik anlamı şudur: rotasyon sayesinde her istekte farklı bir IPv6 adresi kullanmanız, hedefin gözünde farklı ziyaretçiler olduğunuz anlamına gelmeyebilir. Hız sınırı ve itibar değerlendirmesi prefix ya da ASN düzeyinde yapılıyorsa, adres çeşitliliğinin etkisi sınırlı kalır.

Datacenter IPv6 adresleri de IPv4 karşılıkları gibi barındırma şirketlerine ait ASN’lerden yayınlanır. Hedef, trafiğin bir veri merkezinden geldiğini kolayca görebilir. Bu, kamuya açık içerik sunan sitelerin büyük çoğunluğu için sorun değildir; ancak hesap ve ödeme gibi hassas akışlarda daha sıkı inceleme beklenmelidir. IPv6 rotasyonunu bir kimlik gizleme ya da engel aşma aracı olarak düşünmek hem yanlış hem de sürdürülemez bir beklentidir.

Pratik açıdan bu durum, IPv6 portlarınızdaki eşzamanlılığı adres sayısına göre değil hedefin tepkisine göre ayarlamanız gerektiği anlamına gelir. Bir hedefe gönderdiğiniz toplam istek hızını, o hedefin tek bir kurumsal ziyaretçiden kabul edebileceği düzeyde tutun ve 429 yanıtlarını bir uyarı olarak değerlendirin.

Çıkış adresi değiştiğinde hedef sunucu yeni bir bağlantı görür. Durumsuz işlerde, örneğin herkese açık bir sayfayı tek istekte çekmekte, bu sorun yaratmaz. Ancak birden fazla adımdan oluşan akışlarda uygulama durumu IP değişimine duyarlı olabilir. Oturum çerezleri, form doğrulama belirteçleri ve sayfalama imleçleri bazı sitelerde istemcinin IP’siyle ilişkilendirilir; adres değiştiğinde belirteç geçersiz sayılır ve akış başa döner.

Katalog, rotating ürünlerde dönüş politikasının oturum ve istemci ayarına bağlı olduğunu belirtir ve belirli bir rotasyon aralığı taahhüt etmez. Bu yüzden durumlu akışlarınız için panelde bir oturum sabitleme seçeneği olup olmadığını ve varsa nasıl yapılandırıldığını kontrol edin. Böyle bir seçenek yoksa ya da hedef oturumu sıkı bağlıyorsa, o akışları sabit adresli bir ürüne ayırmak daha sağlıklı olur.

• Her akış için ayrı bir HTTP oturumu ve ayrı bir çerez deposu açın; akış bitince ikisini birlikte kapatın.
• Bağlantı havuzunu akış içinde koruyun; açık tutulan bağlantı çoğu istemcide aynı çıkışı kullanmaya devam eder.
• Form ve sayfalama belirteçlerini aldığınız bağlantı içinde tüketin; belirteci kuyrukta bekletip başka bir çalışana devretmeyin.
• Akışın herhangi bir adımında beklenmedik bir yönlendirme ya da giriş sayfası görürseniz akışı baştan, yeni bir oturumla başlatın.
• Yeniden denemeleri akış düzeyinde yapın; tek bir adımı farklı bir çıkıştan yeniden denemek çoğu zaman tutarsız durum üretir.

Katalog SSS’si port sayısının eşzamanlı bağlantı ihtiyacına göre seçilmesini önerir. Ancak bir portun aynı anda kaç bağlantı taşıyabildiği, port başına bir bağlantı ya da hız sınırı olup olmadığı katalogda yazmaz. Bu nedenle port sayısını kâğıt üzerinde değil, tek port ile yapılan bir ölçümle belirlemek gerekir. Ölçümün amacı, bir portla hedefinizde ulaşabildiğiniz sürdürülebilir verimi bulmak ve toplam iş hacminizi bu değere bölmektir.

1. 1 port paketiyle başlayın ve IPv6 destekli hedeflerinizden en yoğun olanını seçin.
2. Aynı port üzerinden eşzamanlı istek sayısını kademeli olarak artırın ve her kademede dakika başına başarılı istek, yüzde 95’lik yanıt süresi ve hata oranını kaydedin.
3. Hata oranının ya da yanıt süresinin belirgin biçimde arttığı ilk kademeyi not edin ve bir alt kademeyi port başına sürdürülebilir verim olarak kabul edin.
4. Bu kırılmanın porttan mı hedeften mi kaynaklandığını anlamak için aynı testi ikinci bir IPv6 destekli hedefe uygulayın; iki hedefte farklı noktalarda kırılıyorsa sınır büyük olasılıkla hedeftedir.
5. Günlük toplam istek ihtiyacınızı port başına sürdürülebilir verime bölün, bakım ve yeniden deneme için yüzde 20 pay ekleyin ve sonucu yukarı yuvarlayın.
6. Bulduğunuz port sayısını katalogdaki 1, 5 ve 10 port paketleriyle eşleştirin ve port başına maliyeti tablodan kontrol edin.

Aşağıdaki senaryo varsayımsaldır ve yöntemi göstermek içindir. Varsayımlar: IPv6 destekli hedeflerde günde 50.000 sayfa toplanır; sayfa başına ortalama aktarım başlıklar ve TLS ek yüküyle 150 KB’tır; yeniden denemeler trafiğe yüzde 10 ekler; hesap kolaylığı için 1 GB yaklaşık 1.000.000 KB kabul edilir. Bu varsayımlarla günlük aktarım 7,5 GB, yeniden deneme payıyla 8,25 GB ve 30 günde yaklaşık 247,5 GB olur. Aynı trafik GB başına 0,60 USD olan rotating IPv4 datacenter ürününde yaklaşık 148,50 USD tutardı. Ölçüm, bu işin 5 portla sürdürülebilir hızda yürüdüğünü gösterirse aylık maliyet 80 USD olur. Ölçüm 10 port gerektiğini gösterirse maliyet 175 USD’ye çıkar ve IPv4 GB modeli bu hacimde daha ucuz kalır.

GB modelinde boşta geçen saatlerin bir maliyeti yoktur; kullanmadığınız veri kotada kalır. Port modelinde ise tam tersi geçerlidir: ay boyunca aynı tutarı ödersiniz ve portların boşta kaldığı her saat, ödediğiniz ama kullanmadığınız kapasitedir. Bu yüzden port bazlı ürünlerde iş zamanlaması, maliyet optimizasyonunun ana aracıdır. Amaç portları sürekli sınırda çalıştırmak değil, günün tamamına dengeli bir yük yaymaktır.

Tipik bir hata, tüm toplama işlerini aynı saatte, örneğin her gün sabah dokuzda başlatmaktır. Bu düzende portlar birkaç saat yoğun çalışır, kalan saatlerde boş kalır ve yoğun saatlerdeki kapasite ihtiyacı yüzünden gerekenden fazla port alınır. Aynı günlük hacmi 24 saate yayan bir kuyruk, çoğu zaman daha küçük bir paketle aynı sonucu verir. Bunun ek bir yararı da vardır: hedefe gönderilen istekler zamana yayıldığı için hedefin gördüğü anlık yük azalır ve 429 yanıtları seyrekleşir.

• Acil olmayan işleri, örneğin haftalık arşiv taramalarını, hedeflerin düşük trafikli saatlerine kaydırın.
• Her hedef için saatlik bir istek bütçesi tanımlayın ve kuyruğu bu bütçeye göre besleyin.
• Önceliklendirme yapın: fiyat ya da stok gibi hızlı değişen veriler için kısa aralık, ürün açıklaması gibi yavaş değişen veriler için uzun aralık kullanın.
• Port kullanım oranını saatlik olarak kaydedin; gün içinde yüzde 30’un altında kalan uzun dönemler varsa paket büyüklüğünü gözden geçirin.
• Bakım ve dağıtım pencerelerini planlarken portların boşta kalacağını hesaba katın ve bu süreyi kuyruğun geri kalanına dağıtın.

Protokol seçimi de kapasite kullanımını etkiler. HTTP proxy üzerinden HTTPS hedeflere giden trafik, CONNECT ile kurulan bir tünel içinde taşınır ve istemci kütüphaneleri bu tüneli bağlantı havuzunda tutarak yeniden kullanabilir. SOCKS5 ise HTTP dışındaki TCP trafiğini de taşıyabildiği için tarayıcı dışı araçlarda esneklik sağlar. Hangi protokolü seçerseniz seçin, bağlantıyı gereksiz yere kapatıp açmak hem gecikmeyi artırır hem de port üzerinde zaman harcar; durumsuz işlerde bile makul bir bağlantı havuzu boyutu belirlemek verimi yükseltir.

Katalogdaki rotating IPv6 datacenter lokasyon seti dokuz ülkeden oluşur: Almanya, Amerika Birleşik Devletleri, Birleşik Krallık, Hollanda, Fransa, Kanada, Polonya, Japonya ve Avustralya. Bu set, rotating IPv4 ürününün lokasyon listesinden daha dardır ve Türkiye’yi içermez. Türkiye’den çıkış gerektiren bir işiniz varsa bu ürün o ihtiyacı karşılamaz; katalogdaki diğer ürünlerin lokasyon listelerine bakın.

Gecikme açısından kural basittir: çıkış lokasyonunu hedef sunucunun bulunduğu bölgeye yakın seçin. Avrupa’daki hedefler için Almanya, Hollanda, Fransa, Birleşik Krallık ve Polonya; Kuzey Amerika’daki hedefler için Amerika Birleşik Devletleri ve Kanada; Asya Pasifik’teki hedefler için Japonya ve Avustralya mantıklı başlangıç noktalarıdır. Ancak hedefin içerik dağıtım ağı kullanıp kullanmadığı da önemlidir. CDN arkasındaki bir site, isteği size en yakın uç noktadan yanıtlar; bu durumda çıkış lokasyonu yalnız gecikmeyi değil, gördüğünüz içeriği, para birimini ve dili de değiştirebilir.

Lokasyon seçimini doğrulamak için her lokasyondan aynı hedefe kısa bir test yapın ve hem bağlantı kurma süresini hem toplam yanıt süresini kaydedin. Bu ölçüm, kapasite planlamasında kullandığınız port başına verim değerini de etkiler: uzak bir lokasyondan yapılan istekler daha uzun sürdüğü için aynı port daha az istek tamamlar.

Aşağıdaki Python iskeleti iki işi birlikte yapar. İşe başlamadan önce proxy üzerinden çıkış adresini kontrol eder ve adres IPv6 değilse işi durdurur; böylece sessiz IPv4’e geri düşme erken yakalanır. Ardından istekleri sınırlı sayıda yeniden deneme ve üstel bekleme ile gönderir. Katalog bu ürün için HTTP, HTTPS ve SOCKS5 protokollerini listeler; örnek HTTP proxy kullanır. Ağ geçidi adresi, port numarası ve kimlik doğrulama yöntemi panelinizde yer alır.

import ipaddress
import random
import time
import requests

PROXY = 'http://KULLANICI:ŞİFRE@GATEWAY:PORT'
# SOCKS5 kullanacaksanız alan adını proxy tarafında çözdürün:
# PROXY = 'socks5h://KULLANICI:ŞİFRE@GATEWAY:PORT'
PROXIES = {'http': PROXY, 'https': PROXY}

def assert_ipv6_exit(session):
    r = session.get('https://api64.ipify.org', proxies=PROXIES, timeout=10)
    addr = ipaddress.ip_address(r.text.strip())
    if addr.version != 6:
        raise RuntimeError('Çıkış IPv6 değil: ' + str(addr))
    return addr  # örnek çıktı: 2001:db8::42

def fetch(session, url, tries=4):
    for attempt in range(1, tries + 1):
        try:
            r = session.get(url, proxies=PROXIES, timeout=(5, 20))
            if r.status_code == 429:
                time.sleep(float(r.headers.get('Retry-After', 15)))
                continue
            if r.status_code not in (502, 503, 504):
                return r
        except requests.RequestException:
            pass
        time.sleep(min(60, 2 ** attempt) + random.uniform(0, 1))
    return None

with requests.Session() as s:
    print('Çıkış:', assert_ipv6_exit(s))
    resp = fetch(s, 'https://www.example.com/')

Port bazlı modelde yeniden denemelerin doğrudan bir GB maliyeti yoktur, ama dolaylı bir maliyeti vardır: her başarısız deneme, sabit ücret ödediğiniz portun kapasitesinden pay alır. Yeniden deneme oranı yükseldikçe aynı port sayısıyla tamamlanan başarılı iş azalır ve daha fazla porta ihtiyaç duyuyormuş gibi görünürsünüz. Bu yüzden port eklemeden önce yeniden deneme oranını ve 429 yanıtlarının sıklığını inceleyin; sorun çoğu zaman port sayısı değil, hedefe uygulanan hızdır.

import { ProxyAgent, request } from 'undici'
import net from 'node:net'

const agent = new ProxyAgent('http://KULLANICI:ŞİFRE@GATEWAY:PORT')

const res = await request('https://api64.ipify.org', { dispatcher: agent })
const ip = (await res.body.text()).trim()

if (net.isIPv6(ip)) {
  console.log('IPv6 çıkış doğrulandı: ' + ip)
} else {
  console.error('Uyarı: çıkış IPv4 görünüyor (' + ip + '), iş başlatılmadı')
  process.exit(1)
}

IPv6 kaynaklı sorunları teşhis ederken önce üç basit soruyu cevaplayın: hedefin AAAA kaydı var mı, proxy üzerinden görülen çıkış adresi IPv6 mı ve aynı istek IPv4 bağlantılı bir istemciden çalışıyor mu. Bu üç cevabın kombinasyonu, aşağıdaki satırlardan hangisine bakmanız gerektiğini büyük ölçüde belirler.

Destek ekibine başvurmadan önce sorunun yaşandığı zamanı, hedef alan adını, seçilen lokasyonu, gördüğünüz çıkış adresini, HTTP durum kodunu ve aynı isteğin IPv4 bağlantılı bir istemcideki sonucunu not edin. Bu bilgiler sorunun hedefin IPv6 yapılandırmasında mı, istemci ayarında mı yoksa proxy tarafında mı olduğunu hızla ayırmayı sağlar.

Port bazlı modelde fatura her ay aynıdır; bu yüzden maliyet kontrolü harcamayı izlemekten çok, ödenen kapasitenin ne kadar kullanıldığını izlemekle yapılır. Aşağıdaki liste hem ilk devreye alma hem de her ay sonunda yapılacak gözden geçirme için kullanılabilir.

• Hedef listesindeki her alan adı ve alt alan adı için AAAA kaydı ve gerçek IPv6 yanıtı doğrulandı.
• Yalnız IPv4 hedefler ayrı bir kuyruğa alındı ve IPv6 portlarına gönderilmiyor.
• Her iş başında proxy üzerinden çıkış adresinin IPv6 olduğu otomatik olarak kontrol ediliyor.
• SOCKS5 kullanılan yerlerde alan adı proxy tarafında çözülüyor.
• Ağ geçidi, port ve kimlik doğrulama bilgileri panelden alındı; gizli bilgiler kod deposunda değil ortam değişkenlerinde tutuluyor.
• Port başına sürdürülebilir verim tek port testiyle ölçüldü ve port sayısı bu ölçüme göre belirlendi.
• Lokasyon seçimi hedef bölgesine göre yapıldı; Türkiye çıkışı gereken işler başka bir ürüne yönlendirildi.
• Durumlu akışlar için oturum davranışı test edildi; her akışın kendi çerez deposu var.
• Yeniden deneme sayısı sınırlı, bekleme üstel; 429 yanıtında Retry-After dikkate alınıyor.
• Ay sonunda port başına başarılı istek, yeniden deneme oranı ve boşta geçen saatler raporlandı; port sayısı gerekirse azaltıldı ya da artırıldı.
• Hedeflerin robots.txt yönergeleri, kullanım koşulları ve yayınlanan hız sınırları gözden geçirildi.

Gözden geçirmede portların günün büyük bölümünde boşta kaldığını görürseniz, işleri zamana yayarak daha az portla aynı sonucu almayı deneyin. Tersine, portlar sürekli doluysa ve yeniden deneme oranı düşükse port eklemek mantıklıdır. Her iki durumda da karar, katalogdaki port başına fiyatlar ve kendi ölçtüğünüz verim üzerinden verilmelidir; tahmini kapasite rakamlarıyla değil.