プロバイダー側のパスワードが正しくても、実際に選択されたプロキシに対する一致する認証情報が確立されるわけではありません。そのエンドポイントのスキーム、ホスト、ポートから確認します。ホスト欄は通常ホスト名か IP のみを受け付け、完全な URL は受け付けません。

  1. 認証のやり取り全体を読みます。 407 の後に再試行が受け入れられる のは正常な場合があります。ログインを拒否と判断する前に、最終結果が依然として 407 であることを確認してください。
  2. 経路と認証情報のスコープを比較します。 実際のホスト/ポートと、導入済みの HttpClient 5 AuthScope が定義する他の項目を突き合わせます。ポートが誤っていると BasicCredentialsProvider に適切なエントリが残らないことがあります。
  3. メソッドと ID を確認します。 プロキシは対応するメソッドを提示したか。再試行は想定どおりの接続を使ったか。運用者がドメイン修飾アカウントや別の文書化された形式を要求していないか。

導入済みのメジャーバージョンの API を使います。HttpClient 4 の認証キャッシュのレシピはバージョン 5 にそのまま移行できません。任意のユーザー名の変種を試すのではなく、運用者のアカウント要件に従います。

先制認証はもう一つの意図的な選択です。互換性のあるスキームでは往復を 1 回減らせますが、認証情報が送出されるタイミングが変わり、対応するスコープが必要です。エンドポイントの不一致や非対応メソッドに対する最初の修正にはできません。

チャレンジされたプロキシの識別情報、メソッド、スコープの一致、最終ステータスを、伏字化した 診断情報 に残します。パスワードや認証情報を含む生のトレースは、その比較には不要です。

関連記事