ブラウザープロファイル別プロキシのDNS、認証、障害モード

このガイドでは、Chromiumに文書化されたネットワーク動作を基準にします。他のブラウザーや製品は異なる選択を行う場合があり、ブラウザー管理ツールはChromiumの周囲にローカルネットワークブローカーを加えられます。実際に運用する正確なビルドの動作を確認してください。

独立した四つの質問から始める

プロキシの記録には通常、方式、エンドポイント、ポート、場合によっては認証情報の参照が含まれます。しかし、次の四つのポリシー判断は別々に残ります。

1. 適用範囲： どのブラウザーリクエストとプロトコルをこのプロキシへ割り当てるか。
2. 名前解決： 端末とプロキシのどちらが宛先ホスト名を解決するか。
3. 認証： どのクライアントとプロキシの方式が組み合わせて動き、認証情報をどこに保存するか。
4. 障害： 接続エラー時に、リクエストを停止するか、別のプロキシを試すか、直接接続へフォールバックするか。

これらを一つの「プロキシ有効」スイッチとして扱うと、多くの予期しない結果が生じます。Chromiumはプロキシ選択をURL単位の解決として説明しています。宛先を解決する前に、URLから順序付きのプロキシ候補一覧を作ります。バイパスとフォールバック規則も、この判断の一部です。

プロファイル別プロキシが対象にするもの

GoogleのProxySettingsポリシーは、Chromeプロファイル単位で適用されます。直接接続、システム設定、自動検出、固定サーバー、PACスクリプトの各モードを選択でき、明示的なバイパスとPAC必須の項目を持ちます。

この境界は、VPNまたはOSのネットワーク名前空間より狭いものです。ブラウザーのネットワークコンテキストが処理するリクエストを管理しますが、次を自動的には管理しません。

• デスクトップ管理ツール自身のAPI呼び出し。
• 別プロセスのアプリケーションまたはブラウザーアップデーター。
• OSのDNSと接続確認。
• ダウンロード済みファイルから起動した別のアプリケーション。
• 拡張機能の別プロセスのネイティブヘルパー。
• 暗黙のループバックバイパスを通じて到達するローカルサービス。
• 選択したプロキシ経路が運べないプロトコルによる通信。

これらの一部には独自のプロキシ対応がある場合があります。その対応は別に仕様化し、テストする必要があります。「プロファイルの通信はこのプロキシを使う」と製品が述べるなら、端末全体の経路であるかのように示さず、含まれるプロセスとプロトコルを明示すべきです。

一つのHTTPSリクエストを追跡する

通常のHTTPSナビゲーションには複数の手順があります。

1. 経路を選ぶ

ブラウザーは、固定規則、プロキシ自動構成スクリプト、システム設定を評価します。バイパスに一致すると直接接続を選ぶ場合があります。プロキシ一覧は、プライマリプロキシに続く代替候補を指定でき、直接フォールバックを認める場合はDIRECTも含められます。

Chromiumは、localhostとリンクローカルの宛先に暗黙のバイパスも適用します。これにより、外部から制御されたプロキシ設定からローカルオリジンを保護しますが、「すべての通信」という広い説明には注記が必要になります。

2. プロキシを解決し接続する

プロキシのエンドポイントがホスト名なら、端末はそのエンドポイントを解決し接続する方法を必要とします。遠隔で宛先DNSを処理しても、この初期解決はなくなりません。この段階の失敗は、プロキシへ到達できてもプロキシが宛先を解決できない場合とは異なります。

3. プロキシへ認証する

認証情報を必要とするHTTPプロキシは、通常、チャレンジを伴う407 Proxy Authentication Requiredを返します。RFC 9110は、このやり取りとProxy-AuthenticateおよびProxy-Authorizationフィールドを定義しています。

Chromiumは、手動プロキシ設定に埋め込まれたユーザー名とパスワードを使いません。プロキシ文書は、認証がブラウザーの通常の認証情報フローに従うと説明しています。したがって、プロファイル管理ツールには、対応するチャレンジ向けの明示的な連携が必要であり、どのuser:password@host文字列でも動くと約束してはいけません。

4. 宛先接続を確立する

HTTPプロキシでは、Chromiumは宛先名の解決をプロキシへ任せます。HTTPSの宛先では、ブラウザーがプロキシにCONNECTトンネルの作成を求め、そのトンネルを通じて宛先とのエンドツーエンドTLSを行います。

プロキシには宛先ホスト名と接続メタデータが見えます。クライアントからプロキシまでの区間が平文HTTPなら、CONNECTリクエストとホスト名はその区間の観察者から保護されません。HTTPSプロキシはブラウザーとプロキシの間にTLSを加え、その区間の観察者からメタデータを保護します。プロキシ自身から要求先を隠すものではありません。

