HTTP 407 Proxy Authentication Required Hatası Nasıl Çözülür?

Yeni aldığınız proxy'yi cURL'e yazıyorsunuz, cevap 407 Proxy Authentication Required. Aynı üç rakam Python'da Tunnel connection failed: 407 diye, Git'te The requested URL returned error: 407 diye, Chrome'da ise tekrar tekrar açılan bir kullanıcı adı penceresi olarak karşınıza çıkar. Hepsinin kaynağı aynıdır: isteğiniz hedef siteye hiç ulaşmamış, aradaki proxy onu kapıda durdurmuştur.

Bu yazıda 407'nin HTTP standardındaki anlamını, 401'den farkını ve kapıda neyin eksik olduğunu anlatıyoruz. Sonra hatanın çıktığı yerleri tek tek ele alıyoruz: satın alınan proxy'de yanlış ya da eksik kimlik, IP yetkilendirmesinde değişen ev adresi, şifredeki özel karakter, Chrome'un user:pass@ biçimini reddetmesi, kurumsal ağlardaki NTLM ve Kerberos proxy'leri ve cURL, Python, Node.js, npm, pip, Git ile Docker'da kimliğin nereye yazılacağı. Bütün kod örneklerini 7 Ekim 2026'da, kullanıcı adı ve şifre isteyen yerel bir test proxy'si üzerinden çalıştırdık; aktardığımız çıktılar bu testlerden.

HTTP 407 Proxy Authentication Required ne demek?#

407, proxy'nin "bu isteği iletmem için önce kim olduğunu kanıtla" demesidir. HTTP standardı RFC 9110, 15.5.8. bölümünde kodu şöyle tanımlar: 407, 401'e benzer, ancak istemcinin bu istek için bir proxy kullanabilmek amacıyla kendini doğrulaması gerektiğini bildirir. Proxy bu cevapla birlikte, kendisi için geçerli bir meydan okuma (challenge) içeren Proxy-Authenticate header'ı göndermek zorundadır; istemci de isteği yeni ya da düzeltilmiş bir Proxy-Authorization header'ıyla tekrarlayabilir.

Pratikte bu alışveriş iki header arasında geçer. Proxy Proxy-Authenticate: Basic realm="x" ile yöntemi söyler; en yaygın yöntem olan Basic'te istemci kullanıcı adı ile şifreyi user:pass biçiminde birleştirir, Base64 ile kodlar ve Proxy-Authorization: Basic dXNlcjpwYXNz header'ını ekler. Base64 şifreleme değildir; dXNlcjpwYXNz değerini çözen herkes user:pass metnini okur. Bu yüzden kimlik bilgisi, proxy'ye giden bağlantının güvenilir bir ağda ya da TLS altında olmasına güvenir.

Standardın bir ayrıntısı hata ayıklarken işe yarar: Proxy-Authorization, isteği alan ilk proxy tarafından tüketilir ve hedef siteye iletilmez. Proxy şifrenizi görür, girdiğiniz site görmez. Kurumsal ağda arka arkaya duran proxy'lerin her biri kendi kimliğini ister; 407'nin hangisinden geldiğini Proxy-Authenticate header'ındaki realm değeri söyler.

407 ile 401 arasındaki fark nedir?#

İki kod aynı mekanizmayı iki farklı tarafta çalıştırır. 401 Unauthorized, hedef sitenin kimlik istemesidir: cevapta WWW-Authenticate header'ı gelir, istemci Authorization header'ıyla cevap verir ve sorun sizinle site arasındadır. 407'de ise aynı diyalog proxy'yle geçer: Proxy-Authenticate ile Proxy-Authorization header'ları kullanılır ve hedef site isteği hiç görmemiştir.

Bu ayrım çözüm yolunu belirler. 401 alıyorsanız sitedeki hesabınıza, API anahtarınıza ya da token'ınıza bakarsınız. 407 alıyorsanız sitenin hiçbir ayarı işe yaramaz; proxy panelindeki kullanıcı adı, şifre, IP listesi ya da ağ yöneticinizin verdiği hesap sorunun olduğu yerdir. İkisini art arda da alabilirsiniz: önce proxy 407 ile geçilir, sonra site 401 döner.

407 adım adım nasıl oluşur?#

