Proxyunterstützung in Microsoft Edge

In diesem Dokument werden grundlegende Proxyterminologien festgelegt und Edge-spezifisches Proxyverhalten beschrieben.

Inhalt

Proxyserverbezeichner

Ein Proxyserver ist ein Vermittler, der für Netzwerkanforderungen verwendet wird. Ein Proxyserver kann mithilfe seiner Adresse zusammen mit dem Proxyschema beschrieben werden, das für die Kommunikation mit ihm verwendet werden soll.

Dieser Bezeichner kann als Zeichenfolge mit dem "PAC-Format" oder dem "URI-Format" geschrieben werden.

Das PAC-Format gibt an, wie man einen Proxyserver in Skripts für die automatische Proxykonfiguration benennt. Beispiel:

PROXY foo:2138 SOCKS5 foo:1080 DIRECT

Das "URI-Format" codiert die Informationen stattdessen als URL. Beispiel:

foo:2138 http://foo:2138 socks5://foo:1080 direct://

Die Portnummer ist in beiden Formaten optional. Wenn keine Angabe erfolgt, wird ein Schemastandard verwendet.

Im Abschnitt Proxyserverschemas finden Sie Details dazu, welche Schemas Edge unterstützt und wie sie in den PAC- und URI-Formaten geschrieben werden.

Die meisten Benutzeroberflächenoberflächen in Edge (einschließlich Befehlszeilen und Richtlinien) erwarten URI-formatierte Proxyserverbezeichner. Außerhalb von Edge werden Proxyserver jedoch weniger genau identifiziert, wenn nur eine Adresse verwendet wird. Das Proxyschema wird basierend auf dem Kontext angenommen.

In den Proxyeinstellungen von Windows gibt es Host- und Portfelder für den Proxy "HTTP", "Secure", "FTP" und "SOCKS". Mit Ausnahme von "SOCKS" sind dies alle Bezeichner für unsichere HTTP-Proxyserver (Proxyschema wird als HTTP angenommen).

Proxyauflösung

Das Proxying in Edge erfolgt auf URL-Ebene.

Wenn der Browser aufgefordert wird, eine URL abzurufen, muss er entscheiden, an welchen IP-Endpunkt die Anforderung gesendet werden soll. Dies kann entweder ein Proxyserver oder der Zielhost sein.

Dies wird als Proxyauflösung bezeichnet. Die Eingabe für die Proxyauflösung ist eine URL, und die Ausgabe ist eine sortierte Liste von Proxyserverbezeichnern.

Welche Proxys verwendet werden sollen, kann mit einer der folgenden Methoden beschrieben werden:

Manuelle Proxyeinstellungen : Die Proxyauflösung wird mithilfe eines deklarativen Regelsatzes definiert. Diese Regeln werden als Zuordnung vom URL-Schema zu Proxyserverbezeichnern und einer Liste von Proxyumgehungsregeln ausgedrückt, die angeben, wann DIRECT anstelle des zugeordneten Proxys verwendet werden soll.

PAC-Skript: Die Proxyauflösung wird mithilfe eines JavaScript-Programms definiert, das immer dann aufgerufen wird, wenn eine URL abgerufen wird, um die Liste der zu verwendenden Proxyserverbezeichner abzurufen.

Autodetect: Das WPAD-Protokoll wird verwendet, um das Netzwerk (mithilfe von DHCP/DNS) zu testen und möglicherweise die URL eines PAC-Skripts zu ermitteln.

Proxyserverschemas

Bei Verwendung eines expliziten Proxys im Browser sind je nach verwendetem Schema mehrere Ebenen der Netzwerkanforderung betroffen. Das Proxyschema hat folgende Auswirkungen:

Erfolgt die Kommunikation mit dem Proxy über einen sicheren Kanal? Ist die Namensauflösung (z. B. DNS) clientseitig oder proxyseitig erfolgt? Welche Authentifizierungsschemas für den Proxyserver werden unterstützt? Welcher Netzwerkdatenverkehr kann über den Proxy gesendet werden? Edge unterstützt die folgenden Proxyserverschemas:

