Proxy pro Browserprofil: DNS, Authentifizierung und Fehlerarten

Dieser Ratgeber verwendet Chromiums dokumentiertes Netzwerkverhalten als Bezugspunkt. Andere Browser und Produkte können andere Entscheidungen treffen, und ein Browsermanager kann Chromium um einen lokalen Netzwerkbroker ergänzen. Prüfen Sie das Verhalten des konkreten Builds, den Sie betreiben.

Beginnen Sie mit vier unabhängigen Fragen

Ein Proxy-Datensatz enthält gewöhnlich Schema, Endpunkt, Port und manchmal einen Authentifizierungsverweis. Der Datensatz lässt vier getrennte Richtlinienfragen offen:

1. Abdeckung: Welche Browseranfragen und Protokolle werden diesem Proxy zugewiesen?
2. Namensauflösung: Löst das Gerät oder der Proxy den Zielhostnamen auf?
3. Authentifizierung: Welche Client- und Proxy-Schemas funktionieren zusammen, und wo werden Zugangsdaten gespeichert?
4. Fehler: Stoppt ein Verbindungsfehler die Anfrage, wird ein anderer Proxy versucht oder auf einen direkten Weg ausgewichen?

Wer diese Fragen als einen einzigen Schalter „Proxy ein“ behandelt, erlebt die meisten Überraschungen. Chromium dokumentiert die Proxyauswahl als Auflösung auf URL-Ebene: Eine URL erzeugt eine geordnete Liste von Proxyoptionen, bevor das Ziel zwangsläufig aufgelöst ist. Umgehungs- und Ausweichregeln sind Teil dieser Entscheidung.

Was ein Proxy pro Profil abdeckt

Googles ProxySettings-Richtlinie wird auf der Ebene eines Chrome-Profils angewendet. Sie kann direkte, systembezogene, automatisch erkannte, feste Server- oder PAC-Skript-Modi sowie ausdrückliche Felder für Umgehungen und verbindliches PAC-Verhalten auswählen.

Diese Grenze ist enger als ein VPN oder ein Netzwerk-Namespace des Betriebssystems. Sie regelt Anfragen, die vom Browser-Netzwerkkontext verarbeitet werden. Sie erfasst nicht automatisch:

• eigene API-Aufrufe des Desktop-Managers;
• eine externe Anwendung oder den Browser-Updater;
• DNS- und Verbindungsprüfungen des Betriebssystems;
• eine andere Anwendung, die aus einer heruntergeladenen Datei gestartet wird;
• ein separates natives Hilfsprogramm einer Erweiterung;
• lokale Dienste, die durch implizite Loopback-Umgehungen erreicht werden; oder
• Datenverkehr über ein Protokoll, das der ausgewählte Proxyweg nicht übertragen kann.

Einige dieser Komponenten können eine eigene Proxy-Unterstützung besitzen. Diese muss getrennt spezifiziert und getestet werden. Eine Produktaussage wie „Der Profildatenverkehr verwendet diesen Proxy“ sollte die enthaltenen Prozesse und Protokolle nennen, statt geräteweites Routing zu suggerieren.

Verfolgen Sie eine einzelne HTTPS-Anfrage

Eine gewöhnliche HTTPS-Navigation durchläuft mehrere Schritte.

1. Route auswählen

Der Browser wertet feste Regeln, ein Proxy-Autokonfigurationsskript oder Systemeinstellungen aus. Eine passende Umgehungsregel kann eine direkte Verbindung auswählen. Eine Proxyliste kann einen primären Proxy und danach Alternativen enthalten, darunter DIRECT, falls direktes Ausweichen erlaubt ist.

Chromium wendet zudem implizite Umgehungen für Localhost- und Link-Local-Ziele an. Dies schützt lokale Origins vor extern kontrollierten Proxy-Einstellungen, bedeutet aber, dass eine weit gefasste Beschreibung wie „gesamter Datenverkehr“ eingeschränkt werden muss.

