Makale içeriği

POST yöntemiyle, gövde ve yetkilendirme başlığıyla bir istek gönderiyorsunuz; ancak sunucuya tek bir özel başlık bile olmadan boş bir GET isteği ulaşıyor. Tanıdık geldi mi? Proxy ve otomatikleştirilmiş isteklerle çalışıyorsanız, er ya da geç bu davranışla karşılaşırsınız. Bu, kodunuzdaki bir hata veya Proxeon proxy'sindeki bir arıza değildir. Bu, HTTP yönlendirmelerinin spesifikasyonda öngörülen normal bir mekanizmasıdır; sadece anlamanız ve kontrol etmeyi bilmeniz gerekir.

Bu kılavuzda, bir yönlendirmeyi takip ederken istek yönteminin neden değişebileceğini ve başlıkların neden kaybolabileceğini inceleyeceğiz. 301, 302, 307 ve 308 kodları arasındaki farkı okumayı öğrenecek, farklı HTTP istemcilerinin varsayılan olarak nasıl davrandığını görecek ve otomatik geçişleri kapatıp ardından manuel işleme için çalışan örnekler elde edeceksiniz. Hepsi gerçek kod üzerinde, gereksiz ayrıntı olmadan.

Giriş: istek POST olarak gönderiliyor, GET olarak ulaşıyor - suçlu kim?

Bir mühendislik görevi hayal edin. Proxy üzerinden bir kimlik doğrulama uç noktasına POST isteği yapıyorsunuz. Sunucu bir yönlendirme koduyla yanıt veriyor ve yeni bir adres belirtiyor. HTTP istemciniz otomatik olarak bu adrese geçiyor. Ancak artık GET yöntemiyle, istek gövdesi olmadan ve Authorization başlığı olmadan geçiyor. Sonuç olarak hedef sunucu, gönderdiğiniz şeyi alamıyor ve mantık bozuluyor.

Suçlu kim? Resmi olarak hiç kimse. Bu davranış, 301 ve 302 kodlarının tarihsel uygulamasında yerleşiktir. Eskiden tarayıcılar ve kitaplıklar bu kodları aldıklarında neredeyse her zaman yöntemi GET olarak değiştirirdi. Bu fiili bir standart haline geldi ve pekiştirildi. Daha sonra, geliştiricilere yöntemi ve gövdeyi koruma imkanı vermek için 307 ve 308 kodları eklendi. Bunları aşağıda ayrıntılı olarak ele alacağız.

Sonunda ne elde edeceksiniz?

Bu kılavuzu okuduktan sonra, herhangi bir popüler HTTP istemcisinde yönlendirmeleri güvenle yönetebileceksiniz. İstek yöntemine ve gövdesine ne olacağını tahmin edebileceksiniz. Geçişler sırasında kritik başlıkları korumayı öğreneceksiniz. Ve proxy üzerinden geçen karmaşık yönlendirme zincirlerinde hata ayıklayabileceksiniz.

Bu kılavuz kimler için?

  • Proxy üzerinde ayrıştırıcılar, entegrasyonlar ve otomasyon yazan geliştiriciler.
  • API'leri ve web senaryolarını test eden QA mühendisleri.
  • Trafik proxy'sini yapılandıran DevOps ekipleri.
  • POST'un neden GET'e dönüştüğünü merak eden herkes.

Önceden bilmeniz gerekenler

HTTP protokolünün temel anlayışı: istek yönteminin, başlıkların, gövdenin ve yanıt durum kodunun ne olduğu. Terminalde komut çalıştırabilme. Python veya JavaScript dillerinden en az biriyle asgari düzeyde tanışıklık. Bunlardan bazıları yoksa endişelenmeyin - anahtar terimleri ayrı bir bölümde basit kelimelerle açıklayacağız.

Ne kadar zaman gerekir?

Tüm örnekleri dikkatlice okuyup tekrarlamak yaklaşık 60 dakika sürer. Yalnızca belirli bir sorunu çözmeniz gerekiyorsa, içindekiler bölümünü kullanın ve doğrudan ilgili bölüme geçin.

Ön hazırlık: Araçlar ve erişimler

Örnekler üzerinde çalışmadan önce çalışma ortamınızı hazırlayın. Biraz zaman alır, ancak sonrasında her şey pürüzsüz ilerler.

Gerekli araçlar

  1. curl sürüm 7.88 veya daha yenisini kurun. Terminalde curl --version komutuyla kontrol edin.
  2. Python sürüm 3.10 veya daha yenisini kurun. python --version komutuyla kontrol edin.
  3. Python kitaplıklarını kurun: pip install requests httpx komutunu çalıştırın.
  4. axios ve fetch'i test edecekseniz Node.js sürüm 20 veya daha yenisini kurun. node --version komutuyla kontrol edin.
  5. Test proje klasöründe npm install axios komutuyla axios'u kurun.

Proxy erişimi

Pratik yapmak için çalışan Proxeon proxy'lerine ihtiyacınız olacak. Bağlantı verilerini hazırlayın: sunucu adresi, bağlantı noktası, kullanıcı adı ve şifre. Bunları güvenli bir yerde saklayın. Kod örneklerinde kullanacağız.