通常の転送では、プロキシはトンネル内のHTTPSページ内容を読めません。TLS傍受は別の信頼モデルです。クライアントが認証局を信頼し、中間者がTLSを終端して再作成できるようにします。通常の転送と黙って混同してはいけません。

DNSの管理主体はプロキシ方式で変わる

Chromiumに文書化された動作は、プロキシ種別によって異なります。

選択経路	Chromiumでの宛先名解決	重要な制限
直接またはバイパス	端末またはブラウザーのリゾルバー	宛先通信がプロファイルプロキシを通らない
HTTPプロキシ	プロキシ側	平文HTTPのクライアント・プロキシ間通信ではHTTPリクエストが見え、HTTPSはCONNECTを使う
HTTPSプロキシ	プロキシ側	クライアントがプロキシのTLS証明書を検証する必要がある
SOCKS4プロキシ	クライアント側	IPv4宛先のみ。ChromiumはSOCKS4aフォールバックを実装しない
SOCKS5プロキシ	プロキシ側	ChromiumはTCPのURLリクエストに使い、SOCKS5認証には対応しないと文書化している

RFC 1928は、SOCKS5リクエストでドメイン名を運べることと、複数の認証方式識別子を定義しています。プロトコルの能力は、クライアント実装を保証しません。Chromiumは現在、SOCKS5プロキシへ宛先名を送りますが、組み込みSOCKS5クライアントはどのプロキシ認証方式にも対応しないと説明しています。ユーザー名とパスワードを使うSOCKS5アクセスを提供する事業者には、対応する中間層または別のプロキシ方式が必要な場合があります。記録を受け入れる前に、ブラウザー実装を確認してください。

DNS-over-HTTPSは別の層を加えます。ChromeのDnsOverHttpsModeポリシーは、安全でないDNSへフォールバックできるautomaticと、安全なDNSが失敗すると名前解決も失敗するsecureを区別します。同じ文書ではこのポリシーをブラウザー単位、ProxySettingsをプロファイル単位としています。この不一致は重要です。ある設定に「プロファイル」と付いても、すべてのDNS管理が同じ範囲になるとは限りません。

製品が各プロファイルを別のブラウザープロセスで動かせば、実質的により狭い境界を作れる場合がありますが、これは実装上の選択です。テストしてください。根拠では次を区別します。

• プロキシエンドポイントの解決。
• 要求先の宛先解決。
• 直接またはバイパスされたリクエストで使うDNS。
• 安全なDNSの初期接続とフォールバック。
• プロファイルのブラウザーネットワークコンテキスト外の要素が行うDNS。

認証は互換性と秘密情報の取扱いの両方に関わる

ChromiumはHTTPプロキシ向けにBasic、Digest、Negotiate、NTLMを文書化しています。HTTPSプロキシはクライアントからプロキシまでを保護し、クライアント証明書にも対応できます。SOCKS5仕様に認証方式が存在しても、Chromiumの組み込みプロキシクライアントはSOCKS4またはSOCKS5認証を実装していません。

対応する方式でも、通信が不適切なら安全ではありません。RFC 7617は、Basic認証情報がBase64でエンコードされるだけであり、TLSなどの保護されたチャネルが必要だと説明しています。平文HTTPプロキシへBasic認証すると、その区間を観察できる人にプロキシパスワードが見えます。

プロファイル管理ツールは、次のデータを分けて扱うべきです。

• 方式、ホスト、ポート、提供者名などの秘密でないエンドポイントメタデータ。
• ライフサイクルまたはネットワークサービスが使う秘密情報参照。
• 保護されたストレージ内の認証情報の値。
• インターフェースと監査記録向けの編集済み接続状態。
• 管理されたサポート手順でのみ利用できる診断詳細。

通常の画面、ログ、API、エクスポート、自動化出力にプロキシパスワードは不要です。担当者に通常必要なのは、認証が失敗したこと、どの方式が要求されたか、どのエンドポイントか、フォールバックが起きたかです。

障害モードと現れ方

障害	起こり得る症状	確認する境界
プロキシ方式が誤り	TLSまたはプロトコルのハンドシェイク失敗	HTTPSエンドポイントをHTTPとして宣言したか、その逆か
プロキシのホスト名を解決不能	プロキシへ到達する前に接続失敗	初期解決をどのリゾルバーが行ったか
プロキシポートへ到達不能	タイムアウトまたは接続拒否	別のプロキシまたはDIRECTが一覧の次にあるか
認証チャレンジに未対応	407の繰り返しまたはサインイン画面	ブラウザーが要求された方式を実装しているか
認証情報が誤りまたは期限切れ	認証情報送信後に407	秘密情報参照が解決され、出力から値が隠されたか
HTTPSプロキシ証明書の失敗	プロキシへの安全な接続を拒否	証明書検証が保たれているか
プロキシが宛先を解決不能	プロキシ固有のホストまたはトンネルエラー	クライアントが宛先を直接再試行しなかったか
CONNECT拒否	その宛先へのHTTPS移動が失敗	拒否をポリシーとして扱い、バイパス許可にしていないか
PACファイルが利用不能	プロキシ解決の停止または経路変更	PACが必須か、Chromiumが密かにDIRECTを使えるか
バイパスパターンが広すぎる	選択したサイトへ直接接続	正確なホスト、サブドメイン、ポート、暗黙の規則を理解しているか
WebRTCが別のインターフェースを使用	メディア経路がページ通信と異なる	プロファイルでプロキシを通らないUDPを無効にしたか
既存接続が変更後も残る	古い経路が一時的に有効	接続を終了するか、プロファイルを再起動するか
診断取得が詳細すぎる	URL、ホスト名、秘密情報がサポートファイルへ入る	どの編集モードと保存規則を使うか

