Proxy sunucu hatası 407, 502, 504 ve tunnel failed: yeni başlayanlar için adım adım teşhis

Giriş: Bu kılavuzdan ne kazanacaksınız

Mobil proxy'lerle çalışıyorsanız, er ya da geç parser loglarında, antidetect tarayıcı konsolunda veya doğrudan reklam hesabı penceresinde "407 Proxy Authentication Required", "502 Bad Gateway", "504 Gateway Timeout" ya da kısa ve ürkütücü "tunnel failed" gibi bir satırla karşılaşırsınız. Böyle bir anda proxy sunucu hatası bir kara kutuya benzer: proxy'nin kendisi mi, yazılımınız mı, hedef site mi yoksa sadece eski bir şifre mi suçlu, belli olmaz. Bu kılavuz kara kutuyu anlaşılır bir eylem planına dönüştürüyor.

Konuyu bilinçli olarak sınırlıyoruz: sadece proxy katmanının döndürdüğü kodları ve mesajları ele alıyoruz. Bağlantı seviyesindeki ağ zaman aşımları (hiç yanıt gelmediğinde ve istemcinin bekleme süresini kendisinin kestiği durumlar) blogda ayrı bir yazıda ele alındı ve burada tekrarlamıyoruz. Logunuzda tam olarak bir kod ya da tünel hakkında bir ifade varsa doğru yerdesiniz.

Sonunda ne elde edeceksiniz

• Dört hatanın her birinin ne anlama geldiğini ve "yazılımınız — proxy — hedef site" zincirinin tam olarak hangi noktasında ortaya çıktığını anlayacaksınız.
• Herhangi bir sistemde yerleşik olan curl aracıyla iki-üç dakika içinde sorunun kaynağını belirlemeyi öğreneceksiniz.
• 407, 502, 504 ve tunnel failed için kontrol listesi gibi uygulayabileceğiniz hazır eylem sıraları elde edeceksiniz.
• Yazılımınızı her koda doğru şekilde tepki verecek biçimde ayarlayacaksınız: bazı hatalar tekrarlanmalı, bazılarını tekrarlamak anlamsızdır.
• Bir sonraki arızada saatler kazandıracak kişisel bir olay günlüğü tutacaksınız.

Bu kılavuz kimler için

Kılavuz, mobil proxy kullanan ancak ağ mühendisi olmak zorunda olmayan pazarlamacılar, arbitraj uzmanları, küçük ekip sahipleri ve geliştiriciler için yazıldı. Ana bölüm yeni başlayanlara yönelik: her komut açıklandı, her eylem adım adım anlatıldı. Kendi script'lerini yazan ve daha derine inmek isteyenler için sonunda ayrı bir ileri düzey bölüm var.

Önceden bilmeniz gerekenler

Terminali ya da komut istemini açabilmek, içine metin yapıştırabilmek ve sonucu okuyabilmek yeterli. IP adresi ve portun ne olduğunu bilmek yardımcı olur ama buna da kısaca değineceğiz. Programlama deneyimi gerekmez.

Ne kadar zaman gerekir

Tam okuma ve ilk teşhis 60 ila 120 dakika sürer. Şu anda belirli bir hatanız yanıyorsa doğrudan ilgili adıma geçin: her bir hata için kontrollerle birlikte 15-25 dakika ayrılmıştır.

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

Proxy katmanı hatalarını teşhis etmek için ağır programlar kurmanız gerekmez. Neredeyse ihtiyacınız olan her şey işletim sisteminizde zaten var. Yine de arıza anında şifre aramamak ve konfigürasyonun nerede olduğunu hatırlamaya çalışmamak için önceden hazırlanmaya değer.

Gerekli araçlar

1. Terminal veya komut istemi. Windows 10 ve 11'de Başlat menüsünü açın, "cmd" veya "PowerShell" yazın ve Enter'a basın. macOS'te "Programlar", ardından "Yardımcı Programlar", ardından "Terminal"i açın. Linux'ta terminal genellikle Ctrl+Alt+T ile açılır.
2. curl aracı. Windows'ta 10. sürümden (derleme 1803) itibaren, macOS'te ve Linux dağıtımlarının çoğunda yerleşiktir. Kontrol edin: terminale curl --version yazın ve Enter'a basın. "curl 8.x.x" gibi sürüm numarası içeren bir satır görünmelidir. Bunun yerine komut bulunamadı yazıyorsa curl'ü sisteminizin paket yöneticisiyle kurun.
3. Geliştirici araçlarına sahip normal bir tarayıcı. F12 tuşuyla "Network" (Ağ) sekmesini açan herhangi bir modern tarayıcı işinizi görür.
4. Olay günlüğü tutmak için bir metin editörü. Not Defteri yeterli, ancak logların yapısını görmek için söz dizimi vurgulamalı bir araç daha kullanışlıdır.
5. Çalışma yazılımınız: antidetect tarayıcı, parser, reklam hesabı yöneticisi veya kendi script'iniz. Proxy ayarlarına ve loglarına erişmemiz gerekecek.

Gerekli erişimler

• Proxy sağlayıcınızın kontrol paneline giriş. mobileproxy.space kullanıcıları için bu, host, port, kullanıcı adı, şifre, yetkilendirme türü ve IP değiştirme bağlantısının göründüğü kanal yönetim sayfasıdır.
• En az bir proxy'nin güncel bilgileri: adres (host), port, kullanıcı adı ve şifre ya da adresle yetkilendirme için onaylanmış IP.
• Hangi protokolü kullandığınızı bilmek: HTTP(S) proxy mi yoksa SOCKS5 mi. Bu bilgiyi de panel gösterir.

Sistem gereksinimleri

Son sekiz yılda çıkan herhangi bir işletim sistemi. Proxy host'una erişilebilen bir internet bağlantısı. Başka bir şeye gerek yok.

Yedekler

Çalışma yazılımınızda proxy ayarlarını değiştirmeden önce mevcut durumu kaydedin. Bu beş dakikanızı alır ve bir hatayı "düzeltirken" aynı zamanda on hesabın çalışan konfigürasyonunu kaybetme durumundan kurtarır.

1. Antidetect tarayıcıda profil listesini proxy ayarlarıyla birlikte dışa aktarın. Genellikle dışa aktarma işlevi profil menüsündedir ve bir CSV veya JSON dosyası oluşturur.
2. Parser veya script'te konfigürasyon dosyasını adında tarih bulunan ayrı bir klasöre kopyalayın, örneğin "config_backup_2026-03-14".
3. Kontrol panelinden tüm kanalların bilgilerini bir metin dosyasına kopyalayın. Bu dosyayı başkalarının erişemeyeceği bir yerde saklayın.
4. Bilgisayarınızın veya sunucunuzun şu anki IP'sini yazın. IP adresiyle yetkilendirme kullanıyorsanız buna ihtiyacınız olacak.

İpucu: "Proxy günlüğü" adında tek bir metin dosyası oluşturun ve her hatayı "tarih, saat, kod, proxy host'u, hedef site, ne yaptım, ne işe yaradı" biçiminde kaydedin. Bir ay sonra herhangi bir makaleden daha faydalı olacak kişisel bir bilgi tabanınız olacak.

Kontrol: terminal açılıyor, curl komutu sürümü gösteriyor, kontrol paneline giriş yaptınız ve en az bir proxy'nin bilgilerini görüyorsunuz, konfigürasyon yedekleri ayrı bir klasörde. Devam edebilirsiniz.

