Betiğiniz datacenter IP üzerinden yüz istekte bir, rezidansiyel veya mobil kanal üzerinden ise on istekte bir bağlantı kopmasıyla hata veriyor. Bu proxy'nin kusuru değil, ortamın doğal özelliğidir: ev veya hücresel kanalda kopma normal bir olaydır ve istemci bunu insan müdahalesi olmadan kendi başına atlatabilmelidir. Kopma sıklığındaki farkın nereden geldiğini, hangi zaman aşımlarını ve tekrar arası beklemeleri ayarlamanız gerektiğini, hangi hataların tekrar denenmesi gerektiğini, hangilerinin denenmemesi gerektiğini ve retry'ların trafik harcamasını nasıl etkilediğini ele alalım.

Rezidansiyel ve mobil kanal neden sunucu kanalından daha sık kopar

Datacenter IP, sağlayıcının yedeklemeli, ayrılmış bir kanalında durur ve jitter'ı neredeyse sıfırdır; orada kopma nadirdir ve genellikle sistemsel bir arızadır. Rezidansiyel adres ise gerçek bir ev bağlantısıdır: router yeniden başlar, sağlayıcı aboneyi düğümler arasında değiştirir, DHCP kiralaması yenilenir, cihaz bir dakikalığına uykuya geçer. Mobil kanal buna baz istasyonları arasındaki handover'ları, ağ geçişlerini ve geçici sinyal kaybını ekler; bunların hepsi sizin için ayrılmış bir portta değil, gerçek bir abonenin canlı cihazında gerçekleşir. Yüzlerce abonenin tek bir adresi paylaşmasını sağlayan mobil operatör NAT'ı, böyle bir IP'yi neredeyse yasaklanamaz kılan nedenin ta kendisidir: ayrıntılar için mobil proxy'lerin yasaklanması neden zor yazısına bakın. Yasaklanmaya karşı dayanıklılığın diğer yüzü, kanalın fiziksel olarak sunucu kanalına göre daha az kararlı olmasıdır.

Bağlantı ve okuma zaman aşımları için makul değerler

Bağlantı zaman aşımı (connect timeout) ile okuma zaman aşımı (read timeout) farklı şeylerdir ve karıştırılmamalıdır. Connect timeout oturumun kurulması için tanınan süreyi sınırlar; datacenter kanalı için 3–5 saniye yeterlidir, rezidansiyel ve mobil kanal için 8–15 saniye gerekir, çünkü paket gerçek bir cihaz üzerinden geçerken daha fazla ara düğümden geçer. Read timeout ise bağlantı kurulduktan sonra yanıtın beklenme süresini sınırlar; ölçüt, hedef sunucunun beklenen yanıt süresinin 2–3 katı pay bırakılmış halidir: sıradan istekler için genellikle 15–30 saniye, ağır işlemler için daha fazla. Rezidansiyel kanalda çok kısa bir zaman aşımı normal ağ gecikmesini sahte bir arızaya dönüştürür, çok uzun olanı ise bağlantıyı boşuna açık tutar ve trafiği boşa harcar.

Tekrarlar arasında üstel bekleme

Kopmanın hemen ardından isteği anında tekrarlamak kötü bir fikirdir: sebep düğümün aşırı yüklenmesi veya geçici sinyal kaybıysa, anlık tekrar aynı duruma denk gelir. Üstel backoff her denemede beklemeyi artırır; örneğin 1, 2, 4, 8 saniye gibi, ve kanala toparlanması için zaman tanır. Beklemeye, hesaplanan değerin yüzde 20–30'u kadar rastgele jitter eklemek gerekir: bu olmadan aynı betiğin paralel iş parçacıkları ortak bir arızadan sonra istekleri eş zamanlı tekrarlar ve kendi yük artışlarını yaratır. Deneme sayısını üç-dört ile sınırlamak mantıklıdır: sonrasında başarı olasılığı neredeyse artmaz, süre ve trafik harcaması ise doğrusal biçimde artar.