DIRECT-Proxyschema

Standardport: N/V (weder Host noch Port sind anwendbar) Beispielbezeichner (PAC): Beispielbezeichner (URI): DIRECTdirect:// Dies ist ein Pseudoproxyschema, das angibt, dass anstelle eines Proxys die Anforderung direkt an den Zielserver gesendet wird.

Es ist ungenau, dies als "Proxyserver" zu bezeichnen, aber es ist eine praktische Abstraktion.

HTTP-Proxyschema

Standardport: 80 Beispielbezeichner (PAC): PROXY proxy:8080, proxy (nicht standardmäßig; nicht verwenden) Beispielbezeichner (URI): http://proxy:8080, proxy:8080 (kann Schema weglassen) Wenn man auf einen "Proxyserver" oder "Webproxy" verweist, handelt es sich im Allgemeinen um einen HTTP-Proxy.

Bei Verwendung eines HTTP-Proxys in Edge wird die Namensauflösung immer auf den Proxy zurückgestellt. HTTP-Proxys können urLs, https://und wss://ws:// proxynhttp://.

Die Kommunikation mit HTTP-Proxyservern ist unsicher, was bedeutet, dass Proxyanforderungen http:// klar gesendet werden. Beim Proxying von https:// Anforderungen über einen HTTP-Proxy wird der TLS-Austausch über den Proxy mithilfe der CONNECT-Methode weitergeleitet, sodass die End-to-End-Verschlüsselung nicht unterbrochen wird. Beim Einrichten des Tunnels wird der Hostname der Ziel-URL jedoch klar an den Proxyserver gesendet.

HTTP-Proxys in Edge unterstützen die gleichen HTTP-Authentifizierungsschemas wie für Zielserver: Basic, Digest, Negotiate, NTLM.

HTTPS-Proxyschema

Standardport: 443 Beispielbezeichner (PAC): HTTPS proxy:8080 Beispielbezeichner (URI): https://proxy:8080

Dies funktioniert wie ein HTTP-Proxy, mit der Ausnahme, dass die Kommunikation mit dem Proxyserver durch TLS geschützt ist und HTTP/2 (aber nicht QUIC) aushandeln kann.

Da die Verbindung mit dem Proxyserver sicher ist, werden anforderungen, https:// die über den Proxy gesendet werden, nicht im Klarnamen wie bei einem HTTP-Proxy gesendet. Da CONNECT-Anforderungen über einen geschützten Kanal gesendet werden, werden auch die Hostnamen für Proxy-URLs https:// nicht angezeigt.

Zusätzlich zu den üblichen HTTP-Authentifizierungsmethoden unterstützen HTTPS-Proxys auch Clientzertifikate.

HTTPS-Proxys, die HTTP/2 verwenden, können aufgrund höherer Verbindungsgrenzwerte eine bessere Leistung in Edge bieten als ein regulärer HTTP-Proxy (HTTP/1.1-Proxys in Edge sind auf 32 gleichzeitige Verbindungen in allen Domänen beschränkt).

Edge, Firefox und Opera unterstützen HTTPS-Proxys. Bei den meisten älteren HTTP-Stapeln ist dies jedoch nicht der Fall.

Die Angabe eines HTTPS-Proxys ist über Systemproxyeinstellungen nicht möglich. Stattdessen muss entweder ein PAC-Skript oder eine Edge-Proxyeinstellung (Befehlszeile, Erweiterung oder Richtlinie) verwendet werden.

SOCKSv4-Proxyschema

