Makale içeriği

Proxy hataları ansızın ortaya çıkıp insanı korkutur. Az önce çalışan istek, birden karşınıza anlaşılmaz bir 407, 502 ya da tunnel connection failed mesajı çıkarır. İyi haber şu: bu hataların her birinin arkasında mantıklı ve anlaşılır bir neden vardır. Bu rehber, bu mesajları açık bir kitap gibi okumanızı sağlayacak.

Giriş: Bu rehber size ne kazandıracak

Proxy ile çalışmak, tercüman üzerinden telefon görüşmesi yapmaya benzer. İstemciniz proxy ile konuşur, proxy hedef siteyle konuşur ve yanıt aynı zincir üzerinden geri gelir. Bir şey bozulduğunda, sorunun tam olarak hangi halkada çıktığını anlamak kritik önem taşır. Bu rehber tam da bunu amaçlıyor.

Sonunda ne elde edeceksiniz:

  • Proxy hatasını hedef site hatasından anında ayırt etme becerisi.
  • 407, 502, 504, 403 kodlarının ve tunnel connection failed mesajının ne anlama geldiğini kavrama.
  • curl -v çıktısını istemci-proxy-sunucu bölümlerine net biçimde ayırarak satır satır okuma yetisi.
  • curl, Python requests ve Node.js ile gerçek hata metinleri üzerinden hazır teşhis örnekleri.
  • Yazdırıp elinizin altında tutabileceğiniz belirti-neden-kontrol hızlı teşhis tablosu.

Bu rehber kimler için. Proxy ile yeni çalışmaya başlayanlar için yazıldı, ancak deneyimli geliştiriciler ve otomasyon uzmanları için de ileri düzey ayrıntılar içeriyor. İster parser kuruyor olun, ister multi-accounting ile uğraşıyor olun, ister sadece scriptinizin neden birden veri alamaz olduğunu merak ediyor olun, bu materyal tam size göre.

Önceden bilmeniz gerekenler. URL, port ve HTTP isteğinin ne olduğuna dair temel bir anlayış yeterli. Derin ağ bilgisine gerek yok. Tüm terimleri yol boyunca sade bir dille açıklayacağız.

Ne kadar zaman gerekir. İlk okuma yaklaşık 30-40 dakika sürer. Örnekleri kendi projenizde uygulamak 20-30 dakika daha alır. Sonrasında tipik bir hatayı teşhis etmeniz bir-iki dakikaya inecek.

Konuya dair önemli bir not. Bu rehberde yalnızca proxy katmanının kendi hatalarını ele alıyoruz. 429 kodu (çok fazla istek) ve yeniden deneme stratejileri burada yer almıyor, çünkü bunlar kendi mantığı ve yaklaşımı olan ayrı ve geniş bir konu. 429 için retry ve limitler üzerine ayrı bir materyal gerekiyor. Biz burada yalnızca proxy bağlantı hatalarının teşhisine odaklanıyoruz.

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

Teşhise başlamadan önce bir araç seti toplayalım. Hepsi ücretsiz ve her işletim sisteminde çalışıyor.

Gerekli araçlar

  1. curl'ü kurun. Çoğu Linux ve macOS sisteminde zaten vardır. curl --version komutuyla kontrol edin. Sürüm numarası görüyorsanız hazırsınız.
  2. Windows'ta curl modern sürümlerle birlikte sistemde geliyor. PowerShell açıp aynı kontrol komutunu yazın.
  3. requests örnekleri planlıyorsanız Python 3.10 veya üstünü kurun. python --version komutuyla kontrol edin.
  4. Terminalde pip install requests komutuyla requests kütüphanesini kurun.
  5. JavaScript örnekleri için Node.js 20 veya üstünü kurun. node --version komutuyla kontrol edin.

Hazırlamanız gerekenler

  • Proxy bilgileriniz: ana makine adresi, port, gerekliyse kullanıcı adı ve parola.
  • Test edeceğiniz hedef adres. Kontroller için, isteğe dair bilgi dönen basit bir site kullanmak pratik olur.
  • Logları ve teşhis notlarını kaydetmek için bir metin düzenleyici.

İpucu: diagnostic-notes adında ayrı bir metin dosyası oluşturun. Her komutu ve sonucunu oraya yazın. Yarım saat sonra neyi kontrol ettiğinizi unuttuğunuzda bu sizi kurtarır.

⚠️ Dikkat: Proxy kullanıcı adı ve parolanızı asla ortak sohbetlerde, herkese açık depolarda veya ekran görüntülerinde saklamayın. Bu verilerin sızması, başkalarına trafiğinize erişim sağlar. Bunları güvenli bir parola yöneticisinde tutun.

✅ Kontrol: Bu aşamada üç sürüm komutu da başarıyla çalışıyor olmalı: curl, python ve node. En az biri çalışmıyorsa ilgili aracın kurulumuna geri dönün.

Temel kavramlar sade bir dille

Teşhisin bilinçli olması için birkaç kilit terimi ele alalım. Terimler tanıdık görünse bile bu bölümü atlamayın.

Proxy aslında nedir

Proxy, programınız ile hedef site arasında bir aracıdır. İsteğiniz önce proxy'ye ulaşır, proxy onu ileriye iletir. Yanıt aynı yoldan geri döner. Bu aracılık yüzünden herhangi bir hata üç yerde çıkabilir: istemcinizde, proxy'nin kendisinde veya hedef sitede.

Ana ayrım: istemci, proxy, sunucu

Zincirin üç halkasını aklınızda tutun. Birinci halka, isteği gönderen program yani istemciniz. İkinci halka, aracı yani proxy. Üçüncü halka, gitmek istediğiniz site yani hedef sunucu. Tüm teşhis şu soruya indirgenir: bu üç halkadan hangisinde sorun çıktı?

İki kelimeyle HTTP kodları

Siteler ve proxy'ler sayısal kodlarla yanıt verir. 4 ile başlayan kodlar (örneğin 407, 403) genellikle istek veya erişim tarafında bir sorun olduğunu gösterir. 5 ile başlayan kodlar (502, 504) sunucu veya aracı tarafında bir sorun olduğunu gösterir. Ancak burada sinsi bir incelik var: 502 kodunu hem hedef site hem de proxy'nin kendisi gönderebilir. Bunları ayırt etmeyi öğrenmek, rehberin ana hedeflerinden biridir.

Proxy üzerinden HTTP ile HTTPS arasındaki fark

