Destek mühendisi için "proxy çalışmıyor" ifadesi, bir doktor için "içeride bir yer ağrıyor" demek gibidir. Yön belli ama tahlil ve belirti olmadan teşhis konulamaz. Bu rehberde, belirsiz bir şikayeti tek ve net bir yanıtı olan somut bir göreve dönüştüren veri setini toplamayı öğreneceksiniz.

Giriş: "Çalışmıyor" neden teşhis edilemez?

Proxeon desteğine gelen iki başvuru düşünün. Birincisi: "Proxy aldım, hiçbir şey çalışmıyor, yardım edin." İkincisi: "PX-48213 kimlikli proxy, 12 Mart 2026, 14:32 UTC+3'te api.example.com'a HTTP üzerinden yapılan istekte bağlantı hatası veriyor; aynı proxy başka bir siteye çalışıyor, proxysiz doğrudan bağlantı da çalışıyor, curl çıktısını ekliyorum." İlk başvuru, her biri saatler süren beş-altı ek soru e-postası zinciri başlatır. İkincisi tek yanıtta kapanır.

Fark nezakette ya da şansta değil. Fark veride. Mühendis sizin ekranınızı görmez, işletim sisteminizi bilmez, isteğinizi kaynak parametreler olmadan yeniden oluşturamaz. Elinde olan tek şey mektubunuzun metni. Bu metinde gerçek yoksa yapacağı ilk şey gerçekleri istemek olur. Basit bir sorunu günlere yayan o e-posta zinciri de tam olarak budur.

Okuyucu sonunda ne elde edecek?

Bu kılavuzdan sonra, sorunu ilk yanıtta çözmek için gereken her şeyi içeren bir teşhis paketini 15-20 dakikada toplayabileceksiniz. Teknik verileri tek bir metin dosyasında toplayan hazır bir betiğiniz, kopyalayabileceğiniz bir başvuru şablonunuz ve desteğe yazmadan önce hangi kontrolleri yapmanız gerektiğine dair net bir anlayışınız olacak.

Bu rehber kimin için?

Kılavuz, orta düzey proxy kullanıcıları için hazırlandı: terminal veya komut istemini açabilen, URL'nin ne olduğunu bilen ve en az bir kez bir uygulamada proxy yapılandırmış olanlar. İleri düzey kullanıcılar burada hazır teşhis betiğini ve sorun izolasyon tablosunu bulacak. Yeni başlayanlar için her terimi ayrıntılı olarak açıklıyoruz.

Önceden bilinmesi gerekenler

Üç şeyi anlamak yeterli. Proxy, ağ isteğinizin üzerinden geçtiği aracıdır. Hedef adres, başvurduğunuz site veya hizmettir. İstemci, proxy üzerinden istek yapan programdır (tarayıcı, kazıyıcı, betik). Gerisini yol boyunca ele alacağız.

Ne kadar zaman alacak?

Betik kurulumuyla rehberi ilk kez baştan sona geçmek yaklaşık 30 dakika sürer. Sonrasında hazır şablonla teşhis toplamak 10-15 dakika alır. Bu, ek sorularla geçen birkaç günlük yazışmayla kıyaslanamayacak kadar az.

İpucu: Bu rehberi ve betiği yer imlerine ekleyin. Proxy sorunları nadiren ortaya çıkar ve çıktığında tüm prosedürü yeniden hatırlamak zordur. Elinizin altındaki hazır kontrol listesi sinirleri korur.

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

Veri toplamaya başlamadan önce temel araçlara sahip olduğunuzdan emin olun. Hepsi ücretsizdir ve çoğu sistemde zaten kuruludur.

Gerekli araçlar

  • curl — ağ istekleri göndermek için komut satırı aracı. Sorunu yeniden oluşturmak için ana aracımız. macOS ve çoğu Linux dağıtımında önceden kuruludur. Windows 10 ve 11'de de sisteme dahildir.
  • Terminal veya komut istemi — komutları girdiğiniz pencere. Windows'ta PowerShell veya Komut İstemi (cmd), macOS ve Linux'ta Terminal.
  • Metin düzenleyici — toplanan dosyayı görüntülemek ve gizli bilgileri silmek için Not Defteri, TextEdit veya herhangi bir düzenleyici.
  • Proxeon'dan proxy verileriniz — kimlik, adres, port, kullanıcı adı ve parola. Bunlar size kontrol panelinizde verilmiştir.

curl'ün kurulu olup olmadığını kontrol etme

Terminali açın ve basit bir kontrol yapın.

  1. Windows'ta Win tuşuna basın, PowerShell yazın ve uygulamayı açın.
  2. macOS'ta Cmd+Boşluk ile Spotlight'ı açın, Terminal yazın ve Enter'a basın.
  3. Linux'ta terminali uygulama menüsünden veya Ctrl+Alt+T kısayoluyla açın.
  4. curl --version
    komutunu girin ve Enter'a basın.

"curl 8.x.x" biçiminde bir satır ve desteklenen protokollerin listesini görüyorsanız araç hazırdır. Sistem komutun bulunamadığını söylüyorsa curl'ü kurun: Windows'ta sistemi güncel bir sürüme güncelleyin, Linux'ta dağıtımınızın paket yöneticisiyle kurulum yapın.

✅ Kontrol:

curl --version
komutu sürüm numarasını ve http ile https dahil protokol listesini verdi. Yani her şey çalışmaya hazır.

Proxeon verilerinden ne hazırlamalı

proxeon.net adresindeki Proxeon kontrol panelinize giriş yapın ve proxy kartınızı açın. Şu alanları bir yere yazın veya ayrı bir dosyaya kopyalayın: proxy kimliği, ana makine (adres), port, tür (HTTP, HTTPS veya SOCKS5), kullanıcı adı ve parola. Bu veriler yeniden oluşturma komutunu hazırlamak için gerekecek.

⚠️ Dikkat: proxy kullanıcı adı ve parolası gizli verilerdir. Bunlarla yerel olarak çalışacağız ancak destek başvurusuna EKLEMEYİN. Aşağıda logları göndermeden önce güvenli şekilde temizleme üzerine ayrı bir bölüm var.

Temel kavramlar: istemci — proxy — sunucu sınırı

Hangi verilerin önemli olduğunu anlamak için isteğin yolunu gözünüzde canlandırmanız gerekir. Üç bölümden geçer ve sorun herhangi birinde ortaya çıkabilir.

Tek zincirin üç halkası

Proxy üzerinden bir siteye başvurduğunuzda istek şöyle ilerler: istemciniz isteği proxy sunucusuna gönderir, o da hedef sunucuya yönlendirir, yanıtı alır ve size döndürür. Üç halka, iki sınır. Hangi sınırda takıldığını anlamak, teşhisin yarısıdır.

  • İstemci — proxy sınırı. İstek proxy'ye ulaşmadıysa sorun sizin tarafınızdadır: yanlış proxy adresi, kapalı port, kurumsal filtre, istemci ayarlarında hata.
  • Proxy — sunucu sınırı. Proxy isteği aldı ama hedef siteye ulaşamadıysa sorun proxy ile hedef arasındadır: site erişilemez, bağlantıyı reddediyor veya hata veriyor.

Teşhisin görevi, zincirin hangi sınırda koptuğunu belirlemektir. Proxeon destek mühendisi çıktınızdan isteğin nerede durduğunu hemen görecek ve bu, olası nedenleri ciddi ölçüde daraltacaktır.

Kesin saat neden bu kadar önemli

Proxy altyapısı log tutar. Mühendisin loglarda sizin belirli isteğinizi bulması için olayın saat dilimi belirtilmiş kesin saatine ihtiyacı vardır. "Bugün sabah" loglarda aranmaz. "14:32 UTC+3" saniyeler içinde bulunur. Sizin ifadenizle logdaki kayıt arasındaki saat farkı, olayın hiç bulunamamasının sık nedenidir.

İpucu: saat dilimini her zaman açıkça belirtin. "UTC+3" veya "TSİ" biçimi tahmine yer bırakmaz. Farklı bir dilimdeyseniz kendi diliminizi yazın — sunucu kendisi dönüştürür.

Adım 1: Asgari veri setini toplayın

Bu aşamanın amacı: herhangi bir başvurunun eksik kalacağı beş olguyu kaydetmek. Bu temeldir, gerisi üzerine inşa edilir.

Beş zorunlu olgu

  1. Proxy kimliği. Proxeon kontrol panelindeki tam ad veya numara, örneğin PX-48213. "Dün aldığım proxy" değil, belirli bir kimlik. Birden fazla proxyniz varsa hangisinden söz ettiğinizi belirtin.
  2. Saat dilimiyle kesin zaman. Sorun tam olarak ne zaman ortaya çıktı. Biçim: tarih, saat, dilim. Örneğin: 12 Mart 2026, 14:32, UTC+3. Sorun tekrarlıyorsa birkaç zaman damgası verin.
  3. Hedef adres. Başvurduğunuz tam URL veya ana makine. Örneğin: https://api.example.com/v2/data. "Bir site" değil, kesin adres.
  4. Tam olarak ne yaptınız. Eylemle ilgili bir-iki cümle. "Betiğimden GET isteği gönderdim" veya "proxy ayarlı tarayıcıda siteyi açtım". Bağlam, isteğin niteliğini anlamaya yardımcı olur.
  5. Ne beklediniz ve ne aldınız. 200 kodu ve veri beklediniz, bağlantı hatası aldınız. Sayfa yüklenmesini beklediniz, sonsuz yükleme aldınız. Beklenti ile gerçek arasındaki fark, sorunun özüdür.

⚠️ Dikkat: somutluğu duygularla değiştirmeyin. "Her şey yavaş, berbat" teknik bilgi taşımaz. "Yanıt normalde 2 saniyede gelirken 40 saniyede geliyor" taşır.

Zamanı doğru kaydetme

Sorun şu anda yaşanıyorsa saate bakın ve zamanı hemen kaydedin. Geçmişte olduysa zamanı uygulamanızın loglarından veya tarayıcı geçmişinden geriye doğru kestirin. Damga ne kadar kesinse sunucu tarafında kayıt o kadar hızlı bulunur.

✅ Kontrol: kayıtlı beş olgunuz var. Bunları yüksek sesle okuyun. Ekranınızı görmeyen biri ne olduğunu, nerede ve ne zaman olduğunu anlıyorsa asgari set toplanmış demektir.

Adım 2: Sorunu tek bir curl komutuyla yeniden oluşturun

