Profile özel proxy: DNS, kimlik doğrulama ve hata durumları

Bu rehber, referans olarak Chromium’un belgelenmiş ağ davranışını kullanır. Diğer tarayıcılar ve ürünler farklı tercihler yapabilir; tarayıcı yöneticisi Chromium’un çevresine yerel ağ aracısı ekleyebilir. Kullandığınız tam derlemenin davranışını doğrulayın.

Birbirinden bağımsız dört soruyla başlayın

Proxy kaydı genellikle şema, uç nokta, bağlantı noktası ve bazen kimlik doğrulama referansı içerir. Bu kayıt dört ayrı politika sorusunu açık bırakır:

1. Kapsam: Hangi tarayıcı istekleri ve protokolleri bu proxy’ye atanır?
2. Ad çözümleme: Hedef ana makine adını cihaz mı, proxy mi çözümler?
3. Kimlik doğrulama: Hangi istemci ve proxy şemaları birlikte çalışır; kimlik bilgileri nerede saklanır?
4. Hata: Bağlantı hatası isteği durdurur mu, başka proxy dener mi, doğrudan yola mı döner?

Bunları tek “proxy açık” anahtarı saymak çoğu sürprizin nedenidir. Chromium proxy seçimini URL düzeyinde çözümleme olarak belgeler: hedefin çözümlenmesi gerekmeksizin önce URL’den sıralı proxy seçenekleri üretilir. İstisna ve alternatif yol kuralları bu kararın parçasıdır.

Profile özel proxy neleri kapsar?

Google’ın ProxySettings politikası, Chrome profili düzeyinde uygulanır. Açık istisna ve PAC zorunluluğu alanlarıyla doğrudan, sistem, otomatik algılama, sabit sunucu veya PAC betiği modlarını seçebilir.

Bu sınır VPN’den veya işletim sistemi ağ ad alanından daha dardır. Tarayıcı ağ bağlamının işlediği istekleri yönetir. Şunları kendiliğinden yönetmez:

• masaüstü yöneticisinin kendi API çağrılarını;
• ayrı süreçteki uygulamayı veya tarayıcı güncelleyicisini;
• işletim sistemi DNS ve bağlantı kontrollerini;
• indirilmiş dosyadan başlatılan başka uygulamayı;
• uzantının ayrı yerel yardımcısını;
• örtük geri döngü istisnalarıyla erişilen yerel hizmetleri;
• seçili proxy yolunun taşıyamadığı protokol trafiğini.

Bu bileşenlerin bazıları kendi proxy desteğine sahip olabilir. Bu destek ayrı tanımlanıp test edilmelidir. “Profil trafiği bu proxy’yi kullanır” gibi ürün ifadesi, cihaz genelinde yönlendirme ima etmek yerine kapsanan süreçleri ve protokolleri belirtmeli.

Bir HTTPS isteğini izleyin

Normal HTTPS gezinmesinin yolu birkaç adımdan oluşur.

1. Yolu seçin

Tarayıcı sabit kuralları, proxy otomatik yapılandırma betiğini veya sistem ayarlarını değerlendirir. İstisna eşleşmesi doğrudan bağlantı seçebilir. Proxy listesi birincil proxy’yi ve ardından alternatifleri seçebilir; doğrudan dönüşe izin varsa DIRECT de bulunabilir.

Chromium, localhost ve yerel bağlantı hedefleri için örtük istisnalar da uygular. Bu, yerel kökenleri dışarıdan kontrol edilen proxy ayarlarından korur; ancak geniş “bütün trafik” ifadesinin sınırlandırılması gerektiği anlamına gelir.

2. Proxy’yi çözümleyip ulaşın

Proxy uç noktası ana makine adıysa cihaz bu adı çözümlemek ve uç noktaya bağlanmak için yine bir yola ihtiyaç duyar. Hedef DNS’in uzakta çözülmesi, bu başlangıç sorgusunu ortadan kaldırmaz. Buradaki hata, proxy’ye erişilebildiği ama proxy’nin hedefi çözümleyemediği durumdan farklıdır.

3. Proxy’de kimlik doğrulayın

Kimlik bilgisi isteyen HTTP proxy normalde bir doğrulama istemiyle 407 Proxy Authentication Required döndürür. RFC 9110, bu alışverişi ve Proxy-Authenticate ile Proxy-Authorization alanlarını tanımlar.