Normal bir HTTP sitesine giderken proxy tüm isteği olduğu gibi görür. Güvenli bir HTTPS sitesine giderken proxy içeriği okuyamaz. Bunun yerine istemci, proxy'den CONNECT adlı özel bir komutla güvenli bir tünel kurmasını ister. İşte bu yüzden tunnel connection failed hatası yalnızca HTTPS'te görülür. Bunu ayrıca ayrıntılı olarak ele alacağız.

İpucu: Aklınızda basit bir resim tutun. İstemci proxy'yi çalar. Proxy içeri alıp almayacağına karar verir. Sonra proxy siteyi çalar. Site yanıt verip vermeyeceğine karar verir. Hata, başarısız olan çalmada ortaya çıkar.

Adım 1: Proxy hatasını hedef site hatasından nasıl ayırt edersiniz

Bu aşamanın amacı: Birkaç saniye içinde suçlunun proxy mi yoksa site mi olduğunu anlamayı öğrenmek. Bu, her teşhisin başladığı temel beceridir.

Ayrımın ana ilkesi

Kilit soru şudur: isteğiniz hedef siteye ulaştı mı, yoksa proxy'de mi takıldı? İstek proxy'de takıldıysa suçlu proxy katmanıdır. İstek siteye ulaşıp site yanıt verdiyse sorun site tarafındadır.

  1. Hata koduna ve mesaj metnine bakın.
  2. Bu yanıtı kimin gönderdiğini belirleyin: proxy mi sunucu mu. Yanıt başlığı ve içeriği bunu anlatır.
  3. Hata metninde doğrudan proxy, tunnel kelimeleri ya da proxy programının adı geçiyorsa neredeyse kesin olarak proxy katmanı suçludur.
  4. Yanıt, hedef sitenin logosu ve tasarımıyla birlikte tanıdık bir HTML sayfası içeriyorsa istek siteye ulaşmış demektir.

Proxy hatasının üç hızlı işareti

  • 407 kodu. Bu kod yalnızca proxy'lerde bulunur. Hedef site asla göndermez. 407 gördüyseniz kesinlikle proxy katmanındasınız.
  • tunnel connection failed ya da proxy'den HTTP kodu alındı metni. Bu tür ifadeleri tam olarak aracı üretir.
  • Anında bağlantı reddi. İstek, siteye ulaşması mümkün olmadan neredeyse anında düşüyorsa sorun büyük olasılıkla istemci ile proxy arasındadır.

İpucu: Bir kontrol deneyi yapın. Aynı isteği doğrudan proxy olmadan gönderin. Doğrudan çalışıyor ama proxy üzerinden çalışmıyorsa sorun proxy katmanında ya da onun siteyle etkileşimindedir. Bu, bir dakikada hipotezlerin yarısını eler.

Hızlı kontrol için curl örneği

Ayrıntılı çıktı bayrağıyla proxy üzerinden bir istek yapın. Komut şöyle görünür: curl -v -x http://kullanıcı:parola@host:port https://ornek-site. -v bayrağı tüm diyaloğu gösterir. -x bayrağı proxy'yi belirtir. Ok ve yıldız işaretleriyle başlayan satırlara bakın. Bunları ayrı bir log okuma adımında ayrıntılı ele alacağız.

⚠️ Dikkat: Kararsız bir siteye yapılan tek bir isteğe dayanarak sonuç çıkarmayın. İsteği iki-üç kez tekrarlayın. Tek seferlik bir ağ aksaklığı, proxy hatası gibi görünebilir; oysa proxy'nin bunda hiçbir suçu yoktur.

✅ Kontrol: Herhangi bir hata mesajı için şu soruyu yanıtlayabilmelisiniz: bunu proxy mi yoksa site mi gönderdi? Yapabiliyorsanız devam edin. Hâlâ emin değilseniz yukarıdaki üç hızlı işarete dönün.

Adım 2: 407 Proxy Authentication Required hatası

Bu aşamanın amacı: Proxy'de en sık görülen yetkilendirme hatasını düzeltmeyi ve bunun benzer kod 401'den farkını anlamayı öğrenmek.

407 ne anlama gelir ve 401'den farkı nedir

407 kodu kısaca şunu söyler: proxy, kendinizi kullanıcı adı ve parolayla tanıtmanızı istiyor, ancak bunu ya yapmadınız ya da yanlış yaptınız. 401'den kilit farkı şudur: 401 kodunu, yetkilendirmeyi kendisi istediğinde hedef site gönderir. 407 kodunu ise tam olarak proxy gönderir. 407 görüyorsanız siteye bile ulaşmamışsınız demektir; sizi girişte aracı durdurmuştur.

Kullanıcı adı ve parola tam olarak nerede kaybolur

Çoğu zaman veriler üç yerde kaybolur.

  1. Kullanıcı adı ve parola komutta hiç iletilmemiştir. İstemci proxy'yi anonim olarak çalmış, proxy de onu geri çevirmiştir.
  2. Veriler iletilmiştir ama yazım hatası vardır. Tek bir fazla boşluk ya da yanlış klavye düzeni yetkilendirmeyi bozar.
  3. Veriler doğru iletilmiştir ama parola, bağlantı dizesinin yapısını bozan özel karakterler içerir. En sinsi neden budur.

Paroladaki özel karakterler ve URL kodlaması

Proxy bağlantı dizesi şöyle görünür: kullanıcıadi iki nokta parola et işareti host iki nokta port. Sorun şu ki iki nokta, et işareti, eğik çizgi ve diğer karakterlerin bu dize içinde özel anlamları vardır. Parolanız örneğin et işareti ya da iki nokta içeriyorsa program bunu yanlış anlar ve dizeyi olması gereken yerde bölmez.

Çözüme URL kodlaması denir. Özel karakterler yüzde işareti ile iki rakam ya da harften oluşan bir kodla değiştirilir. Örneğin et işareti yüzde kırk olur, iki nokta yüzde üç A olur, eğik çizgi yüzde iki F olur, boşluk yüzde yirmi olur.

  1. Parolanızdaki tüm özel karakterleri bulun.
  2. Her birini URL kodunun karşılığıyla değiştirin.
  3. Bağlantı dizesini kodlanmış parolayla yeniden kurun.
  4. İsteği tekrarlayın.