2. Proxy auflösen und erreichen

Ist der Proxy-Endpunkt ein Hostname, benötigt das Gerät weiterhin einen Weg, diesen Endpunkt aufzulösen und zu erreichen. Eine entfernte DNS-Auflösung des Ziels beseitigt diese vorbereitende Auflösung nicht. Ein Fehler an dieser Stelle unterscheidet sich von einem erreichbaren Proxy, der das Ziel nicht auflösen kann.

3. Beim Proxy authentifizieren

Ein HTTP-Proxy, der Zugangsdaten verlangt, antwortet gewöhnlich mit 407 Proxy Authentication Required und einer Herausforderung. RFC 9110 definiert diesen Austausch sowie die Felder Proxy-Authenticate und Proxy-Authorization.

Chromium verwendet keinen in manuelle Proxy-Einstellungen eingebetteten Benutzernamen und kein dort eingebettetes Passwort. Laut Proxy-Dokumentation folgt die Authentifizierung stattdessen dem normalen Zugangsdatenablauf des Browsers. Ein Profilmanager benötigt deshalb eine ausdrückliche Integration für die unterstützte Herausforderung, nicht das Versprechen, dass jede Zeichenkette im Format user:password@host funktioniert.

4. Zielverbindung herstellen

Bei einem HTTP-Proxy überlässt Chromium die Namensauflösung des Ziels dem Proxy. Für ein HTTPS-Ziel fordert der Browser den Proxy auf, einen CONNECT-Tunnel anzulegen, und führt darin eine Ende-zu-Ende-TLS-Verbindung mit dem Ziel durch.

Der Proxy erfährt weiterhin den Zielhostnamen und Verbindungsmetadaten. Verwendet die Strecke vom Client zum Proxy unverschlüsseltes HTTP, sind die CONNECT-Anfrage und ihr Hostname auf dieser Strecke nicht geschützt. Ein HTTPS-Proxy ergänzt TLS zwischen Browser und Proxy und schützt diese Metadaten vor Beobachtenden dazwischen. Er verhindert nicht, dass der Proxy selbst das angefragte Ziel sieht.

Der Proxy kann den durch den Tunnel übertragenen HTTPS-Seiteninhalt normalerweise nicht lesen. TLS-Interception ist ein anderes Vertrauensmodell, bei dem der Client einer Zertifizierungsstelle vertraut, die dem Vermittler das Beenden und erneute Herstellen von TLS ermöglicht. Sie darf niemals stillschweigend mit gewöhnlicher Weiterleitung gleichgesetzt werden.

Die DNS-Zuständigkeit hängt vom Proxy-Schema ab

Chromiums dokumentiertes Verhalten unterscheidet sich nach Proxytyp:

Ausgewählter Weg	Namensauflösung des Ziels in Chromium	Wichtige Grenze
Direkt oder Umgehung	Geräte- oder Browserresolver	Zieldatenverkehr verlässt das Gerät ohne den Profilproxy
HTTP-Proxy	Proxyseite	Unverschlüsselter HTTP-Transport zwischen Client und Proxy legt HTTP-Anfragen offen; HTTPS verwendet CONNECT
HTTPS-Proxy	Proxyseite	Der Client muss das TLS-Zertifikat des Proxys prüfen
SOCKS4-Proxy	Clientseite	Nur IPv4-Ziele; Chromium implementiert kein SOCKS4a-Ausweichen
SOCKS5-Proxy	Proxyseite	Chromium verwendet ihn für TCP-URL-Anfragen und dokumentiert keine Unterstützung für SOCKS5-Authentifizierung