Chromium, elle girilen proxy ayarlarına gömülmüş kullanıcı adı ve parolayı kullanmaz. Proxy belgeleri, doğrulamanın tarayıcının normal kimlik bilgisi akışını izlediğini belirtir. Bu yüzden profil yöneticisi, herhangi bir user:password@host metninin çalışacağını vaat etmek yerine desteklenen doğrulama istemi için açık entegrasyon sağlamalı.

4. Hedef bağlantısını kurun

HTTP proxy ile Chromium hedef ad çözümlemesini proxy’ye bırakır. HTTPS hedefinde tarayıcı proxy’den CONNECT tüneli oluşturmasını ister; sonra bu tünelden hedefle uçtan uca TLS kurar.

Proxy, hedef ana makine adını ve bağlantı meta verisini yine öğrenir. İstemci-proxy bağlantısı düz HTTP kullanıyorsa CONNECT isteği ve ana makine adı bu bölümde korunmaz. HTTPS proxy, tarayıcı ile proxy arasına TLS ekleyerek meta veriyi aradaki gözlemcilerden korur. Proxy’nin kendisinin istenen hedefi görmesini engellemez.

Proxy normalde tünelde taşınan HTTPS sayfa içeriğini okuyamaz. TLS araya girme, istemcinin aracının TLS’yi sonlandırıp yeniden kurmasına izin veren sertifika otoritesine güvendiği farklı modeldir. Sıradan iletimle sessizce aynı şey gibi sunulmamalıdır.

DNS sorumluluğu proxy şemasına göre değişir

Chromium’un belgelenmiş davranışı proxy türüne göre farklıdır:

Seçili yol	Chromium’da hedef ad çözümleme	Önemli sınır
Doğrudan veya istisna	Cihaz ya da tarayıcı çözümleyicisi	Hedef trafiği profil proxy’si olmadan çıkar
HTTP proxy	Proxy tarafı	Düz HTTP istemci-proxy aktarımı HTTP isteklerini açığa çıkarır; HTTPS CONNECT kullanır
HTTPS proxy	Proxy tarafı	İstemci proxy’nin TLS sertifikasını doğrulamalı
SOCKS4 proxy	İstemci tarafı	Yalnızca IPv4 hedef; Chromium SOCKS4a alternatifini uygulamaz
SOCKS5 proxy	Proxy tarafı	Chromium TCP URL isteklerinde kullanır ve SOCKS5 kimlik doğrulama desteği olmadığını belgeler

RFC 1928, SOCKS5 isteğinin alan adı taşımasına izin verir ve birkaç kimlik doğrulama yöntemi kimliği tanımlar. Protokol yeteneği, istemci uygulaması garantisi değildir. Chromium güncel olarak hedef adlarını SOCKS5 proxy’ye gönderir; ancak yerleşik SOCKS5 istemcisinin hiçbir proxy kimlik doğrulama yöntemini desteklemediğini belirtir. Kullanıcı adı-parolalı SOCKS5 sunan sağlayıcı bu yüzden desteklenen aracı veya başka proxy şeması gerektirebilir. Kaydı kabul etmeden tarayıcı uygulamasını doğrulayın.

HTTPS üzerinden DNS başka katman ekler. Chrome’un DnsOverHttpsMode politikası, güvensiz DNS’e dönebilen automatic ile güvenli DNS başarısız olduğunda çözümlemeyi başarısız kılan secure modunu ayırır. Aynı politika tarayıcı düzeyinde, ProxySettings ise profil düzeyinde belgelenmiştir. Bu fark yararlı uyarıdır: bir ayarda “profil” yazması bütün DNS kontrollerinin aynı kapsamda olduğunu göstermez.

Her profili ayrı tarayıcı sürecinde çalıştıran ürün, fiilen daha dar sınır oluşturabilir; ancak bu bir uygulama tercihidir. Test edin. Kanıtlar şunları ayırmalı:

• proxy uç noktasının çözümlenmesi;
• istenen hedefin çözümlenmesi;
• doğrudan veya istisnalı isteklerin DNS’i;
• güvenli DNS başlangıcı ve alternatif davranışı;
• profilin tarayıcı ağ bağlamı dışındaki bileşenlerin DNS’i.

Kimlik doğrulama hem uyumluluk hem sır yönetimi sorunudur