Hatanın akışını görmek için Node.js ile 40 satırlık bir test proxy'si yazdık. Proxy, Proxy-Authorization header'ı user:pass ile eşleşmeyen her isteğe 407 ve Proxy-Authenticate: Basic realm="x" döndürüyor, eşleşen isteği hedefe iletiyor; HTTPS için CONNECT tünelini de aynı kuralla açıyor ve her isteği kayda yazıyor. Kayıtlardaki sıra, HTTPS bir sayfa için şöyleydi:

1. İstemci, proxy'ye CONNECT site.com:443 gönderir; yani siteye bir tünel açmasını ister. http:// ile başlayan adreslerde ise isteğin kendisini (GET http://site.com/ …) gönderir.
2. İstekte Proxy-Authorization yoksa proxy tüneli açmaz, 407 Proxy Authentication Required ve Proxy-Authenticate: Basic realm="x" döner. Kayıtta bu satır CONNECT site.com:443 Proxy-Authorization: (yok) diye görünür.
3. İstemci header'ı ekleyip isteği tekrarlar: Proxy-Authorization: Basic dXNlcjpwYXNz. Pek çok araç bu adımı ilk istekte yapar; cURL -U verildiğinde 407'yi hiç beklemeden kimliği gönderir.
4. Proxy bilgiyi kontrol eder. Doğruysa tüneli açar ve 200 Connection Established döner; artık site ile istemci arasındaki TLS trafiği tünelden geçer. Yanlışsa 2. adımdaki cevabı tekrarlar; yanlış şifre ile eksik şifre proxy için aynı 407'dir.
5. Hedef site isteği ancak bu noktada görür ve kendi cevabını (200, 404, 401…) verir. Kayıtta hedefin gördüğü header'lar arasında Proxy-Authorization yoktur; proxy onu tüketmiştir.

cURL ile bu akışın ilk adımı tek komutla izlenebilir. Düz HTTP bir adres için kimliksiz istek şu cevabı aldı:

curl -i -x http://pr.proxynet.io:8000 http://example.com/

HTTP/1.1 407 Proxy Authentication Required
Proxy-Authenticate: Basic realm="x"
Connection: close

HTTPS adreste ise cevap gövdesi görünmez; cURL tüneli açamadığını kendi hatasıyla söyler: curl: (56) CONNECT tunnel failed, response 407. İki durum da aynı eksikliktir.

407 hatası neden çıkar?#

Nedenler iki gruba ayrılır: satın aldığınız bir proxy'nin kimliği ile çalıştığınız ağın kendi proxy'sinin kimliği. İkisinde de hata metni aynıdır, çözüm yeri farklıdır.

Satın alınan proxy'de 407 nasıl çözülür?#

Çoğu 407, panelden kopyalanan bilgiyle aracın beklediği biçim arasındaki küçük bir farktan çıkar. Önce kimliğin hiç gönderilip gönderilmediğine bakın: curl -v çıktısında > Proxy-Authorization: satırı yoksa araç bilgiyi göndermiyordur ve sorun biçimdedir. Satır var ama cevap 407 ise bilgi yanlıştır ya da hesapta bir sorun vardır; yanlış şifreyle yaptığımız testte proxy, kimliksiz istekle aynı cevabı verdi.

Özel karakterler. Proxy adresi http://user:pass@host:port biçiminde bir URL'dir ve URL'de @ işareti kullanıcı bilgisiyle sunucu adını ayırır. Şifreniz p@ss ise http://user:p@ss@host:port iki @ içerir; cURL 8.5 bunu curl: (5) Unsupported proxy syntax … Bad hostname diye reddetti. Şifredeki @ yerine %40 yazınca (http://user:p%40ss@host:port) proxy user:p@ss olarak çözdü ve istek geçti. : için %3A, # için %23, / için %2F kullanılır. Python Requests aynı adresi kodlamadan da kabul etti, çünkü URL'yi son @ işaretinden böldü; ama buna güvenmek yerine kodlamak her araçta aynı sonucu verir. Kimliği URL'nin dışında veren seçeneklerde (curl -U "user:p@ss", Requests'te HTTPProxyAuth("user", "p@ss")) kodlamaya gerek yoktur; testte ikisi de ham şifreyle geçti.

IP yetkilendirmesi. Panelde şifre yerine IP adresinizi kaydettiyseniz proxy, bağlantının geldiği adrese bakar. Ev internetinde modem yeniden başladığında ya da operatör adres havuzunu değiştirdiğinde dış IP'niz değişir ve dün çalışan ayar bugün 407 döner. Önce bugünkü IP'nizi bir "IP'm ne" sayfasından öğrenip panelde kayıtlı adresle karşılaştırın. Adresi sık değişen bir bağlantıdan çalışıyorsanız kullanıcı adı ve şifre yöntemi daha az sürprizlidir; iki yöntemin karşılaştırması proxy kimlik doğrulama yazımızda var.