RFC 1928 erlaubt einer SOCKS5-Anfrage die Übermittlung eines Domainnamens und definiert mehrere Kennungen für Authentifizierungsmethoden. Eine Protokollfunktion garantiert keine Clientumsetzung. Chromium übermittelt Zielnamen derzeit an einen SOCKS5-Proxy, gibt aber an, dass sein eingebauter SOCKS5-Client keine Proxy-Authentifizierungsmethode unterstützt. Ein Anbieter mit SOCKS5-Zugriff per Benutzername und Passwort kann daher einen unterstützten Vermittler oder ein anderes Proxy-Schema erfordern. Prüfen Sie die Browserumsetzung, bevor Sie den Datensatz akzeptieren.

DNS-over-HTTPS ergänzt eine weitere Ebene. Chromes DnsOverHttpsMode-Richtlinie unterscheidet automatic, das auf unsicheres DNS ausweichen kann, und secure, das die Auflösung bei einem Ausfall von sicherem DNS abbricht. Dieselbe Richtlinie ist als browserweit dokumentiert, während ProxySettings profilbezogen ist. Diese Abweichung ist ein hilfreicher Warnhinweis: Das Wort „Profil“ bei einer Einstellung bedeutet nicht, dass jede DNS-Kontrolle denselben Geltungsbereich besitzt.

Ein Produkt, das jedes Profil in einem separaten Browserprozess ausführt, kann eine engere wirksame Grenze schaffen. Das ist jedoch eine Umsetzungsentscheidung. Testen Sie sie. Der Nachweis sollte unterscheiden:

• Auflösung des Proxy-Endpunkts;
• Auflösung des angefragten Ziels;
• DNS für direkte oder umgangene Anfragen;
• Vorbereitung und Ausweichverhalten von sicherem DNS; und
• DNS durch Komponenten außerhalb des Browser-Netzwerkkontexts des Profils.

Authentifizierung ist ein Kompatibilitäts- und Geheimnisproblem

Chromium dokumentiert Basic, Digest, Negotiate und NTLM für HTTP-Proxys. HTTPS-Proxys ergänzen einen geschützten Kanal zwischen Client und Proxy und können außerdem Clientzertifikate unterstützen. Authentifizierung für SOCKS4 und SOCKS5 ist im eingebauten Proxy-Client von Chromium nicht implementiert, obwohl die SOCKS5-Spezifikation Authentifizierungsmethoden vorsieht.

Selbst ein kompatibles Schema kann bei ungeeignetem Transport unsicher sein. RFC 7617 erläutert, dass Basic-Zugangsdaten nur Base64-codiert sind und einen geschützten Kanal wie TLS benötigen. Basic-Authentifizierung an einem unverschlüsselten HTTP-Proxy legt das Proxy-Passwort jeder Person offen, die diese Strecke beobachten kann.

Ein Profilmanager sollte folgende Daten getrennt halten:

• nicht vertrauliche Endpunktmetadaten wie Schema, Host, Port und Anbieterbezeichnung;
• einen Geheimnisverweis für den Lebenszyklus- oder Netzwerkdienst;
• den Zugangsdatenwert in geschütztem Speicher;
• geschwärzten Verbindungszustand für Oberfläche und Auditverlauf; und
• Diagnosedetails, die ausschließlich über einen kontrollierten Supportablauf verfügbar sind.

Gewöhnliche Ansichten, Protokolle, APIs, Exporte und Automatisierungsausgaben benötigen das Proxy-Passwort nicht. Eine bedienende Person muss normalerweise wissen, dass die Authentifizierung fehlgeschlagen ist, welches Schema angefordert wurde, welcher Endpunkt beteiligt war und ob ein Ausweichen erfolgte.

Fehlerarten und ihre Symptome