Chromium HTTP proxy’leri için Basic, Digest, Negotiate ve NTLM belgeler. HTTPS proxy’leri korumalı istemci-proxy kanalı ekler ve istemci sertifikalarını da destekleyebilir. SOCKS5 standardında doğrulama yöntemleri bulunsa da Chromium’un yerleşik proxy istemcisi SOCKS4 veya SOCKS5 kimlik doğrulamasını uygulamaz.

Uyumlu şema bile yanlış aktarımda güvenli olmayabilir. RFC 7617, Basic kimlik bilgilerinin yalnızca Base64 kodlandığını ve TLS gibi korumalı kanal gerektirdiğini açıklar. Düz HTTP proxy’de Basic kullanmak, proxy parolasını bu bağlantıyı gözlemleyebilen herkese açar.

Profil yöneticisi şu verileri ayrı tutmalı:

• şema, ana makine, bağlantı noktası ve sağlayıcı etiketi gibi sır olmayan uç nokta meta verileri;
• yaşam döngüsü veya ağ hizmetinin kullandığı sır referansı;
• korumalı depodaki kimlik bilgisi değeri;
• arayüz ve denetim izi için hassas bilgileri gizlenmiş bağlantı durumu;
• yalnızca kontrollü destek akışından erişilen tanılama ayrıntıları.

Normal ekranlar, günlükler, API’ler, dışa aktarımlar ve otomasyon çıktısı proxy parolasına ihtiyaç duymaz. Kullanıcının genellikle doğrulamanın başarısız olduğunu, hangi şemanın istendiğini, hangi uç noktanın etkilendiğini ve alternatif yola geçilip geçilmediğini bilmesi yeterlidir.

Hata durumları nasıl görünür?

Hata	Olası belirti	Doğrulanacak sınır
Yanlış proxy şeması	TLS veya protokol el sıkışması başarısız	HTTPS uç noktası HTTP olarak mı, tersi mi tanımlandı?
Proxy adı çözümlenemiyor	Proxy’ye ulaşmadan bağlantı başarısız	Başlangıç sorgusunu hangi çözümleyici yaptı?
Proxy bağlantı noktası erişilemiyor	Zaman aşımı veya bağlantı reddi	Listede sırada başka proxy veya DIRECT var mı?
İstenen doğrulama desteklenmiyor	Tekrarlanan 407 veya giriş istemi	Tarayıcı istenen şemayı uyguluyor mu?
Kimlik bilgisi yanlış veya süresi dolmuş	Kimlik bilgisi sonrası 407	Sır referansı çözüldü mü; değer çıktıdan gizlendi mi?
HTTPS proxy sertifikası hatalı	Proxy’ye güvenli bağlantı reddedilir	Sertifika doğrulaması korunuyor mu?
Proxy hedefi çözümleyemiyor	Proxy’ye özel ana makine veya tünel hatası	İstemci hedefi doğrudan yeniden denemekten kaçındı mı?
CONNECT reddedildi	İlgili hedefte HTTPS gezinmesi başarısız	Ret, aşma izni değil politika olarak mı ele alınıyor?
PAC dosyası erişilemiyor	Proxy çözümlemesi durur veya yol değişir	PAC zorunlu mu; Chromium sessizce DIRECT kullanabilir mi?
İstisna deseni fazla geniş	Belirli sitelere doğrudan bağlantı	Tam makine adı, alt alan, bağlantı noktası ve örtük kurallar anlaşılıyor mu?
WebRTC başka arayüz kullanıyor	Medya yolu sayfa trafiğinden farklı	Profilde proxy dışı UDP kapalı mı?
Ayar değişirken mevcut bağlantı kalıyor	Eski yol geçici olarak etkin	Bağlantılar sonlandırılıyor veya profil yeniden başlatılıyor mu?
Tanılama aşırı ayrıntılı	URL, ana makine adı veya sırlar destek dosyasına girer	Hangi gizleme modu ve saklama kuralı geçerli?

Chromium’un alternatif proxy davranışı durum tutar. Bağlantı düzeyinde hata veren proxy, bozuk işaretlenip belirli süre diğer seçeneklerin arkasına alınabilir. Listede DIRECT varsa sonraki istekler proxy olmadan çıkabilir. CONNECT reddi farklı ele alınır; çünkü erişilemeyen proxy yerine kasıtlı hedef politikasını temsil edebilir.