İpucu: Parolanız karmaşıksa elle kodlamayın. Python'da urllib.parse modülünde quote adlı bir fonksiyon var. Parolayı ona verin, güvenli sürümünü döndürsün. Bu, elle yazma hatalarını ortadan kaldırır.

curl örneği

Yanlış yetkilendirmede gerçek hata metni şöyle görünür: curl (56) Received HTTP code 407 from proxy after CONNECT. Ya da HTTP sitesinde: HTTP 407 Proxy Authentication Required. Yetkilendirmeli doğru komut: curl -v --proxy-user kullanıcı:parola -x http://host:port https://ornek-site. --proxy-user bayrağını kullanmak, verileri doğrudan adrese yazmaktan genellikle daha güvenlidir, çünkü curl karakterleri kendisi doğru biçimde işler.

Python requests örneği

requests'te proxy bir sözlükle verilir. Anahtarlar http ve https, değerler bağlantı dizeleridir. Parola özel karakter içeriyorsa onu quote fonksiyonuna sarın. Yanıt nesnesindeki tipik hata: response.status_code 407 döner ve metinde Proxy Authentication Required geçer. Yalnızca metne değil, status koduna da bakın.

Node.js örneği

Node'da popüler proxy istemcileriyle proxy özel bir agent üzerinden verilir. Gerçek hata, statusCode alanı 407 olan bir nesne ya da tünel yetkilendirme hatasına dair mesaj içeren reddedilmiş bir promise olarak görünür. Proxy yetkilendirme başlığını gönderdiğinizden emin olun, site yetkilendirme başlığını değil; bunlar farklı şeylerdir.

⚠️ Dikkat: Proxy için yetkilendirme başlığı ile site için yetkilendirme başlığı iki ayrı başlıktır. Biri Proxy-Authorization, diğeri Authorization olarak adlandırılır. Karıştırırsanız ya proxy'den 407 ya da siteden 401 alırsınız. Kütüphanenizin tam olarak hangi başlığı gönderdiğini kontrol edin.

✅ Kontrol: Yetkilendirmeyi düzelttikten sonra yanıt kodu 407'den başka bir koda dönmelidir. Site kendi hatasını döndürse bile bu bir ilerlemedir: proxy'yi geçip siteye ulaştınız.

Adım 3: Proxy'den gelen 502 hatası

Bu aşamanın amacı: 502'nin ne zaman hedef site, ne zaman proxy kanalının kendi sorunu olduğunu anlamayı öğrenmek.

502 ne anlama gelir

502 koduna Bad Gateway, yani kötü geçit denir. Aracının bir sonraki halkaya ulaşmaya çalıştığını ama belirsiz ya da kopmuş bir yanıt aldığını söyler. Sorun şu ki 502 iki tamamen farklı durumda gelebilir ve dışarıdan benzer görünürler.

Hedef ana makinenin suçlu olduğu durum

İlk durum: proxy hedef siteyle başarıyla bağlantı kurmuştur, ancak site çöp veri döndürmüş, bağlantıyı koparmış ya da kendi backend'inden yanıt alamamıştır. Bu durumda proxy, size 502'yi dürüstçe şu şekilde iletir: siteye ulaştım ama site kötü yanıt verdi.

  1. Aynı isteği doğrudan proxy olmadan yapın.
  2. Doğrudan da site 502 veriyor ya da takılıyorsa suçlu sitedir, proxy değildir.
  3. Bu durumda proxy değiştirmenin faydası yoktur. Sorun hedef tarafındadır.

Kanalın kendisinin suçlu olduğu durum

İkinci durum: proxy'nin kendisi kararsızdır, üst kanalı kopmuştur ya da proxy siteyle düzgün bağlantı bile kuramamıştır. O zaman 502, hasta aracının işaretidir.

  1. Aynı proxy üzerinden kesinlikle kararlı bir siteye istek yapın.
  2. Kararlı site de 502 döndürüyorsa sorun proxy kanalındadır.
  3. Varsa başka bir proxy ya da başka bir düğüm deneyin.

İpucu: Çapraz kontrol yöntemi kusursuz çalışır. Her seferinde tek bir değişkeni değiştirin. Önce proxy'yi sabit tutup siteyi değiştirin. Sonra siteyi sabit tutup proxy'yi değiştirin. Sonuçların kesişimi size suçluyu gösterecektir.

Gerçek hata metinleri

curl'de 502 kodlu bir HTTP yanıtı ve sıklıkla Bad Gateway yazan bir HTML sayfası görürsünüz. Bazen yanıt başlıklarında hangi sunucunun yanıt verdiğine dair bir iz bulunur. Python requests'te bu, 502'ye eşit olan response.status_code'dur. Node'da 502'ye eşit olan statusCode alanıdır. Yanıt gövdesine dikkat edin: hedef sitenin tasarımlı sayfası isteğin siteye ulaştığını, kısa ve teknik bir sayfa ise genellikle proxy'den geldiğini gösterir.

⚠️ Dikkat: İlk 502'de proxy'yi suçlamaya acele etmeyin. Hedef siteler, özellikle yük altında 502'yi çok sık döndürür. Proxy ayarlarını değiştirmeden önce her zaman doğrudan bir kontrol isteği yapın.

✅ Kontrol: İki çapraz isteğin sonucuna göre bu 502'nin siteden mi proxy'den mi geldiğini kesin olarak söyleyebilmelisiniz. Henüz yapamıyorsanız iki kontrol isteğini de tekrarlayın ve sonuçları karşılaştırın.

Adım 4: 504 hatası ve zaman aşımları

Bu aşamanın amacı: İki temelde farklı zaman aşımı türünü ayırt etmeyi ve istemcide doğru yapılandırmayı öğrenmek.

504 ne anlama gelir

504 koduna Gateway Timeout, yani geçit beklemede kaldı denir. Aracının bir sonraki halkadan yanıt beklerken çok uzun süre beklediğini ve pes ettiğini söyler. Ancak zamanın tam olarak nerede takıldığını anlamak için iki zaman aşımı türünü ayırmak gerekir.

Connect timeout ile read timeout karşılaştırması

İki tamamen farklı bekleme anı vardır.

  • Connect timeout — bağlantının kurulması için geçen süre. İstemci proxy'ye ya da proxy siteye erişmeye çalışır. Bağlantı ayrılan sürede kurulamazsa connect timeout devreye girer. Bu genellikle adresin erişilemez ya da portun kapalı olduğunun işaretidir.
  • Read timeout — bağlantı kurulduktan sonra yanıt bekleme süresi. Bağlantı var, istek gitti ama veri gelmiyor. Bu genellikle sitenin uzun süre düşündüğünün ya da işlemde takıldığının işaretidir.