İpucu: Proxy kullanıcı adınızı ve şifrenizi asla doğrudan koda yazmayın. Ortam değişkenlerini kullanın. Örneğin, terminalde export PROXY_URL=http://user:pass@host:port değişkenini ayarlayın ve kodda bu değeri ortamdan okuyun. Böylece sırları yanlışlıkla depoya göndermezsiniz.

Sistem gereksinimleri

Windows 10 ve üzeri, macOS 12 ve üzeri veya güncel bir Linux dağıtımına sahip herhangi bir modern bilgisayar yeterlidir. Donanım için özel bir gereksinim yoktur: HTTP istekleriyle çalışmak sistemi yormaz.

⚠️ Dikkat: Canlı bir sunucuda test ediyorsanız, önce ayrı bir test kod dalı veya ayrı bir test betiği oluşturun. Yönlendirme mantığını doğrudan canlıda denemeyin - geçiş davranışını değiştirmek kimlik doğrulamayı bozabilir ve isteklerin yanlış yerlere gitmesine neden olabilir.

✅ Kontrol: Bu aşamada, curl, Python ve Node.js sürüm kontrol komutları başarıyla çalışmalı ve Proxeon proxy verileriniz ortam değişkeninde saklanmış olmalıdır.

Temel kavramlar basit dille

Devamını anlamak için anahtar terimleri ele alalım. Biliyor olsanız bile tazelemekte fayda var.

Yönlendirme nedir?

Yönlendirme veya yönlendirme - sunucunun istemciye şunu söyleyen yanıtı: Aradığın kaynak burada değil, başka bir adrese git. Sunucu, 3xx ailesinden bir durum kodu ve yeni adresi içeren Location başlığını döndürür. İstemci bu başlığı okur ve oraya yeni bir istek gönderir.

İstek yöntemi ve gövde nedir?

Yöntem, eylem türüdür. GET veri ister, POST sunucuya veri gönderir, PUT günceller, DELETE siler. İstek gövdesi, POST veya PUT ile gönderdiğiniz yüküdür. Örneğin, kimlik doğrulama sırasında kullanıcı adı ve şifre içeren JSON.

Başlıklar nelerdir?

Başlıklar, isteğin meta verileridir. Ek bilgi iletirler: veri formatı (Content-Type), yetkilendirme (Authorization), kullanıcı aracısı (User-Agent), kendi özel alanlarınız. Yönlendirme sırasında başlıkların bir kısmı korunabilir, bir kısmı kaybolabilir. Mantığı bozan genellikle budur.

Otomatik geçiş nedir?

Otomatik geçiş - HTTP istemcinizin, Location başlığındaki adrese sizin katılımınız olmadan kendi başına gitmesidir. Çoğu istemci varsayılan olarak bunu yapar. Kullanışlıdır, ancak tehlikelidir: yöntem, gövde ve başlıklarla ilgili kontrolü kaybedersiniz.

Proxy buna nasıl uyuyor?

Proxeon proxy'si, istemciniz ile hedef sunucu arasında durur. İsteğinizi iletir ve yanıtı döndürür. Yönlendirme sırasında proxy yalnızca durum kodunu ve Location başlığını iletir. Geçiş kararını istemciniz verir. Önemli bir ayrıntı: rotasyonlu bir proxy havuzu kullanıyorsanız, yönlendirme zincirinin farklı adımları farklı IP'ler üzerinden gidebilir. Buna ayrıca döneceğiz.

İpucu: Basit bir kuralı hatırlayın. Proxy, yönlendirme sırasında istek yöntemini değiştirmez. Yöntemi, durum kodunu işleme kurallarına göre HTTP istemciniz değiştirir. Bu nedenle nedeni proxy'de değil, istemci ayarlarında aramalısınız.

Adım 1: Dört kodu anlayın - 301 ve 302 ile 307 ve 308

Bu aşamanın amacı: dört yönlendirme kodunun her biri alındığında istek yöntemine ve gövdesine ne olacağını hatasız belirleyebilmek.

Bu kılavuzun temelidir. Bu kodlar arasındaki farkı öğrenirseniz, yönlendirme sorunlarının yarısı kendiliğinden çözülür.

Kod 301 - kalıcı yönlendirme

Kaynağın kalıcı olarak taşındığı anlamına gelir. Tarihsel olarak, 301 alındığında istemciler POST yöntemini GET olarak değiştirir ve istek gövdesini atar. Resmi olarak spesifikasyon bunu gerektirmez, ancak pratikte böyle yerleşmiştir ve neredeyse tüm istemciler geriye dönük uyumluluk için bunu yapar.

Kod 302 - geçici yönlendirme

Kaynağın geçici olarak başka bir adreste erişilebilir olduğu anlamına gelir. Davranış 301'e benzer: pratikte POST GET'e dönüşür, gövde kaybolur. Girişteki durumdan en çok sorumlu olan kod 302'dir.

Kod 307 - yöntemi koruyarak geçici yönlendirme

Bu kod, yöntem değişikliği sorununu çözmek için özel olarak eklenmiştir. 307'de istemci orijinal yöntemi ve gövdeyi korumalıdır. POST gönderdiyseniz POST gider. Gövde gönderdiyseniz iletilir. Bu, yöntem sürprizleri olmadan 302'nin geçici bir benzeridir.

Kod 308 - yöntemi koruyarak kalıcı yönlendirme