Standardport: 1080 Beispielbezeichner (PAC): SOCKS4 proxy:8080, SOCKS proxy:8080 Beispielbezeichner (URI): socks4://proxy:8080 SOCKSv4 ist ein einfacher Transportschichtproxy, der einen TCP-Socket umschließt. Seine Verwendung ist für den Rest des Protokollstapels transparent; nach einem ersten Handshake beim Verbinden des TCP-Sockets (mit dem Proxy) bleibt der Rest des Ladestapels unverändert.

Für SOCKSv4 werden keine Proxyauthentifizierungsmethoden unterstützt.

Bei Verwendung eines SOCKSv4-Proxys erfolgt die Namensauflösung für Zielhosts immer clientseitig und muss außerdem in eine IPv4-Adresse aufgelöst werden (SOCKSv4 codiert die Zieladresse als vier Oktette, sodass IPv6-Ziele nicht möglich sind).

Es gibt Erweiterungen für SOCKSv4, die die Proxy-seitenseitige Namensauflösung und IPv6 ermöglichen, nämlich SOCKSv4a. Edge lässt jedoch keine Konfiguration oder ein Fallback auf v4a zu.

Eine bessere Alternative besteht darin, einfach die neuere Version des Protokolls SOCKSv5 zu verwenden (die noch 20+ Jahre alt ist).

SOCKSv5-Proxyschema

Standardport: 1080 Beispielbezeichner (PAC): SOCKS5 proxy:8080 Beispielbezeichner (URI): socks://proxy:8080, socks5://proxy:8080

SOCKSv5 ist ein Transportschichtproxy, der einen TCP-Socket umschließt und die Namensauflösung auf den Proxy zurückgestellt werden kann.

Wenn in Edge das Schema eines Proxys auf SOCKSv5 festgelegt ist, erfolgt die Namensauflösung immer proxyseitig (obwohl das Protokoll auch clientseitig zulässt). In Firefox kann die clientseitige und proxyseitige Namensauflösung mit network.proxy.socks_remote_dnskonfiguriert werden. Edge verfügt über keine entsprechende Option und verwendet immer die proxyseitige Auflösung.

Für SOCKSv5 in Edge werden keine Authentifizierungsmethoden unterstützt (obwohl einige für das Protokoll vorhanden sind).

Eine praktische Möglichkeit zum Erstellen eines SOCKSv5-Proxys ist mit ssh -D, der verwendet werden kann, um Webdatenverkehr über SSH zu einem Remotehost zu tunneln.

In Edge wird SOCKSv5 nur zum Proxy von TCP-basierten URL-Anforderungen verwendet. Es kann nicht zum Weiterleiten von UDP-Datenverkehr verwendet werden.

Manuelle Proxyeinstellungen

Die einfachste Möglichkeit zum Konfigurieren der Proxyauflösung besteht darin, eine statische Liste von Regeln bereitzustellen, die folgendes umfasst:

Eine Zuordnung von URL-Schemas zu Proxyserverbezeichnern Eine Liste von Proxyumgehungsregeln Wir bezeichnen diesen Konfigurationsmodus als "manuelle Proxyeinstellungen".

Manuelle Proxyeinstellungen können Setups wie die folgenden kurz beschreiben:

http://foo:8080 Proxy für alle Anforderungen verwenden Verwenden Sie proxy http://foo:8080 für alle Anforderungen mit Ausnahme der Anforderungen an eine contoso.com Unterdomäne Verwenden Sie proxy http://foo:8080 für alle https:// Anforderungen und Proxy socks5://mysocks:90 für alles andere Obwohl manuelle Proxyeinstellungen eine allgegenwärtige Möglichkeit sind, Proxys plattformübergreifend zu konfigurieren, gibt es keine Standarddarstellung oder Einen Featuresatz.

Die manuellen Proxyeinstellungen von Edge ähneln denen von WinInet am ehesten. Aber es unterstützt auch Idiome von anderen Plattformen - für instance KDE's Konzept, die Umgehungsliste umzukehren, oder Gnomes Interpretation von Umgehungsmustern als Suffix-Übereinstimmungen.