İstemcide bunları nasıl ayırırsınız

Doğru teşhis, bu iki zaman aşımını ayrı ayrı yapılandırmakla başlar. Böylece zamanın hangi aşamada takıldığını hemen anlarsınız.

  1. curl'de bağlantı kurma süresini sınırlamak için --connect-timeout bayrağını kullanın. Tüm işlemin toplam süresini sınırlamak için ayrıca --max-time bayrağını kullanın.
  2. Python requests'te timeout parametresi iki sayıdan oluşan bir demet olarak verilebilir. İlk sayı connect timeout, ikincisi read timeout'tur. Örneğin beş ve otuz saniyelik bir timeout gibi.
  3. Node'da çoğu istemcide bağlantı süresi ve yanıt bekleme süresi için ayrı ayarlar vardır. Hangi türün devreye girdiğini görmek için bunları farklı değerlerle ayarlayın.

Sonucu nasıl okursunuz

Connect timeout devreye girdiyse bağlantıyı bile kuramadınız demektir. Proxy'nin erişilebilirliğini ve portun doğruluğunu kontrol edin. Read timeout devreye girdiyse bağlantı vardı ama yanıt zamanında gelmedi demektir. Sitenin aşırı yüklü olup olmadığını ve çok ağır bir istek yapıp yapmadığınızı kontrol edin.

İpucu: Connect timeout'u küçük, yaklaşık beş saniye tutun. Bağlantı ya hızlı kurulur ya hiç kurulmaz. Read timeout'u ise bol bırakın, çünkü bazı sayfalar yanıtı dürüstçe daha uzun süre hazırlar.

⚠️ Dikkat: Fazla küçük bir read timeout yanlış hatalara yol açar. Normal ama yavaş yanıtları keser ve proxy'yi bozuk sanırsınız. Her zaman limiti kendinizin fazla katı koyup koymadığını kontrol edin.

Gerçek hata metinleri

curl'de connect timeout, stderr ardından Connection timed out mesajı olarak görünür. Python requests'te bağlantı için ConnectTimeout, yanıt için ReadTimeout istisnasıdır. İstisnanın adı, hangi aşamanın çöktüğünü size hemen söyler. Node'da ETIMEDOUT kodlu bir hata ya da yanıt süresinin aşıldığına dair ayrı bir mesaj görürsünüz.

✅ Kontrol: Ayrı zaman aşımlarını ayarladıktan sonra hatada net bir belirti almalısınız: bu bağlantı zaman aşımı mı yoksa okuma zaman aşımı mı. Yalnızca sınırlama olmadan genel timeout kelimesini görüyorsanız zaman aşımları henüz ayrılmamış demektir.

Adım 5: tunnel connection failed hatası ve CONNECT yöntemi

Bu aşamanın amacı: Bu hatanın neden yalnızca güvenli sitelerde çıktığını anlamak ve nasıl teşhis edileceğini öğrenmek.

Hata neden yalnızca HTTPS'te gelir

Normal bir HTTP sitesine giderken proxy isteğinizi basitçe iletir. Ancak bir HTTPS sitesine giderken içerik şifrelidir ve proxy onu okuyamaz. Bu yüzden istemci önce proxy'ye site adresiyle birlikte CONNECT adlı özel bir komut gönderir. Bu komut şu ricayı ifade eder: lütfen bana bu adrese güvenli bir tünel kur, ben de senin üzerinden siteyle doğrudan konuşayım.

Proxy herhangi bir nedenle tüneli kuramazsa tunnel connection failed hatasını döndürür. Normal HTTP'de böyle bir komut yoktur, dolayısıyla bu hata HTTP'de görülmez. Bu, sizin başlıca tanı işaretinizdir.

Tünelin çökmesinin başlıca nedenleri

  • Proxy hedef adrese bağlanamadı. Belki site erişilemez ya da port kapalı.
  • Proxy bu adrese veya porta CONNECT yöntemini yasaklıyor. Bazı proxy'ler yalnızca belirli portlara izin verir.
  • Yetkilendirme geçmedi. Bu durumda genellikle şu kombinasyonu görürsünüz: önce bir CONNECT denemesi, ardından 407 kodu.
  • Proxy aşırı yüklü ya da üst kanalı tünel kurulduğu anda koptu.

Nasıl teşhis edilir

  1. Bir HTTPS adresine curl -v yapın ve çıktıda CONNECT satırını bulun. Tünel isteğinin anını gösterir.
  2. CONNECT'e hangi yanıtın geldiğine bakın. 200 kodlu yanıt tünelin kurulduğu anlamına gelir. Başka herhangi bir kod çökme anlamına gelir.
  3. Yakında 407 görüyorsanız sorun tünelin kendisinde değil yetkilendirmededir. 407 adımına geri dönün.
  4. Bağlantı reddi görüyorsanız proxy siteye ulaşamamış demektir.

İpucu: Tam olarak izin verilen porta gittiğinizden emin olun. Güvenli bağlantılar için klasik portlar genellikle izinlidir, ancak standart dışı portları çoğu proxy bloklar. Portun standart porta çevrilmesi sorunu sık sık anında çözer.

Gerçek hata metinleri

curl'de bu, curl (56) Received HTTP code from proxy after CONNECT biçiminde ya da doğrudan tunnel connection failed olarak görünür. Python requests'te bu, başarısız tünele dair iç içe mesaj içeren ProxyError istisnasıdır. Node'da tünel bağlantısının kurulamadığına dair, sıklıkla proxy'den gelen durum kodunu belirten bir hata metnidir.

⚠️ Dikkat: Tünel çökmesini sertifika hatasıyla karıştırmayın. Tünel kurulup ardından sitenin güvenli sertifikasına itiraz ediliyorsa bu başka bir sorundur ve proxy katmanıyla doğrudan ilgili değildir. Hataya tam olarak hangi aşamada ortaya çıktığına bakın: CONNECT yanıtından önce mi sonra mı.

✅ Kontrol: curl çıktısında CONNECT yanıtını içeren satırı bulabilmeli ve koduna göre tünelin kurulup kurulmadığını anlayabilmelisiniz. 200 yanıtı tünel var demektir. Başka kodda çökme nedenini arayın.