Temel kavramlar: proxy katmanı nasıl çalışır ve kodlar nereden gelir

Proxy sunucu hatasını deneme yanılma yerine anlamlı şekilde düzeltmek için isteğin yolunu gözünüzde canlandırmanız gerekir. Yol üç bölümden oluşur ve dört hatamızın her biri kendi bölümünde yaşar.

İstek yolunun üç bölümü

• İstemci — proxy. Tarayıcınız, parser veya script proxy'nin host ve portuna bağlanır. Bu bölümde yetkilendirme kontrol edilir. 407 hatası ve tunnel failed durumlarının bir kısmı burada doğar.
• Proxy — mobil ağ — hedef site. Proxy sunucusu isteğinizi aldıktan sonra operatörün SIM kartına sahip modemi üzerinden kendi adına hedef siteye bir bağlantı açar. 502 ve 504 burada ortaya çıkar.
• Hedef site — dönüş yolu. Sitenin yanıtı aynı düğümlerden geri döner. Site kendi kodunu, örneğin 403 veya 429, döndürdüyse bu artık proxy katmanı hatası değildir ve bunları ayırt etmeyi öğrenmek önemlidir.

Kod sınıfları basit bir dille

Yanıt kodu, sunucunun yanıtın ilk satırı olarak gönderdiği üç basamaklı bir sayıdır. İlk basamak sınıfı belirtir. 4xx kodları "sorun sizin tarafınızda, isteği düzeltin" anlamına gelir. 5xx kodları "sorun sunucu tarafında ya da arkasında" demektir. Proxy katmanı için bu şöyle işler:

• 407 Proxy Authentication Required — proxy "Kim olduğunu bilmiyorum ya da bilgilerin hatalı" der. 4xx sınıfı: sorunu kendinizde düzeltmelisiniz.
• 502 Bad Gateway — proxy "Daha ileri gitmeyi denedim ama yanıt yerine bir kopma veya bozuk veri aldım" der. 5xx sınıfı: sorun proxy'nin arkasında ya da proxy'nin kendisinde.
• 504 Gateway Timeout — proxy "Bir sonraki düğümden yanıtı belirlenen süre boyunca bekledim ve alamadım" der. Bu da 5xx'tir.

504 kodu ile ağ zaman aşımı arasındaki fark

Bu, tüm makale için kilit ayrımdır. 504 kodu gördüğünüzde proxy sunucusu hayattadır, isteğinizi kabul etmiştir, sitenin yanıtını kendisi beklemiş ve başarısızlığı size kendisi bildirmiştir. Sizinle proxy arasındaki bağlantı bu sırada kusursuz çalışıyordu. Ancak istemciniz kodsuz olarak "connection timed out" veya "operation timed out" yazıyorsa hiç yanıt gelmemiştir ve kopmayı istemciniz başlatmıştır. Birincisi bu kılavuzun konusudur. İkincisi blogdaki ilgili yazılarda ele alınan başka bir konudur. Basit bir işaret: yanıtta üç basamaklı bir sayı varsa burada okumaya devam edin.

Tünel nedir ve neden "düşer"

Bir HTTP proxy üzerinden HTTPS sitesi açtığınızda, tarayıcı önce proxy'ye hedef adresi ve portu içeren özel bir CONNECT komutu gönderir. Proxy siteyle bir bağlantı açar ve "200 Connection established" yanıtını verir. Bundan sonra proxy üzerinden proxy'nin artık okuyamadığı şifreli bir akış geçer. Bu tür bağlantıya tünel denir. CONNECT komutuna proxy 200 dışında bir yanıt verdiyse, istemci "tunnel failed" yazar ve genellikle yanına hangi kodun geldiğini belirtir. Yani tunnel failed bağımsız bir hata değil, kodlardan birinin üzerine sarılmış bir sarmalayıcıdır.

İki yetkilendirme yöntemi

• Kullanıcı adı ve şifre. İstemci bunları Proxy-Authorization başlığında iletir. En yaygın yöntem ve 407'nin en sık kaynağı.
• IP ile yetkilendirme. Bilgisayarınızın veya sunucunuzun adresini önceden panele bildirirsiniz ve proxy bu adresten gelen tüm istekleri şifre olmadan kabul eder. Kullanışlıdır ancak IP'niz değiştiğinde bozulur.

Yanıtın sahibini gösteren servis başlıkları

Proxy sıklıkla yanıtlarına Via, Proxy-Agent veya X-Proxy başlıklarını ekler. Hedef siteler bunları eklemez. 502 kodu içeren yanıtta bir Proxy-Agent başlığı varsa yanıtı verenin kesinlikle proxy olduğunu bilirsiniz. Başlık yoksa ve site web sunucusunun adını taşıyan bir Server başlığı varsa, bu sitenin yanıtıdır. Bu işareti aktif olarak kullanacağız.

İpucu: şu anımsatıcı kuralı aklınızda tutun: "dörtlü — kendinde ara, beşli — proxy'nin arkasında ara, tünel — yanındaki sayıya bak". Bu kural vakaların yarısını daha fazla okumadan çözer.

Adım 1: Hatayı tam olarak kimin döndürdüğünü belirliyoruz

Bu aşamanın amacı: birkaç dakika içinde size proxy sunucusunun mu, hedef sitenin mi yoksa kendi yazılımınızın mı yanıt verdiğini kesin olarak belirlemek ve sonraki çalışmalar için tam yanıt metnini kayıt altına almak.

Talimatlar