Beim Definieren manueller Proxyeinstellungen in Edge geben wir drei (möglicherweise leere) Listen von Proxyserverbezeichnern an:

Proxys für HTTP – Eine Liste von Proxyserverbezeichnern, die für http:// Anforderungen verwendet werden sollen, wenn nicht leere Proxys für HTTPS sind – Eine Liste von Proxyserverbezeichnern, die für https:// Anforderungen verwendet werden sollen, wenn nicht leere andere Proxys – Eine Liste von Proxyserverbezeichnern, die für alles andere verwendet werden sollen (nicht mit den anderen beiden Listen übereinstimmen) Es gibt viele Möglichkeiten, mit manuellen Proxyeinstellungen in Edge zu enden (in anderen Abschnitten erläutert).

In den folgenden Beispielen wird die Befehlszeilenmethode verwendet. Starten von Edge mit --proxy-server=XXX (und optional --proxy-bypass-list=YYY)

Beispiel: Um den Proxy http://foo:8080 für alle Anforderungen zu verwenden, können wir Edge mit --proxy-server="http://foo:8080"starten. Dies bedeutet:

Proxys für HTTP – leere Proxys für HTTPS – leere andere Proxys – http://foo:8080 Mit der obigen Konfiguration würden alle Anforderungen mit ERR_PROXY_CONNECTION_FAILEDfehlschlagen, wenn der Proxyserver nicht erreichbar war. Um dies zu beheben, können wir direct einen Fallback hinzufügen, indem wir mit --proxy-server="http://foo:8080,direct://" starten (beachten Sie die durch Kommas getrennte Liste). Diese Befehlszeile bedeutet Folgendes:

Proxys für HTTP – leere Proxys für HTTPS – leere andere Proxys – http://foo:8080, direct:// wenn wir stattdessen nur http:// URLs über den HTTPS-Proxy https://foo:443proxyn möchten und alle anderen Proxys den SOCKSv5-Proxy socks5://mysocks:1080 verwenden, könnten wir Edge mit --proxy-server="http=https://foo:443;socks=socks5://mysocks:1080"starten. Dies wird nun auf Folgendes erweitert:

Proxys für HTTP – https://foo:443 Proxys für HTTPS – leere andere Proxys – socks5://mysocks:1080 Die obige Befehlszeile verwendet das Proxyzuordnungsformat von WinInet mit einigen zusätzlichen Features:

Anstatt Proxyserver nur nach zu hostname:portbenennen, können Sie das URI-Format von Edge für Proxyserverbezeichner verwenden. Anders ausgedrückt: Sie können dem Proxyschema ein Präfix voran stellen, sodass es nicht standardmäßig AUF HTTP festgelegt ist. Die socks= Zuordnung wird allgemeiner als "andere Proxys" verstanden. Die nachfolgende Proxyliste kann Proxys eines beliebigen Schemas enthalten. Wenn das Schema jedoch ausgelassen wird, wird es als SOCKSv4 und nicht als HTTP verstanden.

Zuordnen von WebSocket-URLs zu einem Proxy

Manuelle Proxyeinstellungen verfügen nicht über Zuordnungen für ws:// oder wss:// URLs.

Die Auswahl eines Proxys für diese URL-Schemas unterscheidet sich etwas von anderen URL-Schemas. Der von Edge verwendete Algorithmus lautet:

Wenn "andere Proxys" nicht leer ist, verwenden Sie es, wenn "Proxys für HTTPS" nicht leer ist, verwenden Sie es Andernfalls verwenden Sie "Proxys für HTTP". Dies entspricht der Empfehlung in Abschnitt 4.1.3 von RFC 6455.

Es ist möglich, und separat mithilfe eines PAC-Skripts zu routen ws://wss:// .

Proxyanmeldeinformationen in manuellen Proxyeinstellungen