Adım 6: Proxy'den gelen 403 hatası

Bu aşamanın amacı: 403'ü proxy'nin limitler, coğrafya ya da yasak port nedeniyle gönderdiği durumu tanımayı öğrenmek.

Proxy bağlamında 403 ne anlama gelir

403 koduna Forbidden, yani yasak denir. Bu kodu genellikle erişimi kapattığında hedef site gönderir. Ancak proxy de isteğinizi geçirmemeye karar verdiğinde 403 gönderebilir. Görev, yasağı tam olarak kimin koyduğunu anlamaktır.

Proxy'den gelen 403'ün üç nedeni

  • Limitler. Proxy istek sayısını, trafik hacmini ya da eşzamanlı bağlantı sayısını sınırlayabilir. Aşıldığında hizmet vermeyi reddetmek için 403 döndürür.
  • Coğrafi kısıtlama. Bazı proxy'ler yalnızca belirli bölgelere erişime izin verir ya da belirli yönleri yasaklar. Kapalı bir yöne yapılan istek 403 alır.
  • Yasak port. Proxy yalnızca standart portlara izin verebilir. Standart dışı bir porta yapılan istek reddedilir.

Proxy 403'ünü site 403'ünden nasıl ayırt edersiniz

  1. Yanıt gövdesine bakın. Hedef sitenin tasarımıyla oluşturulmuş sayfası, yasağı sitenin koyduğu anlamına gelir.
  2. Kısa ve teknik bir sayfa ya da metinde proxy'nin anılması, yasağı aracının koyduğu anlamına gelir.
  3. Aynı isteği doğrudan yapın. Doğrudan da site 403 veriyor ve proxy üzerinden de veriyorsa suçlu sitedir.
  4. Doğrudan site açılıyor ama proxy üzerinden 403 dönüyorsa nedeni proxy'nin limitlerinde ya da kısıtlamalarında arayın.

İpucu: Proxy'nizin dokümantasyonunu ya da kontrol panelini limitler açısından kontrol edin. Çoğu zaman kişisel panelde trafik tükenmiş mi ya da istek limitine ulaşılmış mı görünür. Bu, nedeni doğrulamanın en hızlı yoludur.

⚠️ Dikkat: Proxy limitlerini kurnaz yöntemlerle aşmaya çalışmayın. Tarife sınırına takıldıysanız doğru çözüm tarifeyi genişletmek ya da istek sayısını optimize etmektir. Hizmetin teknik kısıtlamalarını aşmak, kullanım koşullarını ihlal eder.

Gerçek hata metinleri

curl'de bu, kaynağı size fısıldayan bir gövdeyle 403 Forbidden HTTP yanıtıdır. Python requests'te bu, 403'e eşit olan response.status_code'dur. Node'da 403'e eşit olan statusCode'dur. Her zaman yanıt gövdesini kodla birlikte inceleyin, çünkü yasağın gerçek sahibini tam olarak gövde açıklar.

✅ Kontrol: Yanıt gövdesine ve doğrudan istek sonucuna göre 403'ü kimin gönderdiğini belirleyebilmelisiniz. Bu proxy ise limitleri, coğrafyayı ve portu kontrol edin. Site ise neden proxy katmanında değildir.

Adım 7: Yanıtsız bağlantı kopması — connection reset ve EOF

Bu aşamanın amacı: Hiç yanıt gelmeyip bağlantının basitçe koptuğu en gizemli durumları teşhis etmeyi öğrenmek.

Bu hatalar nedir

Bazen hiçbir HTTP kodu almazsınız. Bunun yerine bağlantı aniden kopar. İki tipik belirti vardır.

  • Connection reset. Kelime anlamıyla — bağlantı sıfırlandı. Taraflardan biri, alışverişi tamamlamadan kanalı keskin biçimde kapatmıştır. Sanki karşı taraf cümlenin ortasında telefonu kapatmış gibidir.
  • EOF, unexpected end of file. Kelime anlamıyla — beklenmeyen veri sonu. İstemci yanıtın devamını beklerken veri akışı aniden bitmiştir.

Öncelikle neye bakmalı

  1. Kopma anını belirleyin. CONNECT yanıtından önce mi, istek gönderilirken mi yoksa yanıt alınırken mi oldu? curl -v çıktısı kopmadan önceki son başarılı satırı gösterir.
  2. Kopma en başta, proxy'ye bağlanırken olduysa sorun büyük olasılıkla proxy'nin kendisinde ya da ona giden ağ yolundadır.
  3. Kopma tünel kurulduktan sonra, siteyle konuşurken olduysa sorun büyük olasılıkla site tarafında ya da kararsız kanaldadır.
  4. İsteği birkaç kez tekrarlayın. Sürekli tekrarlayan kopma sistematik bir nedeni, rastgele olan ise geçici ağ kararsızlığını gösterir.

Yaygın nedenler

  • Proxy aşırı yüklü ve fazla bağlantıları zorla kapatıyor.
  • Proxy'nin üst kanalı kararsız ve kopuyor.
  • Hedef site kendi kısıtlamaları nedeniyle bağlantıyı kapatıyor.
  • Zincirdeki halkalar arasında ağ sorunları.

İpucu: Rastgele kopmalarda istatistik tutun. Örneğin üst üste yirmi istek yapın ve kaçının koptuğunu sayın. Yirmide bir kopuyorsa bu tolere edilebilir bir kararsızlıktır. Yarısı kopuyorsa çözülmesi gereken sistematik bir sorun var demektir.

Gerçek hata metinleri

curl'de bu Connection reset by peer ya da Empty reply from server olarak görünür. Python requests'te bu, bağlantı sıfırlamasına dair iç içe mesaj içeren ConnectionError istisnasıdır. Node'da ECONNRESET kodlu bir hatadır. Bu mesajlarda HTTP kodu bulunmamasının nedeni tam olarak HTTP alışverişinin normal biçimde tamamlanmamış olmasıdır.

⚠️ Dikkat: Yanıtsız kopmayı zaman aşımıyla karıştırmak kolaydır. Fark şu: zaman aşımında istemci beklemeyi kendisi sonlandırır, sıfırlamada ise karşı taraf kanalı etkin biçimde kapatır. Hata metnine bakın: reset kelimesi etkin sıfırlamayı, timeout kelimesi beklemenin sona ermesini gösterir.