301'in kalıcı benzeri, ancak yöntem ve gövde korunur. POST gönderdiyseniz POST gelir. POST isteklerini yönlendirmek için kodların en öngörülebilir olanıdır.

Davranış özet tablosu

Aşağıda, resmi zihninizde canlandırmanız için tablonun sözlü açıklaması bulunmaktadır.

  • 301: kalıcı. POST yöntemi pratikte GET olarak değişir. Gövde atılır. GET, GET kalır.
  • 302: geçici. POST yöntemi pratikte GET olarak değişir. Gövde atılır. GET, GET kalır.
  • 307: geçici. Yöntem tamamen korunur. Gövde korunur. POST, POST kalır.
  • 308: kalıcı. Yöntem tamamen korunur. Gövde korunur. POST, POST kalır.

⚠️ Dikkat: Tüm sunucuların spesifikasyona kesinlikle uyduğuna güvenmeyin. Bazı eski sistemler, mantıksal olarak 307 gerektiği yerde 302 döndürür ve yöntemin korunmasını bekler. Yalnızca koda değil, her zaman fiili davranışı kontrol edin. Gerçek bir uç noktada test edin.

İpucu: Kendi sunucunuzu geliştiriyorsanız ve yönlendirme sonrasında POST isteklerinin POST olarak kalmasını istiyorsanız, 307 veya 308 kodlarını kullanın. Bu, istemcilerinizi hoş olmayan sürprizlerden ve gereksiz hata ayıklamadan kurtarır.

✅ Kontrol: Yanıt koduna bakarak yöntem ve gövdenin korunup korunmayacağını hemen söyleyebilirsiniz. 307 ve 308 için - evet. 301 ve 302 için - pratikte hayır.

Adım 2: Geçişte neler kaybolur - Authorization, özel başlıklar, çerezler

Bu aşamanın amacı: yönlendirme sırasında hangi verilerin kaybolduğunu ve neden kaybolduğunu anlamak, böylece korunmalarını önceden planlayabilirsiniz.

Yöntem değişikliği tek sorun değildir. 307 ve 308 kodlarında bile, yöntem korunduğunda bile, bazı başlıklar kaybolabilir. Üç ana kaybı ele alalım.

Alan adı değiştiğinde Authorization başlığının kaybı

Bu en yaygın ve en sinsi sorundur. Güvenlik nedeniyle, çoğu HTTP istemcisi başka bir alan adına yönlendirme sırasında Authorization başlığını kaldırır. Mantık basittir: A sitesinde kimlik doğruladıysanız, gizli belirteciniz otomatik olarak yönlendirildiğiniz B sitesine gitmemelidir. Aksi takdirde, bir saldırgan yönlendirme ayarlayıp kimlik bilgilerinizi ele geçirebilir.

Sonuç olarak, doğru belirteçle bir istek gönderirsiniz, istemci yönlendirmeyi başka bir alan adına takip eder, ancak Authorization olmadan. Hedef sunucu, yetkisiz olduğunuzu söyler. Her şey mantıklı, ancak açık değil.

İpucu: Yetkilendirmeyi gerçekten başka bir alan adına iletmeniz gerekiyorsa, bunu bilinçli ve manuel olarak yapın. Otomatik geçişi kapatın, Location'un tam olarak nereye götürdüğünü kontrol edin, güvenilir bir adres olduğundan emin olun ve ancak o zaman yeni isteğe kendi ellerinizle Authorization başlığını ekleyin.

Özel başlıkların kaybı

Kendi başlıklarınız - örneğin X-Request-Id veya X-Client-Version gibi hizmet alanları - otomatik geçiş sırasında istemciye bağlı olarak farklı davranır. Bazı kitaplıklar onları iletir, bazıları sıfırlar. Buna güvenemezsiniz. Başlık mantık için kritikse, iletilmesini manuel olarak kontrol edin.

Bayraklı çerezlerin kaybı

Çerezlerin gönderimini kısıtlayan bayrakları vardır. Secure bayrağı yalnızca güvenli bağlantı üzerinden gönderime izin verir. Domain bayrağı, çerezin gönderileceği alan adı kümesini sınırlar. SameSite bayrağı, siteler arası geçişlerde gönderimi düzenler. Yönlendirme sizi çerez bayraklarıyla uyuşmayan bir alan adına veya protokole götürürse, bu çerez gönderilmez.

Örneğin, Secure bayraklı bir çerez, yönlendirme aniden güvenli olmayan bir adrese giderse gönderilmez. Alan adı kısıtlı bir çerez, yabancı bir alan adına gönderilmez. Bu güvenlik açısından doğru bir davranıştır, ancak dikkate alınmalıdır.

⚠️ Dikkat: Kolaylık sağlamak için yabancı çerezlerin koruyucu bayraklarını zorla kaldırmaya veya Authorization'ı güvenilmeyen alan adlarına iletmeye asla çalışmayın. Bu mekanizmalar kimlik bilgilerinizi korur. Bunları yalnızca tamamen kontrol ettiğiniz altyapıda ve sonuçlarını tam anlayarak atlayın.

✅ Kontrol: Yönlendirme sırasında üç kayıp sınıfını anlıyorsunuz: başka bir alan adında Authorization başlığı, özel başlıklar ve kısıtlayıcı bayraklı çerezler. Her birinin yalnızca bilinçli manuel işlemeyle geri getirilebileceğini biliyorsunuz.

