---
title: "HTTP 407 Proxy Authentication Required Hatası Nasıl Çözülür?"
description: "HTTP 407, proxy'nin isteği iletmeden önce kullanıcı adı ve şifre istediğini söyler. Eksik ya da yanlış kimlik, %40 kodlaması, Chrome ve NTLM için çözümler."
url: https://proxynet.io/tr/blog/http-407-proxy-authentication-required
date: 2026-10-07
author: "Acar Diveroli"
category: "Nasıl Yapılır, Proxy 101"
lang: tr
---

# 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.

> **Not: Kısa cevap**
>
> HTTP 407 Proxy Authentication Required (proxy kimlik doğrulaması gerekli), isteğinizi ileten proxy'nin sizden kullanıcı adı ve şifre istediği, istekte bu bilginin olmadığı ya da yanlış olduğu anlamına gelir. Hata hedef siteden değil, proxy'den gelir; cevapla birlikte gelen `Proxy-Authenticate: Basic realm="…"` header'ı hangi yöntemi beklediğini söyler. Çözüm, isteğe doğru `Proxy-Authorization` header'ını eklemektir: cURL'de `-U user:pass`, Python Requests'te `proxies={"https": "http://user:pass@host:port"}`, Node'da `ProxyAgent` ile `token`, Chrome ve Puppeteer'da ise adrese değil `page.authenticate()` çağrısına yazılır. Şifrede `@` gibi özel karakter varsa URL içinde `%40` diye kodlanır; IP yetkilendirmesi kullanıyorsanız panelde kayıtlı adresin bugünkü IP'niz olduğunu kontrol edin.

## 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](https://www.rfc-editor.org/rfc/rfc9110.html#section-15.5.8), 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ı:

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

```text
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.

| Neden | Belirti | Çözüm |
|---|---|---|
| Kimlik hiç gönderilmiyor | `Proxy-Authorization` satırı yok, ilk istekte 407 | Aracın proxy kimlik seçeneğini kullanın (`-U`, `proxies=`, `token`) |
| Kullanıcı adı ya da şifre yanlış | Header var, cevap yine 407 | Panelden kopyalayın; boşluk ve büyük-küçük harfe bakın |
| Şifrede `@`, `:`, `#` gibi karakter | URL "bad hostname" ya da 407 | URL içinde `%40`, `%3A`, `%23` diye kodlayın ya da ayrı seçenek kullanın |
| IP yetkilendirmesi, ev IP'si değişmiş | Dün çalışan ayar bugün 407 | Panelde yeni IP'yi ekleyin ya da kullanıcı adı ve şifreye geçin |
| Chrome adresteki `user:pass@` kısmını yok sayıyor | `ERR_NO_SUPPORTED_PROXIES` ya da kimlik penceresi | Puppeteer'da `page.authenticate()`, tarayıcıda pencereye girin |
| Kurumsal proxy NTLM ya da Kerberos istiyor | `Proxy-Authenticate: Negotiate` ya da `NTLM` | Alan adı hesabıyla `--proxy-negotiate`; cURL 8.20'den beri NTLM derlemede kapalı |
| Birden fazla proxy zinciri | Pencere tekrar tekrar açılıyor | Her proxy'nin kendi kimliğini ister; ağ yöneticisine sorun |

## 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](/tr/blog/proxy-authentication-methods) 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](https://proxynet.io/tr/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](https://curl.se/ch/8.20.0.html) (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](https://chromium.googlesource.com/chromium/src/+/HEAD/net/docs/proxy.md) 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:

```js
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.

```bash
# 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](/tr/blog/curl-proxy) 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.

```python
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](/tr/blog/python-requests-post-json) `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](https://undici.nodejs.org/#/docs/api/ProxyAgent) iki yolu da tanımlar ve adresteki kimliğin Base64'e çevrilmeden önce URL kodlamasından çözüldüğünü söyler.

```js
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.

```bash
# 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`.

| Araç | 407'yi nasıl gösterir | Kimliğin yeri |
|---|---|---|
| cURL | `CONNECT tunnel failed, response 407` | `-U user:pass` ya da adres |
| Python Requests | HTTPS'te `ProxyError`, HTTP'te `status_code == 407` | `proxies=` adresi ya da `HTTPProxyAuth` |
| Node undici | `fetch failed`, neden `cause` içinde | `ProxyAgent` `token` ya da `uri` |
| Chrome / Puppeteer | `ERR_INVALID_AUTH_CREDENTIALS`, pencere | `page.authenticate()` |
| Git | `The requested URL returned error: 407` | `http.proxy` adresi |
| pip | Yalnızca `-vvv` ile görünür | `--proxy` ya da `pip.conf` |

## 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](https://proxynet.io/tr/static-isp-residential-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

| Durumunuz | Ne yapmalı |
|---|---|
| `curl -v` çıktısında `Proxy-Authorization` yok | Kimliği `-U` ile ya da adrese ekleyin |
| Header var, yine 407 | Şifreyi panelden yeniden kopyalayın; sade `user:pass` ile deneyin |
| Şifrede `@`, `:` ya da `#` var | URL içinde `%40`, `%3A`, `%23`; ya da ayrı kimlik seçeneği |
| IP yetkilendirmesi, adres değişti | Panelde yeni IP; sık değişiyorsa kullanıcı adı ve şifreye geçin |
| Chrome ya da Puppeteer | `page.authenticate()`; bayrakta kimlik yok |
| Şirket ağı, `Proxy-Authenticate: Negotiate` | `--proxy-negotiate -U :` ya da alan hesabı; NTLM yerine Kerberos |
| Windows'ta pencere kapanmıyor | Credential Manager'daki eski şifreyi silin; zincir proxy için yöneticiye sorun |

## 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](/tr/proxy) göz atabilirsiniz.