プロキシ使用時の WRONG_VERSION_NUMBER：HTTP と HTTPS を確認する

エラーは「バージョンが違う」と言うので、TLS バージョンを切り替えたくなります。プロキシの場合は、まず手前の可能性を確認してください。クライアントは、平文 HTTP を待っていたポートに TLS ハンドシェイクを送っていないでしょうか。

https://example.com/ のような宛先と http://proxy.example:8080 のようなプロキシは、よくある組み合わせです。2 つ目の URL を HTTPS に変えると、クライアントはプロキシ自体との会話を暗号化するよう指示されます。HTTPS のウェブサイトを許可する指示ではありません。

最初の TLS 会話を特定する

HTTP プロキシでは、クライアントはまず CONNECT を送り、HTTP の応答を受け取れます。その後にだけ、トンネルの中で宛先の TLS を開始します。HTTPS プロキシでは、先に プロキシへの別個の TLS 接続が来ます。

HTTP のエラーページやその他の平文を受け取った TLS パーサーは、プロトコルエラーを報告することがあります。その文言は、サイトが対応する TLS バージョンを示すものではなく、サイトに接続したことさえ示しません。

1. プロキシの URL をスキーム込みで記録し、エンドポイントの文書化されたプロトコルも記録します。
2. 失敗が CONNECT 応答の前、宛先の TLS の途中、プロキシ自身の証明書の検証中のどこで起きたかを特定します。
3. 古い回避策と比べるときは、実際のクライアントと依存関係のバージョンを確認します。以前のプロキシ実装はスキームを別扱いすることがありました。

修正の多くは、それぞれ別の理由で誤りになり得ます。HTTP プロキシ一覧は、そうした経路で許可された公開リクエスト向けに、通常の HTTP エンドポイント候補を提供します。平文 HTTP のエンドポイントには HTTP プロキシのスキームが必要で、本当に TLS が有効なエンドポイントは HTTPS と証明書検証を保つべきです。CONNECT を拒否するプロキシには、対応するサービスかポリシーが必要で、ライブラリの場当たり的なダウングレードではありません。

最初に観測できた失敗を残してください。証明書検証を無効にしても HTTP 専用のリスナーが TLS を話すようにはならず、古い暗号ポリシーを選んでも、サイトのハンドシェイク前に返された HTTP の拒否は説明できません。