Adım 3: Farklı istemcilerde varsayılan davranış

Bu aşamanın amacı: her popüler HTTP istemcisinin tam olarak nasıl davrandığını öğrenmek, tutarsızlıklara şaşırmamak için.

Ana tuzak, tüm istemcilerin varsayılan davranışının farklı olmasıdır. En yaygın beş tanesini ele alalım.

curl

Varsayılan olarak curl yönlendirmeleri hiç takip etmez. Size yalnızca 3xx kodlu yanıtı ve Location başlığını gösterir. Otomatik geçişi etkinleştirmek için açıkça -L bayrağını eklemeniz gerekir. Bu, curl'ü çok öngörülebilir kılar: bayrak olmadan gizli geçişler olmayacağını her zaman bilirsiniz.

Geçişsiz istek örneği:

curl -i -x $PROXY_URL https://example.com/redirect

-i bayrağı yanıt başlıklarını gösterir, -x bayrağı proxy'yi belirtir. Kodu ve Location'ı görürsünüz, ancak geçiş olmaz.

requests (Python)

requests kitaplığı varsayılan olarak yönlendirmeleri otomatik olarak takip eder. 301, 302 ve 303 kodları için POST yöntemini GET olarak değiştirir. 307 ve 308 için yöntemi korur. Otomatik geçişi allow_redirects=False parametresiyle kapatabilirsiniz.

httpx (Python)

İlginç bir gerçek: httpx, requests'in aksine varsayılan olarak yönlendirmeleri takip ETMEZ. Bu, geliştiricinin açıkça karar vermesi için bilinçli olarak yapılmıştır. Geçişleri etkinleştirmek için follow_redirects=True değerini iletin. Bu davranış curl felsefesine daha yakındır.

axios (JavaScript, Node.js)

Node.js ortamında axios varsayılan olarak yönlendirmeleri otomatik olarak takip eder. Bunu maxRedirects parametresiyle sınırlayabilir veya kapatabilirsiniz. maxRedirects: 0 ayarlarsanız otomatik geçiş kapanır ve axios ayarlara bağlı olarak bir hata veya yönlendirme kodlu yanıt döndürür.

fetch (tarayıcı ve Node.js)

Standart fetch varsayılan olarak yönlendirmeleri otomatik olarak takip eder. Bunu üç değer alan redirect parametresiyle yönetebilirsiniz: follow - takip et, manual - takip etme ve opak bir yanıt döndür, error - yönlendirmeyi hata olarak kabul et.

İpucu: İki grubu hatırlayın. curl ve httpx varsayılan olarak takip ETMEZ - siz karar verirsiniz. requests, axios ve fetch varsayılan olarak takip eder. Kodu bu araçlar arasında taşırsanız, yönlendirme ayarını mutlaka kontrol edin, aksi takdirde mantık sessizce bozulur.

⚠️ Dikkat: Farklı varsayılan davranış, betikleri bir istemciden diğerine taşırken gizemli hataların bir numaralı nedenidir. requests'te çalışan bir betik, httpx'e taşıdınız ve birdenbire son yanıt yerine 302 kodu geliyor. Neden - httpx kendisi takip etmiyor. Yönlendirme ayarını her zaman açıkça belirtin.

✅ Kontrol: curl, requests, httpx, axios ve fetch için varsayılan davranışı ezbere söyleyebilir ve her birinde yönlendirmeyi yöneten parametreyi bilirsiniz.

Adım 4: Yönlendirmeleri manuel yönetme - tek doğru yol bu olduğunda

Bu aşamanın amacı: otomatik geçişi kapatmayı ve yönlendirmenin her adımını bağımsız olarak işlemeyi, yöntemi, gövdeyi ve başlıkları tamamen kontrol etmeyi öğrenmek.

Otomatik geçiş kullanışlıdır, ancak üç durumda zararlıdır ve manuel kontrol gerekir:

  1. Başka bir alan adına geçerken Authorization'ı korumanız gerektiğinde.
  2. Zincirin her adımının hangi proxy ve IP üzerinden geçtiğini tam olarak bilmek önemli olduğunda.
  3. Sunucu mantıksal olarak 307 gerektiği yerde 302 yanıtı verdiğinde ve POST yöntemini manuel olarak korumak istediğinizde.

Otomatik geçişi kapatma: curl

curl'de her şey basittir: -L bayrağını eklemeyin. İstemci size ilk yanıtı gösterir. Sonra Location'ı kendiniz alıp yeni bir istek yaparsınız:

curl -i -x $PROXY_URL "https://example.com/login"

Çıktıdan Location başlığını okuyup gerekli başlıkları ekleyerek bir sonraki isteği manuel olarak yaparsınız:

curl -i -x $PROXY_URL -H "Authorization: Bearer TOKEN" "https://example.com/next"

Otomatik geçişi kapatma: requests

Burada allow_redirects=False parametresini kullanır ve zinciri bir döngüde işleriz:

import os, requests; proxies = {"http": os.environ["PROXY_URL"], "https": os.environ["PROXY_URL"]}; url = "https://example.com/login"; method = "POST"; body = {"user": "a", "pass": "b"}; headers = {"Authorization": "Bearer TOKEN"}; 
for _ in range(5): 
r = requests.request(method, url, json=body, headers=headers, proxies=proxies, allow_redirects=False); 
if r.status_code not in (301, 302, 303, 307, 308): break; 
loc = r.headers["Location"]; 
if r.status_code in (301, 302, 303): method = "GET"; body = None; 
url = loc