Oturum ekleri. Sticky oturum ya da ülke seçimi için kullanıcı adına eklenen user-session-abc-country-tr gibi parametreler de kullanıcı adının parçasıdır; yazım hatası ya da desteklenmeyen bir parametre bazı sağlayıcılarda 407 olarak döner. Önce sade user:pass ile deneyin, geçerse ekleri tek tek geri koyun. Bir Residential Proxy paketinde bu ekler oturum süresini ve çıkış ülkesini belirler, bu yüzden hatanın parametreden mi şifreden mi geldiğini ayırmak zaman kazandırır.

Kurumsal ağ proxy'sinde 407 nasıl çözülür?#

Şirket ya da üniversite ağında proxy'yi siz kurmadınız; işletim sistemi onu otomatik yapılandırma dosyasından (PAC) ya da grup ilkesinden alır ve kimlik genellikle alan adı hesabınızdır. Bu proxy'ler Basic yerine çoğu zaman Proxy-Authenticate: Negotiate (Kerberos) ya da NTLM ister. Tarayıcı ve Office gibi uygulamalar oturum açtığınız Windows hesabını kullanıp bunu sessizce geçer; komut satırı araçları ve betikler ise geçmez, 407 döner.

cURL'de yöntem seçilebilir: --proxy-negotiate -U : Kerberos için oturumdaki kimliği kullanır, --proxy-anyauth ise proxy'nin sunduğu yöntemlerden uygun olanı seçer. Testte --proxy-anyauth ile cURL önce kimliksiz istek gönderdi, 407 ve Proxy-Authenticate: Basic cevabını okudu, sonra Basic ile tekrarladı; yani bir tur fazladan gider ama hangi yöntemin beklendiğini bilmediğinizde işe yarar. NTLM ayrı bir durumdur. cURL projesi, 8.20.0 sürümünden (29 Nisan 2026) beri NTLM'yi derlemede varsayılan olarak kapatıyor ve tamamen kaldırmayı planlıyor; gerekçe olarak yöntemin zayıf kriptografisini, HTTP/2 ve HTTP/3 ile çalışmamasını ve Microsoft'un kendisinin de NTLM'yi kullanımdan kaldırmasını gösteriyor. Yani 8.20 ve sonrasındaki bir cURL ile --proxy-ntlm çoğu dağıtımda artık çalışmaz; proxy yalnızca NTLM kabul ediyorsa Negotiate'in açılmasını ağ yöneticisinden istemek gerekir. Elimizdeki cURL 8.5 ise --proxy-ntlm ile NTLM'nin ilk mesajını gönderdi; yalnızca Basic kabul eden test proxy'miz buna yine 407 döndü.

Windows'ta tekrar tekrar açılan pencere. Windows'un proxy ayarları yalnızca adresi tutar, kullanıcı adı ve şifreyi tutmaz; kimliği her uygulama 407 aldığında kendisi sorar. Pencere kapatılıp hemen yeniden açılıyorsa girilen bilgi reddedilmiştir: Şifre yakın zamanda değiştiyse Windows Kimlik Bilgisi Yöneticisi'nde (Credential Manager) saklanan eski şifre denenmeye devam eder, eskisini silmek gerekir. Microsoft'un eski bir destek notu bir başka nedeni anlatır: NTLM isteyen birden fazla proxy arka arkaya duruyorsa ilk proxy geçilir, ikincisi 407 döner ve pencere yeniden açılır; çözüm olarak Negotiate ile Kerberos'un açılması önerilir. Bu durum sizin değil, ağ yöneticisinin çözeceği bir yapılandırmadır.

Chrome ve Puppeteer 407'yi neden farklı gösterir?#