Hangi hatalar tekrar denenmeli, hangileri denenmemeli

Geçici bir arızaya benzeyen şeyleri tekrar denemek gerekir: bağlantı kopması, zaman aşımı, 502/503/504 hataları ve sunucudan yanıt gelmeyen ağ istisnaları. Yeni bir denemeyle değişmeyecek şeyleri tekrar denemeyin: hatalı istek gövdesiyle gelen 400 hatasını, yetkilendirme sorunu olarak 401/403'ü, olmayan bir kaynak olarak 404'ü. 429 kodu ayrıca ele alınmalıdır: bu bir arıza değil, yavaşlamak için doğrudan bir talimattır; böyle bir isteği genel backoff şemasıyla değil, sunucunun genellikle yanıt başlığında belirttiği beklemeyle tekrarlamak gerekir. Tüm hataları ayırt etmeden körü körüne tekrarlamak, bir betiğin durup sorunu bildirmek yerine saatlerce duvara vurmasının tipik nedenidir.

Kanal kopması platform engelinden nasıl ayırt edilir

Kanal kopması yanıtın olmamasıdır: zaman aşımı, bağlantı sıfırlama, TCP veya TLS düzeyinde hata. Engelleme ise bir yanıttır, sadece istenmeyen bir yanıt: 403 kodu, içerik yerine captcha, doğrulama sayfasına yönlendirme, beklenen veri yerine normal boyutta bir HTML. Birincisi tekrarla çözülür, ikincisi çözülmez: aynı adresten yapılan ikinci istek engele neredeyse her zaman aynı yanıtı alır; rotasyonla adres değiştirmek ise başka bir konudur ve API ile IP rotasyonu ayarı yazısında ele alınmıştır. Her tekrar, rezidansiyel veya mobil kanalın ayrı bir oturumudur ve bu kanallar trafiğe göre ücretlendirilir: engellenmiş bir adreste agresif retry sorunu çözmez, yalnızca aynı reddi almak için gigabaytlarca trafik harcatır. Deneme sınırı ve yanıt kodunun ayrıştırılması yalnızca güvenilirlik değil, aynı zamanda bütçe meselesidir.

Sıkça Sorulan Sorular

Pes etmeden önce isteği kaç kez tekrarlamak gerekir?

Çoğu görev için üstel olarak artan beklemeyle üç-dört deneme yeterlidir. Hepsi başarısız olduysa, aynı adreste beşinci denemenin başarı olasılığı düşüktür, trafik harcaması ise artmaya devam eder; rotasyonla adresi değiştirmek veya hatayı çağıran koda döndürmek daha mantıklıdır.

Datacenter ve rezidansiyel kanal için farklı zaman aşımı ayarları gerekir mi?

Evet. Datacenter kanalı istikrarlı ve düşük gecikmeyi korur, bu yüzden orada kısa zaman aşımı haklı görülür. Rezidansiyel ve mobil kanallar canlı bir abonenin gerçek ekipmanı üzerinden geçer, bu yüzden bunlarda zaman aşımlarını belirgin biçimde daha geniş ayarlamak gerekir; aksi halde normal ağ gecikmesi sürekli arıza olarak algılanır.

Tüm hatalar için aynı retry algoritmasını kullanabilir miyim?

Hayır. Ağ arızaları ve 5xx yanıtları gecikmeli tekrar için adaydır. Yetkilendirme ve hatalı istek hatalarını tekrarlamak anlamsızdır. 429 kodu sunucunun talimatına göre bekleme gerektirir, engelleme belirtileri — captcha, yönlendirme, 403 kodu — ise aynı IP'de tekrar değil, adres değişikliği gerektirir.

Retry gerektiren görevler için rezidansiyel ve mobil kanallar proxy bölümünde: orada belirli bir senaryo için trafik harcamasını da değerlendirebilir ve mobil ve rezidansiyel proxy'ler arasındaki farka bakarak kararlılık ile fiyat arasında ihtiyacınıza uygun dengeyi seçebilirsiniz.