Bu aşamanın amacı: sorunu, mühendisin zihinsel ya da gerçek olarak tekrarlayabileceği tek bir komuta indirgemek ve ayrıntılı teknik çıktı elde etmek.

Tarayıcı ve karmaşık betikler onlarca gizli işlem yapar. Onlarda sorunu izole etmek zordur. curl tam olarak bir istek yapar ve her aşamasını gösterir. Bu, yeniden oluşturma için ideal araçtır.

Proxeon proxy üzerinden temel komut

Komutu verilerinizden oluşturun. Genel görünüm şöyledir:

curl -v -x http://KULLANICI_ADI:PAROLA@HOST:PORT https://HEDEF-ADRES

Bayrakları inceleyelim. -v ayrıntılı modu (verbose) açar: curl tüm bağlantı akışını satır satır gösterir. -x isteğin geçeceği proxy'yi belirtir. Ardından yetkilendirmeli proxy adresi gelir. Sonda hedef adres bulunur.

Yerleştirilmiş değerlerle örnek (veriler kurgusaldır):

curl -v -x http://user123:secretpass@proxy.proxeon.net:8080 https://api.example.com/v2/data

Zaman ölçümü ve dosyaya kayıt ekleme

Çıktıyı olabildiğince bilgilendirici yapmak için komutu genişletelim. -w bayrağı sona zamanlama özeti ekler.

curl -v -x http://user123:secretpass@proxy.proxeon.net:8080 -w "Son kod: %{http_code}, toplam süre: %{time_total}s" https://api.example.com/v2/data

Artık çıktının en sonunda son HTTP kodunu ve toplam istek süresini göreceksiniz. Bunlar hız teşhisi için kilit rakamlardır.

İpucu: sorun hata değil de yavaşlıksa,

-w "dns: %{time_namelookup} connect: %{time_connect} start: %{time_starttransfer} total: %{time_total}"
ile ayrıntılı zamanlamalar ekleyin. Bu, zamanın hangi aşamada kaybolduğunu gösterir.

SOCKS5 proxy için

Proxyniz SOCKS5 türündeyse adresteki şemayı değiştirin:

curl -v -x socks5://user123:secretpass@proxy.proxeon.net:1080 https://api.example.com/v2/data

⚠️ Dikkat: komut gerçek kullanıcı adınızı ve parolanızı içerir. Bunu kendi terminalinizde çalıştırın ama gizli bilgilerle birlikte mektuba KOPYALAMAYIN. Başvuruda kullanıcı adı ve parola yer tutucularla değiştirilir — bu konu 5. adımda.

Uygulama sırası

  1. Terminali açın.
  2. Oluşturduğunuz komutu gerçek verilerinizi yerleştirerek yapıştırın.
  3. Enter'a basın ve tamamlanmasını bekleyin.
  4. İlk satırdan son satıra kadar tüm çıktıyı seçip bir metin dosyasına kopyalayın.

✅ Kontrol: "*", ">" ve "<" karakterleriyle başlayan satırların göründüğü çok satırlı bir çıktı aldınız. Çıktı varsa istek hata ile bitmiş olsa bile yeniden oluşturma başarılıdır — hata da değerli bilgidir.

Adım 3: Çıktıyı satır satır okuyun ve sorunun sınırını bulun

Bu aşamanın amacı: curl çıktısının ne gösterdiğini anlamayı ve isteğin hangi halkada durduğunu belirlemeyi öğrenmek. Belirli hata kodlarının çözümlemesini burada tekrarlamıyoruz — bunun için Proxeon bilgi tabanında ayrı bir makale var; gerekirse başvuruda ona bağlantı verin.

Çıktıdaki üç satır türü

Ayrıntılı curl çıktısı, yön bulmayı kolaylaştıran önekler kullanır.

  • Yıldızlı (*) satırlar — curl'ün bağlantı akışıyla ilgili servis mesajları: ad çözümleme, proxy ile bağlantı kurma, şifreleme el sıkışması. Bu iç mutfaktır.
  • Sağ ok (>) satırları — istemcinizin GÖNDERDİĞİ şeyler. İstek başlıkları, yöntem, yol.
  • Sol ok (<) satırları — size VERİLEN yanıtlar. Yanıt kodu, sunucu başlıkları.

İstemci — proxy sınırı nerede geçer

Çıktının başında curl proxy ile bağlantı kurduğunu bildirir. "Connected to proxy.proxeon.net port 8080" gibi bir satır görürsünüz. Bu satır yoksa ve yerine bağlantı hatası varsa istek proxy'ye ulaşmamıştır. Sorun istemci — proxy sınırındadır: port kapalı olabilir, adres yanlış olabilir veya yerel bir filtre engelliyor olabilir.

Proxy'ye bağlantı satırı varsa ama ardından yetkilendirme hatası geliyorsa proxy erişilebilir ama kullanıcı adınızı ve parolanızı kabul etmemiştir. Bu da istemci — proxy sınırıdır ama artık kimlik doğrulama düzeyindedir.

Proxy — sunucu sınırı nerede geçer

Proxy'ye başarılı bağlantıdan sonra curl, proxy üzerinden hedef sunucuyla bağlantı kurulumunu gösterir. Burada bir hata oluşuyorsa proxy isteği almış ama hedefe ulaşamamıştır. Sorun proxy — sunucu sınırındadır: hedef site erişilemez, bağlantıyı reddediyor veya yavaş yanıtlıyor.