Chrome, proxy adresinde yazan kullanıcı adı ve şifreyi kullanmaz. Chromium'un proxy belgesi bunu açıkça yazar: Tarayıcı proxy ayarlarına gömülü kimlik bilgilerini uygulamaz, kimlik doğrulama her zaman olağan akıştan, yani 407 cevabından sonra açılan pencereden geçer. HTTP proxy'ler için Basic, Digest, Negotiate ve NTLM desteklenir; SOCKS5 için ise hiçbir kimlik doğrulama yöntemi yoktur. Bu yüzden user:pass@ biçimini --proxy-server bayrağına yazmak işe yaramaz. Puppeteer yazımız için 6 Ekim'de Chrome 154 ile yaptığımız testte Chrome bu değeri tümüyle reddetti ve net::ERR_NO_SUPPORTED_PROXIES verdi; kimlik hiçbir yere yazılmayınca da ilk gezinme net::ERR_INVALID_AUTH_CREDENTIALS ile düştü. 407 bu sürümde kullanıcıya hiç görünmez, Chrome onu kendi hata koduna çevirir.

Çözüm, kimliği tarayıcının 407'ye vereceği cevaba yazmaktır. Puppeteer'da bu page.authenticate() çağrısıdır ve ilk page.goto() çağrısından önce gelmelidir:

import puppeteer from "puppeteer";

const browser = await puppeteer.launch({
  args: ["--proxy-server=http://pr.proxynet.io:8000"], // adreste kimlik yok
});
const page = await browser.newPage();
await page.authenticate({ username: "user", password: "pass" }); // 407'ye verilecek cevap
await page.goto("https://httpbin.org/ip");

Puppeteer'ın belgesine göre bu çağrı arka planda istek yakalamayı (request interception) açar ve null verildiğinde kapanır. Kimlik sayfaya değil browser context'e aittir; aynı context'teki bütün sayfalar ilk girilen bilgiyi kullanır. Elle kullanılan Chrome'da kimliği 407 sonrası açılan pencereye girersiniz.

Araçlarda proxy kimliği nasıl verilir?#

Her aracın kimliği aldığı yer farklıdır. Örneklerin tamamını yerel test proxy'si üzerinden çalıştırdık; adresi yazıda pr.proxynet.io:8000, kimliği user:pass olarak gösteriyoruz.

cURL. Kimlik ya adrese ya da ayrı seçeneğe yazılır; -U ile --proxy-user aynı şeydir. cURL varsayılan olarak Basic kullanır ve kimliği ilk istekte gönderir, 407'yi beklemez.

# kimlik ayrı seçenekte: özel karakter için kodlama gerekmez
curl -x http://pr.proxynet.io:8000 -U user:pass https://httpbin.org/ip

# kimlik adreste: @ yerine %40, : yerine %3A
curl -x http://user:p%40ss@pr.proxynet.io:8000 https://httpbin.org/ip

# proxy'nin hangi yöntemi beklediğini -v ile görün
curl -v -x http://pr.proxynet.io:8000 https://httpbin.org/ip 2>&1 | grep -i proxy-auth

Ortam değişkeniyle de aynı adres kullanılır: export HTTPS_PROXY=http://user:pass@pr.proxynet.io:8000. Düz HTTP adresler için HTTP_PROXY, atlanacak alan adları için NO_PROXY okunur. cURL'ün diğer proxy seçenekleri cURL ile proxy kullanımı yazımızda anlatılıyor.

Python Requests. Kimlik proxies sözlüğündeki adrese yazılır ya da HTTPProxyAuth ile Proxy-Authorization header'ı olarak eklenir. Requests'in belgesi, Basic kimlik için http://user:password@host/ biçimini tanımlar ve kullanıcı adı ile şifreyi ortam değişkeninde ya da sürüm kontrolündeki bir dosyada saklamanın güvenlik riski olduğunu söyler.

import requests
from requests.auth import HTTPProxyAuth

PROXY = "http://user:pass@pr.proxynet.io:8000"
proxies = {"http": PROXY, "https": PROXY}

r = requests.get("https://httpbin.org/ip", proxies=proxies, timeout=15)
print(r.status_code, r.json())

# kimliği adresten ayrı vermek için: şifrede özel karakter varsa kodlama gerekmez
auth = HTTPProxyAuth("user", "pass")
r = requests.get("https://httpbin.org/ip", proxies={"https": "http://pr.proxynet.io:8000"}, auth=auth, timeout=15)