Bu döngüde yöntemi değiştirip değiştirmeyeceğinize ve Authorization başlığını koruyup korumayacağınıza kendiniz karar verdiğinizi unutmayın. Manuel işlemenin gücü tam olarak budur.

Otomatik geçişi kapatma: httpx

httpx varsayılan olarak takip etmediğinden, follow_redirects değerini açmamanız yeterlidir. Döngü mantığı requests ile aynıdır: kodu kontrol edin, Location'ı okuyun, yöntem ve başlıklar hakkında kararlar alın, sonraki isteği yapın.

Otomatik geçişi kapatma: axios

axios'ta maxRedirects: 0 ayarlayın. Yönlendirme kodu alındığında, axios Node.js'de bir hata fırlatır ve hata nesnesinde yanıt durumu ve başlıkları bulunur. Location başlığından yeni adresi alıp sonraki isteği kendiniz oluşturursunuz.

Otomatik geçişi kapatma: fetch

fetch'te redirect: "manual" değerini iletin. Ardından fetch takip etmez ve sonraki adım için gerekli verileri okuyabileceğiniz bir yanıt döndürür.

İpucu: Manuel işlemede her adımda dört şeyi günlüğe kaydedin: kaynak URL, alınan kod, Location değeri ve sonraki isteğin yöntemi. Bu, anlaşılmaz bir zinciri okunması ve hata ayıklanması kolay şeffaf bir diziye dönüştürür.

⚠️ Dikkat: Manuel işlemede güvenlikten kendiniz sorumlusunuz. Authorization'ı Location'daki yeni bir adrese taşımadan önce, alan adının güvendiğiniz altyapıya ait olduğunu kontrol edin. Sırları Location'daki herhangi bir adrese körü körüne kopyalamak ciddi bir güvenlik açığıdır.

✅ Kontrol: En az bir istemcide, yönlendirme zincirini doğru şekilde geçen ve gerekli başlıkları yalnızca güvenilir alan adları için koruyan çalışan bir manuel işleme döngünüz var.

Adım 5: Derinliği sınırlama ve döngülere karşı koruma

Bu aşamanın amacı: kodunuzu sonsuz yönlendirmelerden korumak ve geçiş döngüsünün uygulamayı asmasına izin vermemek.

Bazen sunucular yanlış yapılandırılmıştır ve A adresi B adresine, B ise A'ya geri yönlendirir. İstemciniz kısıtlama olmadan geçiş yaparsa, döngüye girer. Manuel işlemede de aynı tehlike vardır: sayacı olmayan bir döngü sonsuza kadar döner.

Geçiş sayısını sınırlama

Her zaman maksimum derinliği belirleyin. Makul bir değer beş ila on geçiş arasıdır. Normal senaryolarda daha fazlası neredeyse hiç olmaz.

  • curl'de: -L ile birlikte --max-redirs 10 bayrağı.
  • requests'te: kitaplık derinliği kendisi sınırlar, ancak manuel döngüde range(10) kullanın.
  • httpx'te: geçişler açıkken max_redirects parametresi.
  • axios'ta: maxRedirects parametresi ile istediğiniz sayı.
  • fetch'te: manuel işlemede geçişleri döngüde kendiniz sayın.

Ziyaret edilen adresleri izleyerek döngülere karşı koruma

Güvenilir bir yöntem: ziyaret edilen URL'lerin bir kümesini saklayın. Her geçişten önce, bu adreste daha önce bulunup bulunmadığınızı kontrol edin. Bulunduysanız - zinciri bir hatayla kesin. Bu, birkaç adresten oluşan karmaşık döngüleri bile yakalar.

seen = set(); 
while url and url not in seen: 
seen.add(url); 
r = requests.request(method, url, headers=headers, proxies=proxies, allow_redirects=False); 
if r.status_code not in (301,302,303,307,308): break; 
url = r.headers["Location"]

İpucu: Her iki yöntemi de birleştirin: hem sayıya göre katı bir sınır hem de ziyaret edilen adresler kümesi. Sınır uzun zincirlere karşı korur, küme döngülere karşı. Birlikte tam koruma sağlarlar.

✅ Kontrol: Kodunuz, sunucu sonsuz bir döngü oluştursa bile herhangi bir yönlendirme zincirinde garantili olarak sonlanır. Ya son yanıta ulaşır ya da derinlik aşımı veya döngü tespiti hakkında anlaşılır bir hatayla kesilir.

Adım 6: Yönlendirmeler ve IP değişimi - zincir neden başka bir proxy'ye gidiyor?

Bu aşamanın amacı: proxy rotasyonunun yönlendirmelerle nasıl etkileşime girdiğini anlamak ve zincirin adımlarının farklı IP'ler üzerinden gitmesini önlemek.

Bu ince ve çoğu zaman hafife alınan bir noktadır. IP rotasyonlu bir Proxeon proxy havuzu kullanıyorsanız, adres değişiminin hangi düzeyde gerçekleştiğini anlamak önemlidir.

Adımlar neden farklı IP'ler üzerinden gidebilir?