Fehler	Wahrscheinliches Symptom	Zu prüfende Grenze
Falsches Proxy-Schema	TLS- oder Protokoll-Handshake schlägt fehl	Wurde ein HTTPS-Endpunkt als HTTP angegeben oder umgekehrt?
Proxy-Hostname lässt sich nicht auflösen	Verbindung schlägt fehl, bevor der Proxy erreicht wird	Welcher Resolver führte die vorbereitende Auflösung durch?
Proxy-Port ist nicht erreichbar	Zeitüberschreitung oder Verbindungsablehnung	Folgt in der Liste ein anderer Proxy oder DIRECT?
Authentifizierungsherausforderung wird nicht unterstützt	Wiederholtes 407 oder Anmeldeaufforderung	Implementiert der Browser das geforderte Schema?
Zugangsdaten sind falsch oder abgelaufen	407 nach Übermittlung der Zugangsdaten	Wurde der Geheimnisverweis aufgelöst und der Wert in Ausgaben geschwärzt?
Zertifikat des HTTPS-Proxys schlägt fehl	Sichere Verbindung zum Proxy wird abgelehnt	Ist die Zertifikatsprüfung intakt?
Proxy kann das Ziel nicht auflösen	Proxyspezifischer Host- oder Tunnelfehler	Hat der Client einen direkten erneuten Versuch zum Ziel vermieden?
CONNECT wird abgelehnt	HTTPS-Navigation zu diesem Ziel schlägt fehl	Wird die Ablehnung als Richtlinie behandelt und nicht als Erlaubnis zur Umgehung?
PAC-Datei ist nicht verfügbar	Proxy-Auflösung stockt oder ändert den Weg	Ist PAC verbindlich oder darf Chromium unbemerkt DIRECT verwenden?
Umgehungsmuster ist zu weit	Ausgewählte Websites verbinden direkt	Sind Regeln für genauen Host, Subdomain, Port und implizite Fälle verstanden?
WebRTC verwendet eine andere Schnittstelle	Medienweg unterscheidet sich vom Seitenverkehr	Ist nicht weitergeleiteter UDP-Datenverkehr für das Profil deaktiviert?
Bestehende Verbindung überdauert eine Änderung	Alter Weg bleibt vorübergehend aktiv	Werden Verbindungen beendet oder wird das Profil neu gestartet?
Diagnoseaufzeichnung ist zu detailliert	URLs, Hostnamen oder Geheimnisse gelangen in eine Supportdatei	Welcher Schwärzungsmodus und welche Aufbewahrungsregel gelten?

Chromiums Ausweichverhalten ist zustandsbehaftet. Ein Proxy mit einem Verbindungsfehler kann vorübergehend als fehlerhaft markiert und hinter andere Einträge verschoben werden. Steht DIRECT in der Liste, können spätere Anfragen das Gerät ohne Proxy verlassen. Eine CONNECT-Ablehnung wird anders behandelt, weil sie eine beabsichtigte Zielrichtlinie statt eines nicht verfügbaren Proxys darstellen kann.

PAC-Fehler benötigen besondere Aufmerksamkeit. Chromium dokumentiert, dass eine nicht verfügbare PAC-Datei unbemerkt auf direkte Auflösung ausweichen kann, sofern PAC nicht als verbindlich markiert ist. Chromes ProxySettings-Richtlinie bietet ProxyPacMandatory ausdrücklich an, um dieses direkte Ausweichen zu verhindern.

WebRTC und UDP benötigen eine eigene Entscheidung

Eine Seite kann WebRTC-Wege verwenden, die gewöhnlichen HTTP- und HTTPS-URL-Anfragen nicht entsprechen. Chromes standardmäßige WebRtcIPHandling-Richtlinie kann alle verfügbaren Schnittstellen nutzen. Ihr Modus disable_non_proxied_udp beschränkt WebRTC auf der öffentlichen Schnittstelle auf TCP, sofern ein konfigurierter Proxy kein UDP unterstützt.

Die Richtlinie ist als profilbezogen dokumentiert und daher für einen Profilproxy relevant, bleibt aber eine getrennte Kontrolle. Sie kann die Medienleistung verringern oder einen Arbeitsablauf unterbrechen, der direktes UDP benötigt. Wählen und testen Sie diesen Zielkonflikt ausdrücklich. Behaupten Sie keine vollständige Proxy-Eindämmung allein aufgrund eines erfolgreichen Seitenaufrufs.