Requests 2.34 ile yaptığımız testte iki yol da proxy'den geçti. Hata biçimi hedefe göre değişiyor: HTTPS adreste kimliksiz istek requests.exceptions.ProxyError fırlattı ve mesajın içinde Tunnel connection failed: 407 Proxy Authentication Required yazıyordu; düz HTTP adreste ise istisna yoktu, r.status_code 407 döndü ve r.headers["Proxy-Authenticate"] proxy'nin challenge'ını taşıyordu. Yalnızca istisnaları yakalayan bir betik HTTP adreslerde 407'yi sessizce kaçırır; r.status_code == 407 kontrolü gerekir. HTTPProxyAuth yalnızca Proxy-Authorization header'ını ekler; hedef sitenin kendi kimliği için auth= yerine HTTPBasicAuth kullanılır. Bir dizi POST isteğini aynı oturumdan geçirmek için Requests ile POST ve JSON yazımızdaki Session kurulumuna proxies eklemek yeterlidir.

Node.js ve undici. Node'un yerleşik fetch çağrısı, undici kütüphanesinin ProxyAgent sınıfıyla proxy'den geçer. Kimlik uri içinde ya da token seçeneğinde hazır bir header değeri olarak verilir; undici'nin ProxyAgent belgesi iki yolu da tanımlar ve adresteki kimliğin Base64'e çevrilmeden önce URL kodlamasından çözüldüğünü söyler.

import { fetch, ProxyAgent } from "undici";

const agent = new ProxyAgent({
  uri: "http://pr.proxynet.io:8000",
  token: `Basic ${Buffer.from("user:pass").toString("base64")}`, // Proxy-Authorization değeri
});

const res = await fetch("https://httpbin.org/ip", { dispatcher: agent });
console.log(res.status, await res.json());

undici 8.10 ile testte token ve uri içindeki user:p%40ss biçimi aynı sonucu verdi. Kimliksiz istek ise TypeError: fetch failed ile düştü; asıl neden error.cause içinde InvalidArgumentError: Proxy Authentication Required (407) olarak duruyordu, HTTPS adreste ise yalnızca Request was cancelled. yazıyordu. Hata ayıklarken cause alanına bakmadan 407'yi görmek mümkün değil. Node'un ortam değişkenlerini kendiliğinden okumadığını da ekleyelim: HTTPS_PROXY tanımlı olsa bile fetch doğrudan bağlanır; Node 22.21 ve 24.0 ile gelen NODE_USE_ENV_PROXY=1 değişkeni bu davranışı açar ve testte deneysel uyarısıyla çalıştı.

npm, pip, Git ve Docker. Dört araç da aynı adres biçimini kabul eder; kimlik adresin içine yazılır.

# npm: kalıcı ayar (HTTPS_PROXY ortam değişkeni de okunur)
npm config set proxy http://user:pass@pr.proxynet.io:8000
npm config set https-proxy http://user:pass@pr.proxynet.io:8000

# pip: tek komut için --proxy, kalıcı için pip.conf içinde proxy =
pip install --proxy http://user:pass@pr.proxynet.io:8000 requests

# Git: biçim [protocol://][user[:password]@]proxyhost[:port]
git config --global http.proxy http://user:pass@pr.proxynet.io:8000
git config --global http.proxyAuthMethod basic   # anyauth, basic, digest, negotiate, ntlm

Docker istemcisi için ayar ~/.docker/config.json dosyasındaki proxies.default nesnesine (httpProxy, httpsProxy, noProxy) yazılır; Docker belgesi bu değerlerin konteyner yapılandırmasında düz metin olarak saklandığını ve uzak API'den okunabildiğini hatırlatır. Testte Git kimliksiz istekte fatal: unable to access '…': The requested URL returned error: 407 dedi ve kimlikli adresle geçti. pip ise varsayılan çıktıda 407'yi hiç göstermedi, yalnızca Could not find a version that satisfies the requirement yazdı; asıl neden pip -vvv ile göründü: 407 Client Error: Proxy Authentication Required.

Sabit IP ile 407 nasıl önlenir?#

IP yetkilendirmesinde 407'nin en sık nedeni adresinizin değişmesidir. Bulut sunucusu ya da ofis hattı gibi sabit bir dış IP'den çalışıyorsanız listeyi bir kez doldurursunuz ve kodda şifre taşımazsınız. Ev bağlantısından ya da farklı ağlardan bağlanıyorsanız kullanıcı adı ve şifre yöntemi daha az kesinti çıkarır.

Proxy'nin kendi tarafında da sabitlik önemlidir. Bir ISP Proxy paketinde çıkış IP'si değişmez; hedef sitenin ya da kurumsal bir sistemin izin listesine tek bir adres yazılır ve o uçta da kimlik sorunu yaşanmaz.

Sık yapılan hatalar#

