このドキュメントでは、基本的なプロキシ用語を確立し、Edge 固有のプロキシ動作について説明します。
目次
プロキシ サーバー識別子
プロキシ サーバーは、ネットワーク要求に使用される中継サーバーです。 プロキシ サーバーは、そのアドレスと通信に使用するプロキシ スキームを使用して記述できます。
この識別子は、"PAC 形式" または "URI 形式" を使用して文字列として記述できます。
PAC 形式は、 プロキシの自動構成 スクリプトでプロキシ サーバーに名前を付ける方法です。 以下に例を示します。
PROXY foo:2138 SOCKS5 foo:1080 DIRECT
"URI 形式" は、代わりに情報を URL としてエンコードします。 以下に例を示します。
foo:2138 http://foo:2138 socks5://foo:1080 direct://
ポート番号は、両方の形式で省略可能です。 省略すると、スキームごとの既定値が使用されます。
Edge がサポートするスキームと PAC 形式と URI 形式で記述する方法の詳細については、「プロキシ サーバースキーム」セクションを参照してください。
Edge のほとんどの UI サーフェス (コマンド ラインとポリシーを含む) では、URI 形式のプロキシ サーバー識別子が必要です。 ただし、Edge の外部では、アドレスのみを使用する場合、プロキシ サーバーの識別精度は低くなります。プロキシ スキームはコンテキストに基づいて想定されます。
Windows のプロキシ設定には、"HTTP"、"Secure"、"FTP"、"SOCKS" プロキシのホストフィールドとポート フィールドがあります。 "SOCKS" を除き、これらはすべて安全でない HTTP プロキシ サーバーの識別子です (プロキシ スキームは HTTP と見なされます)。
プロキシ解決
Edge でのプロキシは URL レベルで行われます。
ブラウザーで URL の取得を求められたら、要求を送信する IP エンドポイントを決定する必要があります。 これは、プロキシ サーバーまたはターゲット ホストのいずれかです。
これはプロキシ解決と呼ばれます。 プロキシ解決への入力は URL で、出力はプロキシ サーバー識別子の順序付きリストです。
使用するプロキシは、次のいずれかを使用して記述できます。
手動プロキシ設定 - プロキシ解決は、宣言型規則のセットを使用して定義されます。 これらのルールは、URL スキームからプロキシ サーバー識別子へのマッピングと、マップされたプロキシを使用する代わりに DIRECT に移動するタイミングに関するプロキシ バイパス 規則の一覧として表されます。
PAC スクリプト - プロキシ解決は、使用するプロキシ サーバー識別子の一覧を取得するために URL をフェッチするたびに呼び出される JavaScript プログラムを使用して定義されます。
自動検出 - WPAD プロトコルを使用して (DHCP/DNS を使用して) ネットワークをプローブし、PAC スクリプトの URL を検出する場合があります。
プロキシ サーバー スキーム
ブラウザーで明示的なプロキシを使用する場合、使用されるスキームに応じて、ネットワーク要求の複数のレイヤーが影響を受けます。 プロキシ スキームの影響を次に示します。
プロキシへの通信はセキュリティで保護されたチャネル経由で行われますか? 名前解決 (例: DNS) はクライアント側、またはプロキシ側で行われますか? プロキシ サーバーに対してサポートされている認証スキームは何ですか? プロキシを介して送信できるネットワーク トラフィックは何ですか? Edge では、次のプロキシ サーバー スキームがサポートされています。
DIRECT プロキシ スキーム
既定のポート: N/A (ホストもポートも適用されません) 識別子の例 (PAC): DIRECT 例識別子 (URI): direct:// これは、ターゲット サーバーに要求を直接送信するプロキシを使用する代わりに示す擬似プロキシ スキームです。
これを "プロキシ サーバー" と呼ぶのは不正確ですが、便利な抽象化です。
HTTP プロキシ スキーム
既定のポート: 80 識別子の例 (PAC): PROXY proxy:8080、 proxy (標準ではない、使用しない) 識別子の例 (URI): http://proxy:8080、 proxy:8080 (省略可能) スキーム) 一般に、"プロキシ サーバー" または "Web プロキシ" を参照する場合、HTTP プロキシについて話しています。
Edge で HTTP プロキシを使用する場合、名前解決は常にプロキシに遅延されます。 HTTP プロキシは、 http://、 https://、 ws:// 、 wss:// URL をプロキシできます。
HTTP プロキシ サーバーへの通信は安全ではありません。つまり、プロキシされた http:// 要求がクリアで送信されます。 HTTP プロキシを介して要求 https:// プロキシする場合、TLS 交換は CONNECT メソッドを使用してプロキシを介して転送されるため、エンドツーエンドの暗号化が破損することはありません。 ただし、トンネルを確立すると、ターゲット URL のホスト名がクリア内のプロキシ サーバーに送信されます。
Edge の HTTP プロキシでは、ターゲット サーバーと同じ HTTP 認証スキームがサポートされています。Basic、Digest、Negotiate、NTLM。
HTTPS プロキシ スキーム
既定のポート: 443 例識別子 (PAC): HTTPS proxy:8080 例識別子 (URI): https://proxy:8080
これは HTTP プロキシと同様に機能しますが、プロキシ サーバーへの通信は TLS によって保護されており、HTTP/2 をネゴシエートできます (QUIC ではありません)。
プロキシ サーバーへの接続はセキュリティで保護されているため、プロキシを介して送信された https:// 要求は、HTTP プロキシと同様にクリアで送信されません。 同様に、CONNECT 要求は保護されたチャネル経由で送信されるため、プロキシ https:// URL のホスト名も表示されません。
HTTPS プロキシでは、通常の HTTP 認証方法に加えて、クライアント証明書もサポートされます。
HTTP/2 を使用する HTTPS プロキシは、接続制限が高いため、通常の HTTP プロキシよりも Edge のパフォーマンスが向上する可能性があります (Edge の HTTP/1.1 プロキシは、すべてのドメインで同時接続が 32 に制限されます)。
Edge、Firefox、Opera では HTTPS プロキシがサポートされています。ただし、ほとんどの古い HTTP スタックはしません。
システム プロキシ設定を使用して HTTPS プロキシを指定することはできません。 代わりに、PAC スクリプトまたは Edge プロキシ設定 (コマンド ライン、拡張機能、またはポリシー) を使用する必要があります。
SOCKSv4 プロキシ スキーム
既定のポート: 1080 例識別子 (PAC): SOCKS4 proxy:8080、 SOCKS proxy:8080 例識別子 (URI): SOCKSv4 socks4://proxy:8080 は、TCP ソケットをラップする単純なトランスポート層プロキシです。 その使用は、プロトコル スタックの残りの部分に対して透過的です。TCP ソケットを (プロキシに) 接続するときの初期ハンドシェイクの後、読み込みスタックの残りの部分は変更されません。
SOCKSv4 ではプロキシ認証方法はサポートされていません。
SOCKSv4 プロキシを使用する場合、ターゲット ホストの名前解決は常にクライアント側で行われ、さらに IPv4 アドレスに解決する必要があります (SOCKSv4 はターゲット アドレスを 4 オクテットとしてエンコードするため、IPv6 ターゲットは使用できません)。
SOCKSv4 には、プロキシ側の名前解決を可能にする拡張機能と、IPv6 (SOCKSv4a) があります。 ただし、Edge では、v4a の構成やフォールバックは許可されません。
より良い代替手段は、新しいバージョンのプロトコルである SOCKSv5 (まだ 20 歳以上) を使用することです。
SOCKSv5 プロキシ スキーム
既定のポート: 1080 例識別子 (PAC): SOCKS5 proxy:8080 例識別子 (URI): socks://proxy:8080、 socks5://proxy:8080
SOCKSv5 は、TCP ソケットをラップするトランスポート層プロキシであり、名前解決をプロキシに遅延できます。
プロキシのスキームが SOCKSv5 に設定されている Edge では、名前解決は常にプロキシ側で実行されます (プロトコルによってクライアント側も許可されている場合でも)。 Firefox クライアント側とプロキシ側の名前解決では、 network.proxy.socks_remote_dnsで構成できます。Edge には同等のオプションはなく、常にプロキシ側の解像度が使用されます。
Edge の SOCKSv5 では認証方法はサポートされていません (ただし、プロトコルには存在するものがあります)。
SOCKSv5 プロキシを作成する便利な方法は、 ssh -Dを使用して、SSH 経由で Web トラフィックをリモート ホストにトンネリングするために使用できます。
Edge SOCKSv5 では、TCP ベースの URL 要求のプロキシにのみ使用されます。 UDP トラフィックの中継には使用できません。
手動プロキシ設定
プロキシ解決を構成する最も簡単な方法は、次で構成される規則の静的リストを提供することです。
プロキシ サーバー識別子への URL スキームのマッピング プロキシ バイパス 規則の一覧 この構成モードを "手動プロキシ設定" と参照します。
手動プロキシ設定では、次のような設定を簡潔に記述できます。
すべての要求にプロキシ http://foo:8080を使用する contoso.com サブドメイン以外のすべての要求にプロキシ http://foo:8080を使用する https:// 要求すべてにプロキシ http://foo:8080を使用し、それ以外のすべての場合はプロキシ socks5://mysocks:90を使用します。手動プロキシ設定は、プラットフォーム間でプロキシを構成するためのユビキタスな方法ですが、標準の表現や機能セットはありません。
Edge の手動プロキシ設定は、WinInet によく似ています。 ただし、他のプラットフォームからのイディオムもサポートされています。たとえば、バイパス リストを反転させるという KDE の概念や、サフィックスの一致としてのバイパス パターンの Gnome の解釈などです。
Edge で手動プロキシ設定を定義する場合は、プロキシ サーバー識別子の 3 つの (空の可能性がある) リストを指定します。
HTTP のプロキシ - http:// 要求に使用するプロキシ サーバー識別子の一覧(HTTPS のプロキシがない場合) - https:// 要求に使用するプロキシ サーバー識別子の一覧。他のプロキシがない場合は 、他のすべてに使用するプロキシ サーバー識別子の一覧 (他の 2 つのリストでは一致しません) Edge で手動プロキシ設定を使用する方法は多数あります (他のセクションで説明します)。
次の例では、コマンド ライン メソッドを使用します。
--proxy-server=XXXを使用して Edge を起動する (必要に応じて--proxy-bypass-list=YYY)
例: すべての要求にプロキシ http://foo:8080 を使用するには、 --proxy-server="http://foo:8080"で Edge を起動できます。 これは次のようになります。
HTTP のプロキシ - HTTPS の空のプロキシ - 空の他のプロキシ - http://foo:8080 上記の構成では、プロキシ サーバーに到達できない場合、すべての要求が ERR_PROXY_CONNECTION_FAILEDで失敗します。 これに対処するために、 --proxy-server="http://foo:8080,direct://" を使用して起動することで DIRECT にフォールバックを追加できます (コンマ区切りリストに注意してください)。 このコマンド ラインは、次のことを意味します。
HTTP のプロキシ - HTTPS 用の空のプロキシ - 空の他のプロキシ - http://foo:8080、direct://代わりに HTTPS プロキシ https://foo:443を介して URL のみをプロキシする必要があり、他のすべてが SOCKSv5 プロキシを使用場合は、で Edge を起動できます。 これで、次のように拡張されます。
HTTP のプロキシ - HTTPS のプロキシ https://foo:443 - 空の他のプロキシ - socks5://mysocks:1080 上記のコマンド ラインでは WinInet のプロキシ マップ形式が使用され、いくつかの追加機能があります。
hostname:portだけでプロキシ サーバーに名前を付ける代わりに、プロキシ サーバー識別子に Edge の URI 形式を使用できます。 つまり、プロキシ スキームにプレフィックスを付けて、既定で HTTP に設定しないようにすることができます。
socks= マッピングは、より広く "他のプロキシ" と認識されます。 後続のプロキシ リストには任意のスキームのプロキシを含めることができますが、スキームを省略すると、HTTP ではなく SOCKSv4 として認識されます。
WebSocket URL をプロキシにマッピングする
手動プロキシ設定には、 ws:// または wss:// URL のマッピングがありません。
これらの URL スキームのプロキシの選択は、他の URL スキームとは少し異なります。 Edge で使用されるアルゴリズムは次のとおりです。
"その他のプロキシ" が使用できない場合は、"HTTPS のプロキシ" が使用できない場合は、"HTTP 用プロキシ" を使用します。これは RFC 6455 のセクション 4.1.3 の推奨事項に従います。
PAC スクリプトを使用して、 ws:// と wss:// を個別にルーティングできます。
手動プロキシ設定のプロキシ資格情報
ほとんどのプラットフォームの手動プロキシ設定では、プロキシ サインインにクリアテキストのユーザー名/パスワードを指定できます。 Edge はこれを実装せず、プロキシ設定に埋め込まれた資格情報は使用しません。
代わりに、プロキシ認証は通常のフローを通過して資格情報を見つけます。
プロキシ バイパス 規則
エッジの手動プロキシ設定では、プロキシ サーバー識別子の 3 つのリストを指定するだけでなく、URL パターンを使用して "プロキシ バイパス 規則" の一覧を指定できます。
このルールセットは、プロキシがそれ以外の場合に定義されている場合でも、特定の URL がプロキシの使用をすべてスキップする必要があるかどうかを決定します。
この概念は、"例外リスト"、"除外リスト"、または "プロキシ リストなし" などの名前でも知られています。
プロキシ バイパス 規則は、文字列の順序付きリストとして書き込むことができます。 一般的に順序付けは重要ではありませんが、減算ルールを使用する場合があります。
コマンド ラインから手動プロキシ設定を指定する場合は、 --proxy-bypass-list="RULES" スイッチを使用できます。RULES はセミコロンまたはコンマ区切りのバイパス規則の一覧です。
Edge がプロキシ バイパス 規則でサポートする URL パターン形式については、「プロキシ構成 URL パターン」を参照してください。
システム プロキシ設定を使用する場合は、Edge ではなくプラットフォームのルール形式を使用する必要があります。
プロキシ構成 URL パターン
このセクションでは、プロキシの構成のコンテキストで URL パターンを指定するために Edge がサポートする文字列構造について説明します。たとえば、プロキシ バイパス 規則や、ProxyOverrideRules ポリシーのDestinationMatchers値について説明します。 これらのパターンは、コマンド ライン フラグ、拡張機能、またはポリシーから Edge 手動プロキシ設定を定義するときに使用できます。
プロキシ構成 URL パターン: ホスト名
[ URL_SCHEME "://" ] HOSTNAME_PATTERN [ ":" <port> ]
ワイルドカード パターンとオプションのスキームとポート制限を使用してホスト名と一致します。
例:
foobar.com - 正規化されたホストが foobar.com*foobar.com されている任意のスキームとポートの URL と一致する - 正規化されたホストが foobar.com で終わる任意のスキームとポートの URL (たとえば、 blahfoobar.com と foo.foobar.com) *.org:443 - ポート 443 を使用し、最上位ドメインが .orghttps://x.*.y.com:99 されている任意のスキームの URL と https:// 一致します - 正規化されたホスト名が一致するポート 99 の URL と一致します x.*.y.com
プロキシ構成 URL パターン: サブドメイン
[ URL_SCHEME "://" ] "." HOSTNAME_SUFFIX_PATTERN [ ":" PORT ]
ドットで始まるホスト名パターンは、サブドメインが一致することを意味する特別なケースです。
.foo.com は、実質的に *.foo.comを記述する別の方法です。
例:
.contoso.com - outlook.contoso.com と foo.bar.contoso.comに一致しますが、 contoso.comhttp://.contoso.com は一致しません - サブドメインである http:// URL にのみ一致します contoso.com
プロキシ構成 URL パターン: IP リテラル
[ SCHEME "://" ] IP_LITERAL [ ":" PORT ]
IP アドレス リテラル、およびオプションのスキームとポートの制限である URL と一致します。 これは、IP リテラルの正規化を考慮したホスト名照合の特殊なケースです。 たとえば、ルール [0:0:0::1] と [::1] は同等です (どちらも同じ IPv6 アドレスを表します)。
例:
127.0.0.1
http://127.0.0.1
[::1] - IPv6 ループバック アドレスへの任意の URL と一致する [0:0::1] - 上記の http://[::1]:99 と同じ - ポート 99 の IPv6 ループバックへの任意の http:// URL と一致します
プロキシ構成 URL パターン: IPv4 アドレス範囲
IPV4_LITERAL "/" PREFIX_LENGTH_IN_BITS
ホスト名が IPv4 リテラルであり、指定されたアドレス範囲の間にある任意の URL と一致します。
これは、IP リテラルである URL にのみ適用されることに注意してください。
例:
192.168.1.1/16
プロキシ構成 URL パターン: IPv6 アドレス範囲
IPV6_LITERAL "/" PREFIX_LENGTH_IN_BITS
指定された範囲の間にある IPv6 リテラルである任意の URL と一致します。 IPv6 リテラルは角かっこで囲んではなりません。
これは、IP リテラルである URL にのみ適用されることに注意してください。
例:
fefe:13::abc/33
[fefe::]/40 --間違って！ IPv6 リテラルを角かっこで囲んではなりません
プロキシ構成 URL パターン: 単純なホスト名
<local>
ピリオドを含まないホスト名と一致し、IP リテラルではありません。 これは単純な文字列検索です。つまり、ピリオドが任意の場所に表示されるカウント (末尾のドットを含む!) を意味します。
この規則は、macOS の [単純なホスト名を除外する] チェック ボックスと、Windows の [ローカル (イントラネット) アドレスにプロキシ サーバーを使用しない] に対応します。
ルール名は WinInet から取得され、localhost の概念と簡単に混同できます。 ただし、2 つの概念は直交しています。 実際には、localhost をバイパスするルールは追加されません。これは既に暗黙的に行われているためです。
プロキシ構成 URL パターン: 暗黙的な規則を減算する
<-loopback>
暗黙的なプロキシ バイパス 規則 (localhost とリンク ローカル アドレス) を減算します。 これは、テストのセットアップにのみ必要です。 localhost のプロキシに対するセキュリティへの影響に注意してください。
通常のバイパス 規則は、プロキシを使用してはならない URL についてブラウザーに指示しますが、この規則は逆の効果を持ち、代わりにプロキシを使用するようにブラウザーに指示します。
ルールは左から右の順序で評価されるため、減算ルールを使用する場合は順序付けが重要な場合があります。
<-loopback>;127.0.0.1 は、 127.0.0.1;<-loopback>とは微妙に異なる効果を持ちます。
IP アドレス範囲バイパス規則の意味
手動プロキシ設定の IP アドレス範囲バイパス規則は、URL リテラルにのみ適用されます。 これは直感的に期待されることではありません。
例:
たとえば、すべての要求にプロキシを構成したが、 192.168.0.0.1/16のバイパス規則を追加したとします。 この IP を含むバイパス 規則を示したので、 http://foo (セットアップで 192.168.1.5 に解決されます) に移動した場合、ブラウザーは直接接続 (プロキシをバイパス) しますか?
プロキシを経由します。
ブラウザーが実際に fooの名前解決を行うことはないため、この場合のバイパス規則は適用されません。 プロキシ解決は名前解決の前に行われ、後で選択されるプロキシ スキームによっては、クライアント側の名前解決が実行されないことがあります。
URL が明示的に IP リテラルである要求にのみ適用されるため、IP 範囲プロキシ バイパス 規則の有用性はかなり制限されます。
URL のホスト名の解決された IP アドレスに基づいてプロキシの決定を行う必要がある場合は、PAC スクリプトを使用する必要があります。
暗黙的バイパス規則
特定のホストへの要求はプロキシを介して送信されません。代わりに直接送信されます。
これらの暗黙的なバイパス 規則を呼び出します。 暗黙的なバイパス規則は、ホスト部分が localhost 名またはリンクローカル IP リテラルである URL と一致します。 基本的には次のようになります。
localhost
*.localhost
[::1]
127.0.0.1/8
169.254/16
[FE80::]/10 完全なルールは少し複雑です。 たとえば、Windows では、 loopbackも認識されます。
暗黙的なプロキシ バイパス 規則のこの概念は、Windows と macOS でのプラットフォーム レベルのプロキシ サポートと一致しています (ただし、実装の違いによるいくつかの違いはありますが、 net::ProxyHostMatchingRules::MatchesImplicitRulesの互換性に関するメモを参照してください)。
最初に暗黙的なプロキシ バイパス 規則を適用する理由 確かに、人間工学とユーザーの期待に関する考慮事項がありますが、より大きな問題はセキュリティです。 Web プラットフォームでは localhost が安全な配信元として扱われますので、プロキシ機能によって追加の権限が付与されます。 これは、PAC スクリプトを使用する場合と同様に、プロキシ設定が外部で制御可能な場合に特に問題になります。
暗黙的バイパス規則のオーバーライド
セキュリティ上の問題にもかかわらず、localhost へのトラフィックをプロキシ経由で送信する場合は、特別なプロキシ バイパス 規則 <-loopback>を追加することで行うことができます。 このルールは、暗黙的なルールを減算する効果があります。
たとえば、コマンド ライン フラグを使用して Edge を起動します。
--proxy-bypass-list="<-loopback>"
現在、PAC スクリプトを使用するときに暗黙的なプロキシ バイパス 規則を無効にするメカニズムはありません。 プロキシ バイパス 規則 は 手動設定にのみ適用されるため、この手法を使用して PAC スクリプトが localhost URL のプロキシを決定することはできません。
コンテンツ ライセンス
注
このページの一部の情報は、Chromium.org によって作成および共有されている著作物に基づいており、Creative Commons Attribution 4.0 International License に記載されている条項に従って使用されています。 元の Chromium のページはこちらです。
この著作物は、Creative Commons Attribution 4.0 International License に従って使用許諾されています。