Entscheiden Sie zwischen sicherem Abbruch und Verfügbarkeit

Direktes Ausweichen kann für ein allgemeines Browserprofil sinnvoll sein, das Verfügbarkeit priorisiert. Für einen Arbeitsablauf, dessen Autorisierung, Datenschutz oder Gültigkeit regionaler Tests von einem bestimmten Ausgangsweg abhängt, ist es unsicher.

Eine gute Profilrichtlinie benennt das vorgesehene Verhalten:

• Erforderlicher Proxy: Betroffene Netzwerkanfragen abbrechen, wenn der ausgewählte Weg nicht verwendet werden kann.
• Genehmigte Proxymenge: Ausschließlich benannte Alternativen mit gleichwertiger Richtlinie versuchen.
• Direktes Ausweichen erlaubt: Den geänderten Weg anzeigen und das Ereignis ohne Geheimniswerte aufzeichnen.
• Ausdrückliche Umgehung: Die Zielklasse und den Grund für den erforderlichen direkten Zugriff dokumentieren.

Die Oberfläche sollte den Routenzustand vor dem Start und nach einem Fehler sichtbar machen. Ein stiller Wechsel vom Proxy zur direkten Verbindung macht aus einem Netzwerkfehler einen Integritätsfehler: Der Arbeitsablauf kann erfolgreich wirken, obwohl er den falschen Weg verwendet.

Eine sichere Validierungsmatrix

Testen Sie mit Endpunkten und DNS-Zonen, die Sie besitzen oder autorisiert untersuchen dürfen. Dokumentieren Sie die erwarteten Ergebnisse vor dem Test.

1. Prüfen Sie das angegebene Proxy-Schema gegen den tatsächlichen Endpunkttransport.
2. Bestätigen Sie erfolgreiches HTTP-, HTTPS-, WebSocket- und erforderliches WebRTC-Verhalten.
3. Beobachten Sie die Ausgangsadresse an einem kontrollierten Ziel.
4. Beobachten Sie, welcher Resolver die Zielauflösung empfängt und welcher den Proxy-Hostnamen vorbereitet.
5. Lassen Sie Testzugangsdaten ablaufen und bestätigen Sie, dass kein ungeschützter Wert in Oberfläche, Protokollen oder Automatisierungsausgaben erscheint.
6. Machen Sie den Testproxy unerreichbar und bestätigen Sie den konfigurierten sicheren Abbruch oder das Ausweichergebnis.
7. Verweigern Sie einem kontrollierten CONNECT-Ziel den Zugriff und bestätigen Sie, dass die Richtlinienablehnung nicht zu direktem Zugriff wird.
8. Machen Sie eine Test-PAC-Datei nicht verfügbar und bestätigen Sie das verbindliche Verhalten.
9. Prüfen Sie die für den Arbeitsablauf benötigten Fälle für genaue Hosts, Subdomains, lokale und Link-Local-Ziele sowie IPv4 und IPv6.
10. Ändern Sie den Proxy bei aktiven Verbindungen und prüfen Sie, wann der neue Weg wirksam wird.
11. Erfassen Sie nur die für den Test benötigten Diagnosedetails und prüfen Sie anschließend Aufbewahrung und Löschung.

Chromiums NetLog-Leitlinie behandelt Netzwerkprotokollierung als Datenschutz- und Sicherheitsproblem. Geschwärzte Modi können vertrauliche Felder auslassen, während detailliertere Modi Cookies oder Authentifizierungs-Header enthalten können. Eine Supportdatei sollte entsprechend ihrem tatsächlichen Aufzeichnungsmodus behandelt werden, nicht nach ihrem Dateinamen.