Proxy Çalışmıyor: 407, Timeout ve Connection Refused Hataları Nasıl Çözülür?

Önce hatayı doğru katmana ayırın

Bir proxy bağlantısı dört temel aşamadan geçer: cihazınız proxy sunucusuna ulaşır, istemci gerekiyorsa kimlik doğrular, proxy hedef adres ve porta bağlanır, ardından uygulama verisi aktarılır. Aynı ekranda görünen “bağlantı başarısız” mesajı bu aşamaların herhangi birinde oluşabilir. Teşhisin ilk amacı hangi aşamanın başarısız olduğunu bulmaktır.

Proxy IP’sine ve portuna hiç ulaşılamıyorsa kullanıcı adı veya hedef siteyi tartışmak erkendir. Proxy portu erişilebilir fakat doğrulama reddediliyorsa ağ yolu çalışıyor, erişim bilgileri veya yetkilendirme modeli sorunludur. Kimlik doğrulama geçiyor fakat belirli bir hedef açılmıyorsa hedef port, sağlayıcının kural seti, DNS çözümü veya uzak sunucu incelenmelidir.

Bu katmanlı yaklaşım önemli bir alışkanlık kazandırır: aynı anda proxy, DNS, güvenlik duvarı ve uygulamayı değiştirmezsiniz. Her adımda tek değişken değiştirip sonucu kaydedersiniz. Böylece geçici bir düzelmeyi gerçek çözüm sanmaz, sorun tekrar ettiğinde hangi kanıtın nereden geldiğini bilirsiniz.

407 Proxy Authentication Required hatası

HTTP 407, hedef web sitesinin değil proxy sunucusunun kimlik doğrulama istediğini belirtir. RFC 9110’a göre proxy, istemciye Proxy-Authenticate başlığıyla bir doğrulama talebi gönderir; istemci uygun Proxy-Authorization bilgisiyle yanıt verir. Bu nedenle 407 hatasında web sitesi şifresini değil proxy kullanıcı adı, şifre ve doğrulama yöntemini kontrol etmelisiniz.

En sık neden kopyalama sırasında başa veya sona boşluk eklenmesi, eski şifrenin programda saklanması, HTTP proxy bilgisinin SOCKS alanına yazılması ya da sağlayıcının hem kullanıcı/şifre hem kaynak IP yetkilendirmesi kullanmasıdır. Aynı erişim bilgilerini farklı uygulamalarda deneyip kilitlemek yerine tek bir test istemcisiyle başlayın.

IP beyaz liste modeli kullanılıyorsa ev internetinizin dış IP’si değişmiş olabilir. Modem yeniden bağlandığında kaynak IP yenilendiyse sağlayıcı panelindeki yetki eski adreste kalır. Kullanıcı adı/şifre modelinde ise büyük-küçük harf, özel karakter ve URL içine yazılan bilgilerin doğru kodlanması önemlidir.

407 yalnızca HTTP proxy dünyasına ait bir durum kodudur. SOCKS5 istemcisi “authentication failed” veya “no acceptable methods” gibi farklı mesajlar gösterebilir. Hata metnini olduğu gibi kaydetmek, yanlış protokol için çözüm aramanızı engeller.

• Proxy türünü doğru seçin: HTTP(S) bilgisi SOCKS5 alanına yazılmamalı.
• Kullanıcı adı ve şifreyi elle yeniden girin; görünmez boşlukları temizleyin.
• Sağlayıcı IP beyaz listesi kullanıyorsa güncel dış IP’nizi tanımlayın.
• Aynı bilgiyi tek bir test uygulamasında doğrulayın.
• Başarısız denemeleri ve zamanı kaydedin; geçici blok ihtimalini destekle paylaşın.

SOCKS5 hata mesajları ne anlama gelir?

SOCKS5, HTTP durum kodlarından farklı bir cevap alanı kullanır. RFC 1928’de genel sunucu hatası, kural seti tarafından reddedilme, network unreachable, host unreachable, connection refused, TTL expired, komut desteklenmiyor ve adres türü desteklenmiyor gibi cevaplar tanımlanır. Kullandığınız program bu kodları sayıyla veya metinle gösterebilir.

Network unreachable proxy sunucusunun hedef ağa rota bulamadığını; host unreachable belirli hedefe ulaşılamadığını; connection refused ise hedefte ilgili bağlantının kabul edilmediğini anlatır. Bu üçü birbirinin aynısı değildir. Connection refused hızlı dönerken timeout genellikle belirli süre yanıt bekledikten sonra oluşur.