✅ Kontrol: curl çıktısının son satırına göre bağlantının hangi aşamada koptuğunu belirleyebilmelisiniz. Bu, şüphelilerin çemberini hemen bir-iki halkaya indirir.

Adım 8: Pratik — curl -v çıktısını satır satır okuma

Bu aşamanın amacı: curl çıktısında istemci, proxy ve sunucu arasındaki sınırı görmeyi öğrenmek. Bu, tüm rehberin zirvesi.

Satır başlarındaki semboller ne anlama gelir

curl -v çıktısı her satırın başında özel semboller kullanır ve bu, anlamanın anahtarıdır.

  • Satır başındaki yıldız işareti, curl'ün kendi bilgilendirme mesajını gösterir. İstemcinin ne yaptığına dair yorumlardır: bağlantı kuruyor, tünel kuruyor, sertifikayı doğruluyor.
  • Sağa ok, istemcinin proxy'ye ya da sunucuya gönderdiği veriyi gösterir. Bu giden istektir.
  • Sola ok, istemcinin yanıt olarak aldığı veriyi gösterir. Bu gelen yanıttır.

İstemci-proxy-sunucu sınırı nerededir

Proxy üzerinden güvenli bir siteye giden tipik yolu ele alalım. Önce curl, yıldız işaretiyle proxy'ye belirtilen adres ve porttan bağlandığını bildirir. Bu istemci-proxy kesimidir. Ardından CONNECT komutunu içeren giden bir ok gelir — istemci proxy'den tünel kurmasını ister. Sonra CONNECT yanıtını içeren gelen bir ok gelir — bu proxy'nin yanıtıdır. Kod 200 ise tünel kurulmuştur ve sınır yer değiştirir: bundan sonra tüm alışveriş tünel üzerinden istemci-sunucu arasında gerçekleşir.

Gerçek bir log incelemesi

Şöyle bir dizilim gördüğünüzü varsayalım. Yıldız işaretli bir satır: proxy'nin adresi ve portuna bağlanıyorum. Bu, istemcinin proxy'yi bulduğu anlamına gelir. Sonraki yıldız işaretli satır: proxy'ye bağlantı kuruldu. Harika, ilk kesim geçildi. Ardından giden bir ok: hedef site adresine CONNECT. İstemci tünel istedi. Sonra gelen bir ok: kodu içeren CONNECT yanıtı. Burada kilit yol ayrımı başlar.

  1. CONNECT'e yanıt kodu 200 ise tünel kurulmuştur. Okumaya devam edin.
  2. Kod 407 ise proxy yetkilendirme ister. Sorun proxy katmanında, istemci-proxy kesiminde. 407 adımına gidin.
  3. Satır tunnel connection failed diyorsa proxy tüneli kuramamıştır. Neden proxy ile site arasındadır.

Tünelin kurulduğunu varsayalım. Ardından siteyle güvenli bağlantının doğrulandığına dair yıldız işaretleri gelir. Bu artık istemci-sunucu kesimidir. Sonra gerçek isteği içeren giden bir ok gelir: istek satırı ve başlıklar. Dikkat edin: bu ana kadar site isteğinizi hiç görmemiştir; tünelin kurulmasıyla meşguldü. Ve son olarak site yanıtının kodunu içeren gelen bir ok gelir. İşte hedef sitenin sorumluluk alanı burada başlar.

Bunu teşhis için nasıl kullanırsınız

  1. Proxy ile bağlantı kurma satırını bulun. Yoksa ya da hatalıysa sorun istemci ile proxy arasındadır.
  2. CONNECT yanıtını bulun. Koduna göre proxy katmanının geçilip geçilmediğini belirleyin.
  3. Site yanıtını içeren gelen oku bulun. Varsa siteye ulaşmışsınız demektir ve buradaki her hata artık site alanıdır.
  4. Kopmadan önceki son satır, her zaman her şeyin hangi kesimde bozulduğunu fısıldar.

İpucu: Çıktıyı isteğin yolculuğunun güncesi gibi yukarıdan aşağıya okuyun. Her satır yolun bir adımıdır. Hata ya da kopma satırına geldiğiniz anda bir önceki başarılı satıra bakın. O, son canlı halkayı gösterecektir.

⚠️ Dikkat: -v bayrağı, proxy yetkilendirme satırı dahil başlıkları gösterir. Logu yardım için birine gönderecekseniz yetkilendirme verilerini içeren satırı mutlaka karalayın. Aksi halde kullanıcı adı ve parolanızı açık etmiş olursunuz.

✅ Kontrol: Kendi curl -v logunuzu alın ve işaretleyin: nerede istemci-proxy kesimi, nerede CONNECT yanıtı, nerede site alanı başlıyor. Bu sınırları kendinden emin biçimde çizebiliyorsanız teşhisin ana becerisini öğrenmişsiniz demektir.

Adım 9: Belirti-neden-kontrol hızlı teşhis tablosu

Bu aşamanın amacı: Herhangi bir hata anında başvurabileceğiniz hazır bir referans elde etmek.

Tabloyu nasıl kullanırsınız

Belirtinizi ilk sütunda bulun. Olası nedeni okuyun. İlk olarak üçüncü sütundaki eylemi gerçekleştirin — bu, nedeni en yüksek olasılıkla doğrular ya da çürütür.

Belirti: 407 kodu

Olası neden: proxy yetkilendirme verileri iletilmemiş ya da yanlış, veya paroladaki özel karakterler bağlantı dizesini bozmuş. İlk kontrol edilecek: kullanıcı adı ve parolanın doğruluğu ile paroladaki özel karakterlerin URL kodlaması.

Belirti: HTTPS'te tunnel connection failed

Olası neden: proxy siteye tünel kuramamış, belki yasak port ya da sitenin erişilemezliği nedeniyle. İlk kontrol edilecek: curl -v çıktısındaki CONNECT yanıtı ve hedef portun izinli olup olmadığı.

Belirti: 502 kodu

Olası neden: bir sonraki halkadan kötü yanıt; suçlu ya site ya da kararsız proxy kanalı. İlk kontrol edilecek: çapraz istek — aynı site doğrudan ve aynı proxy kararlı bir siteye.

Belirti: 504 kodu

Olası neden: bekleme süresi doldu; bunun bağlantı mı yoksa yanıt mı olduğunu anlamak gerek. İlk kontrol edilecek: hangi aşamanın uzadığını görmek için ayrı connect timeout ve read timeout.

Belirti: proxy üzerinden 403 kodu