Die manuellen Proxyeinstellungen der meisten Plattformen ermöglichen die Angabe eines Klartextbenutzernamens/Kennworts für die Proxyanmeldung. Edge implementiert dies nicht und verwendet keine Anmeldeinformationen, die in die Proxyeinstellungen eingebettet sind.

Die Proxyauthentifizierung durchläuft stattdessen den normalen Ablauf, um Anmeldeinformationen zu finden.

Proxyumgehungsregeln

Zusätzlich zur Angabe von drei Listen mit Proxyserverbezeichnern können Sie mit den manuellen Proxyeinstellungen von Edge eine Liste von "Proxyumgehungsregeln" mithilfe von URL-Mustern angeben.

Dieser Regelsatz bestimmt, ob eine bestimmte URL die Verwendung eines Proxys insgesamt überspringen soll, auch wenn ein Proxy anderweitig für ihn definiert ist.

Dieses Konzept ist auch durch Namen wie "Ausnahmeliste", "Ausschlussliste" oder "Keine Proxyliste" bekannt.

Proxyumgehungsregeln können als geordnete Liste von Zeichenfolgen geschrieben werden. Die Reihenfolge spielt im Allgemeinen keine Rolle, kann aber bei verwendung von subtraktiven Regeln verwendet werden.

Wenn manuelle Proxyeinstellungen über die Befehlszeile angegeben werden, kann der --proxy-bypass-list="RULES" Schalter verwendet werden, wobei RULES eine Semikolon- oder kommagetrennte Liste von Umgehungsregeln ist.

Unter URL-Muster für die Proxykonfiguration finden Sie informationen zum Format von URL-Mustern, das Edge für Proxyumgehungsregeln unterstützt.

Bei Verwendung von Systemproxyeinstellungen sollte das Regelformat der Plattform und nicht das von Edge verwendet werden.

URL-Muster für die Proxykonfiguration

In diesem Abschnitt werden Zeichenfolgenkonstruktionen beschrieben, die Edge für die Angabe von URL-Mustern im Kontext der Proxykonfiguration unterstützt, z. B. Proxyumgehungsregeln oder für den DestinationMatchers Wert der ProxyOverrideRules Richtlinie. Diese Muster können beim Definieren einer manuellen Edge-Proxyeinstellung über Befehlszeilenflags, Erweiterungen oder Richtlinien verwendet werden.

URL-Muster für die Proxykonfiguration: Hostname

[ URL_SCHEME "://" ] HOSTNAME_PATTERN [ ":" <port> ]

Entspricht einem Hostnamen mithilfe eines Wildcardmusters und einer optionalen Schema- und Porteinschränkung.

Beispiele:

foobar.com– Entspricht der URL jedes Schemas und Ports, deren normalisierter Host ist foobar.com*foobar.com : Entspricht der URL jedes Schemas und Ports, dessen normalisierter Host mit foobar.com endet (für instance blahfoobar.com und foo.foobar.com). *.org:443 - Entspricht URLs eines beliebigen Schemas mithilfe von Port 443 und deren Domäne .orghttps://x.*.y.com:99 der obersten Ebene . Entspricht https:// URLs an Port 99, deren normalisierter Hostname entspricht.x.*.y.com

URL-Muster für die Proxykonfiguration: Unterdomäne

[ URL_SCHEME "://" ] "." HOSTNAME_SUFFIX_PATTERN [ ":" PORT ]

Hostnamenmuster, die mit einem Punkt beginnen, werden in besonderer Groß-/Kleinschreibung verwendet, um zu bedeuten, dass eine Unterdomäne übereinstimmt. .foo.com ist praktisch eine andere Methode zum Schreiben *.foo.comvon .

Beispiele:

.contoso.com – Entspricht outlook.contoso.com und foo.bar.contoso.com, aber nicht contoso.comhttp://.contoso.com – entspricht nur http:// URLs, die eine Unterdomäne von sind. contoso.com

URL-Muster für die Proxykonfiguration: IP-Literal