Command not supported mesajı, uygulamanın UDP ASSOCIATE gibi proxy’nin sunmadığı bir özellik istemesiyle görülebilir. Address type not supported ise IPv6, alan adı veya belirli adres biçimi desteğiyle ilgili olabilir. Programın “remote DNS” seçeneğini değiştirirken hangi adres türünü gönderdiğini bilmek gerekir.

Timeout ile connection refused arasındaki fark

Timeout, istemcinin belirlenen sürede beklediği yanıtı alamamasıdır. Paketler güvenlik duvarında sessizce düşüyor, yanlış IP’ye gidiyor, rota kopuk veya servis aşırı yoğun olabilir. Timeout süresini yükseltmek bazen yavaş ağı tolere eder fakat yanlış adres veya kapalı yolu düzeltmez. Önce proxy IP ve portunun erişilebilirliğini ölçün.

Connection refused, hedef makineye ulaşıldığını fakat ilgili portta bağlantının kabul edilmediğini gösterir. Servis çalışmıyor, farklı port dinliyor veya güvenlik politikası aktif biçimde reddediyor olabilir. Bu hata çoğu zaman timeout’tan daha hızlı döner. Proxy aboneliğiniz aktif olsa bile yanlış port yazmak aynı belirtiyi üretir.

Windows’ta TCP port kontrolü için Test-NetConnection kullanılabilir. Bu test proxy kimlik doğrulamasını veya hedefe aktarımı kanıtlamaz; yalnızca cihazınızdan proxy IP/portuna TCP bağlantısı kurulup kurulamadığını ayırır. TcpTestSucceeded false ise önce ağ/port katmanını çözün.

1. 1

   Portu sınayın

   TCP portuna erişim var mı kontrol edin. Başarısızsa kimlik doğrulamaya geçmeyin.

2. 2

   Farklı ağla karşılaştırın

   Mümkünse telefon hotspot’u gibi izinli ikinci bağlantıda aynı testi yapın.

3. 3

   Servis durumunu doğrulayın

   Paket süresi, bakım ve tanımlı kaynak IP bilgisini kontrol edin.

4. 4

   Hedefi ayrı test edin

   Proxy çalışıyor fakat tek hedef başarısızsa hedef adres/portu ve kural setini inceleyin.

DNS, alan adı ve IPv4/IPv6 kaynaklı sorunlar

Bir uygulama hedef alan adını cihazda çözüp proxy’ye IP gönderebilir veya alan adını doğrudan SOCKS5 sunucusuna iletebilir. İkinci davranış genellikle “remote DNS” ya da “proxy üzerinden DNS” olarak adlandırılır. Her uygulama ve proxy aynı yöntemi desteklemez. DNS sızıntısı kavramı da kullanılan uygulama ve protokole göre değerlendirilmelidir.

Alan adı cihazda çözülemiyorsa proxy sağlam olsa bile uygulama hedef IP’yi üretemez. Tersine yerel DNS çalışıyor fakat proxy’nin ağı belirli hedefe rota bulamıyorsa host unreachable görülebilir. Test için önce doğrudan alan adı çözümünü, ardından proxy aracının bağlantı günlüğündeki hedef biçimini kontrol edin.

IPv6 desteklemeyen bir proxy’ye IPv6 hedef gönderildiğinde address type not supported oluşabilir. Dual-stack sistemlerde uygulama önce IPv6 deneyip sonra IPv4’e düşebilir; bu geçiş gecikme veya tutarsız hata yaratabilir. Hedefin ve proxy’nin ortak desteklediği adres ailesini seçin, fakat sistemi rastgele IPv6 kapatarak değil ölçümle teşhis edin.

• Alan adı cihazda çözümleniyor mu?
• Araç hedefi alan adı mı IP olarak mı proxy’ye gönderiyor?
• Proxy IPv4, IPv6 ve remote DNS seçeneklerinden hangilerini destekliyor?
• Hata yalnızca bir alan adında mı, tüm hedeflerde mi?
• DNS değişikliği sonrası eski önbellek sonucu devam ediyor mu?

Uygulama yönlendirme kuralı ve güvenlik duvarı

Proxy test aracı başarılıyken gerçek uygulamanın IP’si değişmiyorsa en güçlü ihtimal yönlendirme kuralıdır. Masaüstü kısayolu bir işlem değildir; kısayolun açtığı gerçek .exe dosyasını belirlemek gerekir. Launcher başka bir oyun işlemi başlatıyorsa ikisi için ayrı kurallar gerekebilir.