• Hatayı sitede aramak. 407 hedef siteye hiç ulaşmayan bir istektir; sitenin hesabı, çerezi ya da API anahtarı sonucu değiştirmez.
• Şifreyi kodlamadan URL'ye yazmak. @ içeren şifre adresi bozar; %40 kullanın ya da kimliği ayrı seçenekle verin.
• Chrome bayrağına user:pass@ yazmak. Chromium bunu kullanmaz; Puppeteer'da page.authenticate(), elle kullanımda pencere.
• Yalnızca istisna yakalamak. Requests düz HTTP adreste istisna fırlatmaz, 407'li bir cevap nesnesi döner; durum kodunu kontrol edin.
• Eski IP'ye güvenmek. IP yetkilendirmesinde dün çalışan ayar bugünkü adresinizle eşleşmeyebilir.
• Kimliği betiğe ya da depoya yazmak. Hem Requests hem Docker belgeleri bunu risk sayar; ortam değişkenini oturum için tanımlayın, gizli anahtar yöneticisi kullanın, komut geçmişini temizleyin.
• cURL 8.20 sonrası NTLM beklemek. NTLM derlemede kapalı; kurumsal proxy'de Negotiate (Kerberos) isteyin.

Karar rehberi#

Sıkça sorulan sorular#

HTTP 407 hatası ne anlama gelir?#

Proxy'nin isteğinizi iletmeden önce kimlik istediği, istekte kimliğin olmadığı ya da yanlış olduğu anlamına gelir. Cevapla gelen Proxy-Authenticate header'ı beklenen yöntemi söyler; çözüm Proxy-Authorization header'ını doğru değerle eklemektir.

407 ile 401 arasındaki fark nedir?#

401'de kimliği hedef site ister ve WWW-Authenticate ile Authorization header'ları kullanılır; 407'de kimliği aradaki proxy ister ve Proxy-Authenticate ile Proxy-Authorization kullanılır. 407 alan istek siteye hiç ulaşmamıştır.

Proxy şifrem doğru olduğu hâlde neden 407 alıyorum?#

En sık üç neden: Şifredeki özel karakter URL'de kodlanmamıştır, kimlik adrese yazıldığı hâlde araç onu okumuyordur (Chrome böyle çalışır) ya da hesap IP yetkilendirmesi modundadır ve bugünkü adresiniz listede yoktur. curl -v ile Proxy-Authorization satırının gidip gitmediğine bakın.

Şifrede @ işareti varsa proxy adresine nasıl yazılır?#

@ yerine %40 yazılır: http://user:p%40ss@host:port. Aynı mantıkla : için %3A, # için %23 kullanılır. cURL'de -U "user:p@ss" ve Requests'te HTTPProxyAuth("user", "p@ss") gibi ayrı seçeneklerde kodlama gerekmez.

Chrome'da proxy kullanıcı adı ve şifresi nereye girilir?#

Chrome proxy ayarında kullanıcı adı alanı yoktur ve adresteki user:pass@ kısmını kullanmaz. İlk istekte 407 gelince açılan pencereye bilgileri girersiniz; Puppeteer gibi otomasyon araçlarında ise page.authenticate({ username, password }) çağrısı bu pencerenin yerini alır.

Şirket proxy'sinde 407 alıyorum, ne yapmalıyım?#

Proxy büyük olasılıkla NTLM ya da Kerberos (Negotiate) istiyordur ve alan adı hesabınızı bekler. cURL'de --proxy-negotiate -U : deneyin; cURL 8.20 ve sonrasında NTLM derlemede kapalı olduğundan, yalnızca NTLM kabul eden proxy için ağ yöneticisinden Negotiate'in açılmasını isteyin.

Özet#

HTTP 407 Proxy Authentication Required, isteğinizi ileten proxy'nin kimlik istediğini söyler; hedef site olanlardan habersizdir. Çözüm her araçta aynı header'ı doğru değerle göndermektir: cURL'de -U, Requests'te proxies= adresi ya da HTTPProxyAuth, undici'de token, Puppeteer'da page.authenticate(), npm, pip, Git ve Docker'da http://user:pass@host:port adresi. Şifredeki @ URL'de %40 olur, IP yetkilendirmesinde bugünkü adresinizin listede olması gerekir, kurumsal ağda ise Basic yerine Negotiate konuşulur ve cURL 8.20'den beri NTLM derlemede kapalıdır. Kullanıcı adı ve şifre ya da IP listesiyle çalışan paketler için proxy hizmetlerimize göz atabilirsiniz.