Rotasyonunuzun her yeni bağlantıda IP değiştirecek şekilde ayarlandığını düşünün. Otomatik geçiş sırasında istemci, yönlendirmenin bir sonraki adımı için yeni bir bağlantı açabilir. Adımlar arasında rotasyon yeni bir IP verirse, ilk istek bir adresten, Location'a geçiş ise başka bir adresten gider. Birçok sunucu için bu şüpheli görünür: kimlik doğrulamayı bir istemci başlattı, ancak devamını başka bir istemci yapıyor gibi.

Bu sırada ne bozulur?

  • IP'ye bağlı oturumlar kesilir. Sunucu, devamın başka bir adresten geldiğini görür ve oturumu sıfırlar.
  • Belirli bir oturum için verilen çerezler kabul edilmez.
  • Zincir içinde tek bir kaynak bekleyen mantık kararsız davranmaya başlar.

Tek bir IP'de tek oturum nasıl tutulur?

Anahtar, zincirin tamamı boyunca IP'yi sabitlemektir. Proxeon, belirli bir süre boyunca aynı IP'yi tutan yapışkan oturum modunu destekler. Yönlendirme zincirinin bütünlüğünün önemli olduğu senaryolar için kullanın.

  1. Bağlantı ayarlarında, her istekte rotasyon yerine yapışkan oturum modunu seçin.
  2. IP tutma süresini tüm geçiş zincirini kapsayacak şekilde ayarlayın.
  3. Kodda tüm adımlar için tek bir istemci oturumu kullanın: requests'te requests.Session() nesnesi, httpx'te httpx.Client().
  4. Her adımda yeni bir bağlantı oluşturmak yerine bağlantıyı yeniden kullandığınızdan emin olun.

İpucu: Yönlendirme zincirinin bütünlüğü için her zaman tek bir istemci oturumu nesnesi oluşturun ve tüm adımları onun üzerinden geçirin. Bu hem bağlantıyı yeniden kullanır hem de istekler arasında çerezleri korur ve zincir ortasında başka bir IP'ye geçme olasılığını azaltır.

⚠️ Dikkat: Yapışkan oturumu sonsuz IP tutma ile karıştırmayın. Makul bir tutma süresi belirleyin - yalnızca işlem süresi kadar. Proxy ile ilgili tüm çalışmaların yasalara ve etkileşimde bulunduğunuz kaynakların kurallarına uygun olması gerektiğini unutmayın.

✅ Kontrol: Yönlendirme zincirinin tamamı aynı IP üzerinden geçer, oturum kesilmez, çerezler her adımda kabul edilir. Bunu, her adımda geçerli IP'nizi gösteren bir hizmeti sorgulayarak ve değişmediğini doğrulayarak kontrol edebilirsiniz.

Adım 7: Hata ayıklama - tüm zinciri ve adım adım kodları görme

Bu aşamanın amacı: yönlendirme zincirinin tam bir resmini elde etmek, yöntemin veya başlığın tam olarak nerede kaybolduğunu bilmek.

Körlemesine hata ayıklama, yönlendirmelerle yapılacak en kötü şeydir. Aşağıda zinciri görünür kılan araçlar bulunmaktadır.

curl'de tam günlük

-v bayrağı ayrıntılı modu etkinleştirir. Her isteği, her yanıtı, tüm başlıkları ve tüm geçişleri görürsünüz. -L bayrağıyla curl tüm zinciri gösterir.

curl -v -L --max-redirs 10 -x $PROXY_URL "https://example.com/login"

Çıktıyı yukarıdan aşağıya okuyun. Büyüktür işaretiyle başlayan satırlar sunucuya gidenleri, küçüktür işaretiyle başlayanlar yanıt olarak gelenleri gösterir. Böylece başlığın hangi adımda kaybolduğunu görürsünüz.

requests'te yönlendirme geçmişi

Otomatik geçişi açık bırakırsanız, son yanıtta history özniteliği bulunur - tüm ara yanıtların listesi. Üzerinden geçin ve her adımın kodunu ve URL'sini yazdırın:

r = requests.post(url, json=body, proxies=proxies); 
for h in r.history: print(h.status_code, h.url); 
print("final", r.status_code, r.url)

httpx'te yönlendirme geçmişi

follow_redirects açıkken, httpx yanıtında da history özelliği vardır. Mantık aynıdır: her ara yanıtın kodunu ve URL'sini döngüyle yazdırın.

axios ve fetch'te hata ayıklama

axios'ta manuel işlemede her yanıtı döngüde kendiniz günlüğe kaydedin. fetch'te manual modunda her adımda durumu ve Location başlığını yazdırın. Burada yerleşik bir geçmiş listesi yoktur, bu nedenle manuel günlük kaydı ana aracınızdır.

İpucu: Bir adım için tek bir günlük satırı formatı oluşturun: adım numarası, yöntem, URL, yanıt kodu, Location, Authorization varlığı. Böyle tablo şeklinde bir kayıt, yöntemin nerede GET'e dönüştüğünü veya belirtecin nerede kaybolduğunu anında gösterir. Bu, saatlerce hata ayıklama tasarrufu sağlar.

Günlüklerde ne aramalısınız?

  • Giden istekte yöntemin POST yerine GET olduğu an. Bu, 301, 302 veya 303 kodunun bir işaretidir.
  • Authorization başlığının kaybolduğu adım. Genellikle başka bir alan adına geçiştir.
  • Location değerinde alan adı veya protokol değişikliği - çerezlerin bayraklar nedeniyle kaybolduğu yer tam olarak budur.
  • Tekrarlanan adresler - döngü belirtisi.

