CONNECT を拒否するプロキシは、そのポリシーや後続接続の失敗を説明する HTTP エラードキュメントを返すことがあります。通常の HTTP プロキシに対する許可された診断では、curl はそのリクエストを直接送信し、応答を保存できます:

curl --proxy '' --http1.1 --max-time 10 \
  --request CONNECT \
  --request-target service.example:443 \
  --header 'Host: service.example:443' \
  --dump-header tunnel.headers \
  --output tunnel.body \
  http://proxy.example:8080/

最後の URL はプロキシのリスナーを指定します。許可された公開プロキシの比較には、HTTP プロキシ一覧がそのリスナー URL の候補を提供します。--request はメソッドトークンを、--request-target は CONNECT の authority を渡します。両者を分けておくと CONNECT service.example:443 HTTP/1.1 が生成されます。

空の proxy オプションは、curl がこの診断を別の継承されたプロキシ経由で送るのを防ぎます。このコマンドは HTTP エラードキュメントを保持できるよう、意図的に --fail を省いています。

認証なしの試行は、調査対象の失敗に達する前に 407 で止まることがあります。認証済みリクエストを再現するときは、プロキシが想定する認証方式を使ってください。

これは失敗応答を調べるためのものです。プロキシが 2xx を返すと、接続は通常の HTTP 本文転送ではなくトンネルになります。このカスタムメソッドの診断は宛先の TLS 交換を開始せず、受け入れられた開いたトンネル上でタイムリミットに達することがあります。

実際の HTTPS 取得には通常の --proxy リクエストフローを使ってください。診断のステータスと本文は、その特定のプロキシと対象とともに保管してください。

関連記事