Olası neden: proxy limitleri, coğrafi kısıtlama ya da yasak port. İlk kontrol edilecek: yasağın kaynağı için yanıt gövdesi ve tükenen limitler açısından proxy kontrol paneli.

Belirti: connection reset veya ECONNRESET

Olası neden: taraflardan biri bağlantıyı zorla kapatmış; sıklıkla aşırı yüklü proxy ya da kararsız kanal. İlk kontrol edilecek: curl -v'nin son satırına göre kopma aşaması ve bir dizi istek boyunca sorunun tekrarlanabilirliği.

Belirti: EOF, empty reply

Olası neden: veri akışı yanıtın sonuna ulaşmadan kopmuş. İlk kontrol edilecek: kopmanın CONNECT yanıtından önce mi sonra mı olduğu.

Belirti: connect timeout

Olası neden: bağlantı kurulamıyor, adres erişilemez ya da port kapalı. İlk kontrol edilecek: proxy adresinin erişilebilirliği ve portun doğruluğu.

Belirti: read timeout

Olası neden: bağlantı var ama yanıt gelmiyor; site uzun süre işliyor ya da takılmış. İlk kontrol edilecek: read timeout'unuz fazla küçük mü ve site aşırı yüklü mü.

İpucu: Bu tabloyu yazdırın ya da notlarınıza kaydedin. Gerçek bir hata anında baskı altında mantığı unutmak kolaydır. Hazır bir referans sinirleri ve zamanı kurtarır.

✅ Kontrol: Son hatalarınızın her birini tablodan geçirin. Her biri için ilk kontrol eylemini biliyor olmalısınız.

Sonuç kontrolü: Teşhisçi kontrol listesi

Tüm kilit becerileri edindiğinizden emin olun. Kontrol listesini gözden geçirin.

  • Hatanın proxy'den mi site tarafından mı geldiğini saniyeler içinde söyleyebiliyorsunuz.
  • 407 ile 401 arasındaki farkı anlıyor ve paroladaki özel karakterler dahil yetkilendirmeyi düzeltebiliyorsunuz.
  • Siteden gelen 502 ile proxy'den gelen 502'yi çapraz kontrolle ayırt ediyorsunuz.
  • Connect timeout ile read timeout'u ayırıyor ve her birinin ne anlama geldiğini biliyorsunuz.
  • tunnel connection failed'in neden yalnızca HTTPS'te olduğunu anlıyor ve CONNECT yanıtını okuyabiliyorsunuz.
  • Proxy'den gelen 403'ün üç nedenini tanıyorsunuz: limitler, coğrafya ve port.
  • Bağlantı kopmalarını, gerçekleştiği aşamaya göre teşhis ediyorsunuz.
  • curl -v çıktısını satır satır okuyup istemci-proxy-sunucu sınırlarını çiziyorsunuz.

Kendinizi nasıl test edersiniz

  1. Farklı hatalar içeren üç gerçek log alın.
  2. Her biri için suçlu halkayı bir dakika içinde belirleyin.
  3. Tabloya göre ilk kontrol eylemini söyleyin.
  4. Üçünü de başardıysanız teşhis öğrenilmiş demektir.

✅ Kontrol: Başarı göstergesi şudur: artık proxy hatası gördüğünüzde paniklemiyor, onu sakin sakin zincir halkalarına ayırıyorsunuz.

Yaygın hatalar ve çözümler

Sorun: her hatada hemen proxy'yi değiştiriyorum

Neden: çapraz kontrol alışkanlığı yok. Çözüm: ayarları değiştirmeden önce her zaman doğrudan ve kararlı bir siteye kontrol isteği yapın. Hataların yarısı site tarafında çıkıyor.

Sorun: et işareti içeren parola bağlantıyı bozuyor

Neden: özel karakter kodlanmamış ve dizeyi bölüyor. Çözüm: parolaya URL kodlaması uygulayın ya da verileri adrese yazmak yerine ayrı bir yetkilendirme parametresi kullanın.

Sorun: 407 ile 401'i karıştırıyorum

Neden: proxy yetkilendirmesi ile site yetkilendirmesini ayırt etmiyorum. Çözüm: unutmayın — 407 her zaman proxy'den, 401 her zaman siteden gelir. Hangi başlığı gönderdiğinizi kontrol edin: Proxy-Authorization mı Authorization mı.

Sorun: fazla katı zaman aşımı normal istekleri kesiyor

Neden: read timeout fazla küçük ayarlanmış. Çözüm: connect ve read zaman aşımlarını ayırın, read'e yavaş sayfalar için bol pay bırakın.

Sorun: standart dışı portta tunnel connection failed

Neden: proxy bu porta CONNECT'i yasaklıyor. Çözüm: güvenli bağlantılar için standart portu kullanın ya da proxy'den izinli port listesini öğrenin.

Sorun: 502 görüp proxy ölmüş sanıyorum

Neden: 502'yi kimin gönderdiğini kontrol etmedim. Çözüm: çapraz kontrol. Sıklıkla 502 aşırı yüklü hedef siteden gelir ve proxy sağlamdır.

Sorun: logda kullanıcı adı ve parolayı açık ettim

Neden: curl -v çıktısını temizlemeden paylaştım. Çözüm: logu birine göndermeden önce yetkilendirme satırını her zaman karalayın ve mümkünse sızmış verileri değiştirin.

Sorun: bağlantı kopmasını zaman aşımı sanıyorum

Neden: reset ile timeout'u ayırt etmiyorum. Çözüm: hata metnine bakın. Reset — karşı tarafın etkin kapatması, timeout — sizin beklemenizin sona ermesi. Bunlar farklı nedenlerdir.

İleri düzey kullanıcılar için ek imkânlar

Kalıcı loglama

Uygulamanızda tüm proxy isteklerinin ayrıntılı loglarının kaydedilmesini ayarlayın. Böylece hata çıktığında elinizde zaten bir geçmiş olur ve sorunu yeniden üretmek zorunda kalmazsınız. Yanıt kodunu, kopma aşamasını ve çalışma süresini kaydedin.

Otomatik hata sınıflandırması

Kodda, istisna türüne ve yanıt koduna göre hatayı doğrudan ilgili halkaya atayan bir fonksiyon tanımlayabilirsiniz. Örneğin ConnectTimeout — bağlantı kesimi, ReadTimeout — yanıt kesimi, tünelli ProxyError — proxy katmanı. Bu, otomatik sistemlerde tepkiyi hızlandırır.