✅ Kontrol: Herhangi bir istemci için kodlar ve URL'lerle tam geçiş zincirini çıkarabilir ve yöntemin değiştiği veya başlığın kaybolduğu adımı tam olarak belirtebilirsiniz.

Sonucu kontrol etme: kontrol listesi

Bu listeyi gözden geçirin. Tüm maddeler yerine getirildiyse, yönlendirmeleri tamamen yönetiyorsunuz demektir.

  1. 301, 302, 307 ve 308 kodları için yöntem ve gövde davranışını biliyorsunuz.
  2. Alan adı değiştiğinde Authorization'ın neden kaybolduğunu anlıyorsunuz.
  3. curl, requests, httpx, axios ve fetch için varsayılan davranışı biliyorsunuz.
  4. Otomatik geçişi kapatmak için çalışan bir örneğiniz var.
  5. Zinciri manuel işlemek için çalışan bir döngünüz var.
  6. Kodunuz sınırsız döngülere karşı limit ve ziyaret edilen adresler kümesiyle korunuyor.
  7. Gerektiğinde zincir bütünlüğü için Proxeon yapışkan oturumunu kullanıyorsunuz.
  8. Günlüklerde tam geçiş zincirini çıkarabiliyorsunuz.

Nasıl test edilir?

POST isteğine 302 koduyla yanıt veren bir test uç noktası alın. Otomatik geçişle çalıştırın ve yöntemin GET'e dönüştüğünü doğrulayın. Ardından yöntemi koruyarak manuel işlemeyle çalıştırın ve POST'un son adrese ulaştığını doğrulayın. Davranış farkı, her şeyi kontrol ettiğinizin kanıtı olacaktır.

✅ Kontrol: Hem otomatik geçiş hem de manuel işleme senaryoları öngörülebilir, açıklanabilir bir sonuç verir, rastgele değil.

Sık yapılan hatalar ve çözümleri

En yaygın tuzakları ve bunlardan kaçınma yollarını ele alalım.

Hata 1: POST GET'e dönüştü

Neden: sunucu 301 veya 302 kodu döndürdü ve istemci tarihsel kurala göre yöntemi değiştirdi. Çözüm: sunucuyu kontrol ediyorsanız, 307 veya 308 döndürün. Değilse - otomatik geçişi kapatın ve isteği manuel olarak istediğiniz yöntemle tekrarlayın.

Hata 2: Authorization başlığı kayboldu

Neden: yönlendirme başka bir alan adına götürdü, istemci güvenlik nedeniyle sırrı kaldırdı. Çözüm: Location'daki alan adını kontrol edin ve güvenilirse, sonraki isteğe Authorization'ı manuel olarak ekleyin.

Hata 3: Betik requests'te çalışıyordu, httpx'te bozuldu

Neden: httpx varsayılan olarak yönlendirmeleri takip etmez, requests ise takip eder. Çözüm: httpx'te açıkça follow_redirects=True ayarlayın veya tekdüzelik için her yerde manuel işlemeye geçin.

Hata 4: Uygulama zincirde asılı kaldı

Neden: derinlik sınırı olmayan sonsuz yönlendirme döngüsü. Çözüm: Adım 5'te gösterildiği gibi geçiş limiti ve ziyaret edilen adresler kümesi ekleyin.

Hata 5: Oturum zincirin ortasında sıfırlanıyor

Neden: proxy rotasyonu nedeniyle zincir adımları farklı IP'ler üzerinden gitti. Çözüm: Proxeon yapışkan oturumunu etkinleştirin ve tüm adımlar için tek bir istemci oturumu nesnesi kullanın.

Hata 6: Yönlendirmeden sonra çerez gönderilmiyor

Neden: Secure, Domain veya SameSite bayrağı yeni adresle uyuşmuyor. Çözüm: Location'daki protokolü ve alan adını kontrol edin ve çerez bayraklarıyla uyumlu olduklarından emin olun. Kolaylık için koruyucu bayrakları kaldırmayın.

Hata 7: curl yönlendirmeyi takip etmiyor

Neden: -L bayrağını unuttunuz. Çözüm: Otomatik geçiş için -L ekleyin veya manuel kontrol için onsuz bırakın - göreve bağlı olarak.

Ek yetenekler ve optimizasyon

Temel konularda uzmanlaştıktan sonra, düzeni sağlamak ve güvenilirliği artırmak faydalıdır.

Birleşik yönlendirme işleme modülü

Mantığı koda yaymayın. Zincir işlemeyi parametrelerle tek bir fonksiyonda toplayın: güvenilir alan adları listesi, maksimum derinlik, yöntemi koruyacak kodlar kümesi. Böylece davranış tüm projede tekdüze hale gelir.

Authorization için beyaz alan adları listesi

Yönlendirme sırasında Authorization'ın iletilmesine izin verilen alan adlarının açık bir listesini tutun. Liste dışındaki her şey - asla sırrı almaz. Bu, güvenliği rastgele değil, yönetilebilir kılar.

Zincir metrikleri

