ヘッドレス ブラウザのプロキシ認証は VPN ルートではありません

ルートと資格情報は別のものであるため、VPN はブラウザのトラフィックをプロキシ サーバーに送信しても、ブラウザがそのプロキシを使用できないままにすることがあります。ヘッドレス自動化では、ウィンドウやプロンプトがないため、ギャップが見えにくくなります。この障害は通常、ハングまたは一般的なナビゲーション エラーとして現れ、最初はトンネルのせいだと直感します。以下のチェックリストは、認証されたプロキシを介したヘッドレス リクエストが成功するために満たす必要がある 四 つの事項を分類しています。

二 つの会話、二 つの認証情報

二 つの会話が発生しますが、それらは異なる当事者に属しています。ブラウザは最初にプロキシ リスナーに接続し、資格情報を要求することがあります, その後、プロキシは宛先への以降の接続を確立または許可します。VPN は、ブラウザーに挑戦するエンドポイントにならずに最初のレグを実行できますが、二 番目のレグについては何も言う必要はありません。

HTTP 407 クライアントがプロキシ要求に対して認証する必要があることを示す信号で、Proxy-Authenticate で運ばれ、応答は Proxy-Authorization で期待されます。これは宛先 Web サイトのログインではなく、両者を混同することがここで最も一般的な混乱の原因です。

したがって、四 つのチェックは、ブラウザーが実際に選択したプロキシ、407 に誰が応答するか、ブラウザーのプロセスがどのネットワーク上にあるか、および資格情報が人間を介さずにどのように配信されるかです。それぞれが独立して失敗する可能性があり、それぞれの失敗は外から見ると同じように見えます。後のチェックでは前のチェックを補うことはできないため、順番に作業してください。選択されていないプロキシは認証できず、ラップトップ上にのみ存在する資格情報はコンテナに到達できません。

1 を確認してください: どのプロキシが実際に選択されているか

プロキシ設定を無視するブラウザは、チャレンジにまったく到達しないため、選択から始めます。Chrome ではフラグは --proxy-server=proxy.example:3128 で、除外には --proxy-bypass-list が使用されます, Selenium はブラウザー オプションを通じて同じものを公開します。PAC ファイルは、独自の障害モードを持つ異なるメカニズムです。

次に、シェルからではなく、実行中のブラウザの環境内から確認します。同じプロキシを持つ独立したプローブは curl -x http://proxy.example:3128 -v https://example.com で、その詳細出力には、 CONNECT が成功したかどうか、返された Proxy-Authenticate 、および 407 が返されたかどうかが示されます。curl が 407 を取得し、ブラウザがハングする場合は、ネットワークではなく認証情報のパスが問題です。CURL が成功してもブラウザが成功しない場合、ブラウザは、想定されているプロキシを使用していません。

2 を確認してください: 407 に答える人

407 には所有者があり、その名前によって修正の行き先が決まります。チャレンジが企業プロキシから送信された場合、修正はブラウザーが無人で提示できる資格情報になります。最初のプロキシが転送する上流プロキシからのものである場合、資格情報はその 二 番目のホップに属し、最初のプロキシはチャレンジを変更せずに中継している可能性があります。Proxy-Authenticate ヘッダーの認証スコープとホストを読み取ります, これらは要求しているボックスに名前を付けているためです。

何を記録する場合でも、その区別を維持してください。プロキシ チャレンジ、転送接続の拒否、Web サイトへのサインイン、および VPN トランスポート タイムアウトは、四 人の異なる所有者による 四 つの異なる失敗であり、一 つの一般的なエラー メッセージによって必要な情報が破壊されます。

3: 認証情報のパスを確認します

ほとんどの無人セットアップでは、資格情報自体が問題になります。Selenium はプロキシ ホストとポートを設定できますが、HTTP プロキシ認証はその構成の移植性の部分ではなく、プロキシ URL の資格情報はブラウザーやドライバーのバージョン間で信頼できるメカニズムではありません。サポートされているオプションは、実際のスタックに文書化されているオプションです, チャレンジに答えるブラウザー拡張機能、ヘッダーを追加しジョブからのみアクセス可能なローカル転送プロキシ、または他の手段でワークロードを認証するプロキシです。慎重に 一 つを選択し、実行するブラウザ、ドライバー、Selenium の正確なバージョンと照らし合わせて確認してください。

資格情報を漏洩する場所に保管しないでください。コマンド ラインはプロセス リストに表示され、スクリーンショットはテスト レポートに含まれ、ブラウザ トレースと HAR ファイルはヘッダーをキャプチャし、コミットされたテスト構成は永久に保持されます。ジョブのシークレット配信メカニズムとそのリダクション ルールを使用し、プロキシ アカウントの範囲を必要な宛先またはロールに設定します。

組織が必須のプロキシではなく、許可された直接 VPN ルートを提供している場合は、二 つの設計を明示的に比較してください。ポリシーを回避するために、プロキシを静かに無効にしたり、別のクライアントの認証を模倣したりしないでください。

4 を確認してください: ブラウザ プロセス自身のネットワーク コンテキスト

これは人びとがスキップするチェックです。ワーカー、コンテナ、またはリモート Selenium Grid ノードによって起動されるブラウザは、その環境のネットワークを使用するため、ラップトップの VPN 接続とシェルのプロキシ変数は、ブラウザが決してアクセスできないパスを記述します。

失敗したジョブに関する 五 つの事実 (ブラウザー ホスト、構成されたプロキシ、初期リゾルバー パス、選択されたルート、認証の所有者) を記録します。次に、通常の宛先 TLS 検証とアプリケーション認証をオンのままにして、その正確なコンテキストから無害な承認済みリクエストを 一 つ作成します。ヘッドレス ブラウザが正常に起動しても、プロキシ アドミッションも VPN カバレッジも証明されません, また、空白のページのスクリーンショットは何も証明しません。チェーン全体を通じて 200 を返すリクエストが唯一重要な証拠です。

完成したワークフローには、セットとしてチェックする価値のある 三 つのプロパティがあります。ブラウザ ホストからプロキシへのルート、プロキシと宛先を指定する明示的な中間ポリシー、および目に見えないプロンプトに応答するオペレータに依存しない資格情報のライフサイクルがサポートされています。三 つのうちのいずれかが人に依存している場合、終了コードが何であろうと、ジョブはまだ無人ではありません。次の人がパイプラインを継承する前に、五 つの事実を書き留めてください。