Kural sırası da önemlidir. Genel “direct” kuralı uygulama kuralından önce eşleşirse trafik proxy’ye hiç ulaşmaz. Bazı programlar alt süreçleri otomatik kapsar, bazıları yalnızca seçilen dosyayı yönlendirir. Bağlantı günlüğünde işlem adı, hedef adres ve kullanılan kural birlikte görünmelidir.

Windows Güvenlik Duvarı veya üçüncü taraf güvenlik yazılımı yönlendirme aracını, yerel servis portunu ya da hedef bağlantıyı engelleyebilir. Sorunu çözmek için korumayı tamamen kapatmak yerine gerekli uygulama ve port için dar kapsamlı izin tanımlayın. Test sonunda gereksiz izinleri kaldırın.

Fail-open davranışı, proxy erişilemezken uygulamanın doğrudan internete çıkmasına izin verir. Hassas oturum eşlemesinde fail-closed yaklaşımı daha güvenlidir: proxy kuralı çalışmıyorsa uygulama bağlantısı durur. Kullandığınız aracın bu davranışı nasıl yönettiğini test edin.

10 dakikalık sistemli proxy teşhis akışı

Hızlı teşhis, çok ayar değiştirmek değil doğru sırayı izlemektir. Önce teslim bilgisini doğrulayın; sonra port erişimini, kimlik doğrulamayı, genel hedef bağlantısını ve son olarak gerçek uygulama kuralını test edin. Her adım bir öncekini kanıtlar. Başarısız katmanı atlayıp son adıma geçmek yalnızca belirsizliği artırır.

Test sırasında tek proxy, tek uygulama ve tek hedef kullanın. Aynı anda on bağlantı açmak rate limit, eşzamanlı oturum sınırı veya yerel kaynak kullanımını devreye sokar. Tek bağlantı başarılı olduktan sonra yükü kademeli artırın ve hangi seviyede sorun çıktığını kaydedin.

Geçici düzeltmeleri gerçek çözümden ayırın. Programı yeniden başlatınca sorun kayboluyorsa eski bağlantıların kapanmaması, DNS önbelleği veya uygulama durumu etkili olabilir. Tekrar üretme adımları olmadan yapılan değişim ileride aynı hatayı bırakır.

1. 1

   Teslim bilgisini karşılaştır

   IP, port, protokol, paket bitişi ve yetkilendirme modelini kontrol et.

2. 2

   TCP erişimini test et

   Proxy portuna bağlantı yoksa ağ ve servis katmanında kal.

3. 3

   Kimlik doğrulamayı sınay

   Tek test istemcisiyle kullanıcı adı/şifre veya IP yetkisini doğrula.

4. 4

   Genel hedef dene

   Bir hedef yerine tüm hedefler mi başarısız ayır.

5. 5

   Gerçek uygulamayı izle

   İşlem adı, kural ve çıkış IP’sini günlükte doğrula.

6. 6

   Yükü kademeli artır

   Tek bağlantıdan başlayıp sorun eşiğini kaydet.

Destek talebinde hangi bilgileri paylaşmalısınız?

İyi bir destek kaydı sorunun çözülmesini hızlandırır ve gereksiz şifre paylaşımını önler. “Çalışmıyor” yerine tarih-saat, hata metni, proxy türü, test edilen hedef ve başarısız aşamayı yazın. IP veya kullanıcı adının yalnızca gerekli bölümünü gösterin; şifreyi hiçbir zaman düz metinle göndermeyin.

Test-NetConnection sonucu, uygulama bağlantı günlüğü ve sorunun tek ağda mı tüm ağlarda mı olduğu önemli kanıtlardır. Ekran görüntüsünde hesap şifresi, lisans anahtarı, e-posta ve ödeme bilgilerini maskeleyin. Destek ekibinin isteğiyle yeni şifre oluşturmak gerekiyorsa eski erişimi iptal ettikten sonra güvenli kanaldan iletin.

Sorunun ne zaman başladığını ve öncesinde ne değiştiğini belirtin: modem yeniden bağlandı mı, Windows güncellendi mi, proxy IP’si değişti mi, yeni güvenlik yazılımı kuruldu mu? Bu zaman çizgisi arızayı uygulama, yerel ağ veya sağlayıcı tarafına ayırmada çok değerlidir.

• Tam hata mesajı ve tarih-saat
• Proxy türü ve port; şifre hariç maskeli hesap bilgisi
• Test-NetConnection sonucu
• Etkilenen uygulamanın gerçek işlem adı
• Sorunun tek hedefte mi tüm hedeflerde mi olduğu
• Son başarılı bağlantı zamanı ve yapılan son değişiklik