İstatistik toplayın: ortalama zincir uzunluğu, yönlendirmeli isteklerin oranı, en sık karşılaşılan kodlar. Zincir uzunluğundaki anormal artış, hedef sunucu tarafındaki sorunların erken bir işaretidir.

İpucu: Zincir üç geçişi aşarsa bir uyarı ayarlayın. Çoğu doğru senaryoda bir veya iki geçiş yeterlidir. Keskin bir artış, hedef kaynakta neyin değiştiğini araştırmak için bir nedendir.

SSS: Yönlendirme işleme hakkında sık sorulan sorular

Hiçbir şeyi değiştirmediğim halde POST neden GET'e dönüşüyor?

Çünkü sunucu 301 veya 302 kodu döndürdü ve istemciniz tarihsel kurala göre yöntemi GET olarak değiştirdi. Bunu önlemek için 307 veya 308 kodu veya manuel işleme gerekir.

Proxy yönlendirme sırasında istek yöntemini değiştirir mi?

Hayır. Proxeon ve herhangi bir doğru proxy yalnızca durumu ve Location'ı iletir. Yöntem değiştirme kararını HTTP istemciniz verir. Nedeni istemci ayarlarında aramalısınız.

Başka bir alan adına geçerken Authorization'ı nasıl korurum?

Yalnızca manuel olarak. Otomatik geçişi kapatın, Location'daki alan adını kontrol edin, güvenilir olduğundan emin olun ve sonraki isteğe Authorization başlığını kendiniz ekleyin.

POST yönlendirmesi için hangi kodu kullanmalıyım?

Geçici yönlendirme için 307, kalıcı yönlendirme için 308. Her ikisi de istek yöntemini ve gövdesini korur ve istemcileri sürprizlerden kurtarır.

Aynı betik requests ve httpx'te neden farklı davranıyor?

Çünkü requests varsayılan olarak yönlendirmeleri takip eder, httpx ise takip etmez. Davranışın eşleşmesi için geçiş ayarını açıkça belirtin.

Sonsuz yönlendirme döngüsünden nasıl korunurum?

Katı bir geçiş limiti belirleyin ve ziyaret edilen adresler kümesi tutun. Adres tekrarlanırsa veya limit aşılırsa - zinciri bir hatayla kesin.

Yönlendirme zincirinin ortasında oturum neden kesiliyor?

Büyük olasılıkla, adımlar rotasyon nedeniyle farklı IP'ler üzerinden gitti. Proxeon yapışkan oturumunu etkinleştirin ve tüm adımlar için tek bir istemci oturumu nesnesi kullanın.

Geçişten sonra çerez neden gönderilmiyor?

Secure, Domain veya SameSite bayraklarının yeni adresle uyuşmaması nedeniyle. Location'daki protokolü ve alan adını kontrol edin. Koruyucu bayraklar kaldırılamaz.

Geçiş zincirinin tamamını nasıl görebilirim?

curl'de -v -L kullanın. requests ve httpx'te son yanıtın history özniteliğine bakın. axios ve fetch'te her adımı manuel olarak günlüğe kaydedin.

Yönlendirmeleri tamamen yasaklayabilir miyim?

Evet. curl'de -L eklemeyin, requests'te allow_redirects=False ayarlayın, httpx'te follow_redirects'i açmayın, axios'ta maxRedirects: 0 yapın, fetch'te redirect: "manual" belirtin.

Sonuç

Artık proxy üzerinden yönlendirmelerle çalışmanın tam ve pratik bir resmine sahipsiniz. POST'un neden GET'e dönüştüğünü anladınız ve bunun suçlusunun proxy değil, 301 ve 302 kodlarını işlemenin tarihsel kuralları olduğunu biliyorsunuz. 301, 302, 307 ve 308 arasındaki farkı anlıyor ve doğru kodu seçebiliyorsunuz. Geçiş sırasında hangi verilerin kaybolduğunu biliyorsunuz: başka bir alan adında Authorization, özel başlıklar, koruyucu bayraklı çerezler.

curl, requests, httpx, axios ve fetch'in varsayılan davranışlarını incelediniz ve kodu taşırken tutarsızlıklara artık şaşırmayacaksınız. Otomatik geçişi kapatmak ve yöntemi ve başlıkları tamamen kontrol ederek zinciri manuel işlemek için çalışan örnekleriniz var. Döngülere karşı korunmayı ve Proxeon yapışkan oturumuyla tek bir IP'de tek oturumu tutmayı biliyorsunuz. Ve son olarak, zincirlerde hata ayıklamayı ve her adımı görmeyi biliyorsunuz.

Sırada ne var? Authorization için beyaz alan adları listesi ve yapılandırılabilir derinlik içeren birleşik bir yönlendirme işleme modülü oluşturun. Zincir uzunluğu metrikleri ekleyin. Gerçek senaryolarınızı manuel işlemeyle çalıştırın ve otomatik geçişle karşılaştırın - böylece verilerin kaybolduğu gizli yerleri bulursunuz.

Ağ yığınını daha derinlemesine incelemeye devam edin: çerez yaşam döngüsünü, TLS bağlantılarının inceliklerini ve bağlantıların yeniden kullanımını daha iyi anlayın. Bu becerilerin her biri, Proxeon proxy ile çalışmanızı daha da güvenilir ve öngörülebilir hale getirecektir. Başarılı mühendislik çalışmaları ve temiz, şeffaf istek zincirleri.