[ SCHEME "://" ] IP_LITERAL [ ":" PORT ]

Entspricht URLs, die IP-Adressliterale sind, sowie optionale Schema- und Porteinschränkungen. Dies ist ein Sonderfall des Hostnamenabgleichs, bei dem die IP-Literal-Kanonisierung berücksichtigt wird. Beispielsweise sind die Regeln [0:0:0::1] und [::1] äquivalent (beide stellen dieselbe IPv6-Adresse dar).

Beispiele:

127.0.0.1 http://127.0.0.1 [::1] – Ordnet eine beliebige URL mit der IPv6-Loopbackadresse [0:0::1] zu – entspricht der oben genannten http://[::1]:99 - Ordnet eine beliebige http:// URL zum IPv6-Loopback an Port 99 zu.

URL-Muster für die Proxykonfiguration: IPv4-Adressbereich

IPV4_LITERAL "/" PREFIX_LENGTH_IN_BITS

Entspricht jeder URL, deren Hostname ein IPv4-Literal ist und zwischen dem angegebenen Adressbereich liegt.

Beachten Sie, dass dies nur für URLs gilt, die IP-Literale sind.

Beispiele:

192.168.1.1/16

URL-Muster für die Proxykonfiguration: IPv6-Adressbereich

IPV6_LITERAL "/" PREFIX_LENGTH_IN_BITS

Entspricht jeder URL, bei der es sich um ein IPv6-Literal handelt, das zwischen dem angegebenen Bereich liegt. IPv6-Literale dürfen nicht in Klammern gesetzt werden.

Beachten Sie, dass dies nur für URLs gilt, die IP-Literale sind.

Beispiele:

fefe:13::abc/33 [fefe::]/40 --FALSCH! IPv6-Literale dürfen nicht in Klammern gesetzt werden

URL-Muster für die Proxykonfiguration: Einfache Hostnamen

<local>

Gleicht Hostnamen ohne Punkt ab, die keine IP-Literale sind. Dies ist eine naive Zeichenfolgensuche , was bedeutet, dass Punkte, die überall erscheinen, zählen (einschließlich nachgestellter Punkte!).

Diese Regel entspricht dem Kontrollkästchen "Einfache Hostnamen ausschließen" unter macOS und dem Kontrollkästchen "Keinen Proxyserver für lokale (Intranet-)Adressen verwenden" unter Windows.

Der Regelname stammt von WinInet und kann leicht mit dem Konzept von localhost verwechselt werden. Die beiden Konzepte sind jedoch orthogonal. In der Praxis würde man keine Regeln hinzufügen, um localhost zu umgehen, da dies bereits implizit erfolgt ist.

URL-Muster für die Proxykonfiguration: Subtrahieren impliziter Regeln

<-loopback>

Subtrahiert die impliziten Proxyumgehungsregeln (localhost und verknüpfen Sie lokale Adressen). Dies ist nur für Testsetups erforderlich. Achten Sie auf die Auswirkungen auf die Sicherheit des Proxyings localhost.

Während reguläre Umgehungsregeln den Browser über URLs anweisen, die den Proxy nicht verwenden sollten, hat diese Regel den gegenteiligen Effekt und weist den Browser an, stattdessen den Proxy zu verwenden.

Die Reihenfolge kann bei der Verwendung einer subtraktiven Regel von Bedeutung sein, da Regeln in einer Von-links-nach-rechts-Reihenfolge ausgewertet werden. <-loopback>;127.0.0.1 hat eine subtil andere Wirkung als 127.0.0.1;<-loopback>.

Bedeutung von Regeln zur Umgehung des IP-Adressbereichs

Die Regel zur Umgehung des IP-Adressbereichs in den manuellen Proxyeinstellungen gilt nur für URL-Literale. Das ist nicht das, was man intuitiv erwarten würde.

Beispiel:

Angenommen, wir haben einen Proxy für alle Anforderungen konfiguriert, aber eine Umgehungsregel für 192.168.0.0.1/16hinzugefügt. Wenn wir jetzt zu http://foo navigieren (was in unserem Setup in aufgelöst wird 192.168.1.5 ), stellt der Browser eine direkte Verbindung her (Proxy umgehen), da wir eine Umgehungsregel angegeben haben, die diese IP-Adresse enthält?

Er durchläuft den Proxy.

Die Umgehungsregel ist in diesem Fall nicht anwendbar, da der Browser nie tatsächlich eine Namensauflösung für foodurchführt. Die Proxyauflösung erfolgt vor der Namensauflösung, und je nachdem, welches Proxyschema später ausgewählt wird, wird die clientseitige Namensauflösung möglicherweise nie durchgeführt.

Der Nutzen von Proxyumgehungsregeln für IP-Adressbereiche ist eher begrenzt, da sie nur für Anforderungen gelten, deren URL explizit ein IP-Literal war.

Wenn Proxyentscheidungen basierend auf den aufgelösten IP-Adressen des Hostnamens einer URL getroffen werden müssen, muss ein PAC-Skript verwendet werden.

Implizite Umgehungsregeln

Anforderungen an bestimmte Hosts werden nicht über einen Proxy gesendet, sondern direkt gesendet.

Wir nennen diese impliziten Umgehungsregeln. Die impliziten Umgehungsregeln stimmen mit URLs überein, deren Hostteil entweder ein localhost-Name oder ein link-lokales IP-Literal ist. Im Wesentlichen entspricht es:

localhost *.localhost [::1] 127.0.0.1/8 169.254/16 [FE80::]/10 Die vollständigen Regeln sind etwas komplizierter. Für instance unter Windows erkennen loopbackwir auch .

Dieses Konzept der impliziten Proxyumgehungsregeln ist mit der Proxyunterstützung auf Plattformebene unter Windows und macOS konsistent (allerdings mit einigen Unterschieden aufgrund ihrer Implementierungsrohigkeiten – siehe Kompatibilitätshinweise in net::ProxyHostMatchingRules::MatchesImplicitRules).

Warum sollten implizite Proxyumgehungsregeln überhaupt angewendet werden? Sicherlich gibt es Überlegungen in Bezug auf Ergonomie und Benutzererwartung, aber das größere Problem ist die Sicherheit. Da die Webplattform localhost als sicheren Ursprung behandelt, gewährt die Möglichkeit, sie zu proxyn, zusätzliche Befugnisse. Dies ist besonders problematisch, wenn Proxyeinstellungen extern steuerbar sind, z. B. bei verwendung von PAC-Skripts.

Überschreiben der Impliziten Umgehungsregeln

Wenn Datenverkehr an localhost trotz der Sicherheitsbedenken über einen Proxy gesendet werden soll, kann dies durch Hinzufügen der speziellen Proxyumgehungsregel <-loopback>erfolgen. Diese Regel hat den Effekt, dass die impliziten Regeln subtrahiert werden.

Starten Sie Edge für instance mit dem Befehlszeilenflag:

--proxy-bypass-list="<-loopback>"

Es gibt derzeit keinen Mechanismus zum Deaktivieren der impliziten Proxyumgehungsregeln bei Verwendung eines PAC-Skripts. Proxyumgehungsregeln gelten nur für manuelle Einstellungen, sodass diese Technik nicht verwendet werden kann, damit PAC-Skripts den Proxy für localhost-URLs festlegen können.

Lizenz für Inhalte

Hinweis

Teile dieser Seite sind Änderungen, die auf von Chromium.org erstellten und freigegebenen Werken basieren und gemäß den in der Creative Commons Attribution 4.0 International License beschriebenen Begriffen verwendet werden. Die Originalseite von Chromium finden Sie hier.

Creative Commons License
Diese Arbeit unterliegt einer Creative Commons Attribution 4.0 International License.

  • Last updated on