Sol okla bir yanıt satırı görüyorsanız, örneğin "< HTTP/1.1 200" veya başka bir kod, tüm zincir çalışmış ve yanıt almışsınızdır. Sonrası yanıtın içeriği meselesidir, proxy'nin çalışması değil.

Mühendis için önemli olan kilit satırlar

  1. Proxy'ye bağlantı satırı — ilk halkanın çalıştığını doğrular.
  2. Proxy'de yetkilendirme satırı — kimlik bilgilerinin kabul edilip edilmediğini gösterir.
  3. Şifreleme el sıkışması (TLS) satırı — HTTPS hedefleri için önemlidir.
  4. Sol oklu ilk yanıt satırı — zincirin nihai kararı.
  5. -w bayrağından gelen kod ve süre özeti.

İpucu: Emin değilseniz hata kodundan kendi başınıza teşhis koymaya çalışmayın. Sizin göreviniz tam çıktıyı eklemek. Proxeon mühendisi onu daha doğru okur. Kodların tam çözümlemesi bilgi tabanındaki ayrı bir makalede var — daha derine inmek isterseniz ona başvurun.

✅ Kontrol: İsteğin koptuğu satırı parmağınızla gösterebiliyor ve bunun hangi sınırda olduğunu söyleyebiliyorsunuz — istemci-proxy mi proxy-sunucu mu. Söyleyebiliyorsanız bu aşamayı geçtiniz.

Adım 4: Başvurmadan önce kontrolleri yapın

Bu aşamanın amacı: Desteğe yazmadan önce eleme yöntemiyle olası nedenleri daraltmak. Her kontrol bir sorun sınıfını eler.

İlke basittir: her seferinde tek bir parametreyi değiştirin ve davranışın değişip değişmediğine bakın. Bu, arıza izolasyonuna klasik mühendislik yaklaşımıdır.

Dört kilit kontrol

  1. Başka bir hedef site. Aynı isteği aynı proxy üzerinden başka bir adrese tekrarlayın. Kesinlikle kararlı bir genel site seçin. Proxy ona çalışıyorken sizin hedefinize çalışmıyorsa sorun hedef siteyle veya onun proxy'ye karşı tutumuyla ilgilidir, proxy'nin kendisiyle değil.
  2. Başka bir protokol. HTTP kullandıysanız HTTPS hedefini deneyin, tersini de. Bazen sorun yalnızca bir protokolde ortaya çıkar ve bu önemli bir sinyaldir.
  3. Başka bir proxy. Proxeon'dan ikinci bir proxyniz varsa isteği onun üzerinden tekrarlayın. İkinci çalışıyor, birinci çalışmıyorsa sorun o belirli proxydedir. Her ikisi de aynı davranıyorsa sorun daha sistemiktir.
  4. Doğrudan bağlantı. Hedefe proxy OLMADAN doğrudan istek yapın. -x bayrağını kaldırın. Doğrudan da site erişilemezse sorun proxy'de değil, hedef sitenin kendisinde veya ağınızdadır.

Doğrudan kontrol için komut

curl -v https://api.example.com/v2/data

Aynı komut ama proxy kısmı olmadan. Sonucu proxy üzerinden istekle karşılaştırın.

Tablo: her kontrol neyi eler

Aşağıda kontrol sonuçlarının nasıl yorumlanacağı var.

  • Başka site çalışıyor, sizinki çalışmıyor. Proxy'nin genel olarak bozuk olduğunu eler. Belirli bir hedefin proxy'yle etkileşiminin özel olduğuna işaret eder.
  • Başka protokol çalışıyor, sizinki çalışmıyor. Tam erişilemezliği eler. Sorunu belirli bir protokol veya port düzeyinde yerelleştirir.
  • Başka proxy çalışıyor, sizinki çalışmıyor. Sizin tarafınızdaki ve ağdaki sorunu eler. Belirli bir proxy'ye işaret eder.
  • Doğrudan bağlantı da çalışmıyor. Proxy'nin suçunu eler. Sorun hedef sitede veya ağınızdadır.
  • Doğrudan çalışıyor, proxy üzerinden çalışmıyor. İşin tam olarak proxy bağlantısında olduğunu doğrular ve desteğin yardımcı olacağı durum budur.

İpucu: Bu dört kontrolün sonuçları başvurunun en değerli kısmıdır. Gereksizi zaten elediğiniz için mühendisin işinin yarısını kurtarır. Mektupta mutlaka listeleyin.

⚠️ Dikkat: Bu proxy'leri yalnızca yasal görevler için kullanın: kendi hizmetlerinizi test etmek, kurallara uygun şekilde genel veri toplamak, API'lerle çalışmak. Kontroller, sitelerin kurallarını veya mevzuatı ihlal eden eylemler için tasarlanmamıştır.

✅ Kontrol: Dört kontrolün de sonucunuz var ve bunların birlikte neyi elediğini tek cümleyle söyleyebiliyorsunuz. Örneğin: "Doğrudan bağlantı ve diğer proxy çalışıyor, yani sorun bu hedefe başvururken PX-48213 adlı belirli proxydedir."

Adım 5: Kendi tarafınıza dair verileri toplayın