Chromiumのフォールバックは状態を持ちます。接続レベルで障害が起きたプロキシは、一定期間不良としてマークされ、他の候補より後に回される場合があります。一覧にDIRECTがあれば、後のリクエストがプロキシを通らない可能性があります。CONNECT拒否は、プロキシ障害ではなく意図的な宛先ポリシーかもしれないため、別に扱われます。

PACの障害には特に注意が必要です。Chromiumは、PACファイルが利用不能な場合、PACを必須としない限り、密かに直接接続へフォールバックできると説明しています。ChromeのProxySettingsポリシーは、その直接フォールバックを防ぐためにProxyPacMandatoryを公開しています。

WebRTCとUDPには別の判断が必要

ページは、通常のHTTP・HTTPS URLリクエストと同等でないWebRTC経路を使えます。Chromeの既定のWebRtcIPHandlingポリシーは、利用可能なすべてのインターフェースを使えます。disable_non_proxied_udpモードは、構成したプロキシがUDPに対応しない限り、公開インターフェース上のWebRTCをTCPへ制限します。

このポリシーはプロファイル単位と文書化されているため、プロファイルプロキシに関係しますが、別の管理策です。メディア性能を下げたり、直接UDPを必要とする業務を壊したりする可能性があります。トレードオフを明示的に選び、テストしてください。ページ読み込みが成功しただけで、すべての通信がプロキシ内に収まると主張してはいけません。

安全側の失敗と可用性のどちらを選ぶか

可用性を重視する一般ブラウジング用プロファイルでは、直接フォールバックが適切な場合があります。認可、プライバシー、地域テストの妥当性が特定の出口経路に依存する業務では安全ではありません。

適切なプロファイルポリシーは、意図した動作を明示します。

• 必須プロキシ： 選択経路を利用できない場合、対象ネットワークリクエストを停止する。
• 承認済みプロキシ群： 同等のポリシーを持つ指定済み代替だけを試す。
• 直接フォールバックを許可： 経路変更を表示し、秘密情報の値なしでイベントを記録する。
• 明示的バイパス： 宛先区分と、直接アクセスが必要な理由を文書化する。

インターフェースは、起動前と障害後に経路状態を見えるようにする必要があります。プロキシから直接接続へ黙って変えると、ネットワークエラーが完全性エラーになります。業務が成功したように見えても、誤った経路を使っている可能性があります。

安全な検証表

自分が所有する、または調査権限を持つエンドポイントとDNSゾーンでテストします。実行前に期待結果を記録してください。

1. 宣言したプロキシ方式が、実際のエンドポイント通信と一致することを確認する。
2. HTTP、HTTPS、WebSocket、必要なWebRTCの動作が成功することを確認する。
3. 管理する宛先で出口アドレスを観察する。
4. どのリゾルバーが宛先名を受け取り、どのリゾルバーがプロキシホスト名を初期解決するか観察する。
5. テスト認証情報を期限切れにし、生の値がインターフェース、ログ、自動化出力に現れないことを確認する。
6. テストプロキシを到達不能にし、構成済みの安全側に失敗する動作またはフォールバック結果を確認する。
7. 管理する一つのCONNECT宛先を拒否し、ポリシー拒否が直接アクセスへ変わらないことを確認する。
8. テストPACを利用不能にし、必須動作を確認する。
9. 業務に必要な正確なホスト、サブドメイン、ローカル、リンクローカル、IPv4、IPv6のバイパス事例を実行する。
10. 接続中にプロキシを変更し、新しい経路がいつ有効になるか確認する。
11. テストに必要な診断詳細だけを取得し、保存と削除を確認する。

ChromiumのNetLogガイダンスは、ネットワークログ取得をプライバシーとセキュリティの問題として扱っています。編集済みモードでは機密フィールドを省けますが、詳細モードにはCookieまたは認証ヘッダーが含まれる場合があります。サポートファイルは、ファイル名ではなく、実際の取得モードに従って扱ってください。