Kararlılık istatistikleri toplama

Metrikler tutun: başarılı istek oranı, kopma oranı, ortalama yanıt süresi. Metriklerdeki ani bozulma, sorunla elle karşılaşmadan önce size haber verir.

İpucu: Metrikleri halkalara göre ayırın. Bağlantı kurma hatalarını ve yanıt aşamasındaki hataları ayrı ayrı sayın. Böylece tam olarak neyin bozulduğunu hemen görürsünüz — proxy'ye erişim mi yoksa sitelerle iletişim mi.

⚠️ Dikkat: Otomatik işleme kurarken bunu aynı isteğin sonsuz tekrarına dönüştürmeyin. Yeniden deneme mantığı, 429 koduyla da bağlantılı, kendi kuralları olan ayrı ve geniş bir konudur. Ona ayrı bir materyal ayrılmıştır ve ayrıca incelenmelidir.

SSS: teşhisle ilgili sık sorulan sorular

Suçlunun kodum değil de tam olarak proxy olduğunu nasıl hızlı anlarım?

Aynı isteği doğrudan proxy olmadan yapın. Doğrudan çalışıyor ama proxy üzerinden çalışmıyorsa sorun proxy katmanında ya da onun siteyle etkileşimindedir. Bu, bir dakikada hipotezlerin yarısını eler.

Doğru parolayı girdiğim halde neden 407 alıyorum?

Büyük olasılıkla parolada bağlantı dizesini bozan özel karakterler vardır. Parolaya URL kodlaması uygulayın ya da verileri adres yerine ayrı bir yetkilendirme parametresiyle iletin.

502 kodu her zaman proxy'nin bozuk olduğu anlamına mı gelir?

Hayır. 502'yi, kötü yanıt verdiğinde hedef site de gönderebilir. Çapraz kontrol yapın: aynı site doğrudan ve aynı proxy kararlı bir siteye. Sonuçların kesişimi size suçluyu gösterecektir.

Connect timeout ile read timeout arasındaki fark nedir?

Connect timeout — bağlantı kurulmasını bekleme süresi. Read timeout — bağlantı kurulduktan sonra yanıtı bekleme süresi. İstemcide bunları ayırın, hangi aşamanın uzadığını hemen görürsünüz.

tunnel connection failed neden yalnızca HTTPS'te olur?

Çünkü güvenli siteler için istemci, proxy'den CONNECT komutuyla tünel kurmasını ister. Normal HTTP'de böyle bir komut yoktur. Tünel kurulamazsa bu hata gelir ve yalnızca HTTPS'te mümkündür.

Proxy'den gelen 403 ile siteden gelen 403 nasıl ayırt edilir?

Yanıt gövdesine bakın. Sitenin tasarımlı sayfası sitenin yasağı anlamına gelir. Teknik bir sayfa ya da proxy'nin anılması aracının yasağı anlamına gelir. Bunu siteye doğrudan istekle doğrulayın.

Rastgele bağlantı kopmalarında ne yapmalıyım?

Önce tekrarlanabilirliği belirleyin: bir dizi istek yapıp kopma oranını sayın. Tek tük kopmalar tolere edilebilir ağ kararsızlığıdır. Yoğun kopmalar proxy ya da kanalın sistematik sorunudur.

curl -v logunu yardım için nasıl güvenle paylaşılır?

Göndermeden önce proxy yetkilendirmesini ve hassas başlıkları içeren satırı mutlaka karalayın. Aksi halde kullanıcı adı ve parolanızı açık edersiniz. Şüphedeyseniz sızmış verileri değiştirin.

Normal isteklerim neden bazen zaman aşımıyla kopuyor?

Büyük olasılıkla read timeout fazla katı ayarlanmıştır ve yavaş ama sağlıklı yanıtları kesiyorsunuz. Read timeout'u bol payla artırın, connect timeout'u küçük bırakın.

429 kodu ve yeniden denemeler hakkında nereden okuyabilirim?

429 kodu ve retry stratejileri, proxy katmanı hatalarıyla doğrudan ilgili olmayan ayrı ve geniş bir konudur. Ona ayrı bir materyal ayrılmıştır; proxy hata teşhisinden ayrı olarak inceleyin.

Sonuç: Ne öğrendiniz ve bundan sonra ne yapmalı

Tebrikler. Anlaşılmaz kodlar karşısındaki şaşkınlıktan kendinden emin adım adım teşhise uzanan yolu katettiniz. Şimdi cephaneliğinizde neler olduğunu hatırlayalım.

Yapılan işlerin özeti. Zinciri üç halkaya — istemci, proxy ve sunucu — ayırmayı ve hatanın tam olarak nerede çıktığını belirlemeyi öğrendiniz. Paroladaki sinsi özel karakterler dahil 407 kodu ve proxy yetkilendirmesi konusunu kavradınız. 502'nin ikili doğasını ve çapraz kontrol yöntemini anladınız. 504'te connect ve read zaman aşımı ayrımını öğrendiniz. CONNECT yöntemini ve HTTPS'teki tunnel connection failed hatasını çözdünüz. Proxy'den gelen 403'ün üç nedenini tanımayı ve bağlantı kopmalarını aşamaya göre teşhis etmeyi öğrendiniz. Ve son olarak, ana beceriyi edindiniz — curl -v çıktısını halkalar arasındaki sınırları tam olarak çizerek satır satır okumayı.

Bundan sonra ne yapmalı. Beceriyi pratikte pekiştirin. Her proxy hatasıyla karşılaştığınızda tahmin etmek yerine, teşhis tablosuyla onu sakince halkalara ayırın. Bir hafta böyle bir pratikten sonra teşhis otomatik hale gelir.

Nereye gelişmeli. Bir sonraki mantıklı adım, ayrı bir materyale ayrılmış olan 429 kodu ve akıllı yeniden deneme stratejileri konusunu öğrenmektir. Ardından kodda otomatik hata sınıflandırması ve kararlılık metrikleri toplama konusunda derinleşin. Bu, sizi yangın söndüren birinden sorunları önceden öngören bir mühendise dönüştürür.

İpucu: Bu rehberi ve teşhis tablosunu yer imlerine ekleyin. Mantık ikinci doğanız haline gelene kadar her yeni hatada onlara dönün. Teşhiste güven tam olarak tekrarla gelir. Her şey yoluna girecek.