Bu aşamanın amacı: Sorunun ortaya çıktığı ortamı tanımlamak. Anlaşılamayan vakaların yarısı istemci ya da yerel ağ özellikleriyle açıklanır.

Ortam hakkında neler belirtilmeli

  1. İşletim sistemi ve sürümü. Windows 11, macOS 15, Ubuntu 24.04. Kesin sürüm koşulları yeniden oluşturmaya yardımcı olur.
  2. İstemci ve sürümü. Proxy'yle ne üzerinden çalışıyorsunuz: tarayıcı ve sürümü, kazıyıcı veya kütüphanenin adı ve sürümü, curl sürümü. Farklı istemciler proxy'yi farklı işler.
  3. Proxy yapılandırma yöntemi. Sistemde, tarayıcıda yapılandırılmış, kodda iletilen, ortam değişkenlerinde tanımlı. Bu, proxy'nin nasıl uygulandığını etkiler.
  4. Kurumsal veya yerel filtre varlığı. Kurumsal bir ağdan mı çalışıyorsunuz, ağ güvenlik duvarı olan bir antivirüs var mı, yerel güvenlik duvarı var mı. Bu tür filtreler bağlantıları proxy'den önce kesebilir veya engelleyebilir.
  5. İnternet bağlantı türü. Ev sağlayıcısı, mobil internet, iş ağı. Bazen sağlayıcı erişilebilirliği etkiler.

İstemci sürümü nasıl öğrenilir

curl için bildiğimiz

curl --version
komutunu kullanın. Tarayıcı için menüdeki "Hakkında" bölümünü açın. Koddaki kütüphane için projenizin bağımlılık dosyasındaki sürümüne bakın.

Kurumsal filtre kontrolü

Kurumsal bir ağdaysanız ve filtreden şüpheleniyorsanız bunu kontrol etmek kolaydır. Hedef olmadan doğrudan proxy'ye istek yapın ve bağlantının kurulup kurulmadığına bakın. Proxy portuna doğrudan bağlantı bile geçmiyorsa ama başka bir ağdan geçiyorsa, giden bağlantılarda kurumsal filtre olması muhtemeldir.

İpucu: Kurumsal ağlar genellikle yalnızca 80 ve 443 portlarına izin verir. Proxyniz standart dışı bir porttaysa ağ yöneticinize bu portun dışa açık olup olmadığını sorun. Bu sık ve kolay çözülebilir bir nedendir.

✅ Kontrol: Ortam hakkında beş maddelik doldurulmuş listeniz var. Mühendis bunu okuduğunda sorunu hangi koşullarda yeniden oluşturacağını bilir.

Adım 6: Teşhis toplamayı tek bir betikle otomatikleştirin

Bu aşamanın amacı: Tüm teknik bilgileri elle yeniden yazmadan tek bir metin dosyasında toplamak. Betik, elle yaptığınızı tek çalıştırmada yapar.

macOS ve Linux için betik

Aşağıdaki içerikle diag.sh dosyasını oluşturun. Değişken değerlerini kendi değerlerinizle değiştirin.

#!/bin/bash
PROXY="http://KULLANICI_ADI:PAROLA@HOST:PORT"
TARGET="https://HEDEF-ADRES"
ALT="https://KARARLI-SITE"
OUT="diag_result.txt"
echo "=== Tarih ve saat ===" > $OUT
date >> $OUT
echo "=== curl sürümü ===" >> $OUT
curl --version >> $OUT 2>&1
echo "=== Proxy üzerinden hedefe istek ===" >> $OUT
curl -v -x $PROXY -w "code:%{http_code} total:%{time_total}s" $TARGET >> $OUT 2>&1
echo "=== Proxy üzerinden alternatif siteye istek ===" >> $OUT
curl -v -x $PROXY -w "code:%{http_code} total:%{time_total}s" $ALT >> $OUT 2>&1
echo "=== Hedefe proxysiz doğrudan istek ===" >> $OUT
curl -v -w "code:%{http_code} total:%{time_total}s" $TARGET >> $OUT 2>&1
echo "Bitti. Dosya: $OUT"

Betik nasıl çalıştırılır

  1. Dosyayı diag.sh adıyla kaydedin.
  2. PROXY, TARGET ve ALT değişkenlerine kendi değerlerinizi yazın.
  3. Terminalde dosyanın bulunduğu klasöre gidin.
  4. Dosyayı
    chmod +x diag.sh
    komutuyla çalıştırılabilir yapın.
  5. ./diag.sh
    komutuyla çalıştırın.
  6. Tamamlandığında diag_result.txt dosyasını açın.

Windows için betik (PowerShell)

Benzer mantıkla diag.ps1 dosyasını oluşturun.

$Proxy = "http://KULLANICI_ADI:PAROLA@HOST:PORT"
$Target = "https://HEDEF-ADRES"
$Alt = "https://KARARLI-SITE"
$Out = "diag_result.txt"
"=== Tarih ve saat ===" | Out-File $Out
Get-Date | Out-File $Out -Append
"=== curl sürümü ===" | Out-File $Out -Append
curl --version 2>&1 | Out-File $Out -Append
"=== Proxy üzerinden hedefe ===" | Out-File $Out -Append
curl -v -x $Proxy -w "code:%{http_code} total:%{time_total}s" $Target 2>&1 | Out-File $Out -Append
"=== Proxy üzerinden alternatife ===" | Out-File $Out -Append
curl -v -x $Proxy $Alt 2>&1 | Out-File $Out -Append
"=== Doğrudan istek ===" | Out-File $Out -Append
curl -v $Target 2>&1 | Out-File $Out -Append