1. Kontrol panelini açın ve sorunlu proxy'nin bilgilerini kopyalayın: host, port, kullanıcı adı, şifre. Örnek olarak host'un proxy.example.net, port'un 8080, kullanıcı adının user1, şifrenin pass1 olduğunu varsayalım. Kendi değerlerinizi yazın.
2. Terminali açın.
3. Bilgileri ve hedef adresi kendi değerlerinizle değiştirerek şu komutu yazın ve Enter'a basın: curl -v -x http://user1:pass1@proxy.example.net:8080 https://example.com/. -v anahtarı ayrıntılı çıktıyı açar, -x anahtarı proxy'yi belirtir.
4. Komutun bitmesini bekleyin. Genellikle bu bir-üç saniyedir. Komut 30 saniyeden uzun "asılı kalıyorsa" Ctrl+C'ye basın: büyük olasılıkla bu bir ağ zaman aşımıdır, kod değildir ve bizim konumuz değildir.
5. Çıktıda "büyüktür" işaretiyle başlayan satırları (curl'ün gönderdikleri) ve "küçüktür" işaretiyle başlayan satırları (yanıt olarak gelenler) bulun. Yanıtın ilk satırı "HTTP/1.1 407 Proxy Authentication Required" veya "HTTP/1.1 200 Connection established" biçiminde olacaktır.
6. CONNECT yazısının bulunduğu satıra bakın. Hemen ardından 200 dışında bir kod geldiyse, hatayı tünel aşamasında proxy döndürmüştür. CONNECT 200 aldıysa ve hata kodu daha sonra, TLS el sıkışması satırlarından sonra geldiyse, yanıtı hedef site vermiştir.
7. Yanıt başlıklarını bulun. Proxy-Agent, Via veya benzeri servis başlıklarının varlığı kesin olarak proxy'ye işaret eder. Web sunucusunun adını taşıyan bir Server başlığı ve Set-Cookie başlığı hedef siteye işaret eder.
8. Aynı komutu -x anahtarı olmadan, yani doğrudan tekrarlayın: curl -v https://example.com/. Site 200 döndürüyorsa ve proxy üzerinden 5xx geliyorsa, sorun proxy'nin arkasındaki bölümde yerelleşmiştir.
9. Komutu proxy üzerinden ancak başka bir siteye, örneğin istikrarlı büyük bir kaynağa tekrarlayın. İkinci site açılıyorsa sorun proxy'nin genelinde değil, belirli bir yönle ilgilidir.
10. Tüm çıktıyı tarih ve saatle birlikte proxy günlüğüne kopyalayın. Sonraki adımlarda buna ihtiyacınız olacak.

Tarayıcı üzerinden alternatif yol

Terminalde çalışmak rahatsız ediciyse, proxy ayarlı tarayıcıyı açın, F12'ye basın, "Network" sekmesine geçin, "Preserve log" (Günlüğü koru) kutusunu işaretleyin, sayfayı yenileyin. İstek listesinde kırmızı kodlu satırı bulun, üzerine tıklayın ve "Headers" sekmesinde "Response Headers" bloğunu inceleyin. Mantık aynı: proxy'nin servis başlıklarını arayın. Yöntemin dezavantajı, tarayıcının genellikle CONNECT aşamasının ayrıntılarını gizlemesidir, bu nedenle tunnel failed için terminal tercih edilir.

Dikkat: -v anahtarlı komut proxy kullanıcı adını ve şifresini açık şekilde yazdırır. Bu çıktıyı şifreyi yıldızlarla değiştirmeden genel sohbetlere, destek taleplerine veya ekran görüntülerine yapıştırmayın.

İpucu: Ekranı yanıt gövdesiyle doldurmamak için komuta -o anahtarı ve boş bir aygıt belirterek -sS ekleyin: curl -sS -v -o /dev/null -x http://user1:pass1@proxy.example.net:8080 https://example.com/. Windows'ta /dev/null yerine NUL kullanın.

Beklenen sonuç

Günlükte tam yanıtı içeren bir kayıt oluştu ve şu üç ifadeden birini rahatça söyleyebiliyorsunuz: "yetkilendirme aşamasında proxy yanıt verdi", "siteye başvuru aşamasında proxy yanıt verdi" veya "sitenin kendisi yanıt verdi". Bu sizi adım 2'ye, 3-4'e ya da tamamen bu makalenin dışına yönlendirir.

Olası sorunlar

• Komut "Could not resolve proxy" yazıyor. Host'ta yazım hatası var. Panelden karakter karakter karşılaştırın.
• Komut "Failed to connect to proxy" yazıyor. Port kapalı veya yanlış. Bu bir taşıma sorunudur, kod değildir; portu kontrol edin ve başka bir kanal deneyin.
• Çıktı kodsuz olarak TLS satırında kesiliyor. Bu, tünelin kurulduğu ama sitenin istemcinizin tanıdığı süre içinde yanıt vermediği anlamına gelir. 504 ile karıştırmayın: kod yok, yani bu bizim konumuz değil.

Kontrol: yanıtın sahibini ve tam kodu veya ifadeyi söyleyebiliyorsunuz ve curl çıktı satırı günlüğe kaydedilmiş durumda.

Adım 2: 407 Proxy Authentication Required hatasını gideriyoruz

Bu aşamanın amacı: proxy'nin CONNECT komutuna 407 yerine "200 Connection established" yanıtı vermesini sağlamak ve hatanın geri dönmemesi için nedenini anlamak.

407 neden ortaya çıkar

Proxy kimlik bilgilerinizi kabul etmedi. Genellikle altı neden vardır ve bunları artan zorluk sırasına göre kontrol edeceğiz: yazım hatası, şifrede özel karakterler, adresle yetkilendirmede IP'nizin değişmesi, kanalın süresinin dolması, yazılımın verileri hiç iletmemesi, tarayıcıdaki eski verilerin önbelleği.

Talimatlar

1. Kontrol panelini açın ve sorunlu kanalı bulun. Kanalın süresinin dolmadığından ve durumunun aktif olduğundan emin olun. Süre dolmuşsa uzatın ve bir dakika sonra isteği tekrarlayın; bu durumda daha ileri gitmenize gerek yok.
2. Kanal için hangi yetkilendirme türünün açık olduğunu kontrol edin: kullanıcı adı ve şifre mi yoksa IP adresiyle mi. Birçok panel ikisini aynı anda açmanıza izin verir.
3. IP ile yetkilendirme açıksa bilgisayarınızın veya sunucunuzun güncel dış adresini öğrenin. Proxy olmadan tarayıcıda IP'nizi gösteren herhangi bir servisi açın ve panelde kayıtlı adresle karşılaştırın. Ev sağlayıcıları ve mobil operatörler yönlendiriciyi yeniden başlattıktan sonra adresi sıklıkla değiştirir. Adresler ayrıştıysa panelde güncelleyin ve bir-iki dakika bekleyin: değişiklikler anında uygulanmaz.
4. Kullanıcı adı ve şifre kullanılıyorsa bunları panelden yeniden kopyalayın, elle yazmayın. Adım 1'deki curl komutuna yapıştırın ve çalıştırın. 407 vakalarının yarısı burada son bulur.
5. Şifreye bakın. İçinde @, :, /, #, ?, % veya boşluk karakteri varsa adres dizesine aktarırken kodlanması gerekir. @ karakteri %40'a, iki nokta %3A'ya, kare işareti %23'e, yüzde işareti %25'e dönüşür. Örneğin p@ss:1 şifresi URL'de p%40ss%3A1 olarak yazılır. Kodlamamak için verileri ayrı bir anahtarla iletin: curl -v -x proxy.example.net:8080 --proxy-user user1:p@ss:1 https://example.com/. Burada curl karakterleri kendisi halleder.
6. curl geçiyorsa ama çalışma yazılımınız hâlâ 407 alıyorsa sorun yazılımın kendisindedir. Proxy ayarlarını açın. Kullanıcı adı ve şifrenin program bunu beklemiyorsa adrese yapıştırılmak yerine ayrı alanlara girildiğinden emin olun. Şifrenin sonunda boşluk olup olmadığını kontrol edin: kopyalama sırasında sıklıkla oluşur.
7. Antidetect tarayıcıda genel ayarlar yerine belirli bir profilin ayarlarını açın. Birçok kullanıcı şifreyi ortak proxy listesinde değiştirir ama profil eski kopyayı saklamaya devam eder. Proxy'yi profilde yeniden kaydedin ve profili yeniden başlatın.
8. Tarayıcı eski verileri hatırlıyor ve yenilerini sormuyorsa bu host için kayıtlı şifreleri tarayıcı ayarlarından temizleyin veya test için yeni bir profil oluşturun.
9. 407 yanıtındaki Proxy-Authenticate başlığına dikkat edin. Orada "Basic" yazıyorsa proxy normal kullanıcı adı-şifre çiftini bekliyor demektir. Başka bir şema belirtilmişse yazılımınızın bunu desteklemesi gerekir; mobil proxy'ler için neredeyse her zaman Basic kullanılır ve uyuşmazlık proxy tipi ayarlarında bir hata olduğu anlamına gelir.
10. curl isteğini tekrarlayın ve CONNECT'e artık 200 geldiğinden emin olun.

Dikkat: 407'yi istekleri toplu şekilde tekrarlayarak "çözmeye" çalışmayın. Bazı proxy sunucuları bir dizi hatalı yetkilendirmeden sonra adresi geçici olarak bloke eder ve başlangıçtaki sorunun üzerine ek bir sorun daha eklenir. Bir kontrol, bir düzeltme, bir kontrol.

İpucu: Onlarca kanalınız varsa bunları kullanıcı adı ve şifrenin ayrı sütunlarda bulunduğu ve yanında URL için zaten kodlanmış şifre sütunu olan bir tabloda saklayın. Böylece hangi varyantın nereye gireceğini asla karıştırmazsınız.

Beklenen sonuç

curl çıktısında CONNECT'e verilen yanıt satırı "HTTP/1.1 200 Connection established" oldu, site içerik döndürdü. Çalışma yazılımınızda istekler geçiyor. Günlükte neden kaydedildi: yazım hatası, kodlama, IP değişikliği, süre dolması veya önbellek.

Olası sorunlar

• 407 kodu iki kez geliyor: önce CONNECT'te, sonra tünelin içinde. Bu, yazılımın verileri yalnızca bir aşamaya gönderdiğinin işaretidir. Programı güncelleyin veya içinde CONNECT'te yetkilendirme aktarma seçeneğini açın.
• Panel IP'nin eklendiğini söylüyor ama 407 devam ediyor. Muhtemelen kurumsal ağ ya da birden fazla çıkış adresi olan bir sunucu üzerinden çalışıyorsunuz. Adresi tam olarak isteklerin gittiği makineden kontrol edin.
• Sizde çalışıyor, aynı verilerle iş arkadaşınızda çalışmıyor. IP ile yetkilendirmede bu beklenen bir durumdur: arkadaşınızın adresi farklıdır. Kullanıcı adı ve şifreye geçin veya ikinci IP'yi ekleyin.

Kontrol: curl ve çalışma yazılımı üzerinden art arda üç istek 407 olmadan geçti, neden günlüğe kaydedildi.

Adım 3: Proxy'nin 502 Bad Gateway hatasını ele alıyoruz

Bu aşamanın amacı: IP değişimi sırasındaki kısa süreli arızayı yön veya kanalla ilgili kalıcı bir sorundan ayırt etmek ve her durum için doğru tepkiyi seçmek.

Proxy neden 502 döndürür

Proxy isteğinizi kabul etti, daha ileri bir bağlantı açmayı denedi ve bir kopma, ret veya okunamayan yanıt aldı. Mobil proxy'ler için tipik nedenler şunlardır: modem o anda IP adresini değiştiriyordu veya operatör ağına yeniden kaydoluyordu; hedef site bağlantıyı sıfırladı; proxy tarafında sitenin alan adı çözümlenemedi; kanal aşırı sayıda eşzamanlı akışla aşırı yüklendi; site herkes için erişilemez durumda.

Talimatlar

1. 502'nin ortaya çıktığı tam zamanı saniyesiyle kaydedin. Bu bir sonraki madde için önemlidir.
2. Panelde bu kanalın IP değişim geçmişini açın veya planlı otomatik rotasyonun açık olup olmadığını hatırlayın. Rotasyon hatayla aynı saniyelerde çalıştıysa normal davranışla karşılaştınız: adres değişimi sırasında istekler iki-on saniye boyunca 502 alır. Çözüm: isteği bir aradan sonra tekrarlamak.
3. On saniye bekleyin ve Adım 1'deki curl komutunu tekrarlayın. Yanıt 200 olduysa günlüğe "rotasyon anında 502" yazın ve Adım 6'daki tekrar ayarına geçin.
4. 502 ısrarla tekrarlanıyorsa aynı proxy üzerinden başka bir siteyi kontrol edin. Açıldıysa sorun yönde. Açılmadıysa sorun kanalda.
5. Yöndeki sorun için: hedef siteyi proxy olmadan doğrudan açın. Doğrudan da erişilemiyorsa veya 5xx döndürüyorsa proxy'nin suçu yok: site çökmüş. Doğrudan her şey çalışıyorsa site muhtemelen bu operatörün adresleriyle bağlantıları koparıyordur. Paneldeki bağlantıdan IP'yi değiştirin ve tekrarlayın. İşe yaramadıysa başka bir operatörün veya bölgenin kanalını deneyin.
6. Kanaldaki sorun için: panelde donanım durumunu kontrol edin. Birçok sağlayıcıda modem durumu göstergesi vardır. Kırmızı veya sarı durum, kanalın kurtarılmakta olduğunu ve yalnızca beklemeniz ya da yedek kanala geçmeniz gerektiğini gösterir.
7. Yükü kontrol edin. Yazılımınızda bu kanal üzerinden kaç eşzamanlı akışın gittiğine bakın. Mobil kanalın sınırlı bant genişliği vardır ve onlarca paralel bağlantıda proxy isteklerin bir kısmını tam da 502 ile reddetmeye başlar. Paralelliği yarıya düşürün ve testi tekrarlayın.
8. Sorunun DNS ile ilgili olup olmadığını kontrol edin. Site izin veriyorsa isteği alan adı yerine IP adresine yapın veya adları proxy'nin çözümlediği socks5h şemasına geçin ve sonucu karşılaştırın. İsme göre 502, IP'ye göre her şey çalışıyorsa sorun proxy tarafında ad çözümlemesindedir; sağlayıcıya alan adının tamamını bildirin.
9. 15 dakika içinde hiçbir şey işe yaramadıysa curl -v çıktısını, zamanı, kanal host'unu, hedef alan adını toplayın ve sağlayıcı desteğine gönderin. Doğru toplanan bilgi çözüm süresini bir günden bir saate indirir.

İpucu: planlı rotasyonla çalışırken yazılımdaki duraklamaları IP değişim aralığıyla önceden eşitleyin. Adres her 5 dakikada bir değişiyorsa parser her beş dakikalık dilimin başında 15 saniye duraklasın. Tek satır karmaşık kod yazmadan 502 sayısı neredeyse sıfıra düşer.

Beklenen sonuç

502'nizin hangi kategoriye girdiğini tam olarak biliyorsunuz: rotasyon anı, belirli bir yön, kanal aşırı yükü, donanım arızası veya sitenin erişilemezliği. İlk üçü için düzeltmeniz var, son ikisi için neyi bekleyeceğinizi ve kime yazacağınızı biliyorsunuz.

Olası sorunlar

• 502 yalnızca büyük dosyalarda geliyor. Site yavaş gönderim hızı nedeniyle bağlantıyı kapatıyor. İstenen veri boyutunu küçültün veya kapsaması daha iyi olan bir kanal kullanın.
• 502 proxy'den değil siteden geliyor. Başlıkları kontrol edin: orada sitenin Server'ı varsa ve Proxy-Agent yoksa bu sitenin iç arızasıdır, daha sonra tekrarlayın.
• 502 görünür bir mantık olmadan 200 ile dönüşümlü geliyor. Klasik kanal aşırı yükü işareti. Kararlı bir sonuç alana kadar paralelliği düşürün.

Kontrol: sorunlu kanal üzerinden kararlı bir siteye iki saniye arayla yapılan art arda on istek 200 döndürüyor ya da elinizde tüm verileri içeren bir destek talebi var.

Adım 4: 504 Gateway Timeout koduyla çalışıyoruz

Bu aşamanın amacı: proxy'nin arkasında zamanın hangi bölümde kaybolduğunu anlamak ve 504 oranını kodu istemcinin ağ zaman aşımıyla karıştırmadan kabul edilebilir bir seviyeye indirmek.

Proxy'den gelen 504 tam olarak ne anlama gelir

Proxy sunucusunun sitenin yanıtını beklemek için kendi iç limiti vardır. Site bu limit içinde yanıt veremezse proxy beklemeyi bırakır ve başarısızlığı size 504 koduyla dürüstçe bildirir. İstemciniz bu sırada bağlantıyı kesmemiştir, yanıt gelmiştir. Bu nedenle yazılımınızdaki bekleme limitinin proxy'nin limitinden büyük olması önemlidir: aksi halde kodsuz ağ zaman aşımı görürsünüz ve ne olduğunu anlayamazsınız.

Talimatlar

1. Yazılımınızdaki bekleme limitini kontrol edin. Çoğu programda timeout, "yanıt bekleme süresi" veya "Read timeout" olarak adlandırılır. 30 saniyeden azsa geçici olarak 60 yapın. Bu bir teşhis adımıdır: tam olarak proxy'den kodu beklemek için gereklidir.
2. Proxy üzerinden yanıt süresini ölçün. Şunu çalıştırın: curl -sS -o /dev/null -w "%{http_code} %{time_connect} %{time_starttransfer} %{time_total}" -x http://user1:pass1@proxy.example.net:8080 https://example.com/. -w anahtarı dört sayı yazdırır: kod, bağlantıya kadar geçen süre, ilk bayta kadar geçen süre ve saniye cinsinden toplam süre.
3. Aynı komutu -x anahtarı olmadan çalıştırın. İlk bayta kadar geçen süreyi karşılaştırın. Doğrudan site 0,4 saniyede yanıt veriyor, proxy üzerinden 8 saniyede yanıt veriyorsa "proxy — site" bölümündeki gecikme büyüktür ve mobil ağdaki her dalgalanmada 504 görünecektir.
4. 504'ün hangi istekte ortaya çıktığını kontrol edin. Sayfa gövdesini yüklemeyen HEAD yöntemiyle istek yapın: curl -I -x http://user1:pass1@proxy.example.net:8080 https://example.com/. HEAD geçiyor ama sayfanın GET'i 504 veriyorsa sorun bağlantının kendisinde değil, boyutta veya yavaş sayfa üretimindedir.
5. Paneldeki bağlantıdan kanalın IP'sini değiştirin. Mobil ağ homojen değildir: bir adres yüklü bir baz istasyonuna, bir diğeri boş olana düşebilir. Ölçümü tekrarlayın. Süre birkaç kat düştüyse yazılıma bir kural ekleyin: 504'te önce IP'yi değiştir, sonra isteği tekrarla.
6. Hedef sayfanın ağırlığını kontrol edin. Bazı siteler yanıtı ancak uzun süren sunucu işlemlerinden sonra verir. Amacınız belirli verilerse aynı sitede daha hafif bir adrese başvurmayı deneyin: bir API'ye, mobil sürüme, sıralama parametresi olmayan bir sayfaya.
7. 504 yalnızca belirli bir alan adına ve yalnızca bir operatörün kanalları üzerinden geliyorsa bunu günlüğe kaydedin ve bu alan adıyla çalışmayı başka bir operatörün kanallarına yeniden dağıtın.
8. Yazılımdaki bekleme limitini çalışma değerine döndürün, ancak artık bilinçli olarak: proxy üzerinden tipik yanıt süresinden biraz büyük ve görev çerçevesinde beklemeye razı olduğunuzdan küçük olmalı. Çoğu senaryo için bu 30-45 saniyedir.

Dikkat: Yazılımdaki bekleme limitini "her ihtimale karşı" birkaç dakikaya ayarlamayın ve sonsuza kadar öyle bırakmayın. Takılan tek bir akış kuyruktaki yeri bloke eder ve on takılan akış, sorun tek bir yavaş sitedeyken proxy'nin çalışmadığı izlenimini yaratır.

İpucu: Yazılımınızın günlüğüne "ilk bayta kadar geçen süre" sütunu ekleyin. Bu sütundan kanalın kademeli olarak mı bozulduğu yoksa ani mi düştüğü görülür. Kademeli artış aşırı yük veya kötü kapsama, ani düşüş genellikle rotasyon veya operatörde arıza anlamına gelir.

Beklenen sonuç

Her kanal üzerinden tipik yanıt süresini biliyorsunuz, yazılımda limiti proxy limitinin üzerine ayarladınız ve 504 otomatik tepki kurulmuş nadir bir olay haline geldi.

Olası sorunlar

• Limiti artırdınız ama 504 yerine ağ zaman aşımı gelmeye başladı. Bu, proxy'nin düşündüğünüzden daha uzun beklediği ya da proxy'nin kendisiyle bağlantının kararsız olduğu anlamına gelir. Bu artık kodların kapsamı dışındadır, zaman aşımları hakkındaki ilgili yazılara bakın.
• 504 yalnızca belirli saatlerde. Mobil ağlarda akşam yük zirvesi. Ağır görevleri geceye veya sabaha kaydırın.
• Yeni bir siteye ilk istekte 504, sonra her şey hızlı. Proxy tarafında ilk ad çözümlemesi ve bağlantı kurulumu. Ana seriden önce bir ısıtma isteği ekleyin.

Kontrol: çalışan bir siteye yirmi isteklik bir seri ilk bayta kadar geçen süreyi öngörülebilir bir aralıkta gösteriyor ve en fazla bir-iki 504 var, yazılım 504'te IP'yi değiştirip isteği tekrarlıyor.

Adım 5: tunnel failed hatasını düzeltiyoruz

Bu aşamanın amacı: tunnel failed ifadesinin yanındaki sayıyı okumayı, onu gerçek nedenle eşleştirmeyi ve protokol, port ve proxy tipi ayarlarını düzeltmeyi öğrenmek.

Nasıl görünür ve ne anlama gelir

curl'de mesaj şöyle görünür: "CONNECT tunnel failed, response 407". Tarayıcılarda ve antidetect çözümlerinde bunlar "Proxy tunnel failed", "Unable to establish tunnel" veya "Tunnel connection failed" ifadeleri olabilir. Ortak nokta tek: istemci CONNECT komutunu gönderdi ve proxy 200 dışında bir yanıt verdi. Yanındaki sayı tam da o koddur ve onunla çalışmak önceki adımlara artı yalnızca tünel aşamasında ortaya çıkan birkaç özel duruma indirgenir.

Talimatlar

1. curl'ü -v anahtarıyla bir HTTPS adresine çalıştırın ve tunnel failed satırını bulun. "response" kelimesinden sonraki sayıyı kaydedin.
2. Bu 407 ise Adım 2'ye dönün. Tek fark: yazılımın yetkilendirmeyi tam olarak CONNECT aşamasında ilettiğinden emin olun. Bazı programların eski sürümlerinde "Proxy yetkilendirmesi" onay kutusu yalnızca HTTP isteklerinde geçerlidir ve tünel şifresiz gider.
3. Bu 502 veya 504 ise Adım 3 ve 4'e dönün. Proxy sitenin 443 portuna bağlantı açamadı veya onu bekleyemedi.
4. Bu 403 ise proxy belirtilen port veya host'a tünel açmayı reddetti. Hangi porta bağlandığınızı kontrol edin. Mobil proxy'ler genellikle 443 ve birkaç yaygın porta tünellere izin verir. Servisiniz standart dışı bir port dinliyorsa panelde veya sağlayıcıda izin verilip verilmediğini sorun.
5. Bu 400 ise proxy komutu anlamadı. En sık neden, SOCKS5 proxy'yi HTTP olarak ya da tersini belirtmenizdir. Paneli açın ve size hangi protokolün ve portun verildiğine bakın. Birçok sağlayıcıda aynı kanalın HTTP ve SOCKS5 için farklı portları vardır.
6. Komuttaki şemayı düzeltin. SOCKS5 için şunu kullanın: curl -v -x socks5h://user1:pass1@proxy.example.net:1080 https://example.com/. socks5h'deki h harfi alan adlarını bilgisayarınızın değil proxy'nin çözümlediği anlamına gelir. Mobil proxy'ler için bu tercih edilen varyanttır.
7. Antidetect tarayıcıdaysanız profilin proxy ayarlarını açın ve tip açılır listesini bulun: HTTP, HTTPS, SOCKS5. Panelde belirtileni seçin ve portu kontrol edin. Kaydettikten sonra profili sekmeyi yenilemek yerine tamamen yeniden başlatın.
8. tunnel failed yanında sayı yoksa ve yalnızca ifade varsa yazılımda ayrıntılı günlük kaydını açın veya durumu curl üzerinden yeniden üretip kodu alın.
9. Yazılımınızın proxy'nin kendisiyle TLS bağlantısı kurmaya çalışıp çalışmadığını kontrol edin. Bazı programlar "HTTPS" tipini seçtiğinizde yalnızca siteye giden trafiği değil proxy'ye bağlantıyı da şifreler. Proxy bunu desteklemiyorsa tunnel failed veya el sıkışma hatası alırsınız. Proxy'ye bağlantı için "HTTP" tipine geçin: siteye giden trafik yine de tünel içinde şifreli kalır.
10. Testi tekrarlayın ve CONNECT'in 200 aldığından ve sayfanın yüklendiğinden emin olun.

İpucu: İki kısa test isteğini günlük rutininizin bir parçası yapın: biri adrese HTTP üzerinden, ikincisi aynı adrese HTTPS üzerinden. Birincisi geçip ikincisi tunnel failed ile düşüyorsa sorunun yetkilendirmede veya kanalda değil tünelde olduğunu bir saniyede anlarsınız.

Beklenen sonuç

tunnel failed ifadesi günlüklerden kayboldu, her kanal için doğru tip ve port kaydedildi ve yazılımda proxy'ye gereksiz şifreleme açık değil.

Olası sorunlar

• Tünel kuruluyor ama sonra sertifika hatası geliyor. Bu artık proxy katmanı değil: site veya sistem sertifika setiniz. Bilgisayardaki tarih ve saati kontrol edin.
• Aynı verilerle curl'de çalışıyor, yazılımda çalışmıyor. Yazılım farklı bir şema uyguluyor veya kendi ön ekini ekliyor. Proxy dizesi biçimiyle ilgili dokümantasyonunu inceleyin.
• tunnel failed yalnızca tek bir site için. Site standart dışı bir port kullanıyor, 403 maddesine dönün.

Kontrol: curl ve çalışma yazılımı üzerinden HTTPS isteği CONNECT'te 200 veriyor, tüm kanallar için tip ve port tabloda kayıtlı.

Adım 6: Yazılımın her koda doğru tepkisini ayarlıyoruz

Bu aşamanın amacı: proxy sunucu hatalarının otomatik işlenmesini sağlamak: bazıları arayla tekrarlansın, bazıları hemen alarm kaldırsın ve siz kırmızı satır akışı yerine anlaşılır günlükler alasınız.

İlke: tüm hatalar aynı değildir

407'de isteği tekrarlamak anlamsızdır: şifre tekrarla doğru olmaz. Rotasyon anında 502'yi tekrarlamak gereklidir: beş saniye sonra her şey çalışır. 504'ü IP değiştirdikten sonra tekrarlamak daha iyidir. Bu üç kural sağlıklı hata işlemenin temelini oluşturur.

Hazır yazılım için talimatlar

1. Parser veya hesap yöneticisinin ayarlarını açın ve tekrarlardan sorumlu bölümü bulun. "Retries", "Yeniden denemeler", "Hata işleme" olarak adlandırılmış olabilir.
2. 5xx için tekrar sayısını 3'e, aralarındaki başlangıç duraklamasını 5 saniyeye ve iki kat artışla ayarlayın: 5, 10, 20 saniye. Duraklamaların bu şekilde artmasına üstel gecikme denir ve yazılımınızın aşırı yüklü kanalı bitirmesini engeller.
3. Yazılım tekrar için kod listesi belirlemeye izin veriyorsa 502 ve 504 yazın. 407'yi eklemeyin.
4. 407'de eylem ayarını bulun. Yoksa genel bölümdeki tekrar sayısını minimuma ayarlayın ve başarısız istekler için bildirimi açın. Amacınız 407'yi bir günlük kesinti sonrasında değil ilk dakikalarda görmek.
5. IP değiştirme bağlantısı için bir alan varsa bulun. İlgili kanalın panel bağlantısını oraya yapıştırın ve "Hata durumunda IP değiştir" veya "Başarısızlıkta rotasyon" seçeneğini açın.
6. Bir mobil kanal üzerindeki eşzamanlı akış sayısını sınırlayın. 3-5 ile başlayın ve 502 oranı yüzde birin altında kalana kadar artırın.
7. Yanıt kodunu ve başlıkları kaydeden ayrıntılı günlüğü açın. Günlükte proxy'den gelen kod ile siteden gelen kod arasındaki farkın göründüğünden emin olun: birçok program bunu ayrı bir "Proxy status" sütununda gösterir.
8. Ayarları kaydedin, yazılımı yeniden başlatın ve 50 isteklik bir test serisi yapın.

Kendi script'iniz için talimatlar

Kod yazıyorsanız mantık aynıdır. requests kütüphanesiyle Python'da sözde kod şöyle görünür:

proxies = {"http": "socks5h://user1:pass1@proxy.example.net:1080", "https": "socks5h://user1:pass1@proxy.example.net:1080"} for attempt in range(3): r = session.get(url, proxies=proxies, timeout=45) if r.status_code == 407: alert("auth failed") break if r.status_code in (502, 504): rotate_ip() sleep(5 * 2 ** attempt) continue break

Üç noktaya dikkat edin. Birincisi: 407'de döngüden hemen çıkıp bildirim gönderiyoruz. İkincisi: 502 ve 504'te önce IP'yi değiştiriyor, sonra artan duraklamayı bekliyoruz. Üçüncüsü: timeout değeri, proxy'den kodu beklemek ve bağlantıyı daha erken kesmemek için seçildi.

Dikkat: Bazı kütüphanelerde CONNECT aşamasındaki hata kodlu yanıt olarak değil, içinde tunnel failed ve sayı bulunan metinli bir istisna olarak gelir. Bu tür istisnaları ayrı yakalayın ve kodu metinden çıkarın, aksi halde tekrar mantığınız çalışmaz.

İpucu: Her kanal için kodların günlük oranlarını sayın ve basit bir tabloya dökün. 5xx oranı diğerlerinden sürekli yüksek olan kanalı, biçimsel olarak çalışsa bile ilk önce kontrol etmeye değer.

Beklenen sonuç

Yazılım 502 ve 504'te istekleri artan duraklamayla ve IP değişimiyle otomatik olarak tekrarlıyor, 407'yi anında bildiriyor, akış sayısını sınırlıyor ve proxy ile site kodlarını ayırarak günlük tutuyor.

Olası sorunlar

• Yazılım 407'yi de tekrarlıyor ve proxy adresi geçici olarak bloke ediyor. 4xx için tekrarları tamamen kapatın veya toplam tekrar sayısını bire düşürün.
• Hata durumunda rotasyon açıldıktan sonra IP çok sık değişiyor. Minimum değişim aralığı girin, örneğin 60 saniye, böylece bir 502 serisi art arda beş rotasyon tetiklemesin.
• Günlük gigabaytlara ulaşıyor. Başlıkları yalnızca hata kodlu yanıtlar için yazın, 200 için tek satır saklayın.

Kontrol: 50 isteklik test serisi elle müdahale olmadan tamamlandı, günlükte 5xx için 5, 10, 20 saniyelik duraklamalı tekrarlar görülüyor ve yanlış şifre girildiğinde yazılım durup 407 bildirimi verdi.

Sonucu kontrol etme: kontrol listesi ve testler

Listeyi gözden geçirin ve her maddeyi işaretleyin. En az biri tamamlanmadıysa ilgili adıma dönün.

Kontrol listesi

• -v anahtarlı curl komutu çalışıyor ve çıktıda CONNECT yanıt satırını ve proxy'nin servis başlıklarını bulmayı biliyorsunuz.
• Her kanal için tabloda host, port, protokol tipi, yetkilendirme yöntemi ve kodlanmış şifre kayıtlı.
• IP ile yetkilendirmede makinenizin güncel adresi paneldeki adresle eşleşiyor.
• Her kanal üzerinden HTTPS isteği CONNECT'te 200 alıyor.
• Her kanal üzerinden ilk bayta kadar tipik süre ölçüldü ve yazılımdaki bekleme limiti bunu payla birlikte aşıyor.
• Yazılımda tekrarlar yalnızca 502 ve 504 için, 5, 10, 20 saniyelik duraklamalarla ve tekrardan önce IP değişimiyle ayarlandı.
• 407'de yazılım duruyor ve bildirim veriyor.
• Kanal başına akış sayısı sınırlı ve test serisi boyunca 5xx oranı yüzde birin altında.
• Olay günlüğü tutuluyor ve en az bir tamamen çözümlenmiş kayıt içeriyor.

Nasıl test edilir

1. Bilinçli olarak yanlış şifre girin ve tek bir istek çalıştırın. Beklenen: curl'de 407 ve yazılımda tekrar serisi olmadan bildirim.
2. Doğru şifreyi geri koyun ve kararlı bir siteye bir saniye arayla 30 istek çalıştırın. Beklenen: hepsi 200 ya da başarılı tekrarla en fazla bir 5xx.
3. Seri sırasında paneldeki IP değiştirme bağlantısına tıklayın. Beklenen: günlükte bir-iki 502, ardından otomatik tekrar ve serinin devamı.
4. HTTP olarak verilen bir kanal için ayarlarda SOCKS5 tipini belirtin ve bir istek yapın. Beklenen: bir saniyede tanıyacağınız tunnel failed veya protokol hatası. Doğru tipi geri koyun.

Başarılı yürütmenin göstergeleri

Çalışma serilerinde proxy katmanı hatalarının oranı yüzde bir-ikiyi aşmıyor, her hata koda göre sınıflandırılmış ve 407 dışında hiçbiri elle müdahale gerektirmiyor. 407'ye tepki süresi saatler değil dakikalar.

Tipik hatalar ve çözümleri

Sorun: yönlendiriciyi her yeniden başlatmadan sonra 407

Neden: IP ile yetkilendirme var ve sağlayıcı dinamik adres veriyor.

Çözüm: kullanıcı adı ve şifreyle yetkilendirmeye geçin veya ikisini aynı anda açın. Mutlaka IP gerekiyorsa sağlayıcıdan statik adres isteyin.

Sorun: şifre doğru ama curl geçerken tarayıcıda 407

Neden: Tarayıcı veya antidetect tarayıcı profili eski verileri önbelleğe aldı.

Çözüm: Proxy'yi belirli profilin ayarlarında yeniden kaydedin ve profili yeniden başlatın, gerekirse proxy host'u için kayıtlı şifreleri temizleyin.

Sorun: 502 tam olarak her N dakikada bir

Neden: Otomatik IP rotasyonu aralığıyla çakışıyor.

Çözüm: Yazılımın duraklamalarını rotasyon planıyla eşitleyin veya görevler arasında uygun anlarda bağlantıdan IP değişimine geçin.

Sorun: çok sayıda akışta 502, az sayıda her şey iyi

Neden: Mobil kanalın aşırı yüklenmesi.

Çözüm: Paralelliği kanal başına 3-5 akışa düşürün ve yükü birkaç kanala dağıtın.

Sorun: 504 yalnızca tek bir sitede, diğerleri hızlı

Neden: Site sayfayı yavaş üretiyor veya mobil operatör adreslerini kısıtlıyor.

Çözüm: Sitenin daha hafif adreslerini kullanın, tekrardan önce IP değiştirin, sorun kalıcıysa bu siteyle çalışmayı başka bir operatörün kanalına taşıyın.

Sorun: 504 yerine kodsuz kopma gelmeye başladı

Neden: Yazılımdaki bekleme limiti proxy'nin iç limitinden küçük.

Çözüm: Yazılımdaki limiti kodu almaya yetişeceğiniz değere, genellikle 30-60 saniyeye yükseltin.

Sorun: tunnel failed, response 400

Neden: SOCKS5 portu HTTP proxy olarak veya tersi belirtildi.

Çözüm: Tipi ve portu panelle karşılaştırın, SOCKS5 için socks5h şemasını, HTTP için http kullanın.

Sorun: standart dışı porta tunnel failed, response 403

Neden: Proxy bu porta tünellere izin vermiyor.

Çözüm: Sağlayıcıdan izin verilen portların listesini isteyin ve mümkünse hedef servisi 443 portuna yapılandırın.

Sorun: 502 veya 504 kodu sitenin Server başlığıyla birlikte geliyor

Neden: Bu, proxy katmanının değil sitenin kendisinin yanıtıdır: sitenin kendi iç servislerinde sorun var.

Çözüm: Bekleyin ve daha sonra tekrarlayın; proxy değiştirmek işe yaramaz.

İleri düzey kullanıcılar için ek imkanlar

Temel teşhisi öğrendiyseniz aşağıdaki teknikler proxy katmanı hatalarıyla çalışmayı neredeyse otomatik hale getirecektir.

Yetkilendirme başlığını elle aktarma

Bazen proxy'nin belirli bir başlığa nasıl tepki verdiğini kontrol etmek faydalıdır. kullanıcı:şifre çiftini herhangi bir yerel araçla Base64 olarak kodlayın ve başlığı kendiniz iletin: curl -v -x proxy.example.net:8080 -H "Proxy-Authorization: Basic dXNlcjE6cGFzczE=" http://example.com/. Bu yöntem normal HTTP istekleri için çalışır ve proxy'nin verileri yazılımınızın nasıl oluşturduğundan bağımsız olarak kabul edip etmediğini anlamaya yardımcı olur. CONNECT için -H yerine --proxy-header anahtarını kullanın.

Ad çözümlemesini proxy tarafında yapma

socks5h şeması ve HTTP tüneli alan adını yerel olarak çözümlemek yerine proxy sunucusuna iletir. Bu iki avantaj sağlar: site isteği tamamen mobil ağdan çıkıyormuş gibi görür ve yerel DNS'inizin bir adres, operatör ağının başka bir adres vermesi gibi tutarsızlıklardan kurtulursunuz. 502'yi yalnızca yerel çözümlemede görüyorsanız socks5h'e geçmek sıklıkla sağlayıcıya başvurmadan sorunu çözer.

Sağlayıcı API'si üzerinden otomasyon

mobileproxy.space'in IP değiştirme ve kanal durumu alma için programatik bir arayüzü vardır. IP değiştirme çağrısını 504 işleyicisine, kanal durumu kontrolünü kalıcı 502 işleyicisine yerleştirin. Böylece script isteği aynı kanaldan mı tekrarlayacağına yoksa yedek kanala mı geçeceğine kendisi karar verir. Basit bir algoritma: bir dakika içinde art arda üç 502 — durumu sorgula, kanal normalse IP'yi değiştir, değilse kanalı beş dakika erişilemez olarak işaretle ve bir sonrakine geç.

Proxy ve site metriklerini ayırma

İzleme sisteminizde iki ayrı metrik oluşturun: proxy başlıklarıyla gelen kodlar ve onlar olmadan gelen kodlar. İlk metrik proxy altyapınızın sağlığını, ikincisi hedef sitelerin davranışını anlatır. Bunlar karışık olduğu sürece proxy sunucu hatasını olmadığı yerde arayacak ve tersini yapacaksınız.

Ağırlıklı kanal havuzu

Her kanala, her 5xx'te düşen ve zamanla yavaşça toparlanan bir ağırlık atayın. İstekleri ağırlıklarla orantılı dağıtın. Bu yaklaşım yükü sorunlu operatör veya bölgeden otomatik olarak uzaklaştırır ve kanal toparlandığında tek bir elle geçiş yapmadan geri getirir.

Tarayıcıdan HAR dışa aktarma

Karmaşık durumlar için antidetect tarayıcıda Network sekmesini açın, hatayı yeniden üretin ve "Save all as HAR"ı seçin. Dosya, programın normal günlüğünde görünmeyen aşamalar dahil tüm istek ve yanıt başlıklarını içerir. Desteğe göndermeden önce dosyadan Proxy-Authorization değerlerini ve çerezleri silin.

Bekleme limitlerini optimize etme

Bir hafta boyunca her kanal ve yön için ilk bayta kadar geçen süre istatistiğini toplayın. Yazılımdaki bekleme limitini 95. yüzdelik dilim artı 10 saniye seviyesine ayarlayın. Böyle bir limit canlı istekleri nadiren keser ve aynı zamanda gerçek takılmalarda akışları hızla serbest bırakır.

SSS: teşhisle ilgili sık sorulan sorular

502'yi proxy'nin mi yoksa sitenin mi döndürdüğünü nasıl anlarım?

Yanıt başlıklarına bakın. Proxy-Agent, Via veya diğer proxy servis başlıkları varsa ve sitenin Set-Cookie ve Server başlıkları yoksa yanıt proxy'den. Ek olarak: kod doğrudan CONNECT yanıtında geldiyse kesinlikle proxy'dir.

407'de isteği tekrarlamaya değer mi?

Hayır. Kimlik bilgileri tekrarla doğru olmaz ve hatalı denemeler serisi proxy tarafında adresinizin geçici olarak bloke edilmesine yol açabilir. Verileri düzeltip bir kez tekrarlayın.

Neden curl'de her şey çalışıyor ama yazılımımda çalışmıyor?

Çoğu zaman yazılım proxy dizesini farklı oluşturur, şifredeki özel karakterleri kodlamaz, farklı bir protokol tipi uygular veya CONNECT'te yetkilendirmeyi iletmez. Yazılım ayarlarındaki tam dizeyi çalışan curl komutuyla karakter karakter karşılaştırın.

Özel karakterli şifre nasıl doğru yazılır?

Adres dizesinde kodlayın: @ yerine %40, : yerine %3A, # yerine %23, % yerine %25, boşluk yerine %20. Ayrı kullanıcı adı ve şifre alanlarında şifreyi olduğu gibi, kodlamadan girin.

504 ile diğer makalelerde yazılan zaman aşımı arasındaki fark nedir?

504, proxy'nin sitenin kendi bekleme limitini doldurup kendisinin döndürdüğü koddur. Kodsuz zaman aşımı, istemcinizin hiçbir şey almadan bağlantıyı kestiği anlamına gelir. Farklı şekilde tedavi edilirler, bu yüzden farklı yazılarda ele alındılar.

Tek bir mobil kanal üzerinden kaç akış geçirebilirim?

Evrensel bir sayı yok. 3-5 ile başlayın ve 502 oranı yüzde birin altında kalana kadar artırın. Ağır sayfalar için sayı daha az, hafif API istekleri için daha fazla olacaktır.

Her hatada IP değiştirmek gerekir mi?

504'te ve kalıcı 502'lerde evet, ilk eylem budur. 407'de hayır, IP değişimi yetkilendirmeyi etkilemez. Hata serisinin rotasyon çığına yol açmaması için minimum değişim aralığı girin.

Sorunu daha hızlı çözmek için desteğe ne göndermeliyim?

Şifresi yıldızlarla değiştirilmiş tam curl -v çıktısı, saat dilimiyle birlikte saniyeli tam zaman, kanalın host'u ve portu, hedef alan adı, yetkilendirme türü ve proxy olmadan doğrudan isteğin sonucu. Böyle bir setle destek genellikle ilk mesajda yanıt verir.

Proxy'nin kendisine bağlantı için HTTPS kullanabilir miyim?

Yalnızca sağlayıcı bunu açıkça destekliyorsa. Çoğu durumda mobil proxy'lerde proxy'ye bağlantı normal HTTP veya SOCKS5 ile yapılır ve siteye giden trafiğin şifrelemesini tünel sağlar. Proxy'ye gereksiz şifreleme açmak tunnel failed veya el sıkışma hatası verir.

Sonuç

Günlükteki anlaşılmaz kırmızı satırdan tam bir teşhis sistemine giden yolu kat ettiniz. Artık yanıtı tam olarak kimin döndürdüğünü belirleyebiliyor, 407'yi kimlik bilgilerini ve yetkilendirme yöntemini kontrol etme sinyali, 502'yi proxy'nin arkasında veya rotasyon anında bir arıza işareti, 504'ü proxy'nin yavaş bir site hakkındaki dürüst raporu ve tunnel failed'ı bu kodlardan birinin üzerine sarılmış, yanında sayı şeklinde ipucu taşıyan bir sarmalayıcı olarak okuyorsunuz. Yazılımınız artık anlamsız şeyleri tekrarlamıyor ve geçici durumda pes etmiyor.

Bundan sonra ne yapmalı

1. En az bir ay olay günlüğü tutun. İki hafta içinde tekrarlayan desenleri fark edip nedenlerini ortadan kaldıracaksınız.
2. Haftada bir kanallar bazında kod oranlarını gözden geçirin ve yükü yeniden dağıtın.
3. Rutin 5xx'lerin sizsiz çözülmesi için sağlayıcı API'si üzerinden IP değişimini ve durum kontrolünü otomatikleştirin.
4. İstek yolunun kalan iki bölümünü de kapatmak için blogdaki ağ zaman aşımları ve hedef sitelerin davranışı hakkındaki ilgili yazıları inceleyin.

Nereye ilerlemeli

Bir sonraki seviye, ağırlıklı ve izlemeli kendi kanal havuzunuzu kurmaktır; burada proxy sunucu hatası panik nedeni değil, sistemin kendisinin işlediği grafikteki bir noktadır. Bunun için gerekli tüm araçlara zaten sahipsiniz: kodları anlama, curl, sağlayıcı paneli ve kaydetme alışkanlığı. Kolay gelsin ve istikrarlı 200'ler.