PAC hatası özellikle dikkat ister. Chromium, PAC zorunlu işaretlenmedikçe erişilemeyen PAC dosyasında sessizce doğrudan çözümlemeye dönebileceğini belgeler. Chrome ProxySettings politikası, bu doğrudan dönüşü önlemek için özellikle ProxyPacMandatory sunar.

WebRTC ve UDP ayrı karar gerektirir

Sayfa, sıradan HTTP ve HTTPS URL isteklerine eşdeğer olmayan WebRTC yolları kullanabilir. Chrome’un varsayılan WebRtcIPHandling politikası bütün kullanılabilir arayüzleri kullanabilir. disable_non_proxied_udp modu, yapılandırılmış proxy UDP desteklemedikçe WebRTC’yi genel arayüzde TCP ile sınırlar.

Politika profil düzeyinde belgelenmiştir; bu, profil proxy’siyle ilgili olmasını sağlar ama yine ayrı kontroldür. Medya performansını düşürebilir veya doğrudan UDP gerektiren işi bozabilir. Bu karşılığı açıkça seçip test edin. Yalnızca başarılı sayfa yükleme kontrolüne dayanarak bütün trafiğin proxy’de kaldığını iddia etmeyin.

Hata durumunda durmayı mı, erişilebilirliği mi seçtiğinizi belirleyin

Erişilebilirliğe öncelik veren genel gezinme profilinde doğrudan yola dönüş meşru olabilir. Yetkisi, gizliliği veya bölgesel test geçerliliği belirli çıkış yoluna bağlı iş akışında güvenli değildir.

İyi profil politikası davranışı adlandırır:

• Zorunlu proxy: Seçili yol kullanılamadığında etkilenen ağ isteklerini durdurur.
• Onaylı proxy kümesi: Yalnızca eşdeğer politikaya sahip belirtilmiş alternatifleri dener.
• Doğrudan dönüşe izin var: Yolun değiştiğini gösterir ve olayı sır değerleri olmadan kaydeder.
• Açık istisna: Hedef sınıfını ve doğrudan erişimin neden gerektiğini belgeler.

Arayüz, başlatmadan önce ve hata sonrasında yol durumunu görünür kılmalı. Sessizce proxy’den doğrudan bağlantıya geçmek ağ hatasını bütünlük hatasına dönüştürür: iş akışı yanlış yolu kullanırken başarılı görünebilir.

Güvenli doğrulama matrisi

Sahibi olduğunuz veya incelemeye yetkili olduğunuz uç noktalar ve DNS bölgeleriyle test edin. Testten önce beklenen sonuçları kaydedin.

1. Bildirilen proxy şemasını uç noktanın gerçek aktarımıyla doğrulayın.
2. Başarılı HTTP, HTTPS, WebSocket ve gereken WebRTC davranışını doğrulayın.
3. Kontrollü hedefte çıkış adresini gözlemleyin.
4. Hedef sorgusunu hangi çözümleyicinin aldığını ve proxy adının başlangıç sorgusunu hangisinin yaptığını gözlemleyin.
5. Test kimlik bilgisinin süresini doldurun; ham değerin arayüzde, günlükte veya otomasyon çıktısında görünmediğini doğrulayın.
6. Test proxy’sini erişilemez yapın; ayarlanmış durma veya alternatif yol sonucunu doğrulayın.
7. Kontrollü bir CONNECT hedefini reddedin; politika reddinin doğrudan erişime dönüşmediğini doğrulayın.
8. Test PAC’ını erişilemez yapın ve zorunlu davranışı doğrulayın.
9. İş akışının gerektirdiği tam ad, alt alan, yerel, yerel bağlantı, IPv4 ve IPv6 istisna durumlarını deneyin.
10. Bağlantılar etkinken proxy’yi değiştirin; yeni yolun ne zaman devreye girdiğini doğrulayın.
11. Yalnızca test için gereken tanılama ayrıntısını alın; sonra saklama ve silmeyi doğrulayın.

Chromium’un NetLog rehberi, ağ günlüğünü gizlilik ve güvenlik konusu olarak ele alır. Gizleme modları hassas alanları çıkarabilir; daha ayrıntılı modlar ise çerez veya kimlik doğrulama başlıkları içerebilir. Destek dosyasını adına değil, gerçek yakalama moduna göre işleyin.