PowerShell'de

.\diag.ps1
komutuyla çalıştırın ve oluşan dosyayı açın.

⚠️ Dikkat: diag_result.txt dosyası kullanıcı adınızı ve parolanızı açık metin olarak içerir, çünkü bunlar PROXY değişkenindeydi. Desteğe göndermeden ÖNCE 7. adımdaki talimata göre MUTLAKA temizleyin.

İpucu: Betiği boş değişkenlerle saklayın, değerleri yalnızca çalıştırmadan önce yerleştirin. Böylece dosyayı yanlışlıkla gizli bilgilerle paylaşma riski taşımazsınız.

✅ Kontrol: diag_result.txt dosyası oluşturuldu ve birkaç blok içeriyor: curl sürümü, iki siteye proxy üzerinden istekler ve doğrudan istek. Bu hazır teknik teşhis paketidir.

Adım 7: Göndermeden önce logları güvenli şekilde temizleyin

Bu aşamanın amacı: Toplanan verilerden tüm gizli bilgileri çıkarırken teşhis değerini korumak. Parola içeren logları göndermek kesinlikle olmaz.

Mutlaka çıkarılması gerekenler

  • Proxy parolası. Çıktıda bağlantı satırına düşmüş olabilir. Bulun ve değiştirin.
  • Ödeme verilerine bağlıysa kullanıcı adı. Genellikle kullanıcı adı kalabilir ama hassas bir bağın parçasıysa onu da değiştirin.
  • Yetkilendirme token'ları. İstek başlıklarında Authorization, Bearer token'ları, API anahtarları, oturum cookie'leri varsa hepsini çıkarın.
  • Kişisel veriler. İstek ya da yanıt gövdesine rastlamışsa ad, adres, telefon gibi her şey.

Ne ile değiştirmeli

Satırın tamamını silmeyin — böylece yapı kaybolur. Gizli bilgiyi, mümkünse uzunluğunu ve biçimini koruyarak anlaşılır bir yer tutucuyla değiştirin. Örnek değişimler:

  • Parolayı [PAROLA_GIZLI] ile değiştirin.
  • Kullanıcı adını [KULLANICI_ADI_GIZLI] ile değiştirin.
  • Token'ı [TOKEN_GIZLI] ile değiştirin.

Böylece mühendis burada bir token olduğunu görür ama değerini görmez. Yapı korunur, güvenlik de korunur.

Temizleme sırası

  1. diag_result.txt dosyasını bir metin düzenleyicide açın.
  2. Ctrl+F ile parolanızı arayın ve tüm geçtiği yerleri yer tutucuyla değiştirin.
  3. Kullanıcı adını gizlemeye karar verdiyseniz onu da aynı şekilde yapın.
  4. Authorization, Cookie, api-key başlıklarını içeren satırları gözden geçirin. Değerleri yer tutucularla değiştirin.
  5. Dosyayı örneğin diag_clean.txt adıyla, orijinaliyle karıştırmamak için yeni bir adla kaydedin.

⚠️ Dikkat: Dosyayı göndermeden önce iki kez kontrol edin. Parola yalnızca komutta değil, curl çıktı satırlarında da yer almış olabilir. Atlanan bir gizli bilgi, proxy'nizin tehlikeye girmesine yol açabilecek bir sızıntıdır.

İpucu: diag_result.txt orijinalini yerel olarak saklayın, yalnızca temizlenmiş kopyayı gönderin. Mühendis bir açıklama isterse elinizin altında tam veri olur.

✅ Kontrol: Temizlenmiş dosyayı açın ve parolanızı arayın. Sıfır sonuç — yani temizleme başarılı. Çıktının yapısı bu arada korunmuş.

Adım 8: Hazır başvuru şablonunu doldurun

Bu aşamanın amacı: Her şeyi, mühendisin okuyup görevi hemen anlayacağı tek bir mektupta bir araya getirmek. Aşağıda kopyalanacak bir şablon var.

Proxeon desteğine başvuru şablonu

Konu: [HEDEF]'e başvururken [KIMLIK] kimlikli proxy ile sorun

1. Proxy kimliği: [örn. PX-48213]
2. Proxy türü: [HTTP / HTTPS / SOCKS5]
3. Sorunun zamanı: [12.03.2026, 14:32, UTC+3]
4. Hedef adres: [https://api.example.com/v2/data]
5. Ne yaptım: [curl'den GET isteği gönderdim]
6. Bekledim: [200 kodu ve veri]
7. Aldım: [bağlantı hatası / yavaş yanıt / hata kodu]

Kontrollerin sonuçları:
- Bu proxy üzerinden başka site: [çalışıyor / çalışmıyor]
- Proxysiz doğrudan bağlantı: [çalışıyor / çalışmıyor]
- Aynı hedefe başka proxy: [çalışıyor / çalışmıyor / ikinci proxy yok]

Ortam:
- İşletim sistemi: [Windows 11]
- İstemci: [curl 8.6.0]
- Proxy yapılandırması: [curl'de -x bayrağı]
- Kurumsal filtre: [yok / var, 80 ve 443 portları]

Teşhis çıktısını (kullanıcı adı ve parola gizli) diag_clean.txt dosyasında ekliyorum.

Kısa sonuç: Kontrollerime göre sorun [istemci-proxy / proxy-sunucu] sınırında, çünkü [doğrudan bağlantı çalışıyor ama proxy üzerinden çalışmıyor].

Doğru şekilde nasıl doldurulur

  1. Şablonu mektubun veya kaydın gövdesine kopyalayın.
  2. Köşeli parantez içindeki her alanı kendi verinizle değiştirin.
  3. Temizlenmiş diag_clean.txt dosyasını ekleyin.
  4. Mektubu baştan sona bir kez daha okuyun: dışarıdan biri için anlaşılır mı?
  5. Gönderin.

İpucu: Sondaki "Kısa sonuç" satırı en faydalısıdır. Burada kontrollere dayanarak kendi hipotezinizi kurarsınız. Hipotez isabetsiz olsa bile mühendise düşünce akışınızı gösterir ve zaman kazandırır.

✅ Kontrol: Mektupta köşeli parantezli tek bir alan kalmadı — hepsi doldurulmuş. Temizlenmiş dosya eklenmiş. Hipotezli kısa sonuç var. Başvuru gönderime hazır.

Sonuç kontrolü: başvuru hazırlık kontrol listesi

Göndermeden önce kısa kontrol listesinden geçin. Hiçbir şeyi atlamadığınızı garanti eder.

  • Tanım değil, kesin proxy kimliği belirtilmiş.
  • Olayın saati açık saat dilimiyle var.
  • Tam hedef adres belirtilmiş.
  • Ne yaptığınız, ne beklediğiniz ve ne aldığınız açıklanmış.
  • Ayrıntılı moddaki tam curl çıktısı eklenmiş.
  • En az iki eleme kontrolü yapılmış ve açıklanmış.
  • İşletim sistemi, istemci ve sürümü belirtilmiş.
  • Loglardan parola ve tüm token'lar çıkarılmış.
  • Teşhis dosyası eklenmiş ve anlaşılır adlandırılmış.
  • Hipotezinizi içeren kısa sonuç var.

Tüm maddeler işaretliyse başvurunuz ilk yanıtta çözülenler arasındadır. Mühendisin hiçbir şeyi açıklığa kavuşturmasına gerek yok — elinde tam bir tablo var.

✅ Kontrol: Kontrol listesinin on maddesi de tamam. Başarının ölçüsü de budur: başvuru kendi kendine yeter.

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

Teşhis toplarken sık karşılaşılan sorunları ve giderme yollarını ele alalım.

Sorun 1: curl proxy'ye bağlanmadan hemen hata veriyor

Neden: proxy adres biçimi yanlış veya şemada yazım hatası var (socks5 yerine http veya tersi).

Çözüm: Proxeon panelindeki proxy türünü kontrol edin ve doğru şemayı yerleştirin. Portun doğru belirtildiğinden ve iki nokta üst üste ile ayrıldığından emin olun.

Sorun 2: proxy'de yetkilendirme hatası

Neden: kullanıcı adı veya parola yanlış ya da paroladaki özel karakterler kaçırılmamış.

Çözüm: kimlik bilgilerini yeniden kontrol edin. Parolada @, :, / gibi karakterler varsa satırı bozabilir. Bu durumda yetkilendirmeyi URL'ye gömmek yerine ayrı bir bayrakla

--proxy-user KULLANICI_ADI:PAROLA
iletin.

Sorun 3: betik Windows'ta çalışmıyor

Neden: PowerShell yürütme ilkesi yerel betikleri engelliyor.

Çözüm: PowerShell'i yönetici olarak çalıştırın ve geçerli oturum için RemoteSigned ilkesini süreç düzeyinde ayarlayan komutla yürütmeye izin verin. Verileri topladıktan sonra ilkeyi eski haline getirin.

Sorun 4: çıktıda ayrıntı yok, yalnızca özet satır var

Neden: ayrıntılı modu açan -v bayrağı unutulmuş.

Çözüm: curl'den hemen sonra -v ekleyin. Bağlantının satır satır akışını gösteren tam da bu bayraktır; o olmadan teşhis faydasızdır.

Sorun 5: parola yanlışlıkla gönderilen dosyada kalmış

Neden: temizleme dikkatsiz yapılmış, parola yalnızca komutta değil çıktı satırında da yer almış.

Çözüm: Proxeon panelinden proxy parolasını derhal değiştirin. Bundan sonra göndermeden önce temizlenmiş dosyada parolayı mutlaka arayın.

Sorun 6: sorun curl'de tekrarlanmıyor ama tarayıcıda var

Neden: tarayıcı başlık, cookie ekliyor ya da proxy'yi farklı bir yöntemle yapılandırıyor.

Çözüm: Başvuruda curl'de sorunun tekrarlanmadığını ama tarayıcıda olduğunu dürüstçe belirtin. Tarayıcının adını ve sürümünü, ayrıca tarayıcıdaki proxy yapılandırma yöntemini ekleyin. Bu da başlı başına teşhis bilgisidir.

Sorun 7: loglardaki saat sizinkiyle uyuşmuyor

Neden: yerel saati saat dilimi belirtmeden yazdınız, sunucu ise UTC'de çalışıyor.

Çözüm: dilimi her zaman açıkça belirtin. Emin değilseniz iki damgayı da ekleyin: yerel saatiniz ve bunun UTC karşılığı.

Ek olanaklar: ileri düzey teşhis

Temel set yetmiyorsa, daha derin analiz için birkaç araç var. İleri düzey kullanıcılara yararlı olacaktır.

Hız sorunları için ayrıntılı zamanlamalar

Proxy çalışıyor ama yavaşsa, zamanın hangi aşamada kaybolduğunu anlamak önemlidir. Genişletilmiş -w bayrağı dökümü gösterir.

curl -o /dev/null -s -w "dns:%{time_namelookup} connect:%{time_connect} tls:%{time_appconnect} ttfb:%{time_starttransfer} total:%{time_total}\n" -x http://KULLANICI_ADI:PAROLA@HOST:PORT https://HEDEF

Bu rakamlar ad çözümlemeye, bağlantı kurmaya, şifrelemeye ve ilk baytı almaya ne kadar gittiğini gösterir. ttfb büyükse gecikme hedef tarafındadır. connect büyükse sorun proxy'ye kadarki ağdadır.

Sorunun tekrarlanabilirliği

Sorun dalgalıysa bir dizi istek toplayın ve bir kısmının geçtiğini, bir kısmının geçmediğini gösterin. Yanıt kodlarını kaydeden basit birkaç istek döngüsü istatistik verecektir. Kararlılık veya yokluğu destek için önemli bir olgudur.

Birden fazla hedefi tek seferde kontrol etme

Üç-dört adreslik bir liste oluşturun ve bunları tek dizi halinde proxy üzerinden geçirin. Böylece sorunun tek bir hedefe özgü mü yoksa genel mi olduğunu hemen görürsünüz.

İpucu: İleri düzey verileri yalnızca temel teşhis yetmediyse ekleyin. Yapıdan yoksun aşırı bilgi, eksikliği kadar zararlıdır. Asgariden başlayın, mühendisin talebi üzerine derinleşin.

SSS: teşhis toplamayla ilgili sık sorulan sorular

Mutlaka curl mü kullanmalıyım?

Hayır ama curl en evrensel ve mühendis için en anlaşılır araçtır. Çıktısı tüm sistemlerde aynıdır. Koddaki bir kütüphane üzerinden çalışıyorsanız onun çıktısını da ekleyin, ama curl kontrolü yine bir referans olarak değerlidir.

Sorun geçtiyse ve tekrarlanmıyorsa ne yapmalıyım?

Hatırladığınız her şeyi kaydedin: yaklaşık saat, hedef, hatanın niteliği. Uygulamanızın o döneme ait loglarını ekleyin. Kesin saatli eksik veriler bile sunucudaki kaydı bulmaya yardımcı olur.

Hata açıklamadan anlaşılıyorsa logları eklemem gerekir mi?

Evet. Size apaçık görünen şeyin olgularla doğrulanması gerekir. Loglar tahminleri ortadan kaldırır ve tahmin yerine kesin yanıt verilmesini sağlar.

Destek kendisi kontrol etsin diye kullanıcı adı ve parolayı gönderebilir miyim?

Hayır. Gizli bilgiler yazışmada iletilmez. Proxeon desteğinin parola olmadan kimlik üzerinden hesabınıza erişimi vardır. Sunucu tarafındaki kontrol için kimlik yeterlidir.

Her şey doğru toplanmışsa yanıt ne kadar hızlı gelir?

Tam bir başvuru, açıklama döngüsünü ortadan kaldırdığı için çözüme kadar geçen süreyi kat kat kısaltır. Kesin süreler destek yoğunluğuna bağlıdır ama birkaç tur yazışmadan kesinlikle kaçınırsınız.

curl başarı gösteriyor ama uygulama yine de çalışmıyorsa?

Bu değerli bir olgudur: sorun proxy'nin kendisinde değil, uygulamanın onu kullanma biçimindedir. Bunu başvuruda belirtin, uygulamadaki proxy ayarlarını ve sürümünü ekleyin.

Hedef adres herkese açıksa da belirtmem gerekir mi?

Evet, mutlaka. Proxy'nin davranışı belirli bir hedefe bağlı olabilir. Adres olmadan mühendis tam olarak sizin durumunuzu yeniden oluşturamaz.

Portun benim mi yoksa başka bir portun mu gerektiğini nasıl anlarım?

Port, kontrol panelindeki proxy kartında belirtilmiştir. Farklı proxy türleri farklı portlar kullanır. Kontrol paneliyle karşılaştırın ve portu rastgele yerleştirmeyin.

Logları gizli bilgilerden temizlemeyi otomatikleştirebilir miyim?

Yazar Hakkında

Roman Melnikov

Roman Melnikov

Technical Writer and System Administrator

İş Deneyimi: Technical writer and DevOps engineer with 9 years of experience. Created over 50 detailed guides on system configuration and administration. His instructions helped thousands of professionals successfully solve technical tasks. Popular author on Habr and YouTube.
Eğitim: Bauman Moscow State Technical University. Information Systems and Technologies
Uzmanlık:
Technical Documentation DevOps System Administration Linux Docker and Kubernetes CI/CD Infrastructure Automation Cloud Technologies System Monitoring Bash and Python Scripting

Makaleyi paylaşın: